Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет Misha Verbitsky ([info]tiphareth)
@ 2007-06-03 17:00:00


Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Настроение: sick
Музыка:Assemblage 23 - CONTEMPT
Entry tags:fascism, lj, ljr, putin

соображения по технологиям ДОС-атак
[info]ru_nbp@lj закрыт Abuse, а равно и [info]ru_nazbol@lj.
Партийцы, уважаемые, перебрались к нам.

Можно заключать пари, когда LJR настанет пиздец, и
каким именно образом. К счастью, у нас уже есть запасной сервер,
совершенно убийственных достоинств. Но что-то делать надо.

Если у вас есть соображения по технологиям ДОС-атак,
которыми валят LJ, и как с ними бороться, расскажите
пожалуйста.

Привет



(Читать комментарии) - (Добавить комментарий)


[info]tiphareth
2007-06-04 03:19 (ссылка)
>Надо бы посмотреть, как эти атаки живьем выглядят.

А как посмотреть? Я написал Носику, он
говорит " у нас нет доступа к тамошним логам."

>Главное сейчас для тебя, чтобы твой провайдер, если тебя
>начнут атаковать, тебя не прогнал.

Там очень жесткий договор.

>Например, написать ядреный модуль, который не пропускает
>более чем N TCP-коннектов в секунду с одного и того же
>адреса.

Это делается через ip_tables. Более того, в shorewall
есть соответствующая функциональность, которая это
дело гибко конфигурирует, включается за минуту.

Такие дела
Миша

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]pzz
2007-06-04 04:06 (ссылка)
А как посмотреть? Я написал Носику, он
говорит " у нас нет доступа к тамошним логам."


Ну как начнут тебя ломать, так сразу и увидим :-)

Хорошо бы только, чтобы у тебя остался доступ к компутеру в тот момент, когда тебя ломать будут. Мне было бы интересно посмотреть, как эта атака выглядит через сниффер (например, tcpdump). Только мне хочется смотреть на бинарный дамп (tcpdump -w).

Это делается через ip_tables. Более того, в shorewall
есть соответствующая функциональность, которая это
дело гибко конфигурирует, включается за минуту.


Я что-то сомневаюсь, что iptables тебе чем-нибудь помогут, когда тебя начнут долбить запросами с нескольких тысяч разных адресов. Говорят также, iptables заметно тормозят, когда правил много.

Я бы воткнул такой модуль _перед_ iptables, чтобы и-таблесам жизнь тоже облегчить.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]tiphareth
2007-06-04 04:11 (ссылка)
>Я что-то сомневаюсь, что iptables тебе чем-нибудь помогут,
>когда тебя начнут долбить запросами с нескольких тысяч
>разных адресов. Говорят также, iptables заметно тормозят,
>когда правил много.

В новых ядрах можно задать ip_tables
инструкцию "не больше n новых коннектов
за k секунд". Если у тебя уже открыт ssh
на сервер, то это решает проблему доступа,.

Спасибо за идею, конечно, я подумаю еще.

Такие дела
Миша

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]pzz
2007-06-04 04:28 (ссылка)
В новых ядрах можно задать ip_tables
инструкцию "не больше n новых коннектов
за k секунд". Если у тебя уже открыт ssh
на сервер, то это решает проблему доступа,.


Это не то, что тебе нужно. Тебе нужно, "не более n коннектов с одного и того же адреса". Или, "адрес, которого мы обслужили недавно, обслуживается в последнюю очередь".

Только это должно работать с большим количеством ядресов - десятки тысяч. Как я написал в самом начале, до миллионов адресов сделать несложно.

В общем, мое тебе предложение: найди толкового аспиранта-программера, а я им поруковожу удаленно. Потом вместе статью в ACM напишем :-)

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]tiphareth
2007-06-04 04:39 (ссылка)
> "не более n коннектов с одного и того же адреса"

Такое в ip_tables тоже есть. Такое у нас включено в Apache, кстати,
15 коннектов и все.

>Или, "адрес, которого мы обслужили недавно, обслуживается в последнюю очередь".

А такое в линуксах тоже делается, но не через ip_tables,
а через другой модуль. И я не думаю, что это сильно нужно.

>В общем, мое тебе предложение: найди толкового
>аспиранта-программера, а я им поруковожу удаленно.

Спасибо, да. Я буду иметь в виду

Такие дела
Миша

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]pzz
2007-06-06 16:15 (ссылка)
> "не более n коннектов с одного и того же адреса"

Такое в ip_tables тоже есть. Такое у нас включено в Apache, кстати,
15 коннектов и все.


Я посмотрел (по диагонали, если честно). По-моему, все таки нету. Количество запросов в секунду вообще ограничить можно, но это не то, что нужно: DDoS'овские запросы не оставят почти никаких шансов нормальным запросам. Надо ограничивать именно повторяющиеся запросы с одних и тех же адресов. Но при этом понимать, что таких адресов может быть много, десятки тысяч.

Да и где бы нетфильтру хранить history последних запросов? Без такого хранилища очевидно эту фичу не реализуешь. Не в conntrack'е же - он предназначен немного для других целей и вряд ли будет себя вести хорошо, если его забить десятками тысяч плохих адресов.

В апаче же ограничивать число коннектов несколько поздно: пока коннект дойдет до апача, он уже успеет скушать слишком много ресурсов.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]tiphareth
2007-06-06 17:40 (ссылка)
>Я посмотрел (по диагонали, если честно). По-моему, все
>таки нету.

Вот например
http://www.debian-administration.org/articles/187

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent \
--set

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent \
--update --seconds 60 --hitcount 4 -j DROP

The second rule is where the magic actually happens. The
--update flag tests whether the IP address is in the list
of recent connections, in our case each new connection on
port 22 will be in the list because we used the --set flag
to add it in the preceeding rule.

Once that's done the --seconds flag is used to make sure
that the IP address is only going to match if the last
connection was within the timeframe given. The --hitcount
flag works in a similar way - matching only if the given
count of connection attempts is greater than or equal to
the number given.

Together the second line will DROP an incoming connection if:

* The IP address which initiated the connection has
previously been added to the list and
* The IP address has sent a packet in the past 60 seconds and
* The IP address has sent more than 4 packets in total.

Такие дела
Миша

(Ответить) (Уровень выше)


[info]tiphareth
2007-06-06 17:50 (ссылка)
"for systems with more than 1GB of RAM, default CONNTRACK_MAX value is limited to 65536 (but can of course be set to more manually)"

У нас 6 гиг рама, так что это далеко не предел

(Ответить) (Уровень выше)


[info]tiphareth
2007-06-06 17:54 (ссылка)
Нужно в ядро добавить модуль
ipt_recent, CONFIG_IP_NF_MATCH_RECENT=m

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]pzz
2007-06-08 02:49 (ссылка)
Это может и будет работать. Надо попробовать :-)

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]tiphareth
2007-06-08 03:06 (ссылка)
Вот тут много еще полезного в ссылках
http://dbg.livejournal.com/64577.html

(Ответить) (Уровень выше)


(Читать комментарии) -