Ruleset Configuration Guide

AtomicEdge provides multiple WAF rule groups targeting different attack vectors. This guide covers rule group selection, customization, and managing false positives.

Available Rule Groups

OWASP Core Rule Set

The OWASP ModSecurity Core Rule Set (CRS) provides broad protection against common web application attacks. This ruleset includes:

Protocol Enforcement – HTTP protocol compliance validation – Request method restrictions – Header format validation – Invalid character detection

Attack Detection – SQL injection patterns – Cross-site scripting (XSS) – Remote file inclusion – Local file inclusion – Remote code execution – Command injection – Path traversal attempts

Scanner Detection – Vulnerability scanner identification – Security tool detection – Automated bot traffic

Application Protection – Session fixation prevention – Authentication bypass attempts – Security misconfiguration detection

The OWASP CRS is updated regularly with new attack signatures. Enable this ruleset for general web application protection.

WordPress Rule Set

Specialized rules for WordPress installations:

WordPress-Specific Attacks – xmlrpc.php abuse detection – wp-login.php brute force protection – Plugin vulnerability exploitation – Theme vulnerability patterns – WordPress-specific SQL injection – Authentication bypass attempts

Sensitive File Protection – wp-config.php access blocking – .htaccess exposure prevention – Database backup file detection – Debug log access blocking

WordPress API Protection – REST API abuse detection – XML-RPC attack patterns – Excessive API request detection

Enable this ruleset alongside OWASP CRS for WordPress sites.

Comodo Rule Set

Additional protection from Comodo’s rule collection:

Extended Attack Coverage – Additional SQL injection patterns – XSS variants – Session management attacks – Cookie manipulation detection

Web Application Scanning – Scanner tool detection – Enumeration attempt blocking – Directory traversal patterns

Protocol Violations – HTTP request smuggling – Header injection attempts – Malformed request detection

The Comodo ruleset provides complementary coverage to OWASP CRS. Enable for enhanced protection.

Rule Group Configuration

Enabling Rule Groups

In site settings under WAF Protection:

  1. Select desired rule groups (OWASP, WordPress, Comodo)
  2. Configure response action (403, 404, drop)
  3. Save configuration
  4. Deployment occurs within 30-60 seconds

Rule groups can be enabled individually or in combination. Most sites benefit from multiple rule groups for layered protection.

Response Actions

Configure how blocked requests are handled:

403 Forbidden – Standard HTTP error response – Clear indication that request was denied – Recommended for most use cases – Helps legitimate users understand blocking

404 Not Found – Stealth mode response – Makes blocked resources appear non-existent – Useful for hiding admin areas – Reduces information disclosure to attackers

Drop – Silently terminates connection – No response sent to client – Wastes attacker resources – May cause client-side timeouts – Use for clearly malicious traffic

Choose response action based on security posture and user experience requirements.

Managing False Positives

Identifying False Positives

Signs of false positive blocking:

  • Legitimate users report access errors
  • Admin operations fail unexpectedly
  • Form submissions are blocked
  • API requests return 403 errors
  • File uploads fail

Check security logs to identify triggered rules.

Reviewing Security Logs

In the dashboard Logs section:

  1. Filter logs by time period
  2. Search for specific URIs or IPs
  3. Identify rule IDs causing blocks
  4. Review matched patterns

Log entries show: – Timestamp of block – Source IP address – Request URI and method – Rule ID that triggered – Rule message describing the match

Disabling Specific Rules

When a rule causes false positives:

  1. Note the rule ID from security logs
  2. Navigate to site WAF settings
  3. Expand the relevant rule group
  4. Add rule ID to disabled rules list
  5. Save configuration

Example disabled rules configuration:

OWASP Core Rule Set: Enabled
Disabled Rules: 920100, 941130, 942100

WordPress Rule Set: Enabled
Disabled Rules: WP001

Comodo Rule Set: Enabled
Disabled Rules: None

Testing After Rule Disabling

After disabling a rule:

  1. Test the previously blocked operation
  2. Verify it now succeeds
  3. Check that security is not overly reduced
  4. Document why the rule was disabled

Monitor logs for similar patterns – you may need to disable additional rules.

Selective Rule Disabling

Disable rules only when necessary:

  • Start with the most specific rule causing issues
  • Test after each change
  • Avoid disabling entire rule categories
  • Document business justification
  • Review disabled rules quarterly

Balance security and functionality based on your application’s needs.

Advanced Configuration

Rule Severity Understanding

Rules are classified by severity:

CRITICAL – SQL injection attempts – Remote code execution – Command injection – Highly likely to be attack traffic

WARNING
– Suspicious patterns – Protocol violations – Scanner detection – May include some false positives

NOTICE – Informational events – Unusual but not necessarily malicious – Often includes false positives

Consider severity when evaluating whether to disable a rule.

Phase-Based Processing

WAF rules execute in phases:

Phase 1: Request Headers – Method validation – Header format checking – Protocol compliance

Phase 2: Request Body – POST data analysis – File upload inspection – JSON/XML parsing

Phase 3: Response Headers – Outbound header validation – Security header checks

Phase 4: Response Body – Data leakage prevention – Error message sanitization

Phase 5: Logging – Audit logging – Alert generation

Understanding phases helps diagnose complex false positives.

Rule ID Patterns

Rule IDs follow patterns indicating their category:

