Дана стаття являє собою введення в теорію виявлення мережевих атак. Крім того, в ній представлений огляд одного з продуктів ринку систем виявлення вторгнень (IDS) — Snort, що є некомерційним і, на мій погляд, одним з кращих представників IDS.

Отже, почнемо з теорії…
Виявлення атак або вторгнень можна розділити на 2 категорії по факту і часу аналізу. До першої можна віднести аналіз інформації, зібраної за будь-який кінцевий термін; до другої — аналіз в реальному часі. Відкидати одну з категорій — груба помилка адміністратора безпеки. Для точного аналізу з прийняттям адекватних рішень і дій на вторгнення необхідно враховувати інформацію, одержувану як в даний момент, так і вже наявну. Тобто мається на увазі наявність досвіду (набору або бази знань) системи (хоча і адміністратор теж повинен бути не дурний).
Далі, після отримання інформації, проводиться її аналіз, який може зводитися до накладення фільтрів (найбільш простий, хоча і достатньою мірою ефективний спосіб) або аналіз на основі інтелектуальної системи. Під накладенням фільтрів розуміється порівняння масиву або «бази» з заздалегідь закладеними «регулярними виразами» (мають певний рівень визначеності або певними повністю, і ранжированными за ступенем довіри або уваги) з даною інформацією і виявлення цікавлячих нас подій. А під інтелектуальною мається на увазі система, здатна на основі вже отриманих раніше знань (дані знання не «забиваються» в систему, а абсорбуються в базу на основі алгоритмів системи — випливає висновок, що чим краще спроектовано алгоритми абсорбції, тим вище рівень інтелектуальності, — хоча рівня штучного інтелекту домогтися навряд чи вийде — так що без людини тут, на жаль, не обійтися — єдине, це тільки можливо звести до мінімуму зусилля їм витрачаються) виявляти незвичайні події (в даному випадку використовується статистика подій).
Також дана система повинна бути здатна аналізувати на майбутнє (так звана експертна система) — тобто за раніше отриманими даними і інформації, одержуваної в даний момент, будувати припущення про подальший розвиток подій. Для накопичення знань» інтелектуальними системами їм необхідно час адаптації (навчання) у даної середовищі, протягом якого відбувається вивчення і накопичення подій у «базу знань». (Взагалі-то, на етапі навчання не погано б ізолювати систему в середу з імітацією «нормальної роботи», але імітація то якраз і є одним із складних етапів — адже одна помилка може привести до повної непрацездатності системи в подальшому.) Знову ж при використанні тільки одного методу аналізу ми ризикуємо що-небудь упустити (один метод може дати аналіз точніше ніж інший). Наприклад, відмова від використання фільтрів може коштувати того, що ми втратимо будь-яких очевидний прояв атаки.
Надалі, в залежності від результату аналізу, система повинна зреагувати. В даному випадку ми можемо поділити системи ще на 2 типи — активні і пасивні. Пасивні системи виробляють журналювання системи і повідомляють про незвичайних проявах активності. Тоді як активні системи виробляють дії спрямовані на захист від цієї небезпеки або блокування її. Але активні системи не завжди виправдовують себе: наприклад, системи, що виробляють блокування будь-якого хоста при визначенні сканування з його боку, можуть бути використані зловмисником — він може навмисно (за рахунок спуффинга пакетів) обмежити доступ до хосту з такою системою.
Хотілося б відзначити, що при побудові системи виявлення мережевих атак необхідно розглядати всі можливості отримання і аналізу інформації. Також, система повинна бути збалансована в залежності від даної мережі — її топології та розташування — що істотно впливає ще й на вибір засобів виявлення.

