How to Set Up LogZilla on EVE-NG for Free

Eve-NG LogZilla Lab

EVE-NG is a network emulation platform for labbing multi-vendor topologies. It provides a reproducible network sandbox to validate logging pipelines, parsing, and incident workflows before deploying to production. A minimal but practical lab sends telemetry to a LogZilla collector, applies ingest‑time preprocessing (deduplication, suppression, enrichment, routing), and forwards selected streams to a downstream analytics platform. The result is a safe environment to tune cost, performance, and detection quality without impacting live systems.

Lab outcomes to validate

• Baseline normal device chatter vs. incident spikes.
• Quantify indexed volume reduction from deduplication and suppression.
• Demonstrate that first occurrences remain visible immediately while duplicates are summarized with accurate counts.
• Show how enrichment (site, owner, device role) improves query speed and triage quality.
• Verify routing: premium destinations receive only security‑relevant streams.

Minimum topology

• One EVE‑NG host (bare metal or VM) with nested virtualization support.
• Two network devices or simulators capable of syslog (for example, Linux nodes with syslog‑ng/rsyslog, or vendor virtual routers).
• One LogZilla collector VM or container.
• Optional: a downstream analytics/SIEM endpoint to validate forwarding.

A small lab still reveals volume patterns and lets teams tune windows and filters with realistic traffic.

Prerequisites

• EVE‑NG Community or Professional installed and reachable via HTTPS/SSH.
• Images for the device types you plan to emulate (vendor licensing may apply).
• A Linux image (for example, Ubuntu cloud image) to act as a generic syslog sender when vendor images are not available.
• LogZilla collector VM OVA or container deploy plan (CPU/memory sized for the lab; single‑node is sufficient for exercises).

High‑level architecture

• Device VLAN/segment inside EVE‑NG for sources.
• Management VLAN/segment for the collector and lab access.
• NAT or bridged uplink for internet access if needed (package updates, container pulls).
• Static addressing to keep device identities stable across reboots.

Create the lab in EVE‑NG

1. Create a new EVE‑NG project and open the topology canvas.
2. Add two network nodes that can emit syslog. If vendor router images are not available, use two Linux nodes:
   • Node A (linux‑a)
   • Node B (linux‑b)
3. Add one Linux node for the LogZilla collector (or import the LogZilla appliance if a prebuilt image is available).
4. Create two EVE‑NG networks:
   • net‑devices (for sources)
   • net‑mgmt (for management and the collector)
5. Connect linux‑a and linux‑b to net‑devices.
6. Connect the LogZilla node to both net‑devices and net‑mgmt (dual‑homed).
7. Start all nodes.

Assign IP addresses

Choose an addressing scheme suitable for the lab. Example:

• net‑devices: 10.10.10.0/24
  • linux‑a: 10.10.10.11
  • linux‑b: 10.10.10.12
  • logzilla (devices‑facing int): 10.10.10.10
• net‑mgmt: 10.20.20.0/24
  • logzilla (mgmt int): 10.20.20.10

Configure addresses on each node with static settings to avoid churn.

Install a syslog sender on linux‑a and linux‑b

Use syslog‑ng for consistent configuration in the lab. On each linux node:

bash
Wrap: OnCopyFullscreen
sudo apt-get update && sudo apt-get install -y syslog-ng-core

Create a minimal syslog‑ng config that forwards to the LogZilla collector over UDP first, then upgrade to TLS in a later section:

bash
Wrap: OnCopyFullscreen
cat | sudo tee /etc/syslog-ng/conf.d/10-forward-to-logzilla.conf >/dev/null <<'CONF'
@version: 3.38

source s_local {
  system();
  internal();
};

destination d_lz_udp {
  syslog("10.10.10.10" transport("udp") port(514));
};

log { source(s_local); destination(d_lz_udp); };
CONF

sudo systemctl restart syslog-ng

Trigger test events:

bash
Wrap: OnCopyFullscreen
logger -p auth.info "linux-a: test event one"
logger -p daemon.warn "linux-a: test event two"

Repeat on linux‑b, changing the message host tag accordingly.

Deploy the LogZilla collector

Use either the VM/appliance or a container‑based deployment appropriate for a single‑node lab. Ensure that the device‑facing interface (10.10.10.10 in this example) listens for syslog on UDP/514 and TCP/6514 for TLS in later steps. Validate reachability with nc -uz 10.10.10.10 514 from linux‑a.

Baseline normal chatter

Let the lab idle for a few minutes to accumulate normal messages (periodic service logs, cron, DHCP renewals if applicable). Capture a baseline:

• Events per minute by host and program
• Top message signatures (pre‑dedup)
• Burst behavior during simple actions (for example, restarting a service)

These measurements help choose an initial dedup window that suppresses back‑to‑back duplicates without delaying first occurrences.

Enable deduplication and suppression upstream

Configure ingest‑time preprocessing in LogZilla:

