Flood vulnerability

[dubux]

The bots current state responds to commands from ANY user on irc. Example:

.load yweather
You aren't allowed to do that. (requires admin)
.load yweather
You aren't allowed to do that. (requires admin)
.load yweather
You aren't allowed to do that. (requires admin)
.load yweather
You aren't allowed to do that. (requires admin)

This can easily be exploited with a 2 man botnet to flood the bot off a server over and over again. My proposal is to limit the amount of commands that can be executed in a certain time period or only respond verbosely to so many commands in a given time period. The time period should probably be user defined within the configuration file.

[veiset]

This is also affecting commands like:

.currency 5 USD to EURO
Result: some currency amount
.currency 5 USD to EURO
Result: some currency amount

Not sure how to handle that. I agree that some throttling would probably be a good idea, but I am quite unsure how to implement this. It would seem like the bot is 'dropping/ignoring' requests at times if it ignores commands like .currency, .duration, .tv and so on. These commands can be abused in the same way you described the '.load' command.

Any suggestions how to solve this in an efficient matter would be appreciated.

Flagging this as an enhancement as this is not really a bug, but more an issue with how IRC-servers usually works.

[dubux]

My suggestion...

Rules must apply to anything that executes a command which returns data to any entity via PRIVMSG (msg, channel, etc).

1 - Keep track of single user flooding by hostname/ip address and throttle accordingly based of a command:seconds ratio. If the threshold is hit, notify the user they cannot request public commands for x amount of time.

2 - Create a global threshold and queuing system. If x amounts of commands are thrown, queue the command for x amount of time. Keep track of these commands, if the user is still in the channel where the command originated from, return the results once their position in the queue has been reached. A certain amount of queues should be given (via configuration file). If the queue is full, the user who initiates a public command should be ignored. This should prevent any botnets or groups of people from flooding the brunobot offline by attempting to execute an excessive amount of commands. This should also keep the load down on the location or server of where the bot is running giving itself a lighter footprint in times when bot modules are being used heavily.

[veiset]

Thanks for the feedback. I am still a little unsure about this.

Your approach using a commands per second (for an interval, e.g: 5 messages allowed during any 10 seconds) should be quite easy to implement as the bot currently is built, if you ignore messaging the user warning him/her about the threshold.

The problem occur if you start restricting it to, or filtering it on specific users. The communication.say() method currently uses the parameters target and message.

class Communication():
...
    def say(self, target, message):
    ...

It has no information about who sends the message. This means that we would have to rewrite all the modules that are currently using the communication object. This is not that huge of a problem, and should absolutely be possible (with some work). It is just that it adds a lot of extra complexity for a very small benefit, and makes the code less readable as you will always have to pass a third (forth, and fifth) argument to the say() method. As in:

def say(self, target, message, userOfSender, identOfSender, hostOfSender):

You will also have to manage queues for this. That being said, I quite agree with you on that this is actually an issue we need to think about. If the simplest approach (your (1) without user feedback) is enough that would be great. We could possible set the standard spam value to quite high to avoid the problems I mentioned in the last reply in this issue.