How to drop corrupted packages on pfSense?
-
Hello,
I have created a rule to allow UDP traffic and noticed multiple times in the linux kernel log entries "UDP: bad checksum".
Is it possible to drop any corrupted packages at pfSense and don't let them pass to the client?
I have tried to find something like that in the documentation and via Google without success (or I am blind).
-
Where are those bad packets coming from? At which layer are they corrupted? If Ethernet, then they shouldn't be passed by anything.
-
I think they are send by purpose.
Apr 6 18:21:44 debian kernel: [522750.011183] UDP: bad checksum. From 79.44.213.169:65535 to ... ulen 33 Apr 6 18:21:44 debian kernel: [522750.088737] UDP: bad checksum. From 79.44.213.169:65535 to ... ulen 33 Apr 6 18:21:46 debian kernel: [522752.090057] UDP: bad checksum. From 79.44.213.169:65535 to ... ulen 33 Apr 6 18:21:46 debian kernel: [522752.090065] UDP: bad checksum. From 79.44.213.169:65535 to ... ulen 33 Apr 6 18:21:46 debian kernel: [522752.543712] UDP: bad checksum. From 79.44.213.169:65535 to ... ulen 33 Apr 6 18:21:46 debian kernel: [522752.572293] UDP: bad checksum. From 79.44.213.169:65535 to ... ulen 33 Apr 6 18:21:46 debian kernel: [522752.574443] UDP: bad checksum. From 79.44.213.169:65535 to ... ulen 33
-
What kind of NIC are you using?
-
System / Advanced / Networking > Network Interfaces
Several types of checksum offloading can be turned off there. You might want to give that a try, some packages and configurations don't work well with checksum offloading even if using a well supported NIC.
Checking this option will disable hardware checksum offloading.
Checksum offloading is broken in some hardware, particularly some Realtek cards. Rarely, drivers may have problems with checksum offloading and some specific NICs. This will take effect after a machine reboot or re-configure of each interface.That said if the problem doesn't lie there and you are using Intel NICs and don't have a reason to turn those off, then leave them on as they will save you CPU cycles.
-
I am using an Intel NIC.
Is there no option just do drop such packages without thinking about it? As far as I know they are used to kill some game servers.
-
If the packets had a bad checksum when they reached pfSense, they would already be blocked/dropped. It would appear they are being corrupted at or just before they reach the Linux system.
-
Hum interesting, but why does the package reach my client if you say pfsense drops them?
-
How do you know it's corrupt when it enters the firewall?
The usual answer is: It's being corrupted at or just before the linux box (e.g. bad cable, switchport, etc)
-
How do you know it's corrupt when it enters the firewall?
In fact, it probably isn't. Ethernet frames have a checksum, as do IPv4 packets as well as TCP. UDP often has a CRC on IPv4 and always on IPv6, so there are many checks along the way to stop a damaged packet from being passed by a switch or router. So, you have to determine at what layer it's corrupt. Only UDP or TCP content that's been corrupted at source is likely to make it all the way to your network. Bad IP packets or Ethernet frames are likely to be dropped enroute. Also, if it's the Ethernet frame that's corrupt, the problem can only be at your end, as Ethernet frame are created & discarded on every hop. As for corrupted at the UDP level, is it only one source that they're coming from?
-
How do you know it's corrupt when it enters the firewall?
I assume it. How I said before it is a known attack for the game server to cause a crash with such defect packages.
They are iterating about all instances of my server (about 10). So I can say that is no normal client and I want to drop these packages.I think the topic is misleading. It is just about how to drop packages to a specific destination which are not valid.
As for corrupted at the UDP level, is it only one source that they're coming from?
They are coming from different IPs. They are iterating over the ports to hit every running instance.
Apr 9 22:40:18 debian kernel: [797866.671229] UDP: bad checksum. From sameattackerip:65535 to myserverip:11116 ulen 33 Apr 9 22:40:22 debian kernel: [797870.598135] UDP: bad checksum. From sameattackerip:65535 to myserverip:11115 ulen 33 Apr 9 22:40:24 debian kernel: [797872.684341] UDP: bad checksum. From sameattackerip:65535 to myserverip:11122 ulen 33 Apr 9 22:40:24 debian kernel: [797872.686461] UDP: bad checksum. From sameattackerip:65535 to myserverip:11121 ulen 33 Apr 9 22:40:24 debian kernel: [797872.704227] UDP: bad checksum. From sameattackerip:65535 to myserverip:11119 ulen 33 Apr 9 22:51:05 debian kernel: [798514.350548] UDP: bad checksum. From sameattackerip:65535 to myserverip:11117 ulen 33 Apr 9 22:51:05 debian kernel: [798514.575728] UDP: bad checksum. From sameattackerip:65535 to myserverip:11120 ulen 33 Apr 9 22:51:46 debian kernel: [798555.452463] UDP: bad checksum. From sameattackerip:65535 to myserverip:11116 ulen 33 Apr 9 22:51:50 debian kernel: [798559.479862] UDP: bad checksum. From sameattackerip:65535 to myserverip:11115 ulen 33 Apr 9 22:51:52 debian kernel: [798561.488506] UDP: bad checksum. From sameattackerip:65535 to myserverip:11122 ulen 33 Apr 9 22:51:52 debian kernel: [798561.490455] UDP: bad checksum. From sameattackerip:65535 to myserverip:11121 ulen 33 Apr 9 22:51:52 debian kernel: [798561.490509] UDP: bad checksum. From sameattackerip:65535 to myserverip:11119 ulen 33
-
They are iterating about all instances of the server (about 10 servers) from the same ip.
So I can say that is no normal client and I want to drop these packages.They are coming from different IPs. They are iterating over the ports to hit every running instance.
This is a little confusing, what is coming from one IP and what is coming from multiple IPs?
Either way, if it's one type of attack then implement suricata and write a custom rule that searches for that type of attack and drops the packet.
If you post a packet capture or something of the traffic you are having trouble with then I'm sure the community can help you write a rule or two to drop it.
Also, it looks like you are trying to keep the IP of your attacker private in the post above? Don't protect a known attacker, if they are attacking you then publicize their IP. That could also be useful information in helping you defeat the attack.
