[80817] in North American Network Operators' Group
Re: Blocking port udp/tcp 1433/1434
daemon@ATHENA.MIT.EDU (Jeff Kell)
Thu May 12 16:27:07 2005
Date: Thu, 12 May 2005 16:26:55 -0400
From: Jeff Kell <jeff-kell@utc.edu>
To: Valdis.Kletnieks@vt.edu
Cc: John Kristoff <jtk@northwestern.edu>, nanog@merit.edu
In-Reply-To: <200505122003.j4CK2wPS026678@turing-police.cc.vt.edu>
Errors-To: owner-nanog@merit.edu
Valdis.Kletnieks@vt.edu wrote:
> On Thu, 12 May 2005 12:23:19 CDT, John Kristoff said:
>>I think there always has been some justification. Here is a very
>>small sample of real traffic that I can assure is not Slammer traffic,
>>but it is being filtered nonetheless (IP addresses removed):
>>
>> May 12 09:15:30.598 CDT[...] denied udp removed(53) -> removed(1434), 1 packet
>> May 12 09:26:30.210 CDT[...] denied tcp removed(80) -> removed(1434), 1 packet
>> May 12 09:32:23.122 CDT[...] denied tcp removed(80) -> removed(1434), 1 packet
>> May 12 09:42:38.558 CDT[...] denied udp removed(123) -> removed(123), 1 packet
>> May 12 10:12:50.422 CDT[...] denied udp removed(53) -> removed(1434), 1 packet
>
> Looks like a good justification to *NOT* filter. Somebody nuked the reply
> packets for 2 DNS lookups and 2 hits to web pages just because the user's
> machine picked 1434 as the ephemeral port. Oh, and one machine that
> got slapped across the face for having the temerity to ask what time it was. ;)
For TCP, you can filter it statefully, don't allow connections inbound
to 1433/1434, 135-139, etc.
For UDP, you could risk allowing source 53/123/etc either "period",
or "to >1023"
or "to 1434"
depending on the your taste, or just tolerate the collateral damage.
(And yes, there's always the wise-arse using nmap -g53 or -g123 etc)
Jeff
