IPB

Здравствуйте, гость ( Вход | Регистрация )

 
Ответить в эту темуОткрыть новую тему
> SYN,ACK SYN,ACK REJECT
coolman
сообщение 24.10.2010, 17:38
Сообщение #1





Группа: Пользователи
Регистрация: 20.2.2006
Пользователь №: 9 465



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

По теме, а что если злоумышленник как раз и рассчитывает, что мы будем отвечать режектом на син аск, и будет ими нас заваливать, тем самым опять же мы косвенно способствуем злоумышленнику в атаке на хост жертвы, или я не прав, поправьте.
Я кстати все старющие правила с участием state и т.п перевел на conntrack unsure.gif , правильно ведь сделал, на нагрузку же не влияет?
вот например:
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
сообщение 25.10.2010, 09:37
Сообщение #2





Группа: Пользователи
Регистрация: 2.12.2007
Из: Переехал в Первоуральск
Пользователь №: 30 323



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

С какой целью, что это ему даст?
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
coolman
сообщение 25.10.2010, 13:47
Сообщение #3





Группа: Пользователи
Регистрация: 20.2.2006
Пользователь №: 9 465



Цитата(slime666 @ 25.10.2010, 10:37) *
С какой целью, что это ему даст?

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

Сообщение отредактировал coolman - 25.10.2010, 13:49
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
blazed
сообщение 25.10.2010, 16:55
Сообщение #4





Группа: Пользователи
Регистрация: 24.2.2009
Пользователь №: 40 392



Цитата(slime666 @ 25.10.2010, 10:37) *
С какой целью, что это ему даст?

Если цель DDoS атака на A-хост, то она примерно на 50% тяжелее получится.
Т.к. помимо входящего SYN и исходящего SYN/ASK добавятся еще и входящие RST пакеты.
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
coolman
сообщение 25.10.2010, 18:59
Сообщение #5





Группа: Пользователи
Регистрация: 20.2.2006
Пользователь №: 9 465



Цитата(blazed @ 25.10.2010, 17:55) *
Если цель DDoS атака на A-хост, то она примерно на 50% тяжелее получится.
Т.к. помимо входящего SYN и исходящего SYN/ASK добавятся еще и входящие RST пакеты.

Тоесть получается, что всетаки я прав и не всегда SYN,ACK SYN,ACK REJECT хорошая вещь?
Опять же если не REJECTить, то может попасть в черные списки атакующих, хм дилемма.
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
blazed
сообщение 25.10.2010, 21:04
Сообщение #6





Группа: Пользователи
Регистрация: 24.2.2009
Пользователь №: 40 392



Цитата(coolman @ 25.10.2010, 19:59) *
Тоесть получается, что всетаки я прав и не всегда SYN,ACK SYN,ACK REJECT хорошая вещь?

Ога, не всегда.
Цитата(coolman @ 25.10.2010, 19:59) *
Опять же если не REJECTить, то может попасть в черные списки атакующих, хм дилемма.

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





Группа: Пользователи
Регистрация: 20.2.2006
Пользователь №: 9 465



Цитата(blazed @ 25.10.2010, 22:04) *
Ога, не всегда.
В начальном топике необходимость посылать RST обусловлена вероятностью атаки типа Sequence Number Prediction.

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

ко мне за день штук по 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
сообщение 26.10.2010, 00:37
Сообщение #8





Группа: Пользователи
Регистрация: 24.2.2009
Пользователь №: 40 392



Цитата(coolman @ 25.10.2010, 23:17) *
ваши рекомендации? flower.gif
ко мне за день штук по 15 приходят таких:

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

Цитата(coolman @ 25.10.2010, 23:17) *
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
сообщение 26.10.2010, 13:28
Сообщение #9





Группа: Пользователи
Регистрация: 20.2.2006
Пользователь №: 9 465



Цитата(blazed @ 26.10.2010, 01:37) *
Конечно забить, зачем тратить ресурсы системы на ненужные вам действия.
Я надежнее проверочку рекомендовал бы.
Инвалидов сразу всех дропаем
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 и указанное выше мое правило подхватилось smile.gif

Сообщение отредактировал coolman - 26.10.2010, 13:33
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
blazed
сообщение 26.10.2010, 19:02
Сообщение #10





