Information Leakage: Banners, Errors, and Listings

Before anyone types a password, your transfer server has already been talking. Connect to it cold, with no credentials at all, and it will typically volunteer a greeting naming the software it runs — often down to the exact version. Guess a username and it may confirm whether that user exists. Poke at a folder and it may explain, in helpful detail, exactly why you cannot have it and where it lives on disk. None of this requires an attacker to be clever; the server offers it to everyone who knocks.

Information leakage is this category of giveaway: details a system reveals to people who have proven nothing about themselves. On a transfer server the classic leaks are three — banners (the pre-login greeting), verbose errors (messages that explain too much), and listable directories (folder contents visible without, or beyond, authorization). This article, part of our Server Hardening series, works through all three: what leaks, how it gets used, and a trimming policy that is honest about its limits — because pretending obscurity is security is its own failure mode.

By the end you will have run the same checks a stranger would run against your server, and you will know which of the results are worth changing and which are theater.

What a Stranger Learns in Ten Seconds

The technique is called banner grabbing: open a plain connection to a service port and read whatever the service says first. No exploit, no credentials — just listening to the introduction. Here is what it looks like against a typical unhardened box, using nc (netcat, a simple make-a-connection tool; on Windows, modern systems ship curl.exe, and the optional telnet client does the same job):

$ nc files.example.com 21
220 AcmeFTPd 3.1.4 ready — Springfield office, upgrade pending

$ nc files.example.com 22
SSH-2.0-ExampleSSH_9.9 Ubuntu-3

$ curl -I https://files.example.com/
HTTP/1.1 200 OK
Server: ExampleHTTPd/2.4.1 (Unix) OpenTLS/1.1.7

Read that the way a stranger would. The FTP greeting names the product, the exact version, the office it serves, and — a gift — the fact that an upgrade is overdue. The SSH identification string names the software build and the OS family. The HTTPS response names the web server and its TLS library, versions included. In three connections and ten seconds, an outsider knows your software inventory more precisely than some of your own documentation does. TLS certificates add more: their subject and issuer fields can reveal internal hostnames and organizational details to anyone who completes a handshake.

How That Information Gets Used

Why does any of this matter? Because the internet is continuously indexed. Automated scanners sweep the entire public address space on a rolling basis, recording exactly these banners, and searchable services organize the results. Your server's greeting is not a private handshake with one visitor — it is a database row available to anyone who queries for it.

The mechanism that turns a banner into a knock on your door is version matching. Software flaws, once discovered, are published in public catalogs of known vulnerabilities so defenders can patch. Attackers read the same catalogs backward: take a newly published flaw in AcmeFTPd 3.1.4, query the indexes for every server announcing that string, and work down the list. A server that broadcasts its version has volunteered for the list; a server that doesn't must be probed individually, which costs attackers time and creates noise your monitoring can see. Version banners also serve targeted attackers, who use them to prepare the right exploit before ever touching you in a detectable way.

The same indexes work for defenders, and you should use them that way. Querying the public scan databases for your own addresses shows you exactly what has been recorded about your servers — sometimes including services you did not know were exposed, or an old banner from before your last cleanup that tells you how long the leak stood. It is the outside-in view of your own estate, for free, and checking it periodically belongs in the verification habit this series ends with.

The defensive conclusions are refreshingly plain. First: assume everything your server announces is public knowledge, because it effectively is. Second: what actually protects you from version matching is not hiding the version — it is not being the vulnerable version, which is a patching outcome, covered in patching without breaking partners. Third: since announcing detail has costs and no benefits, stop announcing it. That ordering — patch first, trim second — is the whole policy in miniature.

The Obscurity Question, Settled Sanely

Any discussion of banners eventually collides with the phrase "security through obscurity" — the criticism aimed at defenses that only work while the attacker stays ignorant. The criticism is correct: a secret version number is not a control. Attackers can fingerprint software by its behavior — response phrasing, feature quirks, protocol details — regardless of what the banner claims, and any defense that evaporates the moment someone learns a fact was never a defense. If trimming banners is your patching strategy, you do not have a patching strategy.

