Suricata pass list question
-
You probably want to leave all those boxes checked, and then create a firewall alias containing the IP you want exempted.
Using a non-default Pass List with those extra items unchecked (gateway, WAN IP, DNS, etc.) can lead to lots of headaches, because if those local hosts get blocked you can cripple the firewall's connectivity. In fact, you can lock yourself completely out of the firewall over the network. Your only recourse then would be to use the physical console.
The default Pass List is constructed like it is (with gateways, DNS servers and all locally-attached networks protected against blocks) to preserve basic connectivity. All remote hosts (the Internet endpoints your local hosts communicate with) are still blocked. That is enough to stymie any malware. If you let Suricata block your gateway, for instance, then no traffic from your firewall can get to the Internet -- none, as in not a single bit! That's fantastic security, but very poor usability.
So for your original question, create a firewall Alias for the static IP, then create a custom Pass List and add the Alias to the list. Leave all the other boxes checked (in other words, leave the defaults). Save the list, then go to the Suricata interface where you want to use it and apply it by selecting it in the drop-down for Pass List and saving the change.
-
@bmeeks
Thank you. -
Humm, the pass list doesn't pass the traffic after configuring as recommended, clearing all blocks, and restarting.
Could that be because the machine is communicating with an external VPN, perhaps prsenting the WAN with an IP other than the expected 192.168.1.50?
-
@maxbishop said in Suricata pass list question:
Humm, the pass list doesn't pass the traffic after configuring as recommended, clearing all blocks, and restarting.
Could that be because the machine is communicating with an external VPN, perhaps prsenting the WAN with an IP other than the expected 192.168.1.50?
Where do you have Suricata running? I assumed it was on your LAN interface. If you have it on your WAN (not recommended, by the way), it will see all local addresses after NAT has been applied (for outbound traffic) and before NAT is unwound (for inbound traffic). Thus all local IPs will be masked with the WAN's IP address. This is the main reason for running Suricata on internal interfaces only (so that NAT does not get in the way).
Refer to these two diagrams that I have posted before that show the traffic flow:
Notice in both diagrams above where the IDS/IPS sits. It is BEFORE the firewall engine (for inbound traffic) and after the firewall engine (for outbound traffic). So putting Suricata on the WAN just exposes it to a bunch of junk noise the firewall is going to drop anyway. No sense having Suricata inspect something the firewall is already going to block.
-
Hi,
I have disabled Suricata on the WAN and cleared all blocks. However, I am still seeing blocks,
-
@maxbishop said in Suricata pass list question:
Hi,
I have disabled Suricata on the WAN and cleared all blocks. However, I am still seeing blocks,
Suricata cannot block if it is actually disabled and the BLOCKS tab is showing no IP addresses in the list.
The only possible way that can happen is if you have a duplicate, zombie Suricata process running that the GUI is no longer aware of and can't control.
-
@bmeeks
My post was ambiguous. I'll be more precise:I took your advise and disabled Suricata on the WAN. Then, to start fresh, I cleared all of the current blocks and restarted Suricata.
Later, when the user of 192.168.1.50 went back to her workstation and worked for a short while, I inspected the Suricata blocks and found new blocks associated with her device.
-
@maxbishop said in Suricata pass list question:
@bmeeks
My post was ambiguous. I'll be more precise:I took your advise and disabled Suricata on the WAN. Then, to start fresh, I cleared all of the current blocks and restarted Suricata.
Later, when the user of 192.168.1.50 went back to her workstation and worked for a short while, I inspected the Suricata blocks and found new blocks associated with her device.
You should not be seeing the IP address of that workstation in the BLOCKS list, but you will see any OTHER hosts that workstation was talking to. So the communications will still be interrupted with those other hosts. A Pass List keeps the IP addresses on the list from being blocked, but it does NOT keep the other end of the conversation from being blocked. So stating this another way, just because you put a workstation IP in the Pass List does not mean that workstation can then talk without interruption to any other hosts. If a rule triggers, those other hosts will still get blocked and that will interrupt communications with them.
-
I know I'm late to the game here, but I have a question that relates to all of this. How does one add an alias to the passlist to pass OUTBOUND rule processing for that alias, but not INBOUND rule processing that might apply to inbound connections to that device?
I have a device that occasionally creates invalid traffic patterns that create false positives in its OUTBOUND traffic that I would like to have Suricata ignore, but I still want to protect it from malicious INBOUND traffic.
Can you use a passlist to do that?
-
@drewsaur said in Suricata pass list question:
I know I'm late to the game here, but I have a question that relates to all of this. How does one add an alias to the passlist to pass OUTBOUND rule processing for that alias, but not INBOUND rule processing that might apply to inbound connections to that device?
I have a device that occasionally creates invalid traffic patterns that create false positives in its OUTBOUND traffic that I would like to have Suricata ignore, but I still want to protect it from malicious INBOUND traffic.
Can you use a passlist to do that?
No, a Pass List only understands IP address info, not traffic direction. So it can't distinguish between traffic inbound to some IP versus traffic outbound from the same IP. The general idea with using a Pass List is you never want that particular device's IP address to get blocked. And futhermore, it is usually assumed the IP in question is within a trusted network (either LAN or some variant that is trusted). That was how the Pass List idea was hatched.
Just so you know, the concept of "Alias" in Suricata is that it represents simply one or more IP addresses or network segments. It has no relation to how that alias might be used in firewall rules (for example, testing inbound versus outbound traffic against IPs represented in the alias). All Suricata does is pull the IP addresses out of the alias and put them into a memory structure that it consults before issuing a "block" against an IP.
-
@bmeeks Thank you very much. I suppose the best option for this sitation would be to watch the rules that my internal box is triggering false positives with, and to change their behavior on the LAN side to something other than DROP. Very helpful. Thanks.
-
@drewsaur There is the + icon to Suppress a rule for an IP, in the source and destination IP columns, if that helps.