Группа: Пользователи
Регистрация: 24.2.2009
Пользователь №: 40 392



Цитата(coolman @ 26.10.2010, 14:28) *
кстати может всетаки вот так:
iptables -A evil -p tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j DROP
ибо у меня ни где в правилах нету, что бы модуль tcp нужно было подгружать, у меня iptables 1.4.9.1 и указанное выше мое правило подхватилось smile.gif

Модуль tcp прописывать не обязательно, он для данного правила он необходим, так что пропишется сам,
можешь посмотреть командой iptables-save во что iptables преобразует данное правило.
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
coolman
сообщение 8.11.2010, 02:28
Сообщение #11





Группа: Пользователи
Регистрация: 20.2.2006
Пользователь №: 9 465



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

Сообщение отредактировал coolman - 8.11.2010, 12:51
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
blazed
сообщение 8.11.2010, 10:20
Сообщение #12





Группа: Пользователи
Регистрация: 24.2.2009
Пользователь №: 40 392



Цитата(coolman @ 8.11.2010, 02:28) *
короче, что он сначала проверяет, выставленные флаги или например проверку на син флуд,

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

Цитата(coolman @ 8.11.2010, 02:28) *
что начала сделать в правилах?

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

Сообщение отредактировал blazed - 8.11.2010, 10:28
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
coolman
сообщение 8.11.2010, 12:49
Сообщение #13





Группа: Пользователи
Регистрация: 20.2.2006
Пользователь №: 9 465



извините , уже спал, не правильно выразился, я хотел узнать, что вперед поставить: проверку на скорость поступления новых пакетов или проверку их флагов?
тесть например это вперед:
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), потом идет проверка на плохие пакеты(ну тоесть некорректно выставленные флаги), потом идет проверка на скорость поступления новых син пакетов, и только потом уже остальные правила.

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

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

Сообщение отредактировал coolman - 8.11.2010, 13:34
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
blazed
сообщение 8.11.2010, 17:26
Сообщение #14





Группа: Пользователи
Регистрация: 24.2.2009
Пользователь №: 40 392



Цитата(coolman @ 8.11.2010, 12:49) *
извините , уже спал, не правильно выразился, я хотел узнать, что вперед поставить: проверку на скорость поступления новых пакетов или проверку их флагов?

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

Цитата(coolman @ 8.11.2010, 12:49) *
И еще вопрос smile.gif стоит ли OUTPUT проверять на плохие флаги? Логически нет, но может я чего-то не знаю?

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

Цитата(coolman @ 8.11.2010, 12:49) *
и еще , кто мне может сказать, в чем отличие этих двух команд, вроде обе за таймают 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
сообщение 8.11.2010, 21:12
Сообщение #15





Группа: Пользователи
Регистрация: 20.2.2006
Пользователь №: 9 465



Цитата(blazed @ 8.11.2010, 18:26) *
tcp_fin_timeout

ip_conntrack_tcp_timeout_fin_wait

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

Цитата(blazed @ 8.11.2010, 18:26) *
Для начала поставить логирование

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

Сообщение отредактировал coolman - 8.11.2010, 21:15
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
blazed
сообщение 8.11.2010, 23:23
Сообщение #16





Группа: Пользователи
Регистрация: 24.2.2009
Пользователь №: 40 392



Цитата(coolman @ 8.11.2010, 21:12) *
так я про это и говор что не понятно, не догоняю что-то я, вроде одно и тоже проделывают, в чем разница?

Вот тут я не уверен, но судя по описанию
ip_conntrack_tcp_timeout_fin_wait это таймауты для переходов с состояния FIN-WAIT-1 на FIN-WAIT-2 и с FIN-WAIT-2 на CLOSING.
А tcp_fin_timeout это время для закрытия сокета находящегося в состоянии FIN-WAIT-2
Цитата(coolman @ 8.11.2010, 21:12) *
может получится, что одно правило перекроет другое, и второе всегда будет после первого срабатывать, если первое что то не запрещает smile.gif

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

Ответить в эту темуОткрыть новую тему
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 



- Текстовая версия Сейчас: 17.7.2018, 14:48
Блог КАБiNET