Защита Apache, Nginx и IIS

Для кого эта статья?

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

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

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

С браузером все понятно, он умеет обрабатывать эти запросы, но как удаленный сервер прочитает запрос и в целом как он будет выстраивать общение с клиентом? Ответ прост - веб-сервер. 

Что такое веб-сервер?

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

Самыми популярными веб-серверами на данный момент являются:

1. Apache
2. Nginx
3. IIS

Давайте чуть подробнее рассмотрим каждый из них

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

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

Nginx крайне быстр в обработке запросов и сильно экономит ресурсы сервера. Он хорошо оптимизирован и не создаёт отдельный процесс для каждого клиента, а направляет их в один и обрабатывает. Обычно nginx используется как балансировщик нагрузки (об этом мы поговорим ниже) или в роли веб сервера, отвечающего за статический контент (видео, картинки), ведь nginx лучше работает с медленным интернетом клиента, поэтому ему проще загрузить статические файлы, нежели Apache.

Что за балансировщик нагрузки?

На многих веб приложениях используется схема:

Client -> Nginx -> Apache

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

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

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

Какие ошибки могут привести к компрометации веб-сервера и как их предотвратить?

1. Наличие баннеров с версией сайта

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

Решение для Apache:

1. Для начала давайте отправим запрос на сервер с неправильным методом GET_CODEBY:

2. Чтобы убрать строку с версией сервера нам нужно открыть файл:

sudo nano /etc/apache2/conf-enabled/security.conf

И поменять значение строк с этих:

На эти:

После этих изменений ServerTokens будет показывать только тип веб сервера, а ServerSignature не будет показывать версию

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

service apache2 restart

А теперь посмотрим на результат:

Решение для Nginx

1. Вновь отправим неправильный запрос на веб-сервер Nginx:

2. Чтобы убрать баннеры, нужно изменить файл:

sudo nano /etc/nginx/nginx.conf

Теперь просто раскомментируйте эту строку: (уберите перед строкой знак решетки)

3. Не забудьте перезагрузить сервер

service nginx restart

Результат:

 

Решение для IIS

