Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Форумы портала PHP.SU :: Версия для печати :: CTRL+R / CTRL+F5 - DoS-атака на веб-сервер
Форумы портала PHP.SU » Серверное администрирование » Apache и другие веб-серверы » CTRL+R / CTRL+F5 - DoS-атака на веб-сервер

Страниц (1): [1]
 

1. Klinch - 14 Апреля, 2016 - 23:48:32 - перейти к сообщению
Доброго времени суток!

Имеется веб-сервер (apache+nginx в связке) на Linux Debian 8. Если зайти на веб-сайт, размещенный на этом веб-сервере и зажать комбинацию клавиш CLTR+R / CTRL+F5 (получается флуд обновлением страницы), сервер довольно быстро грузится - процессоры используются на 100%, ОЗУ загружается на 100%.

Уже довольно много статей перечитал, хотя, может не в том направлении ищу...
Я пробовал поставить такие правила iptables:

PHP:
скопировать код в буфер обмена
  1. /sbin/iptables  -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 20 --connlimit-mask 24 -j REJECT --reject-with tcp-reset
  2.  
  3. /sbin/iptables  -A INPUT -p tcp --syn --dport 443 -m connlimit --connlimit-above 20 --connlimit-mask 24 -j REJECT --reject-with tcp-reset


Это помогает от такие программ как, например ioncube loader при атаке с одного адреса. Но в случае с CTRL+R данное правило почему-то оказывается совершенно бессильным.

Прошу помочь подправить правило для его эффективной работы, или хотя-бы подсказать в каком направлении рыть (что искать, что блокировать). Буду очень признателен! Заранее спасибо!
2. Viper - 15 Апреля, 2016 - 01:00:28 - перейти к сообщению
Удаление зубов ядерной ракетой... Оригинально...
Klinch пишет:
на веб-сайт
с этого места подробнее.
3. Klinch - 15 Апреля, 2016 - 10:17:36 - перейти к сообщению
Обычный веб-сайт на Wordpress (+ Woocommerce) с использованием одного из бесплатных шаблонов, доступных для скачивания. На сколько я знаю, Wordpress в стоке не имеет нормального механизма кеширования. Но кеш есть на стороне mysql-сервера, а также используется кеширование средствами nginx.

Вчера с помощью настроек apache ограничил для пользователей сервера:
* Объём используемой оперативной памяти
* Количество процессов
* Процессорное время
* Кол-во одновременных соединений на сессию с одного IP
* Количество обработчиков Apache для домена

Это немного дало результаты, теперь хотя-бы ОЗУ не забивается так сильно, да и к процессору задач идёт поменьше. Но ядра процессоров загружены на 100% и всё же атака ощутима для сервера.


Хотелось бы лучших результатов, а это, наверное, даст только firewall? Или же надо покупать нормальный роутер и ставить его перед сервером, который будет заниматься фильтрацией таких атак?
4. skiphog - 15 Апреля, 2016 - 12:36:51 - перейти к сообщению
http://4debian[dot]info/article/page[dot][dot][dot]stall-configure/
5. Viper - 15 Апреля, 2016 - 14:08:54 - перейти к сообщению
Klinch пишет:
Хотелось бы лучших результатов, а это, наверное, даст только firewall? Или же надо покупать нормальный роутер и ставить его перед сервером, который будет заниматься фильтрацией таких атак?
за предсказаниями к гадалкам. Нет информации о конфигурации сети - нет и ответа.
6. Klinch - 15 Апреля, 2016 - 14:42:26 - перейти к сообщению
skiphog
Спасибо! Полезная штука с понятной документацией, буду разбираться и может что получиться)

Viper
В данный момент, от коммутатора интернет-провайдера (который подключен по оптоволокну) идёт витая пара к моему L1 Хабу, от него идут витые пары к серверам.

Подключение выполняется по статике, на белых IP. т.е. на сетевые интерфейсы серверов просто вешаются IP из блока, выдаваемого провайдером и сервер получает доступ к сети.

Понимаю, что по уму вместо L1 Хаба там должен стоять нормальный управляемый роутер, но пока-что нам это не обязательно, да и средств на его покупку нет (покупать дешевое г*вно не хотим). Однако, если это необходимо для более-менее нормальной защиты от DoS-атак, мы будем собирать средства на покупку роутера. Но хотелось бы пока обойтись каким-нибудь более простым временным решением.

Спасибо!
7. Viper - 15 Апреля, 2016 - 15:16:18 - перейти к сообщению
Klinch пишет:
Однако, если это необходимо для более-менее нормальной защиты от DoS-атак, мы будем собирать средства на покупку роутера.
тут зависит от бюджета. Дешево и сердито софтварным вариантом, хотя это не спасет от "забития" канала.
8. Klinch - 15 Апреля, 2016 - 15:44:47 - перейти к сообщению
Viper
Забитие канала, к сожалению, нам пока вряд-ли грозит Улыбка
А вот такие "школьные" атаки бывают... и у меня пока совсем нет опыта по отражению атак.

Поэтому, лучше пока софтварным вариантом. Здесь, я так понимаю, поможет вариант от skiphog?

Меня интересует, почему тут не срабатывает
CODE (htmlphp):
скопировать код в буфер обмена
  1. /sbin/iptables  -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 20 --connlimit-mask 24 -j REJECT --reject-with tcp-reset

?

Предположу, что потому, что это правило сбрасывает соединение, когда их слишком много. А в случае с CTRL+R соединений не так много и правило не работает. А нагрузка высокая просто потому, что Wordpress требователен к ресурсам?
9. Viper - 15 Апреля, 2016 - 20:44:51 - перейти к сообщению
Klinch пишет:
Предположу, что потому, что это правило сбрасывает соединение, когда их слишком много. А в случае с CTRL+R соединений не так много и правило не работает.
те же яйца только в профиль.
Klinch пишет:
что Wordpress требователен к ресурсам
без комментариев Улыбка Кеширование вам может помочь.
10. Klinch - 17 Апреля, 2016 - 17:58:36 - перейти к сообщению
Viper пишет:
без комментариев Улыбка Кеширование вам может помочь.


Поставил плагин WP Super Cache, настроил. Теперь и сайт быстрее работает, и нагрузки от этого гораздо меньше.
Тем не менее, всё равно буду пытаться сделать защиту от такого флуда, ибо кеш - это костыль, а не реальное решение
11. Viper - 17 Апреля, 2016 - 18:07:00 - перейти к сообщению
Klinch пишет:
ибо кеш - это костыль
вы не правы. Просто в вашем случае нужно ещё и фаервол настроить.
12. Klinch - 18 Апреля, 2016 - 02:57:40 - перейти к сообщению
Да, неправильно выразился - конкретно в моём случае он костыль Улыбка

Дело в том, что на сервере крутятся, скажем так, клиентские приложения. Владельцы этих приложений периодически вносят изменения в свои веб-сайты, а также время от времени владельцы приложений меняются, появляются новые, уходят старые. Каждый городит у себя то, что ему хочется - в основном это Wordpress. Поэтому, каждый раз объяснять и принуждать каждого владельца к установке кеша на вордпресс - не вариант...

Нашел в интернете несколько интересных статей по настройке фаерволла, на днях попытаюсь что-нибудь соорудить и если получится, напишу сюда - будет полезно, ибо реально рабочих подобных инструкций для новичков я не нашел

 

Powered by ExBB FM 1.0 RC1