Многоуважаемый All,

Существует ли возможность отправить "RST" на "destination" по правилу находящемуся в цепочке INPUT (в пакетном фильтре iptables)?

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

Т.е. по первому же пакету после syn/ack я средствами iptables (-m string --string test) могу распознать, что клиент это bot-машина участвующая в ddos, но если выполню DROP либо REJECT, то со стороны сервиса останется болтаться потомок ожидающий запроса. Понимаю, что существует возможность выполнить REJECT в цепочке OUTPUT, но это "уже поздно" потому как сервису всё-таки придётся выполнить запрос от участника ddos.

Кто сталкивался с подобным, подскажите пожалуйста

• iptables и хитрый rst установленного tcp соединения,PavelR, 17:31 , 10-Мрт-11
  • iptables и хитрый rst установленного tcp соединения,max_tr, 17:39 , 10-Мрт-11
    • iptables и хитрый rst установленного tcp соединения,PavelR, 17:55 , 10-Мрт-11
      • iptables и хитрый rst установленного tcp соединения,max_tr, 18:03 , 10-Мрт-11
• iptables и хитрый rst установленного tcp соединения,Andrey Mitrofanov, 17:52 , 10-Мрт-11
• iptables и хитрый rst установленного tcp соединения,Anonymous11, 22:40 , 12-Мрт-11
  • iptables и хитрый rst установленного tcp соединения,PavelR, 22:44 , 12-Мрт-11
  • iptables и хитрый rst установленного tcp соединения,PavelR, 23:16 , 12-Мрт-11

>[оверквотинг удален]
> Необходимость возникла в связи с ddos, который идентифицируем лишь на стадии установленного
> соединения (после tcp handshake и порождения со стороны сервиса потомка обслуживающего
> это соединение).
> Т.е. по первому же пакету после syn/ack я средствами iptables (-m string
> --string test) могу распознать, что клиент это bot-машина участвующая в ddos,
> но если выполню DROP либо REJECT, то со стороны сервиса останется
> болтаться потомок ожидающий запроса. Понимаю, что существует возможность выполнить REJECT
> в цепочке OUTPUT, но это "уже поздно" потому как сервису всё-таки
> придётся выполнить запрос от участника ddos.
> Кто сталкивался с подобным, подскажите пожалуйста

может быть имеет смысл дописать модуль iptables ?

wishlist: http://bugzilla.netfilter.org/show_bug.cgi?id=696 - достаточно свежий :-)

Код модуля - файл /usr/src/linux-source-2.6.32/net/ipv4/netfilter/ipt_REJECT.c, функция send_reset  - сравнительно не сложно.

спасибо за информацию, попробую двинуться в этом направлении

> спасибо за информацию, попробую двинуться в этом направлении

есть еще другое направление. Более костыльное и ресурсоемкое. =)

- маркируем ненужные соединения маркером
- делаем им стандартный -j REJECT --tcp-reset
- делаем cat /proc/net/ip_conntrack, находим там нужные строчки по маркеру, вызываем утилиту сброса соединения, что-то типа отсюда: http://habrahabr.ru/blogs/linux/105441/

-------------

Если сервер - веб, то ставим nginx и выкручиваем на приемлимый минимум его параметр по смыслу который "read_timeout" и не паримся ?

---
из возможных действий еще возможно применение ACCEPT-фильтров ?

PavelR, Andrey Mitrofanov большое спасибо за советы, теперь уж точно смогу сдвинуться с мертвой точки в этом вопросе

> Необходимость возникла в связи с ddos, который идентифицируем лишь на стадии установленного
> соединения (после tcp handshake и порождения со стороны сервиса потомка обслуживающего
> это соединение).

Ddos-ят веб-сервер?

Если да, поставить перед апачем или кто там, nginx (он _не форкается на каждое соедиение) и дропать соединения им - по опознаванию ключа в запросе.

if ($uri ~* "test" ) {
  return 444;
}
#а уж что прошло - передавать на ~апач

http://sysoev.ru/nginx/docs/http/ngx_http_rewrite_module.htm...

>[оверквотинг удален]
> Необходимость возникла в связи с ddos, который идентифицируем лишь на стадии установленного
> соединения (после tcp handshake и порождения со стороны сервиса потомка обслуживающего
> это соединение).
> Т.е. по первому же пакету после syn/ack я средствами iptables (-m string
> --string test) могу распознать, что клиент это bot-машина участвующая в ddos,
> но если выполню DROP либо REJECT, то со стороны сервиса останется
> болтаться потомок ожидающий запроса. Понимаю, что существует возможность выполнить REJECT
> в цепочке OUTPUT, но это "уже поздно" потому как сервису всё-таки
> придётся выполнить запрос от участника ddos.
> Кто сталкивался с подобным, подскажите пожалуйста

tarpit - модуль к netfilter

незаслуженно забытое оружие.
Делает следующее - окно соединения на стороне сервера зануляет и соединение со стороны сервера сбрасывает. На клиенте оно продолжает висеть до выпада по таймауту.
После этого уже атакующие компьютеры (виндовые члены ботнета) начинают тормозить.
Применять с осторожностью!

>[оверквотинг удален]
>> в цепочке OUTPUT, но это "уже поздно" потому как сервису всё-таки
>> придётся выполнить запрос от участника ddos.
>> Кто сталкивался с подобным, подскажите пожалуйста
> tarpit - модуль к netfilter
> незаслуженно забытое оружие.
> Делает следующее - окно соединения на стороне сервера зануляет и соединение со
> стороны сервера сбрасывает. На клиенте оно продолжает висеть до выпада по
> таймауту.
> После этого уже атакующие компьютеры (виндовые члены ботнета) начинают тормозить.
> Применять с осторожностью!

http://ru.wikipedia.org/wiki/Iptables - офигеннейший ман. Можно ну просто зачитаться. Рекомендую.

>[оверквотинг удален]
>> в цепочке OUTPUT, но это "уже поздно" потому как сервису всё-таки
>> придётся выполнить запрос от участника ddos.
>> Кто сталкивался с подобным, подскажите пожалуйста
> tarpit - модуль к netfilter
> незаслуженно забытое оружие.
> Делает следующее - окно соединения на стороне сервера зануляет и соединение со
> стороны сервера сбрасывает. На клиенте оно продолжает висеть до выпада по
> таймауту.
> После этого уже атакующие компьютеры (виндовые члены ботнета) начинают тормозить.
> Применять с осторожностью!

Что-то я не понял, где, применимо к описанной в топике ситуации, будет происходить сброс уже принятого сервером соединения.
"соединение со стороны сервера сбрасывает" - имхо это не так. Этого нет ни в типовом описании использования модуля, ни в его коде. Зануление - будет. Но в случае топика - соединение уже будет принято сервером, TARPIT на такие пакеты будет отвечать пакетами с window 0 и всё. (Будет удерживать). Никакого сброса соединения, принятого (веб-?)сервером, не произойдет.