Как мы отбивали 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; DeniedUrl "/RequestDenied"; include "/etc/nginx/my_naxsi.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; } ... } Перезапускаем 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 </путь/до/errorlog-файла> -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 </путь/до/errorlog-файла> | grep NAXSI Вот так всего за несколько часов была организована базовая защита сайта от XSS/SQL атак. А разработчики уже без спешки продолжили устранять несовершенства в коде.
На этом всё. Спасибо за внимание!
Автор Last_Lame
Будем рады ответить на любые вопросы в личной переписке или по почте ask@centos-admin.ru
Sent from my iPhone
Комментариев нет:
Отправить комментарий