Firewall Audit with AWS Config

February 13, 2026 | AWS Security Compliance

Automated security group compliance.

Firewall Rules Audit with AWS Config

Security Group misconfigurations are the #1 cause of cloud security incidents. AWS Config provides continuous monitoring and automated remediation for Security Group compliance — ensuring your firewall rules stay locked down even as teams make changes.

Common Security Group Violations

  • 0.0.0.0/0 on SSH (port 22) — Exposes servers to the entire internet
  • 0.0.0.0/0 on RDP (port 3389) — Widespread Windows RDP exploitation
  • 0.0.0.0/0 on database ports — Direct database access from the internet
  • Overly permissive egress — Allows data exfiltration
  • Unused Security Groups — Orphaned rules that create confusion

AWS Config Rules for Security Groups

# Detect Security Groups allowing unrestricted SSH
aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "restricted-ssh",
  "Source": {
    "Owner": "AWS",
    "SourceIdentifier": "INCOMING_SSH_DISABLED"
  }
}'

# Detect Security Groups allowing unrestricted common ports
aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "restricted-common-ports",
  "Source": {
    "Owner": "AWS",
    "SourceIdentifier": "RESTRICTED_INCOMING_TRAFFIC"
  },
  "InputParameters": "{\"blockedPort1\":\"3389\",\"blockedPort2\":\"3306\",\"blockedPort3\":\"5432\",\"blockedPort4\":\"6379\",\"blockedPort5\":\"27017\"}"
}'

# Detect VPCs without default Security Group lockdown
aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "vpc-default-sg-closed",
  "Source": {
    "Owner": "AWS",
    "SourceIdentifier": "VPC_DEFAULT_SECURITY_GROUP_CLOSED"
  }
}'

Automated Remediation

Automatically fix non-compliant Security Groups using SSM Automation:

aws configservice put-remediation-configurations --remediation-configurations '[{
  "ConfigRuleName": "restricted-ssh",
  "TargetType": "SSM_DOCUMENT",
  "TargetId": "AWS-DisablePublicAccessForSecurityGroup",
  "Parameters": {
    "GroupId": {"ResourceValue": {"Value": "RESOURCE_ID"}},
    "AutomationAssumeRole": {"StaticValue": {"Values": ["arn:aws:iam::xxx:role/ConfigRemediation"]}}
  },
  "Automatic": true,
  "MaximumAutomaticAttempts": 3,
  "RetryAttemptSeconds": 60
}]'

Custom Config Rule for Advanced Checks

# Lambda-based custom rule: detect SGs with more than 50 rules
import boto3
import json

def lambda_handler(event, context):
    config = boto3.client('config')
    ec2 = boto3.client('ec2')

    configuration_item = json.loads(event['invokingEvent'])['configurationItem']
    sg_id = configuration_item['resourceId']

    sg = ec2.describe_security_groups(GroupIds=[sg_id])['SecurityGroups'][0]
    total_rules = len(sg['IpPermissions']) + len(sg['IpPermissionsEgress'])

    compliance = 'COMPLIANT' if total_rules <= 50 else 'NON_COMPLIANT'

    config.put_evaluations(
        Evaluations=[{
            'ComplianceResourceType': 'AWS::EC2::SecurityGroup',
            'ComplianceResourceId': sg_id,
            'ComplianceType': compliance,
            'Annotation': f'Security Group has {total_rules} rules',
            'OrderingTimestamp': configuration_item['configurationItemCaptureTime']
        }],
        ResultToken=event['resultToken']
    )

Security Group Audit Dashboard

Build a CloudWatch dashboard showing:

  • Non-compliant Security Groups — Count by rule type
  • Remediation history — Auto-fixes applied
  • Security Group changes — Via CloudTrail events
  • Trend over time — Compliance score improvement

Best Practices

  1. Lock down default SGs — Remove all rules from the default Security Group in every VPC
  2. Use descriptive names — Name SGs by purpose: web-alb-sg, api-ecs-sg, db-rds-sg
  3. Reference SG IDs — Use source Security Group references instead of CIDR blocks
  4. Review monthly — Generate compliance reports from AWS Config
  5. Tag ownership — Tag every SG with the owning team for accountability

Eazy SaaS Tip: We enable AWS Config with Security Group rules and automatic remediation as part of our security baseline. Any Security Group that opens SSH or database ports to 0.0.0.0/0 is automatically locked down within 60 seconds — preventing accidental exposure before it can be exploited.