Back to scan results
Check 43 of 45

Anonymous FTP + Cleartext Authentication

We follow up on exposed FTP, Telnet, SMTP, POP3, and IMAP ports to distinguish a reachable socket from a confirmed anonymous login or authentication flow that is available before transport encryption.

What this check probes

The check reuses the earlier open-port result and performs a bounded protocol conversation only for relevant services on TCP 21, 23, 25, 110, 143, and 587:

  • FTP: reads the greeting, requests FEAT, and makes one anonymous login attempt using anonymous and the scanner identity pciscan43@pciscan.org. A successful login fails. The scanner never requests a directory listing or opens a data connection.
  • Telnet: sends an empty line and inspects the returned negotiation or login prompt. A public login/password prompt confirms a cleartext authentication path.
  • POP3: requests CAPA and submits one uniquely randomized, nonexistent username. It never submits a password.
  • IMAP: requests CAPABILITY and checks STARTTLS, LOGINDISABLED, and pre-TLS authentication mechanisms. It never sends LOGIN or a password.
  • SMTP: sends EHLO pciscan.org and checks whether STARTTLS and pre-TLS AUTH PLAIN/AUTH LOGIN are advertised. It never issues AUTH, addresses a message, or sends mail.

A confirmed anonymous FTP login or confirmed authentication flow without a TLS upgrade fails. Optional encryption, pre-TLS credential advertisement, Telnet exposure without a visible prompt, or an incomplete protocol response produces a warning. A service that explicitly requires TLS before authentication passes this check, although its public exposure may still require business-need review under the open-port check.

No real username, password, mailbox, message, recipient, file, directory command, or customer data is used.

Why this matters for PCI DSS

Passwords sent before encryption can be read or modified by anyone able to observe the network path. Anonymous FTP can expose files and server structure, and writable anonymous storage can become a malware or web-shell delivery point even when the payment application itself is not directly involved.

For PCI readiness, insecure protocols should be removed or protected with strong cryptography and compensating controls where a documented business need remains. Public authentication services should require encryption before accepting credentials, use least privilege and strong authentication, and be restricted by firewall or VPN wherever possible.

How to fix it

Close every service that is not required. Remove the server role or daemon and block its port at both the host and perimeter firewall. Do not rely on a login banner as the access control.

For IIS FTP, disable anonymous authentication and require SSL on both the control and data channels:

<system.ftpServer>
  <security>
    <authentication>
      <anonymousAuthentication enabled="false" />
      <basicAuthentication enabled="true" />
    </authentication>
    <ssl controlChannelPolicy="SslRequire"
         dataChannelPolicy="SslRequire" />
  </security>
</system.ftpServer>

Bind a valid server certificate in IIS Manager and restrict FTP authorization rules to the specific users and directories required. Prefer SFTP over SSH when clients support it; SFTP is a different protocol and is not enabled by configuring FTP over TLS.

For vsftpd, disable anonymous access and force TLS for local-user authentication and data transfers:

anonymous_enable=NO
local_enable=YES
ssl_enable=YES
force_local_logins_ssl=YES
force_local_data_ssl=YES
rsa_cert_file=/etc/letsencrypt/live/example.com/fullchain.pem
rsa_private_key_file=/etc/letsencrypt/live/example.com/privkey.pem

Remove Telnet and use SSH with key-based authentication, MFA where available, and source-IP restrictions. Do not expose SSH broadly merely because its transport is encrypted.

For Dovecot POP3/IMAP, require TLS and disable plaintext authentication before encryption:

ssl = required
disable_plaintext_auth = yes

Prefer IMAPS on 993 and POP3S on 995, or strictly enforce STARTTLS before authentication on ports 143 and 110.

For Postfix submission, require TLS and allow SMTP authentication only after encryption:

smtpd_tls_security_level = encrypt
smtpd_tls_auth_only = yes

Apply those controls to the submission service on port 587. Internet-facing SMTP on port 25 has different mail-delivery requirements, but it should still offer current STARTTLS and must not expose user authentication mechanisms before encryption.

Fixed it? Re-run the scan to confirm.

Run scan again