Anonymous FTP Enabled: How to Disable Anonymous and Cleartext FTP Logins

Anonymous FTP Enabled means your FTP server lets anyone log in as “anonymous” or “ftp” with no real password; its companion finding means real usernames and passwords cross the network unencrypted. Fix both by disabling anonymous login (anonymous_enable=NO in vsftpd, no <Anonymous> block in ProFTPD, Anonymous Authentication off in IIS) and requiring FTPS or moving to SFTP.

What the scanner is actually detecting

These two findings usually arrive together on the same port 21 listener, so it makes sense to fix them in one change window.

Note what 34324 does and does not mean. A server that offers AUTH TLS but still accepts a plain login is flagged. Tenable’s own solution asks you to configure the server “so that control connections are encrypted”, which means FTPS has to be required, not just available.

How serious is it, honestly

An anonymous, read-only FTP site that serves public files by design is low risk in itself. The problems come from drift and from write access:

• Content drift. Over the years, backups, configuration exports and database dumps end up in the FTP root because it was a convenient place to put them. Anyone who can reach the port can list and download them.
• Anonymous upload. A writable directory lets outsiders store and distribute files through your server. If the same directory is also served by a web server, an uploaded file may become reachable over HTTP.
• Cleartext credentials. Anyone who can see the traffic (same segment, a compromised host, a mirrored switch port) can read the password. That is why the rating is Low: the attacker needs that position first. The impact grows because FTP accounts are often real system accounts. vsftpd’s local_enable uses local Unix users, and IIS FTP Basic authentication uses Windows accounts, domain accounts included, so a sniffed FTP password may also work for SSH or RDP.

Printers, NAS boxes, cameras and PLCs often ship with FTP turned on. Before you run authenticated FTP checks against that kind of equipment, read our notes on scanning fragile OT and embedded devices.

How to confirm it on the host

From the network

# Does the server accept an anonymous login? (look for "Anonymous FTP login allowed")
nmap -p 21 --script ftp-anon ftp.example.com

# Does it offer explicit TLS at all?
openssl s_client -connect ftp.example.com:21 -starttls ftp

# Does it accept a real login without TLS? (curl prompts for the password)
curl -v --user alice ftp://ftp.example.com/

If the last command lists the directory, the server accepted your password in cleartext, and 34324 is a true positive.

On Linux (vsftpd or ProFTPD)

ss -tlnp | grep ':21 '
grep -E '^(anonymous_enable|ssl_enable|force_local_logins_ssl|force_local_data_ssl)' /etc/vsftpd.conf /etc/vsftpd/vsftpd.conf 2>/dev/null
grep -rn '<Anonymous' /etc/proftpd/

In upstream vsftpd, anonymous_enable defaults to YES, so a missing line means anonymous logins are on. vsftpd treats both the “ftp” and “anonymous” usernames as anonymous.

On Windows (IIS FTP)

Get-NetTCPConnection -LocalPort 21 -State Listen
%windir%system32inetsrvappcmd.exe list config -section:system.applicationHost/sites

Look for anonymousAuthentication enabled=”true” and for the ssl element’s controlChannelPolicy under each FTP site, and also under siteDefaults.

How to fix it

vsftpd

Edit /etc/vsftpd.conf (Debian and Ubuntu) or /etc/vsftpd/vsftpd.conf (RHEL family). Use no spaces around the equals sign:

anonymous_enable=NO
local_enable=YES
ssl_enable=YES
rsa_cert_file=/etc/ssl/certs/ftp.example.com.pem
rsa_private_key_file=/etc/ssl/private/ftp.example.com.key
force_local_logins_ssl=YES
force_local_data_ssl=YES
ssl_sslv2=NO
ssl_sslv3=NO

force_local_logins_ssl and force_local_data_ssl default to YES, but they only take effect once ssl_enable=YES is set. Write them out anyway so the intent is visible to the next admin. Then run systemctl restart vsftpd.

ProFTPD

Remove or comment out the whole <Anonymous …> to </Anonymous> section, including any copy in an included file. To require TLS, add this to the server config (on Debian it usually lives in /etc/proftpd/tls.conf):

<IfModule mod_tls.c>
  TLSEngine on
  TLSRSACertificateFile /etc/ssl/certs/ftp.example.com.pem
  TLSRSACertificateKeyFile /etc/ssl/private/ftp.example.com.key
  TLSProtocol TLSv1.2 TLSv1.3
  TLSRequired on
</IfModule>

TLSRequired on enforces TLS on both the control and data channels. TLSRequired auth+data is the documented alternative when clients need CCC to get through a firewall. If mod_tls is built as a loadable module on your system, make sure its LoadModule line is active. Check the syntax with proftpd -t, then run systemctl restart proftpd.

IIS FTP (Windows Server)

In IIS Manager, select the FTP site, open FTP Authentication, select Anonymous Authentication and click Disable. Then open FTP SSL Settings, choose a certificate, set SSL Policy to Require SSL connections and click Apply. The same change from an elevated prompt:

cd %windir%system32inetsrv
appcmd.exe set config -section:system.applicationHost/sites /[name='FTP Site'].ftpServer.security.authentication.anonymousAuthentication.enabled:"False" /commit:apphost
appcmd.exe set config -section:system.applicationHost/sites /[name='FTP Site'].ftpServer.security.authentication.basicAuthentication.enabled:"True" /commit:apphost
appcmd.exe set config -section:system.applicationHost/sites /[name='FTP Site'].ftpServer.security.ssl.serverCertHash:"<certificate thumbprint>" /commit:apphost
appcmd.exe set config -section:system.applicationHost/sites /[name='FTP Site'].ftpServer.security.ssl.controlChannelPolicy:"SslRequire" /commit:apphost
appcmd.exe set config -section:system.applicationHost/sites /[name='FTP Site'].ftpServer.security.ssl.dataChannelPolicy:"SslRequire" /commit:apphost

