SMB file services often sit between Windows clients, Linux systems, backup products, and line-of-business appliances. A Samba fingerprint can identify candidate servers, but signing is a negotiated property of each connection. A product match without a negotiation test cannot show whether a specific share rejects an unsigned client.
The observed query
This measurement used the Samba application fingerprint:
app="Samba"
The query used sub_type=all, page 1, and pagesize=1. At 20:40:14 UTC on 28 October 2026, ZoomEye returned 74,610 matching records. The count describes matching observations at that time, not verified file shares, credential exposure, or servers without signing.
Samba is used in many deployment forms, and the same organization may expose different services on different networks. The next step is to tie an owned match to a file-service owner and to the clients that depend on it.
Make signing a per-path property
Microsoft's documentation explains that SMB signing prevents tampering and relay attacks and that recent Windows releases require it by default in different directions depending on the edition and role. Windows Server 2025, for example, requires outbound signing by default. A client-to-server matrix is therefore more useful than a single setting named in a policy document.
For each owned Samba server, record the supported dialect, signing configuration, authentication mode, guest policy, share list, and the client populations that mount it. Confirm whether the server requires signing or merely supports it. Then check the client side. Two endpoints can both support signing while a legacy configuration still permits an unsigned path.
Test a denial and a success
Use a controlled test share and non-production accounts. Attempt an unsigned connection to a server configured to require signing and confirm that it is rejected. Connect with the intended client and verify that the negotiated connection is signed. Record the client, server, dialect, authentication method, and outcome.
Check the relevant event logs on both sides. A successful login is not enough evidence. The verification should show the negotiation and the component that enforced the requirement. Repeat after a Samba upgrade or a change to a Windows policy.
Use discovery to find exceptions
Owned ZoomEye matches that do not appear in the file-service inventory deserve an ownership investigation. They may be temporary test servers, embedded storage, or systems managed by a different team. A match that maps to a known backup appliance can be reviewed with its vendor's signing guidance rather than assumed to follow Samba's defaults.
Monitor for new public SMB endpoints, changes in certificate or authentication configuration, and reappearance of legacy protocols. Do not disable signing on a production network merely to make a scan or an old appliance pass. Isolate the exception and set a remediation owner.
Record a defensible conclusion
Store the query, scope, observed count, and time. Compare the owned subset with the client-server matrix and the results of the controlled negotiation. The final result should say which paths require signing and which exceptions remain.
ZoomEye provides the external candidate set. Samba and Windows configuration provide the actual signing state. Combining them gives a security team a concrete inventory and a way to prove enforcement across mixed environments.