Audit Your Security Groups for Insecure Ports and Protocols
Identify Insecure Ports and Protocols in Inbound Rules
Using insecure ports and protocols makes it possible for your traffic to be sent unencrypted over the Internet. In this demo, we will walk through how to audit your security groups for insecure ports and protocols like FTP, Telnet, and SNMP. Security groups, after all, act as a firewall in your AWS environment, and their inbound rules will show you areas of vulnerability in terms of insecure ports and protocols.
- From the AWS Management Console, navigate to the EC2 Dashboard, then the Security Groups section.
- Choose a security group to analyze, then select the Inbound Rules tab.
- What ports and protocols do you see? Any that are known to be insecure? If so, they need to be modified.
For a visual guide on how to audit your security groups for insecure ports and protocols, watch the full demo. To learn more about the details of security group rules, read here.
Hello everyone! Thanks for joining today. In this demo, we’re going to talk about not using insecure ports and protocols. We’re going to start off with the “why.” When we talk about insecure ports and protocols in this vein, we’re going to be talking about protocols that are inherently unencrypted. So, things like FTP, Telnet, and SNMP. Why is it important that you’re only using an encrypted channel? If you’re sending information over the Internet in an unencrypted manner, it exposes that traffic to the potential of being intercepted by an attacker and being used for unintended uses. How do we protect ourselves against this? What you’re going to make sure you’re doing is, in your environment, only sending traffic over the Internet that is in an encrypted manner. So, for example, instead of FTP you’re going to use something like SFTP. Instead of Telnet, you’re going to you SSH. Using those encrypted channels is going to be important. When you’re looking at your environment, you can look at your security groups in AWS to identify if you’re using any type of insecure port or protocol.
What we’re going to do right now is walk through the steps to identify if you’re using any insecure ports or protocols. When you log into your AWS Management Console, you’re going to be presented with the management screen. We’re going to go to the EC2 Console. The reason that we’re going to the EC2 Console is this is where security groups live. As we know, security groups act as a firewall within an AWS environment. We’re going to go look at the security groups here. For this particular demo, we already have a demo environment set up that has some insecure ports. There’s a couple different security groups listed here, but we’re going to look at this specific one. When you’re presented with this screen, we’re looking at the inbound rules. The inbound rules, in this particular case, are going to show us the type of connection that’s being made, the protocol that’s being used, the port range, the source address, and for this demo, I also put in a description.
As you can see here, we have some culprits that are widely seen as insecure ports and protocols. We have port 21, which is a classic FTP. If you’re sending files via FTP, they’re going in an unencrypted manner so that exposes them to being intercepted. Then we have 161 which is SNMP. SNMP by nature is not going to be encrypted. That’s going to send unencrypted traffic over the Internet which has the potential to be intercepted. Then we also have Telnet. Telnet is usually used as an administrative protocol. If you’re using Telnet, you’re basically making administrative actions on your systems that are unencrypted, so that traffic could be intercepted. If you send a password or something over Telnet, that password could be intercepted by a nefarious user and used to exploit your systems.
It’s really important that you’re auditing your security groups and making sure that you’re not using these insecure protocols. If you are, they need to be discontinued of their use. Thanks for joining and have a great day!