• Immediate‑first behavior: forward the first matching event instantly.
• Dedup window: choose a conservative window (for example, 30–60 seconds) for chatty sources like interface flaps or keepalives.
• Suppression rules: mark known non‑actionable messages (for example, periodic INFO with no operational impact) as non‑actionable; retain counts and samples for audit.

Validate outcomes:

• First occurrence appears in dashboards immediately.
• Duplicate bursts from logger loops are summarized with accurate counts.
• Indexed volume to downstream platforms drops while investigative fidelity is preserved.

Add enrichment

Attach context that accelerates triage:

• site: "lab‑dc"
• owner: "net‑team"
• device_role: "sim‑router" or "linux"
• zone: "dmz" | "user" | "core" (as fits your model)

Enrichment can come from static files, CMDB exports, or CSVs during lab work. Verify that enriched fields are searchable and appear in downstream payloads.

Route only what matters

Define routing so premium destinations receive security‑relevant streams; other streams can remain summarized upstream or be sent to a lower‑cost store. Examples:

• Security events (auth failures, privilege changes): forward.
• High‑volume operational chat (link flaps, keepalives): summarize and retain upstream; forward rollups or samples if needed.

Validate with a simple incident simulation

1. On linux‑a, simulate a burst:

   bash
   Wrap: OnCopyFullscreen
   for i in $(seq 1 200); do logger -p auth.warn "linux-a: auth flood $i"; done
   

2. Observe in the LogZilla UI/API:

   • First event is visible immediately.
   • Duplicates within the window are summarized (counts increase).

3. If a downstream SIEM is connected, confirm that it receives the first event and periodic rollups (if configured), not 200 identical lines.

Upgrade transport to TLS (syslog‑ng)

After validating functionality with UDP, enable TLS for confidentiality and integrity in transit. On linux‑a and linux‑b, create a client cert/key pair from a test CA (or use self‑signed for the lab), then configure syslog‑ng:

Syslog over TLS is standardized in RFC 5425 (default TCP port 6514). syslog-ng supports TLS forwarding using transport("tls") and port(6514).

bash
Wrap: OnCopyFullscreen
cat | sudo tee /etc/syslog-ng/conf.d/20-forward-to-logzilla-tls.conf >/dev/null <<'CONF'
@version: 3.38
source s_local { system(); internal(); };

destination d_lz_tls {
  syslog(
    "10.10.10.10"
    transport("tls") port(6514)
    tls(
      ca-dir("/etc/syslog-ng/ca.d")
      key-file("/etc/syslog-ng/client.key")
      cert-file("/etc/syslog-ng/client.crt")
      peer-verify(required-trusted)
    )
  );
}

log { source(s_local); destination(d_lz_tls); };
CONF

sudo systemctl restart syslog-ng

On the LogZilla collector, enable the TLS listener (6514) with the server certificate chain. Validate mutual authentication and verify certificate expiration monitoring is in place.

Measurement checklist

• Events per minute by source before/after dedup
• Indexed GB/day to downstream before/after routing rules
• Search performance deltas (smaller datasets should accelerate queries)
• Analyst time to triage common issues with and without enrichment

Record numbers in a simple table so improvements are visible to stakeholders.

Troubleshooting patterns

• Nothing arrives at the collector:
  • Confirm reachability with nc and that iptables/ufw is not blocking.
  • Check syslog‑ng status and logs on senders for transport errors.
• TLS handshake failures:
  • Verify CA trust path and hostnames.
  • Confirm key/cert permissions and dates.
• Dedup not taking effect:
  • Ensure messages truly match a signature (hostname/program and normalized text).
  • Increase window incrementally; avoid windows so large that first‑seen is delayed.
• Enrichment missing on some sources:
  • Check lookup keys (IP, hostname) and perform a test query.

Example lab variations

• Add a third node that emits noisy periodic logs, then tune suppression while retaining samples for audit.
• Introduce a synthetic network failure and observe bursts from link and routing processes; validate dedup behavior.
• Add a low‑cost object store sink and route non‑security rollups there.

Micro-FAQ

What is EVE-NG and why use it?

EVE-NG is a network emulation platform for labbing multi-vendor topologies. It helps validate parsing, routing, and dashboards before production.

How do devices in EVE-NG send logs to LogZilla?

Configure each virtual device to forward syslog to the LogZilla receiver IP and port. Use TLS when testing cross-boundary or sensitive flows.

Should TLS be used in labs?

Use TLS for security-sensitive tests. For quick local validation, TCP or UDP is acceptable, but prefer TLS as configurations mature.

How should lab scale be sized?

Start small, measure forwarded volume and duplicate ratios, then increase sources stepwise. Tune dedup windows by source type.

Next Steps

• Export the lab configuration (topology plus configs) for repeatability.
• Socialize the measured outcomes and agree on target reductions.
• Plan a phased rollout in production starting with high‑volume, low‑signal sources.