Educause Security Discussion mailing list archives
Re: Windows mystery udp/137 to udp/137
From: "Vanderbilt, Teresa" <tvanderb () OZARKS EDU>
Date: Tue, 29 May 2007 17:51:17 -0500
Thanks!!! It is an upgrade. -----Original Message----- From: Lee Weers [mailto:weersl () CENTRAL EDU] Sent: Tuesday, May 29, 2007 2:16 PM To: SECURITY () LISTSERV EDUCAUSE EDU Subject: Re: [SECURITY] Windows mystery udp/137 to udp/137 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
Current thread:
- Re: Windows mystery udp/137 to udp/137, (continued)
- Re: Windows mystery udp/137 to udp/137 Buz Dale (May 22)
- Re: Windows mystery udp/137 to udp/137 Lovaas,Steven (May 22)
- Re: Windows mystery udp/137 to udp/137 Vanderbilt, Teresa (May 22)
- Re: Windows mystery udp/137 to udp/137 Vanderbilt, Teresa (May 22)
- Re: Windows mystery udp/137 to udp/137 Jeff Kell (May 22)
- Re: Windows mystery udp/137 to udp/137 David Gillett (May 22)
- Re: Windows mystery udp/137 to udp/137 Brady McClenon (May 22)
- Re: Windows mystery udp/137 to udp/137 Vanderbilt, Teresa (May 22)
- Re: Windows mystery udp/137 to udp/137 Fowler, Steve (May 23)
- Re: Windows mystery udp/137 to udp/137 Lee Weers (May 29)
- Re: Windows mystery udp/137 to udp/137 Vanderbilt, Teresa (May 29)
- Re: Windows mystery udp/137 to udp/137 Lee Weers (May 30)
- Re: Windows mystery udp/137 to udp/137 Vanderbilt, Teresa (May 30)