On Fri, 7 Mar 2008, Dave Pooser wrote:
Might as well do TCP 20, 21 and 23, too. Woah, that slope's getting slippery!
Do bots try brute force attacks on Telnet and FTP? All I see at my firewall are SSH attacks and spam. But sure, if there's a lot of Telnet abuse block 23 too; I think it's used about as rarely by "normal" customers as SSH is.
And I'm amazed how often "slippery slope" arguments are deployed to oppose any sort of change at all. What percentage of consumer broadband users do you think use SSH to connect to remote servers? 1%? 0.1%? 0.01%? It seems intuitively obvious that the number of people who will call the help desk to unblock their SSH (which should be a ~2 minute call anyway, if not a self-service Web page with captcha) would be an order of magnitude less than the number of remote network users who WON'T be calling/emailing your abuse desk to complain about bots on your network hammering their servers.
Just straight up blocking outbound ports (with the debatable exception of port 25) seems heavy handed and too slanted toward admin convenience over customer satisfaction. It's a slippery slope because unlike with spam, people who are affected by brute force attacks have some degree of complicity through either negligance or laziness. Once you decide it's your job to protect other people's networks from their own stupidity, you may as well do full blown deep packet inspection and look for customers who are using your network to download kiddie porn...step by step you get closer to losing safe harbor, or at least having to pay a lawyer to convince otherwise. Perhaps a more thoughtful solution would work, but would take a bit of engineering. Ideally you would only block a certain class of brute-forceable ports once you cross some threshold amount of brief TCP sessions in a given period. I would suspect an extremely low false positive rate of blocking the ports of a user who has had, say 100 brief telnet, ssh, ftp, pop, or imap sessions in 5 minutes. Perhaps instead of filtering just those ports, you instead do a captive portal where they forced to a webapp which presents them with the logs of their issues and the suggestion they may be compromised, along with locally reachable resources to assist in correcting the issue. But just in case, if they feel it was an accidental situation (a perl script gone mad, say), they could merely click a button to open them right back up. However, three strikes and you're out until an admin reviews the case and considers the feedback ("we run a cyber cafe, sometimes people come in with messed up laptops") and implements a whitelisting. Remember, YOUR customers are what matter. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 ---