Re: Windows mystery udp/137 to udp/137

[David Gillett <gillettdavid () FHDA EDU>]

  169.254.x.x addresses are "self-assigned"; they're used by
clients configured for DHCP who have, alas, not been able to
receive an assigned address.

  So first of all, you shouldn't let *any* traffic leave your
network looking for those destinations.  If they exist at all,
they're internal, and probably unreachable for all practical
purposes.

  Windows servers tend to like to exchange 137/udp packets with
every client.  Again, probably not something you want to allow
to leak out (or in).

  In this case, I think you have a few clients who, having failed
to get DHCP addresses, are nevertheless trying to access server
resources that they already know about.  If there are a *lot* of
these, you may be having a problem with your DHCP servers or with
delivery of broadcast traffic.

David Gillett
CISSP CCNP etc


> -----Original Message-----
> From: Clyde Hoadley [mailto:hoadleyc () mscd edu]
> Sent: Tuesday, May 22, 2007 6:02 AM
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Subject: [SECURITY] Windows mystery udp/137 to udp/137
>
> We have several Windows servers that regularly attempt to
> send udp packets from port 137 to non existent IP address udp
> port 137.  These get blocked by the firewall.  The Sys Admins
> haven't been able to figure out why they do it.  Has anyone
> encountered this problem before?
>
> Deny udp src inside:10.10.18.64/137 dst
> outside:169.254.221.242/137 Deny udp src
> inside:10.10.18.64/137 dst outside:169.254.221.242/137 Deny
> udp src inside:10.10.18.64/137 dst outside:192.168.81.1/137
> Deny udp src inside:10.10.18.64/137 dst outside:192.168.81.1/137
>
> --
> Clyde Hoadley
> Director of Information Security
> Information Technology
> Metropolitan State College of Denver
> Campus Box 96, P.O. Box 173362, Denver Co 80217-3362
> 303-556-5074 | CELL 720-232-4737
> www.mscd.edu