Многочисленные DDOS-атаки в день [дубликат]

На этот вопрос уже есть ответ здесь:

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

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

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

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

Я готов попробовать все, что угодно.

SYSCTL SETTINGS

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 SETTINGS

*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 часа. Пики - это атаки, и именно тогда сервер становится недоступным.

MRTG Graph

1
задан 8 August 2011 в 11:03
1 ответ

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

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

2
ответ дан 3 December 2019 в 22:04

Теги

Похожие вопросы