Ideco NGFW Novum Syslog

Quick Start

uv tool install eventum-generator
git clone https://github.com/eventum-generator/content-packs.git
cd content-packs
eventum generate \
  --path generators/network-ideco-ngfw/generator.yml \
  --id ideco-ngfw \
  --live-mode true

Event Types

Realism Features

• VPN users (300 by default, each with one home address and an activity weight between 0.7 and 2.5) log in about three times a day over a PPTP control connection (inp, port 1723), may fail first (each failure is a utm-vpn-authd Found), then authorize and produce a few flows (median 6, about 90 s apart) from a 10.128.0-3.x tunnel address to internal servers. 96.9% of ordinary logins succeed at once, 2.5% after one failure and 0.6% after two. About 1% of logins, more on some days than others, use a stale saved password and fail three to eight times: after three failures the user types the right password, after more the user gives up and in 60% of cases returns later (median 40 minutes), usually succeeding at once. About 4% of logins see at least one failure, and about 8-11% of VPN authorization attempts fail.
• About 40 brute-force campaigns a day from 40 internet addresses against utm-vpn-authd, utm-ssh or utm-web-interface, each address with its own jail preferences; a campaign makes about five attempts in median, a few seconds apart, and long campaigns end in a ban. Administrators mistype the web-interface password about six times a day, one to four failures from one of three LAN workstations. Traffic is LAN browsing (7% dropped), name and time lookups on the NGFW, and internet connections to NGFW ports, half of them from the brute-force addresses.
• About 27,000 records a day on UTC hour-of-day curves: LAN traffic from 296 records an hour at 21:00-06:00 to 1,432 at 08:00-17:00, VPN logins from 4 to 76 an hour, and internet traffic 250 an hour around the clock (each hour varying by up to 10%; daily LAN and VPN counts vary by up to 3%). Failures, authorizations, session flows and fail2ban records take the place of traffic records at their time, so they do not add to the volume.
• fail2ban is consistent: six Found for one address and jail within 900 s produce Ban (3 s later in median, at most about 30 s), a banned address makes no attempts in that jail, and Unban follows 2700 s later plus a few seconds. The 6 failures / 15 minutes / 45 minutes thresholds come from the v21 guide and apply to every jail, so ban durations are nearly constant; a real NGFW writes a ban within milliseconds of the failure that triggers it.
• Ordinary data contains every user, address, user/address pair, jail and action of the chain, including failure runs of four or more without success and successes after one to three failures. Only the full order is absent: when a returning user's address already has four VPN failures in the last 15 minutes, that attempt fails once more instead of authorizing (a few times a week). With anomaly_mode true, counts of four- and five-failure VPN runs, of authorizations after failures and of VPN control connections are about one per episode higher.
• The guide traffic-journal example is cut off after ips_pro, so 19 of the 39 documented keys are emitted in a plausible order without NAT, user, location, cluster and VCE keys, and the random 16-digit flow_id format is undocumented. Unban wording is inferred; only the documented successful pptp authorization is produced, failed VPN authorizations appear only as fail2ban Found, and VPN disconnections are not modeled.
• Records of one login, campaign or ban are seconds apart; timestamps have whole-second precision and are UTC, and Syslog transport framing is not modeled. Rates and failure shares are synthetic. No Elastic integration exists, so the ECS mapping is inferred. Home addresses are in 198.18.0.0/15, internet addresses in documentation ranges and internal ones in RFC 1918 networks; zone names, rule IDs and security profile names are examples of one deployment, not vendor defaults.

Sample Output

{
  "@timestamp": "2026-09-01T11:26:00+00:00",
  "ecs": {
    "version": "8.17.0"
  },
  "event": {
    "action": "vpn_authorized",
    "category": [
      "authentication",
      "network"
    ],
    "dataset": "ideco.ngfw_syslog",
    "kind": "event",
    "original": "2026-09-01T11:26:00+00:00 ideco-ngfw ideco-vpn-authd - - - Subnet 10.128.0.68/32 is authorized as user \u0027p.vlasov\u0027. Connection made from \u0027198.19.71.123\u0027, type \u0027pptp\u0027",
    "outcome": "success",
    "type": [
      "start",
      "allowed"
    ]
  },
  "ideco": {
    "ngfw": {
      "fields": {
        "connected_from": "198.19.71.123",
        "subnet": "10.128.0.68/32",
        "type": "pptp",
        "user": "p.vlasov"
      },
      "service": "ideco-vpn-authd"
    }
  },
  "message": "Subnet 10.128.0.68/32 is authorized as user \u0027p.vlasov\u0027. Connection made from \u0027198.19.71.123\u0027, type \u0027pptp\u0027",
  "observer": {
    "hostname": "ideco-ngfw",
    "ip": "10.50.0.1",
    "product": "NGFW Novum",
    "vendor": "Ideco"
  },
  "process": {
    "name": "ideco-vpn-authd"
  },
  "related": {
    "ip": [
      "198.19.71.123",
      "10.128.0.68"
    ],
    "user": [
      "p.vlasov"
    ]
  },
  "source": {
    "ip": "198.19.71.123"
  },
  "user": {
    "name": "p.vlasov"
  }
}

Parameters