Data Flow – Windows UNC Access to Share Ports (SMB)

When you try to use UNC (Universal Naming Convention) to access a share on a different server, multiple components come into play, including name resolution services like DNS and the SMB protocol for file sharing. Let’s say Server A is internal, and Server B is in the DMZ (Demilitarized Zone). Here’s a simplified data flow diagram along with the ports involved:

1. DNS Query:
Server A (Internal) [UDP 53] ---> DNS Server
DNS Server [UDP 53] ---> Server A (Internal)
Purpose: Resolve the IP address of Server B.

2. SMB Negotiation:
Server A (Internal) [TCP 445] ---> Server B (DMZ)
Purpose: Start SMB negotiation and establish SMB session.

3. SMB Session and File Copy:
Server A (Internal) [TCP 445] <--> Server B (DMZ)
Purpose: Copy files to the share on Server B.

Main Points

1. DNS Query: The internal server (Server A) queries a DNS server to resolve the server’s hostname in the DMZ (Server B). This typically uses UDP port 53.

2. SMB Negotiation: Server A initiates an SMB session with Server B over TCP port 445. They’ll negotiate capabilities, security features, and more.

3. SMB Session and File Copy: Server A and Server B use the same established SMB session (TCP port 445) to facilitate the file copy.

Firewall Considerations

Allow outbound TCP 445 from the Internal Network to DMZ for Server A to reach Server B.
Allow inbound TCP 445 on Server B in the DMZ.
Ensure DNS traffic is allowed if your DNS server is not on the same network as Server A.

Security Considerations

1. Both servers should be updated with the latest security patches.
2. Use strong authentication methods.
3. Ideally, the traffic should be encrypted. SMB 3.x supports encryption.
4. Strictly limit which internal addresses are allowed to connect through the firewall to the DMZ, ideally only Server A in this scenario.
5. Consider using a VPN or IPSec for additional layers of security if necessary.

Remember that this is a simplified explanation. Additional steps like authentication, encryption, and logging would also be involved in real-world scenarios.

Why do I see TCP/139?

TCP port 139 is associated with NetBIOS over TCP/IP, which is an older protocol that was commonly used for Windows file sharing before the widespread adoption of SMB over TCP/IP on port 445. In modern Windows environments, port 445 is generally the primary port used for SMB traffic. However, port 139 might still be used for compatibility with older systems or applications that rely on NetBIOS over TCP/IP.

If you are observing traffic on port 139, it’s possible that:

  1. Legacy Support: Older software or services running on the server might still be using NetBIOS over TCP/IP, requiring port 139.
  2. Fallback Mechanism: Some systems are configured to try the newer SMB over port 445 first, and if that’s not available, they will fall back to using port 139.
  3. Client Behavior: Some Windows clients may attempt connections on both ports when trying to establish a share, even if port 445 is available and operational.
  4. Mixed Environments: If you’re operating in a mixed environment with older Windows versions or software, you might see port 139 in use.

Is it needed?

The necessity of having port 139 open depends on your specific use case:

  • Modern Systems: If you’re working exclusively with modern systems and applications, you can generally disable NetBIOS and only use port 445 for SMB traffic.
  • Legacy Systems: If older systems or applications are in the mix, you may need to keep port 139 open for compatibility.
  • Network Policies: Some organizations have policies that dictate which ports must be used for certain types of traffic. Check with your network and security teams for guidance.

If you’re not sure whether you need port 139, you can monitor your network traffic to see if the port is actively being used. If it’s not, and if you’re sure you don’t have legacy systems that require it, you might consider disabling it to reduce the attack surface of your network.

Always remember to consider the security implications and thoroughly test any changes in a lab environment before rolling them out in a production network.