Customer-facing ACLs

Sat Mar 8 05:40:52 UTC 2008

Frank Bulk wrote:
> The last few spam incidents I measured an outflow of about 2 messages per
> second.  Does anyone know how aggressive Telnet and SSH scanning is?  Even
> if it was greater, it's my guess there are many more hosts spewing spam than
> there are running abusive telnet and SSH scans.  

Judging by the hits on my firewall there's a fair amount of variation
between the scanners that are doing a couple login attempts per hour, 
and the bot that's making thousands of login attempts with 4 or 5 
connection attempts going at a time. We don't filter them  till they hit 
a threshold.

I don't even bother to log telnet attempts anymore so I can't say much 
about that.

> Frank
> 
> -----Original Message-----
> From: owner-nanog at merit.edu [mailto:owner-nanog at merit.edu] On Behalf Of Mark
> Foster
> Sent: Friday, March 07, 2008 10:02 PM
> To: Dave Pooser
> Cc: nanog at merit.edu
> Subject: Re: Customer-facing ACLs
> 
> 
>> Blocking port 25 outbound for dynamic users until they specifically
> request
>> it be unblocked seems to me to meet the "no undue burden" test; so would
>> port 22 and 23. Beyond that, I'd probably be hesitant until I either
> started
>> getting a significant number of abuse reports about a certain flavor of
>> traffic that I had reason to believe was used by only a tiny minority of
> my
>> own users.
>>
> 
> Sorry, I must've missed something.
> Port 25 outbound (excepting ISP SMTP server) seems entirely logical to me.
> 
> Port 22 outbound? And 23?  Telnet and SSH _outbound_ cause that much of a
> concern? I can only assume it's to stop clients exploited boxen being used
> to anonymise further telnet/ssh attempts - but have to admit this
> discussion is the first i've heard of it being done 'en masse'.
> 
> It'd frustrate me if I jacked into a friends Internet in order to do some
> legitimate SSH based server administration, I imagine...
> 
> Is this not 'reaching' or is there a genuine benefit in blocking these
> ports as well?
> 
> Mark.
> 
> 
> 
> 