Рубрика: web

Отключение аутентификации Nginx для заданных ip-диапазонов

Posted on by

Удобный инструмент для защиты разного рода тестовых/разработческих сайтов — аутентификация на уровне веб-сервера по паролю. Она закрывает сайты от ненамеренного индексирования поисковиками и от входа третьих лиц. В Nginx такая делается директивой auth_basic, которая дополняется файлом с пользователями и паролями. Кто-то из разработчиков заходит со статических адресов, поэтому в им аутентификация не нужна и её можно отключить. Делается это следующим образом:

satisfy  any;
allow XX.XX.XX.XX/ZZ;
allow YY.YY.YY.YY/WW;
allow ...
deny   all;

auth_basic            "restricted area";
auth_basic_user_file  htpasswd/example.com;

Таким образом пользователи со статических адресов могут заходить на сайт без ввода паролей. Таким же образом можно открыть сайт для интернет-тестеров разных возможностей сайта, в частности оптимизации (google pagespeed, gtmetrix), безопасности и т.п.

Реальный адрес через обратный прокси nginx

Posted on by

Nginx в последнее время повсеместно используется как обратный веб-прокси. Среди параметров, которые он передаёт бэкенду есть и реальный ip-адрес пользователя, который нередко используется в приложении. Кроме приложения тот же адрес отображается в логах и для целей отладки целесообразно в них писать также действительный адрес. Задача передачи этого параметра (и некоторых других — протокола, хоста) со стороны обратного прокси обычно решается добавлением заголовков:

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

Файл с этими заголовками в виде сниппета есть даже в поставке nginx «из коробки», поэтому со его стороны всё решается предельно просто: инклюдом этого сниппета в конфигурации виртуальных хостов.

По-разному задача решается со стороны бэкендов. Так, в apache2 для этого подключается модуль remoteip и добавляется для него (стандартный) конфигурационный файл:

    RemoteIPHeader X-Real-IP
    RemoteIPInternalProxy 127.0.0.1

И после этого всё работает. В лог-файлах для корректного отображения адреса также стоит заменить «%h» -> «%a», что есть не лучшее, но рабочее решение.

В nginx-бэкенде чтобы не менять стандартный log_format в окружение server виртуального хоста добавляется

    set_real_ip_from  192.168.1.4;
    real_ip_header    X-Forwarded-For;

После этого в логах отображается правильный исходный клиентский адрес.

Ссылки для теста https

Posted on by

Сайты с поддержкой протокола https становятся все более и более популярны. Ниже короткий список наиболее полезных ресурсов для проверки корректности работы SSL/TLS и проверки безопасности.

  1. Наиболее полезный тест безопасности есть на сайте SSL Labs. Проверяет поддерживаемые протоколы, обмен ключей и многое другое. Если что не так, сразу видно и можно пофиксить.

  2. Ещё один очень информативный тест от High-Tech Bridge https://www.htbridge.com/ssl/
    Также здесь можно протестировать SSL на почтовых протоколах POP/IMAP/SMTP.

  3. Проверить цепочки сертификатов можно
    https://www.sslchecker.com/sslchecker
    https://www.geocerts.com/ssl_checker
    https://www.sslshopper.com/ssl-checker.html
    Из них первый проверяет цепочку полностью, но на деле корневой сертификат не всегда нужно явно указывать в настройках сервера.

  4. Тест безопасности от Симантек. У них же есть и более широкая подборка утилит.

  5. Ещё полезные тесты:
    https://www.wormly.com/test_ssl
    https://www.digicert.com/help/
    https://sslanalyzer.comodoca.com/

  6. Также проверка клиента, особенно если подключение идёт со старых машин
    https://www.howsmyssl.com/

Странности nginx ssl

Posted on by

Параметры SSL в конфигурации nginx могут быть описаны как в глобальной http-секции, так и в настройках локальных серверов server. В контексте server по логике настройки должны применяться только на этот сервер.

Интересно, что поддержка TLS v1.2 включается только если её включить в server-секциях всех виртуальных хостов, а не только нужного.

nginx HTTP/2

Posted on by

Отлично! В энжинксе сделали полноценную поддержку http2, а если точнее, то заменили SPDY на HTTP/2. Поддержка есть в последних версиях (>=1.9.5), проверяем

$ nginx -V

и если в ответе есть --with-http_v2_module, то можно включать. Включается, как и все в nginx, очень просто — дописываем в конфигурации SSL:

listen 443 ssl http2;

или меняем spdy, если оно там стояло ранее.