But the correct criticism gets over-applied. Between "obscurity is worthless" and "broadcast everything" lies the sensible position: volunteering precision is free help to the other side. Reducing what you announce does not make you secure; it makes you absent from the cheapest target lists and forces opportunists to spend effort where they expected a gift. Soldiers wear camouflage and armor — nobody argues camouflage is useless because it isn't armor, and nobody wears camouflage instead of armor.

Three rules keep you on the sane side of the line:

• Patch level is the control; the banner is hygiene. Trim banners only on servers you also keep patched. Never let a trimmed banner appear in a risk discussion as a mitigation.
• Reduce, don't impersonate. Replace detail with neutrality — a greeting that says nothing — rather than a fake version string. Lying banners break client workarounds and vendor diagnostics, confuse your own future troubleshooting, and buy nothing that neutrality doesn't.
• Accept the floor. Some announcement is protocol-mandated (more below). Trim what is configurable, accept what isn't, and move on — chasing perfect silence wastes hours that patching would spend better.

Trimming, Protocol by Protocol

What can actually be changed varies by protocol family, and it helps to know the floor before you start.

FTP and FTPS. The greeting — that 220 line — is ordinary configurable text in virtually every server, graphical or config-file based. Set it to something neutral: the service's purpose and an authorized-use notice, no product, no version, no location. FTPS changes nothing here; the greeting is part of the FTP conversation inside the secured channel (or before it, in explicit mode — one more reason it should say little). While you are in the TLS settings, the protocol-level lockdown — versions, ciphers, downgrade paths — is its own discipline, covered in hardening FTPS.

SFTP / SSH. Here is the floor: the SSH protocol requires both sides to open with an identification string of the form SSH-2.0-softwarename, so you cannot be fully silent and still speak SSH. What you can usually do is reduce what follows the required prefix — many servers append OS or distribution detail that can be turned off, and commercial servers vary in how much they expose. Accept the prefix, trim the suffix, and rely on patching for the rest.

HTTPS. The Server response header is configurable or removable in most web-facing software; shorten it to the product family or nothing. Error pages deserve equal attention — default error pages often name the software and version in friendly HTML.

