flood

tcpdump

ну я запустил tcpdump -e, жду следующей аткаи. что-нибудь еще предпринять можно? в ядре вроде стоит защита от син-флуда, но что-то щас у меня аж все повисло пока от сети не отрубился, можно как-нибудь смягчить воздействия? фарволл стоит, причем не пропускате пакеты с тех адресов, откуда флуд. т.е. от пропускат тока с 192.168.0.0/24, а флуд шел с разных ip.

Ну как находить источник атаки я понял, но как можно смягчить воздействие син-флуда? Син-куки стоят, но при аткаке все начинает страшно тормозить...

> Как можно хотя бы узнать мак отправителя?
iptables -A INPUT такие_запросы -j LOG --log-prefix "iptables SYN_flood_attack: "

>причем не пропускате пакеты с тех адресов, откуда флуд. т.е. от пропускат тока с 192.168.0.0/24, а флуд шел с разных ip
Это действительно странно... Точнее странно не то, что шел, а то, что принимался сервером. Может все таки не совсем верно настроены правила или это исключено ?

> аж все повисло
А на какие порты шел ? На сервере висит на них что-нибудь ?
Может он повис от чрезмерного траффика ? Не пробовали собственноручно смоделировать SYN_flood и посмотреть на реакцию сервера ?

NET="192.168.0.0/255.255.255.0"
$IPTABLES -A INPUT -p TCP -i eth0 -s $NET -j bad_tcp_packets

$IPTABLES -A bad_tcp_packets -p tcp --tcp-flags SYN,ACK SYN,ACK \
-m state --state NEW -j REJECT --reject-with tcp-reset
$IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j REJECT --reject-with tcp-re
set
$IPTABLES -A bad_tcp_packets -j tcp_packets

$IPTABLES -A tcp_packets -p tcp --dport 22 -j allowed
................................................................................ ......

$IPTABLES -A allowed -p tcp --syn -j ACCEPT
$IPTABLES -A allowed -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A allowed -p tcp -j REJECT --reject-with tcp-reset

Вот основные правила. Что странно, tcpdump говорит во время
флуда что почти все пакеты дропятся ядром. Ну это не сервер, а
моя тачка, я бы не сказал что она слабовата (p3,100mbps).
Я пинговал себя большими пакетами, особенно не замечалось
а тут прям мышка остановилась. Как показывал tcpdump пакеты
шли с разных адресов и портов на мои разные порты, а у меня открыто
всего 2 порта(22,139) и политика дроп по умолчнанию.
Так а зачем тогда в ядре syn cookies если они не помогают?
Или может это была не син атака, но тогда что?

нада юзать не REJECT а DROP , про DROP пакеты отбрасываются молча , не посылая в ответ ничего .

Да можно использовать DROP, но тогда при скане появляется что все неоткрытые порты filtered, а мне не хочется "светить" фаерволл. А как на счет модуля recent? Он вроде бы для этого, но я не понял как именно его использовать...

как раз то при DROP сканер покажет отсутвие порта а не филтеред , при REJECT он будет филтеред , а значит сканер будет знать о наличии этого порта , при DROP будет тишина в эфире

Посмотрите внимательнее на мои правила. Там не просто REJECT, там tcp-reset. nmap обманывается, и на все порты, которые не пропускаются самим фарволом, пишет closed. Не ну это не обязяательно конечно REJCT мне, а что DROP действительно смягчит атаку? А как настроить модуль recent? Или он подойдет тока для защиты от атак где один source ip?