snort failing to start and stops itself sometimes
-
Hi all
Running snort, it seems that its not very stable, maybe its a bug or a misconfiguration? Could more advanced logging be enabled?
Based on the forum searches, I enabled the SensitiveDataPreprocessor just to be sure.
Any help will be appreciated!
2021-08-30 07:25:56.321362+02:00 snort 3138 FATAL ERROR: /usr/local/etc/snort/snort_44408_em0.34/snort.conf(5) Failed to parse the IP address: [10.10.10.0/24,10.114.126.0/23,10.121.22.0/23,10.122.154.0/23,10.124.6.0/23,82.169.124.1,82.169.124.75,127.0.0.1,172.16.1.0/24,172.16.2.0/24,172.16.5.0/24,172.16.6.0/24,172.16.7.0/24,172.16.8.0/24,192.168.1.0/24,::1,Array,fe80::1:1,fe80::96c6:91ff:fea4:5987]. -
The Sensitive Data Preprocessor has nothing to do with your error. And you do not want it enabled unless you are actually searching for sensitive data exfiltration. But that is close to impossible to do these days because everything is encrypted (SSL and TLS) flowing through the firewall.
Your problem is that an interface or alias is resolving to an empty array. See the value "Array" in the error? That is not an IP address or CIDR subnet, so Snort is balking.
There is one other user reporting a similar problem, and the root cause of the "Array" entry has not yet been determined for him either.
Go to the INTERFACE SETTINGS tab for the Snort interface, scroll down to the Choose the Networks Snort Should Inspect and Whitelist section, and then click on the View List button next to the Home Net drop-down selector. See if that shows the same values as are showing above - including that errant "Array" value. If it does, then you need to examine the list and see if you can determine which of your configured IP addresses on the firewall is missing from the list. The "Array" value is likely to be that one. The most likely source of this problem is an interface that is either not up (i.e., has no assigned IP address), or perhaps an alias you assigned that is now not resolving.
Here is a link to the other thread with what appears to be the same problem: https://forum.netgate.com/topic/166106/suricata-doesn-t-start-automatically-at-boot.
If you can do some research on your configuration and provide me the data, I can try to reproduce on my end to see if it's something I can prepare the GUI package code to watch out for. At the moment I have no idea precisely where the problem exists, thus creating a fix is difficult.
-
@bmeeks thanks for your prompt reply! Regarding the interfaces I have this running:
-WireGuard incoming (might be related to this experimental package?)
-OpenVPN outgoing 4xI doe assume that the OpenVPN interfaces does not have an IP when the FW boots. Without reading your post I moved my client subnets to the Home section and all other subnets to the External net section. From what I could see this improved the situation, is there a possibility to enable debug logs?
Could you explain the diff between policies and bootup sequence regarding to external and home networks?
-
@thebear said in snort failing to start and stops itself sometimes:
@bmeeks thanks for your prompt reply! Regarding the interfaces I have this running:
-WireGuard incoming (might be related to this experimental package?)
-OpenVPN outgoing 4xI doe assume that the OpenVPN interfaces does not have an IP when the FW boots. Without reading your post I moved my client subnets to the Home section and all other subnets to the External net section. From what I could see this improved the situation, is there a possibility to enable debug logs?
Could you explain the diff between policies and bootup sequence regarding to external and home networks?
In the context of IDS/IPS, HOME_NET is the collection of networks (IP addresses, actually) that you wish to protect. These are generally trusted internal networks and hosts. EXTERNAL_NET is, by default, any networks and IP addresses that are not in HOME_NET. In fact, the standard literal definition of EXTERNAL_NET is !HOME_NET (with "!" meaning "not").
Many of the IDS signatures are written with these two variables used in either the Source or Destination portions of the rule. Probably the most frequent use is something like this:
$EXTERNAL_NET any -> $HOME_NET any <some payload content to look for>So that rule means any IP address that is not part of HOME_NET sending data from any source port to an IP address that IS part of HOME_NET on any destination port is one condition for triggering the signature. The other condition is, of course, for the payload content to match.
So as you can tell from the above example, if the HOME_NET and EXTERNAL_NET variables are not correctly defined for your configuration, the IDS/IPS signatures can fail to properly trigger.
The values for HOME_NET and EXTERNAL_NET are pulled from the defined interfaces on the firewall. But if some configured firewall interface starts AFTER the IDS/IPS, then it is conceivable the IP values pulled for populating HOME_NET and EXTERNAL_NET will be incorrect. That can certainly happen for something like a VPN interface if that interface is brought up after the IDS/IPS has started and attempted to build the HOME_NET and EXTERNAL_NET variables.
-
Make sense! Would you configure a Guest network as External or Home? Then I'll generate a final config and see what a reboot does.
-
@thebear said in snort failing to start and stops itself sometimes:
Make sense! Would you configure a Guest network as External or Home? Then I'll generate a final config and see what a reboot does.
Most folks would likely choose to isolate the Guest network (wireless I am assuming here), and not bother with IDS/IPS on it. But if you want IDS/IPS on a Guest Wireless, then HOME_NET should contain the following values at a minimum:
- IP subnet of firewall interface (or VLAN) the Guest Network is assigned to;
- IP address of any assigned DNS servers;
Snort will then automatically define EXTERNAL_NET as "!$HOME_NET" (again, meaning all IP addresses/subnets not defined in HOME_NET). So in a Guest Network setup, because you likely want to limit HOME_NET as I outlined above, you will customize HOME_NET by creating a Pass List, and then assigning that Pass List by name in the HOME_NET assignment drop-down on the INTERFACE SETTINGS tab.
My reply in a previous post explaining how HOME_NET and EXTERNAL_NET work was based on the assumption you were using the automatic, default setup. In that mode, Snort automatically determines HOME_NET and EXTERNAL_NET settings based on the process I described. If you are customizing either variable, then what I described earlier in terms of how HOME_NET is automatically constructed does not apply. It, and EXTERNAL_NET, will contain whatever values (IP addresses and subnets) you specified.
One last important point. Snort runs on the physical interface. It does not understand VLANs. So running on the physical interface means it runs on the VLAN parent and will thus see ALL traffic that traverses the interface. When using IDS/IPS, it's better to separate networks by putting them on physically separate ports rather than using VLANs on a single interface.
-
@bmeeks Interesting I'm indeed running it on a vlan trunk, NUC only has one port.
