Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Topics - koushun

#1
Maybe I am not understanding this, but, I thought I could go to Wazuh > Threat intelligence > Threat Hunting and get an overview over Suricata events, however it does not seem to pick up any events from /var/log/suricata/eve.json?

OPNsense firewall version:
Versions
OPNsense 25.1.4_1-amd64
FreeBSD 14.2-RELEASE-p2
OpenSSL 3.0.16

os-wazuh-agent installed on OPNsense firewall:
os-wazuh-agent (installed) 1.2 40.4KiB 3 OPNsense Agent for the open source security platform Wazuh
Wazuh (LXC container installed by helper script: https://community-scripts.github.io/ProxmoxVE/scripts?id=wazuh):
4.11.2
The agent installed on the firewall is marked as active in Wazuh.

Configuration file for agent installed on firewall:
cat /var/ossec/etc/ossec.conf
<ossec_config>
  <client>
    <server>
      <address>192.168.1.12</address>
      <protocol>tcp</protocol>
      <port>1514</port>
    </server>
    <crypto_method>aes</crypto_method>
    <enrollment>
      <port>1515</port>
    </enrollment>
  </client>

  <client_buffer>
    <!-- Agent buffer options -->
    <disabled>no</disabled>
    <queue_size>5000</queue_size>
    <events_per_second>500</events_per_second>
  </client_buffer>

  <!-- Policy monitoring -->
  <rootcheck>
    <disabled>no</disabled>

    <!-- Frequency that rootcheck is executed - every 12 hours -->
    <frequency>43200</frequency>

    <rootkit_files>/var/ossec/etc/shared/rootkit_files.txt</rootkit_files>
    <rootkit_trojans>/var/ossec/etc/shared/rootkit_trojans.txt</rootkit_trojans>

    <system_audit>/var/ossec/etc/shared/system_audit_rcl.txt</system_audit>
    <system_audit>/var/ossec/etc/shared/system_audit_ssh.txt</system_audit>
    <system_audit>/var/ossec/etc/shared/cis_debian_linux_rcl.txt</system_audit>

    <skip_nfs>yes</skip_nfs>
  </rootcheck>

  <wodle name="syscollector">
    <disabled>no</disabled>
    <interval>1h</interval>
    <scan_on_start>yes</scan_on_start>
    <hardware>yes</hardware>
    <os>yes</os>
    <network>yes</network>

    <!-- Database synchronization settings -->
    <synchronization>
      <max_eps>10</max_eps>
    </synchronization>
  </wodle>

  <!-- File integrity monitoring -->
  <syscheck>
    <disabled>no</disabled>

    <!-- Frequency that syscheck is executed default every 12 hours -->
    <frequency>43200</frequency>

    <scan_on_start>yes</scan_on_start>

    <!-- Directories to check  (perform all possible verifications) -->
    <directories>/etc,/usr/bin,/usr/sbin</directories>
    <directories>/bin,/sbin,/boot</directories>

    <!-- Files/directories to ignore -->
    <ignore>/etc/mtab</ignore>
    <ignore>/etc/hosts.deny</ignore>
    <ignore>/etc/mail/statistics</ignore>
    <ignore>/etc/random-seed</ignore>
    <ignore>/etc/random.seed</ignore>
    <ignore>/etc/adjtime</ignore>
    <ignore>/etc/httpd/logs</ignore>
    <ignore>/etc/utmpx</ignore>
    <ignore>/etc/wtmpx</ignore>
    <ignore>/etc/cups/certs</ignore>
    <ignore>/etc/dumpdates</ignore>
    <ignore>/etc/svc/volatile</ignore>
    <ignore>/sys/kernel/security</ignore>
    <ignore>/sys/kernel/debug</ignore>

    <!-- File types to ignore -->
    <ignore type="sregex">.log$|.swp$</ignore>

    <!-- Check the file, but never compute the diff -->
    <nodiff>/etc/ssl/private.key</nodiff>

    <skip_nfs>yes</skip_nfs>
    <skip_dev>yes</skip_dev>
    <skip_proc>yes</skip_proc>
    <skip_sys>yes</skip_sys>

    <!-- Nice value for Syscheck process -->
    <process_priority>10</process_priority>

    <!-- Maximum output throughput -->
    <max_eps>100</max_eps>

    <!-- Database synchronization settings -->
    <synchronization>
      <enabled>yes</enabled>
      <interval>5m</interval>
      <response_timeout>30</response_timeout>
      <queue_size>16384</queue_size>
      <max_eps>10</max_eps>
    </synchronization>
  </syscheck>

  <!-- Log analysis -->
  <localfile>
    <log_format>syslog</log_format>
    <location>/var/ossec/logs/active-responses.log</location>
  </localfile>

  <localfile>
    <log_format>syslog</log_format>
    <location>/var/ossec/logs/opnsense_syslog.log</location>
  </localfile>

  <!-- Suricata -->
  <localfile>
    <log_format>json</log_format>
    <location>/var/log/suricata/eve.json</location>
  </localfile>


  <!-- Active response -->
  <active-response>
    <disabled>yes</disabled>
  </active-response>


</ossec_config>

The necessary permissions are in place on the firewall, as root is running the 'wazuh-logcollector'- which is presumably able to read /var/log/suricata/eve.json?
ps aux | grep wazuh
root        35464   0.0  0.1   49484   16068  -  S    21:32       0:05.04 /var/ossec/bin/wazuh-logcollector
root        86633   0.0  0.0   23596   12032  -  I    21:32       0:00.00 /var/ossec/bin/wazuh-execd
wazuh       90197   0.0  0.1   39936   14848  -  S    21:32       0:35.77 /var/ossec/bin/wazuh-agentd
root        95620   0.0  0.1   46636   17808  -  SN   21:32       0:12.82 /var/ossec/bin/wazuh-syscheckd
root        92113   0.0  0.0   13748    2036  1  S+   23:14       0:00.00 grep wazuh

Additional Information, group membership for user wazuh:
id wazuh
uid=309(wazuh) gid=309(wazuh) groups=309(wazuh)

File permissions for eve.json:
ls -al /var/log/suricata/eve.json
-rwx------  1 root wheel 15899978 Apr  5 23:16 /var/log/suricata/eve.json

There are active events being logged to eve.json- although they are not of "event_type":"alerts", but rather "event_type":"tls":
tail -f /var/log/suricata/eve.json
{"timestamp":"2025-04-05T23:18:25.645024+0200","flow_id":434493063789884,"in_iface":"vtnet1","event_type":"tls","src_ip":"p.p.p.p","src_port":13938,"dest_ip":"z.z.z.z","dest_port":443,"proto":"TCP","pkt_src":"wire/pcap","tls":{"subject":"CN=*.iot.eu-west-1.amazonaws.com","issuerdn":"C=US, O=Amazon, CN=Amazon RSA 2048 M01","serial":"04:83:77:02:F6:2F:7A:39:61:31:41:F2:29:7A:8E:CF","fingerprint":"5a:ee:c9:1e:e7:3c:6b:48:86:66:dc:f7:a5:0a:ea:24:49:15:cb:eb","sni":"al9fa5uwnmgg7-ats.iot.eu-west-1.amazonaws.com","version":"TLS 1.2","notbefore":"2024-08-21T00:00:00","notafter":"2025-07-28T23:59:59","ja3":{"hash":"d311fcfe5b660d59dc616e20831c55a0","string":"771,52393-49195-49196-52392-49199-49200-49161-49162-49171-49172-156-157-47-53,65281-0-23-13-5-11-10,29-23-24,0"},"ja3s":{"hash":"e36e593c5f33a620e2c9d3801f61be4a","string":"771,49199,0-11-65281-23"}}}
{"timestamp":"2025-04-05T23:18:25.740509+0200","flow_id":285055222499977,"in_iface":"vtnet1","event_type":"tls","src_ip":"x.x.x.x","src_port":14301,"dest_ip":"y.y.y.y","dest_port":443,"proto":"TCP","pkt_src":"wire/pcap","tls":{"subject":"CN=*.iot.eu-west-1.amazonaws.com","issuerdn":"C=US, O=Amazon, CN=Amazon RSA 2048 M01","serial":"04:83:77:02:F6:2F:7A:39:61:31:41:F2:29:7A:8E:CF","fingerprint":"5a:ee:c9:1e:e7:3c:6b:48:86:66:dc:f7:a5:0a:ea:24:49:15:cb:eb","sni":"al9fa5uwnmgg7-ats.iot.eu-west-1.amazonaws.com","version":"TLS 1.2","notbefore":"2024-08-21T00:00:00","notafter":"2025-07-28T23:59:59","ja3":{"hash":"d311fcfe5b660d59dc616e20831c55a0","string":"771,52393-49195-49196-52392-49199-49200-49161-49162-49171-49172-156-157-47-53,65281-0-23-13-5-11-10,29-23-24,0"},"ja3s":{"hash":"e36e593c5f33a620e2c9d3801f61be4a","string":"771,49199,0-11-65281-23"}}}


#2



2024-08-27T00:48:43 Warning ntopng 27/Aug/2024 00:48:43 [Ntop.cpp:3890] WARNING: Unable to find timezone: using UTC
2024-08-27T00:48:40 Notice root /usr/local/etc/rc.d/ntopng: WARNING: failed to start ntopng
2024-08-27T00:48:40 Warning ntopng 27/Aug/2024 00:48:40 [Ntop.cpp:3890] WARNING: Unable to find timezone: using UTC
2024-08-27T00:47:27 Notice root /usr/local/etc/rc.d/ntopng: WARNING: failed to start ntopng
2024-08-27T00:47:27 Error ntopng 27/Aug/2024 00:47:27 [Redis.cpp:157] ERROR: to specify a redis server other than the default
2024-08-27T00:47:27 Error ntopng 27/Aug/2024 00:47:27 [Redis.cpp:154] ERROR: Please start it and try again or use -r
2024-08-27T00:47:27 Error ntopng 27/Aug/2024 00:47:27 [Redis.cpp:153] ERROR: ntopng requires redis server to be up and running
2024-08-27T00:47:26 Error ntopng 27/Aug/2024 00:47:26 [Redis.cpp:98] ERROR: Connection error [Connection refused]
2024-08-27T00:47:25 Error ntopng 27/Aug/2024 00:47:25 [Redis.cpp:98] ERROR: Connection error [Connection refused]
2024-08-27T00:47:24 Error ntopng 27/Aug/2024 00:47:24 [Redis.cpp:98] ERROR: Connection error [Connection refused]


After latest update. ..
Tried stopping and starting redis, tried to stop and start ntopng, tried to reset Redis as well. Tried a reboot.

And ideas?


#3
* OPNsense 21.7-amd64
* os-telegraf 1.11.0 (Telegraf 1.19.0)
* InfluxDB 2.0.7

I was hoping this release would fix the problem I have with Intrusion Detection Alerts not beiing sent to InfluxDB.

https://opnsense.org/opnsense-21-7-released/ states that "intrusion detection: fix alert reads from eve.json", but as I was unable to find any more information in the release post, this statement is probably referering to another issue. Anyways, to bump this issue to 21.7, I'll post my findings here on this more active Forum section - I have rambled over at the General Discussion page quite a bit : https://forum.opnsense.org/index.php?topic=16966.0)

1) Suricata is started with the user root
2) Suricata produces events in the /var/log/suricata/ directory which has these permissions

