One benefit of security group rules: they’re explicit. You must explicitly grant access or it will automatically drop the traffic. To properly configure your access to ports for security groups, you must be able to identify unrestricted access. In this demo, we will analyze the inbound rules for security groups and AWS expert Mike Wise will teach you how to identify and modify ingress from 0.0.0.0/0 or ::/0 to common ports including: 

For a visual guide on how to identify unrestricted access to ports for security groups, watch the full demo.

Hello everyone! Today, we’re going to talk about security groups and restrictions on ingress ports. One of the common tenets of information security is the idea of least access and having a strong perimeter for your network. As we all know, security groups serve as a firewall within AWS, especially when we’re talking about service like EC2. What we’re going to do today is talk about some common ports, IPv4 and IPv6, how they interact with security groups, and how we can audit as well as fix identified areas where we have unrestricted access to a specific port. 

When you first log into AWS, you’re going to be presented with the screen that you see right now. This is your main AWS Management Console. You’re going to click on “EC2” on the left, then you’re going to scroll down to “Security Groups.” When you click on “Security Groups,” this will show you all of the security groups that you have. It also gives you some other important information like the owner of the security group, a description of what the security group is for, what VPC it’s attached to, and obviously the name and security group ID. For this specific demo, we’re going to click on this “demo-unrestricted-access” security group. We’re going to go through some common ports that are out there and in use. We’re also going to be talking about IPv4 versus IPv6 in the context of security groups, and how you can identify unrestricted access. 

Let’s go and look at this security group. We’re going to look at the inbound rules, so we’ll click on “Edit Inbound Rules.” We’re given a couple of pieces of information that are going to be important in our discussion. Let’s start with the type. Within security groups, you can specify different types of connections as well as custom TCP or UDP connection. You’re also given the protocol type, port range, source, and a description of the rule that’s there. An important piece here that we’re going to identify is the source. When we talk about unrestricted access, what we’re really saying is that anyone on the Internet can access this report if it’s unrestricted. In this case, this 0.0.0.0/0 CIDR means that anyone on the Internet via IPv4 can access this port. In this specific case, we’re going to talk about port 1433, which is commonly used for MSSQL. If you see this, this means that anyone on the Internet can hit your SQL port. If you’ve ever looked at logs, sometimes on a specific server or things like that, you will see a lot of people doing what they call port scanning. Port scanning is when someone runs a script that will allow them to knock on a range of IPs and see if the port is open. What they’re looking for is exploitable ports that they can attack to try to gain access to information. For this specific rule, this will allow anyone to know your MSSQL port – which is a bad thing, because if you’re using MSSQL as a data store, you really don’t want attackers to be able to hit that port. At minimum, you want to restrict access. How are we going to do that? We’re going to delete this 0.0.0.0/0 and put a new CIDR in. We’re going to restrict it down to specific IPs: 4.2.2.1/32. That’s going to restrict access down to this port. It’s really important to note that you can create different CIDRs and different ranges of IPs that can have access. Based on your specific needs, you can put whatever IP range that you want to have access to that port in this box. That will allow you to restrict access down to a specific CIDR range. 

We’re going to continue on and go through some other common ports that are in use. 27018 is a common port for MongoDB. Something important I want to point out here is this CIDR range here, ::/0. Inside of security groups you can use security group rules for both IPv6 and IPv4. When you see a nomenclature like this, this means that you’re going to have all access from IPv6. You really do need to think about what you’re granting access to. A good thing about security group rules is that they’re explicit. You have to explicitly allow access and, by default, unless you have a rule that says allow-all for everything (which we never want to do), it will automatically drop the traffic. So, unless you’re specifically allowing it or there’s a rule specifically allowing all, you’re going to drop that traffic. In this case, we created a rule that’s going to allow all access on IPv6 to MongoDB. We’re going to want to take that rule out and put a specific range in to allow access from MongoDB. 

Continuing on with common ports that you want to look out for in your security group rules to ensure they have restricted access – we have 5432, which is commonly used for PostgresSql. We have 7199, which is a Cassandra port. We have 2843, which is Oracle. We have 11211, which is Memcached. We have 3389, which is rdp. We have 1521, which is Oracle. We have 8888, which is Cassandra. We have 22, which is ssh. We have 6379, which is Redis. We have 27017, which is MongoDB. We have 9160, which is another Cassandra. We have 3306, which is MySQL. As you can see, these are common services that are out there that a lot of organizations are using. You really want to take time and pay attention to your security group rules when you’re auditing them to make sure that these specific ports don’t have unrestricted access. Thanks for viewing this demo and have a great day!