SYN,ACK SYN,ACK REJECT Опции

[coolman]

что то я не смог ответить в этой теме:
http://forum.telenet.ru/index.php?showtopi...p;#entry4116088
поэтому новое:

По теме, а что если злоумышленник как раз и рассчитывает, что мы будем отвечать режектом на син аск, и будет ими нас заваливать, тем самым опять же мы косвенно способствуем злоумышленнику в атаке на хост жертвы, или я не прав, поправьте.
Я кстати все старющие правила с участием state и т.п перевел на conntrack , правильно ведь сделал, на нагрузку же не влияет?
вот например:
iptables -A evil -m conntrack --ctstate NEW,INVALID -p tcp --tcp-flags SYN,ACK SYN,ACK -j REJECT --reject-with tcp-reset

инвалид тоже режектить?

Сообщение отредактировал coolman - 25.10.2010, 09:34

[slime666]

рассчитывает, что мы будем отвечать режектом на син аск, и будет ими нас заваливать

С какой целью, что это ему даст?

[coolman]

С какой целью, что это ему даст?

Я написал что ему это даст, чисто с теоретической точки зрения рассуждаю, как это дело обстоит на практике я не знаю, я ведь не злоумышленник.
Кстати не только 3 лицо можно закидывать син аск, но и саму жертву, ведь ответные пакеты это тоже трафик(исходящий) и нагрузка для сервера жертвы, хотя в этом случаи скорее всего син пакетами заваливать проще, но син пакеты обычно фильтруют, а вот исходящий трафик или установленные соединения мало кто.

Сообщение отредактировал coolman - 25.10.2010, 13:49

[blazed]

С какой целью, что это ему даст?

Если цель DDoS атака на A-хост, то она примерно на 50% тяжелее получится.
Т.к. помимо входящего SYN и исходящего SYN/ASK добавятся еще и входящие RST пакеты.

[coolman]

Если цель DDoS атака на A-хост, то она примерно на 50% тяжелее получится.
Т.к. помимо входящего SYN и исходящего SYN/ASK добавятся еще и входящие RST пакеты.

Тоесть получается, что всетаки я прав и не всегда SYN,ACK SYN,ACK REJECT хорошая вещь?
Опять же если не REJECTить, то может попасть в черные списки атакующих, хм дилемма.

[blazed]

Тоесть получается, что всетаки я прав и не всегда SYN,ACK SYN,ACK REJECT хорошая вещь?

Ога, не всегда.

Опять же если не REJECTить, то может попасть в черные списки атакующих, хм дилемма.

В начальном топике необходимость посылать RST обусловлена вероятностью атаки типа Sequence Number Prediction.
Для современных реализаций TCP/IP стеков данная атака не актуальна.
Например на линях ядра где-то с 2.0.x приращения Sequence Number случайны, на виндах времязависимые, но вроде как патч для рандомайза имеется и т.д.
А если кто-то не удосужился за несколько лет обновиться или пропатчиться, то сам виноват.

[coolman]

Ога, не всегда.
В начальном топике необходимость посылать RST обусловлена вероятностью атаки типа Sequence Number Prediction.

ваши рекомендации?

ко мне за день штук по 15 приходят таких:
Oct 25 21:28:55 ubuntu kernel: [59609.523961] TCP-REJECT IN=eth0 OUT= MAC=тут мак SRC=173.244.203.236 DST=мои Ip LEN=44 TOS=0x00 PREC=0x20 TTL=46 ID=0 DF PROTO=TCP SPT=80 DPT=47112 WINDOW=5840 RES=0x00 ACK SYN URGP=0
Oct 25 21:28:59 ubuntu kernel: [59613.014484] TCP-REJECT IN=eth0 OUT= MAC=тут мак SRC=173.244.203.236 DST=мои Ip LEN=44 TOS=0x00 PREC=0x20 TTL=46 ID=0 DF PROTO=TCP SPT=80 DPT=47112 WINDOW=5840 RES=0x00 ACK SYN URGP=0
Oct 25 17:30:05 ubuntu kernel: [45279.137509] TCP-REJECT IN=eth0 OUT= MAC=тут мак SRC=74.86.183.209 DST=мои Ip LEN=40 TOS=0x00 PREC=0x20 TTL=97 ID=19057 DF PROTO=TCP SPT=80 DPT=9774 WINDOW=65535 RES=0x00 ACK SYN URGP=0

