Suricata doesn't start automatically at boot
-
Thanks @bmeeks. The router was what slowing it down. I unplugged it, rebooted and suricata was up.
-
Sorry, but the issue came back after I updated pfSense.
suricata.log after failure to start at boot
28/8/2021 -- 16:16:13 - <Notice> -- This is Suricata version 6.0.3 RELEASE running in SYSTEM mode 28/8/2021 -- 16:16:13 - <Info> -- CPUs/cores online: 4 28/8/2021 -- 16:16:13 - <Info> -- HTTP memcap: 67108864 28/8/2021 -- 16:16:13 - <Error> -- [ERRCODE: SC_ERR_ADDRESS_ENGINE_GENERIC(89)] - failed to parse address "Array" 28/8/2021 -- 16:16:13 - <Error> -- [ERRCODE: SC_ERR_INVALID_YAML_CONF_ENTRY(139)] - failed to parse address var "HOME_NET" with value "[10.10.0.0/24, 10.10.10.1/32, 10.10.20.0/24, 10.10.30.0/24, 127.0.0.1/32, 192.168.1.14/32, 192.168.1.254/32, 193.19.108.2/32, 194.242.2.2/32, ::1/128, Array, fe80::a236:9fff:fe18:6f7c/128, fe80::a236:9fff:fe18:6f7d/128, fe80::a236:9fff:fe18:6f7e/128, fe80::a236:9fff:fe18:6f7f/128]". Please check its syntax 28/8/2021 -- 16:16:13 - <Error> -- [ERRCODE: SC_ERR_INVALID_YAML_CONF_ENTRY(139)] - basic address vars test failed. Please check /usr/local/etc/suricata/suricata_10842_igb0/suricata.yaml for errors
HOME_NET after manual start
HOME_NET: "[10.10.0.0/24, 10.10.10.1/32, 10.10.20.0/24, 10.10.30.0/24, 127.0.0.1/32, 192.168.1.14/32, 192.168.1.254/32, 193.19.108.2/32, 194.242.2.2/32, ::1/128, fe80::a236:9fff:fe18:6f7c/128, fe80::a236:9fff:fe18:6f7d/128, fe80::a236:9fff:fe18:6f7e/128, fe80::a236:9fff:fe18:6f7f/128]"
pfSense 2.5.2 or 2.6.0-dev.
So, I gave WAN a static address (I am behind the router of an ISP).
I removed other interfaces and unplugged anything on them until only left with WAN and LAN.
I removed other packages.
I tried Legacy Mode or Inline Mode.
Same result : whichever interface doesn't come up fast enough according to @bmeek.
I have a smaller form factor box and it does it on both. maybe it's the ISP's router. -
After it fails to start at boot, do not manually start it. Instead go here and examine the
suricata.yaml
file to read the actual runtime value for HOME_NET from the file.The file will be in a subdirectory for each interface under
/usr/local/etc/suricata/
. Use the DIAGNOSTICS > EDIT FILE menu option in pfSense to browse the directory previously listed. In it you will see one or more subdirectories (one for each configured Suricata interface). The subdirectorties will have the physical NIC device name and a random UUID in their name. Inside each subdirectory you will find thesuricata.yaml
file for that interface.Open that file in the GUI editor and scroll until you see the HOME_NET definition line. Examine that line and compare all the IP addresses and subnets listed to what is defined on your firewall. See which defined IP is missing in HOME_NET and is instead showing as "Array". That's going to be the guilty party interface.
-
@bmeeks This is exactly what I did. as you can see there's any differrences.
I started from scratch again but I didn't import the aliases (the only thing I imported each time, there's too many of them).
-
@koff said in Suricata doesn't start automatically at boot:
@bmeeks This is exactly what I did. as you can see there's any differrences.
I started from scratch again but I didn't import the aliases (the only thing I imported each time, there's too many of them).
Do you have Wireguard or OpenVPN in use? Another possible suspect would be a VPN interface that comes up late in the boot process (after Suricata has already started, for example). Trying to correlate your symptoms with those of a Snort user with a similar problem. Wireguard and/or OpenVPN might be a common denominator.
-
@bmeeks As I said, even with a clean install with only the aliases imported, suricata had this behavior.
Right now, I didn't import the aliases and it works normally for the last 3 days. -
@koff said in Suricata doesn't start automatically at boot:
@bmeeks As I said, even with a clean install with only the aliases imported, suricata had this behavior.
Right now, I didn't import the aliases and it works normally for the last 3 days.So that narrows your problem down to one or more of the aliases not populating correctly. Although it should warn you when choosing aliases in Suricata, be aware that it does not support FQDN aliases. Snort does on a limited basis, but not Suricata.
Are you using a nested alias in a custom HOME_NET declaration, or are you using the default HOME_NET value? I assumed you were using the default, so with the default HOME_NET configuration an alias should not matter as none are defined in HOME_NET by default.
-
@bmeeks I 'm using the default HOME_NET value.
-
@koff said in Suricata doesn't start automatically at boot:
@bmeeks I 'm using the default HOME_NET value.
Now I am very confused. If you are using the default settings for HOME_NET and EXTERNAL_NET, then there is no way importing or not importing an alias would matter one bit.
Do you maybe mean you originally had a custom HOME_NET definition using an alias, and now, with the aliases not imported, you have reverted to the default HOME_NET?
I'm not understanding your setup here, and thus your problem does not seem logical.
-
@bmeeks The aliases are for firewall rules. I didn't add them to the HOME_NET value
-
@koff said in Suricata doesn't start automatically at boot:
@bmeeks The aliases are for firewall rules. I didn't add them to the HOME_NET value
Then there is no way they are related to your problem with having "Array" defined in HOME_NET. We are back to the original suspect -- an interface (likely a VPN) is not up and configured at the time the IDS/IPS starts and constructs the automatic default values.
Perhaps the alias would impact the VPN startup, and that in turn might influence how HOME_NET gets constructed. But there is not a direct relationship between firewall rule aliases and HOME_NET and EXTERNAL_NET in the IDS/IPS packages.
-
@bmeeks You are probably right, wireguard is the last package to start... So I will import the aliases and see what happens.