Безопасная эксплуатация Apache, часть 10: модуль mod_security (продолжение)

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

http://www.example.com/login.php?user=arpit';DELETE%20FROM%20users--

Атака может быть предотвращена с помощью следующей директивы:

SecFilter "delete[[:space:]]+from"

Как только соответствующий запрос захватывается фильтром, в журнале событий audit_log делается аналогичная запись: ======================================== Request: 192.168.0.207 - - [04/Jul/2006:23:43:00 +1200] "GET /login.php?user=tom';DELETE%20FROM%20users-- HTTP/1.1" 500 1215 Handler: (null) ---------------------------------------- GET /login.php?user=arpit';DELETE%20FROM%20users-- HTTP/1.1 Host: 192.168.0.100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive mod_security-message: Access denied with code 500. Pattern match "delete[[:space:]]+from" at THE_REQUEST mod_security-action: 500 HTTP/1.1 500 Internal Server Error Last-Modified: Fri, 21 Oct 2005 14:30:18 GMT ETag: "8238-4bf-833a5280" Accept-Ranges: bytes Content-Length: 1215 Connection: close Content-Type: text/html

В ответ на вредоносный запрос выполняется действие, заданное директивой SecFilterDefaultAction (запрос отклоняется, создается запись в журнале событий и взломщик получает сообщение об ошибке со статусом 500). Если вы хотите выполнить другое действие (например, выполнить переадресацию на HTML-страницу с нестандартным предупреждением), вы можете сформировать правило следующим образом:

SecFilter "delete[[:space:]]+from" log,redirect:http://example.com/invalid_request.html

Для предотвращения атак на основе SQL-инъекций, мы можем использовать некоторые другие директивы, такие, как:

SecFilter "insert[[:space:]]+into"
SecFilter "select.+from"
SecFilter "drop[[:space:]]table"
SecFilter create[[::space:]]+table
SecFilter update.+set.+=
SecFilter union.+select
SecFilter or.+1[[:space:]]*= [[:space:]]1
SecFilter '.+--
SecFilter xp_enumdsn
SecFilter xp_cmdshell
SecFilter xp_regread
SecFilter xp_regwrite
SecFilter xp_regdeletekey

Единственной проблемой директивы SecFilter является то обстоятельство, что с помощью нее исследуется весь запрос, а не его определенные поля. В данном случае является полезной директива SecFilterSelective; она позволяет задать те области, которые должны исследоваться. Ее синтаксис:

SecFilterSelective ОБЛАСТЬ КЛЮЧЕВОЕ_СЛОВО [ДЕЙСТВИЯ]

В данном случае параметр ОБЛАСТЬ определяет то, какая область запроса будет исследована. Следовательно, для противодействия атакам на основе SQL-инъекций, вы также можете использовать:

SecFilterSelective SCRIPT_FILENAME "login.php" chain
SecFilterSelective ARG_user "!^[a-zA-Z0-9\.@!]{1,10}$"

Для борьбы с XSS-атаками мы можем использовать следующие директивы:

SecFilter "<(.|\n)+>"
SecFilter "<[[:space:]]*script"
SecFilter "<script"
SecFilter "<.+>"

А также некоторые дополнительные фильтры, подобные следующим:

SecFilterSelective THE_REQUEST "<[^>]*meta*\"?[^>]*>"
SecFilterSelective THE_REQUEST "<[^>]*style*\"?[^>]*>"
SecFilterSelective THE_REQUEST "<[^>]*script*\"?[^>]*>"
SecFilterSelective THE_REQUEST "<[^>]*iframe*\"?[^>]*>"
SecFilterSelective THE_REQUEST "<[^>]*object*\"?[^>]*>"
SecFilterSelective THE_REQUEST "<[^>]*img*\"?[^>]*>"
SecFilterSelective THE_REQUEST "<[^>]*applet*\"?[^>]*>"
SecFilterSelective THE_REQUEST "<[^>]*form*\"?[^>]*>"

Для защиты кук, хранящих идентификаторы сессий PHP, от XSS-атак могут использоваться следующие фильтры:

SecFilterSelective ARG_PHPSESSID "!^[0-9a-z]*$"
SecFilterSelective COOKIE_PHPSESSID "!^[0-9a-z]*$"

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

SecFilter /etc/password
SecFilter /bin/ls

В данном случае взломщик может попытаться использовать строку, аналогичную /bin/./sh для обхода фильтра, но модуль mod_security автоматически приводит путь /./ к виду / и // к виду /, а также декодирует символы, к которым было применено URL-кодирование. Вы также можете использовать список разрешенных символов:

SecFilterSelective SCRIPT_FILENAME "directory.php" chain
SecFilterSelective ARG_dir "!^[a-zA-Z/_-\.0-9]+$"

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

SecFilterSelective THE_REQUEST "/^(etc|bin|sbin|tmp|var|opt|dev|kernel)$/"
SecFilterSelective ARGS "bin/"

В ходе процесса фиксации сессий, в одной из его фаз, взломщику необходимо каким-либо образом передать желаемый идентификатор сессии браузеру жертвы атаки. Мы можем нейтрализовать угрозу, применив следующие директивы:

# Слабая защита от XSS-атак, позволяющая использование стандартных HTML-тэгов
SecFilter "<[[:space:]]*script"
# Защита от XSS-атак (HTML/Javascript-инъекций)
SecFilter "<.+>"
# Блокировка передачи кук и идентификаторов сессий в строках URL
SecFilterSelective THE_REQUEST "(document\.cookie|Set-Cookie|SessionID=)"

Для противодействия атакам обхода путей или директорий чаще всего применяются следующие директивы:

