TechTalkz.com Logo Ask the Experts!

Go Back   TechTalkz.com Technology & Computer Troubleshooting Forums > Tech Support Archives > Linux & Opensource

syn flood understanding

Linux & Opensource

 
 
Thread Tools Display Modes
Unread 14-11-2007, 01:46 PM   #1
Andy
Guest
 
Posts: n/a
syn flood understanding

Hi folks Ii've got an understanding problem.

# dmesg
yields lots of
"possible SYN flooding on port 25 sending cookies."

Right here goes...


I run qmail and can set the incomming concurrency value e.g.
100 to start up to 100 processes listening on port 25.

Is the syn flood:-
1. More emails trying to make a tcp connection but failing
to find a process to handle the data?

or
2. More than the kernel's default number of tcp SYN packets
coming in per second ? What is that default?

or
3. Assuming that the kernel sends a tcp SYN-ACK immediately
on receiving a SYN packet and assuming that many will be
faked IP's, is the SYN flood report based on the time it
takes to receive the ACK packet from any genuine IP's ?
(Since a SYN-ACK sent to an IP which didn't request one will
be dropped - or is that the purpose of these kernel cookies?)



All of the websites I've found which suggest an iptables
ruleset use the --limit.. as in
# iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j
ACCEPT

I guess this will affect genuine and spoofed IP attempted
connections.

Is there anyway of setting a snesible time for the final ACK
of the tcp handshake? (assuming that a genuine connection
request will respond quickly and a faked IP won't respond at
all)

Sorry for so many questions, feel free to answer any parts
you can.

Thanks

Sponsored Links
 
Unread 14-11-2007, 01:46 PM   #2
Robert Harris
Guest
 
Posts: n/a
Re: syn flood understanding

Andy wrote:
> Hi folks Ii've got an understanding problem.
>
> # dmesg
> yields lots of
> "possible SYN flooding on port 25 sending cookies."
>
> Right here goes...
>
>
> I run qmail and can set the incomming concurrency value e.g. 100 to
> start up to 100 processes listening on port 25.
>
> Is the syn flood:-
> 1. More emails trying to make a tcp connection but failing to find a
> process to handle the data?
>
> or
> 2. More than the kernel's default number of tcp SYN packets coming in
> per second ? What is that default?
>
> or
> 3. Assuming that the kernel sends a tcp SYN-ACK immediately on receiving
> a SYN packet and assuming that many will be faked IP's, is the SYN flood
> report based on the time it takes to receive the ACK packet from any
> genuine IP's ?
> (Since a SYN-ACK sent to an IP which didn't request one will be dropped
> - or is that the purpose of these kernel cookies?)
>
>
>
> All of the websites I've found which suggest an iptables ruleset use the
> --limit.. as in
> # iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT
>
> I guess this will affect genuine and spoofed IP attempted connections.
>
> Is there anyway of setting a snesible time for the final ACK of the tcp
> handshake? (assuming that a genuine connection request will respond
> quickly and a faked IP won't respond at all)
>
> Sorry for so many questions, feel free to answer any parts you can.
>
> Thanks


You get a SYN flood when a "flood" of SYNs, which your kernel presumably
acknowledges with a SYN-ACK, are not followed by ACKs.

The SYN flood will generally come from a faked IP address because the
flooder is not waiting for the SYN-ACK to arrive back so it doesn't
matter to him where the SYN-ACK is sent.

Traditionally (i.e. without SYN cookies) TCP connections have to be kept
half open after receiving the first SYN because that is the way that TCP
connections are established. And there is a limit to how many half open
connections the kernel can maintain at any given time.

If SYN cookies are enabled, then the kernel doesn't track half open
connections at all. Instead it knows from the sequence number in the
following ACK datagram that the ACK very probably follows a SYN and a
SYN-ACK. That way SYN floods are not a problem to it.

Robert
 
Unread 14-11-2007, 01:47 PM   #3
Andy
Guest
 
Posts: n/a
Re: syn flood understanding

Wow, what I rapid and comprehensive answer - thank you.

I guess then since these cookies are obviously enabled in
the kernel and the SYN flood doesn't tie up loads of
potential connections I can stop fretting about my firewall
since the kernel is handling them perfectly well on its own.

thanks again Robert

Robert Harris wrote:
>
> If SYN cookies are enabled, then the kernel doesn't track half open
> connections at all. Instead it knows from the sequence number in the
> following ACK datagram that the ACK very probably follows a SYN and a
> SYN-ACK. That way SYN floods are not a problem to it.
>
> Robert

 
Unread 14-11-2007, 01:47 PM   #4
Robert Harris
Guest
 
Posts: n/a
Re: syn flood understanding

Andy wrote:
> Wow, what I rapid and comprehensive answer - thank you.
>
> I guess then since these cookies are obviously enabled in the kernel and
> the SYN flood doesn't tie up loads of potential connections I can stop
> fretting about my firewall since the kernel is handling them perfectly
> well on its own.


Yes.

>
> thanks again Robert
>
> Robert Harris wrote:
>>
>> If SYN cookies are enabled, then the kernel doesn't track half open
>> connections at all. Instead it knows from the sequence number in the
>> following ACK datagram that the ACK very probably follows a SYN and a
>> SYN-ACK. That way SYN floods are not a problem to it.
>>
>> Robert

 
Unread 12-02-2009, 06:33 AM   #5
Unregistered
Guest
 
Posts: n/a
Re: syn flood understanding

Sponsored Links
I dont think I can handle it, but I believe I can see it if I try. The belief that one is not the same as his father and/or mother is false, though it might be only half of what I say. I met a girl once, she was a BEAR! EARING!

Sponsored Links
 
 

Thread Tools
Display Modes



< Home - Windows Help - MS Office Help - Hardware Support >


New To Site? Need Help?

All times are GMT. The time now is 08:09 PM.


vBulletin, Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © 2005-2016, TechTalkz.com. All Rights Reserved - Privacy Policy
Valid XHTML 1.0 Transitional