Skip to main content
Sumo Logic

Lab 11 - Tighten up your Security Group exposure by detecting "Permit Any" on any of your EC2 Ingress

Has this ever happened? A new person starts and creates a Security Group (SG) but they made a mistake, like opening up access to a specific SG. The good news is you can detect it and clean it up. 

To provide a little background, your Virtual Private Cloud (VPC) has 2 protective layers for data security. One is the Network Access Control Lists (NACLs), and the second is your Security Group rules. They act as a secondary virtual firewall allowing or denying  traffic for any of your AWS EC2 instances. As your data ingress from your VPC and flows to an EC2 Instance it must pass through the NACL and then through each EC2 instance's Security Group.

Screen Shot 2020-05-20 at 8.41.07 AM.png

Lab Activity

Detect "permit any"

  1. The best practice here is to block by default and then allow specific traffic, so we should eliminate ports that we detect having "Permit Any". Fortunately, in AWS the default setting on the security groups applied to EC2 instances deny inbound traffic and allow outbound. It's up to you to configure access rules that specify what types of ingress data traffic you allow.
  2. The below query detects if you have any "permit any" across your ports. Every security group also has permitted ingress and egress limits. As a best practice, limit access to resources by IP range, protocol and port. Avoid “Permit Any“ rules, which might allow unwanted traffic ingress. Click +New Log Search and paste the query into the query builder,  and run it for Today

_sourceCategory=Labs/AWS/CloudTrail
// and authorizesecuritygroupingress
// and authorizesecuritygroupegress
| json "requestParameters", "userIdentity"
| json "errorCode" nodrop
| json field=useridentity "type" nodrop
| json field=useridentity "arn" nodrop
| json field=requestParameters "ipPermissions"
| json field=requestParameters "groupId"
| json field=ipPermissions "items[*].ipRanges.items[*].cidrIp" as cidrIp nodrop
| json field=ipPermissions "items[*].ipv6Ranges.items[*].cidrIpv6" as cidrIpv6 nodrop
| json field=ipPermissions "items[*].fromPort" as fromPort nodrop
| json field=ipPermissions "items[*].toPort" as toPort nodrop
| json field=ipPermissions "items[*].ipProtocol" as ipProtocol nodrop
/* Did anyone create permit any access, -1, or a security group has opened the entire port range (like turning off the firewall), cidrip when you see 0.0.0.0=”any” has a port is any type of protocol*/
//| where (ipProtocol matches "*-1*" or (fromPort="[0]" and toPort="[65535]")) or cidrip matches "0.0.0.0*" or cidripv6 matches "*::*"
| formatDate(_messageTime, "yy-MM-dd HH:mm:ss") as date
| count date, cidrip, fromport, toport, groupid, ipprotocol, arn, type, errorcode

 

 

  1. Observe the aggregated results returned for all SGs. To add the detection for "permit any", remove the comment on the where filter line of code and rerun.

  2. No results will be returned, which means our training environment is properly configured. You may want to export this to your own environment and see if your SGs are secure.

 

Quiz (True or False?)

  1. The where filter only returns incoming log messages that match its argument.

  2. In the json parse, no drop allows log messages that don't match the parse to remain.

  3. When I get no results, that means something is definitely wrong with the code.

Summary

Congratulations! You’ve completed these tasks:

  1. Used JSON parsing.

  2. Applied a where filter multi argument.

  3. Counted the occurrence of possibly "permit any".