TOC

Как установить и настроить Naxsi в Ubuntu 14.04

Вступление

Naxsi - это сторонний модуль Nginx, который предоставляет функции брандмауэра веб-приложений. Он обеспечивает дополнительную безопасность вашему веб-серверу и защищает вас от различных веб-атак, таких как инъекции XSS и SQL.

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

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

Из этого туториала Вы узнаете, как установить Naxsi, понять правила, создать белый список и где найти правила, уже написанные для часто используемых веб-приложений.

Предпосылки

Прежде чем следовать этому руководству, убедитесь, что вы выполнили следующие предварительные условия:

  • Капля Ubuntu 14.04

  • Пользователь без полномочий root. За подробностями обращайтесь к Initial Server Setup с Ubuntu 14.04.

Если не указано иное, все команды, которым требуются привилегии root в этом учебном пособии, должны запускаться как пользователь без полномочий root с привилегиями sudo.

Шаг 1 - Установка Naxsi

Чтобы установить Naxsi, вам нужно будет установить скомпилированный с ним сервер Nginx. Для этого вам понадобится пакет + nginx-naxsi +. Вы можете установить его обычным способом Ubuntu с помощью команды + apt-get +:

sudo apt-get update
sudo apt-get install nginx-naxsi

Это установит Naxsi вместе с Nginx и всеми его зависимостями. Это также гарантирует, что служба запускается и останавливается автоматически в Droplet.

Установка Nginx по умолчанию обеспечивает базовую рабочую среду Nginx, которой достаточно для знакомства с Naxsi. Мы не будем тратить время на настройку Nginx, а вместо этого перейдем непосредственно к настройке Naxsi. Однако, если у вас нет опыта работы с Nginx, рекомендуется проверить How To Установите Nginx на Ubuntu 14.04 LTS и связанные с ним статьи, особенно https://www.digitalocean.com/community/tutorials/how-to-set-up-nginx-server-blocks-virtual-hosts-on-ubuntu-14 -04-lts [Как настроить серверные блоки Nginx (виртуальные хосты) в Ubuntu 14.04 LTS].

Шаг 2 - Включение Naxsi

Во-первых, чтобы включить Naxsi, нам нужно загрузить основные правила, которые находятся в файле + / etc / nginx / naxsi_core.rules +. Этот файл содержит общие подписи для обнаружения вредоносных атак. Мы обсудим эти правила более подробно позже. Сейчас мы просто включим правила в основной файл конфигурации Nginx + / etc / nginx / nginx.conf + в часть прослушивателя HTTP. Итак, откройте последний файл для редактирования с помощью nano:

sudo nano /etc/nginx/nginx.conf

Затем найдите раздел + http + и раскомментируйте включающую часть для правил Naxsi, удалив символ + # + в начале строки. Теперь это должно выглядеть так:

/etc/nginx/nginx.conf

