![]() |
Здравствуйте, гость ( Вход | Регистрация )
![]() ![]() |
![]() |
![]()
Сообщение
#1
|
|
Группа: Пользователи Регистрация: 20.2.2006 Пользователь №: 9 465 ![]() |
что то я не смог ответить в этой теме:
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 |
|
|
![]()
Сообщение
#2
|
|
Группа: Пользователи Регистрация: 2.12.2007 Из: Переехал в Первоуральск Пользователь №: 30 323 ![]() |
Цитата рассчитывает, что мы будем отвечать режектом на син аск, и будет ими нас заваливать С какой целью, что это ему даст? |
|
|
![]()
Сообщение
#3
|
|
Группа: Пользователи Регистрация: 20.2.2006 Пользователь №: 9 465 ![]() |
С какой целью, что это ему даст? Я написал что ему это даст, чисто с теоретической точки зрения рассуждаю, как это дело обстоит на практике я не знаю, я ведь не злоумышленник. Кстати не только 3 лицо можно закидывать син аск, но и саму жертву, ведь ответные пакеты это тоже трафик(исходящий) и нагрузка для сервера жертвы, хотя в этом случаи скорее всего син пакетами заваливать проще, но син пакеты обычно фильтруют, а вот исходящий трафик или установленные соединения мало кто. Сообщение отредактировал coolman - 25.10.2010, 13:49 |
|
|
![]()
Сообщение
#4
|
|
Группа: Пользователи Регистрация: 24.2.2009 Пользователь №: 40 392 ![]() |
|
|
|
![]()
Сообщение
#5
|
|
Группа: Пользователи Регистрация: 20.2.2006 Пользователь №: 9 465 ![]() |
Если цель DDoS атака на A-хост, то она примерно на 50% тяжелее получится. Т.к. помимо входящего SYN и исходящего SYN/ASK добавятся еще и входящие RST пакеты. Тоесть получается, что всетаки я прав и не всегда SYN,ACK SYN,ACK REJECT хорошая вещь? Опять же если не REJECTить, то может попасть в черные списки атакующих, хм дилемма. |
|
|
![]()
Сообщение
#6
|
|
Группа: Пользователи Регистрация: 24.2.2009 Пользователь №: 40 392 ![]() |
Тоесть получается, что всетаки я прав и не всегда SYN,ACK SYN,ACK REJECT хорошая вещь? Ога, не всегда. Опять же если не REJECTить, то может попасть в черные списки атакующих, хм дилемма. В начальном топике необходимость посылать RST обусловлена вероятностью атаки типа Sequence Number Prediction. Для современных реализаций TCP/IP стеков данная атака не актуальна. Например на линях ядра где-то с 2.0.x приращения Sequence Number случайны, на виндах времязависимые, но вроде как патч для рандомайза имеется и т.д. А если кто-то не удосужился за несколько лет обновиться или пропатчиться, то сам виноват. |
|
|
![]()
Сообщение
#7
|
|
Группа: Пользователи Регистрация: 20.2.2006 Пользователь №: 9 465 ![]() |
Ога, не всегда. В начальном топике необходимость посылать 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 |
|
|
![]()
Сообщение
#8
|
|
Группа: Пользователи Регистрация: 24.2.2009 Пользователь №: 40 392 ![]() |
ваши рекомендации? ![]() ко мне за день штук по 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 |
|
|
![]()
Сообщение
#9
|
|
Группа: Пользователи Регистрация: 20.2.2006 Пользователь №: 9 465 ![]() |
Конечно забить, зачем тратить ресурсы системы на ненужные вам действия. Я надежнее проверочку рекомендовал бы. Инвалидов сразу всех дропаем 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 |
|
|
![]()
Сообщение
#10
|
|
Группа: Пользователи Регистрация: 24.2.2009 Пользователь №: 40 392 ![]() |
кстати может всетаки вот так: 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 преобразует данное правило. |
|
|
![]()
Сообщение
#11
|
|
Группа: Пользователи Регистрация: 20.2.2006 Пользователь №: 9 465 ![]() |
раз пошла такая радость, у меня есть еще вопрос:
схема проверки пакета iptables или ядром, Netfilter, не знаю уж как правильно написать, или определение структуры пакета в ядре, короче, что он сначала проверяет, выставленные флаги или например проверку на син флуд(тобишь скорость поступления новых пакетов), что начала сделать в правилах? Сообщение отредактировал coolman - 8.11.2010, 12:51 |
|
|
![]()
Сообщение
#12
|
|
Группа: Пользователи Регистрация: 24.2.2009 Пользователь №: 40 392 ![]() |
короче, что он сначала проверяет, выставленные флаги или например проверку на син флуд, Что-то я вас недопонимаю. Как можно сравнивать критерий проверки и проверку? что начала сделать в правилах? Мне нравится сначала размещать сначала запрещающие правила, затем разрешающие, и под конец всякие маскарады. Это во благо безопасности. А уже внутри данных логических блоков, правило которое чаще срабатывает стоит проверять раньше. Это для оптимизации обработки. PS: Естественно, на достаточно больших объемах трафика стоит еще учитывать и скорость обработки каждого конкретного правила, но для меня это пока что не актуально. Сообщение отредактировал blazed - 8.11.2010, 10:28 |
|
|
![]()
Сообщение
#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), потом идет проверка на плохие пакеты(ну тоесть некорректно выставленные флаги), потом идет проверка на скорость поступления новых син пакетов, и только потом уже остальные правила. И еще вопрос ![]() и еще , кто мне может сказать, в чем отличие этих двух команд, вроде обе за таймают 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 |
|
|
![]()
Сообщение
#14
|
|
Группа: Пользователи Регистрация: 24.2.2009 Пользователь №: 40 392 ![]() |
извините , уже спал, не правильно выразился, я хотел узнать, что вперед поставить: проверку на скорость поступления новых пакетов или проверку их флагов? Для начала поставить логирование и помониторить несколько дней, наиболее частосрабатываемое правило наверх. И еще вопрос ![]() Через цепочку 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. |
|
|
![]()
Сообщение
#15
|
|
Группа: Пользователи Регистрация: 20.2.2006 Пользователь №: 9 465 ![]() |
tcp_fin_timeout ip_conntrack_tcp_timeout_fin_wait так я про это и говор что не понятно, не догоняю что-то я, вроде одно и тоже проделывают, в чем разница? Для начала поставить логирование может получится, что одно правило перекроет другое, и второе всегда будет после первого срабатывать, если первое что то не запрещает ![]() Сообщение отредактировал coolman - 8.11.2010, 21:15 |
|
|
![]()
Сообщение
#16
|
|
Группа: Пользователи Регистрация: 24.2.2009 Пользователь №: 40 392 ![]() |
так я про это и говор что не понятно, не догоняю что-то я, вроде одно и тоже проделывают, в чем разница? Вот тут я не уверен, но судя по описанию ip_conntrack_tcp_timeout_fin_wait это таймауты для переходов с состояния FIN-WAIT-1 на FIN-WAIT-2 и с FIN-WAIT-2 на CLOSING. А tcp_fin_timeout это время для закрытия сокета находящегося в состоянии FIN-WAIT-2 может получится, что одно правило перекроет другое, и второе всегда будет после первого срабатывать, если первое что то не запрещает ![]() Поэтому я и написал ранее, что предпочитаю размещать сначала запрещающие, а потом разрешающие. А сортировать по частоте срабатывания правила, конечно же, среди одинаковых по действию. |
|
|
![]() ![]() |
![]() |
Текстовая версия | Сейчас: 16.2.2019, 18:45 |