SOC Analyst SIEM Monitoring Lab with Real Attack Traffic

Quick Lab Overview and Setup Roadmap

This lab is designed to simulate what a real SOC analyst does on shift: monitor logs, detect suspicious activity, correlate events, and document findings. Instead of using pre-built datasets, you will deploy your own cloud environment and allow it to receive real internet traffic.

The goal is simple: build a controlled, low-cost monitoring environment where you can observe brute-force attempts, scanning behavior, and authentication failures in real time. You will centralize logs, apply basic detection logic, and generate investigation artifacts just like in a production SOC.

In this setup, you are intentionally exposing a small AWS EC2 instance to the internet. WordPress acts as a visible web application target. SSH provides a common attack surface. Local security tools such as fail2ban and firewall logging create defensive telemetry. New Relic acts as a lightweight SIEM-like platform for log ingestion and analysis.

By the end of this lab, you will not only understand how monitoring works, you will have executed it end to end.

Because this lab involves real internet attack traffic: Use a fresh AWS account (or a dedicated sandbox account) with strict budget alerts, least-privilege access, and no sensitive data. Never reuse production keys, credentials, or personal passwords in this environment, and terminate all resources immediately after completing the lab.

Step 1 – Understand the Setup and Prepare Accounts

Before deploying anything, review the lab and understand what you are building. You are intentionally exposing a cloud server to observe real attack behavior, so preparation matters.

Start by registering a fresh AWS account if you do not already have one. Ensure billing is configured correctly and that you understand how EC2 pricing works.

Decide whether SSH will be restricted to your IP or open to the internet for realistic brute-force observation. Choose a strong WordPress administrator username and avoid defaults like “admin.”

For stable performance, use a t3.medium (2 vCPUs, 4 GB RAM). Smaller instances may struggle once WordPress, logging, and monitoring tools are active.

Always terminate the instance when finished to prevent unnecessary charges.

Step 2 – Launch and Configure Your EC2 Instance

Now you deploy the infrastructure that will function as both honeypot and monitoring node.

Launch an Ubuntu 22.04 EC2 instance using the following configuration:

• AMI: Ubuntu Server 22.04 LTS
• Instance type: t3.medium (recommended for stability)
• Storage: 8 GB minimum
• Public IP: Enabled

The t3.medium smoothes up CPU credit throttling and memory pressure once multiple services are running.

Security group configuration defines your exposure model. Allow:

• HTTP (80) from anywhere
• HTTPS (443) from anywhere
• SSH (22) from your IP, or from anywhere if you want to observe brute-force attempts naturally

After launch, connect via SSH using your key. Successful login confirms networking and permissions are configured correctly. At this stage, you have a stable, internet-facing Linux server ready to become an observable target.

Note: Disabling SSH password authentication prevents accidental compromise from repeated brute-force success.

Step 3 – Install the LAMP Stack and Deploy WordPress

This is where you create the visible attack surface.

Install Apache, MySQL, and PHP to transform the Ubuntu server into a functioning web server. Create a dedicated MySQL database and user for WordPress to maintain separation of privileges.

Download and extract WordPress into /var/www/html, adjust file ownership to www-data, and configure wp-config.php with your database credentials.

Complete the WordPress installer by visiting the public IP address in your browser.

The moment WordPress becomes reachable, automated scanners will begin probing:

• /wp-login.php
• /xmlrpc.php
• Username enumeration
• Credential spraying attempts

You now have a publicly exposed web application ready to collect real attack noise.

Step 4 – Install Wordfence and Enable Attack Logging

Now that your WordPress site is public, you add application-level visibility.

Wordfence acts as your first detection layer inside the web application. While Apache logs show raw HTTP requests, Wordfence gives you structured insight into login attempts, blocked IPs, and suspicious behavior patterns.

Inside WordPress Admin:

• Install and activate the Wordfence Security plugin
• Enable login attempt logging
• Enable Live Traffic view
• Enable email alerts for blocked IPs

Once enabled, Wordfence will immediately begin capturing:

• Failed login attempts
• Username targeting patterns
• User-agent strings
• IP addresses and timestamps

You should leave the site public. Within hours, bots will start probing /wp-login.php.

This step gives you visibility at the application layer. You are no longer just seeing network requests. You are seeing authentication behavior.

Important: Wordfence logs are stored inside the WordPress application and database. They are not automatically written to standard Linux log files and will not be forwarded to New Relic unless additional export configuration is implemented. In this lab, Wordfence primarily provides in-application visibility through the WordPress dashboard.

Step 5 – Install fail2ban and Create SSH + WordPress Jails

Now you introduce automated detection and response.

fail2ban monitors log files and temporarily bans IP addresses that show malicious behavior. This simulates real SOC detection logic tied to enforcement actions.

First, enable the default sshd jail to monitor:

/var/log/auth.log

Then configure:

• maxretry = 5
• bantime = 1h

Next, create a custom filter for WordPress to detect repeated POST requests to:

/wp-login.php

Attach this filter to the Apache access log and create a dedicated jail.

