forum.opennet.ru - "iptables и хитрый rst установленного tcp соединения" (8)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"iptables и хитрый rst установленного tcp соединения"

Форум Открытые системы на сервере (Firewall, Фильтрация пакетов / Linux)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"iptables и хитрый rst установленного tcp соединения"	+/–
Сообщение от max_tr on 10-Мрт-11, 14:49
Многоуважаемый All, Существует ли возможность отправить "RST" на "destination" по правилу находящемуся в цепочке INPUT (в пакетном фильтре iptables)? Необходимость возникла в связи с ddos, который идентифицируем лишь на стадии установленного соединения (после tcp handshake и порождения со стороны сервиса потомка обслуживающего это соединение). Т.е. по первому же пакету после syn/ack я средствами iptables (-m string --string test) могу распознать, что клиент это bot-машина участвующая в ddos, но если выполню DROP либо REJECT, то со стороны сервиса останется болтаться потомок ожидающий запроса. Понимаю, что существует возможность выполнить REJECT в цепочке OUTPUT, но это "уже поздно" потому как сервису всё-таки придётся выполнить запрос от участника ddos. Кто сталкивался с подобным, подскажите пожалуйста
Ответить \| Правка \| Cообщить модератору

Оглавление

iptables и хитрый rst установленного tcp соединения, PavelR, 17:31 , 10-Мрт-11, (1) +1

iptables и хитрый rst установленного tcp соединения, max_tr, 17:39 , 10-Мрт-11, (2)

iptables и хитрый rst установленного tcp соединения, PavelR, 17:55 , 10-Мрт-11, (4)

iptables и хитрый rst установленного tcp соединения, max_tr, 18:03 , 10-Мрт-11, (5)

iptables и хитрый rst установленного tcp соединения, Andrey Mitrofanov, 17:52 , 10-Мрт-11, (3) +1
iptables и хитрый rst установленного tcp соединения, Anonymous11, 22:40 , 12-Мрт-11, (6)

iptables и хитрый rst установленного tcp соединения, PavelR, 22:44 , 12-Мрт-11, (7)
iptables и хитрый rst установленного tcp соединения, PavelR, 23:16 , 12-Мрт-11, (8)

Сообщения по теме [Сортировка по времени | RSS]

1. "iptables и хитрый rst установленного tcp соединения" +1 +/–

Сообщение от PavelR (??) on 10-Мрт-11, 17:31

>[оверквотинг удален]
> Необходимость возникла в связи с 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 - сравнительно не сложно.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "iptables и хитрый rst установленного tcp соединения" +/–

Сообщение от max_tr on 10-Мрт-11, 17:39

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

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

4. "iptables и хитрый rst установленного tcp соединения" +/–

Сообщение от PavelR (??) on 10-Мрт-11, 17:55

> спасибо за информацию, попробую двинуться в этом направлении
есть еще другое направление. Более костыльное и ресурсоемкое. =)
- маркируем ненужные соединения маркером
- делаем им стандартный -j REJECT --tcp-reset
- делаем cat /proc/net/ip_conntrack, находим там нужные строчки по маркеру, вызываем утилиту сброса соединения, что-то типа отсюда: http://habrahabr.ru/blogs/linux/105441/
-------------
Если сервер - веб, то ставим nginx и выкручиваем на приемлимый минимум его параметр по смыслу который "read_timeout" и не паримся ?

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

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

5. "iptables и хитрый rst установленного tcp соединения" +/–

Сообщение от max_tr on 10-Мрт-11, 18:03

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

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

3. "iptables и хитрый rst установленного tcp соединения" +1 +/–

Сообщение от Andrey Mitrofanov on 10-Мрт-11, 17:52

> Необходимость возникла в связи с ddos, который идентифицируем лишь на стадии установленного
> соединения (после tcp handshake и порождения со стороны сервиса потомка обслуживающего
> это соединение).
Ddos-ят веб-сервер?
Если да, поставить перед апачем или кто там, nginx (он _не форкается на каждое соедиение) и дропать соединения им - по опознаванию ключа в запросе.
if ($uri ~* "test" ) {
return 444;
}
#а уж что прошло - передавать на ~апач
http://sysoev.ru/nginx/docs/http/ngx_http_rewrite_module.htm...

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "iptables и хитрый rst установленного tcp соединения" +/–

Сообщение от Anonymous11 on 12-Мрт-11, 22:40

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "iptables и хитрый rst установленного tcp соединения" +/–

Сообщение от PavelR (??) on 12-Мрт-11, 22:44

>[оверквотинг удален]
>> в цепочке OUTPUT, но это "уже поздно" потому как сервису всё-таки
>> придётся выполнить запрос от участника ddos.
>> Кто сталкивался с подобным, подскажите пожалуйста
> tarpit - модуль к netfilter
> незаслуженно забытое оружие.
> Делает следующее - окно соединения на стороне сервера зануляет и соединение со
> стороны сервера сбрасывает. На клиенте оно продолжает висеть до выпада по
> таймауту.
> После этого уже атакующие компьютеры (виндовые члены ботнета) начинают тормозить.
> Применять с осторожностью!
http://ru.wikipedia.org/wiki/Iptables - офигеннейший ман. Можно ну просто зачитаться. Рекомендую.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "iptables и хитрый rst установленного tcp соединения" +/–

