SURICATA QUIC failed decrypt - filling my logs
-
@bmeeks Yes, exactly, that's how I found them, a search for the IP that was listed for the current event...
-
So now I have one more question about this...
@bmeeks said in SURICATA QUIC failed decrypt - filling my logs:
The difference is that Suricata provides a link to the rule's action when it calls my custom blocking module plugin, and thus the plugin can see if the rule's action was ALERT or DROP. It will only make the system call to insert the IP into the snort2c table if the action is DROP (when "Block on DROPs Only" is enabled). Otherwise, it skips entering the IP into the table and simply logs the alert.
Rules with Drop Action results in a block (with Block on DROP Only ticked), that is understood. And in Legacy mode, besides being marked RED in the Alerts tab, all of them also show up under the blocks tab? Including possible earlier blocks related to the same IP that create a match in the log file.
However, now I am looking at the list in the blocks tab, and see two recent blockings like this one:
I can find those exact same items marked RED in the Alerts tab as well:
But then I am also seeing another listing in the Alerts tab, more recent, but this one is NOT visible in the blocks tab?? Is this because it's a request going to pfsense?
Since if I simply type in one of the blocked IP's in the TOR rules list, it shows up in the blocks list..
[EDIT] No that was not it... This is confusing, what is actually going on here?
I do nslookup 'somthing.onion' from my PC and get the following response back:
Server: dns.google
Address: 8.8.8.8*** dns.google can't find something.onion: Non-existent domain
And it shows up under the Alerts tab like so:
And there is nothing in the blocks tab?!?Meaning... I do get a response from google, and looking into the blocks tab, confirms this as it is not listed as actually being blocked...
HOWEVER, looking in the Alerts tab I am led to belive that Drop Action was taken, -
@Gblenn said in SURICATA QUIC failed decrypt - filling my logs:
But then I am also seeing another listing in the Alerts tab, more recent, but this one is NOT visible in the blocks tab?? Is this because it's a request going to pfsense?
Those two IP addresses (192.168.1.115 and 192.168.1.1) are in RFC1918 space, so I assume those are on an internal firewall interface (LAN maybe ??). If true, then they will never result in a block because all local firewall interfaces are in the automatic pass list-- meaning those IP addresses will never be blocked although they will show as alerts. You see the DROP icon simply because that rule's action is DROP. That icon on the ALERTS tab shows you the "action" of the rule as read from the actual rule text. Also, to make them more apparent, rules with the DROP action keyword are highlighted with red text. But that does not necessarily mean each entry in red resulted in an IP address being added to the BLOCKS tab. For those that triggered and resulted in an actual block, you will see an additional red X icon beside whichever IP address (SRC or DST) was blocked.
Additionally, the default Pass List contains all of the local firewall interface subnets except that of the WAN. For the WAN, only the literal single host address of the firewall's WAN port is included. But for other internal interfaces such as the LAN, the entire subnet is pulled from the interface configuration and used in the Pass List. So, for example, likely 192.168.1.0/24 is in the default Pass List.
-
@bmeeks Yes that makes sense of course. And that made med realize that 8.8.8.8 is also in the default pass list so that's probably why my other attempt, bypassing pfsense resolver, were not blocked either...
Tried a different DNS server and now it shows up in the block list.
AND, I suppose I also managed to show the drawback of legacy mode, with "package leakeage".
First attempt, I do get a response back:nslookup something.onion
Server: dns.sse.cisco.com
Address: 208.67.222.222*** dns.sse.cisco.com can't find something.onion: Non-existent domain
Second attempt, fails - blocked:
nslookup something.onion
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 208.67.222.222 -
@Gblenn said in SURICATA QUIC failed decrypt - filling my logs:
@bmeeks Yes that makes sense of course. And that made med realize that 8.8.8.8 is also in the default pass list so that's probably why my other attempt, bypassing pfsense resolver, were not blocked either...
Tried a different DNS server and now it shows up in the block list.
AND, I suppose I also managed to show the drawback of legacy mode, with "package leakeage".
First attempt, I do get a response back:nslookup something.onion
Server: dns.sse.cisco.com
Address: 208.67.222.222*** dns.sse.cisco.com can't find something.onion: Non-existent domain
Second attempt, fails - blocked:
nslookup something.onion
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 208.67.222.222Yep. The number one drawback of that mode of operation. At least the first packet (and usually several in the flow) get past before the IDS/IPS has enough data to issue a verdict on the traffic. Inline IPS Mode does not have that problem. Nothing is passed on from the NIC until the IDS/IPS has finished analzying and come to a verdict on the flow.
