Snort uses up all memory (12GB) [SOLVED]
-
For what reason shouldnt you kill the states?
Just asking since I would imagine that killing the connection is better than keeping the state and this could get congested by a massive attack…?
@jflsakfja:
Snort doesn't have anything to do with the blocking, to put it simply. Think of snort like your scout. He can spot enemies, but can't engage them directly. I've already described the way the packets get copied and passed to snort, I'll explain what snort does when an alert is generated.
When an alert is raised by snort, the offending IP is added to pfsense's snort2c table. It's just a normal table, think of it like a table that gets created when you add an alias. It's job is to hold many IPs, nothing more. When that IP is added to the table, pfsense needs to become aware of the change, therefore the previously cached table is refreshed. There are hidden rules (like dark forces wanting to take over the world?) that say any IP in the snort2c table, either source or destination, gets blocked. As soon as pfsense becomes aware of the change (DON'T tick the reset states under snort/suricata) it effectively stop transmitting packets for those IPs. If you selected to reset the states, then the states are reset, killing the connection in a more RFC compliant way (the proper way). You do NOT want to EVER do this. The attacker shouldn't know what system is your firewall (the one that does the reset).
Snort isn't involved in any way with the actual packet, from the point the initial actual packet is first received, to the moment it results in a ban. You do understand that going through the previous paragraph takes a while. It's rarely above 2 seconds though, so don't worry. During that time pfsense (the way I like to call it) leaks packets along the network. Using a theoretical 1 packet exploit attack scenario (very very unlikely), no host is directly protected, since at least 1 packet WILL get through. Snort spots what's wrong with the packets, the blocking is all pfsense's job.
-
Snort/Suricata inline will be much better as it will be able to block faster than how it works now. However, once the first packet from a malicious IP is blocked, any packets that follow are subsequently blocked immediately by the packet filter as the IP is now in the snort2c file.
-
Blocking the IP and killing the states for "Both" WAN and LAN is recommended. Any IPs on the lan side won't be added to the snort2c file as they are on the "pass list".
You don't want to leave the states alive that were involved in an "alert" as you leave an attack vector open into your network.
-
pfsense handles the killing, no need to tell the attacker "hey, I just blocked your connection, kthxbye"
-
2 opposite ideas….
What to believe?
-
Only trust the little voice inside your head.
EDIT: I'm assuming we are talking about a home type system. For a large network then yes, killing the states could save you from a massive attack.
-
@jflsakfja:
If you selected to reset the states, then the states are reset, killing the connection in a more RFC compliant way (the proper way). You do NOT want to EVER do this. The attacker shouldn't know what system is your firewall (the one that does the reset).
This is incorrect. Killing states does not involve sending RST packets, it just clears firewall's internal state for the connection in question.
As BBcan177 said, checking this box is recommended. -
In that case I understand that I have broken the cluster's quorum and agree to re-sync with the rest of the cluster. See why clusters with 2 members never work? :p
In plain english: I stand corrected, enable killing the states.
-
Take a look at this thread: I have seen others but hard to find on you mobile browser ;)
On the other hand for firewall rules "block" on WAN and "reject" on LAN.
https://forum.pfsense.org/index.php?topic=75199.msg410525#msg410525
-
Thanks :)