drwx------   2 root      wheel       12B Jul 30 00:00 suricata

3) Suricata creates JSON entries in the file /var/log/suricata/eve.json which has these permissions

-rwx------  1 root  wheel    30K Jul 30 14:53 /var/log/suricata/eve.json

4) Enabling "Intrusion Detection Alerts" in Telegraf, creates this config in /usr/local/etc/telegraf.conf

[[inputs.tail]]
  data_format = "json"
  files = ["/var/log/suricata/eve.json"]
  name_override = "suricata"
  tag_keys = ["event_type","src_ip","src_port","dest_ip","dest_port"]
  json_string_fields = ["*"]

5) Telegraf is started by the user telegraf

ps aux | grep telegraf
telegraf 12093   0.0  1.1  5040852   92304  -  S    14:02     0:35.47 /usr/local/bin/telegraf --quiet --config=/usr/local/etc/telegraf.conf --config-directory=/usr/local/etc/telegraf.d

6) Telegraf does not have permissions to view the file /var/log/suricata/eve.json

sudo -u telegraf more /var/log/suricata/eve.json
/var/log/suricata/eve.json: Permission denied

7) There is no errors in /var/log/telegraf/telegraf.log from [[inputs.tail]] that the file is inaccessible

A quick fix is to add the user telegraf to the wheel group and change permissions. This will not survive a reboot.

