>вот поэтому я покупаю хостинг in america ;)

Святая простота.
Ты думаешь, там всё иначе?

Извините, но автор полный мудак:

1. Во первых такая конструкция -m string --string сама по себе заметно увеличит время отклика системы, при большой количестве такого дерьма в файрволе система заметно тормозит без видимых причин.

2. Использовать NEW, RELATED, ESTABLISHED на высоконагруженном сервере это бред сивой кобылы, под эти вещи выделяется нехило оперативки + каждое правило должно быть найдено в таблице соединений, еслине найдено совпадений то создано.

3. Аналогично с -m limit --limit 20/sec

4. Аналогично с -m iplimit --iplimit-above 10

5. аФФтар ни слова не сказал о sysctl и conntrack в частности

6. Такие вещи делать с помошью Iptables НЕЛЬЗЯ. Кстати с помошью apache тоже - mod_cguard, mod_evasive mod_limitconn хорошо, но сам процесс apache будет жрать оперативку. ЕДИНСТВЕННЫЙ правильный способ это Nginx front-end к apache с ограничениями limit_conn, limit_rate и пр.

>DDOS - что делать.

Брать бубен и бегать

От наплыва ЛОРовцев, слэшдотовцев одновременно не помогут никакие меры.

А те, кто от серъезных атак защищают не будут статейки для админов локалхоста читать

> Такие вещи делать с помошью Iptables НЕЛЬЗЯ. Кстати с помошью apache тоже - mod_cguard, mod_evasive mod_limitconn

Таки mod_evasive + руки и нормальный фаерволл спасают от несерьезных атак.

Мда. статейка воистину от админа локалхоста и для админов локалхостов.

Если бы кто-нить сходил по ссылке (и вернулся еще и на предыдущую статью), то увидел бы, что анализируется атака среднего уровня на один комп с сайтом.

Т.е. на очень маленький сервер, который нахрен никому не сдался (почти).

>При нормальном DDOS'е не спасёт ;) Вот, например, когда ддосили Ультру, то

что "то"? реальный случай из жизни: датацентр - 3 гигабитных канала, DDoS на один шкафчик 1 гигабит - на шкафчик клиентом куплено 20 мегабит :))) на бордере отрезали азиатчкие блоки и стало сразу всё хорошо :-P

ЛАМЕРСТВО! майкрософтовский файрвол и то лучше опционально и практически чем ваш иптаблетс!

> и grep tcp не нужен

Ага, wc -l хватит.

DDoS, блин. Вот когда нам клали несколько гигабитных аплинков, то был DDoS. Досили один IP на котором сидит 1500 клиентов вирутального хостинга, как на зло клиенты и сайты все жирные до безобразия, т.к. это не совсем public хостинг. Зато начальство сразу заинтересовалось покупкой Cisco Guard + Anomaly Detector, а перед хостингом еще поставили Cisco CSS 11503 и балансили http трафик по 4-м машинам. Хорошо хоть бабло есть, а что делать клиентосу у которого только linux, iptables и nginx...

вот хоть один грамотный высказался. две недели назад один большой провайдер от этого тоже пострадал, потому как фильтровал траффик на себе. :) забили и его ВСЕ каналы.

господа! грамотно настроенный nginx у меня выдерживал 18500 active connections на pentium-d без помощи iptables.

ddos'ы бывают разные :) и cisco guard + ещё что-то очень дорогое может не спасти.

Хостерам невыгодно отключать ДДоСимые хосты. Спустя 15 минут после начала DDoS клиент "попадает" на несколько тысяч долларов США по трафику. Если клиент не в состоянии расплатиться, то будет вынужден расстаться со своими серверами.

> ddos'ы бывают разные :) и cisco guard + ещё что-то очень дорогое может не спасти.

На самом деле это лучшее, что сейчас есть на рынке. Мы на покупку этих железок делали тендер (естественно бабло-то какое), все что нам продемонстрировало большинство интеграторов - полный слив по всем параметрам. Еще есть TippingPoint от 3COM, но стоит он просто очень-очень, а ставить его надо в разрез, т.е. либо по штуке на каждый аплинк, а лучше по два для redundancy - счет уже будет на миллионы долларов. С другой стороны даже для большой сети можно обойтись одним guard'ом и 1-2 anomaly detector'ами, guard просто по bgp заберет и переварит на себя траф который идет на атакуймый хост.