The legal notice — the banner you should add. Trimming is not the same as saying nothing at all. A short authorized-use notice — "This system is for authorized use only; activity is monitored and logged" — is worth displaying at connection or login. It leaks nothing technical, it removes any claim of innocent wandering, and organizational policies (and some jurisdictions' practices) favor having it on record. Keep it to one or two sentences: purpose, authorization, monitoring. A banner is not the place for hostnames, contact emails, or org-chart trivia.

Errors That Say Too Much

Banners leak to everyone; errors leak to anyone who asks questions. Three patterns account for most of the damage:

• Username confirmation. If a wrong username earns "unknown user" but a wrong password earns "incorrect password," the server is an oracle: an attacker can feed it a list of guesses and harvest your real account names — partner names very much included — before trying a single password. Then the password-guessing campaign starts warm. Configure uniform failure responses ("login incorrect") wherever the server allows, and treat enumeration attempts as the early stage of the credential attacks described in our brute-force protection series. Noticeably different response times for valid and invalid usernames leak the same fact sideways; perfect timing uniformity is hard, but avoid settings that make the difference dramatic.
• Path disclosure. Errors like 550 /srv/transfer/partners/acme/inbound: permission denied hand strangers your directory layout — the exact knowledge that makes a later foothold efficient. Well-behaved servers report paths relative to the user's own root (their jail), which is one more argument for the jails in account isolation and jails: inside a jail, there is no revealing path to leak.
• Existence confirmation. If asking for a file you cannot have returns "permission denied" but asking for a nonexistent file returns "not found," an outsider can map which filenames exist without reading any of them. Filenames are data: acme-acquisition-draft.docx confirms a rumor all by itself. Prefer configurations that return the same answer for "not found" and "not yours."

A pleasant side effect of tightening errors: your logs get more interesting. When the server tells strangers nothing, the stranger has to try more probes to learn anything, and every probe is a log line. A server such as Sysax Multi Server records session activity including failed logins, so an enumeration attempt shows up as a tidy, attributable pattern — visitors asking questions they should not be asking — rather than passing unremarked.

Listings That Say Too Much

The third leak is the humble directory listing. Filenames and folder names are metadata that read like a briefing: a listable folder of partner-a/ partner-b/ partner-c/ is your client roster; payroll-export-final.csv announces its own sensitivity; even file sizes and timestamps sketch your business rhythms. The failure arrives three ways:

• Anonymous or guest listing — a login that requires no real credentials and permits browsing. If you did not deliberately build a public download area, no unauthenticated visitor should be able to list anything. (Deliberate public distribution is its own design problem, with its own series on anonymous and guest access.)
• Over-broad authenticated visibility — a valid partner login that can list other partners' folders, even without read access to the files. "They can see the names but not the contents" is still a leak of the names. Jails close this completely: inside a jail there is nothing else to list.
• The forgotten web view — a web server fronting the same data with automatic index pages enabled, cheerfully rendering folder contents to any browser. Transfer directories acquire web front ends over the years; check every path to the same files, not just the transfer protocol's.

The listing policy that falls out of this is one line: nobody lists anything they have not authenticated for, and nobody lists anything beyond their own jail. It costs no functionality that a transfer service legitimately needs, and it converts an entire category of quiet reconnaissance into log entries.

The Self-Check: See What They See

Now make it concrete. From an outside network — a home connection or phone hotspot, so you see what the internet sees — run these against your own server. (The usual note: probing systems you do not own or administer is unauthorized activity in most places; this checklist is for your servers only.)

# LEAKAGE SELF-CHECK — run from outside, against your own server only.

# 1. FTP/FTPS greeting: product? version? location?
nc your-host 21
# 2. SSH identification: what follows the required SSH-2.0- prefix?
nc your-host 22
# 3. Certificate fields (explicit FTPS; use port 990 without
#    -starttls for implicit FTPS; port 443 for HTTPS):
openssl s_client -starttls ftp -connect your-host:21
#    read the subject/issuer lines: internal names? old hostnames?
# 4. HTTPS headers and error page:
curl -I https://your-host/
curl -sS https://your-host/does-not-exist | more
# 5. Username oracle: attempt logins with a real username + wrong
#    password, then a fake username. Are the failure messages
#    (and rough response times) identical?
# 6. Existence oracle: request a real-but-forbidden path, then a
#    nonexistent one. Same answer both times?
# 7. Listing probe: can you list anything before authenticating?
#    Can a test partner account list anyone else's folder names?

# Record the outputs beside your baseline document.
# Re-run after every upgrade — updates love to restore default banners.

Windows note: curl.exe ships with current Windows; for the raw banner grabs, the optional telnet client, nc from common admin toolkits, or a PuTTY "raw" connection all work. The point is not the tool — it is that you read your server's introduction the way a stranger does, and then decide each line on purpose.

A Sane Leakage Policy on One Screen

Keeping It Trimmed

Leakage settings have a habit of regenerating: upgrades restore default greetings, migrations recreate default error pages, a new web front end arrives with indexing on. The fix is to make the self-check above a recurring event rather than a one-time cleanup — it takes ten minutes from the outside and belongs in the same calendar slot as your other re-checks, described in verifying your hardening actually holds. Between checks, the leakage lines in your baseline document record what the greeting, headers, and error behavior are supposed to be, so any drift is a diff, not a debate.

Seen from a distance, this whole article is one idea: your server should require strangers to earn every fact they learn about it. Patching decides whether knowledge helps them; trimming decides how much knowledge they get for free; logging decides whether you notice them collecting it. All three together are simply good manners toward your future self.

Frequently Asked Questions