Re: Windows mystery udp/137 to udp/137

[Lee Weers <weersl () CENTRAL EDU>]

Was your problem server upgraded from Windows 2000, and the 2650 was a
new install of Windows 2003?  If it was upgraded you may need to apply
the default Security template for a Windows 2003 server. 

-----Original Message-----
From: Vanderbilt, Teresa [mailto:tvanderb () OZARKS EDU] 
Sent: Tuesday, May 22, 2007 9:53 AM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Windows mystery udp/137 to udp/137

The dual network cards aren't the issue for us, but I could look at the
driver. Just so we're all talking apples and apples, my server is Dell
P/E 1500SC, dual processor, Intel Pro/1000XT with Microsoft 6.3.6.31
driver, Windows 2003 server, domain controller. My other domain
controller is a Dell P/E 2650 with a teamed Broadcom NetXtreme Gigabit
network cards and a Broadcom driver. WE ARE NOT SEEING THE SAME STRANGE
TRAFFIC FOR IT. If there are any similarities in my problem server and
yours, please let me know.


Thanks,
Teresa

-----Original Message-----
From: Lovaas,Steven [mailto:Steven.Lovaas () COLOSTATE EDU]
Sent: Tuesday, May 22, 2007 9:12 AM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Windows mystery udp/137 to udp/137

Given that the destination is an Automatic Private IP address (the
LinkLocal 169.254 range), I'd look for reasons that either a leftover
service or a secondary interface might have decided it didn't have a
real IP and grabbed an automatic one. In my previous job, we found that
servers with two NICs were working OK on the primary interface, but the
secondary interface (which didn't even have a cable plugged in) was
grabbing a 169.254 address. Since these servers were domain controllers,
you can imagine the grief THAT caused until we figured it out.

It may be that at some point, these booted up without full network
connectivity, grabbed an auto IP address, and shared old-style Windows
networking (WINS or even browse list) with another computer in the same
boat... If that's the case, you could disable or manually address the
secondary interface.

Steve


==============================================
Steven Lovaas, MSIA, CISSP
Network Security Manager
Academic Computing & Network Services
Colorado State University
970-297-3707
Steven.Lovaas () ColoState EDU
============================================
-----Original Message-----
From: Buz Dale [mailto:buz.dale () USG EDU]
Sent: Tuesday, May 22, 2007 7:28 AM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Windows mystery udp/137 to udp/137

I don't know about the 192.168 address but the 169.254 address looks a
lot like an autonet address for a Windows box that doesn't know who he
is.
Luck,
Buz

On 5/22/07, Clyde Hoadley <hoadleyc () mscd edu> wrote:
> 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


--
Buz Dale                                buz.dale () usg edu
IT Security Specialist              1-888-875-3697 (In GA)
1-706-583-2005
Office of Information and Instructional Technology University System of
Georgia GMT -5:00