Replace FTP Site with your site name, and get the thumbprint from Get-ChildItem Cert:LocalMachineMy. To change the server-wide default, use the /siteDefaults.ftpServer… path instead of /[name=’…’]. Settings made on a site override the defaults, so check both. Restart the service with Restart-Service ftpsvc so that existing sessions drop.

Replacing FTP with SFTP

If users only need authenticated file transfer, SFTP over OpenSSH removes FTP altogether. A typical chrooted, SFTP-only group in /etc/ssh/sshd_config:

Match Group sftponly
    ChrootDirectory /srv/sftp/%u
    ForceCommand internal-sftp
    DisableForwarding yes

sshd requires every component of the ChrootDirectory path to be owned by root and not writable by group or others. Once clients have moved, stop and disable the FTP service.

If anonymous access has to stay

For a genuine public download site, keep it read-only. In vsftpd, leave write_enable, anon_upload_enable and anon_mkdir_write_enable at NO, and point anon_root at a dedicated directory. In ProFTPD, put a <Limit WRITE> DenyAll block inside the <Anonymous> section. In IIS, grant anonymous users Read permission only. Audit the directory on a schedule, run that service on a host with no local user logins, and record the finding as an accepted risk rather than leaving it open.

Verify the fix and rescan

# Anonymous login must now fail
curl -v --user anonymous:guest@example.com ftp://ftp.example.com/

# A plain login must be refused before the password is accepted
curl -v --user alice ftp://ftp.example.com/

# The same login over explicit TLS must work
curl -v --ssl-reqd --user alice ftp://ftp.example.com/

nmap -p 21 --script ftp-anon ftp.example.com

Both refusals should come back as a 5xx reply (vsftpd and IIS word it differently). Then rescan with the same policy and credentials that produced the original finding. If the host is in a cardholder data environment, keep the before and after results as evidence for your PCI DSS Requirement 11.3 scanning records.

What can break and how to roll back

• Anonymous consumers. Scan-to-FTP printers, firmware update jobs and old download links may rely on anonymous access. Check the FTP logs for anonymous sessions before the change.
• Clients without TLS. The built-in Windows ftp.exe command-line client has no TLS support, and many legacy scripts use it. Move those jobs to a client that supports FTPS or SFTP.
• Firewalls and NAT. With FTPS the control channel is encrypted, so firewall FTP helpers can no longer read the PASV replies and open data ports for you. Set a fixed passive range (pasv_min_port and pasv_max_port in vsftpd, FTP Firewall Support in IIS) and open it explicitly.
• TLS session reuse. vsftpd requires SSL session reuse on data connections by default (require_ssl_reuse=YES). The vsftpd manual warns that this can break many FTP clients. Try a current client before you set it to NO.

To roll back on Linux, copy the file before you edit it (cp -p /etc/vsftpd.conf /etc/vsftpd.conf.bak), then restore the copy and restart the service. On IIS, run appcmd.exe add backup pre-ftp-hardening first. The backup includes FTP configuration, and appcmd.exe restore backup pre-ftp-hardening reverts it. The restore stops IIS services while it runs.

Common false positive reasons

• Offered is not required. A server that supports AUTH TLS but still accepts a plain login is a true positive for 34324.
• A second listener. Implicit FTPS on port 990 does not help if port 21 is still open with plain FTP. The same applies to a second vsftpd instance started with its own config file.
• Service not restarted. The scanner saw the old running configuration.
• Site overrides in IIS. Anonymous access was turned off in siteDefaults, but the site’s own setting still enables it.
• Anonymous left on a TLS-enforced server. Anonymous logins can still be cleartext, and some scanners may keep reporting cleartext authentication until anonymous access is disabled too.
• Wrong asset. The port belongs to an appliance or a NAT rule in front of another box, not the server you changed.

FAQ

Is enabling FTPS enough to close Nessus 34324?

Only if encryption is required for the login. vsftpd needs force_local_logins_ssl=YES, ProFTPD needs TLSRequired, and IIS needs its control channel policy set to SslRequire or SslRequireCredentialsOnly.

Are SFTP and FTPS the same thing?

No. SFTP is a subsystem of SSH and normally runs on port 22. FTPS is ordinary FTP wrapped in TLS on ports 21 or 990. Either one clears the cleartext finding.

Why does the finding reappear after reimaging?

The base image or configuration management template still carries the old FTP settings. Fix it there, not only on the host.

Can I accept the anonymous FTP finding instead?

For a deliberate public mirror, yes. Keep it read-only, check what is in it, and document the exception with an owner and a review date.

Tracking this finding across many hosts

FTP findings tend to surface on many servers and devices at once, under different IDs in Nessus and OpenVAS. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners and merges duplicates within each scanner, not across them, so each tool’s report stays a separate entry. Nessus findings such as plugin 10079 can be re-tested one at a time after the change. AI-drafted, host-specific fix scripts run through its Windows and Linux agents only after a person approves them.

Sources

• Tenable: Anonymous FTP Enabled (plugin 10079)
• Tenable: FTP Supports Cleartext Authentication (plugin 34324)
• vsftpd.conf manual (official vsftpd site)
• Microsoft Learn: FTP Anonymous Authentication <anonymousAuthentication>
• Microsoft Learn: Default FTP over SSL Settings <ssl>