pw group mod wheel -m telegraf
chmod 750 /var/log/suricata ; chmod 750 /var/log/suricata/eve.json


Then metrics are populated in InfluxDBv2.

Although I have not figured this out entirely, I think the [[inputs.tail]] section would benefit from having "timestamp" from eve.json parsed.

https://docs.influxdata.com/telegraf/v1.19/data_formats/input/json/#json_time_key-json_time_format:
Quote
By default the current time will be used for all created metrics, to set the time using the JSON document you can use the json_time_key and json_time_format options together to set the time to a value in the parsed document.

The json_time_key option specifies the key containing the time value and json_time_format must be set to unix, unix_ms, or the Go "reference time" which is defined to be the specific time: Mon Jan 2 15:04:05 MST 2006.


[[inputs.tail]]
  data_format = "json"
  files = ["/var/log/suricata/eve.json"]
  name_override = "suricata-alerts"
  tag_keys = ["flow_id","in_iface","event_type","src_ip","src_port","dest_ip","dest_port","proto"]
  json_string_fields = ["*"]
  json_time_key = "timestamp"
  json_time_format = "2006-01-02T15:04:05-0700"


Has anyone got this to work / having the same problems?

#4

  • OPNsense 21.1.8_1-amd64
  • os-telegraf (installed)   1.11.0
  • Telegraf 1.19.0   
  • VLAN_15: 192.168.15.0/24


  • Ubuntu 20.04.2 LTS
  • InfluxDB 2.0.7 (git: 2a45f0c037) build_date: 2021-06-04T19:17:40Z

