3.2 Архитектура пак
Для ПАК мною была разработана архитектуру frontend-backend c промежуточным кэшированием. Введение в стандартную архитектуру дополнительного кэширующего сервера позволяет защититься от шквала запросов от frontend'а к backend’у в случае, например, 5-10 тысяч одновременных запросов. Архитектура ПАК на основе кэширующего сервера представлена на рисунке 3.1.
Рисунок 3.1 – Архитектура ПАК на основе кэширующего сервера
После первого запроса страница кэшируется, и теперь (при последующих запросах) схема работы будет выглядеть, как на рисунке 3.2.
Рисунок 3.2 – Работа ПАК на последующих запросах
Таким образом, второй запрос (и каждый последующий) не вызвали обращений к backend’у, а весь нужный контент страниц был отданы из кэша.
Но данная архитектура сама по себе ещё не защищает от DDoS-атак. Представим алгоритм действий, необходимых для настройки ПАК:
Меняем порт backend-сервера на любой отличный от 80 (например 2080).
Устанавливаем Varnish.
Устанавливаем и настраиваем lighttpd.
Ограничиваем количество соединений с одного хоста средствами iptables.
Настраиваем критерии определения вредоносных запросов (DDoS). В нашем случае это не пустой User-agent, клиент запрашивает наш домен и это не четвёртый одновременный запрос.
В случае, когда web-сервер lighttpd получает запрос от клиента и если он удовлетворяет заданным критериям, lighttpd отправляет запрос одному из серверов varnish. Varnish проверяет свой кэш на наличие нужного пользователю контента и отдает его либо из кэша, либо отправляет запрос на backend, если в кэше данного контента нет или он устарел.
Для повышения отказоустойчивости рекомендуется использовать несколько серверов. Описание настройки Varnish и lighttpd представлено в приложениях.
Средствами iptables разрешаем 10 подключений в секунду с одного IP, как показано в листинге 3.1. Этого достаточно для обеспечения корректной работы множества клиентов из корпоративных сетей, использующих один реальный IP из-за NAT-ирования.
iptables -I INPUT 1 -p tcp -m hashlimit --hashlimit-upto 10/sec --hashlimit-burst 10 --hashlimit-mode srcip --hashlimit-name HTTPD_DOS -m tcp --dport 80 -m state --state NEW -j ACCEPT
Листинг 3.1 – Разрешение 10 подключений в секунду с одного IP
Необходимо увеличить количество открытых файлов до 5000: ulimit -n 5000.
Изменяем сетевые настройки в sysctl.conf, как показано в листинге 3.2.
vm.swappiness=10
vm.vfs_cache_pressure=10000
vm.dirty_ratio = 1
vm.dirty_background_ratio = 1
vm.dirty_writeback_centisecs = 250
vm.dirty_expire_centisecs = 3000
kernel.panic = 10
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_sack = 1
net.core.rmem_max = 16777216
net.core.rmem_default = 16777216
net.core.netdev_max_backlog = 262144
net.core.somaxconn = 262144
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2
net.ipv4.netfilter.ip_conntrack_max = 1048576
net.nf_conntrack_max = 1048576
net.ipv4.icmp_echo_ignore_all = 1
net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 15
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 15
net.ipv4.ip_local_port_range= 10000 65000
Листинг 3.2 – Изменение сетевых настроек в sysctl.conf
На рисунке 3.3 представлен график, иллюстрирующий интенсивность (в Мб) запросов к backend-у при запущенном сервере кэширования и при отключённом.
Рисунок 3.3 – График интенсивности запросов к backend-у
Это наглядно подтверждает эффективность разработанной архитектуры в борьбе с DDoS-атаками.
В качестве выводов можно сказать следующее:
система кеширования страниц на отдающем сервере освобождает ощутимое количество ресурсов на backend-е;
значительно уменьшается время ожидания страниц с сайта (ускоряется его работа), т.е. при забивании канала паразитным DDoS-трафиком сайт всё равно будет доступен клиентам;
внедрение разработанного ПАК в готовый проект легче, чем внедрение любого другого решения.