1

I asked somewhere else, and I got this response:

Using DROP turns any type of DDoS attack into a SYN flood, because your server expects ACK responses which it will never get. Even if you can fine tune your tcp timeout options some of the settings are hardcoded into the kernel. A REJECT is very quick and takes tiny bandwidth. For more information Google "drop vs reject".

I researched on what he said and he seems correct, but I just want to make sure.

LanguagesNamedAfterCofee
  • 121
  • 1
  • 4
  • 1
    Whoever said that is an idiot. Dropping SYNs doesn't create a SYN flood attack, because the dropped incoming SYN never reaches the TCP stack, and thus doesn't consume any resources. – womble Jul 28 '12 at 04:13

1 Answers1

6

Using DROP makes him wait for a timeout (the packet is dropped before it reaches your application). You don't send anything back.

Using REJECT you send a RST packet, saying the port is closed.

Using DROP is better for DoS protection, since you don't send anything out. Using REJECT is a "nicer", since someone connecting to you by mistake, knows the port is closed immediately, and does not have to wait for a timeout.

A syn flood is when someone sends alot of syn packets to start alot of connections (fake or not), and you reserve resources for each connection, while there are no real users to use them. Since you use up all your resources, legit users cannot use your service.

mulaz
  • 10,472
  • 1
  • 30
  • 37
  • What about his comment that using DROP turns any type of DDoS into a SYN flood? – LanguagesNamedAfterCofee Jul 28 '12 at 03:27
  • 2
    Well, it's not a 'real' synflood. But you really do only get syn packets. So using REJECT would be a SYN&RST "flood". A real SYN floopd would be, if you reserved resources and waited for the real connection to happen. – mulaz Jul 28 '12 at 03:29
  • Okay, thanks for the info. So in essence the quote in my question is wrong? – LanguagesNamedAfterCofee Jul 28 '12 at 03:31
  • In a "normal" way.. yes. But if you put the DROP in your input chain, and dont allow established connections, and if you then connect to (let's say) 1.2.3.4, you'd send a SYN, 1.2.3.4 would respond with a SYN/ACK, which you would then DROP, causing 1.2.3.4 to wait for an ACK. But that's with you having a (very bad) DROP rule, and 'DoSing' the other guy (very poorly). – mulaz Jul 28 '12 at 03:36
  • ...actually "DoSing" yourself too, since your application would wait for his SYN/ACK too :) – mulaz Jul 28 '12 at 03:38