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
---
|
