Proving Plain FTP Is Actually Gone

The last flow converted weeks ago. The old service is switched off. Everyone involved would like to declare victory and reclaim their calendars — and this is precisely the moment retirements go soft. "We turned it off" and "we can show it is off, everywhere, and would know if it came back" are different claims, and only the second one closes audit findings, satisfies questionnaires, and survives the discovery of a forgotten quarterly job three months from now.

This is the closing article of our Retiring Plain FTP series, and it covers the finish line properly: shutting down in an order that preserves your rollback and your evidence, running the final verification sweep, watching for reappearance with a tripwire that tells you about stragglers before they become outages, assembling the evidence pack that closes the loop with compliance and leadership, and installing the small permanent habits that keep FTP from quietly returning. None of it is difficult. All of it is the difference between a retirement and a rumor of one.

What "Gone" Actually Means

Define the claim before proving it. Plain FTP is gone from your organization when four statements are true and evidenced:

1. Nothing on your networks listens for plain FTP. No service answers unencrypted FTP on any address you operate — with the exception of relay hosts inside documented containment segments, which listen only on their isolated interfaces.
2. Nothing you run dials out over plain FTP. No script, scheduled job, application, or device initiates cleartext FTP to anyone — internal or external — except contained devices talking to their local relay.
3. Every exception is documented and fenced. Each surviving cleartext hop lives inside an isolation segment with a signed, unexpired risk-acceptance memo, per the containment article.
4. Reappearance would be detected. Controls exist — and have been tested — that surface a new listener, a straggler job, or a helpful colleague re-enabling FTP "temporarily."

The fourth condition is the one organizations skip, and it is what separates gone from merely invisible. FTP has a habit of resurrecting: an old server restored from backup, a vendor appliance reset to defaults, a new hire solving a problem the old way. Without detection, each of those quietly reopens the exposure your program just spent months closing.

Shut Down in the Right Order

How you turn the service off determines what evidence and rollback you keep. The order that works:

1. Disable accounts first, service second. By cutover's end, individual accounts were disabled as flows converted. Disabling the protocol itself is then an anticlimax — which is the goal. On a multi-protocol server this is a configuration change, not a decommissioning: in Sysax Multi Server, switch off the plain-FTP protocol while FTPS, SFTP, and HTTPS keep serving the same folders and accounts. The machine stays; the cleartext door closes.
2. Disable, don't uninstall — at first. Keep the FTP service present but off through a settling period of a few normal business cycles, including a month-end or quarter-end if your flows follow finance rhythms. If a forgotten flow surfaces, re-enabling one account for a week (a decision for the program sponsor, not a reflex) is a controlled response; reinstalling from scratch under outage pressure is not.
3. Archive the configuration and logs before removal. The server's final configuration and its transfer logs are evidence: they show what existed, who connected, and when each account went quiet. Export both into the evidence pack before anything is deleted. When the settling period passes without surprises, remove or permanently disable the service and take the final configuration snapshot.
4. Replace firewall allows with deny-and-log. Do not merely delete the port 21 rules — replace them with explicit deny rules that log hits. A deleted rule forgets; a deny rule that logs becomes your reappearance tripwire, covered below.

One naming decision is worth making consciously rather than by default: keep the hostname. If partners and scripts connected to transfer.example.com for years, that name now points at the encrypted services on the same host, and leaving it in place is free continuity. Deleting or repointing a long-lived transfer hostname buys nothing and creates a fresh round of partner confusion just as the program is trying to end quietly.

The Final Verification Sweep

Now generate the proof. The method is the same three-direction sweep from the discovery article — run one last time, with outputs saved and dated, expecting emptiness. This symmetry is the tidy part of the program: the procedure that opened it also closes it.

# 1. Listener scan of every subnet you operate (expected: no hits
#    outside documented containment segments)
nmap -p 21 --open -sV 10.10.0.0/16 192.168.0.0/24 -oA proof-ftp-final

