Как мы отбивали xss/sql атаку с Nginx и Naxsi
Совсем недавно в разгар рабочего дня от клиента к нам поступила тревожная информация о том, что их сайт подвергается XSS/SQL атакам, часть из которых была успешной. Необходимо было срочно принять меры и настроить базовую защиту в течение нескольких часов, т.к. возможности быстро найти и устранить несовершенства кода у разработчиков не было.После недолгих раздумий выбор пал на firewall веб-приложений для nginx под названием naxsi, который технически является модулем nginx.Naxsi работает по принципу: всё, что не разрешено — запрещено. Каждый HTTP-запрос (GET|PUT|POST) проверяется на соответствие шаблонам запрещающих правил, заданным по-умолчанию в файле naxsi_core.rules. Данные простые правила охватывают 99% всех возможных вариантов зловредных запросов. Например по-умолчанию запрещены все запросы в URI которых содержится символ »<". Если для приложения использование такого символа необходимо для нормальной работы, то нужно вручную прописать соответствующие исключения в белый список.
Такой подход обеспечивает высокий уровень защиты, т.к. для naxsi нет такого понятия как «неизвестный тип атаки», как это может быть с другими системами защиты, которые используют при фильтрации сигнатуры известных уязвимостей. Но есть и обратная сторона медали: если разрешающие правила будут проработаны плохо, то naxsi будет блокировать еще и часть легальных запросов. Ответственность за конечный результат разработчики модуля целиком и полностью возлагают на администратора системы. С этими мыслями мы и приступили к установке модуля.
Сайт клиента работает под управлением CentOS 6. К сожалению готового пакета nginx с включенным модулем naxsi для CentOS 6 не нашлось, поэтому нужно было компилировать самостоятельно.
В нашей компании существует политика, согласно которой устанавливать что-либо из исходников запрещается, поэтому для решения задачи моим коллегой был собран rpm-пакет, который при желании можно взять в нашем репозитории.
Установка из пакета:
rpm -Uvh http://rpms.southbridge.ru/southbridge-rhel6-stable.rpm yum install -y nginx-naxsi Добавляем nginx в автозапуск: chkconfig nginx on Создаем файл со стандартными запрещающимиправилами naxsi: wget -O /etc/nginx/naxsi_core.rules https://raw.githubusercontent.com/nbs-system/naxsi/master/naxsi_config/naxsi_core.rules Включаем стандартные запрещающие правила в конфиг nginx в контекст http:/etc/nginx/nginx.conf http { … include /etc/nginx/naxsi_core.rules; … } Создаем файл с конфигурацией naxsi: touch /etc/nginx/my_naxsi.rules cat << EOF >/etc/nginx/naxsi.rules LearningMode; # режим обучения. В SecRulesEnabled; #SecRulesDisabled; DeniedUrl »/RequestDenied»; include »/etc/nginx/my_naxsi.rules»; ## check rules CheckRule »$SQL >= 8» BLOCK; CheckRule »$RFI >= 8» BLOCK; CheckRule »$TRAVERSAL >= 4» BLOCK; CheckRule »$EVADE >= 4» BLOCK; CheckRule »$XSS >= 8» BLOCK; EOF Включаем naxsi для желаемого виртуального хоста: server { … set $naxsi_extensive_log 1; # отключите это когда закончите настройку … location / { … include /etc/nginx/naxsi.rules; … } … location /RequestDenied { return 500; # все «плохие» запросы идут на 500 } … } Перезапускаем nginx: service nginx restart С этого момента naxsi работает в режиме обучения. Никакие запросы не блокируются, но активно записываются в errorlog для указанного виртуального хоста nginx.Чтобы не нарушить в будущем работу сайта, в режиме обучения необходимо обеспечить нагрузку сайта легитимным трафиком так, чтобы было сделано как можно больше различных запросов, которые будут возникать в обычной его работе.После обучения, переходим к генерации исключений (whitelists) для базовых запрещающих правил. Это можно делать как вручную, так и в автоматическом режиме с помощью утилиты nx_util.py.
wget -O /tmp/naxsi.zip https://github.com/nbs-system/naxsi/archive/0.53–2.zip unzip /tmp/naxsi.zip rm -f /tmp/naxsi.zip sed -i 's/\/usr\/local\/etc/\/tmp\/naxsi-0.53–2\/nx_util/' /tmp/naxsi-0.53–2/nx_util/nx_util.py python /tmp/naxsi-0.53–2/nx_util/nx_util.py -l -o Утилита парсит errorlog файл на предмет записей от NAXSI и выводит в stdout сгенерированный список исключений, отсортированный по частоте срабатываний. При этом правила из нижней части списка могут быть по-умолчанию закомментированы.Данные сгенерированные исключения, их полнота и корректность являются основным фактором — насколько эффективно будет применяться фильтрация Naxsi. Автоматически сгенерированные правила необходимо обязательно проанализировать и при необходимости отредактировать. Разобраться в синтаксисе правил можно, изучив официальную документациюКопируем полученные whitelist-правила в файл /etc/nginx/my_naxsi.rules.Включаем боевой режим naxsi: sed -i 's/LearningMode/#LearningMode/' /etc/nginx/naxsi.rules Перезапускаем nginx: nginx -t service nginx reload Базовая настройка завершена! Если при работе модуля в боевом режиме какие-то легальные запросы все-таки оказываются неучтенными и блокируются, то нужно их добавлять в белый список в файл /etc/nginx/my_naxsi.rules. Для этого можно повторно запускать nx_util.py или научиться анализировать записи NAXSI в errorlog и писать исключения самостоятельно.Проверить, попадают ли какие-нибудь запросы под блокировку или нет можно так: cat | grep NAXSI Вот так всего за несколько часов была организована базовая защита сайта от XSS/SQL атак. А разработчики уже без спешки продолжили устранять несовершенства в коде.На этом всё. Спасибо за внимание!
Автор Last_Lame Будем рады ответить на любые вопросы в личной переписке или по почте ask@centos-admin.ru