I am not certain how this is supposed to work, but I do not receive any data from OPNsense to my InfluxDB (??). There is nothing showing on the Boards section of InfluxDB, "No Results", using the default "System" dashboard and the correct bucket. Using the "Explore" section of InfluxDB, there is no data- even when enabling "View Raw Data".  I do not know what I have done wrong. Can someone help me?

Output

The Input section is default. I have then on the General tab enabled the Telegraf Agent. I have saved all these settings, and I've also tried to restart the Telegraf service. Both the Quiet and Debug Log have been enabled.

Using
netstat
on the host machine (192.168.15.10), I can see a tcp connection from the firewall on port:8086, but no data has been sent/received. The installation of InfluxDB is done following this guide: https://docs.influxdata.com/influxdb/v2.0/install/?t=Linux on an Ubuntu 20.04 machine.

I have double, triple and quadrupled checked that the bucket is correct, the Token is correct and the Organization name is correct (which has been altered in this forum post).

The most common error I've found in the OPNsense Telegraf Log File is

2021-07-20T12:22:50 E! [outputs.influxdb_v2] Failed to write metric (will be dropped: 404 Not Found): not found: path not found


However, when I change a setting / hit Save in the Input section of Telegraf, I get these errors:

2021-07-20T12:29:00 I! Starting Telegraf 1.19.0
time="2021-07-20T14:29:00+02:00" level=error msg="failed to open. Ignored. open /.cache/snowflake/ocsp_response_cache.json: no such file or directory\n" func="gosnowflake.(*defaultLogger).Errorf" file="log.go:120"
time="2021-07-20T14:29:00+02:00" level=error msg="failed to create cache directory. /.cache/snowflake, err: mkdir /.cache: permission denied. ignored\n" func="gosnowflake.(*defaultLogger).Errorf" file="log.go:120"


Are those errors related to why nothing is happening on my InfluxDB v2 instance? I have tried to remove the plugin, install the plugin and even rebooted the firewall.

The firewall (192.168.15.1) is able to ping the machine hosting InfluxDB, from the VLAN15 interface (Source Address) - there are no funky firewall rules either. ..

What have I done wrong?