# 2. Inside view on every former FTP server (expected: nothing on 21)
Get-NetTCPConnection -LocalPort 21 -State Listen   # Windows
ss -ltnp | grep -w :21                             # Linux

# 3. Scheduled-task and script sweep (expected: zero live references)
schtasks /query /fo LIST /v | findstr /i "ftp"
grep -rn --include="*.sh" -e "ftp://" /opt /usr/local /home

# 4. Firewall: list every rule referencing port 21 (expected: only
#    the deny-and-log rules, plus contained-segment internals)

# 5. Tripwire self-test: from a test machine, attempt an outbound
#    FTP connection — expected: blocked, logged, and alerted on

Three notes on reading the results. First, scan port 21 for the retirement claim — a listener on port 990 is implicit FTPS, which is encrypted and not part of what you retired; note such listeners as context, not findings. Be precise in your records about the difference, because "FTP-ish thing on a scan" and "cleartext FTP" are exactly the distinction this program exists to manage. Second, expect the contained segments to appear in their designated places, and record that they appear only there — the exceptions ledger says two relay hosts, the scan shows two relay hosts, and the match itself is evidence the fences hold. Third, treat any other hit as a finding, not a failure: a straggler found by your own final sweep is the program working. Convert or remove it, then re-run the sweep so the archived output is clean.

Step 5 deserves emphasis because it tests the detector rather than the estate: you deliberately attempt what a straggler would do, and confirm the block, the log entry, and the alert all fire. A tripwire that has never been tripped on purpose is a hope, not a control.

Wire-Level Confirmation

Scans prove nothing is listening and configuration proves nothing should dial out; a packet capture — recording actual traffic and checking it for readable USER and PASS lines — proves what is really crossing the wire, and catches the case the other checks structurally miss: two machines exchanging cleartext FTP inside a single network segment, invisible to boundary firewalls. One capture session on your busiest segments and at the network edge, run during a normal business day and archived with the evidence, settles the question with the strongest evidence type available. The full method — where to capture, what to look for, how to keep it repeatable — is in our companion article on finding cleartext on your network; run it as written and file the result.

The Verification Checklist

This is the closing checklist. Every line is either checked with evidence attached, or the retirement is not done. Copy it into the project tracker and work it top to bottom:

FTP RETIREMENT — FINAL VERIFICATION CHECKLIST

Estate is clean
[ ] Port-21 listener scan of all subnets: no hits outside
    documented containment segments (output archived, dated)
[ ] Per-server listener check on every former FTP host: clean
[ ] Scheduled-task/script sweep on automation hosts: no live
    plain-FTP jobs or ftp:// references
[ ] Device inventory: every FTP-capable device converted,
    contained, or decommissioned
[ ] Partner tracker: all partners Verified or under signed,
    unexpired exception

Shutdown is real
[ ] Plain-FTP protocol disabled on all multi-protocol servers;
    FTPS/SFTP/HTTPS confirmed still serving
[ ] Former FTP-only services disabled; removal scheduled/complete
[ ] Final server configurations and transfer logs archived

Detection is live
[ ] Firewall: port-21 allows removed; deny-and-log rules in place
    at boundaries and between internal zones where feasible
[ ] Alert on deny-rule hits configured — and TESTED with a
    deliberate connection attempt (evidence: the alert itself)
[ ] Periodic re-scan scheduled and on the calendar
[ ] Packet-capture spot check performed and archived

Paper trail is closed
[ ] Exceptions ledger current: memo, owner, review date per device
[ ] Evidence pack assembled and stored with the security records
[ ] Risk register / audit findings updated and closure requested
[ ] Questionnaire and insurance answer language updated
[ ] Business case closed out to the sponsor with evidence attached

The Deny-and-Alert Tripwire

