EveBox - Secure Suricata IDS Alert Triage Console

This is a repackaged open source software product wherein additional charges apply for cloudimg support services.

## Overview

EveBox is a web-based event viewer and alert-triage console for the Suricata network intrusion detection system. It gives security analysts a searchable, filterable inbox over Suricata's alert stream: escalate, archive and comment on alerts, drill into raw events, and pivot by source, destination or signature. This AMI ships the complete detection stack - the Suricata IDS engine captures traffic on the instance's primary interface and writes its EVE JSON event stream, and EveBox indexes that stream into a self-contained local datastore and serves the triage web UI. The result is a private, self-hosted intrusion-detection console you run and control in your own AWS account.

## Why This Image vs a Manual Install

This image eliminates the manual work of installing and wiring together a Suricata sensor and an EveBox console: capture-interface configuration, ruleset fetching, systemd service authoring, reverse-proxy setup, and credential hardening. The Emerging Threats Open ruleset is fetched at build time so the engine ships with a real signature set. The console is never left exposed: EveBox is bound to the loopback interface and an nginx reverse proxy fronts it with HTTP Basic authentication whose password is generated uniquely on each instance's first boot. Launch the instance, read your unique credential, and start triaging alerts.

## Application Stack

• Suricata is installed from the distribution archive, configured for af-packet capture on the primary interface, and seeded with the Emerging Threats Open ruleset
• EveBox runs as an unprivileged system user under a hardened systemd unit, using a self-contained SQLite datastore (no external database) and tailing the Suricata EVE JSON stream, bound to the loopback interface only
• nginx reverse proxy on port 80 forwards to EveBox, upgrading the connection for the live event stream and enforcing HTTP Basic authentication, with an unauthenticated health endpoint for load-balancer probes
• systemd starts every service on boot and restarts it on failure

## Security Hardening

This image follows a defence-in-depth approach:

• Network isolation: the console binds exclusively to the loopback interface; only the nginx reverse proxy is exposed, so authentication cannot be bypassed
• Authentication enforced: every request to the web UI and its API is authenticated - only an unauthenticated health endpoint is served anonymously
• No default or shared credentials: a cryptographically random web password is generated on each instance's first boot and written only to a root-only file
• Least privilege: the console runs as an unprivileged system user with NoNewPrivileges, PrivateTmp and ProtectHome set
• Empty by default: build-time telemetry is wiped before capture, so every instance starts clean

Buyers requiring formal compliance documentation should contact cloudimg to discuss specific requirements.

## Concrete Use Cases

• Intrusion-detection triage: A security team points the sensor at mirrored or in-line traffic and works the resulting alerts from a single searchable inbox, escalating real detections and archiving noise, pivoting from a signature to every related flow in one click
• Incident response and threat hunting: A responder searches historical events by source, destination, signature or timestamp to reconstruct what a host did around an incident, drilling into the raw EVE records behind each alert
• Self-hosted network monitoring: A platform team runs a private, self-contained IDS console per environment with no dependency on a paid external service, keeping all captured event data inside their own account

## AWS Integration

Deploy on any EC2 instance type; larger instances sustain higher capture throughput. Use the unauthenticated health endpoint with an Application Load Balancer for availability monitoring. Place the sensor in a VPC and use security groups and VPC Traffic Mirroring to control what it sees. Forward Suricata logs to CloudWatch Logs for long-term retention and alerting integration with other AWS services.

## Getting Started

1. Launch the AMI on your chosen EC2 instance type

2. Read your unique credential from the root-only file on the instance

3. Open the web interface in your browser and sign in

4. The alert inbox appears immediately with live events

5. Run the shipped self-test probe to verify the full capture-to-console pipeline

6. Tune the ruleset and point the sensor at the traffic you want to monitor

For guidance on instance sizing, traffic-mirror configuration, ruleset tuning, or integrating with your own TLS certificate and domain, contact cloudimg support.

## cloudimg Support

24/7 technical support by email and chat.