http {
...
       # nginx-naxsi config
       ##
       # Uncomment it if you installed nginx-naxsi
       ##


...

Сохраните файл и выйдите из редактора.

Во-вторых, мы должны включить предыдущие правила и настроить некоторые основные параметры для Naxsi. По умолчанию базовая конфигурация Naxsi находится в файле + / etc / nginx / naxsi.rules +. Откройте этот файл:

sudo nano /etc/nginx/naxsi.rules

Измените только значение для + DeniedUrl + на файл ошибок, который уже существует по умолчанию, и оставьте остальное без изменений:

/etc/nginx/naxsi.rules

# Sample rules file for default vhost.
LearningMode;
SecRulesEnabled;
#SecRulesDisabled;


## check rules
CheckRule "$SQL >= 8" BLOCK;
CheckRule "$RFI >= 8" BLOCK;
CheckRule "$TRAVERSAL >= 4" BLOCK;
CheckRule "$EVADE >= 4" BLOCK;
CheckRule "$XSS >= 8" BLOCK;

Сохраните файл и выйдите.

Вот директивы конфигурации сверху с их значением:

  • + LearningMode + - Запустить Naxsi в режиме обучения. Это означает, что ни один запрос на самом деле не будет заблокирован. В журнале ошибок Nginx будут отображаться только исключения безопасности. Такое неблокирующее начальное поведение важно, потому что правила по умолчанию довольно агрессивны. Позже, основываясь на этих исключениях, мы создадим белый список для законного трафика.

  • + SecRulesEnabled + - включить Naxsi для блока / местоположения сервера. Точно так же вы можете отключить Naxsi для сайта или части сайта, раскомментировав + SecRulesDisabled +.

  • + DeniedUrl + - URL-адрес, на который отклоненные запросы будут отправлены внутри. Это единственная настройка, которую вы должны изменить. Вы можете использовать легкодоступную страницу ошибок + 50x.html +, найденную в корне документа по умолчанию (+ / usr / share / nginx / html / 50x.html +), или вы можете создать свою собственную страницу ошибок.

  • + CheckRule + - Установить порог для разных счетчиков. Как только этот порог пройден (например, 8 баллов за счетчик SQL) запрос будет заблокирован. Чтобы сделать эти правила более агрессивными, уменьшите их значения и наоборот.

Файл + naxsi.rules + должен быть загружен в зависимости от местоположения для блока сервера. Давайте загрузим его для корневого расположения (+ / +) блока сервера по умолчанию. Сначала откройте файл конфигурации блока сервера + / etc / nginx / sites-enabled / default +:

sudo nano /etc/nginx/sites-enabled/default

Затем найдите корневой каталог + / + и убедитесь, что он выглядит следующим образом:

   location / {
           # First attempt to serve request as file, then
           # as directory, then fall back to displaying a 404.
           try_files $uri $uri/ =404;
           # Uncomment to enable naxsi on this location

   }

После внесения вышеуказанных изменений вы можете перезагрузить Nginx, чтобы изменения вступили в силу:

sudo service nginx reload

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

Шаг 3 - Проверка журналов

Чтобы убедиться, что Naxsi работает, хотя он еще находится в режиме обучения, давайте перейдем по URL-адресу, который должен вызвать исключение, и проследим журнал ошибок для исключения.

Позже мы увидим, как именно работает это правило. Пока что журнал ошибок хвостовой части Nginx найдет исключение (опция + -f + сохраняет вывод открытым и добавляет к нему новый контент:

sudo tail -f /var/log/nginx/error.log

Попробуйте получить доступ к вашей капле по URL + http: ///index.html? Asd = ---- +. Это должно вызвать исключение безопасности Naxsi из-за тире, которые используются для комментариев в SQL и, следовательно, считаются частями SQL-инъекций.

В выводе + sudo tail -f / var / log / nginx / error.log + теперь вы должны увидеть следующее новое содержимое:

Output of nginx's error log2015/11/14 03:58:35 [error] 4088#0: *1 NAXSI_FMT: ip=X.X.X.X&server=Y.Y.Y.Y&uri=/index.html&learning=1&total_processed=24&total_blocked=1&, client: X.X.X.X, server: localhost, request: "GET /index.html?asd=---- HTTP/1.1", host: "Y.Y.Y.Y"

Наиболее важная часть вышеприведенной строки выделена: + zone0 = ARGS & id0 = 1007 & var_name0 = asd +. Он дает вам зону (часть запроса), идентификатор сработавшего правила и имя переменной подозрительного запроса.

Кроме того, + X.X.X.X + - это IP-адрес вашего локального компьютера, а + Y.Y.Y.Y + - это IP-адрес вашей капли. URI также содержит имя файла запроса (+ index.htm +), тот факт, что Naxsi все еще работает в режиме обучения (+ learning = 1 +) и общее количество всех обработанных запросов (`+ total_processed). = 24 + `).

Также сразу после вышеприведенной строки должно следовать сообщение о перенаправлении на + DeniedUrl +:

Output of nginx's error log2015/11/14 03:58:35 [error] 4088#0: *1 rewrite or internal redirection cycle while internally redirecting to "/50x.html" while sending response to client, client: X.X.X.X, server: localhost, request: "GET /favicon.ico HTTP/1.1", host: "Y.Y.Y.Y", referrer: "http://Y.Y.Y.Y/index.html?asd=----"

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

Нажмите + CTRL-C +, чтобы выйти из + tail + и остановить вывод файла журнала ошибок.

Позже мы узнаем больше о правилах Naxsi, и тогда будет важно иметь это базовое понимание журналов.

Шаг 4 - Настройка правил Naxsi

Самая важная часть конфигурации Naxsi - это ее правила. Существует два типа правил - основные правила и основные правила. Основные правила (обозначенные + MainRule +) применяются глобально для сервера и, таким образом, являются частью блока + http + конфигурации основного Nginx. Они содержат общие подписи для обнаружения вредоносных действий.

Основные правила (обозначенные + BasicRule +) используются в основном для внесения в белый список ложноположительных подписей и правил. Они применяются для каждого местоположения и поэтому должны быть частью конфигурации блока сервера (vhost).

Давайте начнем с основных правил и рассмотрим стандартные, предоставляемые пакетом + nginx-naxsi + в файле + / etc / nginx / naxsi_core.rules +. Вот пример строки:

/etc/nginx/naxsi_core.rules

...
MainRule "str:--" "msg:mysql comment (--)" "mz:BODY|URL|ARGS|$HEADERS_VAR:Cookie" "s:$SQL:4" id:1007;
...

Из приведенного выше правила мы можем выделить следующие части, которые являются универсальными и присутствуют в каждом правиле:

  • + MainRule + - это директива, с которой начинается каждое правило. Точно так же каждое правило заканчивается идентификатором правила.

  • + str: + находится во второй части правила. Если это + str: +, это означает, что подпись будет простой строкой, как в примере выше. Регулярные выражения также могут быть сопоставлены с директивой + rx: +.

  • + msg: + дает некоторое разъяснение о правиле.

  • + mz: + обозначает зону совпадения или часть запроса, которая будет проверена. Это может быть тело, URL, аргументы и т. Д.

  • + s: + определяет счет, который будет назначен при обнаружении подписи. Результаты добавляются к различным счетчикам, таким как + SQL + (атаки SQL), + RFI + (атаки с удаленным включением файлов) и т. Д.

По сути, вышеприведенное правило (+ id 1007 +) с комментарием + mysql comments + означает, что если строка + - + найдена в любой части запроса (теле, аргументах и ​​т. Д.), 4 балла будет добавлен в счетчик SQL.

Если мы вернемся к примеру URI (+ http: ///index.html? Asd = ---- +), который вызвал исключение SQL в журнале, вы заметите, что для запуска правила 1007 нам понадобилось 2 пары тире (+ - +). Это потому, что для каждой пары мы получаем 4 балла, а цепочке SQL нужно 8 баллов, чтобы заблокировать запрос. Таким образом, только одна пара штрихов не будет проблематичной, и в большинстве случаев законный трафик не пострадает.

Одна специальная директива правила - «+ отрицательный +». Он применяет баллы, если подпись не совпадает, т.е. вы подозреваете вредоносную активность, когда что-то в запросе отсутствует.

Например, давайте посмотрим на правило с + id 1402 + из того же файла + / etc / nginx / naxsi_core.rules +:

/etc/nginx/naxsi_core.rules

...
MainRule negative "rx:multipart/form-data|application/x-www-form-urlencoded" "msg:Content is neither mulipart/x-www-form.." "mz:$HEADERS_VAR:Content-type" "s:$EVADE:4" id:1402;
...

Приведенное выше правило означает, что к счетчику EVADE будут добавлены 4 точки, если в заголовке запроса + Content-type + нет ни + multipart / form-data +, ни + application / x-www-form-urlencoded + , Это правило также является примером того, как регулярные выражения (+ rx: +) могут использоваться для описания подписи.

Шаг 5 - Правила белого списка

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

Белые списки создаются со вторым типом правил, базовыми правилами Naxsi. С помощью основного правила вы можете внести в белый список либо целое правило, либо его части.

Чтобы продемонстрировать, как работают основные правила, давайте вернемся к правилу комментариев SQL (id 1007). Представьте, что у вас есть файл с двумя тире в имени файла, например, + some - file.html + на вашем сайте. С правилом 1007 этот файл увеличит счетчик SQL на 4 пункта. Одно только это имя файла и итоговая оценка недостаточны для блокировки запроса, но это все еще ложный положительный результат, который может вызвать проблемы. Например, если у нас также есть аргумент с двумя черточками, то запрос вызовет правило 1007.

Чтобы проверить это, подключите журнал ошибок, как раньше:

sudo tail -f /var/log/nginx/error.log

Попробуйте получить доступ к + http: ///some—​file.html? Asd = - +. Вам не нужно иметь этот файл на своем веб-сайте для тестирования.

Вы должны увидеть знакомое исключение, подобное этому в выходных данных журнала ошибок:

Output of nginx's error log2015/11/14 14:43:36 [error] 5182#0: *10 NAXSI_FMT: ip=X.X.X.X&server=Y.Y.Y.Y&uri=/some--file.html&learning=1&total_processed=10&total_blocked=6&zone0=URL&id0=1007&var_name0=&zone1=ARGS&id1=1007&var_name1=asd, client: X.X.X.X, server: localhost, request: "GET /some--file.html?asd=-- HTTP/1.1", host: "Y.Y.Y.Y"

Нажмите + CTRL-C +, чтобы перестать показывать вывод журнала ошибок.

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

BasicRule :1007 "mz:URL";

Важным ключевым словом является + wl + для белого списка, за которым следует идентификатор правила. Чтобы быть более точным, что мы в белом списке, мы также указали зону соответствия - URL.

Чтобы применить этот белый список, сначала создайте новый файл для белых списков:

sudo nano /etc/nginx/naxsi_whitelist.rules

Затем вставьте правило в файл:

/etc/nginx/naxsi_whitelist.rules

BasicRule wl:1007 "mz:URL";

Если у вас есть другие белые списки, они также могут войти в этот файл, каждый в новом ряду.

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

sudo nano /etc/nginx/sites-enabled/default

Затем добавьте новый include сразу после предыдущего для Naxsi следующим образом:

/ И т.д. / Nginx / сайты с поддержкой / по умолчанию

       location / {
               # First attempt to serve request as file, then
               # as directory, then fall back to displaying a 404.
               try_files $uri $uri/ =404;
               # Uncomment to enable naxsi on this location
               include /etc/nginx/naxsi.rules;

       }

Чтобы изменения вступили в силу, перезагрузите Nginx:

sudo service nginx reload

Теперь, если вы попытаетесь снова выполнить тот же запрос в вашем браузере для + / some - file.html? Asd = - +, только параметр + asd +, равный двум черточкам, вызовет 4 точки для счетчика SQL, но необычный имя файла не будет. Таким образом, вы не увидите этот запрос в журнале ошибок как исключение.

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

Убедившись, что вы не видите никаких исключений для законных запросов в журнале ошибок, вы можете отключить режим обучения Naxsi. Для этого откройте файл + / etc / nginx / naxsi.rules + с помощью nano:

sudo nano /etc/nginx/naxsi.rules

Закомментируйте директиву + LearningMode +, добавив перед ней символ + # + следующим образом:

/etc/nginx/naxsi.rules

...
LearningMode;
SecRulesEnabled;
#SecRulesDisabled;
...

Наконец, перезагрузите Nginx, чтобы изменения вступили в силу:

sudo service nginx reload

Теперь Naxsi заблокирует любые подозрительные запросы, и ваш сайт станет более безопасным.

Заключение

Вот как легко иметь брандмауэр веб-приложений с Nginx и Naxsi. Этого достаточно для начала, и, надеюсь, вам будет интересно узнать больше о том, что может предложить мощный модуль Naxsi. Теперь вы можете сделать свой сервер Nginx не только быстрым, но и безопасным.

Related