Snort uses up all memory (12GB) [SOLVED]
-
@jflsakfja:
facepalm sure, the forum's senior expert on how to configure snort (me) doesn't know about the block option ;)
;D ;D ;D
(I always have to laugh about how cynical you can write :P ).
Snort's blocking ability (block offenders) doesn't depend so much on the processing you do to the packet, but on the priority of the rule. The higher the priority, the faster the packet is pushed through processing (actually the lower the number in the queue that gets assigned to it, but don't let technicalities get in the way). In plain words, the higher the priority (technically lower number), the less packets get through before the block is active (see end for further explanation as to why).
The difference between processing a packet, adding the IP to the snort2c table (for the block offenders setting to actually work), pfsense getting notified about the change and acknowledging it, between the matchers is so negligible, it's universally agreed by all races in the known universe to ignore it. Since I don't know about the option ;)As I mentioned in my previous post, by the time you are done processing the >COPY< of the packet, added the host to the blocked table and all that, the >ACTUAL< packet has already passed through pfsense and it's extremely (read:almost guaranteed) that it has gone to it's original destination (if pfsense's rules allow it).
The confusion about the snort package lies in the misconception that snort is acting on the >ACTUAL< packet. It's NOT acting on the >ACTUAL< packet! It's acting on a >COPY< of the packet. The >ACTUAL< packet (ignoring routing bottlenecks, rules, etc) is NOT affected in ANY way by snort. Not even seen by snort. Snort doesn't even know it exists.
About the parts in bold, because I didn't realize this (I have not seen it documented elsewhere so clearly, but then again, I suggested to you before you go write books ;) ): so actually what you are saying Snort in the current way of working will not block all offensive packets, only parts of them?
-
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.
-
@jflsakfja:
Snort doesn't have anything to do with the blocking, to put it simply.
If you would write books I would be one of the first to buy them ;D
So, what you explained now: and is this why everybody is 'eagerly' awaiting the inline filtering? Then it would be a situation of no packet getting through whatsoever?
With the reset states you mean 'kill states' in the GUI?
-
Yes and yes ;D
Inline will bring the current functionality + not having packets leak through the network gateway.
Technically kill is performed by an RST (reset) flag being set (a reset packet). ;D
-
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 :)