Из коробки в IIS нельзя убрать версию сервера из ответа, нужно установить расширение (https://www.iis.net/downloads/microsoft/url-rewrite)(конечно, можно впринципе обойтись и без расширения, банально использя файл web.config, но для разнообразия мы поработаем с GUI интерфейсом) 

После его установки делаем следующие шаги:

1. Переходим в переопределитель

 

2. Переходим: Добавить правило(правый верхний угол) -> Пустое правило

 

3. Кликаем «применить правило» в правом верхнем углу и наблюдаем изменения

2. Установите mod_security/mod_evasive

ModSecurity - это программа, реализующая функции межсетевого экрана

Настройка для apache

1. Для начала нам нужен пакет с самим mod_security

sudo apt-get install libapache2-mod-security2

2. Перезапустим сервер

service apache2 restart

3. Теперь нам нужно разобраться с правилами WAF

Дефолтный набор правил нас не устраивает, нас устроит набор правил от OWASP(https://github.com/SpiderLabs/owasp-modsecurity-crs)

Давайте заменим файлы с дефолтных на файлы OWASP.

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

mv /etc/modsecurity/modsecurity.conf-recommended  modsecurity.conf

Скопируем репозиторий

git clone https://github.com/SpiderLabs/owasp-modsecurity-crs

Далее переместим правила:

cd owasp-modsecurity-crs

mv crs-setup.conf.example /etc/modsecurity/crs-setup.conf

mv rules/ /etc/modsecurity/

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

/etc/apache2/mods-available/security2.conf

 

Mod_evasive - программа, защищающая ваш сервер от DOS, DDOS и BruteForce атак

1. Установите саму программу

apt install libapache2-mod-evasive

2. Включите правила для evasive в файл apache2.conf

Попробуйте часто обновлять страницу и вы увидите это:

Установка на IIS

1. Скачайте сам mod_security(https://github.com/SpiderLabs/ModSecurity/releases) под сборку IIS

2. Далее откройте папку с установленным ModSecurity(в моем случае это C:\Program Files\ModSecurity IIS) и найдите в ней файл modsecurity.conf

3. Поменяйте параметр SecRuleEngine с DetectionOnly на On в этом файле:

 

4. Далее введите в терминал команду, которая даст необходимые разрешения

cacls C:\inetpub\temp /e /p IIS_IUSRS:f

5. Перезагрузите сервер
6. Закройте важные директории

Допустим, в нашем веб приложении имеются те файлы, которые мы не хотим выставлять на всеобщее обозрение (банально то же содержимое папки wordpress). По умолчанию мы все так же сможем получить доступ из браузера к содержимому этой папки (например /var/www/html/admin/), если вы не закроете к ней доступ. Закрыть папки вы можете используя следующий алгоритм:

Для Apache:

1. Папка password, которую мы закроем:

 

2. Откройте файл /etc/apache2/apache2.conf и впишите данные строки в файл:

3. Вместо директории с паролями вы можете вписать туда любую другую папку, которую вы хотите закрыть

Теперь давайте взглянем на результат:

В nginx:

1. Создадим директорию password-nginx, содержащую чувствительную информацию:

Теперь давайте закроем от посторонних глаз содержимое этой директории

2. Для этого нам нужно перейти в файл /etc/nginx/sites-available/default, куда мы добавим следующие строки(выделены белым):

При попытке получить доступ к папке и ее содержимому будет отправлена ошибка 404

 

Решение для IIS

Основным файлом конфигураций для IIS является файл web.config(C:\inetpub\wwwroot\web.config)

1. Давайте поменяем его так, чтобы закрыть новую созданную директорию test

2. Перезагрузим сервер

3. Получаем результат

 

Защита папок паролем:

Для apache:

1. Внесите изменения в файл /etc/apache2/apache2.conf

Поменяйте на выделенной белым цветом строке значения с None на All

 

2. В папке, которую вы хотите защитить паролем(в моем случае это папка /test-htpass с текстовым файлом внутри), нам нужно создать файл .htaccess с таким содержимым:

3. Создайте файл и директорию, в которой будет храниться .htpasswd(в моем случае это домашняя папка)

cd ~ && sudo htpasswd -c -B .htpasswd admin

Давайте проверим результат:

Для Nginx все действия идентичны, но изменяется файл конфигураций по следующему пути: /etc/nginx/sites-available/default

Результат:

 

3. Обновления ПО

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

4. Минимальная защита от XSS

Есть множество технологий для защиты от XSS, те же WAF и SOP. Но минимальным рубежом защиты будут добавления специальных заголовков. Чтобы включить защиту нужно добавить следующий заголовок в файл apache2.conf:

Для nginx все то же самое, только с файлом /etc/nginx/nginx.conf

5. Защититесь от Http Request Smuggling

В самом начале статьи я рассказывал про популярную связку из nginx -> apache, где nginx является фронтенд сервером. Но эта связка подвержена крайне опасной уязвимости Http Request Smuggling.

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

Есть два метода для того, чтобы показать окончание запроса:

1. Transfer-Encoding: chunked

Особенностью Transfer-Encoding является разделение запроса на фрагменты, каждый из которых оканчивается на 0

2. Content-Length: <длина запроса в байтах>

Атака базируется на одновременном использовании этих заголовков, скрывая вредоносный запрос в теле легитимного

Рассмотрим самую простую схему. Например, на сервере, где висит уязвимое веб приложение есть дыра(допустим, RCE), но вполне вероятно, что WAF, так же висящий на сервере отклонит вредоносный запрос с пейлоадом, но мы знаем, что в инфраструктуре возможна схема с балансировщиком, соответственно мы сделаем примерно такой запрос:

GET /home HTTP/1.1
Host: vulnerable-website.com
Content-Length: 13
Transfer-Encoding: chunked

0

POST /home?xss=payload HTTP/1.1
Host: vulnerable-website.com

Данный запрос при наличии HRS будет сначала доставлен на nginx, который смотря на content-lenght(обрабатывает только этот заголовок) увидит, что запрос идет вплоть до конца второго(вредоносного запроса) и пошлет его уже на apache(игнорирует Content-Length и смотрит только на Transfer-Encoding) , который разобьет запрос на два запроса(разделенных нулем), один из которых будет вредоносным

Такое поведение может помочь обойти WAF для доставки пейлоада, ибо вредоносный запрос скрыт в легетимном

Ряд атак, которые можно произвести при наличии HRS:

- XSS

- Обход WAF

- Захват сеанса

- DNS cache poisoning

Как защитить сервер от HRS?

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

Ответ: Используйте HTTP/2, он из коробки более совершенно обрабатывает запросы и избегает атак HRS

Чтобы включить HTTP/2 в Apache у вас должен быть ssl сертификат

Если вы создали сертификат при помощи LetsEncrypt, то перейдите по пути /etc/apache2/sites-enabled/mysite-le-ssl.conf в конфиге которого вы напишите новую строчку:

Protocols h2 http/1.1

Сохраните изменения и перезагрузите сервер

Для nginx

Тоже нужен ssl сертификат, но для включения http/2 достаточно поменять строки после слова ssl на http2 в файле /etc/nginx/sites-available/default