I am learning a legacy system where the security team only opened TCP port 139 between web servers and a file server (both Windows 2008 R2) for file access. I have usually used TCP port 445 for such access. Why would the recommend using port 139 only? Are there benefits from using Port 139 over port 445 or vise versa?
Why would file services only be setup for TCP 139
netbiosserver-message-blockwindows-server-2008-r2
Related Solutions
I have seen a similar phenomen.
Symptoms sound not too similar at first sight: Windows Explorer sometimes hangs for a few seconds regardless whether a local disk or a network share is accessed.
But after some investigation I believe the hang is caused by a similar NetBIOS issue.
Some system details:
- Windows XP Pro SP3
- VMware Server 1.0.9 installed
- VMNet1 (host-only) network adapter and NetBOIS over TCP/IP enabled
- VMNet8 (NAT) network adapter and NetBOIS over TCP/IP enabled
- The system's only physical network adapter's static IP address is 192.168.10.111. This adapter is configured to use 192.168.10.192 as its only WINS server. MAC address: 00-16-17-FA-2C-D4
- On the VMNet1 adapter the system's static IP address is 192.168.137.1. No WINS server configured. MAC address: 00-50-56-C0-00-01
- On the VMNet8 adapter the system's static address is 192.168.145.1. No WINS server configured. MAC address: 00-50-56-C0-00-08
- All VMs are configured to use NAT but are stopped anyway.
I was running Wireshark all day sniffing packets on the physical adapter. I noticed that whenever Explorer hung for a few seconds simultaneously a NetBIOS Name Service query packet was sent to the WINS server. These packets contained one of the VMNet adapter's address as its source IP address!
Here's one of the suspicious packets:
Frame 25475 (92 bytes on wire, 92 bytes captured)
Ethernet II, Src: 00:16:17:fa:2c:d4 (00:16:17:fa:2c:d4), Dst: 00:15:c5:87:4f:6a (00:15:c5:87:4f:6a)
Internet Protocol, Src: 192.168.145.1 (192.168.145.1), Dst: 192.168.10.192 (192.168.10.192)
User Datagram Protocol, Src Port: netbios-ns (137), Dst Port: netbios-ns (137)
NetBIOS Name Service
Transaction ID: 0x82a5
Flags: 0x0000 (Name query)
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
*<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>: type NBSTAT, class IN
I think this is not correct. The packet's source IP address should be set to 192.168.10.111 instead.
I haven't sniffed packets on the WINS server's interface. But I expect it to send a reply to 192.168.145.1 via its default gateway since it is not connected to the 192.168.145.0 network. The gateway should reject this packet with "network unreachable".
As this is a UDP packet there's no connection in SYN_SENT state. But a TCP SYN packet that is "corrupted" in the same way should leave the connection in SYN_SENT state until a timeout occurs.
Some things I tried to work around this problem:
- Disable both the VMNet adapters: Problem solved. No suspicious packets.
- Re-enable VMnet1: Explorer starts again hanging sometimes. Suspicious packets with source 192.168.137.1.
- Disable VMNet1 and re-enable VMNet8: Explorer hangs sometimes. Suspicious packets with source 192.168.145.1.
- Enable both the VMNet adapters, but disable NetBIOS over TCP/IP for both: Problem solved. No suspicious packets.
- Re-enable NetBIOS over TCP/IP for VMNet1: Explorer starts again hanging sometimes. Suspicious packets with source 192.168.137.1.
- Disable NetBIOS over TCP/IP for VMNet1 and re-enable it for VMNet8: Explorer hangs sometimes. Suspicious packets with source 192.168.145.1.
- Change interface metrics from automatic metric to static values for all interfaces. The LAN adapter having the lowest metric: Explorer still hangs sometimes and suspicious packtes captured.
I have checked adapter ordering in Network Connections->Advanced->Advanced Settings as well as by running netsh interface ip show config. Local Area Connection is the first connection listed in both places.
Additionally I noticed some NTP packets with source IP address 192.168.137.1 as well as 192.168.145.1 being sent to 192.168.10.192 (it's an AD DC) via the physical adapter.
Your memory of ports 137 and 139 relate to NetBIOS over TCP/IP. SMB directly over TCP uses port 445.
Allowing TCP port 445 from a Windows XP client to a Samba or Windows Server computer will permit the client to "map" a "drive" to SMB shares exported by the server computer so long as you use the IP address of the server computer in such a request. Just to be sure, I verified with Windows XP Professional 32-bit SP3 against Windows Server 2003 R2 SP2 and Samba 3.0.33 running on CentOS 5.5, through a packet filter that allowed only TCP port 445 traffic from the client to the server. I was able to "map" "drives" and access files on the remote machines.
Best Answer
This is explained in Q204279.
In short: earlier Windows versions (pre Windows 2000) used "NetBIOS over TCP/IP" (with 137/udp, 137/tcp, 138/udp and 139/tcp) to offer the SMB protocol. Newer versions can skip the NetBIOS part and can communicate directly with other hosts via 445/tcp and NetBIOS can be disabled.
Oh, and as to why anyone would use one or the other: 139/tcp would be used if older Windows clients are in use that don't know about direct SMB. But in general 445/tcp would be preferable, as it's easier to configure just one port as 4 different port/protocol configurations in e.g. a firewall.