Помогите с правилом Iptables

читаем маны до посинения, там все написано

Может и ошибаюсь, это значит, что нужно делать REJECT для tcp-пакета, у которого есть флаги SYN и ACK (подтверждение открытия tcp-соединения), при условии, что ранее не было пакета с флагом SYN (окрытие tcp соединение).

Скорее RFC с описанием протокола tcp.

Читаем википедию:

Другой пример:

iptables -I INPUT -m conntrack --ctstate NEW,INVALID -p tcp --tcp-flags SYN,ACK SYN,ACK -j REJECT --reject-with tcp-reset

будет препятствовать спуфингу от нашего имени. Ведь если мы получаем пакет с установленными флагами SYN и ACK (такой комбинацией флагов обладает только ответ на SYN-пакет) по еще не открытому соединению, это означает, что кто-то послал другому хосту SYN-пакет от нашего имени, и ответ пришел к нам. Конечно, злоумышленнику предстоит еще угадать номер последовательности, но лучше не предоставлять ему такого шанса. Согласно приведенному правилу, наш хост ответит RST-пакетом, после получения которого атакуемый хост закроет соединение. Добавление такого правила в конфигурацию фаервола настоятельно рекомендуется, потому что если злоумышленнику удастся осуществить спуфинг-атаку от вашего имени, при расследовании этого инцидента следы приведут к вам.

nnz спасибо теперь всё более менее ясно

А можно ещё более подробно (для тех, кто в танке) нахрена это правило ???

будет препятствовать спуфингу от нашего имени.

Как ? Вот я сейчас ставлю себе на интерфейс IP ЛОР-а и шлю пакеты на google.com. Как установка данного правила на ЛОР-е поможет ему ? У меня сразу интерфейс отвалится ? :-)

предстоит еще угадать номер последовательности

Какой последовательности, зачем угадывать ? Инициатором соединения является он, а не мы (для нас ведь этот пакет имеет статус NEW, а не ESTABLISHED, как было бы, если б инициатором были мы), значит нам надо угадывать, а не ему.

если злоумышленнику удастся осуществить спуфинг-атаку от вашего имени

Если ему это удастся, тогда и ответные пакеты должны долетать до него, что в интернете просто не реально, а в локальной сети будет обнаружимо пропаданием связи между нами и атакуемой тачилой (у неё в ARP таблице для нашего IP будет появляться то наш MAC, то чужой), да и разбираться в локальной сети будет админ, который отвечает за настройку всего, в том числе и нашего хоста.

при расследовании этого инцидента следы приведут к вам

При наличии правила тоже приведут к нам: со стороны будет видно, как мы сначала шлём SYN, а потом отвечаем RST - типа позвонили/постучали к кому-то в дверь и свалили, кто-то открыл дверь - никого. И так постоянно, не думаю что нам это поможет.

>Как ? Вот я сейчас ставлю себе на интерфейс IP ЛОР-а и шлю пакеты на google.com. Как установка данного правила на ЛОР-е поможет ему ?

Лор будет отвечать гуглу RST, и гугл будет закрывать TCP-коннекты.
Прежде всего это осложнит жизнь атакующему, а все остальное — уже следствия этого.

значит нам надо угадывать, а не ему

Пожалуй, да, это было из другой оперы .

тогда и ответные пакеты должны долетать до него, что в интернете просто не реально

Иногда ответные пакеты получать необязательно :)

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

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

мы сначала шлём SYN, а потом отвечаем RST - типа позвонили/постучали к кому-то в дверь и свалили, кто-то открыл дверь - никого

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

Здравствуйте всем !!!

ну так правило ставить на сервер или нет ?

Ну поставь, если не жалко.

Да ну ... ставить то чего не понимаешь. Боком может выйти