This is a discussion on syn flood understanding - Networking ; 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 ...
Hi folks Ii've got an understanding problem.
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?
2. More than the kernel's default number of tcp SYN packets
coming in per second ? What is that default?
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
I guess this will affect genuine and spoofed IP attempted
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
Sorry for so many questions, feel free to answer any parts