Использование snort для блокирования атак скрипт-киддисов

    Данная статья не претендует на полноту описания системы snort, а всего лишь предлагает пользователю готовое решение для защиты своего сервера от маленьких шаловливых ручек.
    Я лично ставил всё это дело на OpenBSD, но от смены системы суть не меняется.

    Лирическое отступление

    snort (http://snort.org) — система обнаружения атак (NIDS) для сетей ipv4 на базе libpcap. Сам по себе — обычный tcpdump. Но к нему можно создавать правила, по которым он будет блокировать вредный траффик и создавать события безопасности (alert).
    У меня стоит связка snort-сенсоров, связанных между собой через коллектор на базе дописанного prelude (http://prelude-ids.org). Все правила написаны собственноручно.
    Результаты (по статистике работы за 4 месяца):
    Ложных срабатываний — около 2% (средний траффик — 120 мбит/сек).
    Блокировок за день — около 15.
    Количество пропущенных атак — 0 (после внедрения системы безопасности ни один сервер не был взломан. Под защитой стоят хостинг и VDS).
    В дополнение дописаны модули автоабьюса по базе данных RIPE и блокировки траффика на корневой циске.

    Итак, имеем:
    Некий сервер с установленным на нём snort-inline (в случае *BSD устанавливается из портов, в случае Linux'а — из исходников с указанием опции --enable-inline).
    Для начала настраиваем сам snort (для вашей ОС пути могут отличаться — смотрите дефолтный конфиг). /etc/snort/snort.conf

    # сокращённый вариант конфига - правила от SourceFire я не использую.
    var HOME_NET 1.2.3.4 # ip-адрес нашего сервера
    var EXTERNAL_NET any
    var HTTP_SERVERS $HOME_NET
    portvar HTTP_PORTS [80,8080]
    # путь к папкам с правилами
    var RULE_PATH /etc/snort/rules
    var PREPROC_RULE_PATH /etc/snort/preproc_rules
    # запрещаем ошибки обработки пакетов - они нафиг не нужны
    config disable_decode_alerts
    config disable_tcpopt_experimental_alerts
    config disable_tcpopt_obsolete_alerts
    config disable_tcpopt_ttcp_alerts
    config disable_tcpopt_alerts
    config disable_ipopt_alerts
    # папки с процессорами
    dynamicpreprocessor directory /usr/local/lib/snort_dynamicpreprocessor/
    dynamicengine /usr/local/lib/snort_dynamicengine/libsf_engine.so
    # фрагментация пакетов - нужен для tcp
    preprocessor frag3_global: max_frags 65536
    preprocessor frag3_engine: policy linux
    # tcp и udp процессор - нужен для httpinspect
    preprocessor stream5_global: max_tcp 8192, track_tcp yes, track_udp no
    preprocessor stream5_tcp: policy linux
    #preprocessor stream5_udp: ignore_any_rules
    # а вот и сам http_inspect
    # замените unicode.map 1251 на свою дефолтную кодировку
    preprocessor http_inspect: global iis_unicode_map unicode.map 1251
    preprocessor http_inspect_server: server default profile apache no_alerts ports { 80 8080 8180 } oversize_dir_length 500
    output alert_syslog: LOG_ALERT
    # инклудим классификаторы траффика
    include classification.config
    include reference.config
    # и файл с правилами
    include $RULE_PATH/local.rules


    И создаём $RULE_PATH/local.rules:
    # убиваем UNION SQL injection
    drop tcp any any -> $HOME_NET $HTTP_PORTS (msg:"UNION SQL Injection";uricontent:"union";nocase;uricontent:"select";nocase;sid:1;gid:666;)
    # убиваем blind SQL injection
    drop tcp any any -> $HOME_NET $HTTP_PORTS (msg:"Blind SQL Injection";uricontent:"ascii";nocase;uricontent:"substr";nocase;uricontent:"select";nocase;sid:2;gid:666;)
    # убиваем XSS/CSS
    drop tcp any any -> $HOME_NET $HTTP_PORTS (msg:"XSS/CSS attack";uricontent:"";nocase;sid:4;gid:666;)
    # убиваем хитрый XSS/CSS
    drop tcp any any -> $HOME_NET $HTTP_PORTS (msg:"XSS/CSS attack";pcre:"/GET \/.*\?.*=(javascript:|onclick=|onmouseover=|onmouseout=|onload=).*\n/i";sid:5;gid:666;)
    # убиваем ../../../etc/passwd
    drop tcp any any -> $HOME_NET $HTTP_PORTS (msg:"PHP include attack";uricontent:"=../..";sid:6;gid:666;)

    Запускаем snort
    snort -i em0 -c /etc/snort/snort.conf -D
    Проверяем и радуемся.
    Прим. Тут не затронуты вопросы безопасности POST-запросов, но нет ничего невозможного.

    P.S. Опубликована данная статья по просьбе некоего kreon'а, который на Хабре не присутствует.
    Поделиться публикацией

    Похожие публикации

    Комментарии 39

      +2
      Немного б побольше информации в плане: что такое snort, от каких атак спасает, какие результаты
        0
        Опубликовал дополнение автора.
      • НЛО прилетело и опубликовало эту надпись здесь
          0
          >Прим. Тут не затронуты вопросы безопасности POST-запросов, но нет ничего невозможного.
          Так и отличает :)
            +1
            нескрипткиддисы введут uni/**/on :)
            Кстати, как WAF от битрикса на СС себя показал, никто не в курсе?
            • НЛО прилетело и опубликовало эту надпись здесь
            +1
            что то _очень_ мало информации, про _POST бы описали еще.
            • НЛО прилетело и опубликовало эту надпись здесь
                0
                adz.kreon@gmail.com
                • НЛО прилетело и опубликовало эту надпись здесь
                    +2
                    Благодарю за инвайт.
                    Надо собрать весь материал в кучу — и можно писать большую статью о снорте и его использовании.
                0
                Сильно кушает проц? Давно на него смотрел, но машинка делается 400 мбит трафика… не загнется ли железка…
                  +2
                  Xeon E5345 2.33 Ggz/1Gb mem
                  OpenBSD 4.5
                  5 snort'ов по разным углам + 1 центральный, получающий весь траффик хостинга через cisco monitor. Траффик указан выше.
                  uptime: 3:48PM up 85 days, 1:49, 3 users, load averages: 0.21, 0.16, 0.10
                    0
                    BTW, (средний траффик — 120 мбит/сек) — ето автор явно привел исход а не вход. Снорт исход в такой конфигурации никак не слушает :)
                    Сколько входа и какой packet rate?
                      0
                      Это на мониторе с циски на главный снорт уходит — просто завернут весь траффик с влана.
                      А исход снорт тоже слушает — например вопит если где-то видит ифрейм или признаки Зевса (который Kaspersky.Zbot).
                        0
                        Я так понимаю трафик span'итса. Как на интерфейсе em0 возникает исходящий траффик? Интересна физика процесса :)
                          0
                          Вопрос снят :)
                            +1
                            На корневом свитче
                            !
                            monitor session 1 source vlan 226
                            monitor session 1 destination interface Gi0/11

                            Вот так :)
                            em0 не имеет своего адреса и просто работает в promisc-mode, получая всё, что пролетает мимо.
                    +2
                    По снорту лучшее и исчерпывающее руководство — Snort Cookbook от O'Reilly
                      +2
                      Ето защита для китайской молодежи :) Для того чтоб почуствовать разницу приведу
                      пример дефолтового регекспа от mod_security для SQL injection:
                      SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|XML:/*|!REQUEST_HEADERS:Referer "(?:\b(?:(?:s(?:elect\b(?:.{1,100}?\b(?:(?:length|count|top)\b.{1,100}?\bfrom|from\b.{1,100}?\bwhere)|.*?\b(?:d(?:ump\b.*\bfrom|ata_type)|(?:to_(?:numbe|cha)|inst)r))|p_(?:(?:addextendedpro|sqlexe)c|(?:oacreat|prepar)e|execute(?:sql)?|makewebtask)|ql_(?:longvarchar|variant))|xp_(?:reg(?:re(?:movemultistring|ad)|delete(?:value|key)|enum(?:value|key)s|addmultistring|write)|e(?:xecresultset|numdsn)|(?:terminat|dirtre)e|availablemedia|loginconfig|cmdshell|filelist|makecab|ntsec)|u(?:nion\b.{1,100}?\bselect|tl_(?:file|http))|group\b.*\bby\b.{1,100}?\bhaving|load\b\W*?\bdata\b.*\binfile|(?:n?varcha|tbcreato)r|autonomous_transaction|open(?:rowset|query)|1\s*=\s*1|dbms_java)\b|i(?:n(?:to\b\W*?\b(?:dump|out)file|sert\b\W*?\binto|ner\b\W*?\bjoin)\b|(?:f(?:\b\W*?\(\W*?\bbenchmark|null\b)|snull\b)\W*?\()|(?:having|or|and)\b\s+(?:\d{1,10}|[\'\"][^=]{1,10}[\'\"])\s*[=<>]+|print\b\W*?\@\@|cast\b\W*?\()|(?:;\W*?\b(?:shutdown|drop)|\@\@version)\b|'(?:s(?:qloledb|a)|msdasql|dbo)')" \

                      Для XSS:
                      # XSS
                      SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|XML:/*|!REQUEST_HEADERS:Referer "(?:\b(?:(?:type\b\W*?\b(?:text\b\W*?\b(?:j(?:ava)?|ecma|vb)|application\b\W*?\bx-(?:java|vb))script|c(?:opyparentfolder|reatetextrange)|get(?:special|parent)folder)\b|on(?:(?:mo(?:use(?:o(?:ver|ut)|down|move|up)|ve)|key(?:press|down|up)|c(?:hange|lick)|s(?:elec|ubmi)t|(?:un)?load|dragdrop|resize|focus|blur)\b\W*?=|abort\b)|(?:l(?:owsrc\b\W*?\b(?:(?:java|vb)script|shell)|ivescript)|(?:href|url)\b\W*?\b(?:(?:java|vb)script|shell)|background-image|mocha):|s(?:(?:tyle\b\W*=.*\bexpression\b\W*|ettimeout\b\W*?)\(|rc\b\W*?\b(?:(?:java|vb)script|shell|http):)|a(?:ctivexobject\b|lert\b\W*?\())|<(?:(?:body\b.*?\b(?:backgroun|onloa)d|input\b.*?\btype\b\W*?\bimage|script|meta)\b|!\[cdata\[)|(?:\.(?:(?:execscrip|addimpor)t|(?:fromcharcod|cooki)e|innerhtml)|\@import)\b)"

                      При том что снорт пизоцинирует себя как IDS/IPS у него нет даже pps/bps каунтеров.
                        +1
                        Не снортом единым надо защищаться от XSS
                          +1
                          Прочитайте про dynamic rules.
                            +1
                            Я имел ввиду то, что даная конфигурация snort'а на самом деле не защищает от XSS, SQL Injections, File injection etc… И даная рекомендация для организации полноценного web-firewall'а _не есть_ хорошим примером для production environment.
                              0
                              Она обеспечивает внешний барьер между web-сервером и идиотами с потными ладошками, которые прочитали статью на Хакере и полезли ломать всё подряд.
                              А комплексную безопасность опеспечивает много факторов, в том числе регулярная проверка на уязвимости, проведение краш-тестов, грамотная конфигурация хостинг-сервера и многое другое.
                              Снорт — первый барьер. А от хакера-профессионала спасёт разьве что отключение компьютера от электричества и запирание в сейф…
                                0
                                Так зачем строить етот барьер, тратить ресурс, только для «идиотов с потными ладошками»? Есть лучшее решение для даной задачи, например тот же mod_security, имлементация которого позволяет боротся и с «хакерами-профессионалами» втом числе.
                                  +3
                                  А кто сказал, что snort используется только для web?
                                  У меня лично туда внесены стандартные фрагменты шеллкодов (спасибо милворму), нулл-сканы, rpc-сплоиты и другие примеры народного творчества. Всё это обслуживает prelude-manager.
                                  Все события безопасности регистрируются, обрабатываются, генерируются абьюсы. Для защиты от DDoS-атак есть экстренный скрипт-перенаправлятор, который кидает весь роутинг на IDS (где стоит очень злой pf). Всё это интегрировано с корневой циской, в случае крупной атаки с подсети — подсеть будет выпилена из route table очень быстро. И всё — в автономном режиме.
                                  Или вы хотели увидеть 300-страничный мануал по настройке комплексной системы инфомационной безопасности?
                                  Простите, так я за это деньги получаю.
                                  P.S. Более «продвинутая» статья появится чуть позже.
                                    +1
                                    Спасобо, мануала не надо, я и сам такое строю :). Как разлуются у вас 2-3 гбитние flood DDoS на забивание канала?
                                      0
                                      Сначала — выпиливанием подсети на bgp-маршрутизаторе, потом — автоматическим письмом аплинкам и абьюзом владельцам AS'ки где живёт эта сеть.
                                      Для этого у нас 3 внешних канала + пиринг :)
                                        0
                                        Что щитает pps/bps per ip?
                                          0
                                          общий — pf/log
                                          Конкретный по протоколам — snort и dynamic rules.
                                          Точнее они не считают per ip, а проверяют на превышение допустимого per ip/per network.
                                      0
                                      Интересно было бы почитать в принципе, какие подходы применяются у вас :) Разумеется, без специфических деталей и ноу хау.

                                      Так сказать, для расширения общего кругозора относительно направлений
                                      0
                                      mod_security — такое же унылое говно как и большинство сигнатурных IDS. Особенно когда ставящие его не идут дальше правил по умолчанию, во многом полагаясь уже на сам факт наличия «чего-то эдакого». В таком случае любая блокировка обходится даже минимальной модификацией зловредного кода.
                                      Лучше не допускать появления дыр в приложениях, нежели делать такие вот «затычки».
                                        0
                                        Не допускать «появления дыр в приложениях» можна только в контолируемих окружениях, а ето явно не хостинг, и не компания где больше 100 девелоперов. А про «унылое говно» — назови хотя б 1 продукт, которий лучше притивостоит web-атакам в неконтролируемих окружениях, даже не из open-source.
                                          0
                                          Правильно, не допускать дыр в приложениях.
                                          Жаль, что не все дыры разработчик может/успевает учесть.
                                          Периодически проводите аудиты безопасности веб приложений при помощи сторонних компаний, которые заинтересованы максимально выполнить свои обязанности и меют большой опыт в проведении таких мероприятий.
                                +1
                                Вот нравятся мне такие статьи.

                                Рассказывают про какую-то плюшку и сразу приводят примеры конфигов в неизвестном формате. Про формат — ни слова. Что делают ключевые слова — неясно. Как правила писать — неясно. Какой синтаксис у этого конфига — неясно.

                                Аффтару два.
                                  0
                                  Простите, а при статье про новый девайс надо отсканить и выложить инструкцию пользователя?
                                  А рассказывая кому-то о своей работе, вы зачитываете вслух мануалы?
                                  Кому будет интересно — разберется.
                                  Гугл поможет.
                                  0
                                  А почему о том, что для snort_inline нужно настроить iptables — ни слова? И про ключ -Q, и про modprobe ip_queue. До всего пришлось догугливаться. Или я изначально пошел не тем путем (скачал исходники snort_inline)?
                                  Такое ощущение, что вы рассказывали про snort, а не snort_inline. Но снорт же не может блокировать трафик?
                                  Вот тут толково нарисовано openmaniak.com/inline_final.php
                                    0
                                    Не смотрели как Snort 2.8.* научить inline?
                                    0
                                    Может кто напишет про функции inline в snort 2.8.5? Что крутить чтобы все заработало как надо? Отправка всего трафика -j QUEUE привиодит к тому что вообще ничего не работает. Кто может сталкивался?

                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                    Самое читаемое