у большинства вендоров вообще нет железок подобного класса.

На самом деле, конечно нужно нахуй сломать этот интернет и построить нормальный.

> На самом деле, конечно нужно нахуй сломать этот интернет и построить нормальный.

А там будет блекджек?

как это OUTPUT на 80-й порт? вход на 80 выход на как-то иной (с которого было инициализировано соединение)

> IT'S RUSSIAN BUSINESS BABY

не надо гнать. никто не будет за те жалкие копейки, что ты платишь, делать хоть что-нибудь, что не оговорено в договоре.

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

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

> HTTP flood — наиболее типичный вид DDOS-атаки, когда атакуемый веб-сервер переполняется запросами к главной странице.

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

>на бордере отрезали азиатчкие блоки и стало сразу всё хорошо

Ну значит вам повезло. А когда струячат отовсюду - что будете резать? С ультрой было именно так.

>1. Во первых такая конструкция -m string --string сама по себе заметно увеличит время отклика системы, при большой количестве такого дерьма в файрволе система заметно тормозит без видимых причин.

Затраты на обработку одного конекта все равно будут заначительно меньше, чем исполнение холостого запроса сервером.

>2. Использовать NEW, RELATED, ESTABLISHED на высоконагруженном сервере это бред сивой кобылы, под эти вещи выделяется нехило оперативки + каждое правило должно быть найдено в таблице соединений, еслине найдено совпадений то создано.

На _любое_ tcp соединение должна быть создана запись в ядре, незавивисимо от того, указано это в фаерволе или нет. И любое соединение, как ни странно, должно хратить свое состояние. Давайте вообще tcp из ядра выкинем - оно так жрет оперативку.

>3. Аналогично с -m limit --limit 20/sec

Аналогично

>4. Аналогично с -m iplimit --iplimit-above 10

Аналогично

>5. аФФтар ни слова не сказал о sysctl и conntrack в частности

Это вы о чем?

>6. Такие вещи делать с помошью Iptables НЕЛЬЗЯ. Кстати с помошью apache тоже - mod_cguard, mod_evasive mod_limitconn хорошо, но сам процесс apache будет жрать оперативку. ЕДИНСТВЕННЫЙ правильный способ это Nginx front-end к apache с ограничениями limit_conn, limit_rate и пр.

Следуя этой логике, файервол вообще не нужен. Зачем? Со всем вполне можно справиться libc и грамотной настрока самих приложений.

>>Прежде всего временно отключите атакуемый IP адрес, лучше всего через ?>>iptables, командой iptables -A FORWARD -p tcp -s <атакуемый IP> --dport >80 -j REJECT

>причем тут таблица FORWARD? разве имеем дело с пакетами проходящими между интерфейсами? >и зачем отвечать REJECT?

Видимо, имеются в виду отдельные роутеры с NAT и DMZ-зоной. В принципе всё правильно, по мне так, ставить во внешнюю сеть ясдро 2.6.xx боязно как-то, в пример, недавно найденные дыры.

>имхо, не стоит скромничать

>iptables -A INPUT -s <атакуемый IP> -j DROP

iptables -N attackers

iptables -A attackers -s <атакуемый IP> -j DROP

ИМХО смысл тот же, но как-то правильнее выглядит

ИМХО, тема ipconntack в статье не раскрыта...

Автор молоцец - суммаризовал что знал. Хоть знал и не много, но уже хорошо. Остальным 'экспертам' читать тут -> http://www.google.com.by/search?hl=en&q=ddos+puzzle+solving&btnG=Goog...

Ключевые слова ddos puzzle solving

А то как дети, говно жедезка вас спасет. Стыдно господа.

http://www.opennet.ru/docs/RUS/iptables/ -
"Максимальное количество записей, которое может содержаться в таблице зависит от значения по-умолчанию, которое может быть установлено вызовом функции ipsysctl в последних версиях ядра. Для объема ОЗУ 128 Мб это значение соответствует 8192 записям, для 256 Мб - 16376. Вы можете посмотреть и изменить это значение установкой переменной /proc/sys/net/ipv4/ip_conntrack_max."

Я правильно понял, что на каждое соединение iptables для отслеживания состояний (state) забирает 16 кбайт оперативки?

это русские клиенты, со своего дедика уберёт сайт который под досом и переносит его на обычный хостинг, зная/предполагая что будут проблемы, но тут уже не он решать их будет :)