North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Customer-facing ACLs

  • From: Andy Dills
  • Date: Fri Mar 07 21:57:08 2008

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 Dills
Xecunet, Inc.