Внимание: прочитайте описание разметки LORCODE

По дефолту всё разрешено?

Ответ

да, разрешено

Это же плохо. Вообще сложно сказать. Кроме дефолта могут сработать правила раньше. Или ты неверно вводишь строчку -string для правила. Я вообще в первый раз слышу, что iptables, без дополнительных ухищрений вот так позволяет фильтровать по имени хоста. Получается на запрос ты ещё и дополнительные запросы к dns отсылаешь?

UDP протокол - это протокол без установки соединения (в отличии от TCP). Если это DDos атака, то это атака на канал связи, и порт, на который она осуществляется (у вас 3366) не играет роли, ибо я полагаю, что у вас нет сервиса на этом порту. Исходя из этого понятно, что через iptables данный пакет не пройдёт (при обычной настройке iptables). А вот до сетевого интерфейса дойдёт, и вы с этим ничего сделать не можете. Т.о. никакие настройки iptables здесь ни при чём, поэтому забейте (ибо более ничего сделать нельзя).

Ответ

Вы, вероятно, определённо правы. На указанном мною порту не работает никакой сервис. Однако в случае, если я дропаю весь входящий трафик на данный порт с помощью iptables, то канал не забивается и всё работает на ура.

Послушайте, эти пакеты и так не проходят через iptables, и если вы написали правило iptables - это ничего не меняет, более того, пакеты всё равно, продолжают идти до сетевого интерфейса. Канал связи, поэтому, забит так же. Или я что-то не то говорю?

Послушайте, эти пакеты и так не проходят через iptables

Почему? На сколько я понимаю все пакеты приходящие с интерфейса отправляются на netfilter (iptables — утилита для конфигуряния netfilter).
Если речь идёт о DDoS атаке то всё что можно сделать со стороны клиента это как можно быстрее и дешевле выбрасывать эти пакеты. В данном случае проще всего видимо фильтровать по порту назначения. Фильтрация по имени исходного хоста или содержимому пакета гораздо дороже (думаю даже дороже чем просто пропускать эти пакеты без фильтрации).

похоже на http://en.wikipedia.org/wiki/Fraggle_attack#Fraggle_Attack

В чём собственно выражается атака? Какие проблемы создают эти пакеты? В каком колличестве они приходят? Какой трафик создают?

Если их достаточно что-бы забить канал (или значительную его часть) то фильтровать их на твоей стороне бесполезно, нужно фильтровать у вышестоящего провайдера (свяжись с ним, они вроде как обычно помогают, ведь им этот трафик тоже нафиг не нужен).
Если канал не забивается, но пакеты всё-же создают какие-то проблемы то решить эти проблемы можно и на твоей стороне. Если речь об исчерпании ресурсов («всё тормозит!111») то дело либо в настройках фаервола, либо в приложении которое получает эти пакеты (если таковое есть).
Неправильно настроенный фаервол может отхавать большое количество ресурсов на обработку даже сравнительно небольшого трафика.

Я так подозреваю, в случае дропа системе не надо отвечать в обратную «Ой-вей, таки этот порт никто не слушает!», ergo, нагрузка на систему и канал всё-таки меньше.

Важной особенностью есть то, что у всех хостов имеется chargen.

Чего? chargen это порт, см. /etc/services, или запускайте tcpdump с опцией -nn, чтобы порты были цифрами.

Вам уже написали, что входящие пакеты будут идти в любом случае и DROP'ая их вы просто исключаете генерируемые ядром исходящие от вас icmp-пакеты. Возможно, что атакующий бот написан так, что при наличии этих icmp port unreachable пакетов начинает генерить меньший трафик и канал свободнее. Ну это посмотрите сами, посчитайте число пакетов с помощью tcpdump с и без ″-j DROP″.

и DROP'ая их вы просто исключаете генерируемые ядром исходящие от вас icmp-пакеты

Дроп не генерирует ответные пакеты, на то он и дроп. Reject генерирует, даже можно выбрать какие :)

Ядро генерирует, если ACCEPT, а порт никто не слушает.

Звиняюсь, читаю через слово после нового года, «исключаете» пропустил :D

cat /etc/services | fgrep chargen
chargen 19/tcp ttytst source
chargen 19/udp ttytst source

iptables -A INPUT -p tcp --sport 19 --dport 3366 -j DROP
iptables -A INPUT -p udp --sport 19 --dport 3366 -j DROP