OSDev.org

I have been optimizing the algorithms around the packet filtering code in my OS, and I was thinking about protection schemes that could be easily implemented and have a huge impact on securing network devices further down the line (and itself) from basic flooding and overflow attacks.

I was wonder what you guys thought about this. I have been working on some code that remembers who sent the last ICMP (ping) and at what rate it recieves the next set of pings and raises the drop-rate if the recieve rate is too high, this protects everything down the line from further bombardment and should not be a nusience to admins as it only kicks in when extreme quantities are transmitted over show periods of time. Also, once another ping source is identified, the restrictions get taken away until it happens again. This seems like a basic win-win design to me, what would be the purpose of allowing tens/hundreds of thousands of ping packets from a single source through the network. I can understand a few hundred a second on large networks, but once again, different sources so there are no restrictions.

Any other things like this that could be of use for a network filtering device? I would say that most routers/switches would have basic filtering like this already in the code, but it seems that alot dont utilize these basic protection schemes.

ping floods are imo not that big an issue, as they are stateless things and generate an equal amount of load in both directions. So while they shouldn't occur, you can't really call them dangerous.

Syn floods however are more nasty things that are more worth the time you spend on protecting against that...

IIRC syn floods are dangerous due to inefficient tcp connection buffer schemes implemented in servers. I believe that the server allocates x amount of resources for each potential tcp connection and if a bunch of half-open tcp handshakes happen, then x*n_tcp_syn resources are allocated and if too much gets allocated things begin to crash due to memory starvation. I don't believe that there would be an efficient way to filter out syn floods as it could take 100 packets, or it could take 100,000 pps to cause any damage. I can't set a threshold as if set too low would cause bottlenecking for high-end networks and if set too high does not solve the syn flood issue for low-end networks. Also, if set with a timerless filter, what would happen if someone goes to one site many times? the filter would kick in and drop legit packets. If a timer was implemented, the afore mentioned threshold issue still exists.

DiNS (unmanaged version) wouldn't be affected by this as it does not respond to syn packets, but I think it would be a great idea to have some defense for the weaker network devices that could potentially exist further down the network chain.

also, I just tested my icmp flood filter, and it seems to work great. It only begins filtering once a single source has spewed out over a thousand ping requests, and then it only slows them down a bit, and if things get to rediculous will drop packets (< 1%) to lower network overhead due to pings. (tested with ping -f)

I may be thinking may be a tad simplistic but couldn't you just wait to allocate the resources until after you get a response from a SYN+ACK packet. Thus halving the attackers speed because they have to wait on and respond to a SYN+ACK packet.

i.e.

Normal Syn attack:

A = Attacker
S = Server

A: SYN
S: SYN+ACK
A: SYN
S: SYN+ACK (inc counter of incorrect answers from IP)
Repeat for X amount of times
S: RST+FIN (Filter Address)

What they would have to do:
A: SYN
S: SYN+ACK
A: ACK
S: (Gives space)
Effectively doubling their attack time and giving you more response time. Maybe even giving time to alert network admin of a sudden surge in network activity.

A possible solution is to allow a certain percentage of half-open connections from a certain IP - given the amount of formalisms you can assume that under stress (and bad use of TCP) the amount of half-open connections percent is some 30 percents:

SYN (half-open starts here)
SYN+ACK
ACK (half-open ends here)
DATA (one packet) <-
DATA (one packet) ->
FIN stuff (can't recall the exact closing protocol)
(connection ends here)

only 2 of the 7 intervals belong to half-open connections (between syn and ack)

So if you abort the latest half-open connection when the percentage would get over that 30% (given some slack for when the total count is low), you'd get a fairly decent syn flood filter.

Under normal use, high load the percentage of half-open connections vs open connections would be rather low - most time would be spent on transferring data.
Under normal use, low load, there will be little concurrent connections, so they will stay within the slack space.
Under flood, only half-opens will be present, and once the slack has been used up no more connections are made but rather reused.

The only problem with this scheme is when usage suddenly goes up - when suddenly many connections are made at the same time. If the total connection requests will exceed the current load significantly, there will be some breakage in connection allowance since the half-opens vs full-opens are too large. By evicting newer connection requests, the legitimate ones that did get into the free space will manage to get to a full-open state and up the balance to allow more connections on average, eventually matching the demand.

The advantage is that it will adapt to the actual network load.

But since I conjured this scheme almost out of thin air, therea re probably some holes left. (At least, it won't work against syn+ack floods)

chezzestix wrote:I may be thinking may be a tad simplistic but couldn't you just wait to allocate the resources until after you get a response from a SYN+ACK packet. Thus halving the attackers speed because they have to wait on and respond to a SYN+ACK packet.

i.e.

Normal Syn attack:

A = Attacker
S = Server

A: SYN
S: SYN+ACK
A: SYN
S: SYN+ACK (inc counter of incorrect answers from IP)
Repeat for X amount of times
S: RST+FIN (Filter Address)

What they would have to do:
A: SYN
S: SYN+ACK
A: ACK
S: (Gives space)
Effectively doubling their attack time and giving you more response time. Maybe even giving time to alert network admin of a sudden surge in network activity.

This would be great, if all server OS implementations used the 'wait and then allocate' method, but I guess (wikipedia knowledge) that there are quite a few that allocate resources at the syn stage, thus allowing for overflows and starvation to occur if too many syn's are sent. My OS is in a bridge state where it has no pull on what the server does, only what it receives from the network. The RST+FIN idea is good, but I think dropping the flood packet altogether is a better solution as it will further reduce network overhead by not responding and secondly, I doubt the attacker would not respond appropriately to the FIN command. Basically, I picture the DiNS machine taking the hit (which it can handle as it it dedicated and does not allocate resources for it) and allowing the server an extended, if not indefinite, uptime during a flood attack. Thus (as Combuster said) could give sysadmins precious time to contain the situation and neutralize the issue altogether.

@Combuster, could you give a more elaborate example of implementing a adaptive method using your explanation? I don't quite grasp the 30% bit and how it is calculated. Also, reusing packets is tricky as you have to allocate resources during a flood which is asking for trouble.

Either those are extreme words of wisdom crammed into a blond joke, or you just like posting stupid jokes in non-related threads.

Actually, artificial intelligence going by the name "Spambot" - Combuster