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