On Wed, 5 Aug 2009, J. Oquendo wrote:
The fact that if you used fail2ban, I can insert whatever network I like via packetcrafting and give you headaches for days. Imagine that for a moment - blocking I don't know say... 0.0.0.0 or better yet, if someone has an axe to grind with you and is capable (not difficult) of tracking down your address ranges. They could do some really cruddy stuff like have your own servers/netblocks block themselves out, have your servers block out your default route and the list goes on and on.
Absolutely. Use of such a tool has to be with the realization that the tool can be used against you, and that you need to really know your network, and how your firewall works.
Multiple that by all of your netblocks, clients' static netblocks, etc. It would be a horrible thing to maintain.
I disagree. A single file with a mix of netblocks, static and dynamic DNS, and customer IP addresses that allows for inline comments can be used in multiple applications. For the most part, most of your production IP services are already firewalled with an explicit whitelist. When you need production IP services available to the world (HTTP, SIP if you are handling NAT'ed customer devices), a tool that supports whitelisting and dynamically blocks for Z seconds non-whitelisted IPs and hosts that fail to authenticate (or do something) X times in Y seconds is valuable. The shell script examples you posted are bad for production, because they block on the first failed attempt, and have no method for unblocking. The tools being discussed (sshguard, fail2ban, others) block hosts for Z seconds only after X failures in Y seconds. This is useful to proactively protect the availability of your services in the following instances: * This means a tinkerer who screws up their Asterisk config and blasts you with 150 registration requests a minute would get blocked for 15 minutes before being able to try again, forcing the customer to maybe realize something isn't right, and for you to optionally be notified of the block, and maybe call the person proactively to help, AND proactively protecting your SIP registration server from being DOS'ed by a newbie. * Drive-by brute force. 150 failed auths in 1 minute indicate an attempted brute force attack. * Packetcrafting usefulness is diminished by your whitelist. While packetcrafting could be used to temporarily disconnect one of your non-whitelisted customers, at least you'd know about the block and could make an informed decision to either whitelist the client temporarily or permanently. Sometimes it will have a previously unthought of bad result on your services, which you then consider and fix. It may not be perfect, but neither is getting brute forced and having thousands of dollars of calls made on your dime, or having your customers offline because of one bad tinkerer DOSing your services at 2am while you sleep. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------