IPS log flooded with SURICATA QUIC failed decrypt

Security Intrusion Prevention
1

After Core 185 Update I noted if I’m using chromium based browser(Vivaldi, Brave or Edge) without Web Proxy IPS log gets flooded with these messages. If I use Firefox or enable proxy there are no new QUIC messages in log. It seems to happen every machine I have and it doesn’t matter what operating system I try.

Pages I visit always open without issue and remote ip seems to point to Google, Amazon, Cloudflare, Microsoft or Akamai datacenters even if the web page itself would be hosted somewhere else. Not all pages generate those messages but many do.

Date: 04/29 09:31:49 Name: SURICATA QUIC failed decrypt
Priority: 3 Type: Generic Protocol Command Decode
IP info: client.ip:55255 → remote.ip:443
References: none found SID: 2231000
Date: 04/29 09:29:57 Name: SURICATA QUIC failed decrypt
Priority: 3 Type: Generic Protocol Command Decode
IP info: remote.ip:443 → client.ip:61431
References: none found SID: 2231000

Does this mean suricata can’t filter that traffic and is it also blocked?

2

The QUIC decoder for Suricata is new. I don’t have much experience with it so I don’t know if this is simply some feature that isn’t supported or a bug.

However if the decode cannot decode some protocol, the traffic will be passed and not dropped.

3

This is definitely Chrome, it sends data to the owner Google.
Снимок экрана 2024-04-30 075852

4

I have blocked udp on port 443 and 5228 to prevent google from using quic.
I want to see how many connections has my devices open and quic hide this.

2 Likes
5

That’s better option than disabling QUICK protocol from every chromium based browser in every device.

1 Like
6

When thinking privacy is it better to leave QUIC enabled?

It looks like there are still connections to similar google owned *.e100.net servers. It doesn’t matter if I block ports mentioned in post by Arne.F or use web porxy. Not even when using “Google free” Brave or Vivaldi.

It seems that currently only benefit from blocking QUIC is that your log don’t get flooded with those QUIC failed decrypt messages and you see more active connections.

Edit.
I guess Url Filter does something.

image
image559×746 71.9 KB

1 Like
7

I wasn’t even aware quic was able to by pass firewall that easily,
so I took a look at outgoing traffic on ports 443 and 5228 and @arne_f is right,

It looks like that using any browser you will initiate a QUIC session when you visit Google, Youtube, or Facebook, etc.

I think it would make sense just to disable any network traffic that is using QUIC protocol.

Would a simple firewall rule suffice?

8

This is my proposed Firewall Rule, I would appreciate any feedback

image
image1552×754 45.9 KB

image
image1543×762 37.7 KB

9

I solved it!
To disable QUIC protocol in Google Chrome browser, follow these steps:
1.Open the Chrome browser and enter the following in the address bar: chrome://flags/#enable-quic
2. Find the “QUIC protocol” option and change its status to “Disabled”.
3. Restart Chrome.
I had up to 5000 records a day, I don’t know what it transmits using the QUIC protocol. This doesn’t look good on Google’s part. Usually they save you before entering =)

chrome Quick
chrome Quick1644×526 65.7 KB

10

Did that stop IPS log flooding?

I made Service group.

image
image932×109 2.77 KB

UDP 5228 it’s needed for Android device updates but I haven’t tested yet if blocking it breaks updating.

After creating group I made rule like this and it seems to work.

image
image872×1088 36.7 KB

No more SURICATA QUIC failed decrypt in IPS logs after this.

2 Likes
11

FYI, there is a similar setting in Edge that you should disable too if you’re going this route.

1 Like
12

I think a firewall rule as shown by @porkyle in post #10 should be much more effective.
First you have to change one device ( IPFire ) only, further this rule applies to all browsers/devices not known yet.

3 Likes
13

Bernhard would you be able explain the difference between firewall rules that have

A) Destination = STANDARD NETWORKS - RED
B) Destination = FIREWALL - ANY

QUIC uses only ports 443 and 5228?

I see some UDP traffic on port 137 as well going to 192.168.1.255

and UDP port 67 from 0.0.0.0 to 255.255.255.255 this one looks like a BOGON traffic

14

STANDARD NETWORKS - RED … packets destined for any target in the WAN
FIREWALL - ANY … packets which target an IP in the local networks

UDP packets to 192.168.1.255:137 are usually NETBIOS packets. 192.168.1.255 is the broadcast address of the network 192.168.1.0/24
UDP packets 0.0.0.0:67 → 255.255.255.255:68 or 0.0.0.0:68 → 255.255.255.255:67 are BOOTP packets of the DHCP protocol ( see Dynamic Host Configuration Protocol - Wikipedia and Bootstrap Protocol - Wikipedia )

2 Likes
15

Got it

so if I put destination = firewall it will only reject packets meant for local networks 192.168.0.1-255 and it will ignore packets for let’s say google-analytics.com ?

Let me change it to destination = standard networks

16

Is a firewall rule better, or commenting QUIC out in suricata-used-rulesfiles.yaml?

17

It depends what you wan’t. To block those QUIC connections use firewall rule but if you only want to disable logging you should comment them from surricata rules.

1 Like
18

After I posted, I realized suricata-used-rulesfiles.yaml is not a static file. It gets updated frequently, so if you comment the line, it will get undone shortly. So the firewall rule seems the only option. Thanks!

19

You could try to comment quick rules from /usr/share/suricata/rules/quic-events.rules file. I don’t know if it will be overwriten in updates.

20

That file is part of the suricata rootfile list so it will get replaced with any suricata update.

1 Like