iptables -A evil -m conntrack --ctstate NEW,INVALID -p tcp --tcp-flags SYN,ACK SYN,ACK -j DROP

и спать спокойно?

Сообщение отредактировал coolman - 25.10.2010, 22:17

[blazed]

ваши рекомендации?
ко мне за день штук по 15 приходят таких:

Конечно забить, зачем тратить ресурсы системы на ненужные вам действия.

iptables -A evil -m conntrack --ctstate NEW,INVALID -p tcp --tcp-flags SYN,ACK SYN,ACK -j DROP
и спать спокойно?

Я надежнее проверочку рекомендовал бы.
Инвалидов сразу всех дропаем
iptables -A INPUT -m state --state INVALID -j DROP
Новые соединения разрешаем только с пакета с установленным SYN и сброшенными FIN, RST, ACK, иначе дропаем (можете, конечно, слать в ответ RST, но лично я не вижу в этом необходимости)
iptables -A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP

[coolman]

Конечно забить, зачем тратить ресурсы системы на ненужные вам действия.
Я надежнее проверочку рекомендовал бы.
Инвалидов сразу всех дропаем
iptables -A INPUT -m state --state INVALID -j DROP
Новые соединения разрешаем только с пакета с установленным SYN и сброшенными FIN, RST, ACK, иначе дропаем (можете, конечно, слать в ответ RST, но лично я не вижу в этом необходимости)
iptables -A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP

ок спасибо, у меня целый батальон из инета собранный подобных правил с участием SYN ACK RST FIN
кстати может всетаки вот так:
iptables -A evil -p tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j DROP
ибо у меня ни где в правилах нету, что бы модуль tcp нужно было подгружать, у меня iptables 1.4.9.1 и указанное выше мое правило подхватилось

Сообщение отредактировал coolman - 26.10.2010, 13:33

[blazed]

кстати может всетаки вот так:
iptables -A evil -p tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j DROP
ибо у меня ни где в правилах нету, что бы модуль tcp нужно было подгружать, у меня iptables 1.4.9.1 и указанное выше мое правило подхватилось

Модуль tcp прописывать не обязательно, он для данного правила он необходим, так что пропишется сам,
можешь посмотреть командой iptables-save во что iptables преобразует данное правило.

[coolman]

раз пошла такая радость, у меня есть еще вопрос:
схема проверки пакета iptables или ядром, Netfilter, не знаю уж как правильно написать, или определение структуры пакета в ядре, короче, что он сначала проверяет, выставленные флаги или например проверку на син флуд(тобишь скорость поступления новых пакетов), что начала сделать в правилах?

Сообщение отредактировал coolman - 8.11.2010, 12:51

[blazed]

короче, что он сначала проверяет, выставленные флаги или например проверку на син флуд,

Что-то я вас недопонимаю.
Как можно сравнивать критерий проверки и проверку?

что начала сделать в правилах?

Мне нравится сначала размещать сначала запрещающие правила, затем разрешающие, и под конец всякие маскарады. Это во благо безопасности.
А уже внутри данных логических блоков, правило которое чаще срабатывает стоит проверять раньше. Это для оптимизации обработки.
PS: Естественно, на достаточно больших объемах трафика стоит еще учитывать и скорость обработки каждого конкретного правила, но для меня это пока что не актуально.

Сообщение отредактировал blazed - 8.11.2010, 10:28

[coolman]

извините , уже спал, не правильно выразился, я хотел узнать, что вперед поставить: проверку на скорость поступления новых пакетов или проверку их флагов?
тесть например это вперед:
iptables -A evil -p tcp --tcp-flags SYN,ACK SYN,ACK -m conntrack --ctstate NEW -j DROP
или это:
iptables -A SYN_FLOOD -m hashlimit --hashlimit-above 3/sec --hashlimit-burst 9 --hashlimit-mode srcip,dstip,dstport --hashlimit-name SYN_FLOOD5 -j DROP
iptables -A SYN_FLOOD -j RETURN
iptables -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j SYN_FLOOD
Вот например у меня сейчас так:

