SMB Port Alternatives for Remote Access

SMB (Server Message Block) was known originally as Common Internet File System (CIFS). The SMB protocol supports mapping drives over legacy port 139 for NetBIOS or port 445 over TCP. SMB is a file sharing protocol that enables mapped drive access using built-in native tools on Windows PC’s such as “Net Use”.

Over time the SMB Protocol has been updated to improve security (SMB1/CIFS), reduce chattiness (SMB2) and improve performance (SMB3).

cloud storage gateway

SMB Security Concerns

Typically, Internet service providers block SMB Ports to prevent issues with security and malware by preventing remote mapped drive direct access over SMB Port 445. SMB Requires port 445 to be open, which is prone to malware including the likes of infamous offenders like Wannacry, Sasser, Nimda, Petya/NotPetya, and more. If SMB Ports are open, an infected computer will search its Windows network for Server shares accepting traffic on TCP ports 135-139 or 445 indicating the system is configured to run SMB. It’s a constant worry and reoccurring nightmare to think about having ports 137-139 and/or port 445 open to the internet waiting for the next exploit – which is why they are always blocked.

The SMB protocol has no built-in options to prevent files from being encrypted or renamed, alerting, or detecting ransomware attacks. This means ransomware such as WannaCry can spread automatically without victim participation.

SMB Port Remote Access

To facilitate remote access mapped drives, businesses have often granted access to SMB ports over a VPN tunnel. This provides some level of security, however in addition to SMB Port 445 other ports are needed to allow remote PC’s to authenticate and resolve server names and shares internally. This increases the attack surface for potential Malware and Ransomware and adds an additional support burden on IT Staff who need to maintain and support remote mapped drives for users. While MAC Address filtering can be used to limit SMB Port access, this further adds to the complexity of managing file share remote access and associated support costs.

SMB/QUIC

Available soon? We have been following SMB/QUIC protocol with quite a bit of interest, and as partner with the Microsoft Azure File Shares teams we have known about it for a while now. Initially it’s only available in Azure based Windows 2022 VM’s. Our thinking is part of the reason is most firewall/security vendors don’t yet support routing QUIC protocol and aren’t yet comfortable routing it since they can’t inspect the network traffic inside of the https UDP packets, can’t restrict access using firewall policies, and are unable to implement logging and reporting. SMB over QUIC could be useful in the short term for internal LAN based networks such as Azure File Shares traffic since it would be in a controlled network environment and it may speed up and secure internal SMB file share access. From what we are seeing, even if firewall vendors and ISP’s come on board, not too many enterprises are keen to allow mapping of their internal network shares directly over the internet without any front-end security, file type blocking, size restrictions, or traffic inspection and reporting capabilities.

SMB protocol has been around since 1983, with new exploits being found year after year for decades. Enterprises will rightfully remain cautious when allowing direct access to any internal resource from external networks over the SMB/QUIC protocol.

In the meantime, MyWorkDrive already converts Windows based SMB/CIFS file shares into secure file shares that can be accessed anywhere using TCP https/SSL port 443 over highly encrypted RSA 4096 and TLS 1.2 FIPS compliant protocols that are available and supported today.

MyWorkDrive will support SMB either way, and will continue to support our Web Brower based access, Windows Mapped Drive and Mobile clients as the SMB protocol evolves.

Daniel, Founder of MyWorkDrive.com, has worked in various technology management roles serving enterprises, government and education in the San Francisco bay area since 1992. Daniel writes about information technology, security and strategy.