Атака Флудом По Udp 53 Порт

[vokforever]

Здравствуйте!
Проблема в следующем. Есть небольшой проект, после старта в скайп пришли "доброжелатели" и попросили заплатить, чтобы они не атаковали.
Естественно с преступниками переговоры никто не вел.
По итогу- неделя атак. При которых флуда идет столько, что либо ложится порт, либо сетевухи (проверял на ноутах и на сервере)
Сервер подготовлен, iptables есть, но получается что до них не доходит.

Видел тему http://forum.global-ua.com/index.php?/to...va/?p=4418
Человек там разруливает все тремя провайдерами и одним роутером (бюджетным).
Возможен ли вариант, что при покупке оного, проблемы исчезнут ?

P/S/ Канал 100мбит - можно завести 1Гбит, если поможет. У меня два IP при атаках лежат оба.
Провайдер говорит (могут врать) что у них все хорошо.

Так что это ? у меня интерфейс не держит или провайдер ?
Если нужно могу дать логи атак и скрины трассировок во время.

[n3k0nation]

Данный порт, как и вообще весь UDP траф - должен быть закрыт, если это сервер lineage.
По ссылке написан полный бред безграмотного человека. Хотите защиту от ддоса? - Используйте FLUX DNS. Я уже писал об этом в некоторых темах. (Я подчеркиваю, именно DDoS, а не DoS).
Роутер - на помойку, особенно, если это из домашних длинков или похожей хрени, ибо они даже не тянут хоть мальски большую таблицу роутинга и тупо падают, либо виснут.

[P3iNN]

> UDP
> Атака на конкретный порт

fucking newfags

[vokforever]

Спасибо за ответы!
fast flux dns крутая технология, но стоит она... дороговато
Кусок из iptables по udp 53

iptables -A INPUT -p UDP -m pkttype --pkt-type broadcast -j DROP
iptables -A INPUT -p UDP -m limit --limit 3/s -j ACCEPT
iptables -A INPUT -i eth0 -p udp --sport 53 -j DROP
iptables -A INPUT -i eth0 -p tcp --sport 53 -j DROP
iptables -A INPUT -i eth0 -p udp --dport 53 -j DROP
iptables -A INPUT -i eth0 -p tcp --dport 53 -j DROP

Просто самое противное, что при атаке канал полностью загружен.
Даже пинги на шлюз не уходят.
И выходит что эта фильтрация не работает.
Может быть можно еще как-то закрыть порт 53 ?
Кстати, читал что увеличение шарины канала тоже спасает от udp флуда, стоит ли брать гигабит ?

[moveton]

Мне одному кажется это странным?
Я не помню, когда последний раз релизил фришку, но отчетливо припоминаю, что у меня было закрыто абсолютно все, кроме 2016 TCP. Ну и 3306 открывал чисто для веб-сайта.

[vokforever]

Мне одному кажется это странным?
Я не помню, когда последний раз релизил фришку, но отчетливо припоминаю, что у меня было закрыто абсолютно все, кроме 2016 TCP. Ну и 3306 открывал чисто для веб-сайта.

У меня закрыто всё. Или что-то еще можно добавить или убрать?
Так дело в том, что это не спасает. Канал тухнет. Расширять нужно и будет норм ?

#!/bin/sh
MODPROBE=/sbin/modprobe

# Очищаем правила
iptables -F
iptables -X

# Разрешаем SSH
iptables -A INPUT -i eth0 -p tcp --dport 1443 -j ACCEPT

# Назначение глобальных политик
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP
iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD

# Загружаем модули, погнали:
# Модуль для отслеживания состояния соединений
$MODPROBE nf_conntrack
# Модуль для отслеживания по ipv4, ipv6 пока не используем
$MODPROBE nf_conntrack_ipv4

# Изменение параметров SYSCTL
# Увеличение размера очередей
echo 32000000 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max
# Время ожидания до закрытия соединения
echo 14400 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
# Время ожидания до посылки FIN пакета
echo 60 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_fin_wait
# Время ожидания до посылки FIN пакета
echo 10 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_syn_sent
# Для защиты от syn флуда
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
# Увеличиваем размер backlog очереди
echo 1280 > /proc/sys/net/ipv4/tcp_max_syn_backlog
# Число начальных SYN и SYNACK пересылок для TCP соединения
echo 4 > /proc/sys/net/ipv4/tcp_synack_retries
echo 4 > /proc/sys/net/ipv4/tcp_syn_retries
#Сколько секунд ожидать приема FIN до полного закрытия сокета
echo 10 > /proc/sys/net/ipv4/tcp_fin_timeout
# Как часто посылать сообщение о поддержании keep alive соединения
echo 1800 > /proc/sys/net/ipv4/tcp_keepalive_time
# Сколько пакетов проверки keepalive посылать, прежде чем соединение будет закрыто.
echo 2 > /proc/sys/net/ipv4/tcp_keepalive_probes
# Зaпрещаем TCP window scaling
echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
# Запрещаем selective acknowledgements, RFC2018
echo 0 > /proc/sys/net/ipv4/tcp_sack
# Запрещаем TCP timestamps, RFC1323
echo 0 > /proc/sys/net/ipv4/tcp_timestamps
# Уличиваем размер буфера для приема и отправки данных через сокеты.
echo 1048576 > /proc/sys/net/core/rmem_max
echo 1048576 > /proc/sys/net/core/rmem_default
echo 1048576 > /proc/sys/net/core/wmem_max
echo 1048576 > /proc/sys/net/core/wmem_default
# Через какое время убивать соединеие закрытое на нашей стороне
echo 1 > /proc/sys/net/ipv4/tcp_orphan_retries