PS: Если поддержка https на вашем сайте не настроена, то скорее настраиваем.

Confluence + nginx

Posted on by

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

В документации Atlassian рассматривается вариант проксирования траффика, в том числе энжинксом. Предлагаемый в документации способ предполагает правки в xml-конфиге самого Confluence, что есть не лучшее решение. Можно обойтись настройкой только nginx, без правок оригинального конфига конфлюенса, что обычно намного разумнее. Вот пример проксирования:

	location / {
		proxy_set_header X-Forwarded-Host $host;
		proxy_set_header X-Forwarded-Server $host;
		proxy_set_header X-Real-IP $remote_addr;
		proxy_set_header X-Forwarded-For $remote_addr;
		port_in_redirect off;
		proxy_pass http://confluence-vhost:8090;
		proxy_redirect http://confluence-vhost:8090/ /;
		proxy_connect_timeout 600;
		#proxy_redirect off;
	}

Аналогичным способом можно завернуть траффик в SSL и отдавать его через https, что существенно повышает безопасность работы.

Минимум настроек apache2 и nginx веб-серверов для повышения безопасности

Posted on by

Рассмотрим типовую схему веб-сервера: nginx используется в качестве фронтэнда (front-end), apache2 — бэкэнда (back-end). Установка пакетов из репозитариев дает стандартную конфигурацию, которая применима для сервера разработки и тестирования. Однако, стоковая конфигурация изначально подстроена под большой класс задач и требует доработки. В частности, в плане безопасности. Опишем минимум настроек, которые необходимо сделать, если настраиваемый сервер выходит в интернет для широкого использования.

apache2

Отключаем потенциально опасные и просто неиспользуемые модули, а также неиспользуемые подконфиги. Почти всегда можно (и нужно) отключить:

  • модуль autoindex, позволяющий просматривать содержимое директории при отсутствии индексного файла,
  • обработку cgi-bin, которая в deb-based системах лежит в конфиге serve-cgi-bin.conf и используется очень редко,
  • Другие неиспользуемые модули (список которых зависит от выкладываемого кода). Т.е. необходимо перешерстить директории mods-enabled, conf-enabled

На продакшн-сервере пользователю не нужно знать точную версию апача. Вообще, подобной информации должно отдаваться как можно меньше. Формат этой информации регулируется параметром ServerTokens, который по умолчанию обычно выставлен в OS и в результате веб-сервер выдает что-то вроде

Apache/2.4.10 (Debian) Server at ...

Этот параметр, как и некоторые другие настройки безопасности в debian-системах обычно находится в конфиге /etc/apache2/conf-available/security.conf. Переключаем в менее информативную и, соответственно, более безопасную версию:

#ServerTokens Minimal
#ServerTokens OS
#ServerTokens Full
ServerTokens Prod

Аналогичным образом стоит поступить с подписью сервера на «ошибочных» страницах

ServerSignature Off
#ServerSignature On

и трассировкой

TraceEnable Off

Последняя обычно уже отключена, но в этом необходимо убедиться.

Код некоторых выкладываемых сайтов может содержать скрытые файлы, вроде .gitignore, .svn и других, раскрывающих стуктуру кода. Их желательно отключить здесь же, в апаче, или в фронт-энде. Можно отключить сразу все скрытые файлы:

<DirectoryMatch "/\.">
	Require all denied
</DirectoryMatch>

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

Некоторые из правил для бэкэнда закрывают те же места, что и в фронтэнде. Даже если каким-то образом будет поломана конфигурация nginx, уязвимость все равно не реализуется.

Отключим доступ к скрытым файлам — в секции виртуалхоста добавляем:

RedirectMatch 404 /\..*$

Такие файлы нередко встречаются в проектах. В частности, системы контроля версий вроде git, svn. Эта метаинформация не должна попадать в прошакш, тем не менее следует превентивно защититься от такой возможности.

Если VirtualHost на сервере не один, то также не плохо будет раскомментировать секцию 


   AllowOverride None
   Order Deny,Allow
   Deny from all

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


	AllowOverride All
	Order Deny,Allow
	Allow from all

Я не описываю настройку прав доступа (пользователь:группа) на уровне ОС и файловой системы и использование модуля mpm_itk с директивой AssignUserID. Это тоже должно быть сделано для серверов, на которых такое разделение требуется.

nginx

Отключим отображение скрытых файлов:

location ~ /\. {
	deny all;
}

