Port reference
Port 990 (TCP) – FTPS (implicit TLS)
FTP over implicit TLS — the control channel is wrapped in TLS from connect, unlike explicit FTPS (AUTH TLS) on port 21.
Default state
Open on FTP servers configured for implicit FTPS. Often internet-facing for file exchange with partners.
Common attacks
- Credential brute force and reuse of leaked logins
- Weak/legacy TLS (SSLv3/TLS 1.0), bad ciphers and certificates
- Data-channel exposure and firewall/NAT mishandling of FTP passive ports
- Anonymous access and over-permissive file/directory permissions
Hardening
- Require TLS 1.2+ with strong ciphers and a valid certificate
- Disable anonymous login; enforce strong, unique credentials and MFA where possible
- Restrict and firewall the passive data-port range explicitly
- Prefer SFTP (SSH, port 22) for new deployments where feasible
- Lock down file permissions; log and rate-limit auth attempts
nmap snippet
nmap -p990 --script ssl-enum-ciphers,ssl-cert <target>Replace <target> with the host or range you're authorized to scan.
What runs on port 990?
Port 990 is the registered TCP port for implicit FTPS — FTP wrapped in TLS from the moment the connection opens. This differs from explicit FTPS on port 21, where a normal FTP session is upgraded with the AUTH TLS command. Both protect the classic File Transfer Protocol; implicit FTPS on 990 is the older approach where the client expects TLS immediately and negotiates passive data channels over TLS as well.
Why it matters for security
FTPS fixes plain FTP's biggest flaw — credentials and data sent in cleartext on port 21 — by encrypting the control and data channels. But the encryption only helps if the TLS configuration is strong; legacy protocol versions, weak ciphers, or invalid certificates undermine it. FTPS also inherits FTP's clunky separate data channel, which complicates firewalls and can leak transfers if misconfigured.
How it's attacked
Attackers run credential brute force and replay leaked logins, especially where anonymous access or weak passwords are allowed. They downgrade or exploit weak/legacy TLS (SSLv3, TLS 1.0, bad ciphers) to undermine confidentiality. Misconfigured passive data-port ranges and NAT handling can expose transfers or be abused, and over-permissive permissions leak files.
Hardening checklist
Require TLS 1.2+ with strong ciphers and a valid certificate, and disable anonymous login. Enforce strong, unique credentials and MFA where possible, and explicitly restrict and firewall the passive data-port range. Lock down file permissions, log and rate-limit auth attempts, and prefer SFTP (port 22) for new deployments. The nmap scripts above enumerate the TLS configuration and certificate on hosts you are authorized to test.
Related ports
Frequently asked questions
- What is the difference between port 990 and port 21 FTPS?
- Port 990 is implicit FTPS — TLS is negotiated immediately on connect. Port 21 uses explicit FTPS (AUTH TLS), upgrading a plaintext FTP session. Both protect FTP, but implicit is the legacy approach on 990.
- Is FTPS on 990 secure?
- TLS protects credentials and data in transit, but FTPS still inherits FTP's awkward data channels and weak-password risks. Enforce TLS 1.2+, disable anonymous access, and consider SFTP instead.