SecFilter "\.\./"
SecFilterSelective SCRIPT_FILENAME "/scripts/foo.cgi" chain
SecFilterSelective ARG_home "!^[a-zA-Z].{15,}\.txt"

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

SecFilterSelective REQUEST_URI "^/(scripts|cgi-local|htbin|cgibin|cgis|win-cgi|cgi-win|bin)/"
SecFilterSelective REQUEST_URI ".*\.(bak|old|orig|backup|c)$"

Динамически создаваемые с помощью функции индексации директорий веб-страницы должны иметь заголовок, начинающийся со строки "Index of /". Мы можем использовать это обстоятельство как сигнатуру и добавить следующие директивы для обнаружения и запрета доступа к данной информации:

SecFilterScanOutput On
SecFilterSelective OUTPUT "\<title\>Index of /"

В последнем примере мы использовали возможность фильтрации выходных данных с помощью модуля mod_security и параметра OUTPUT, для активации которой следует добавить директиву SecFilterScanOutput On в файл настроек. Мы можем простейшим образом установить фильтр для отслеживания стандартных сообщений об ошибках базы данных, отправляемых клиенту, и генерации стандартного сообщения со статусом 500 вместо подробного сообщения:

SecFilterScanOutput On
SecFilterSelective OUTPUT "An Error Has Occurred" status:500
SecFilterSelective OUTPUT "Fatal error:"

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

SecFilterSelective OUTPUT "Volume Serial Number"
SecFilterSelective OUTPUT "Command completed"
SecFilterSelective OUTPUT "Bad command or filename"
SecFilterSelective OUTPUT "file(s) copied"
SecFilterSelective OUTPUT "Index of /cgi-bin/"
SecFilterSelective OUTPUT ".*uid\=\("

Модуль mod_security способен вмешиваться в процесс загрузки файлов с использованием запросов POST и запросов PUT с кодированием multi-part/form-data. Загрузка всегда производится в директорию для временных файлов. Вы можете выбрать эту директорию, использовав директиву SecUploadDir:

SecUploadDir /tmp

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

SecUploadApproveScript /usr/local/apache/bin/upload_verify.pl

В общем случае атаки удаленного включения файлов достаточно просто идентифицировать с помощью директивы, подобной следующей: SecRule ARGS "@rx (?i)^(f|ht)tps?://([^/])" msg:'Remote File Inclusion attack' # Обнаружение включений, содержащих IP-адреса SecRule ARGS "@rx (ht|f)tps?://([01]?\d\d?|2[0-4]\d|25[0-5])\.([01]?\d\d?|2[0-4]\d|25[0-5])\.([01]?\d\d?|2[0-4]\d|25[0-5])\.([01]?\d\d?|2[0-4]\d|25[0-5])" msg:'Remote File Inclusion attack' #Обнаружение включений, содержащих функцию 'include()' PHP SecRule ARGS "@rx \binclude\s*\([\w|\s]*(ht|f)tps?://" "msg:'Remote File Inclusion'" # Обнаружение включений, оканчивающихся символом '?' SecRule ARGS "@rx (ft|htt)ps?.*\?+$" msg:'Remote File Inclusion'

Вы можете заблокировать IP-адреса с помощью следующей команды:

SecFilterSelective "REMOTE_ADDR" "^192.168.1.1$"

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

SecFilterSelective "ARG_url" "c99"

Следующая директива помогает серверу в борьбе с исследованием реализации протокола HTTP и позволяет принимать только запросы с корректными версиями протокола:

SecFilterSelective SERVER_PROTOCOL !^HTTP/(0\.9|1\.0|1\.1)$

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

SecServerSignature "Microsoft-IIS/5.0"

Инъекция кода PHP не может быть осуществлена напрямую, но есть возможность сохранения кода на диск для его последующего исполнения в ходе атаки локального включения файлов. Следующее правило обнаружит попытку осуществления такой инъекции, но проигнорирует документы XML, использующие подобный синтаксис:

SecRule ARGS "@rx <\?(?!xml)"

Существуют три места, в которых, в зависимости от настроек, вы можете обнаружить журналы событий модуля mod_security:

• Журнал отладки модуля mod_security: Если запись отладочных сообщений включена с помощью директив SecFilterDebugLevel и SecFilterDebugLog, он содержит большое количество записей для каждого обработанного запроса. Каждая запись ассоциируется с уровнем важности в диапазоне от 0 (вообще без сообщений) до 4 (максимально подробные сообщения). В обычных условиях следует устанавливать уровень важности для сообщений отладки равным нулю и повышать его только в случаях отладки вашего набора правил.
• Журнал ошибок Apache: Некоторые сообщения из журнала отладки добавляются в журнал ошибок Apache (даже если вы установите уровень важности для сообщений отладки модуля mod_security равным 0). Обычно это сообщения, требующие внимания со стороны администратора, такие, как информация об отклоненных запросах.
• Журнал аудита модуля mod_security: Когда запись сообщений аудита включена (с помощью директив SecAuditEngine и SecAuditLog), модуль mod_security может записывать каждый запрос (и его тело в случае включения буферизации данных запросов) и соответствующий ему заголовок ответа.

Ниже представлен пример сообщения об ошибке, сгенерированного при обнаружении некорректных данных в куках:

[Tue Jun 26 17:44:36 2011] [error] [client 127.0.0.1]
mod_security: Access denied with code 500. Pattern match "!(^$|^[a-zA-Z0-9]+$)"
at COOKIES_VALUES(sessionid) [hostname "127.0.0.1"]
[uri "/test.php"] [unique_id 3434fvnij54jktynv45fC8QQQQAB]

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