Hey,
Once in a while my servers are getting hit with ( usually spoofed ) attacks, what I've noticed that everytime the packet length they are sending is a certain number.
I temporary drop them to block the attacks ( which works fine, and the ongoing attack doesn't affect the server anymore ), However when I block that packet length, people seem to be stuck
at sending client info. I was thinking that maybe the source engine is using that packet length, however when there was no attack ongoing and people couldn't join it didn't seem like
it was dropping anything. Can you give me a hand?
I'm using iptables to block it on linux Ubuntu 12.04.
Thanks in advance.
If your rule is something like
iptables -A INPUT -p udp --destination-port 27015 -m length --length <length> -j DROP
then you could change it to something like this
iptables -A INPUT -p udp --destination-port 27015 -m length --length <length> -m state --state NEW -j DROP
Although UDP is stateless, iptables will give a UDP packet an ESTABLISHED state if there has been previous communication with that ip and the timeout value hasn't been reached.
[QUOTE=bliptec;44470091]If your rule is something like
iptables -A INPUT -p udp --destination-port 27015 -m length --length <length> -j DROP
then you could change it to something like this
iptables -A INPUT -p udp --destination-port 27015 -m length --length <length> -m state --state NEW -j DROP
Although UDP is stateless, iptables will give a UDP packet an ESTABLISHED state if there has been previous communication with that ip and the timeout value hasn't been reached.[/QUOTE]
Using stateful tracking during a spoofed attack is a terrible idea. The conntrack table will easily overflow.
iptables -t raw -A INPUT -j NOTRACK
iptables -A INPUT -p udp --dport 27015 -m recent --name something --rcheck --rttl -j ACCEPT
iptables -A INPUT -p udp --dport 27015 -m length --length x -m recent --name something --set -j DROP
Haven't run those rules to test syntax but they should be along the right lines. Essentially what it will do is drop the first packet of that length from an IP address, which will retry if not spoofed and is then accepted.
[QUOTE=Flapadar;44471541]Using stateful tracking during a spoofed attack is a terrible idea. The conntrack table will easily overflow.[/QUOTE]
That's definitely a cleaner way to do it since it won't keep track of the destination ip, source port, and destination port for each entry – but won't it still grow at a similar rate? I've never used the recent module to handle such a large amount of IPs. Is there a set limit for how many entries can be handled, or will it just keep creating entries until the machine runs out of RAM?
[QUOTE=bliptec;44472964]That's definitely a cleaner way to do it since it won't keep track of the destination ip, source port, and destination port for each entry – but won't it still grow at a similar rate? I've never used the recent module to handle such a large amount of IPs. Is there a set limit for how many entries can be handled, or will it just keep creating entries until the machine runs out of RAM?[/QUOTE]
You can change the limit but generally it will remember ~100 IP's. Not great for remembering IP's during a spoofed attack, but it should handle it better than stateful tracking.
[QUOTE=Flapadar;44479056]You can change the limit but generally it will remember ~100 IP's. Not great for remembering IP's during a spoofed attack, but it should handle it better than stateful tracking.[/QUOTE]
So wouldn't it be easier for the average guy to just use the state module instead? Conntrack will have a default max value of 65536 connections on systems that have 1gB of RAM or more, and the timeout for an unreplied entry will be 30 seconds (which changes to 180 seconds once the connection becomes established). How is this worse than only remembering 100 IPs with a timeout value of 64 seconds, like what you suggested?
[QUOTE=bliptec;44479517]So wouldn't it be easier for the average guy to just use the state module instead? Conntrack will have a default max value of 65536 connections on systems that have 1gB of RAM or more, and the timeout for an unreplied entry will be 30 seconds (which changes to 180 seconds once the connection becomes established). How is this worse than only remembering 100 IPs with a timeout value of 64 seconds, like what you suggested?[/QUOTE]
Conntrack overflows causes all tracked packets to be lost - this will only cause packets matching the rule to be lost.
E.g. your rules would end up with packet loss to the entire box, mine would just drop some packets with the specific matches set in the rules with an attack of over 2185 packets per second (which is tiny)
Nearly forgot about this topic,
Anyways I tried what you've told me.
I tried to use this: iptables -A INPUT -p udp -m length --length 400:500 -m recent --set -j DROP which blocked the attack perfectly, however some people still were stuck on "Sending client info" when trying to join the server.
Did you add iptables -A INPUT -p udp -m length --length 400:500 -m recent --rcheck --rttl -j ACCEPT above that rule?
[QUOTE=Flapadar;44559938]Did you add iptables -A INPUT -p udp -m length --length 400:500 -m recent --rcheck --rttl -j ACCEPT above that rule?[/QUOTE]
Yes, And people are still getting stuck ( as I said, when there is no attack ongoing, and people are getting stuck, there is no packet drops at all ).
But what about attacks that are not really spoofed but still coming from many ip's ( as in showing up much more than once through that ip, but still from many ip's )?
Would it be stupid or would mess up anything by white-listing only traffic that coming out of 27000-27030 or something with destination port 27015?
[QUOTE=Konth;44564185]Yes, And people are still getting stuck ( as I said, when there is no attack ongoing, and people are getting stuck, there is no packet drops at all ).
But what about attacks that are not really spoofed but still coming from many ip's ( as in showing up much more than once through that ip, but still from many ip's )?
Would it be stupid or would mess up anything by white-listing only traffic that coming out of 27000-27030 or something with destination port 27015?[/QUOTE]
Yes - that could be problematic. The hashlimit module would allow you to let 'sensible' amounts of traffic through per IP
Regarding source ports = > 27015 fairly sure not all client=>server traffic is restricted to those ports, and the attacker could just start using them too?
Sorry, you need to Log In to post a reply to this thread.