сначала идет тюненг ядра, потом список пользовательских цепочек, потом проверка на баны, потом идет проверка на временные баны(с использованием recent), потом идет проверка на плохие пакеты(ну тоесть некорректно выставленные флаги), потом идет проверка на скорость поступления новых син пакетов, и только потом уже остальные правила.

И еще вопрос стоит ли OUTPUT проверять на плохие флаги? Логически нет, но может я чего-то не знаю?

и еще , кто мне может сказать, в чем отличие этих двух команд, вроде обе за таймают fin пакетов отвечают
echo 30 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_fin_wait
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
только в первом это для отслеживания соединений, а во втором это настройка для ядра, короче я запутался
....кстати походу мы с тобой тут только одни гуру, сидим на горе, размышляем

Сообщение отредактировал coolman - 8.11.2010, 13:34

[blazed]

извините , уже спал, не правильно выразился, я хотел узнать, что вперед поставить: проверку на скорость поступления новых пакетов или проверку их флагов?

Для начала поставить логирование и помониторить несколько дней, наиболее частосрабатываемое правило наверх.

И еще вопрос стоит ли OUTPUT проверять на плохие флаги? Логически нет, но может я чего-то не знаю?

Через цепочку OUTPUT проходят только пакеты сгенерированные непосредственно на самом хосте, так что фильтрация будет срабатывать только если некорректные пакеты идут с твоего хоста.
Такое может быть если тебя, например, захакали и производят атаку с тебя, но тогда атакующий думаю, без проблем обойдет фильтрацию.
Вообщем, не вижу смысла.

и еще , кто мне может сказать, в чем отличие этих двух команд, вроде обе за таймают fin пакетов отвечают
echo 30 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_fin_wait
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout

tcp_fin_timeout
Переменная задает максимальное время пребывания сокета в состоянии FIN-WAIT-2. Используется в тех случаях, когда другая сторона по тем или иным причинам не закрыла соединение со своей стороны. Каждый сокет занимает в памяти порядка 1.5 Кб, что может привести к значительным утечкам памяти в некоторых случаях.
ip_conntrack_tcp_timeout_fin_wait
Переменная содержит время таймаута для состояний FIN-WAIT-1 и FIN-WAIT-2, описанных в RFC 793. Состояние FIN-WAIT-1 устанавливается после того как серверу будет передан FIN-пакет, а состояние FIN-WAIT-2 после получения FIN/ACK-пакета от сервера. Если от сервера FIN-пакет приходит раньше, чем FIN/ACK-пакет (ситуация "одновременного закрытия соединения" прим. перев.), то вместо состояния FIN-WAIT-2 устанавливается состояние CLOSING.

[coolman]

tcp_fin_timeout

ip_conntrack_tcp_timeout_fin_wait

так я про это и говор что не понятно, не догоняю что-то я, вроде одно и тоже проделывают, в чем разница?

Для начала поставить логирование

может получится, что одно правило перекроет другое, и второе всегда будет после первого срабатывать, если первое что то не запрещает

Сообщение отредактировал coolman - 8.11.2010, 21:15

[blazed]

так я про это и говор что не понятно, не догоняю что-то я, вроде одно и тоже проделывают, в чем разница?

Вот тут я не уверен, но судя по описанию
ip_conntrack_tcp_timeout_fin_wait это таймауты для переходов с состояния FIN-WAIT-1 на FIN-WAIT-2 и с FIN-WAIT-2 на CLOSING.
А tcp_fin_timeout это время для закрытия сокета находящегося в состоянии FIN-WAIT-2

может получится, что одно правило перекроет другое, и второе всегда будет после первого срабатывать, если первое что то не запрещает

Поэтому я и написал ранее, что предпочитаю размещать сначала запрещающие, а потом разрешающие.
А сортировать по частоте срабатывания правила, конечно же, среди одинаковых по действию.