Сообщение от PavelR (??) on 12-Мрт-11, 23:16

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

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "iptables и хитрый rst установленного tcp соединения"	+1 +/–
Сообщение от PavelR (??) on 10-Мрт-11, 17:31
>[оверквотинг удален] > Необходимость возникла в связи с 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 - сравнительно не сложно.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	2. "iptables и хитрый rst установленного tcp соединения"	+/–
	Сообщение от max_tr on 10-Мрт-11, 17:39
	спасибо за информацию, попробую двинуться в этом направлении
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	4. "iptables и хитрый rst установленного tcp соединения"	+/–
	Сообщение от PavelR (??) on 10-Мрт-11, 17:55
	> спасибо за информацию, попробую двинуться в этом направлении есть еще другое направление. Более костыльное и ресурсоемкое. =) - маркируем ненужные соединения маркером - делаем им стандартный -j REJECT --tcp-reset - делаем cat /proc/net/ip_conntrack, находим там нужные строчки по маркеру, вызываем утилиту сброса соединения, что-то типа отсюда: http://habrahabr.ru/blogs/linux/105441/ ------------- Если сервер - веб, то ставим nginx и выкручиваем на приемлимый минимум его параметр по смыслу который "read_timeout" и не паримся ? --- из возможных действий еще возможно применение ACCEPT-фильтров ?
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	5. "iptables и хитрый rst установленного tcp соединения"	+/–
	Сообщение от max_tr on 10-Мрт-11, 18:03
	PavelR, Andrey Mitrofanov большое спасибо за советы, теперь уж точно смогу сдвинуться с мертвой точки в этом вопросе
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору

3. "iptables и хитрый rst установленного tcp соединения"	+1 +/–
Сообщение от Andrey Mitrofanov on 10-Мрт-11, 17:52
> Необходимость возникла в связи с ddos, который идентифицируем лишь на стадии установленного > соединения (после tcp handshake и порождения со стороны сервиса потомка обслуживающего > это соединение). Ddos-ят веб-сервер? Если да, поставить перед апачем или кто там, nginx (он _не форкается на каждое соедиение) и дропать соединения им - по опознаванию ключа в запросе. if ($uri ~* "test" ) { return 444; } #а уж что прошло - передавать на ~апач http://sysoev.ru/nginx/docs/http/ngx_http_rewrite_module.htm...
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору

6. "iptables и хитрый rst установленного tcp соединения"	+/–
Сообщение от Anonymous11 on 12-Мрт-11, 22:40
>[оверквотинг удален] > Необходимость возникла в связи с ddos, который идентифицируем лишь на стадии установленного > соединения (после tcp handshake и порождения со стороны сервиса потомка обслуживающего > это соединение). > Т.е. по первому же пакету после syn/ack я средствами iptables (-m string > --string test) могу распознать, что клиент это bot-машина участвующая в ddos, > но если выполню DROP либо REJECT, то со стороны сервиса останется > болтаться потомок ожидающий запроса. Понимаю, что существует возможность выполнить REJECT > в цепочке OUTPUT, но это "уже поздно" потому как сервису всё-таки > придётся выполнить запрос от участника ddos. > Кто сталкивался с подобным, подскажите пожалуйста tarpit - модуль к netfilter незаслуженно забытое оружие. Делает следующее - окно соединения на стороне сервера зануляет и соединение со стороны сервера сбрасывает. На клиенте оно продолжает висеть до выпада по таймауту. После этого уже атакующие компьютеры (виндовые члены ботнета) начинают тормозить. Применять с осторожностью!
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	7. "iptables и хитрый rst установленного tcp соединения"	+/–
	Сообщение от PavelR (??) on 12-Мрт-11, 22:44
	>[оверквотинг удален] >> в цепочке OUTPUT, но это "уже поздно" потому как сервису всё-таки >> придётся выполнить запрос от участника ddos. >> Кто сталкивался с подобным, подскажите пожалуйста > tarpit - модуль к netfilter > незаслуженно забытое оружие. > Делает следующее - окно соединения на стороне сервера зануляет и соединение со > стороны сервера сбрасывает. На клиенте оно продолжает висеть до выпада по > таймауту. > После этого уже атакующие компьютеры (виндовые члены ботнета) начинают тормозить. > Применять с осторожностью! http://ru.wikipedia.org/wiki/Iptables - офигеннейший ман. Можно ну просто зачитаться. Рекомендую.
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	8. "iptables и хитрый rst установленного tcp соединения"	+/–
	Сообщение от PavelR (??) on 12-Мрт-11, 23:16
	>[оверквотинг удален] >> в цепочке OUTPUT, но это "уже поздно" потому как сервису всё-таки >> придётся выполнить запрос от участника ddos. >> Кто сталкивался с подобным, подскажите пожалуйста > tarpit - модуль к netfilter > незаслуженно забытое оружие. > Делает следующее - окно соединения на стороне сервера зануляет и соединение со > стороны сервера сбрасывает. На клиенте оно продолжает висеть до выпада по > таймауту. > После этого уже атакующие компьютеры (виндовые члены ботнета) начинают тормозить. > Применять с осторожностью! Что-то я не понял, где, применимо к описанной в топике ситуации, будет происходить сброс уже принятого сервером соединения. "соединение со стороны сервера сбрасывает" - имхо это не так. Этого нет ни в типовом описании использования модуля, ни в его коде. Зануление - будет. Но в случае топика - соединение уже будет принято сервером, TARPIT на такие пакеты будет отвечать пакетами с window 0 и всё. (Будет удерживать). Никакого сброса соединения, принятого (веб-?)сервером, не произойдет.
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору