Защита сайта на vds от атаки ботами

Чтение и понимание файлов журнала Nginx

Вы можете открывать и анализировать файлы журнала, используя стандартные команды, такие как , , , , и т. Д.

Вот пример записи из файла журнала доступа, в котором используется стандартный формат журнала Nginx для объединения:

Давайте разберемся, что означает каждое поле записи:

— — IP-адрес клиента, выполняющего запрос.
— — Пользователь, аутентификацию по HTTP. Если имя пользователя не задано, в этом поле отображается .
— — Время на локальном сервере.
— — тип запроса, путь и протокол.
— — Код ответа сервера.
— — Размер ответа сервера в байтах.
— — URL перехода.
— — Пользовательский агент клиента (веб-браузер).

Используйте команду для просмотра файла журнала в режиме реального времени:

Что такое HAProxy?

HAProxy, или High Availability Proxy, является программным балансировщиком нагрузки TCP/HTTP. Он распределяет рабочую нагрузку по серверам для обеспечения максимальной производительности и оптимизации использования ресурсов. HAProxy поддерживает гибко настраиваемые методы проверки доступности, обработки отказов и восстановления после них.

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

В одном из вариантов настройки HAProxy устанавливается на каждом сервере приложений, выполняющем запросы к базе данных. Такой вариант отлично подходит при наличии нескольких серверов, что позволяет контролировать нагрузку и скрыть организацию кластера СУБД. Приложение подключается к локальному HAProxy (например, устанавив mysql-соединение на 127.0.0.1:3306) и может получить доступ ко всем серверам базы данных. Веб-сервер и HAProxy вместе образуют рабочий блок, поэтому веб-сервер не будет работать, если HAProxy недоступен.

Использование HAProxy для балансировки нагрузки дает следующие преимущества:

Все приложения получают доступ к кластеру через указанные IP-адреса. Внутренняя топология кластера базы данных скрывается за HAProxy.
Соединения MySQL распределены между доступными узлами БД.
Можно добавлять или удалять узлы базы данных без необходимости внесения каких-либо изменений в приложения.
Как только достигается максимальное количество соединений с базой данных, новые соединения ставятся в очередь. Это удобный способ ограничения количества запросов на соединение с базой данных, обеспечивающий защиту от перегрузки.

ClusterControl поддерживает развертывание HAProxy из пользовательского интерфейса, поддерживая стандартные алгоритмы балансировки, предоставляемые HAProxy:

Round Robin. Каждый сервер получает запросы пропорционально своему весу, при этом веса серверов могут меняться на лету.
Least Connection. Выбирается сервер с наименьшим количеством активных соединений.
Source Hash Scheduling. Сервер для соединения назначается на основе хэша IP-адреса отправителя запроса и весов серверов.

Доступ с определенных IP-адресов

Данная возможность обеспечивается модулем ngx_http_access_module. Как правило, он входит в стандартную установку.

В настройке виртуального домена:

location / {
deny 192.168.0.15;
allow 192.168.0.0/24;
allow 2001:0ab3::/32;
deny all;
}

* в данном примере мы разрешаем доступ для всех компьютеров сети 192.168.0.0/24 (за исключением 192.168.0.15) и компьютеру с адресом ipv6 2001:0ab3::. Остальным доступ запрещен.

Если мы хотим сделать ограничение не для конкретного сайта, а для всего nginx (всех сайтов), то прописываем настройки в общем конфигурационном файле секции http:

vi /etc/nginx/nginx.conf

http {
…
    deny 192.168.0.15;
    allow 192.168.0.0/24;
    allow 2001:0ab3::/32;
    deny all;
…
}

После перезапускаем NGINX одной из команд:

systemctl reload nginx

service nginx reload

Ограничение доступа к определенной папке

Стоит отметить, что блокировать доступ по IP-адресу можно не только ко всему сайту, но и к определенным директориям, например:

location /install {
allow 192.168.0.15;
deny all;
}

* в данном примере мы запрещаем доступ к папке install, но разрешаем устройству 192.168.0.15.

Разрешить только локальные запросы

Самый правильный способ, настроить, чтобы NGINX слушал только на локальном адреса, например, listen 127.0.0.1:80;

Но если такой метод, по каким-либо причинам нам не подходит, делаем так:

location / {
allow 127.0.0.1;
deny all;
}

Действие с IP по условию

В зависимости от определенного IP-адреса NGINX может выполнять различные действия, а не только запрет доступа. Например, перенаправление:

location / {
…
if ($remote_addr != 127.0.0.1) {
return 301 https://$host$request_uri;
}
…
}

* в данном примере мы перенаправляем всех посетителей по пути https://$host$request_uri, кроме запросов с IP-адреса 127.0.0.1.

Установка

Пакет nginx доступен в прекомпилированном виде для любого дистрибутива. Однако собрав сервер самостоятельно, ты сможешь сделать его более компактным и надежным, а также получишь возможность изменить строку приветствия Web-сервера, чтобы отбить несмышленых скрипт-кидди.

Измени строку приветствия Web-сервера

Скачай исходники nginx, открой файл src/http/ngx_http_header_filter_module.c и найди следующие две строки:

Замени их на что-то вроде этого:

Удали все неиспользуемые тобой nginx-модули

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

Выполни сборку с помощью следующих команд:

Так ты получишь nginx с заранее отключенными (и в большинстве случаев бесполезными) модулями SSI (Server Side Includes) и Autoindex. Чтобы узнать, какие модули можно безболезненно выбросить из Web-сервера, запусти скрипт configure с флагом ‘—help’.

Безопасность

Помимо уменьшения времени отклика веб-сервера, необходимо позаботиться о безопасности. Разберем основные http заголовки, которые могут представлять угрозу.

X-XSS-Protection

Заголовок может предотвратить некоторые XSS-атаки.

Вы можете реализовать защиту XSS, используя три варианта в зависимости от конкретной потребности.

Это полностью отключит фильтр
Это включает фильтр, но очищает только потенциально вредоносные скрипты
Это включает фильтр и полностью блокирует страницу.

X-Frame-Options

Заголовок позволяет снизить уязвимость вашего сайта для clickjacking-атак. Этот заголовок служит инструкцией для браузера не загружать вашу страницу в frame/iframe. Не все браузеры поддерживают этот вариант.

Настроить X-Frame-Options можно тремя способами:

: это полностью отключит функции iframe.
: iframe может использоваться только кем-то из того же источника.
: Это позволит размещать страницы в окнах iframe только с определенных URL-адресов.

X-Permitted-Cross-Domain-Policies

Аналогично механизму браузеров блокировки стороннего контента Adobe Flash имеет свой. Он регулируется файлами crossdomain.xml сайта, начиная с корневого каталога. Проблема с механизмом в том, что на любом уровне вложенности корневой регулирующий файл (политика безопасности) может быть переопределен. Чтобы избежать таких ситуаций, необходимо задать этот HTTP-заголовок.

Доступно несколько вариантов настройки:

— никакая политика не допускается
— разрешить только главную политику
— все позволено
— Разрешить только определенный тип контента. Пример — XML
— применимо только для FTP-сервера

Strict-Transport-Security

Заголовок Strict-Transport-Security запрещает использование незащищенного HTTP соединения на сайте, если есть защищенное HTTPS.

X-Content-Type-Options

Рейтинг наиболее опасных к использованию возможностей браузера возглавляет возможность Internet Explorer «угадывать» тип файла, игнорируя его MIME-тип.

При передаче от сервера к браузеру все файлы имеют тот или иной тип, который прямо указывает на суть содержимого файла. Однако, Internet Explorer имеет встроенный механизм, который позволяет по-содержимому файла переопределить его тип.

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

Настройка журнала ошибок

Nginx записывает сообщения об ошибках приложения и общих ошибках сервера в файл журнала ошибок. Если вы испытываете ошибки в своем веб-приложении, журнал ошибок — это первое место, с которого можно начать поиск и устранение неисправностей.

Директива включает и устанавливает расположение и уровень серьезности журнала ошибок. Он имеет следующую форму и может быть установлен в блоке , или :

Параметр устанавливает уровень ведения журнала. Ниже перечислены уровни в порядке их серьезности (от низкого до высокого):

— сообщения.
— Информационные сообщения.
— Уведомления.
— Предупреждения.
— Ошибки при обработке запроса.
— Критические проблемы. Требуется быстрое действие.
— Оповещения. Действия должны быть предприняты немедленно.
— Чрезвычайная ситуация. Система находится в непригодном для использования состоянии.

Каждый уровень журнала включает в себя более высокие уровни. Например, если вы установите уровень журнала , чтобы , Nginx будет также регистрировать , , и сообщения.

Если параметр не указан, по умолчанию используется .

По умолчанию директива определена в директиве внутри основного файла nginx.conf:

/etc/nginx/nginx.conf

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

Например, чтобы настроить журнал ошибок domain.com на вы должны использовать:

Каждый раз, когда вы изменяете файл конфигурации, вам необходимо перезапустить службу Nginx, чтобы изменения вступили в силу.

Оптимизация работы соединений

Настроим несколько основных параметров, которые отвечают за количество обрабатываемых соединений и сроки их поддержания.

— Определяет количество рабочих процессов. Обычно, выставляют равному числу ядер, но в новых версиях его лучше устанавливать в auto. По умолчанию 1

— Устанавливает максимальное количество соединений одного рабочего процесса, то есть nginx будет обрабатывать * , остальные запросы ставить в очередь. Следует выбирать значения от 1024 до 4096. По умолчанию 512.

— Позволяет принимать максимально возможное количество соединений. Иначе, процесс nginx за один раз будет принимать только одно новое соединение. По умолчанию off.

— Отвечает за максимальное время поддержания keepalive-соединения, в случае, если пользователь по нему ничего не запрашивает. Для современных систем, стоит выставить от 30 до 50. В нашем случае 45. По умолчанию 75.

— Если клиент перестал читать страницу, Nginx будет сбрасывать соединение с ним. По умолчанию off.

— Ждет выставленное количество секунд тело запроса от клиента, после чего сбрасывает соединение. По умолчанию 60.

— Если клиент прекратит чтение ответа, Nginx подождет выставленное количество секунд и сбросит соединение. По умолчанию 60.

| Атаки на сайт довольно распространённый метод вредительства.

Статья несёт в себе не только список команд или конкретный метод борьбы с атакой, следует тщательно прочитать всю информацию для полноты восприятия, Вы потратите немного больше времени на прочтение, но получите больше информации и у Вас с вероятностью 99% всё получится.
Начнём с обычного флуда на сайт (bruteforce, POST\HEAD\GET флуд и другое вредительство)

Забивание inode на сервере, это количество максимальных файлов (не размер файлов) которые могут быть на диске. Обычно это сессии и временные файлы от CMS (движка сайта).
Перегрузка MySQL, даже при нормально работающем nginx и apache2, нужно искать в логах, куда именно идёт флуд и на какой скрипт, который приводит к нагрузке на MySQL.
Перегрузка nginx или apache2, нужно читать логи и выяснять, куда идёт атака. Если в логах информации нет, но нагрузка есть, следует настроить правила iptables и сделать дамп трафика утилитой tcpdump, что бы анализировать дальнейшую защиту.
Вас могут брутить, т.е подбирать логины\пароли, в этом случае требуется каптча и опять же чтение логов и их анализ, для более лучшего эффекта.
Самое плохое, что может случится, что Ваш сервер VDS будет просто виснуть, когда ресурсы будут переполнены и сервер перегружен, тогда для борьбы с атакими нужно повышать тариф и иметь запас мощности.

1. Немного настроим наш Nginx веб-сервер
events { worker_connections 100;}
events { worker_connections 65535; use epoll;}
/etc/init.d/nginx restart
2. Собираем информацию для дальнейшего анализа

/var/www/httpd-logs
/var/www/ПОЛЬЗОВАТЕЛЬ/data/logs/

grep -lr ‘access_log’ /etc/nginx/

cat /etc/nginx/vhosts/user/site.com.conf | grep access_log

3. Анализируем полученные логи
tail -n 100 /var/www/httpd-logs/site.com.access.log

4. Проверяем все подключения к серверу, ищем наличие атаки
netstat -ntu | grep «:443\|:80» | grep -v 127.0.0.1 | awk ‘{print $5}’ | cut -d: -f1 | sort | uniq -c | sort -nr

5. Блокируем «плохие» IP адреса, которые атакуют сайт
/etc/init.d/nginx restart
/etc/nginx/vhosts/user/site.com.conf

netstat -ntu | grep «:443\|:80» | grep -v 127.0.0.1 | awk ‘{print $5}’ | cut -d: -f1 | sort | uniq -c | sort -nr

ip route add blackhole 2.92.2.14
ip route del 2.92.2.14
/sbin/iptables -I INPUT -p tcp —match multiport —dports 80,443 -s 2.92.2.14 -j DROP
/sbin/iptables -D INPUT -p tcp —match multiport —dports 80,443 -s 2.92.2.14 -j DROP
/sbin/iptables-save | grep -v 2.92.2.14 | iptables-restore
6. Переходим к автоматизации процесса блокировки и обнаружения атаки.

FREQ= здесь указывается интервал запуска скрипта, параметр средней важности, так как в крон мы добавим задания вручную.
TAILCOUNT= количество строк, читаемых с лога, этот параметр на каждый сайт уникален, чем больше запросов у сайта, тем больше указывайте значение, на 1000 посетителей, которые что-то делают на сайте или открывают, желательно указать 10000, считайте дальше сами, если Вы не знаете что лучше указать, напишите нам в поддержку.
LOGPATH= это путь к вашему access_log логу сайта, как его найти мы читали выше.
GREP_FILTER= желательно не трогать, здесь указан фильтр по которому считать запросы..
NO_OF_CONNECTIONS= количество одновременных запросов к сайту, по умолчанию 100, обычно хватает.
APF_BAN= не трогаем, здесь указывается метод блокировки, через iptables или APF
KILL= не трогаем, указывается блокировать ип адреса которые флудят или нет, при настройке скрипта можете поменять, что бы не банить настоящих пользователей в процессе настройки.
EMAIL_TO= здесь заполняем свой email куда будут отправляться отчёты о блокировках, должен быть установлен почтовый сервер, по умолчанию уже должен быть установлен, если нет, то (apt-get install exim4)
BAN_PERIOD= период бана IP адреса, указывается в секундах, разблокировка происходит при последующих запусках скрипта.

ignore.ip.listignoreds.listapt-get install nanoexport EDITOR=nanocrontab -e

Настройка журнала доступа

Каждый раз, когда клиентский запрос обрабатывается, Nginx генерирует новое событие в журнале доступа. Каждая запись события содержит отметку времени и включает различную информацию о клиенте и запрошенном ресурсе. Журналы доступа могут показать вам местоположение посетителей, страницу, которую они посещают, сколько времени они проводят на странице и многое другое.

Директива позволяет вам определять формат регистрируемых сообщений. Директива включает и устанавливает расположение файла журнала и используемый формат.

Самый простой синтаксис директивы следующий:

Где — это полный путь к файлу журнала, а — формат, используемый файлом журнала.

Журнал доступа можно включить в блоке , или .

По умолчанию журнал доступа глобально включен в директиве в основном файле конфигурации Nginx.

/etc/nginx/nginx.conf

Для удобства чтения рекомендуется создавать отдельный файл журнала доступа для каждого серверного блока. Директива установленная в директиве директиву, установленную в директиве (более высокого уровня).

/etc/nginx/conf.d/domain.com.conf

Если формат журнала не указан, Nginx использует предопределенный комбинированный формат, который выглядит следующим образом:

Чтобы изменить формат ведения журнала, отмените настройку по умолчанию или определите новую. Например, чтобы определить новый формат ведения журнала с именем custom, который расширит комбинированный формат значением, показывающим заголовок добавьте следующее определение в директиву или :

Чтобы использовать новый формат, укажите его имя после файла журнала, как показано ниже:

Хотя журнал доступа предоставляет очень полезную информацию, он занимает дисковое пространство и может повлиять на производительность сервера. Если на вашем сервере мало ресурсов и у вас загруженный веб-сайт, вы можете отключить журнал доступа. Чтобы сделать это, установите значение директиву :