The deny-and-log rules installed at shutdown are the program's permanent sensor, and they will fire eventually — which is their value, not their failure. When a hit appears, the triage is short. Identify the source from the log: machine, then owner, the same resolution work as discovery. Classify it: a straggler (a long-cycle job the sweeps missed — the annual report script is the classic) gets converted with the standard playbook, gently, since its owner just found out the hard way; a revival (someone re-enabled or newly installed FTP to solve a problem) gets converted too, plus a conversation about the change-control gate; an outsider (internet scanning against your closed port) gets ignored, which is why boundary deny hits from unknown external sources are normal noise while internal sources are always worth a name. Record each internal hit and its resolution in the exceptions ledger's log — a quiet tripwire plus a handled-stragglers list is exactly the story an auditor wants to read.

Firewalls cannot see everything, though. Two machines on the same segment can still speak FTP to each other without crossing any rule, which is why the tripwire is paired with the scheduled re-scan: the firewall watches the paths between zones continuously, and the scan sweeps the spaces inside zones periodically. Together they cover what neither covers alone.

Keeping It Gone

Entropy reintroduces FTP the same way it accumulated in the first place: one convenient decision at a time. Four small standing habits hold the line, none requiring a project:

• The change-control gate. "No new plain-FTP flows" is written policy, and any exception requires the same risk-acceptance memo as a legacy device — same signature level, same expiry. Making the exception path formal but real prevents both quiet workarounds and quiet approvals.
• The procurement line. Equipment that transfers files must support SFTP, FTPS, or HTTPS. One sentence in the purchase checklist retires the next decade's containment segments before they exist.
• The build baseline. Server templates and images ship with FTP services absent or disabled, so restored backups and new builds default to the retired state rather than the historical one. This closes the restore-from-backup resurrection path, which is the most common one.
• The calendar entries. The periodic port scan, the exception-memo reviews, and an occasional tripwire self-test each get a recurring slot. Fifteen minutes per cycle is the entire ongoing cost of staying retired.
• The runbook. The sweep commands, the tripwire triage steps, and the exceptions ledger live in one documented place, so the re-scan does not depend on the memory of whoever ran the program. Retirements outlive their administrators; the runbook is how the state survives the handover.

While the scan calendar exists anyway, extend it one step: verify the surviving encrypted endpoints stay properly configured too — no anonymous or guest doors quietly enabled on the new services. That neighboring audit has its own series, anonymous and guest access, and it reuses the habits you just built.

Closing the Loop with Compliance and the Business

The final act is administrative, and skipping it wastes the program's best output. Assemble the evidence pack — one folder, stored with your security records: the dated final scan outputs and listener checks, the firewall rule export showing deny-and-log in place, the alert-test evidence, the packet-capture note, the final retirement inventory with every row closed, the exception memos, and the archived server configurations and logs. Then spend it, three ways:

• Close the findings. Send the auditor or assessor who flagged FTP the closure request with evidence attached. A finding closed with proof stays closed; one closed with "we fixed it" gets re-tested next cycle.
• Update the answers. Security questionnaires and the cyber-insurance application now read accurately and favorably: data encrypted in transit, with any exceptions contained, documented, and reviewed. Whoever answers those documents needs to know the language changed — tell them, with the pack's location.
• Close the business case. The program began with a one-page case promising "this exposure ends"; it closes with a one-paragraph memo to the sponsor: exposure removed, evidence archived, standing controls in place, exceptions listed with expiry dates. That memo is what makes the next security program easier to fund — you are now the team whose projects finish.

The Program, Start to Finish

Seen whole, the retirement ran a clean arc: a business case in risk language won the decision; the discovery sweep made the invisible estate visible; the plan sequenced easy wins, parallel runs, and a date that held; partners moved on a drumbeat of notices and test windows; the unupgradeable devices were fenced and signed for; and the sweep that started everything ran once more to prove the ending. What remains is fifteen minutes a quarter and a tripwire that occasionally catches an annual script — which is what "retired" is supposed to feel like: not a memory of a project, but a state you can demonstrate on demand.

Frequently Asked Questions