Назад | Перейти на главную страницу

Несколько DDOS-атак в день

У меня есть популярный технический веб-сайт, и в течение нескольких недель мой сайт подвергался DDOS-атакам. Приступы случаются в случайное время и часто около 10 раз в день. Обычно приступы длятся всего несколько минут, затем прекращаются.

Когда мой сайт подвергается атаке, он становится недоступным. Нагрузка на сервер не увеличивается, сервисы вроде MySQL, Nginx и FPM не пострадали. Похоже, это SYN-атака или что-то подобное.

Я запускаю CentOS 5.6 (64 бит) на мощной машине. Я уже пытался немного усилить SYSCTL, мои настройки можно найти ниже. Кроме того, я установил iptables для блокировки всех портов, кроме тех, которые мне нужны. Этот сценарий также можно найти ниже.

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

Я готов попробовать все.

НАСТРОЙКИ SYSCTL

net.ipv4.ip_forward                         = 0
net.ipv4.conf.default.rp_filter             = 1
net.ipv4.conf.default.accept_source_route   = 0
kernel.sysrq                                = 1
kernel.core_uses_pid                        = 1
net.ipv4.tcp_syncookies                     = 1
kernel.msgmnb                               = 65536
kernel.msgmax                               = 65536
kernel.shmmax                               = 68719476736
kernel.shmall                               = 4294967296
net.ipv4.conf.all.send_redirects            = 0
net.ipv4.conf.default.send_redirects        = 0
net.ipv4.tcp_max_syn_backlog                = 2048
net.ipv4.icmp_echo_ignore_broadcasts        = 1
net.ipv4.conf.all.accept_source_route       = 0
net.ipv4.conf.all.accept_redirects          = 0
net.ipv4.conf.all.secure_redirects          = 0
net.ipv4.conf.all.log_martians              = 1
net.ipv4.conf.default.accept_redirects      = 0
net.ipv4.conf.default.secure_redirects      = 0
net.ipv4.icmp_echo_ignore_broadcasts        = 1
net.ipv4.icmp_ignore_bogus_error_responses  = 1
net.ipv4.conf.default.rp_filter             = 1
net.ipv4.tcp_timestamps                     = 0
net.ipv4.conf.all.rp_filter                 = 1
net.ipv4.conf.default.rp_filter             = 1
net.ipv4.conf.eth0.rp_filter                = 1
net.ipv4.conf.lo.rp_filter                  = 1

НАСТРОЙКИ IPTABLES

*filter
:INPUT DROP
:FORWARD DROP
:OUTPUT ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 21 -m state --state NEW -j ACCEPT
-A INPUT -p tcp --dport 22 --syn -m limit --limit 1/m --limit-burst 3 -j ACCEPT
-A INPUT -p tcp --dport 22 --syn -j DROP
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -m state --state NEW -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
COMMIT

График MRTG за последние 24 часа. Пики - это атаки, и тогда сервер становится недоступным.

«Похоже, это SYN-атака» - на каких доказательствах вы это основываете? Заполняется ли ваша таблица conntrack или у вас есть смешное количество неполных записей в выводе netstat? Учитывая, что файлы cookie SYN обычно довольно эффективны, я был бы более склонен думать, что это простая атака с заполнением канала, для которой единственным решением является получение канала большего размера, попросите своего провайдера заблокировать оскорбительный трафик в восходящем направлении (если это просто трафик, такой как атака с отражением DNS) или получите услугу очистки каналов (если это более сложный трафик), либо от вашего восходящего провайдера, либо от стороннего поставщика, такого как Arbor Networks, - потому что брандмауэр на вашем компьютере находится не на той стороне ограниченное сетевое соединение.

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