Другие способы

Открой файл /etc/sysctl.conf и помести в него следующие строки:

Поместив корневой каталог Web-сервера в выделенный раздел и запретив на нем размещение любых исполняемых файлов и файлов-устройств, ты обезопасишь остальную часть системы от тех, кто сможет получить доступ к корню Web-сервера. При этом запись в файле /etc/fstab должна иметь примерно такой вид:

Помести nginx в chroot/jail-окружение

Любая современная *nix-система позволяет запереть приложение в изолированной среде исполнения. В Linux для этого можно использовать технологии KVM, Xen, OpenVZ и VServer, во FreeBSD – Jail, в Solaris – Zones. Если ни одна из этих технологий не доступна, ты можешь поместить nginx в классический chroot, который хоть и намного более хрупок, но большинство взломщиков остановить сможет.

Установи правила SELinux для защиты nginx

Хорошей альтернативой изолированным средам исполнения являются локальные системы обнаружения и предотвращения вторжений, такие как SELinux или AppArmor. Будучи правильно настроенными, они смогут предотвратить попытки взлома Web-сервера. По дефолту ни одна из них не настроена для работы в связке с nginx, однако в рамках проекта SELinuxNginx (http://sf.net/projects/selinuxnginx/) были созданы правила для SELinux, которые может использовать любой желающий. Остается только скачать и установить:

Настрой брандмауэр

Обычно nginx устанавливают на выделенных машинах, готовых к высокой нагрузке, поэтому зачастую он остается единственным сетевым сервисом, работающим на сервере. Чтобы обезопасить сервер, достаточно создать совсем небольшой набор правил, которые будут открывать 80, 110 и 143-й порты (если, конечно, nginx должен работать еще и как IMAP/POP3-прокси) и закрывать от внешнего мира все остальное.

Ограничь количество соединений с помощью брандмауэра

Для не слишком нагруженного Web-сайта хорошей идеей будет ограничить количество попыток соединений с одного IP-адреса в минуту. Это сможет уберечь тебя от некоторых типов DoS-атак и брутфорса. В Linux это можно сделать с помощью стандартного iptables/netfilter-модуля state:

Правила урезают лимит на количество подключений с одного IP в минуту до 15. То же можно сделать и с помощью pf:

Кроме лимита на количество последовательных подключений (15 в минуту), данное правило устанавливает дополнительный лимит на количество одновременных подключений равный 100.

Настрой PHP

Если ты используешь nginx в связке с PHP, не забудь настроить и его. Вот как должен выглядеть конфигурационный файл /etc/php/php.ini защищенного сервера:

Оптимизация работы с файлами

позволяет использовать более совершенный системный вызов, который обеспечивает прямую передачу файла, то есть без системных вызовов read + write.

включает использование асинхронного обращения к файлам, что избавит от очередей запросов.

позволит передавать заголовок ответа и начало файла в одном пакете.

по умолчанию выключена. Задает настройку для кэширования информации о файлах, с которыми работает nginx. По умолчанию выключено.

задает время, через которое веб-сервер будет проверять актуальность данных. По умолчанию 60 секунд.

задает минимальное число обращений к файлу, чтобы дескриптор файла оставался открытым в кэше.

Выводы

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

О герое дня

Nginx – один самых производительных и популярных Web-серверов в мире. Согласно данным Netcraft, он используется для поддержки более чем 12 миллионов Web-сайтов по всему миру, включая таких мастодонтов как Rambler, Yandex, Begun, WordPress.com, Wrike, SourceForge.net, vkontakte.ru, megashara.com, Либрусек и Taba.ru. Грамотная архитектура, основанная на мультиплексировании соединений с помощью системных вызовов select, epoll (Linux), kqueue (FreeBSD) и механизме управления памятью на основе пулов (небольших буферов от 1 до 16 Кб), позволяет nginx не проседать даже под очень высокими нагрузками, выдерживая свыше 10000 одновременных соединений (так называемая проблема C10K). Изначально написан Игорем Сысоевым для компании Rambler и открыт в 2004 году под BSD-подобной лицензией.

Взято с xakep.ru