Prev: Can't access website from Linux
Next: Console form type input
From: Andy on 8 Nov 2007 13:07
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
From: Robert Harris on 8 Nov 2007 14:30
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
From: Andy on 8 Nov 2007 15:26
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
From: Robert Harris on 8 Nov 2007 16:57
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
 | 
Pages: 1
Prev: Can't access website from Linux
Next: Console form type input