А тепер розглянемо Snort IDS.
Дана система являє собою аналізатор подій мережі у реальному часі, що виробляє як аналіз трафіку, так і запис пакетів мережі. Вона дозволяє аналізувати як вміст та стан трафіку. Snort може використовуватися як сніфер, логгер мережевих пакетів або як система спостереження за мережевою активністю. Нас цікавить останнє, тобто можливість виявлення атак.
Отже, Snort можна охарактеризувати як систему, що виробляє аналіз фільтрами (при великій базі знань здатний виявити практично всі атаки — а крім цього, він (практично повністю) дає характеристику трафіку — від пінгів (навіть ОС видає), до спроб доступу до irc, icq тощо).
У файлі конфігурації можна оголошувати змінні, які можуть використовуватися нами в подальшому. Загальний вигляд такий — var ІМ’Я_ЗМІННОЇ значення. Звертатися до цієї змінної можна потім так — $ІМ’Я_ЗМІННОЇ.
Структура фільтра (правила) така:
func proto src_ip/mask src_port_range -> dst_ip/mask dst_port_range (options)
Не буду особливо вдаватися в подробиці, а наведу лише приклад достатньої гнучкості таких правил.
func — функція дії — alert, log, pass.
proto, src_ip/mask, src_port_range, dst_ip/mask, dst_port_range — протокол, адрес_источника/маска, порт(и)_источника, адрес_назначения/маска, порт(и)_назначения — відповідно.
замість -> можна використовувати для позначення двосторонньої передачі.
(options) — поле опцій яких достатня кількість, де описуються фільтри стану та змісту пакета. Опції мають вид — имя_опции: значення
Ось, на мій погляд, основні опції:
msg — повідомлення, який буде виводиться в разі збігу з даним фільтром.
flags — TCP прапори (S,F,A,U,P,R,0,1-reserved bit,2-reserved bit), можна використовувати 0 якщо ні прапорів.
ttl — час життя пакету.
content — вміст пакета.
itype — номер типу icmp.
icode — номер коду icmp.
seq, ack — номер послідовності і підтвердження TCP.
id — ідентифікатор фрагмента.
logto — який файл виробляти журналювання даної події.
ipopts — опції пакету.
Є й інші (див. документацію).
Припустимо ми хочемо визначати пакети з встановленими одночасно прапорами SYN, FIN і RST. Ось так буде виглядати дане правило:
alert tcp any any -> any any (msg:«А прапори то дивні!»; flags: SFR;)
— все досить просто…
Крім цього він здатний (точніше один із його плагінів — Snort побудований на основі системи плагінів, що дозволяє нам додавати нові засоби аналізу або реакцій) стежити за аномальною поведінкою в мережі — виявляти підозрілу активність (якась інтелектуальна система) — так званий Spade (лопатка). Вона збирає статистику пакетів за певний проміжок часу, і виробляє обчислення ступеня аномальності пакета (хоча, можна налаштувати, щоб даний плагін повідомляв про якомусь відсотку пакетів) і при перевищенні норми починає скаржитися… Крім того, ці дані цікаво аналізувати, і можна зробити висновки, коли ваша мережа найбільш завантажена. 🙂
Також він здатний реагувати в залежності від результату аналізу (збіги з фільтрами) — може посилати RST-пакети завершальні з’єднання як жертви, так і атакуючого (поки ще не реалізована можливість запуску будь-яких скриптів або програм — є привід написати плагін).
Це одна з опцій — resp — може приймати значення:
rst_snd, rst_rcv, rst_all — посилає пакет завершення відправнику, одержувачу або обох відразу відповідно
icmp_net, icmp_host, icmp_port, icmp_all — посилає пакет недоступності мережі, хоста, порту або всі відповіді відразу відповідно
Тобто визначимо, наприклад, змінну заборони даного з’єднання — var RESP_TCP_URG resp:rst_all
тепер напишемо правило, яке в разі конекта до нас на порт 111 вирубував б з’єднання.
alert tcp $ENEMY_NET any -> $HOME_NET 111 (msg: «connection to Kill RPC!»; flags: S; $RESP_TCP_URG)

Стаття підійшла до кінця, і хотілося б відзначити, що завдяки Snort’у мною особисто було виявлено безліч спроб мережевих атак (на даний момент лідирують атаки проти IIS вони займають перше місце в моїх рейтингах систем виявлення ;). Але все-таки обмежуватися лише цим програмним продуктом я б не радив… Для отримання ефективної і адекватної системи виявлення атак необхідно використовувати засоби різнобічного аналізу!!! (хоча хотілося б мати єдиний засіб)…