72,819 internet-reachable Samba servers: the file-sharing layer that never got an inventory
Opening
Samba implements the SMB protocol for Unix and Linux systems, providing file and print sharing that Windows clients can reach. It is the interoperability layer between Linux file servers and Windows desktops, and in many organisations it is the primary mechanism by which documents move between teams.
A ZoomEye fingerprint query for the Samba application signature returns 72,819 services reachable from the public internet, collected on 24 September 2026 (UTC).
Earlier collection in the same series recorded 110 NFS results and 1,771 SMB results under different query forms, which is a useful reminder that the number depends on the query. This measurement uses an application fingerprint for a specific implementation, so it counts deployments whose responses match that signature.
Context and method
| Query | exact_count | What the query measures |
|---|---|---|
app="Samba" |
72,819 | Services matching the ZoomEye application fingerprint for Samba |
port="2049" |
1,870,478 | Any reachable service on 2049, the standard NFS port |
Both figures collected on 24 September 2026 (UTC) through the ZoomEye query interface. The Samba figure is an application fingerprint. The NFS figure is a port-level count, which measures reachability of a service on that port without asserting what implementation is behind it.
Analysis and walkthrough
Why file sharing is the hardest layer to close
A management console can be placed behind a VPN because the people who use it are administrators, and administrators can be given one more step. A file share cannot, usually, because the people who use it are everyone.
The structure of file sharing explains why SMB and NFS exposure persists. The share is the collaboration mechanism. It serves desktops in offices, laptops on home connections, partners exchanging documents, and line-of-business applications that read and write files as their method of integration. Restricting it to a controlled network means restructuring how work happens, and that is a project rather than a firewall change.
What SMB exposes at the protocol level
Server Message Block negotiates dialects, handles authentication through NTLM or Kerberos, supports signing, and brokers access to named shares with per-share permissions. The historical record is that most of the significant attacks against it target the negotiation and authentication path, and earlier dialects had authentication designs that modern configurations reject.
Version and dialect configuration of each server matters as much as reachability. A Samba deployment on a current release with signing required, SMB1 disabled and only modern dialects negotiated presents a very different surface from one preserving SMB1 for a legacy device.
The 72,819 figure and the network architecture it implies
A service answering an SMB fingerprint from the public internet is reachable from outside the organisation's control. In most corporate environments, SMB traffic between Windows clients and a Linux file server stays inside a private network. Reachability from the public internet implies one of a few arrangements: a file server placed in a DMZ, a routing or firewall rule that permits the port from a wide source range, a hosting environment where the private network is a shared tenancy, or a deployment in a colocation that was assumed to be closed.
The last category is the one worth checking. A file server in a hosting provider is often built with the assumption that its address range is not scanned, and the assumption is not a control.
Why this layer gets excluded from scanning programmes
A vulnerability scan of a file server returns a long list of findings about dialects, signing configuration and anonymous access. In an estate where the shares are load-bearing, most of those findings cannot be fixed without breaking access, and a remediation programme that produces only unfixable findings tends to drop the whole category.
The practical alternative is to separate the findings into those that require a configuration change on the server, which the server team can make, and those that require restructuring access, which is a project. Reachability from the internet is in the first group and it is the finding with the largest effect per unit of effort.
Implications
Where ZoomEye fits
File sharing is the layer where an organisation's own inventory is least likely to be complete, because shares are created informally and named inconsistently. ZoomEye lets a team run the same fingerprint query an outside observer would use and compare the results against what it believes exists. The public interface is at https://www.zoomeye.ai.
Practical steps
- Establish whether any SMB or NFS service is reachable from outside the organisation's controlled networks. Treat a positive result as a routing error until proven intentional.
- Confirm SMB1 is disabled and signing is required on every server, including file servers that serve only legacy clients.
- Check anonymous and guest access configuration on every share, which is the most common finding after reachability.
- Inventory share permissions against the identities that can reach them. A reachable share with broad permissions is the combination that matters.
- Include file servers in the credential review. Service accounts used for share access are frequently long-lived and excluded from rotation.
- Remember that the two queries measure different things. A port count for NFS and a fingerprint count for Samba cannot be compared directly, and neither is a vulnerability count.
References
- ZoomEye query interface:
app="Samba"andport="2049", collected 24 September 2026 (UTC) - ZoomEye: https://www.zoomeye.ai
- Samba project documentation: https://www.samba.org/samba/docs/
Top comments (0)