# Защита от скана #
# Silently Drop Stealth Scans
# All of the bits are cleared
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
# SYN and FIN are both set
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
# SYN and RST are both set
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
# FIN and RST are both set
iptables -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j DROP
# FIN is the only bit set, without the expected accompanying ACK
iptables -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j DROP
# PSH is the only bit set, without the expected accompanying ACK
iptables -A INPUT -p tcp --tcp-flags ACK,PSH PSH -j DROP
# URG is the only bit set, without the expected accompanying ACK
iptables -A INPUT -p tcp --tcp-flags ACK,URG URG -j DROP

# Уже установленные соединения и соединения, порожденные установленными принимаем
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Блокируем людей, которые постучались на левые порты
iptables -N scan
iptables -A scan -m recent --rcheck --name badscan --seconds 86400 -j DROP
iptables -A scan -m recent --name badscan --remove
iptables -A scan -p tcp -m multiport --dport 139,445 -m recent --name badscan --set -j DROP
iptables -A INPUT -i eth0 -j scan

iptables -A OUTPUT -p icmp --icmp-type timestamp-reply -j DROP

# Разрешаем петлю
iptables -A INPUT -i lo -j ACCEPT

# DNS - АТАКА ПО НИМ:
iptables -A INPUT -p UDP -m pkttype --pkt-type broadcast -j DROP
iptables -A INPUT -p UDP -m limit --limit 3/s -j ACCEPT
iptables -A INPUT -i eth0 -p udp --sport 53 -j DROP
iptables -A INPUT -i eth0 -p tcp --sport 53 -j DROP
iptables -A INPUT -i eth0 -p udp --dport 53 -j DROP
iptables -A INPUT -i eth0 -p tcp --dport 53 -j DROP

# Открываем порты
# FTP
iptables -A INPUT -i eth0 -p tcp --dport 21 -j ACCEPT
# SMTP
iptables -A INPUT -i eth0 -p tcp --dport 25 -j ACCEPT

# HTTP и защита от множественных запросов.
iptables -A INPUT -m conntrack --ctstate NEW -p tcp --dport 80 -m limit --limit 100/sec --limit-burst 100 -j ACCEPT

# Proftpd (порты для пассивного режима)
iptables -A INPUT -i eth0 -p tcp --dport 49152 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 49153 -j ACCEPT
# Мои порты
iptables -A INPUT -i eth0 -p tcp --dport 7777 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 2106 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 5938 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 5939 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 443 -j ACCEPT


# ICMP
iptables -A INPUT -p icmp --icmp-type 8 -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type 8 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type 6 -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type 6 -j ACCEPT

[P3iNN]

Мне одному кажется это странным?
Я не помню, когда последний раз релизил фришку, но отчетливо припоминаю, что у меня было закрыто абсолютно все, кроме 2016 TCP. Ну и 3306 открывал чисто для веб-сайта.

UDP пакет плевать хотел на то, открыт порт или нет. В отличии от ТСР протокола, UDP не имеет "handshake" (рукопожатия) SYN -> ACK и тд. А просто стучится в дверь и забивает канал,так сказать. Это как гопник.



Так что ТС забей на iptables и прочую ересь,бери канал шире + анти ддос прокси

[vokforever]

UDP пакет плевать хотел на то, открыт порт или нет. В отличии от ТСР протокола, UDP не имеет "handshake" (рукопожатия) SYN -> ACK и тд. А просто стучится в дверь и забивает канал,так сказать. Это как гопник.



Так что ТС забей на iptables и прочую ересь,бери канал шире + анти ддос прокси

Спасибо, а какой анти-ддос посоветует ?

[SmileForMe]

vokforever, http://stormwall.pro/

[vokforever]

vokforever, http://stormwall.pro/

А бюджетный вариант ?
Проект небольшой, поэтому и решено было все на своих железках делать , до первых атак...