nginx используется как frontend, и если на нем отдается контент по https, то повышаем его безопасность. Для начала отключаем SSLv3 и другие небезопасные протоколы. Если nginx свежий, то в нем это уже и так отключено, поэтому лучше просто обновиться.
Генерируем параметры обмена ключами Diffie-Hellman (которые могут генерироваться достаточно долго, запаситесь временем)

openssl dhparam -out /etc/nginx/ssl/dhparam.pem 4096

и затем подключаем их в энжинксе

ssl_dhparam /etc/nginx/ssl/dhparam.pem;

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

ssl_ciphers 'AES256+EECDH:AES256+EDH:!aNULL';

Также имеет смысл включить кеширование

ssl_session_cache shared:SSL:10m;

После всех настроек желательно проверить их корректность в каком-нибудь сервисе, например, этом.

PHP

Как и в случае апача скрываем версию

expose_php = Off

В зависимости от задач можно отключить вывод ошибок:

error_reporting = 0
display_errors = Off

 

Проверки

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

HEAD example.com

Также побродим по сайту, в том числе по страницам, которые генерируют 4xx и 5xx ошибки, проверим, что версии софта не раскрываются и тем более не раскрывается внутренняя структура сервиса.

Завершающие замечания

Если на сервере хостится несколько сайтов, то многие из приведённых выше настроек повышают безопасность лишь частично. Сделать хорошую защиту между виртуалхостами на одной машине принципиально будет достаточно сложно. Если такое требуется — лучше смотреть в сторону виртуализации уровня операционной системы, по образцу OpenVZ или lxc.

Со временем пост будет пополняться.

htaccess-правила в apache2

Posted on by

Размещение правил в .htaccess лучше избегать, хотя бы по этой причине:

In the case of RewriteRule directives, in .htaccess context these regular expressions must be re-compiled with every request to the directory, whereas in main server configuration context they are compiled once and cached. Additionally, the rules themselves are more complicated, as one must work around the restrictions that come with per-directory context and mod_rewrite. Consult the Rewrite Guide for more detail on this subject.

Если коротко, то реврайты в .htaccess компилируются каждый раз при запросе к директории, тогда как в основном конфиге — только при запуске. На большом количестве запросов это может сделать апач быстрее.
Кроме того, размещение правил в основном конфиге безопаснее. В этом случае, поиск .htaccess отключается (что тоже имеет маленькое влияние на производительность — апач не ищет эти файлы).

Прописывайте правила в конфиге самого апача!

Как убрать фигурные кавычки WordPress

Posted on by

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

К счастью, это легко исправляется. Для этого в файле /wp-includes/formatting.php находим строки, отвечающие за замену кавычек:

/* translators: opening curly double quote */
$opening_quote = _x( '&#8220;', 'opening curly double quote' );
/* translators: closing curly double quote */
$closing_quote = _x( '&#8221;', 'closing curly double quote' );

и в них меняем символы ‘&#8220;’, ‘&#8221;’ на ‘&quot;’.

PS: Да, с обновлением WP, код может снова поменяться на оригинальный. По-хорошему, такое надо делать с помощью утилит diff и patch.

Основы безопасности сайта

Posted on by

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

Для решения как минимум нужно обеспечить условия:

  1. Исполняемый код должен быть защищен от записи от пользователя веб-сервера. Наиболее очевидный вариант как это сделать: назначить ему owner:group другого пользователя, от которого и работать с кодом на запись, а веб-серверу оставить права только на чтение.
  2. Запретить исполнение кода во всех директориях разрешенных на запись от веб-сервера (контент, кеш и подобные).
  3. Забыть про ftp и не сохранять пароли в файловых менеджерах. Взамен пользоваться scp/sftp, желательно с авторизацей по ключу.
  4. Для разных virtual hosts использовать разных системных пользователей, которые не читают данные друг друга.

Первый пункт из вышеприведенных гарантирует сохранность кода, даже в движке с дырами или бэкдором. Второй затрудняет исполнение залитых файлов: их можно исполнить с помощью include(), но для этого в read-only коде должна быть такая возможность (которая по сути является бэкдором).

Кроме этого, желательно:

  • Ограничить доступ в административные части сайта по IP-адресам на уровне веб-сервера только с рабочих компьютеров. Способ помогает даже при компрометации паролей, а также при человеческих конфликтах.
  • Использовать SSL-соединения (с префиксом https://) для входа в административные части и везде, где используется пароль для входа. Это защитит от компрометации паролей и данных по каналам связи, например при работе по незащищённому вайфаю.
  • Если точек входа на сайт небольшое количество, разрешить использовать только их, остальное запретить.