Слайд 1OWASP ModSecurity Core Rule Set (CRS) Project
Ryan Barnett
OWASP CRS Project
Leader
Senior Security Researcher
Слайд 2Ryan Barnett - Background
Trustwave
SpiderLabs Research Team
Web application firewall research/development
ModSecurity Community
Manager
Interface with the community on public mail-list
Steer the internal development
of ModSecurity
Author
“Preventing Web Attacks with Apache”
Слайд 3Community Projects
Open Web Application Security Project (OWASP)
Project Leader, ModSecurity Core
Rule Set
Project Contributor, OWASP Top 10
Project Contributor, AppSensor
Web Application Security
Consortium (WASC)
Project Leader, Web Hacking Incident Database
Project Leader, Distributed Web Honeypots
Project Contributor, Web Application Firewall Evaluation Criteria
Project Contributor, Threat Classification
The SANS Institute
Courseware Developer/Instructor
Project Contributor, CWE/SANS Top 25 Worst Programming Errors
Слайд 4Session Outline
Обзор ModSecurity
Обзор Core Rule Set (CRS)
Основные категории определения уязвимостей
Дальнейшее
совершенствование CRS
CRS Demonstration Page
Дальнейшие направления развития
Слайд 5Обзор ModSecurity
(текущая версия 3.0 – 2018г.)
Слайд 6 Что такое ModSecurity?
Это open
source web application firewall (WAF) module для Apache web servers
www.modsecurity.org
Разделение
Rule и Audit Engines
Возможности создания логов полного запроса/ответа HTTP
Глубокий анализ HTTP и HTML
Надежный Parsing (form encoding, multipart, XML)
Язык Rules основан на событиях
Возможности предотвращения обхода (функции нормализации)
Дополнительные возможности
Transactional and Persistent Collections
Content Injection
Lua API
Слайд 7Основные возможности модуля:
Фильтрация запросов: входящие запросы анализируются перед тем, как
они будут обработаны веб-сервером или другими модулями.
Использовании технологии предотвращения обхода
проверок: все параметры нормализуются перед тем, как модуль анализирует входные параметры, для того, чтобы не допустить возможность обхода проверок.
Фильтрация запросов с учетом семантики НТТР протокола: может выполняться очень специфичная и точная фильтрация. Например, модуль может просматривать отдельные параметры или значения поименованных cookies.
Слайд 8Основные возможности модуля:
Анализ содержимого POST: модуль может анализировать содержимое, передаваемое
с использованием метода POST.
Аудит логов: полная детализация каждого запроса (включая
POST) может быть занесена в лог для последующего анализа.
Фильтрация сжатого содержимого: модуль анализирует запросы после того, как была выполнена декомпрессия.
Слайд 9Понятие регулярных выражений
Слайд 10Синтаксис языка ModSecurity’s Rules
Говорит ModSecurity где просматривать (например ARGS, ARGS_NAMES
or COOKIES).
Говорит ModSecurity как обрабатывать данные (например @rx, @pm or
@gt).
Говорит ModSecurity 0 что делать, если правило соответствует пакету (например deny, exec or setvar).
Слайд 11Основные этапы жизненного цикла запроса ModSecurity’s Apache
Слайд 12Обзор базового набора правил OWASP ModSecurity (Core Rule Set -
CRS)
Слайд 13Информация о проекте
http://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project
Слайд 14Что такое Core Rule Set (CRS)?
Общий, plug-n-play набор WAF-правил
Позволяет выбирать
режим выполнения
Стандартный vs. Определение аномалий
Категории обнаружения:
Корректность протокола
Идентификация вредоносного клиента
Сигнатуры общих
атак
Сигнатуры известных уязвимостей
Доступ Trojan/Backdoor
Утечка данных во вне
Утилиты и скрипты антивируса и DoS
Слайд 15Начальная конфигурация
После распаковки следует отредактировать основной конфигурационный файл
modsecurity_crs_10_config.conf
Настроить следующие элементы
Способ
обнаружения – стандартный или определение аномалий
Уровни строгости определения аномалий
Необходимость блокировки
(Enable/Disable)
Уровни порогов блокировок
Paranoid режим – агрессивная инспекция
Установки политики HTTP
Выбор, где хранить логи событий (Apache error_log и/или ModSecurity’s audit log)
Слайд 16Режим традиционного определения
Концепция «самодостаточных» правил
IDS/IPS режим с “самодостаточными” правилами
Подобно самому
HTTP – правила не поддерживают состояния
Нет разделяемой информации между правилами
Если
правило срабатывает, оно будет выполнять disruptive/logging действие
Легкость освоения новыми пользователями
Не оптимально с точки зрения управления правилами (ручная обработка ложных позитивностей /исключений)
Не оптимально с точки зрения безопасности
Не все сайты имеют одинаковые риски безопасности
Сообщения малой важности чаще всего игнорируются
Слайд 17Режим определения аномалий
Концепция совместно выполняющихся правил
Усовершенствованный режим инспектирования/обнаружения
Задержка блокировки
Правила устанавливают
транзакционные переменные (tx) для хранения временных мета-данных о соответствии правилу
Правила
также приведут к возрастанию обнаружений и атак, связанных с аномальным поведением
Правила, усиленные аномальными оценками, принимают решение, запрещать ли транзакции при завершении входящего запроса.
modsecurity_crs_49_inbound_blocking.conf
Слайд 18Аномальное поведение – просмотр отладочных логов
Слайд 20Условные правила (Weak Sigs)
Пример SQL Injection
Агрегация индикаторов для определения атаки
Строгие
индикаторы
Ключевые слова, такие как: xp_cmdshell, varchar,
Последовательности, такие как: union
…. select, select … top … 1
Amount: script, cookie и document появляются в некотором поле ввода
Слабые индикаторы – мета-символы
--, ;, ', …
CRS используют только слабые сигнатуры
Слайд 22Логи событий
Стандартные vs. Коррелирующие события
Стандартный режим
Правила записывают данные о
событии как в Apache error_log, так и в ModSecurity Audit
log
Коррелирующий режим
Базовые правила анализируют ссылки и не записывают их непосредственно в Apache error_log
Коррелирующие правила на фазе создания логов анализируют входящие /исходящие события и создают специальные события
modsecurity_crs_60_correlation.conf
Слайд 23Входящая /исходящая корреляция
Сопоставление входных и выходных данных для улучшенного принятия
решений
Была ли входящая атака?
Был ли HTTP Status Code Error (4xx/5xx
уровень)?
Была ли утечка прикладной информации?
Возможности корреляции лучше анализируют ответ
Ошибка в приложении без входной атаки -> Contact Ops
Входная атака + выходная ошибка -> Contact Security
Слайд 24Рейтинг важности событий
Коррелирующие события
0: Emergency – генерируется при корреляции (входная
атака + выходная утечка информации)
1: Alert – генерируется при корреляции
(входная атака + выходная ошибка прикладного уровня)
Не коррелирующие события
2: Critical – самый высокий уровень важности, возможно, без корреляции. Обычно это генерируется правилами веб-атаки (40 level files)
3: Error – обычно генерируется правилами выходной утечки информации (50 level files)
4: Warning – генерируется правилами при обнаружении вредоносного клиента (35 level files)
5: Notice – генерируется политикой протокола
6: Info – генерируется при использовании клиентом поисковых engine (55 marketing file)
Слайд 25Сообщения о коррелирующих события
Слайд 26Механизмы определения: нарушения протокола
Уязвимости протокола, такие как расщепленный ответ, Request
Smuggling, преждевременное завершение URL
Длина содержимого только для не GET/HEAD методов
Не
ASCII символы или кодировки в заголовках
Корректное использование заголовков (например, длина содержимого является числом)
Доступ через прокси
modsecurity_crs_20_protocol_violations.conf
Запросы атакующего распознаются автоматически
Пропуск заголовков таких, как Host, Accept, User-Agent
Хост является IP-адресом (стандартный метод распространения червей)
modsecurity_crs_21_protocol_anomalies.conf
Слайд 27Механизмы определения: политики протокола
Обычно политика зависит от приложения
Некоторые ограничения могут
применяться в целом
Для определенных окружений может быть создан белый список
Ограничения
на размер
Размер запроса, размер загрузки
# параметров, длина параметров
modsecurity_crs_23_request_limits.conf
Элементы, которые могут быть как разрешены, так и ограничены
Методы – позволять или ограничить WebDAV, блокировать «плохие» методы, такие как CONNECT, TRACE или DEBUG
Расширения файлов – backup файлы, файлы БД, ini-файлы
Content-Types (и некоторые другие заголовки)
Modsecurity_crs_30_http_policy.conf
Слайд 28Механизмы определения: вредоносные клиенты
Не помогает против атак на определенные цели,
но помогает против общей вредоносной интернет-активности
Загрузка большого количества чуши и
шума
Эффективно против спама
Уменьшает количество событий
Определение вредоносных роботов
Уникальные атрибуты запроса: User-Agent header, URL, Headers
Черный список IP-адресов
Определение, основанное на скорости (rate)
Определение сканеров безопасности
Блокировка может сбить с толку ПО тестирования безопасности (WAFW00f)
modsecurity_crs_35_bad_robots.conf
Слайд 29Механизмы определения: атаки прикладного уровня
Определение атак прикладного уровня, таких, которые
описаны в OWASP top 10
SQL injection и blind SQL
injection
Cross site scripting (XSS)
OS command injection и удаленное выполнение команд
Удаленное включение файла
modsecurity_crs_40_generic_attacks.conf
modsecurity_crs_41_sql_injection_attacks.conf
modsecurity_crs_41_xss_attacks.conf
Слайд 30Сигнатуры известных уязвимостей
SpiderLabs имеет авторизацию от ET для преобразования их
правил для Snort и включения их в CRS
http://www.emergingthreats.net/
Конвертирование следующих
файлов правил
emerging-web_server.rules
emerging-web_specific_apps.rules
Идентификация атак на известные уязвимости
Поднятие уровня угрозы
Если выполнено корректно, то уменьшение ложных срабатываний
CRS комбинирует что определять в содержимом атаки и где расположены уязвимые данные
Слайд 31Пример правила обнаружения угроз
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
(msg:"ET WEB_SPECIFIC_APPS 20/20 Auto Gallery SQL Injection Attempt -- vehiclelistings.asp
vehicleID SELECT"; flow:established,to_server; uricontent:"/vehiclelistings.asp?"; nocase; uricontent:"vehicleID="; nocase; uricontent:"SELECT"; nocase; pcre:"/.+SELECT.+FROM/Ui"; classtype:web-application-attack; reference:cve,CVE-2006-6092; reference:url,www.securityfocus.com/bid/21154; reference:url,doc.emergingthreats.net/2007504; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/WEB_SPECIFIC_APPS/WEB_2020_Auto_gallery; sid:2007504; rev:5;)
Расположение вектора атаки –
URI + Parameter
PCRE –
Слабая сигнатура
Слайд 32Преобразование правила обнаружения угроз
# (sid 2007508) ET WEB_SPECIFIC 20/20 Auto
Gallery SQL Injection Attempt -- vehiclelistings.asp vehicleID
SecRule REQUEST_URI_RAW "(?i:\/vehiclelistings\.asp)" "chain,phase:2,block,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:normalisePathWin,capture,ctl:auditLogParts=+E,nolog,auditlog,logdata:'%{TX.0}',id:sid2007508,rev:3,msg:'ET
WEB_SPECIFIC 20/20 Auto Gallery SQL Injection Attempt -- vehiclelistings.asp vehicleID ',tag:‘web-application-attack',tag:'url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/WEB_SQL_INJECTION/WEB_2020_Auto_gallery'"
SecRule &TX:'/SQL_INJECTION.*ARGS:vehicleID/' "@gt 0" "setvar:'tx.msg=ET WEB_SPECIFIC 20/20 Auto Gallery SQL Injection Attempt -- vehiclelistings.asp vehicleID
',setvar:tx.sqli_score=+1,setvar:tx.anomaly_score=+20,setvar:tx.%{rule.id}-SQL_INJECTION/SQL_INJECTION-%{matched_var_name}=%{matched_var}"
Проверка URI запроса
Проверка расположения вектора атаки из сохраненных TX SQL Injection данных
Слайд 33Механизмы обнаружения: Trojans/Backdoors
Основная проблема для окружений, выполняющих хостинг
Разрешены загрузки
Некоторые сайты
могут быть юезопасны, в то время как другие нет
Определение загрузок
Проверка
загрузок файлов, содержащих вирусы (например, WORD docs)
util/modsec-clamscan.pl
Проверка загрузок http-страниц c backdoor
Определение доступа
Известные сигнатуры (x_key заголовок)
Generic file management output (gid, uid, drwx, c:\)
modsecurity_crs_45_trojans.conf
Слайд 34Механизмы обнаружения: утечка информации
Мониторинг исходящих прикладных данных
Коды статуса ответа HTTP
Error
Утечка информации через SQL
Дампы стека
Утечка исходного кода
Последняя линяя обороны, если
всё остальное вышло из строя
Обеспечить обратную связь с разработчиками приложения
Важно для приобретения опыта клиентами
Осложняет жизнь хакерам (если используется болкировка)
modsecurity_crs_50_outbound.conf
Слайд 36Самые последние улучшения
Lua портировал of PHPIDS Converter.php код
Улучшенные функции нормализации
Более
точное использование PHPIDS-фильтров
Раздельное обнаружение содержимого атаки
Экспериментальные правила
Обнаружение содержимого общих атак
Демонстрационная
страница CRS
Тегирование заголовка запроса
Слайд 37Lua портировал PHPIDS
http://phpids.net/
~70 правил регулярных выражений для определения содержимого общих
атак
XSS
SQL Injection
RFI
Фильтры тяжело тестировать и часто изменять
Trustwave SpiderLabs работает с
PHPIDS для портирования кода в Lua для использования с ModSecurity’s API
https://svn.php-ids.org/svn/trunk/lib/IDS/Converter.php
https://svn.php-ids.org/svn/trunk/lib/IDS/default_filter.xml
Thanks to Mario Heiderich
Слайд 38Lua портировал PHPIDS
Пример функций нормализации
--[[ Make sure the value to
normalize and monitor doesn't contain Regex DoS
--[[ Check for comments
and erases them if available ]]
--[[ Strip newlines ]]
--[[ Checks for common charcode pattern and decodes them ]]
--[[ Eliminate JS regex modifiers ]]
--[[ Converts from hex/dec entities ]]
--[[ Normalize Quotes ]]
--[[ Converts SQLHEX to plain text ]]
--[[ Converts basic SQL keywords and obfuscations ]]
--[[ Detects nullbytes and controls chars via ord() ]]
--[[ This method matches and translates base64 strings and fragments ]]
--[[ Strip XML patterns ]]
--[[ This method converts JS unicode code points to regular characters ]]
--[[ Converts relevant UTF-7 tags to UTF-8 ]]
--[[ Converts basic concatenations ]]
--[[ This method collects and decodes proprietary encoding types ]]
Слайд 39Пример фильтра PHPIDS
1
)|(?:[^\w\s]\s*\/>)|(?:>")]]>
finds html breaking injections including whitespace attacks
xss
csrf
4
Слайд 40Примеры фильтров конвертации PHPIDS
SecRule TX:'/^(QUERY_|REQUEST_|ARGS:).*_normalized/' "(?:\]*)t(?!rong))|(?:\
and XML wrapped HTML',id:'9000033',tag:'WEB_ATTACK/XSS',logdata:'%{TX.0}',severity:'2',setvar:'tx.msg=%{rule.id}-%{rule.msg}',setvar:tx.anomaly_score=+4,setvar:'tx.%{tx.msg}-WEB_ATTACK/XSS-%{matched_var_name}=%{tx.0}'"
SecRule TX:PARANOID_MODE "@eq 1" "chain,phase:2,t:none,logdata:'%{TX.0}',severity:'2',pass,nolog,auditlog,msg:'Detects obfuscated script
tags and XML wrapped HTML',id:'9000033',tag:'WEB_ATTACK/XSS'"
SecRule ARGS|REQUEST_BODY|REQUEST_URI_RAW "(?:\<\w*:?\s(?:[^\>]*)t(?!rong))|(?:\
Слайд 41Код Centrifuge
Negative security approach to combating XSS and SQL Injection
is doomed to fail…
Unlimited ways to write functionally equivalent code
Obfuscation
methods, however often have certain characteristics
PHPIDS has an interesting approach to identify attack payloads through heuristics called Centrifuge
Analysis of the use of special characters
Ratio between the count of the word characters, spaces, punctuation and the non word characters
If <3.49 = malicious
Normalization and stripping of any word character and spaces including line breaks, tabs and carriage returns
Regex check in default_filters.xml catches results
Слайд 43Экспериментальные общие правила обнаружения
Два новых экспериментальных /beta общих правила обнаружения
Optional_rules/modsecurity_crs_40_experimental.conf
Использование
ограничений на символы для обнаружения аномалий
Анализ значений и типов мета-символов,
присутствующих с содержимом
Тестирование, как будет показано далее, что обнаружение является корректным, за исключением текстовых полей, допускающих ввод в свободной форме.
Возможность приспособить определение аномалий для своего сайта
Повторное использование символов, не имеющих изображение
В настоящий момент создаются оповещения (alerts), если найдено 4 или более специальных символов в строке таблицы
Слайд 45Демонстрационная страница CRS
http://www.modsecurity.org/demo/
Слайд 46Демонстрационная страница CRS
Запрос первым делом проходит через первую страницу CRS
и затем запрос пропускается через прокси и передается странице PHPIDS
http://demo.php-ids.org/
Затем
инспектируются входные и выходные значения, после чего предоставляются результаты
CRS определил атаку
CRS не нашел что-либо вредоносное, а PHPIDS нашел
Ни CRS, ни PHPIDS не нашли ничего вредоносного
Предоставляется ссылка на отчет ложных срабатываний для JIRA ticketing системы
https://www.modsecurity.org/tracker/browse/CORERULES
Таким способом определено >6700 атак
Слайд 50Демонстрационная страница CRS
В случае распределенной архитектуры можно совместно использовать данные
WAF с защищаемых хостов
Аналогично SMTP SPAM-данные в mime-headers
optional_rules/modsecurity_crs_49_header_tagging.conf
Отображение в точки
обнаружения AppSensor – RP2 (подозрительное поведение внешнего пользователя)
Слайд 51GET /path/to/foo.php?test=1%27%20or%20%272%27=%272%27;-- HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.9.1.5) Gecko/20091109 Ubuntu/9.10 (karmic) Firefox/3.5.5
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
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
X-WAF-Events:
TX: / 999935-Detects common comment types-WEB_ATTACK/INJECTION-ARGS:test, TX:999923-Detects JavaScript location/document property access and window access obfuscation-WEB_ATTACK/INJECTION-REQUEST_URI_RAW, TX:950001- WEB_ATTACK/SQL_INJECTION-ARGS:test
X-WAF-Score: Total=48; sqli=2; xss=
Connection: Keep-Alive
Пример тегирования заголовка
Слайд 53Направления будущего развития
Превентивный XSS with Content Injection
Javascript Sandboxing with Active
Content Signatures
http://blog.modsecurity.org/2010/09/advanced-topic-of-the-week-xss-defense-via-content-injection.html
http://www.modsecurity.org/demo/demo-deny-noescape.html
Реализация OWASP AppSensor точек обнаружения
We currently have some mappings
for existing events
Will be using Lua to implement other aggregate/behavioral/trend detection Points
Слайд 54Call for Community Help
We have made great strides with CRS
v2.0 but there is still much work to be done
Test
out the CRS demo page and report any issues found either to the mail-list or to JIRA
Need Rule Documentation help
Please sign up on our project mail-list if you want to help
https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
Слайд 55Questions?
Email – Ryan.Barnett@owasp.org
Twitter - @ryancbarnett / @modsecurity