Disabling Insecure Ports and Protocols
What Are Secure Ports and Protocols?
When insecure ports and protocols are used to exchange sensitive data, you weaken your security posture. Examples of insecure protocols would be HTTP, FTP, or Telnet because they operate in clear text. To properly harden your operating system, these insecure protocols must be replaced with secure alternatives like HTTPS, SFTP, or SSH.
In AWS, you can verify that your infrastructure only allows the use of secure ports and protocols in several ways, including:
- Using AWS Config, set up a managed rule (like restricted-common-ports) that monitors if known, insecure ports are disabled.
- Create a security group rule in a VPC that controls inbound and outbound traffic.
- Amazon Inspector has Network Reachability rules which analyze configurations for network access to your EC2 instances.
One of the fundamentals of hardening our operating systems against attack is to only enable the services, the protocols, and the applications that we actually need. Now, sometimes, the application architect or the system architect has determined that we need a port or a protocol or a service that is, itself, known to be insecure. One of the principal reasons why that might be insecure is because it operates in clear text. HTTP is an example. FTP is an example. Telnet is an example. Anytime that these applications will be used to transfer sensitive information – which could be as basic as a username and a password – then we really need to consider secure alternatives to that. We consider the use of HTTPS instead of HTTP. We just wrap our HTTP session in a TLS tunnel, then we can transfer that data securely. The same thing with FTP – we might replace that with SFTP, which would be an SSH-based implementation of file copy protocols. The same thing goes for Telnet – we would replace that with SSH, as well. It’s important, in our application stacks, to consider the different protocols that are being used and the security impacts of those protocols. If a secure alternative is available, to use it. If a secure alternative is not available, to take additional steps. Maybe, if we had to use FTP, then we would require the use of PGP or GPG encrypted files that we would be transferring back and forth to keep the sensitive information out of unencrypted application sessions. Be sure to revisit your operating systems, to revisit your technology stacks, take a look at the ports, the protocols, and the services and make sure that they are the ones that absolutely must be there and for any insecure ones that are used, consider using secure alternatives instead.