architecting real-time threat detection with wazuh: a practical deep dive

introduction: why real-time threat detection is your new best friend

imagine your web application is a bustling digital storefront. real-time threat detection is like having a team of highly trained security guards who not only spot shoplifters but can recognize a suspicious pattern and stop them as they walk in the door. in the world of devops and full stack development, security isn't an afterthought—it's woven into the fabric of your operations. wazuh, an open-source security platform, is your all-in-one toolkit for building this vigilant, always-on security system. this deep dive will guide you, step by step, through architecting that solution.

chapter 1: wazuh 101 – understanding the core components

before we build, let's understand the blueprint. wazuh's architecture is like a well-orchestrated alert system.

• the wazuh manager (brain): this is the central server that processes all the data from your agents, applies security rules, and triggers alerts. think of it as the security command center.
• the wazuh agent (eyes & ears): a lightweight piece of software you install on each server or endpoint (your web server, database, application container) you want to monitor. it collects system logs, file changes, and network activity and sends it securely to the manager.
• the wazuh indexer (memory): powered by opensearch, this is where all the alert and log data is stored, indexed, and made searchable for analysis and dashboards.
• the wazuh dashboard (face): the beautiful, interactive web interface (opensearch dashboards) where you can visualize alerts, manage agents, and hunt for threats. it's your single pane of glass.

chapter 2: setting up your lab environment

let's get our hands dirty. the easiest way to start is with the all-in-one deployment on a linux machine (like an ubuntu vm). this sets up the manager, indexer, and dashboard on a single server.

prerequisites

• a clean linux server (ubuntu 22.04 lts recommended).
• root or sudo user access.
• at least 4 gb of ram and 20 gb of disk space.

install wazuh (a quick start script)

wazuh provides a fantastic script that handles the heavy lifting. run these commands as root:

# download and run the wazuh installation script
curl -so https://packages.wazuh.com/4.7/wazuh-install.sh && sudo bash ./wazuh-install.sh -a

once complete, the script will output the dashboard credentials and its url (typically https://). log in and take a look around!

chapter 3: onboarding your first agent – securing a web server

this is where your full stack journey with wazuh begins. let's secure an nginx web server.

step 1: install the agent on the web server

on your web server (not the wazuh manager), run:

# add the wazuh repository
curl -s https://packages.wazuh.com/key/gpg-key-wazuh | gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && chmod 644 /usr/share/keyrings/wazuh.gpg
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | tee -a /etc/apt/sources.list.d/wazuh.list
apt-get update

# install the agent package
apt-get install wazuh-agent

step 2: configure the agent to talk to the manager

edit the agent configuration file to point to your wazuh manager's ip address.

# /var/ossec/etc/ossec.conf

    
        
            your_wazuh_manager_ip
            tcp
        
    
    ...

then start the agent: sudo systemctl start wazuh-agent

step 3: approve the agent in the dashboard

navigate to your wazuh dashboard, go to "agents" > "add agent". you should see your new web server listed with a "pending" status. select it and click "add agent". within moments, it will become active, and wazuh will start receiving its first logs.

chapter 4: crafting your threat detection rules

wazuh's power lies in its decoders (which parse log lines) and rules (which define what constitutes a threat). you can use the pre-installed ruleset, but creating custom rules is a key coding skill for your security architecture.

example: detecting sql injection attempts in nginx access logs

our goal is to trigger a high severity alert if an nginx access log contains a url with common sql injection patterns like union select or or 1=1.

step 1: create a custom decoder

if the existing nginx decoder doesn't capture the full url query, we can enhance it. create a file: /var/ossec/etc/decoders/local_decoder.xml

<decoder name="nginx-accesslog">
    <parent>nginx-accesslog</parent>
    <type>web-log</type>
    <prematch>^</prematch>
    <regex>^(\s+ \s+) (\s+) (\s+) (\s+ \s+) "(\s+)" (\d+) {$} (\d+)$</regex>
    <order>srcip, srcport, user, url, action, status, size</order>
</decoder>

step 2: write the detection rule

create a file: /var/ossec/etc/rules/local_rules.xml

<group name="attack,sqli,">
    <rule id="100001" level="10">
        <decoded_as>nginx-accesslog</decoded_as>
        <url type="pcre2">(?i)(union(\s|\+)+select|select\s.+\sfrom|or\s+\d+=\d+)</url>
        <description>possible sql injection attack pattern found in nginx access log.</description>
        <mitre>
            <id>t1190</id>
        </mitre>
        <group>attack,web,sql_injection,</group>
    </rule>
</group>

restart the manager to load the new rules: sudo systemctl restart wazuh-manager. now, any nginx log line matching that pattern will generate a high-priority alert visible in your dashboard's security events tab.

chapter 5: integrating into your devops & ci/cd pipeline

a devops culture means tools should integrate smoothly. here’s how wazuh fits in:

• infrastructure as code (iac): manage your wazuh ossec.conf and custom rules in git. use ansible, puppet, or chef to deploy the agent and its configuration consistently across all your environments (dev, staging, prod).
• automated alerting: use the wazuh restful api to integrate alerts into your slack or microsoft teams channels, jira tickets, or pagerduty incidents.

# example: using the api to get the last 5 high-severity alerts (run on the manager)
token=$(curl -u wazuh:wazuh -k -x post "https://localhost:55000/security/user/authenticate" | jq -r '.data.token')
curl -k -h "authorization: bearer $token" -x get "https://localhost:55000/syscheck?limit=5&pretty&select=all" | jq

• immutable containers: secure your docker containers and kubernetes clusters by deploying the wazuh agent as a daemonset. this provides visibility across your entire containerized full stack.

chapter 6: beyond alerts – proactive threat hunting & seo security

real-time detection is reactive. proactive threat hunting uses the wazuh dashboard and its integration with opensearch to find latent threats. you can run complex queries to hunt for anomalies.

# example opensearch query in the dashboard: find all failed sudo attempts from the last hour
{
  "query": {
    "bool": {
      "must": [
        { "match": { "rule.groups": "sudo" } },
        { "match": { "data.status": "failed" } },
        { "range": { "@timestamp": { "gte": "now-1h" } } }
      ]
    }
  }
}

security and seo are linked: a hacked website can be injected with spam links, malware, or become a part of a botnet, leading to devastating google penalties or blacklisting. wazuh helps protect your seo standing by detecting the very compromises that search engines punish, such as defacement, phishing content injection, or unusual outbound traffic that could indicate a site takeover. protecting your site's integrity is, in essence, protecting its search rank.

conclusion: your journey to a secure, real-time stack

you’ve just built the foundation for real-time threat detection. you’ve installed the system, onboarded a critical piece of your full stack, written a custom detection rule as code, and considered how to weave it into devops practices. remember, this is a journey. start with monitoring your web servers and other critical nodes. then, expand your detection rules to cover authentication failures, file integrity changes (fim), and command execution anomalies.

the best security is the kind that grows with you. wazuh provides the open-source flexibility and powerful features to make that possible. start small, automate what you can, and watch your alerts. happy securing!