- Previous message: Justin Shore: "Re: Customer-facing ACLs"
- Maybe in reply to: Justin Shore: "Customer-facing ACLs"
- Next in thread: Adrian Chadd: "Re: Customer-facing ACLs"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
|
|
|
From: Andy Dills (no email)
Date: Fri Mar 07 2008 - 21:54:29 EST
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 ---
|
|
|