We release security updates for the following versions:

Please do not report security vulnerabilities through public GitHub issues.

We take security seriously. If you discover a security vulnerability, please follow these steps:

Send details to: security@yourorg.com (or create a private security advisory on GitHub)

Include:

• Description of the vulnerability
• Steps to reproduce
• Potential impact
• Suggested fix (if any)

• Initial Response: Within 48 hours
• Status Update: Within 7 days
• Fix Timeline: Depends on severity
  • Critical: 24-72 hours
  • High: 1-2 weeks
  • Medium: 2-4 weeks
  • Low: Next release cycle

• We follow coordinated disclosure
• We'll work with you to understand and fix the issue
• We'll credit you in the security advisory (unless you prefer anonymity)
• Please allow us reasonable time to fix before public disclosure

• � Use IAM roles on EC2 instances (recommended)
• � Follow principle of least privilege
• � Never commit AWS credentials to version control
• � Rotate access keys regularly (every 90 days)
• � Use AWS Secrets Manager or Parameter Store for production

• � Use bot tokens (not user tokens)
• � Restrict bot permissions to chat:write only
• � Store tokens in environment variables or secrets management
• � Rotate tokens if compromised

# Set restrictive permissions on sensitive files
chmod 600 .env
chmod 600 config.yaml
chmod 600 whitelist.txt
chown root:root .env config.yaml whitelist.txt

• � Run on private subnets when possible
• � Use VPC endpoints for AWS API calls
• � Implement egress filtering
• � Monitor outbound connections

• � Test in dry-run mode first
• � Maintain a separate whitelist
• � Monitor blocked IPs regularly
• � Have rollback procedures ready
• � Use manual rules for critical overrides (rules 1-79)

• � Protect log files from unauthorized access
• � Implement log rotation
• � Redact sensitive data from logs
• � Monitor logs for suspicious activity

• All changes require review before merging
• Security-sensitive changes require two reviewers
• Use automated security scanning (Dependabot, Snyk)

• Keep dependencies up to date
• Review dependency changes in pull requests
• Use tools like safety to check for vulnerabilities

• Write tests for security-critical functions
• Test with invalid/malicious inputs
• Use mocking for AWS API calls in tests

• Never commit secrets, even in examples
• Use placeholders in example files
• Scan commits for accidental secret exposure

• AWS NACLs have a limit of 20 rules per NACL (inbound/outbound)
• This script manages a subset (default: 20 rules from 80-99)
• Consider deploying multiple NACLs or using AWS WAF for larger deployments

• ALB access logs may contain sensitive information
• Ensure S3 buckets have appropriate access controls
• Consider encrypting logs at rest

• Block registry file contains IP addresses and metadata
• Protect this file with appropriate permissions
• Consider encrypting if storing PII

• Attack pattern detection may produce false positives
• Maintain a whitelist for legitimate traffic
• Monitor blocked IPs and adjust thresholds

• Notifications may contain IP addresses and attack details
• Ensure Slack workspace has appropriate security controls
• Consider data retention policies

1. Input Validation

   • Validates IP addresses before blocking
   • Filters out private/reserved IPs
   • Checks whitelist before blocking

2. AWS IP Exclusion

   • Automatically excludes AWS service IPs
   • Prevents blocking AWS health checks

3. Dry-Run Mode

   • Test without making changes
   • Verify behavior before production deployment

4. Graceful Error Handling

   • Handles corrupted registry files
   • Recovers from API failures
   • Logs errors without exposing secrets

5. Tiered Blocking

   • Prioritizes high-severity threats
   • Prevents displacement of critical blocks
   • Time-based expiration

• All block/unblock actions
• IP addresses and hit counts
• NACL rule modifications
• API errors and warnings
• Configuration changes

• Application logs: /var/log/auto-block-attackers.log
• Systemd journal: journalctl -u aws-auto-block-attackers
• CloudTrail: AWS API calls (if enabled)

• IP Addresses: May be considered PII in some jurisdictions
• Retention: Configure based on your compliance requirements
• GDPR: Implement data retention and deletion policies

• Document your blocking policy
• Implement a process for unblocking requests
• Maintain audit logs for compliance
• Regular security reviews

1. Immediate Actions

   • Revoke compromised AWS credentials
   • Rotate Slack tokens
   • Review NACL rules for unauthorized changes
   • Check block registry for tampering

2. Investigation

   • Review CloudTrail logs
   • Check system logs for unauthorized access
   • Identify scope of compromise

3. Recovery

   • Deploy new credentials
   • Restore from known-good backups
   • Update security controls

4. Post-Incident

   • Document lessons learned
   • Update security procedures
   • Notify affected parties if required

Before deploying to production:

• Run in dry-run mode and verify behavior
• Configure whitelist with trusted IPs
• Set up Slack notifications for monitoring
• Implement log rotation and retention
• Use IAM roles (not access keys)
• Set restrictive file permissions
• Enable CloudTrail for audit logging
• Document rollback procedures
• Test emergency unblock process
• Schedule regular security reviews

• AWS VPC Security Best Practices
• AWS Network ACL Documentation
• OWASP Top 10

For security questions or concerns:

• Email: security@yourorg.com
• GitHub Security Advisories: Create Advisory

Last Updated: 2025-01-XX