Skip to content
Notifications
Clear all

Showcase: My alerting system for when the box's CPU spikes.

1 Posts
1 Users
0 Reactions
3 Views
(@cloud_security_sera)
Estimable Member
Joined: 1 month ago
Posts: 134
Topic starter   [#15134]

Default alerting for Firebox CPU is reactive. You're already in trouble. Here's my proactive system.

I use AWS CloudWatch Logs, not WatchGuard Dimension. Dimension is fine for dashboards, but its alerting is clunky. This method streams logs from the Firebox via syslog to a Lambda function for near-real-time analysis.

First, configure your Firebox to send syslog. Use a custom log format to include CPU. Ensure your log receiver (like an EC2 instance with syslog-ng) forwards to CloudWatch Logs.

Lambda function triggers on new log events. It parses the log line, extracts the CPU percentage, and checks against a threshold (I use 85% sustained for 2 minutes). If breached, it pushes to SNS, which feeds into our SIEM and PagerDuty.

```python
import json
import gzip
import base64
import re

def lambda_handler(event, context):
# Decode CloudWatch Logs
compressed_payload = base64.b64decode(event['awslogs']['data'])
uncompressed_payload = gzip.decompress(compressed_payload)
log_data = json.loads(uncompressed_payload)

cpu_pattern = re.compile(r'cpu_percent="(d+)"')
threshold = 85

for log_event in log_data['logEvents']:
message = log_event['message']
match = cpu_pattern.search(message)
if match:
cpu_usage = int(match.group(1))
if cpu_usage > threshold:
# Send to SNS
# ... your alerting logic here
print(f"ALERT: CPU spike detected: {cpu_usage}%")
```

Key points:
* Alert on sustained load, not a single spike.
* Tag alerts with the specific policy or feature causing the load (from the logs).
* This bypasses vendor lock-in for monitoring.
* Cost is negligible.


Least privilege is not a suggestion.


   
Quote