Suricata JA3 alert on WAN interface
-
Hi Everyone,
I've just dipped into the world of Pfsense and found it to be an amazing product so far and has helped me replace some overly restrictive Unifi/Ubiquiti gear already. I have recently installed some IDS/IPS software (Suricata) and have been tuning it to remove as many false positives as possible.
I'm struggling with one alert that I don't wish to suppress yet, but can't work out how it only originates from the WAN IP and not a corresponding internal address too.
I have a single WAN interface, and a single LAN interface with multiple VLANs. Suricata watches both of my interfaces with the same configuration on each.
This is one of the alerts:
Any insight into tracing this would be great.
-
@olliecampbell said in Suricata JA3 alert on WAN interface:
Hi Everyone,
I've just dipped into the world of Pfsense and found it to be an amazing product so far and has helped me replace some overly restrictive Unifi/Ubiquiti gear already. I have recently installed some IDS/IPS software (Suricata) and have been tuning it to remove as many false positives as possible.
I'm struggling with one alert that I don't wish to suppress yet, but can't work out how it only originates from the WAN IP and not a corresponding internal address too.
I have a single WAN interface, and a single LAN interface with multiple VLANs. Suricata watches both of my interfaces with the same configuration on each.
This is one of the alerts:
Any insight into tracing this would be great.
Suricata (and Snort, if it were in use) sits outside the firewall engine. So packets go from the NIC straight to Suricata. They do not get filtered by the firewall first. So when you put Suricata on the WAN (which I don't recommend, by they way -- more on that at the end of this post), it will see and alert on traffic your firewall is likely to be blocking anyway. If that is the case here, then the LAN interface nevers sees the offending traffic and thus the rule is not triggered there.
Another possibility is you have VLANs defined. So it could be the HOME_NET variable is not correctly configured. That would make rules not fire properly when they contain the $HOME_NET and $EXTERNAL_NET variables in the SRC or DST fields of the rule. When using VLANs, you really should run only a single instance of Suricata on the physical parent interface with promiscuous mode enabled.
Lastly, check the configurations of both instances (LAN and WAN) of Suricata to be sure you have the same protocol analyzers enabled and configured the same way. That can change which rules alert or not in a given instance.
There really is no need to run Suricata on your WAN. As I mentioned, it is simply going to be busy analyzing, alerting, and possibly blocking typical Internet "noise" that your firewall is not going to allow through anyway. So why waste CPU cycles and RAM in that instance? Another problem with Suricata on the WAN is that for alerts logged there, because Suricata is seeing traffic before NAT is "unwound", all of your local hosts appear as your public WAN IP. So that makes tracking down what local host is the source of a problem very hard.
-
@bmeeks Perfect explanation thank you.
I've checked my $HOME_NET setting and it includes all of my internal networks and external DNS servers (not sure why the latter but presume that is an automatic addition) and $EXTERNAL_NET is the same list as $HOME_NET with exclamations at the front (I presume this is an exclude rule).
My LAN config is running on the parent LAN interface in promiscuous mode.
As you suggested, I've disabled the WAN checking. I think I followed a couple of guides on the Internet that might have suggested it so carried on. At the time I think I was unsure as to whether it would be assessing the traffic flowing into the WAN interface from the inside network rather than from the dark dangerous Internet.
Thanks once again.
-
The suggestion about HOME_NET and EXTERNAL_NET was a long shot mentioned just in case you had done some customization. The default settings usually work fine and capture all of the local firewall interfaces via pfSense system API calls. It also grabs things like defined DNS servers, so that's why those external DNS servers are there. They must be defined elsewhere in the pfSense configuration.
Here are two simple flow diagrams that illustrate how packets flow when either of the IDS/IPS packages are installed on pfSense.