Restart fail2ban and verify active jails are running. Whitelist your own IP address to prevent accidental lockout.

At this stage, your system automatically:

• Detects repeated SSH login failures
• Detects WordPress brute-force attempts
• Bans offending IP addresses

You are now generating enforcement telemetry, which is critical for SOC-style analysis.

Step 6 – Configure ufw for Network Control and Logging

Now you add a basic perimeter control layer.

Using ufw (Uncomplicated Firewall), configure:

• Default deny incoming
• Allow outgoing
• Allow ports 22, 80, and 443
• Enable logging

This adds another source of telemetry: firewall-level blocked traffic.

For more advanced users, iptables can be configured to log dropped packets and persist rules using netfilter-persistent. However, ufw is sufficient for this lab.

With this layer in place, you now have three monitoring perspectives:

1. Application-level logging (Wordfence)
2. Authentication-level logging (fail2ban + auth.log)
3. Network-level logging (ufw)

You are building layered detection visibility, similar to how production SOC environments collect multi-source telemetry.

Step 7 – Integrate New Relic for Log Centralization

Until now, logs have been distributed across multiple files:

• /var/log/auth.log for SSH
• Apache access and error logs
• fail2ban.log
• Wordfence application logs

In a real SOC environment, analysts do not manually tail log files on individual servers. Logs are centralized into a SIEM platform for correlation and querying.

In this lab, New Relic acts as a lightweight SIEM-style solution. Install the New Relic Infrastructure Agent on your EC2 instance and add your license key to the configuration file.

Then configure log forwarding for:

• /var/log/auth.log
• /var/log/apache2/access.log
• /var/log/apache2/error.log
• fail2ban.log

Once enabled, verify that logs are visible in the New Relic dashboard.

You can now:

• Query failed SSH login attempts
• Identify repeated IP addresses
• Visualize spikes in authentication failures
• Track ban actions over time

This is where your lab transitions from server hardening to actual monitoring and detection.

Note: The New Relic free tier includes daily data ingestion limits. If your instance receives heavy brute-force traffic, logs may temporarily stop forwarding once the daily cap is reached. Monitor ingestion usage inside the New Relic dashboard to avoid confusion during analysis.

Step 8 – Generate and Observe Real Attack Traffic

Now you allow the environment to produce meaningful data.

There are two approaches:

Option 1: Passive collection
Leave the server publicly exposed for 24 to 72 hours. Automated scanners and bots continuously crawl the internet and will begin probing your endpoints.

Option 2: Controlled simulation
From another VM, attempt repeated SSH logins or send repeated POST requests to /wp-login.php to generate predictable attack patterns.

As traffic accumulates, monitor activity across:

• auth.log for SSH failures
• fail2ban.log for ban enforcement
• Apache access logs for WordPress login attempts
• New Relic dashboards for aggregated patterns

You will begin to observe:

• Hundreds of failed SSH login attempts
• Credential spraying against WordPress
• Repeated IPs targeting multiple services
• Short bursts of scanning activity

This is real internet background noise. You are now observing live attack behavior in your own controlled environment.

Step 9 – Analyze Results and Create Deliverables

Now you shift roles.

You are no longer deploying tools. You are investigating.

Start by extracting the top attacking IP addresses from both SSH and Apache logs. Identify:

• IPs with the highest number of login failures
• IPs targeting both SSH and WordPress
• IPs repeatedly banned by fail2ban

Next, enrich those IP addresses using:

• WHOIS lookup
• GeoIP databases
• ASN identification

Then build a timeline for at least one high-frequency attacker:

• When did activity begin
• How many attempts occurred
• How quickly bans were triggered
• Whether attacks resumed after ban expiration

Capture screenshots of:

• New Relic dashboards
• Query results
• Wordfence live traffic
• fail2ban statistics

Prepare professional artifacts:

• CSV file with top IPs, attempt counts, countries, ASN
• One-page incident summary explaining findings
• Visual evidence of detection and response

This is what differentiates theory from execution.

You now have documented proof that you:

• Deployed infrastructure
• Collected live attack data
• Correlated events across log sources
• Performed enrichment
• Produced structured incident documentation

These deliverables can be used in a portfolio, interview discussion, or SOC job application.

Step 10 – Clean Up and Secure Your Environment

Once you have collected data, completed analysis, and created your deliverables, the final step is operational discipline.

In real environments, analysts do not leave exposed infrastructure running without purpose. Cleanup is part of responsible security practice.

Inside the instance:

• Remove the New Relic agent if it was used only for this lab
• Revoke or rotate the New Relic license key
• Securely delete any exported logs or IP enrichment files

Inside AWS:

• Terminate the EC2 instance if you are finished
• Or stop it if you plan to reuse the lab later
• Delete unused snapshots and AMIs to prevent hidden storage costs

Finally:

• Review the AWS Billing Dashboard
• Confirm there are no running compute resources
• Ensure no elastic IPs or volumes remain attached

This step prevents unnecessary charges and ensures your lab does not become an unmanaged exposed asset.

You have now completed a full monitoring lifecycle:

Deploy → Detect → Correlate → Document → Close