OWASP CRS – 920xxx: Protocol enforcement – 930xxx: Application attacks – 941xxx: XSS detection – 942xxx: SQL injection – 943xxx: Session fixation – 950xxx: Outbound data leakage

WordPress Rules – WPxxx: WordPress-specific patterns

Comodo Rules – Numeric IDs without pattern prefix

Use patterns to understand rule categories when reviewing logs.

Anomaly Scoring

Some rulesets use anomaly scoring:

  • Each matched rule adds to a score
  • Block occurs when threshold is exceeded
  • Allows multiple weak indicators to trigger block
  • Reduces false positives from single rules

AtomicEdge uses direct blocking by default (not anomaly scoring) for predictable behavior.

Best Practices

Initial Configuration

When first enabling WAF protection:

  1. Enable OWASP CRS as baseline
  2. Add WordPress rules if applicable
  3. Use 403 response initially for visibility
  4. Monitor logs intensively for first 24 hours
  5. Disable rules causing false positives
  6. Test all critical application flows

Progressive Enhancement

Gradually increase protection:

  1. Start with core rule groups
  2. Monitor for false positives
  3. Tune rules based on traffic patterns
  4. Add additional rule groups
  5. Consider stricter response actions
  6. Enable rate limiting and access controls

Build confidence in configuration before enabling aggressive blocking.

Rule Maintenance

Regular maintenance ensures optimal protection:

  • Review disabled rules quarterly
  • Test if false positives still occur
  • Re-enable rules when application changes
  • Document reason for each disabled rule
  • Update configuration after application updates

Documentation

Document your rule configuration:

  • List all enabled rule groups
  • Document each disabled rule with reason
  • Note application-specific requirements
  • Record testing procedures
  • Maintain change history

This documentation aids troubleshooting and onboarding.

Testing Procedures

Establish testing procedures:

  1. Maintain a staging environment
  2. Test rule changes in staging first
  3. Verify critical application flows
  4. Test from multiple IP addresses
  5. Simulate attack traffic to verify blocking

Never change production rule configuration without testing.

Monitoring and Alerting

Set up monitoring for:

  • High rule trigger rates
  • New rule IDs triggering
  • Specific critical rules (SQL injection, RCE)
  • Geographic attack patterns
  • Sustained attack campaigns

Use dashboard analytics and alerting features.

Common Scenarios

E-Commerce Sites

Typical configuration:

  • Enable OWASP CRS
  • Disable rules that block checkout process
  • Monitor payment form submissions carefully
  • Test gift card and coupon code entry
  • Verify shipping address forms work

Common false positive areas: – Address fields with special characters – Product search with quotes or apostrophes – Checkout form submissions

Content Management Systems

Typical configuration:

  • Enable OWASP CRS
  • Enable CMS-specific rules (WordPress, etc.)
  • Disable rules blocking WYSIWYG editors
  • Allow HTML in content fields
  • Test media upload functionality

Common false positive areas: – Rich text editor operations – HTML/CSS in page content – File upload operations – API requests from editor

APIs and Web Services

Typical configuration:

  • Enable OWASP CRS
  • Carefully test JSON/XML payloads
  • Monitor API authentication endpoints
  • Verify parameter validation rules
  • Test error responses

Common false positive areas: – Complex JSON structures – SQL-like parameters in legitimate queries – User-generated content in API calls

Single Page Applications

Typical configuration:

  • Enable OWASP CRS
  • Test AJAX request patterns
  • Verify API endpoint access
  • Check WebSocket connections if used
  • Monitor authenticated requests

Common false positive areas: – Large JSON payloads in POST requests – Dynamic routing patterns – State management API calls

Troubleshooting

Legitimate Traffic Blocked

If legitimate traffic is blocked:

  1. Reproduce the block
  2. Check security logs for rule ID
  3. Verify the request is actually legitimate
  4. Disable the specific rule
  5. Test that block no longer occurs
  6. Document the change

Attacks Not Blocked

If attacks are not being blocked:

  1. Verify rule groups are enabled
  2. Check that deployment was successful
  3. Test with known attack patterns
  4. Review rule configuration
  5. Confirm DNS is pointed correctly

Test with a known attack string:

curl "https://example.com/?test=<script>alert(1)</script>"

Expected result: 403 Forbidden (or configured response)

Inconsistent Blocking

If blocking is inconsistent:

  1. Check if multiple edge endpoints have different configs
  2. Verify deployment completed successfully
  3. Test from multiple source IPs
  4. Check for IP whitelist configurations
  5. Review rate limiting settings

Performance Impact

If performance degrades after enabling rules:

  1. Check origin server load
  2. Verify edge endpoint connectivity
  3. Review rule processing logs
  4. Consider rule count (large disabled rule lists)
  5. Test with fewer rule groups

WAF processing adds minimal latency (typically <10ms). Significant performance issues usually indicate other problems.

Rule Group Conflicts

If multiple rule groups cause issues:

  1. Identify which group contains the problematic rule
  2. Disable rules in the specific group
  3. Test with one group at a time
  4. Enable groups progressively
  5. Document interactions between rulesets

Additional Resources

  • OWASP ModSecurity CRS documentation: https://coreruleset.org/
  • ModSecurity rule writing guide: https://github.com/SpiderLabs/ModSecurity/wiki
  • Common attack patterns: OWASP Top 10

For complex rule tuning scenarios, contact support for assistance with rule analysis and optimization.