Overload <virusprot>with max-src-conn-rate not wanted</virusprot>
-
Hello, I just figured out why the old method I used to limit the damage that an infected computer (spam generator) could do, now completely blocks all traffic from the host when it is triggered.
It looks like any time I set the max-src-conn-rate in a rule, it adds on the overload option, which placed the source ip in the virusprot table when triggered. Is their a way to change this back to the old behavior of just blocking any more states being created for that combination of src and rule until the limit has been met?
I get why it would be preferable to completely block the client from any network access, and clean it up. But for my use case, I cannot provide any help to the clients that would hit that block. They would just see it as the wireless being broken, and complain to staff that cannot take any action to fix the problem.
Thanks
Josh -
How is the behavior really all that different? If they hit the limit, things will break without being able to make new states. If you set the limit right, they'd only be hitting that if they are broken in some way (or abusing the network). The virusprot table gets cleared periodically (1hr I think?) so eventually it will work again.
But if they are compromised, you would really want to block them and not let them keep pumping spam out over the existing connections they do have. If they complain that it's broken, have the on-site staff instructed to tell them that can happen if they have a virus/torrent/whatever.
-
jimp, the old behavior would just stop any new connections that matched the rule, so it would just stop them from making new smtp connections after they hit the limit. So the user could keep playing farmville, checking their aol account, etc, but keeping the location from being listed on spam blacklists.
In this situation I have no control over the equipment that connects to the wireless network, and I need the connection to just work, without staff having to have any interaction with the users.
The problem with having on site staff instructing the users, is that there is no way for on site staff to know that in this instance, the user cannot connect to the network because they have a spambot. The symptom(to the user) is the same as when the captive portal randomly stops working, or when the user doesn't turn on their wireless card, or when they have a helpful friend statically set their dns, or when they don't have dhcp enabled at all, or when they have a socks proxy set, etc. I guess I just don't want this feature to increase my workload with more reports of wireless problems.
Also, if a user did want to try and download tools to fix their computer, it would be difficult to do with no way to connect to the sites that have such tools.
If the virusprot feature included it's own captive portal setup I could see it working. It would redirect the user to a page that explains why they are being limited, and still allow access to certain sites such as virus updates, majorgeeks malware removal guide, etc.
But going back to my orig question. How about just having a checkbox "Block all on trigger" under the advanced rule. If it is checked then add an ip to the virusprot table. If it isn't checked use the old behavior. Do you think this would be considered for 2.1? It seems like without this feature the only use case for the rate limiting rules is to catch infected machines. What if someone wanted to use the feature to limit the number of web requests a web spider was making to their servers, or … some other made up example I cannot think of right now. :)
Thanks
Josh
