Traffic on port 137,138,139 question

UncleCid

Before I saying anything, thanks you guys for all the help and "goto" advice I've gotten from these forums. Esspecially, dynamik... I swear he's like the first person to respond to every post.

Anyway, I have a domain controller setup that I have blocked ports except those necessary for login and such. 53 (tcp/udp), 135(tcp), 445(tcp/udp), 3268(tcp), 88(tcp/udp), 389(tcp/udp), 123(udp), 1026(tcp) I know that 389(tcp) and 123(udp) are not needed for login, but just encase I use another DC and so NTP can be used. Everything is gravy. Until I start logging dropped packets and monitoring the network traffic.

It appears that I substanial amount of traffic on ports 137,138,139, as logged in dropped packets. I know that these are netbios ports. I know that they recieve alot of attention from worms and network attacks(as well as 445). I scanned my workstation and found nothing. I'm also receiving a high amount of traffic on 445,when packet sniffing, but my books are telling me that I need this port.

These packets are coming during either no activity, activity, or even logged off(DC and/or Workstation). I was curious if anyone could help me to figure out the exact cause to this traffic. ty.

astorrs

I was going to reply, but figured someone else had already written up a good explanation and sure enough the good folks at petri.co.il had. This should clear up any confusion.

When does Windows 2000/XP/2003 uses port 445, and when it uses 139?

From now on I will refer to the "client" as the computer from where you map drives and other shared resources, and to the "server" as the computer with resources that are shared. I will also refer to NetBIOS over TCP/IP only as NetBT.

If the client has NetBT enabled, it will always try to connect to the server at both port 139 and 445 simultaneously. If there is a response from port 445, it sends a RST to port 139, and continues it's SMB session to port 445 only. If there is no response from port 445, it will continue it's SMB session to port 139 only, if it gets a response from there. If there is no response from either of the ports, the session will fail completely.

If the client has NetBT disabled, it will always try to connect to the server at port 445 only. If the server answers on port 445, the session will be established and continue on that port. If it doesn't answer, the session will fail completely. This is the case if the server for example runs Windows NT 4.0.

If the server has NetBT enabled, it listens on UDP ports 137, 138, and on TCP ports 139, 445. If it has NetBT disabled, it listens on TCP port 445 only.

Source: What's Port 445 in W2K/XP/2003? - SMB Over TCP

Now I have to ask, why do you need to protect all these ports? Are you trying to secure it from other machines on your internal network, or are you putting this machine on the Internet? (the latter of course is a bad idea)

UncleCid

I am blocking all ports, but the ones mentioned to just harden security. I'm using the philosophy that if I don't need it I'm closing that port. This DC is able to access the the internet but is separated by a router/(basic firewall) that has stateful packet inspection. I am using the DC for private network organization and configuration.

From readin your post.. Your quote is saying that if any of the workstations on my domain have Netbios over Tcp/Ip enabled, they will relentlessly try to connect to these ports on a domain controller? I am not using my DC with any unrelated active directory fileshares. Unless the sysvol and netlogon file shares are causing the workstations to do these constant session attempts?

astorrs

UncleCid wrote: »

Unless the sysvol and netlogon file shares are causing the workstations to do these constant session attempts?

Yes those would cause it. As would attempts to access to the IPC$ share.

You can either disable it (discussed in the source article I linked to) on each client manually or via DHCP. Or you can also just safely ignore it, since you are providing access via 445, and assuming that all clients are Windows 2000 or later, you will not have any problems.

UncleCid

Thanks astorrs. XD You know when I was trying to identify port 1026 (tcp), I got almost no information. I ended up finding this somewhat abscure sight that said it was for Active Directory Replication @ logon. Wierd that that wasn't anywhere in my 299 text book. Is that a new service tacked on since the publish of that book? thank you again astorrs. XD

astorrs

UncleCid wrote: »

Thanks astorrs. XD You know when I was trying to identify port 1026 (tcp), I got almost no information. I ended up finding this somewhat abscure sight that said it was for Active Directory Replication @ logon. Wierd that that wasn't anywhere in my 299 text book. Is that a new service tacked on since the publish of that book? thank you again astorrs. XD

Yes it's used for the Active Directory logon and directory replication interface. Actually it could be 1025 or 1026 or any other port >1024 (unless you fix it in the registry).

Since you're firewalling off this computer I would fix the port so it doesn't change down the road and you end up troubleshooting some arcane logon problem. Here's how:

To map the port in the registry:

1. Start Registry Editor (Regedt32.exe).
2. Locate the following key in the registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
3. On the Edit menu, click Add Value, and then add the following registry value: Value Name: TCP/IP Port
   Data Type: REG_DWORD
   Radix: Decimal
   Value: greater than 1024
4. Quit Registry Editor.

Make sure that the slash in "TCP/IP" is a forward slash, and that the value that you assign is greater than 1024, in decimal format. That number is the extra port that you have to open (TCP, UDP) on the firewall. Setting this registry value on every domain controller inside the firewall does not affect performance, and covers any logon request redirects that occur because of servers that are down, roles that change, or bandwidth requirements.

UncleCid

Awesome, and will do, sir. Thanks a bunch. XD