DDOS

Еще момент, флудят по доменному имени.
по domain.com
потому что убивая DNS на domain.com
www.domain.com - нормально работает

Сайт дёргают только с 92.112.135.235? Пройди grep/awk/cut/sort/uniq по логу, вытащи IP. Если IP мало - забань из iptables, если много - ты ничего не сделаешь, проси помощи провайдера.

Много, с разных регионов

А если на некоторое время воспользоватся этим:

iptables -A INPUT -p tcp --syn --dport 80 -m recent --name suxx --set
iptables -A INPUT -p tcp --syn --dport 80 -m recent --name suxx --update --seconds 300 --hitcount 3 -j DROP

патч-о-матик и валить по стрингу типичные запросы

Да завалить их - нет проблем.
iptables -m limit --limit - даже этим решается.
Но мне нужно отдавать трафик.
За сутки входящего трафика по этим запросам выходит 7-10Гб.
И чтобы трафик был бесплатным мне отдать нужно в 4 раза больше.
Т.е. проблема в том, что отдавая картинку по 404 ошибке, или по стрингу
VPS-у не хватает сокетов.
Вот как решить этот вопрос...

да никак ты его сам не решишь, если есть возможность поставь перед серверов catalyst 65xx с ACE или CCE модулем, ну или на худой конец CSS content switch, там есть возможности защиты от некоторых разновидностей DOS-а.
если возможности нет, пиши аплинку, они это решат, но топорными средствами, так что прохождение нормального трафика может пострадать в некоторой степени.

> А если на некоторое время воспользоватся этим
Попробовать конечно можно, но только не такими простым (приведённым здесь) вариантом этих правил, потому что таблица модуля recent (/proc/net/ipt_recent/*) имеет ограниченный объём, если она меньше кол-ва ломящихся клиентов - новые записи будут вытеснять старые (сам тестил недавно), и правило с DROP не сработает.
Если в правиле с DROP есть --hitcount N, то надо чтоб запись для заданного src IP сохранилась в /proc/net/ipt_recent/suxx как минимум до тех пор, пока этот IP не обратится N раз втечение --seconds T. Если же клиентов много - записи будут вытесняться, и последующие обращения одного и того же IP модуль recent (не найдя в таблице) будет считать как первые, из-за этого --hitcount N не сработает, и клиент не будет запрещён.
Это во-первых, во-вторых, с точки зрения работоспособности сайта (когда правильные клиенты будут иметь возможность нормально с ним работать) нужно учитывать динамику syn пакетов правильных клиентов: если сайт содержит картинки/flash/javascript/css, то при получении клиентом html-страницы сразу последует серия запросов её составляющих (запросы будут идти рывками - много, тишина, много, тишина, ...), что может вызвать срабатывание правила с seconds и hitcount. Поэтому для отлова досеров нужно выставлять время побольше, например, не 3 запроса за 300с, а 30 запросов за 3000с, что усугубляет проблему с вытеснением записей (да и с эффективностью такого firewall-а).

P.S. Поправьте меня, если где-то не прав

> патч-о-матик и валить по стрингу типичные запросы
Обычный DROP по шаблону в HTTP-запросе - по-моему это зло: соединение установлено, а потом в середине начинается DROP пакетов. Да, сам HTTP-запрос до web-сервера не дойдёт, но что будет делать ядро с этим соединением ? Выжидать timeout-ы до закрытия ? А соединений таких будет аццки много.

Когда сам сталкивался с DDoS-ом пробовал блокировать его с помощью ipset, recent и др. Идея была в 2-х словах такая: в первую очередь ограничить приём syn-пакетов на 80 порт до определённого значения (какой смысл их принимать, если мы не в состоянии их обслужить ?), далее использовать модуль recent (теперь мы уже примерно знаем каких размеров задавать таблицы) для определения хороший/плохой клиент. Если плохой - iptables -j SET --add-set bad_client, иначе - --add-set correct_client (правила с DROP или ACCEPT для клиентов этих set-ов должны быть в самом начале (перед limit-ом для syn-пакетов), чтоб после однозначной классификации не проходить проверки recent, string и т.п.)
+ во время отсутствия DDoS-а это наполнит множество correct_client списком "правильных" IP. При DDoS-е у них будет больший шанс достучаться до сервера. (если и они начинают досить - блокируются на время, ipset позволяет создавать такие set-ы - тип iptree)
Это всё позволяет обеспечить работоспособность системы для небольших DDoS-атак, при приличных атаках не поможет ничто, по-любому надо будет обращаться к провайдеру/хостеру (иногда и они не помогают - делают null route на твои IP и сиди жди когда DDoS прекратится).

> чтобы не попасть на денюжку - мне нужно отдавать в 4 раза больше чем принял.
Независимо от типа трафика ? Т.е. можно тупо запустить генератор пакетов, идущих куда попало (например на 1.1.1.1) и всё ?

А можно продробней про генератор?

Да различных генераторов пакетов много, например, http://www.hping.org/

Если я правильно понял Спирита, то он предлагает просто тупо слать пакеты в "черные дыры" Интернета. Но, ИМХО, провадер ваш заметит это и будет зол. Может даже в вашем договоре есть пункт наподобие "учитывается только траффик, инициированный удаленной стороной".

То, что у вас не хватает сокетов, означает, что атакующая сторона не принимает RST пакеты. То есть вам бы закрывать такие соединения чем-то наподобие tcpcutter http://www.lowth.com/cutter/, только он на это не расчитан.

Бредовая идея: режем все с помощью "iptables -m limit", регулярно смотрим логи и список отрытых сокетов. Если сокет вызвал 404 и открыт более 30 секунд, то начинаем "заливать" в него ненужные данные с помощью hping или чего-то подобного... Но это нужно кодить и ещё неизвестно какая нагрузка на сервер и будет ли хватать у него ресуров.

И -m limit вас не особо выручит, ИМХО, будет не хватать записей в conntrack, их нужно будет чистить отдельно.

>да никак ты его сам не решишь, если есть возможность поставь перед серверов catalyst 65xx с ACE или CCE модулем,

лучше ещё один линукс поставь, а на оставшиеся деньги год бухай

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