Автор Тема: Оптимальные правила iptables  (Прочитано 13387 раз)

Оффлайн Schum@cheR

  • Участник
  • *
  • Сообщений: 71
    • http://twitter.com/schumachermkua
Re: Оптимальные правила iptables
« Ответ #15 : 30.10.2009 15:55:29 »
connlimit не поможет?
как не странно нет, он слишком слам и syn пакеты он не глушит, а атака происходит именно ними... (((  :'(
http://twitter.com/schumachermkua - Мой Твиттер

Drool

  • Гость
Re: Оптимальные правила iptables
« Ответ #16 : 30.10.2009 17:15:59 »
В sysadmins@ ?

Оффлайн Мню

  • Участник
  • *
  • Сообщений: 45
Re: Оптимальные правила iptables
« Ответ #17 : 30.10.2009 17:30:19 »
connlimit не поможет?
как не странно нет, он слишком слам и syn пакеты он не глушит, а атака происходит именно ними... (((  :'(
Четче нужно описывать задачу.
"Нужно, что бы если с одного ипа приходит син пакетов больше определенного числа за единицу времени, то ....?"
Модуль recent, два списка. С помощью первого отлавливаешь ip с которого приходят syn пакеты чаще, чем тебе хотелось бы и вносиш во второй список. А с попавшими во второй список поступаешь, уже так как тебе хочется. Например глушишь все син пакеты, или вообще даешь бан.

Add: Чуть позже подумалось, если почитать доку, и разобраться со статусом соединения, то модуль connlimit решит задачу со син флуд атакой с определенного ипа, и городить огород с recent не придется.
« Последнее редактирование: 30.10.2009 17:51:25 от Мню »

Оффлайн Schum@cheR

  • Участник
  • *
  • Сообщений: 71
    • http://twitter.com/schumachermkua
Re: Оптимальные правила iptables
« Ответ #18 : 30.10.2009 19:38:50 »
connlimit не поможет?
как не странно нет, он слишком слам и syn пакеты он не глушит, а атака происходит именно ними... (((  :'(
Четче нужно описывать задачу.
"Нужно, что бы если с одного ипа приходит син пакетов больше определенного числа за единицу времени, то ....?"
Модуль recent, два списка. С помощью первого отлавливаешь ip с которого приходят syn пакеты чаще, чем тебе хотелось бы и вносиш во второй список. А с попавшими во второй список поступаешь, уже так как тебе хочется. Например глушишь все син пакеты, или вообще даешь бан.

Add: Чуть позже подумалось, если почитать доку, и разобраться со статусом соединения, то модуль connlimit решит задачу со син флуд атакой с определенного ипа, и городить огород с recent не придется.
в netstat -n есть наводнение такого типа:
Цитировать
tcp        0     38 80.222.225.25:411            212.92.221.111:1941         SYN_RECV 
насколько я почитал в гугле и википедии то это пакет "на запрос установления соединения" а на практике оказалось модуль connlimit глушит только количество уже УСТАНОВЛЕНЫХ соединений, тоесть получаеться что он может только притормозить обработку запроса, но количество "запросов на установление соединения" он не глушит... вопрос как запретить или максимально возможно ограничить прием пакетов с флагом SYN_RECV


В sysadmins@ ?
может это конечно покажеться вам групым но я не могу понять зачем тогда альту нужен форум если практически во всех темах шлют на сисадминс??? Я пришол сюда за получением ответа на свой вопросы, мне нравиться общяться именно тут (на форуме) и я не привык пользоваться мейл рассылками, они мне не нужны...  :-[
http://twitter.com/schumachermkua - Мой Твиттер

Оффлайн Skull

  • Глобальный модератор
  • *****
  • Сообщений: 20 191
    • Домашняя страница
Re: Оптимальные правила iptables
« Ответ #19 : 30.10.2009 19:59:49 »
Я пришол сюда за получением ответа на свой вопросы, мне нравиться общяться именно тут (на форуме) и я не привык пользоваться мейл рассылками, они мне не нужны...  :-[
А здесь сидят такие же пользователи, как вы. Сисадмины привыкли пользоваться рассылками, им форум не нужен. ;)
Андрей Черепанов (cas@)

Оффлайн Мню

  • Участник
  • *
  • Сообщений: 45
Re: Оптимальные правила iptables
« Ответ #20 : 30.10.2009 20:41:29 »
в netstat -n есть наводнение такого типа:
Цитировать
tcp        0     38 80.222.225.25:411            212.92.221.111:1941         SYN_RECV 
насколько я почитал в гугле и википедии то это пакет "на запрос установления соединения"
Не правильно понял. Тут вообще нет речи о пакете, тут есть информация, о состоянии соединения.

Цитировать
а на практике оказалось модуль connlimit глушит только количество уже УСТАНОВЛЕНЫХ соединений, тоесть получаеться что он может только притормозить обработку запроса, но количество "запросов на установление соединения" он не глушит...
Не совсем верно, он не позволит установить новое соединение, то есть "за глушит" новый syn, если уже установлено больше определенного числа соединений.

Цитировать
пакетов с флагом SYN_RECV
Таких пакетов не существует. Точнее у пакетов нет таких флагов.

Цитировать
вопрос как запретить или максимально возможно ограничить прием пакетов с флагом SYN_RECV
Использовать модуль recent и два списка.

Цитировать
Я пришол сюда за получением ответа на свой вопросы, мне нравиться общяться именно тут (на форуме) и я не привык пользоваться мейл рассылками, они мне не нужны...  :-[
Тебе стоит привыкнуть к мысли, что у альта на форуме нет технически грамотных людей.

Оффлайн Schum@cheR

  • Участник
  • *
  • Сообщений: 71
    • http://twitter.com/schumachermkua
Re: Оптимальные правила iptables
« Ответ #21 : 30.10.2009 21:07:09 »
Использовать модуль recent и два списка.
можно поподробней и если не трудно с примером так как я немного не допонял.. :(
http://twitter.com/schumachermkua - Мой Твиттер

Оффлайн Мню

  • Участник
  • *
  • Сообщений: 45
Re: Оптимальные правила iptables
« Ответ #22 : 30.10.2009 21:57:44 »
Использовать модуль recent и два списка.
можно поподробней и если не трудно с примером так как я немного не допонял.. :(
По подробней можно, с примером, нет. Вечер тяпницы тяжелое время, что бы думать.
Суть проста. Новые пакеты со статусом нев и флагом син и нужным тебе условием отправляешь в новую цепочку. Там с обновлением заносишь в первый список, и если в списке записей за единицу времени меньше, чем тебе нужно то разрешаешь.
-m recent --name FLUD_TEST --update --seconds число --hitcount число -j ACCEPT
Оставшееся вносиш в бан лист и посылаешь нафиг.
-m recent --name BAN_LIST --set -j ПОСЛАТЬ_НАФИГ

И в инпут добавляешь
-m recent --name BAN_LIST --update -j ПОСЛАТЬ_НАФИГ

А перед этим правилом в тот же инпут стоит добавить правило фильтрующие пакеты с ACK с ипов входящих в FLUD_TEST и удаляющих их из этого списка.

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

А вообще, сколько я видел люди особо не мудрствуют, а тупо лепят правило limit и все. Да и нфиг это не нужно. Ядро само умеет глушить подобное, или у тебя аппач так роняют?

Потренируйся на пингах, если не заработает, свистни в приват со со своими контактами, вместе поэкспериментируем.
« Последнее редактирование: 30.10.2009 22:02:35 от Мню »

Оффлайн Мню

  • Участник
  • *
  • Сообщений: 45
Re: Оптимальные правила iptables
« Ответ #23 : 31.10.2009 07:34:14 »
connlimit не поможет?
как не странно нет, он слишком слам и syn пакеты он не глушит, а атака происходит именно ними... (((  :'(
Извени, а вот такой вопрос, ты считаешь, что connlimit не поможет, или ты попробовал, а он не помогает.
Я почему спрашиваю, потому что SYN/ACK пакет, котрый отправляет твоя система в ответ на SYN пакет уже имеет state ESTABLISHED, а значит соединение должно быть подсчитано в connlimit.

Оффлайн Schum@cheR

  • Участник
  • *
  • Сообщений: 71
    • http://twitter.com/schumachermkua
Re: Оптимальные правила iptables
« Ответ #24 : 02.11.2009 17:20:32 »

Цитировать
Извени, а вот такой вопрос, ты считаешь, что connlimit не поможет, или ты попробовал, а он не помогает.
я пробовал,он замедляет атаку, но не устраняет, не надо с меня дурочка делать, я не маленький ребёнок чтобы доказывать то чего не пробовал...
Цитировать
Я почему спрашиваю, потому что SYN/ACK пакет, котрый отправляет твоя система в ответ на SYN пакет уже имеет state ESTABLISHED, а значит соединение должно быть подсчитано в connlimit.
я выше кидал пример атаки, не какого там "Естеблишед нет" там есть просто статус SYN_RECV и все пакеты атакуюшего в таком статусе!!!! :(
http://twitter.com/schumachermkua - Мой Твиттер

Оффлайн Мню

  • Участник
  • *
  • Сообщений: 45
Re: Оптимальные правила iptables
« Ответ #25 : 02.11.2009 17:40:05 »
я выше кидал пример атаки, не какого там "Естеблишед нет" там есть просто статус SYN_RECV и все пакеты атакуюшего в таком статусе!!!! :(
Пакетов в таком статусе, нет, и не бывает. Я уже писал тебе об этом.

Оффлайн Schum@cheR

  • Участник
  • *
  • Сообщений: 71
    • http://twitter.com/schumachermkua
Re: Оптимальные правила iptables
« Ответ #26 : 02.11.2009 18:06:38 »
я выше кидал пример атаки, не какого там "Естеблишед нет" там есть просто статус SYN_RECV и все пакеты атакуюшего в таком статусе!!!! :(
Пакетов в таком статусе, нет, и не бывает. Я уже писал тебе об этом.
такое впичатление что netstat врёт=) ???
netstat -n
и там куча таких статусов!!! и обмановать мне нету смысла так как потерпаю от отак ... :(
http://twitter.com/schumachermkua - Мой Твиттер

Оффлайн Мню

  • Участник
  • *
  • Сообщений: 45
Re: Оптимальные правила iptables
« Ответ #27 : 02.11.2009 19:07:58 »
я выше кидал пример атаки, не какого там "Естеблишед нет" там есть просто статус SYN_RECV и все пакеты атакуюшего в таком статусе!!!! :(
Пакетов в таком статусе, нет, и не бывает. Я уже писал тебе об этом.
такое впичатление что netstat врёт=) ???
netstat -n
и там куча таких статусов!!! и обмановать мне нету смысла так как потерпаю от отак ... :(
Он не врет, это ты не понимаешь, что выводит netstat -n.

Покажи, как ты описывал лимит.
« Последнее редактирование: 02.11.2009 19:23:18 от Мню »

Оффлайн AMike

  • alt linux team
  • ***
  • Сообщений: 479
Re: Оптимальные правила iptables
« Ответ #28 : 02.11.2009 19:28:19 »

Тебе стоит привыкнуть к мысли, что у альта на форуме нет технически грамотных людей.

Не верно. Просто не часто заходят.

Оффлайн Schum@cheR

  • Участник
  • *
  • Сообщений: 71
    • http://twitter.com/schumachermkua
Re: Оптимальные правила iptables
« Ответ #29 : 02.11.2009 21:05:39 »
Цитировать
Покажи, как ты описывал лимит.
$IPT -I INPUT -p tcp --syn --dport 80 -i eth1 -m connlimit --connlimit-above 20 -j DROP
$IPT -N syn-flood
$IPT -A INPUT -p tcp --syn -j syn-flood
$IPT -A syn-flood -m limit --limit 1/s --limit-burst 20 -j RETURN
$IPT -A syn-flood -j DROP
http://twitter.com/schumachermkua - Мой Твиттер