4582

Сучасні технології захисту інформації в комп’ютерних системах і мережах

Книга

Информатика, кибернетика и программирование

Частина друга присвячена питанням захисту інформації в комп’ютерних мережах. До її складу входять роботи: Перехоплення мережевого обміну, Сканування TCP/IP мереж, Засоби аналізу захищеності, Міжмережеві екрани, Системи виявлення атак. Лаборатор...

Украинкский

2012-11-22

2.15 MB

99 чел.

Частина друга присвячена питанням захисту інформації в комп’ютерних мережах. До її складу входять роботи: Перехоплення мережевого обміну, Сканування TCP/IP мереж, Засоби аналізу захищеності, Міжмережеві екрани, Системи виявлення атак.

Лабораторна робота №7. Перехоплення мережевого обміну

Мета роботи

ознайомлення із засобами перехоплення й аналізу мережевого обміну на прикладі утіліти TCPDump.

Теоретичні відомості

Відмітною ознакою компютерних мереж як класу обчислювальних систем є їхня просторова розподіленність. При цьому взаємодія абонентів мережі здійснюється фізично (по мережевих з'єднаннях) і програмно (за допомогою механізму повідомлень). Усі керуючі повідомлення і дані, що пересилаються між об'єктами, передаються по мережевих з'єднаннях у вигляді пакетів обміну. Ця особливість привела до появи ряду специфічних для комп'ютерних мереж (на відміну від окремих комп’ютерів) загроз безпеці. Одна з них полягає в прослуховуванні каналу зв'язку і носить назву "аналіз мережевого трафіка" (sniffing), скорочено – "мережевий аналіз".

Реалізація загрози "мережевий аналіз" дозволяє, по-перше, вивчити логіку роботи мережі, тобто одержати взаємно однозначну відповідність подій, що відбуваються, і команд, що пересилаються один одному об'єктами у момент появи цих подій. Це досягається шляхом перехоплення й аналізу пакетів обміну на канальному рівні. Знання логіки роботи комп'ютерної мережі дозволяє на практиці моделювати її роботу і здійснювати віддалені (дистанційні) атаки.

По-друге, така віддалена атака дозволяє безпосередньо перехопити потік даних, якими обмінюються об'єкти мережі. Тобто, атака цього типу полягає в одержанні несанкціонованого доступу до інформації, якій обмінюються два абоненти мережі. При реалізації даної загрози неможливо модифікувати трафік, а сам аналіз найчастіше можливий тільки всередині одного сегмента мережі. Прикладом інформації, перехопленої за допомогою такої типової атаки, можуть бути ім'я і пароль користувача, що пересилаються по мережі в незашифрованому вигляді.

За характером впливу аналіз мережевого трафіка є пасивним впливом (спостереженням). Здійснення даної атаки веде до порушення конфіденційності інформації всередині одного сегмента мережі на канальному рівні моделі взаємодії відкритих систем (OSI).

Оскільки пасивне прослуховування мережевого обміну можливе лише за умови безпосереднього підключення до каналу зв’язку, яким здійснюється обмін, ефективними засобами протидії здійсненню цієї атаки є такі:

  •  Максимальне обмеження окремих сегментів мережі, відмова від розділюваного середовища передачі. Це досягається відмовою від фізичної топології мережі “загальна шина” (10Base2 і 10Base5 Ethernet), а також відмовою від концентраторів (hub) на користь комутаторів (switch).
  •  Прокладення кабелю в місцях, де або неможливий доступ до нього, або можливий постійний контроль за доступом, що виключає несанкціоноване підключення до кабелю.
  •  Там, де постійний контроль за кабелями неможливий, слід віддавати перевагу волоконно-оптичним кабелям, підключення до яких важко здійснити і легко помітити, оскільки воно суттєво погіршує характеристики каналу.

В тих випадках, коли принципово неможливий захист від аналізу трафіка (наприклад, коли трафік проходить через комп’ютери іншої організації, зокрема, провайдера Internet), для критичної інформації, особливо імен користувачів і паролів, слід застосовувати шифрування. Втім, для застосування будь-якого шифрування законодавство деяких країн (в тому числі Росії, Франції, Китаю) вимагає отримання спеціальних ліцензій.

Аналіз трафіку може проводитись дуже розповсюдженими засобами, одним з яких є утіліта TCPDump (дамп мережевого трафіка), що вільно і безкоштовно розповсюджується, і використовується в системах Unix і Linux. Утіліта використовує гнучкий інтерфейс командного рядка, а її вихідний потік у відповідності до традицій Unix можна перенаправити на будь-які фільтри для подальшого аналізу. Опис синтаксісу команди і опцій tcpdump наведено у Додатку 1. Детальний опис версії, що встановлена у вашій системі, можна знайти в довідковій системі man (man tcpdump).

Хід роботи

  1.  Докладно ознайомтесь з ПЗ TCPDump (Додаток 1 і команда man tcpdump).
  2.  Виконайте за допомогою TCPDump перехоплення мережевого обміну відповідно до варіанта завдань (за вибором викладача).
  3.  Організуйте перехоплення пароля telnet і ftp-секцій. Напишіть фільтр для розв’язання таких задач.
  4.  Оформіть звіт.

Звіт має містити:

  1.  неформально задану політику безпеки для не менш ніж 3 користувачів і 2 груп та не менш ніж 6 файлових об’єктів;
  2.  протокол спроб отримати доступ з п.9 ходу роботи;
  3.  роздрук фрагментів журналу реєстрації.

Варіанти завдань

  1.  Спіймати 10 пакетів IP-протоколу c хоста hostname у файл ippakets
  2.  Спіймати всі UDР пакети, що передаються між нестандартними (>1024) портами.
  3.  Спіймати всі TCP пакети, що передаються між нестандартними (>1024) портами.
  4.  Спіймати HTTP-пакети, що спрямовані з localnet і не на yahoo.com, з переведенням IP-адреси у символьну форму.
  5.  Показати усі початкові і кінцеві IP-пакети, що адресовані з localnet у зовнішній світ із указівкою тільки напрямків пакетів
  6.  Спіймати всі IP-пакети, розмір яких перевищує 1k.
  7.  Спіймати і витягти логін по FTP
  8.  Спіймати і витягти пароль по Telnet
  9.  Спіймати і показати в ASCII усі 68 байт кожного IP пакета
  10.  Спіймати і показати пакети, що мають відношення до HTTP-запитів логіна
  11.  Спіймати пакети, що беруть участь в обміні по Realtime Application Protocol і вивести їхню кількість
  12.  Приблизно підрахувати кількість викликів по Remote Procedure Call
  13.  Спіймати 10 IP-пакетів між двома хостами і показати розширену службову інформацію з них
  14.  Спіймати і підготувати для обробки С-програмою перший-ліпший пакет (структура як вхідний параметр)
  15.  Спіймати пакети, що відіслані з HTTP порту на FTP порт і вивести напрямки пакетів.
  16.  Спіймати всі НТТР-пакети, що спрямовуються в зовнішні мережі.

Контрольні запитання

  1.  Перелічіть способи захисту від атак "мережевого аналізу".
  2.  Які загрози, крім конфіденційності, реалізує даний вид атак?
  3.  Запропонуйте міжсегментний спосіб перехоплення мережевого обміну.
  4.  Запропонуйте спосіб реалізації перехоплення мережевого обміну в мережі, що побудована на керованих комутаторах.

Лабораторна робота №8. Сканування TCP/IP мереж

Мета роботи

Вивчення методів сканування TCP/IP мереж на прикладі використання утіліти NMap.

Теоретичні відомості

Атака на комп’ютерну систему здійснюється здебільшого за таким сценарієм. На першому етапі зловмисник здійснює збирання інформації про мережу, яка є ціллю атаки, як технічними, так і нетехнічними методами. В загальному випадку метою збирання інформації є отримання відомостей про конфігурацію мережі, системне й прикладне програмне забезпечення, що в ній використовується, сервіси, що запущені. Переважна більшість таких відомостей може бути отримана шляхом сканування мережі. Тривалість цього етапу не визначена. В результаті обробки отриманих даних зловмисник або шукає відомі вразливості, притаманні ПЗ, що використовується, або здійснює самостійні дослідження ПЗ, в залежності від його кваліфікації.

На другому етапі запускається програмний код, що використовує ту або іншу вразливість, так званий «exploit». Цей етап і становить власне сутність атаки. В результаті виконання коду зловмисник або отримує несанкціонований доступ до комп’ютерної системи, або спричиняє в ній порушення функціонування (аж до краху системи) у випадку атаки на відмову в обслуговуванні. Тривалість цього етапу, як правило, дуже мала, хоча можуть бути й виключення (наприклад, підбір паролів). Джерелом коду, що реалізує атаку, може бути як власна творчість досвідченого хакера, так і величезна кількість сайтів в Інтернет, тобто зловмисник, що реалізує (навіть успішно) атаку, не обов’язково має високу кваліфікацію.

На третьому етапі зловмисник здійснює дії, заради яких він здійснював атаку: читання конфіденційних захищених даних, несанкціонована модифікація, блокування або знищення інформації, тобто реалізуються загрози конфіденційності, цілісності й доступності інформації.

На четвертому (необов’язковому) етапі зловмисник здійснює дії, спрямовані на приховування слідів його перебування в системі. Як правило, вони полягають в редагуванні файлів аудиту операційної системи.

Таким чином, першим етапом атаки є розвідка, яка здебільшого здійснюється шляхом сканування мережі, або включає таке сканування як складову частину. Сканери мереж і портів є найбільш поширеними інструментами збору інформації технічними методами. Безпосередньо сканування дає інформацію про активні IP-адреси і пов’язані з ними сервіси, а також про деякі подробиці, які система явно чи неявно повідомляє про себе через мережу (тобто, або система явно дає відповідь на стандартні чи спеціально сформовані запити визначених протоколів, або її поведінка може бути визначеним чином проінтерпретована). Одним з найпоширеніших і найдоступніших сканерів є NMap (Network Mapping) – безкоштовне ПЗ для ОС Unix і Linux.

Правові аспекти сканування

Перш, ніж детальніше познайомитись з методами сканування й утілітою NMap, необхідно з’ясувати правові аспекти здійснення сканування, яке, як ми зазначили вище, можна розглядати як перший етап здійснення атаки. Однак, певна частина спеціалістів з комп’ютерної безпеки, в тому числі автори деяких популярних книг і автори програмного забезпечення, яке здійснює сканування, не відносять сканування до атаки. Автор NMap і автори книги “Атака на Інтернет” – яскраві тому приклади. Однак слід розібратись, що саме може бути метою сканування.

По-перше, сканування може бути актом тестування, яке здійснює уповноважений адміністратор для перевірки працездатності і активності тих чи інших сервісів у мережі. По-друге, сканування може бути актом розвідки, за яким з великою ймовірністю буде здійснено спробу атаки. По-третє, сканування може бути частиною дослідження комп’ютерів і мереж, яке виконують адміністратори і експерти для перевірки на наявність недокументованих інтерфейсів, так званих люків (“backdoor), які відкриваються деякими “троянськими конями”, вірусами або мережевими “хробаками” для несанкціонованого віддаленого доступу, в тому числі для надання зловмиснику можливості повного контролю над комп’ютером через мережу. Фактично, третій випадок від другого відрізняється лише тим, як будуть застосовані результати розвідки: для компрометації системи чи для захисту від компрометації.

Таким чином, мережеві сканери дійсно можна вважати не просто інструментом, а зброєю, наслідки застосування якої залежать від того, в чиїх вона руках і наскільки ці руки вправні. А сканування є ні чим іншим, як застосуванням цієї зброї. Крім того, за несприятливого збігу обставин (мала потужність сервера-цілі, вразливе або неправильно налаштоване ПЗ) саме сканування без цілеспрямованих спроб атаки може стати причиною відмови в обслуговуванні. Тому цілком природно, що реакція системного адміністратора на сканування його машини або мережі, напевно, буде дуже різкою, аж до звернення до правоохоронних органів. В деяких мережах, наприклад в мережі НТУУ “КПІ”, сканування інших підмереж заборонено правилами. Сканування в Інтернет, скоріше за все, закінчиться тим, що провайдер відключить комп’ютер, з якого проводилось сканування, без відшкодування грошей, що залишались на рахунку. Малоймовірно, щоби за одним лише фактом сканування наступила кримінальна відповідальність, однак, якщо слідство буде розпочато за іншим фактом (компрометація системи, викрадення конфіденційної інформації, створення та впровадження шкідливого ПЗ), то наявність в арсеналі підозрюваного мережевого сканера однозначно буде розцінено як доказ (прецеденти вже мали місце в Російській Федерації і обговорювались в російській пресі).

Тому суворе застереження, яке слід пам’ятати – якщо ви плануєте здійснити сканування, обов’язково попередьте (або дістаньте згоду, в залежності від наявних у вас повноважень) усіх зацікавлених осіб. В деяких випадках згоду слід отримати у письмовому вигляді.

Методи сканування

Перш, ніж знайомитись з використанням програми NMap, ознайомимось з різними методами сканування, які вона дозволяє здійснювати.

TCP connect() (TCP з’єднання)

Це самий основний вид TCP сканування. Системний виклик connect(), що забезпечується операційною системою машини, з якої здійснюється сканування, використовується для відкриття з’єднання з кожним з цікавлячих портів на машині, яка є ціллю сканування. Якщо порт слухає, виклик connect() буде успішним, в іншому разі порт недоступний. Велика перевага цього методу для того, хто сканує, полягає в тому, що для цього не потрібні жодні спеціальні привілеї. Будь-який користувач на більшості UNIX-машин вільний використовувати цей системний виклик.

З іншого боку, цей вид сканування легко зафіксувати, оскільки протоколи подій на хості-цілі будуть показувати низку повідомлень про з’єднання і помилки від служб, які здійснюють з’єднання (accept()), що після цього негайно закриваються.

TCP SYN

Цей метод часто називають скануванням “напіввідкривання” ("half-open"), оскільки той, хто сканує, не відкриває повне TCP-з’єднання. Він (вона?) відсилає SYN-пакет (TCP-пакет з встановленою ознакою SYN), якби він дійсно збирався відкрити з’єднання, і чекає на відповідь. Важливий момент: в першому методі сканування використовувався системний виклик, і ядро системи само брало на себе турботу по формуванню пакетів, що відповідають за встановлення TCP-з’єднання. В цьому методі підхід інший: програма, що використовується для сканування (ми зараз концентруємось на NMap), формує окремий пакет, відсилає його і чекає на відповідь. Відповідь SYN|ACK (TCP-пакет з встановленими ознаками SYN і ACK) вказує, що порт слухає. Відповідь RST – ознака, що порт не слухає. Якщо надходить SYN|ACK, негайно відправляється RST для знищення з’єднання. Фактично, це для нас робить ядро нашої ОС, бо для нього цей пакет “несподіваний” – це ж не воно розпочинало з’єднання.

Головна перевага цього методу сканування полягає в тому, що менша кількість вузлів зареєструє його. Але для побудови цих окремих SYN-пакетів необхідні привілеї суперкористувача.

Тут і далі автор програми NMap однозначно на боці тих, хто сканує: переваги методу – це додаткові можливості здійснити сканування, з приводу можливості зафіксувати факт сканування або необхідності привілеїв суперкористувача він висловлює жаль. Оскільки нас однаково цікавить як можливість здійснити сканування (з метою тестування мережі), так і можливість виявити сканування (з метою захисту від атак), ми будемо додержуватись нейтралітету і намагатись уникнути емоцій.

Stealth FIN (Приховане FIN), Xmas Tree (Різдвяне дерево), Null scan (нульове сканування)

Іноді навіть TCP SYN сканування недостатньо приховане. Деякі міжмережеві екрани (брандмауери) і пакетні фільтри пильнують пакети SYN до портів, що охороняються. Доступні також програми подібні до Synlogger і Courtney, здатні виявляти такі сканування. Удосконалені сканування, що розглядаються тут, можуть пройти через згадані перешкоди непоміченими. ().

Спільна ідея цих методів полягає в тому, що закриті порти повинні відповідати на “незрозумілі” пакети (пакети з несподіваними, неправильними, неприпустимими комбінаціями ознак) RST, в той час коли відкриті порти такі пакети повинні просто ігнорувати (див. RFC 793 pp 64). FIN-сканування використовує в якості зонда “несподівані” FIN-пакети, сканування “Xmas tree” використовує пакети з ознаками FIN, URG і PUSH, нульове сканування використовує пакети взагалі без прапорців.

Деякі ОС ігнорують стандарт і відсилають RST від відкритих портів, коли вони мали б просто пропустити (відкинути) пакет. Тому ці типи сканування не будуть працювати проти таких систем. Втішним є те, що це – добрий спосіб розрізнити платформи. Автор NMap в якості таких ОС називає Windows95/NT, і витрачає немало слів на адресу Microsoft. Однак, потім сам додає, що є також кілька інших систем, які поводять себе також “неправильно”, як і Windows. До їх числа належать Cisco IOS, BSDI, HP/UX, MVS і IRIX. Тобто, якщо таке сканування знаходить відкриті порти, ви знаєте, що ваша ціль працює не під Windows, а також не під жодною із щойно згаданих ОС. Якщо ж згадані тут сканування показують, що всі порти закриті, а сканування SYN показує відкриті порти, то ви, ймовірно, скануєте машину або під Windows, або... Однак таке визначення ОС не так вже й корисно, оскільки Nmap має вбудовані можливості детектування ОС.

Ping-сканування

Іноді ви бажаєте лише дізнатись, які хости в мережі включені. Це можна зробити, відсилаючи ICMP-пакети echo (запит відгуку) до кожної IP-адреси в мережах, які вас цікавлять. Хости, які відповідають, включені. Деякі сайти, як, наприклад, microsoft.com, блокують пакети запиту відгуку. Тоді можна (NMap робить це автоматично) відсилати TCP ACK-пакети на такий порт, який зазвичай відкритий (типово – 80-й, HTTP). Якщо ми отримуємо у відповідь RST, машина включена. Третя методика передбачає відсилання SYN-пакета й очікування RST або SYN/ACK. Для non-root користувачів залишається використовувати метод connect().

UDP-сканування

Цей метод використовується, щоби визначити, які UDP-порти (User Datagram Protocol, Протокол користувацьких дейтаграмм, RFC 768) відкриті на хості. Методика полягає в тому, що 0-байтні UDP-пакети відсилають на кожний порт на машині-цілі. Якщо ми у відповідь отримуємо ICMP-повідомлення “порт недосяжний”, то порт закритий. Інакше ми припускаємо, що він відкритий.

Дехто вважає, що UDP-сканування безцільно. Слід нагадати, що UDP в якості транспортного протокола використовується великою кількістю служб, керуючих протоколів, а також “троянців”. Варто навести низку прикладів. Наприклад, вразливість Solaris Rpcbind. Можна знайти Rpcbind, який приховується на недокументованому UDP-порту з номером десь більше за 32770. Таким чином те, що порт 111 блокований міжмережевим екраном, не має значення. Але можете ви знайти, на якому з більше ніж 30000 верхніх портів він (Rpcbind) слухає? З UDP-сканером ви можете! Інший приклад – дуже відома програма-люк Back Orifice (авторам важко відмовити в дотепності назви!), що ховається на конфігурованому UDP-порту на машинах під Windows. Це типовий “троянець”, і, до речі, свого часу він був дуже небезпечним. А що вже й казати про безліч зазвичай вразливих сервісів, що використовують UDP, на кшталт SNMP, TFTP, NFS і т.д.

На жаль, UDP-сканування іноді іде дуже повільно, оскільки більшість хостів здійснюють пропозицію RFC 1812 (розділ 4.3.2.8) щодо обмеження швидкості ICMP-повідомлень про помилки. Наприклад, ядро Linux (в net/ipv4/icmp.h) обмежує генерацію повідомлень “адресат недосяжний” (destination unreachable) до 80 за 4 секунди, із штрафом у 1/4 секунди при перевищенні цієї границі. Solaris має значно більш суворі обмеження (приблизно 2 повідомлення в секунду), і таким чином вимагає ще більшого часу для сканування (65536 портів / 2 = 32768 сек = 9 годин 6 хвилин). При такій швидкості сканування здається доцільним здійснювати UDP-сканування хостів під керуванням Solaris безперервно, щоби не занадто пізно помітити впровадженого “троянця”. Microsoft типово проігнорувала пропозицію RFC і, здається, взагалі не робить будь-яких обмежень швидкості на Windows-95 и NT-машинах. Таким чином, можна сканувати всі 64k портів Windows-хоста дуже швидко. Оце так так!

Сканування IP-протоколів

Цей метод використовується, щоби визначити, які IP-протоколи підтримуються на хості. Методика полягає в тому, що відсилають необроблені (raw) IP-пакети без будь-якого подальшого заголовка протоколу до кожного вказаного протоколу на машині-цілі. Якщо у відповідь надходить ICMP-повідомлення “протокол недосяжний” (protocol unreachable), то протокол не використовується. Інакше залишається припустити, що він відкритий. На жаль, деякі хости (під керуванням AIX, HP-UX, Digital UNIX) і міжмережеві екрани можуть не відсилати повідомлення “протокол недосяжний”. Це веде до того, що всі протоколи здаються відкритими.

Оскільки задіяна методика дуже подібна до UDP-сканування, границя швидкості ICMP також могла би діяти. Але поле “IP-протокол” має лише 8 біт, так що треба досліджувати максимум 256 протоколів, а це в будь-якому разі буде можливим за прийнятний час.

Idlescan

Цей удосконалений метод сканування дозволяє дійсно сліпе сканування TCP-портів цілі (це означає, що жодних пакетів не відсилається до цілі з вашої реальної IP-адреси). Замість того, унікальна атака типу “бічний канал” експлуатує передбачувану генерацію послідовності "ідентифікатор IP-фрагментації" на хості-“зомбі”, щоби зібрати інформацію щодо відкритих портів на цілі. Системи IDS відобразять сканування як таке, що іде з хоста-зомбі, який ви вкажете (такий хост має бути включеним і задовольняти певним критеріям). Більш детальне пояснення можна знайти за адресою http://www.insecure.org/nmap/nmap_documentation.html.

Крім надзвичайної прихованості (завдяки його “сліпій” природі), цей тип сканування дозволяє визначити основані на IP відношення довіри між машинами. Список портів показує відкриті порти з точки зору хоста-зомбі. Так що ви можете спробувати сканувати ціль, використовуючи різні зомбі, які на ваш погляд можуть бути довіреними (через правила маршрутизатора/пакетного фільтра). Вочевидь, це – критична інформація під час розстановки пріоритетів цілей атаки. Інакше атакуючий міг би витратити значні ресурси для захоплення проміжної системи лише для того, щоби виявити, що її IP-адресі навіть не довіряє хост або мережа, що є кінцевою ціллю атаки.

ACK-сканування

Цей удосконалений метод зазвичай використовується для розкриття набору правил міжмережевого екрана. Зокрема, він може допомогти визначити, чи є міжмережевий екран брандмауером типу “stateful firewall”, чи простим пакетним фільтром, який блокує SYN-пакети, що надходять.

Цей тип сканування відсилає ACK-пакет (з номерами підтвердження/послідовності, що виглядають випадковими) на вказані порти. Якщо повертається RST, порти класифікуються як закриті безпосередньо на хості ("нефільтровані"). Якщо нічого не повертається (або якщо повертається ICMP-повідомлення “недосяжний”), порт класифікується як "фільтрований", тобто закритий фільтром або міжмережевим екраном. Це сканування очевидно ніколи не буде показувати відкриті порти.

Віконне сканування

Це удосконалене сканування дуже подібне до ACK-сканування, за виключенням того, що воно може іноді визначати відкриті порти, як і фільтровані/нефільтровані, завдяки аномалії в повідомленні про розміри TCP-вікна деякими операційними системами. Системи, вразливі до цього, включають щонайменше деякі версії AIX, Amiga, BeOS, BSDI, Cray, Tru64 UNIX, DG/UX, OpenVMS, Digital UNIX, FreeBSD, HP-UX, OS/2, IRIX, MacOS, NetBSD, OpenBSD, OpenStep, QNX, Rhapsody, SunOS 4.X, Ultrix, VAX і VxWorks. Повний список можна знайти в архіві списку розсилки Nmap-хакерів.

RPC-сканування

Цей метод працює в комбінації з іншими методами сканування портів. Всі знайдені відкриті TCP/UDP порти заповнюються командами NULL SunRPC у намаганні визначити, чи є ці порти RPC-портами, і, якщо це так, яку програму і який номер версії вони обслуговують.

Атака “FTP bounce”

Цікава особливість (“feature”) протоколу FTP (RFC 959) – це підтримка “proxy” FTP-з’єднань. Іншими словами, користувач повинен мати можливість підключитись з хоста evil.com до FTP-сервера target.com і дати команду, щоби сервер відправив файл будь-куди в Internet! Можливо, це добре працювало в 1985 р., коли був написаний RFC. Але в теперішньому Internet ми не можемо дозволити наявність людей, що беруть контроль над FTP серверами і вимагають, щоби дані розповсюджувались у довільні вузли в Internet. Як написав *Hobbit* в 1995 р., ця вада протоколу “може використовуватись, щоби відправляти фактично невідслідковувану пошту й новини, розміщати її на серверах в різних сайтах, заповнювати диски, намагатись проникати скрізь міжмережеві екрани і взагалі бути дратуючим і важковідслідковуваним одночасно.”

Для чого це можна використати – це (ось несподіванка!) для сканування TCP-портів з “proxy” FTP-сервера. Таким чином можна підключитись до FTP-сервера за міжмережевим екраном, а потім сканувати порти, які, ймовірно, блоковані екраном (наприклад, 139). Якщо FTP-сервер дозволяє читання і запис у деякому каталозі (як, наприклад, /incoming), можна відправити довільні дані на порти, яки знайдено відкритими.

Програмне забезпечення для сканування

Найпоширенішим засобом сканування ТСР/ІР мереж (у Unix-подібних системах є програма Nmap, що вільно і безкоштовно розповсюджується. Утіліта використовує інтерфейс командного рядка. Опис синтаксісу команди і опцій nmap наведено у Додатку 2. Детальний опис версії, що встановлена у вашій системі, можна знайти в довідковій системі man (man nmap).

Хід роботи

  1.  Докладно ознайомтесь з ПЗ Nmap (Додаток 2, команда man nmap, команда nmap -h).
  2.  Оберіть ціль в межах лабораторії, спочатку в тому ж сегменті, а потім в іншому. Здійсніть сканування TCP-портів цілі “повним перебором” з використанням connect().
  3.  Для вказаної викладачем цілі здійсніть ідентифікацію її ОС.
  4.  Налаштуйте і запустіть утіліту TCPdump для фіксації своїх дій.
  5.  Здійсніть “приховане” (з використанням списку сервісів) сканування методом згідно вказаного викладачем варіанта.
  6.  Порівняйте результати.
  7.  Оформіть звіт.

Варіанти завдань

  1.  Сканування TCP SYN
  2.  Сканування Stealth FIN
  3.  Сканування Xmas tree
  4.  Null-сканування
  5.  Сканування з використанням FTP
  6.  Сканування UDP-портів

Контрольні запитання

  1.  За якими ознаками (якщо аналізувати трафік мережі в реальному часі) можна виявити сканування?
  2.  Які заходи під час сканування забезпечують непомітність?
  3.  Які чинники впливають на можливість відмови цілі внаслідок сканування? Як цьому запобігти?
  4.  За якими ознаками за результатами сканування портів можна визначити операційну систему цілі?

Лабораторна робота №9. Засоби аналізу захищеності

Мета роботи

ознайомлення з інструментальними засобами аналізу захищеності

Теоретичні відомості

Засоби аналізу захищеності (ЗАЗ), або сканери безпеки, призначені для автоматизації роботи адміністратора безпеки шляхом пошуку потенційних порушень політики безпеки та вразливостей ОС. При цьому ЗАЗ можуть виявляти такі види порушень (вразливості):

  •  “люки” (back door) в програмах и програми типу “троянський кінь”;
  •  слабкі паролі й неправильні налаштовування механізмів автентифікації;
  •  сприйнятливість до проникнення внаслідок неявних довірчих відношень між системами;
  •  сприйнятливість до атак на відмову в обслуговуванні;
  •  неправильні налаштовування міжмережевих екранів, мережевих і прикладних сервісів;
  •  нездатність засобів захисту системи адекватно реагувати на спроби збору інформації;

ЗАЗ можуть здійснювати сканування системи як “ззовні”, з використанням для доступу до системи мережевих засобів (network-based), так і “зсередини”, працюючи безпосередньо на хості, який аналізують (host-based, application-based). Як правило, мережеві сканери також здатні здійснювати сканування локальної системи через “зворотний” інтерфейс (127.0.0.1).

Для мережевих ЗАЗ існують дві групи способів виявлення вразливостей – сканування й зондування.

Сканування (banner check) – механізм пасивного аналізу, використовуючи який сканер намагається визначити існування вразливості за непрямими ознаками без фактичного підтвердження її наявності. Цей метод є найшвидшим і найпростішим для реалізації. Цей процес ідентифікує відкриті порти, що знайдені на кожному мережевому пристрої, і збирає пов’язані з портами заголовки (banner), знайдені під час сканування кожного порту. Аналіз заголовків дозволяє ідентифікувати операційну систему й використовувані сервіси аж до конкретної версії. На підставі апріорних знань про наявність вразливостей в тій чи іншій версії ПЗ робиться висновок про наявність або відсутність вразливості в системі, яку аналізують.

Варто зазначити, що певна функціональність щодо аналізу заголовків включається навіть в ПЗ, яке призначене лише для сканування мереж (як розглянутий у попередній роботі Nmap). ПЗ, що спеціально призначене для пошуку вразливостей, обов’язково має базу даних щодо вразливостей, і механізми її оновлення.

Зондування (active check) – механізм активного аналізу, який дозволяє впевнитись, чи присутня вразливість на вузлі, що аналізують. Зондування виконнується шляхом імітування атаки, що використовує вразливість, яку перевіряють. Цей метод повільніший, чим сканування, але майже завжди значно точніший. Цей процес використовує інформацію, що була отримана в процесі сканування, для детального аналізу кожного мережевого пристрою.

Наприклад, в ході сканування можна отримати відомості про відкриті TCP порти №№ 135, 139. Це ознака використання в мережі служби NetBIOS (майже напевно, на системі, яку сканують, встановлено операційну систему від Microsoft). При цьому можна одразу підозрювати численні вразливості, притаманні системам Windows і протоколу NetBIOS. Далі логічною є взаємодія з системою за протоколом NetBIOS для вивчення наявності загальнодоступних (shared) ресурсів, захищеності цих ресурсів паролем. При цьому можна отримати відомості про користувачів системи, наявність можливості адміністрування системи через мережу, тощо. За цими даними можна отримати детальні й достатньо достовірні відомості про наявність вразливостей.

Також під час зондування можуть використовуватись відомі методи реалізації атак для того, щоб остаточно підтвердити або спростувати наявність тих вразливостей, які припускаються за результатами сканування, а також виявити інші вразливості, які не можуть бути виявлені пасивними методами, як, наприклад, нестійкість до атак типу “відмова в обслуговуванні” (“denial of service”).

Необхідною складовою сканера безпеки є система підготовки звітів. Оскільки основним призначенням цього ПЗ є надання інформації системним адміністраторам, доброю ознакою якості програми є її здатність не лише виявляти вразливості, але й надавати рекомендації з їх усунення.

Одним з перших мережевих сканерів був SATANSystem Administrator Tool for Analysis of the Network. В часи його появи (перша половина 90-х) ситуація з безпекою в Internet була просто катастрофічна (достатньо пригадати успішне розповсюдження “віруса Морріса”, який автоматично, без втручання користувачів, за одну ніч спромігся здійснити проникнення на тисячі хостів). Тому поява SATAN – засобу, доступного для використання усіма зацікавленими, спричинила величезний галас. Зрештою, переміг здоровий глузд – неможливо заборонити розробку і розповсюдження подібних засобів через погану захищеність хостів, навпаки, слід підтримувати достатній рівень захищеності хостів і для контролю цього періодично застосовувати сканери безпеки.

Ніколи не можна сподіватись, що ваша система не буде знайдена зловмисниками, не буде для них цікавою, або вони не будуть достатньо оснащені або компетентні. Як правило, все відбувається навпаки. Зловмисників багато, вони добре оснащені, серед них є дуже талановиті і досвідчені. Успіх адміністратора безпеки ніколи не буває остаточним, оскільки успішними повинні бути всі без виключення його дії протягом всього часу роботи системи. Але система може бути скомпрометована внаслідок лише однієї з дуже багатьох спроб лише одного з дуже багатьох порушників, навіть якщо всі інші спроби виявились невдалими. Результат – успіх зловмисника. Тому слід розуміти – адміністратор безпеки повинен постійно випробувати свою систему “на міцність” (звичайно ж, з дотриманням мір обачності). Він повинен бути на крок попереду зловмисників, користуючись своєю обізнаністю щодо особливостей системи.

Пошук вразливостей є ще більш загрозливою активністю в мережі, ніж сканування портів. Якщо його проводить неуповноважена або некомпетентна особа, можуть виникнути наслідки, такі як відмова систем або їх компонентів, втрата або псування інформаційних ресурсів, розголошення конфіденційної інформації. Але ті ж дії у виконанні грамотних адміністраторів є невід’ємною складовою мережевої безпеки.

Сканери безпеки бувають комерційні і вільні (безкоштовні). Мабуть, найвідоміший з комерційних сканерів – Internet Scanner, продукт компанії Internet Security Systems.

З некомерційних сканерів слід відзначити сканер nessus, який складається з ядра, що працює під керуванням Unix, та клієнтської частини, яка існує для різних систем. Ядро здійснює сканування, використовуючи базу даних по вразливостям. Клієнтська частина реалізує інтерфейс користувача. Сканер розповсюджується безкоштовно, з відкритим кодом.

Дуже широкого поширення набула програма російських розробників XSpider. Хоча її бази даних були розраховані на пошук вразливостей переважно в системах Windows (для інших платформ програма також надавала певний обсяг інформації, але він поступався і детальністю, і точністю), програма мала зручний інтерфейс, надавала детальні звіти, а при застосуванні імітації атак ефективно використовувала вразливості, в тому числі підбирала слабкі паролі. На жаль, успіх програми дозволив розробникам перевести її на комерційну основу, остання безкоштовна версія датована груднем 2002 року.

Також слід пам’ятати, що для платформи Windows існує безкоштовний сканер безпеки від розробників – Microsoft. Його застосування вимагає повноважень адміністратора, і хоча ніхто не знає вади Windows краще за їх творців з Microsoft, деякі вразливості цей сканер може не помічати через те, що розробникі не бажають їх такими визнавати. З іншого боку, цей продукт дуже зручний для оцінювання поточного стану системи, особливо стосовно встановлення необхідних оновлень і виправлень.

Для виконання лабораторної роботи можна використовувати сканер XSpider. Деяка інформація про порядок роботи з програмою наведена в Додатку 3.

У попередній роботі ми вже звертали увагу на правові питання здійснення сканування мережі. Використання сканера безпеки ще критичніше, оскільки крім сканування він здатний здійснювати також і зондування цілі, а це вже фактично є здійсненням атаки. Тому в жодному разі не використовуйте сканери безпеки у мережах, в яких ви не є адміністратором, а використання сканера не погоджено з відповідальними особами (не слід забувати, що адміністратор фактично є технічним обслуговуючим персоналом, а не безроздільним господарем мережі, тому навіть адміністратор не повинен здійснювати сканування будь-коли за власним розсудом).

Хід роботи 

  1.  Ознайомтеся з ПЗ XSpider.
  2.  Проаналізуйте налаштовування програми XSpider.
  3.  Проскануйте локальну систему.
  4.  Здійсніть сканування вказаного хосту.
  5.  Включіть режим проведення атак на відмову в обслуговуванні і проскануйте вказаний хост.
  6.  Здійсніть сканування не-Windows системи (наприклад, Linux, FreeBSD, керований мережевий пристрій).
  7.  Оформіть звіт, використовуючи підсистему побудови звітів ПЗ XSpider.

Контрольні запитання

  1.  Назвіть типи засобів аналізу захищеності.
  2.  Назвіть види вразливостей, що виявляються засобами аналізу захищеності.
  3.  Назвіть способи виявлення вразливостей.
  4.  Охарактеризуйте етапи роботи сканера безпеки.

Лабораторна робота №10. Системи виявлення атак

Мета роботи

ознайомлення з ПЗ систем виявлення атак

Теоретичні відомості

Загальні відомості про системи виявлення атак

Системами виявлення атак (СВА, рос. – системы обнаружения атак, англ. – intrusion detection sensors, IDS) називають програмні засоби автоматичного виявлення в даних моніторингу інформаційно-телекомунікаційних систем (ІТС) подій, що вказують на порушення політики безпеки. Існують два класа СВА за ознакою використовуваних даних моніторингу: системні (на рівні хоста) і мережеві. Системні СВА в якості вихідних даних для аналізу використовують журнали реєстрації (авдиту) операційних систем та/або прикладного ПЗ контрольованих комп’ютерів. Мережеві СВА використовують дані мережевого обміну (трафік), що безпосередньо передаються в контрольованій мережі (отримання таких даних здійснюється за тими ж методиками, що й прослуховування мережевого трафіку, яке було розглянуто раніше).

СВА вирішують такі завдання:

  •  збирання даних моніторингу;
  •  редукція даних;
  •  аналіз даних з метою виявлення ознак порушень політики безпеки;
  •  побудова звітів;
  •  реагування на виявлені порушення.

Збирання даних полягає в отриманні, інтеграції й обробці файлів журналів реєстрації (для системних СВА) або перехопленні й розборі мережевого обміну (для мережевих СВА). В мережевих СВА для рішення цього завдання може застосовуватись спеціалізована реалізація стеку мережевих протоколів.

Редукція даних – це зведення зібранної інформації про активність однієї задачі АС або окремої сесії користувача чи сеансу мережевого зв’язку до атомарної форми, наприклад, до одного запису в базі даних.

Аналіз даних полягає у власне виявленні ознак порушень. Існують два підходи до рішення цієї задачі – виявлення зловживань і виявлення аномалій.

Для використання першого створюється опис відомих порушень за ознаками, які спостерігаються (набір шаблонів, або сигнатур). Такий опис, крім компактного подання порушень, повинен також забезпечувати урахування всіх можливих їх варіацій. В подальшому СВА, що використовує виявлення зловживань, виконує порівняння поточних даних моніторингу з цим описом і фіксує порушення при співпадіннях з одним із шаблонів. Зрозуміло, що подібно до антивірусних систем, така СВА буде ефективною лише за умови своєчасного оновлення набору сигнатур.

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

Побудова звітів здійснюється на основі зафіксованих порушень з метою подальшого аналізу адміністраторами безпеки (авдиторами).

Реагування на виявлені порушення может набувати самих різних форм, починаючи від повідомлення адміністратора безпеки й закінчуючи закриттям мережевих з’єднань і переналаштовуванням маршрутизаторів і міжмережевих екранів. Можливість рішення цієї задачі з’явилась у сучасних СВА лише останнім часом, оскільки методи аналізу СВА й обчислювальні потужності комп’ютерів раніше не дозволяли проводити аналіз в режимі реального часу.

Мережеві системи виявлення атак (МСВА, NIDS)

Деякі МСВА реалізуються у вигляді спеціалізованих програмно-апаратних засобів. Наприклад, широко відомі пристрої IDS компанії Cisco (в Україні вони мають експертний висновок на відповідність вимогам критеріїв з захищеності інформації). Крім очевидних переваг, ці й аналогічні пристрої інших виробників мають дуже високу ціну, що обмежує їх поширення в умовах України.

Інший підхід до реалізації МСВА – використання звичайного комп’ютера із спеціалізованим програмним забезпеченням. Такий МСВА базується на платі мережевого інтерфейсу, яка працює в “безладному” (promiscuous), або наскрізному режимі, тобто прослуховує всі пакети на одиночному фізичному кабелі.

Компонент МСВА, який забезпечує контроль трафіку в мережі називається сенсором. Якщо ви бажаєте контролювати трафік, що надходить до кількох Web-серверів, одним сенсором, ви повинні розташувати цей сенсор на тій ділянці кабеля, через яку будуть проходити всі пакети.

Рис. 10.1

У простій ЛОМ без ДМЗ (див. рисунок 10.1) є два оптимальних місця розташування сенсору: між маршрутизатором і відкритою мережею (Інтернет), і між маршрутизатором і локальною мережею (ЛОМ), яку захищають. Перша конфігурація, позначена (1), виявить всі атаки проти мережі, но не буде показувати, які атаки фактично проходять через маршрутизатор в ЛОМ. Крім того, у цій позиції МСВА не побачить атаки, які здійснюються в самій захищеній мережі. Друга конфігурація, позначена (2), покаже, які атаки проникають у ЛОМ, або ініціюються в ній.

У мережі з ДМЗ є три ймовірних місцеположення для сенсора (див. рисунок 10.2.).

Рис. 10.2.

Ця ситуація складніша. Хости (сервери) в ДМЗ можуть пропонувати різні типи послуг, що змінюються, и працювати під керуванням різних операційних систем.

Якщо сенсор розташовано в положенні 1, то він виявить всі спроби атак проти захищеної мережі.

Сенсор, розташований в положенні 2, виявить всі атаки, які проходять через зовнішній маршрутизатор. Якщо на меті є виявлення атак проти хостів ДМЗ, то саме у цьому положенні слід розташувати сенсор. Це розташування виявить також атаки, що спрямовані на захищену ЛОМ, але не дасть відповіді, чи була атака успішною.

Положення 3 виявить атаки, які досягають захищеної ЛОМ, але не атаки, що націлені на хости ДМЗ.

Може здаватись, що сенсори в положенні 1 дають небагато. Дійсно, якщо все, що робить маршрутизатор – це тільки маршрутизація, то положення 1 не є ефективним для сенсора. Якщо ж маршрутизатор 1 – це міжмережевий екран, або він здійснює будь-яку фільтрацію пакетів, то дані сенсора в положенні 1 можна порівняти з даними сенсора в положенні 2, щоби виміряти, як добре зовнішній міжмережевий екран робить свою справу.

Для обрання місць розташування сенсора(ів) слід проаналізувати конфігурацію мережі і визначити, що саме необхідно контролювати. Сенсор виявить весь трафік на фізичному проводі. Стандартний концентратор (hub) повторює все з одного порту на решту його портів, тому підключення сенсора до комутатора, що вставлений в розрив кабелю, дійсно дозволить зафіксувати весь трафік у даній ділянці мережі. Комутатор буде шукати в своїй таблиці MAC адресу призначення пакету і комутувати пакет тільки до належного порту, тому у сучасній мережі, побудованій на комутаторах, безпосередньо підключити сенсор практично неможливо.

Типовою і рекомендованою є конфігурація підключень між маршрутизатором и ЛОМ, що подана на рисунку 10.3.

Рис. 10.3

Більшість добре сконструйованих мереж використовують комутатор для підключення маршрутизатора до ЛОМ або хостів ДМЗ. Це робиться для того, щоби зменшити циркулярний трафік в каналі зв’язку. Розташування концентратора між маршрутизатором і комутатором утворює вузол, який дозволить легко переміщувати сенсор.

Система виявлення атак Snort

Спеціалізоване програмне забезпечення, яке реалізує на комп’ютері функції МСВА, розглянемо на прикладі ПЗ Snort. Snort – мережева система виявлення атак з відкритим вихідним кодом. Вона використовує просту у вивченні систему правил для виявлення й реєстрації сигнатур можливих атак. Спочатку вона була створена для операційних систем Unix, а тепер портована також для сімейства операційних систем Windows.

Причини обрати Snort замість інших мережевих систем виявлення атак витікають з факту, що це система з відкритим вихідним кодом:

  •  Вона розповсюджується безкоштовно.
  •  Її мову правил легко вивчити, а це означає:
    •  з появленням інформації про нові експлоіти (exploit), ви можете легко їх врахувати;
    •  ви можете створювати правила для застосування у будь-якій особливій ситуації, з якою вам доведеться зіткнутись.
  •  Snort має активно підтримувану базу правил.
  •  Існує широка підтримка Snort в комп’ютерному співтоваристві.
  •  SiliconDefense.Com пропонує розумну комерційну підтримку Snort.

В Додатку 4 наведені основи роботи із Snort в системі Unix, а в Додатку 5 описано використання програми IDScenter для керування Snort в системі Windows.

Хід роботи

  1.  Детально ознайомтесь з документацією Snort.
  2.  Запустіть Snort на обраній вами або викладачем платформі (Windows, FreeBSD). Перегляньте найпростіші правила, навчіться вносити до них зміни. Добийтесь того, щоби Snort фіксував трафік у мережі і реагував на найпростіші події (“пінгування” портів, надходження TCP пакетів тощо).
  3.  Підготуйтесь до моделювання атаки (згідно варіанту) на вашу мережу. Сканування портів можна виконувати за допомогою nmap або XSpider. Для підбирання паролів або створюється відповідна програма (сценарій), або використовується існуючий exploit.
  4.  Підберіть з існуючих файлів або самостійно створіть правила для виявлення заданого виду атак, налаштуйте і запустіть Snort.
  5.  Змоделюйте атаку і спробуйте зафіксувати її за допомогою Snort.
  6.  Оформіть звіт.

Варіанти завдань

  1.  Сканування портів.
  2.  Підбір паролю по FTP.
  3.  Підбір паролю по Telnet.
  4.  Ping-of-Death.

Контрольні запитання

  1.  Охарактеризуйте умови застосування мережевих і системних СВА.
  2.  Чи заміняє СВА традиційні засоби розмежування доступу? Обґрунтуйте.
  3.  Де в мережі слід розміщувати МСВА? Прокоментуйте різні місця розташування на схемі мережі, запропонованої викладачем.
  4.  Які обмеження існують у використанні СВА?

Лабораторна робота №11. Міжмережеві екрани

Мета роботи

ознайомлення із засобами розмежування доступу в мережах

Теоретичні відомості

Мережеві засоби розмежування доступу (міжмережеві екрани, або брандмауери) призначені для захисту внутрішніх ресурсів мереж шляхом обмеження можливостей обміну між ними. При цьому комп’ютер, на якому виконується ПЗ міжмережевого екрану (МЕ), або спеціалізований програмно-апаратний пристрій, що реалізує функції МЕ, слугує шлюзом між двома мережами, найчастіше – Інтернет і корпоративною мережею.

Пристрій, подібний до мережевого екрану, може використовуватись для захисту окремого комп’ютера. В такому випадку екран у вигляді спеціалізованого програмного забезпечення встановлюється на комп’ютер, який підлягає захисту, і контролює весь вхідний і вихідний трафік. Такий мережевий екран часто називають персональним брандмауером.

В загальному випадку робота міжмережевого екрану базується на динамічному виконанні двох груп функцій:

  1.  фільтрації інформаційних потоків, що проходять крізь нього;
  2.  посередництва при реалізації міжмережевої взаємодії (проксі-сервер).

Фільтрація трафіка здійснюється на основі набору правил, які попередньо завантажуються до мережевого екрану. Ці правила є відображенням мережевих аспектів політики безпеки. Оскільки результат обробки пакету в загальному випадку залежить від послідовності застосування правил, правила є упорядкованими. Механізм застосування правил можна уявити як послідовність фільтрів. Кожний фільтр містить набір критеріїв, яким повинен задовольняти пакет. Якщо пакет відповідає критеріям цього фільтру, по відношенню до пакету застосовується визначена дія:

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

Якщо пакет не відповідає критеріям фільтру, він просто передається на наступний фільтр. Набір правил повинен забезпечувати визначеність дій, що застосовуються до кожного пакета. Тому повинно існувати “правило за замовчуванням”, яке застосовується до будь-якого пакету, для якого не знайшлося відповідного йому фільтру. Від того, що це за правило, залежить принцип політики безпеки, який реалізує мережевий екран. Фактично можливими є два правила за замовчуванням – пропустити або не пропустити пакет, і, відповідно, реалізуються два різних принципи політики безпеки.

Перший – відфільтровувати всі потенційно небезпечні пакети, а решту пропускати за замовчуванням. Такий підхід дозволяє бути спокійним за доступність ресурсів мережі, але не гарантує достатнього захисту, оскільки пропущеним буде будь-який пакет з непередбаченими параметрами. Тому цей підхід вважається хибним. Інший підхід дозволяє реалізувати принцип мінімуму повноважень: “заборонено все, що не дозволено явно”. Тобто, правило за замовчуванням – відкинути всі пакети, що не відповідають явно заданим фільтрам. Звичайно, сам по собі такий підхід ще не гарантує захисту, оскільки його можна легко зіпсувати занадто ліберальними правилами, що пропускають пакети. Але відсутність “ліберальних” правил фактично вимагає окремого явного дозволу для кожного сервісу, який повинен бути доступним у мережі.

Розрізняють три рівня функціональності МЕ, у порядку зростання:

  •  пакетні фільтри, які також називають екрануючими маршрутизаторами – працюють головним чином на 3-му (мережевому) рівні еталонної моделі взаємодії відкритих систем OSI, як правило, аналізують також інформацію із заголовків протоколів 4-го (транспортного) рівня;
    •  шлюзи сеансового рівня, які також називають екрануючим транспортом – працюють головним чином на 5-му (сеансовому) рівні моделі OSI;
    •  прикладні, або екрануючі шлюзи, що працюють на прикладному рівні моделі OSI.

При цьому МЕ, що реалізують функціональність будь-якого рівня, як правило, реализують також і функціональність попередніх (нижчих) рівнів.

Пакетні фільтри здійснюють розбір заголовків пакетів для протоколів TCP, UDP, IP і, в залежності від заданого адміністратором безпеки набору правил, приймають рішення про дії з пакетом. Кожний пакет аналізується окремо, без зв’язку з іншими. Тим самим забезпечується фільтрація пакетів за такими параметрами:

  •  IP-адреси відправлювача й отримувача;
    •  тип пакету (протокол);
    •  флаг фрагментації пакету;
    •  номери портів TCP (UDP) відправлювача й отримувача.

Шлюзи сеансового рівня призначені для контроля віртуальних з’єднань і трансляції IР адрес (Network Address Translation, NAT) при взаємодії із зовнішньою мережею. Захисні функції шлюзів сеансового рівня відносяться до функцій посередництва.

Так, при спробі з’єднання із будь-яким з власних TCP портів такий МЕ, в залежності від своїх налаштовувань, може ініціювати з’єднання з іншим портом іншого комп’ютера (як правило, всередині захищеної мережі), після чого передавати дані в обох напрямах. Для комп’ютера-ініціатора з’єднання все виглядає так, ніби він працює з сервісом на самому МЕ. Ще більш типовим випадком є дозвіл ініціювати з’єднання лише зсередини захищеної мережі, при цьому для зовнішніх комп’ютерів ініціатором з’єднання виглядає МЕ. Головною перевагою таких МЕ є можливість приховати внутрішню структуру захищеної мережі. МЕ мережевого рівня может поєднувати дві мережі з різними адресними просторами.

Контроль віртуальних з’єднань полягає в контролі за встановленням ТСР з’єднання і відслідковуванні послідовності пакетів і квитанцій-підтверджень у встановлених з’єднаннях. Для цього шлюз сеансового рівня повинен зберігати інформацію про встановлені з’єднання у спеціальних таблицях.

МЕ прикладного рівня працюють як проксі-сервери протоколів прикладного рівня (HTTP, FTP, Telnet тощо). На відміну від шлюзу сеансового рівня, такий МЕ містить в собі не просто транслятор з’єднань, а сервери прикладних протоколів. Крім можливості приховування внутрішньої структури захищеної мережі, такі МЕ дозволяють використовувати для розмежування доступу достатньо широкий спектр засобів автентифікації прикладного рівня, обмежуючи доступ на основі комбінації адрес, номерів портів, повноважень окремих користувачів, реального часу.

Розміщення МЕ в мережі показано на ілюстрації в описі попередньої роботи (рисунок 10.3). Типовим є виділення так званої демілітарізованої зони (ДМЗ), правила обміну з якою відмінні від правил обміну з внутрішньою (захищеною) мережею. В ДМЗ переважно розміщують сервери, до яких необхідно відкрити доступ із зовнішньої мережі (наприклад, корпоративний веб-сайт). Це дозволяє встановити більш жорсткі обмеження на взаємодію із внутрішньою мережею. Так, наприклад, винесення в ДМЗ ftp, http і поштового серверів дозволяє повністю заборонити доступ до внутрішньої мережі за номерами портів 21, 25 і 80.

В роботі пропонується ознайомитись з МЕ ipfirewall, що входить до ядра операційної системи FreeBSD. МЕ ipfirewall має можливості як пакетного фільтру, так і шлюзу сеансового рівня.Для того, щоби задіяти цей МЕ, необхідно зібрати ядро системи з встановленою відповідною опцією. Для керування МЕ використовується команда ipfw. Синтаксіс команди і формат правил МЕ наведені в Додатку 6.

Хід роботи

  1.  Ознайомтесь з інтерфейсом МЕ ipfilter – програмою ipfw.
  2.  Додайте в набір правил правило, що дозволяє передачу всіх пакетів, під номером 1.
  3.  Здійсніть за допомогою утиліти nmap сканування портів комп'ютерів, що знаходяться з різних сторін МЕ.
  4.  Створіть свій набір правил фільтрації пакетів згідно завдання викладача і завантажте його в ipfw.
  5.  Повторно здійсніть сканування портів аналогічно п.3
  6.  Оформіть звіт.

Звіт має містити:

  1.  ваш набір правил фільтрації пакетів;
  2.  протоколи сканування портів;
  3.  висновки.

Варіанти завдань

  1.  Пропустити лише TCP пакети між хостами 1 і 2 (IP адреси визначає викладач)
  2.  Заборонити проходження ping (пакети ICMP echo request)
  3.  Дозволити виступати в якості ініціатора з’єднання лише хостам внутрішньої мережі
  4.  Дозволити трафік на порти FTP і HTTP

Контрольні запитання

  1.  Охарактеризуйте переваги і недоліки МЕ різних рівнів.
  2.  Опишіть загрози, від яких можна захиститься використанням МЕ.
  3.  Запропонуйте способи обходу МЕ.
  4.  Що таке ДМЗ?

Додаток 1. Використання утіліти tcpdump

Наведена далі інформація про використання tcpdump базується на авторській документації з довідкової системи man. Додано деякі пояснюючи коментарі, виключені частини щодо інтерпретації деяких протоколів (AppleTalk, AFS), які не використовуються в цьому лабораторному практикумі. Рекомендується ознайомитись з оригіналом документації.

Авторами програми є Van Jacobson, Craig Leres і Steven McCanne, всі з Lawrence Berkeley National Laboratory, University of California, Berkeley, CA. Зараз програма підтримується tcpdump.org. Поточну версію можна завантажити через HTTP: http://www.tcpdump.org/

tcpdump виводить результати аналізу заголовків пакетів, що були зафіксовані на мережевому інтерфейсі, які відповідають булевому виразу expression. Для роботи tcpdump переводить мережевий інтерфейс в режим “безладного” захоплення пакетів (promiscuous mode), що дозволяє передавати ядру системи всі пакети, що були в каналі зв’язку, а не лише ті, що адресовані цьому інтерфейсу. expression задає фільтр, за яким відбираються пакети, а опції команди tcpdump здебільшого впливають на об’єм і формат виводу, а також на загальні параметри роботи утіліти.

Переведення мережевого інтерфейсу в “безладний” режим вимагає додаткових повноважень від користувача. Так, в системі BSD для запуска tcpdump ви повинні мати доступ на читання з /dev/bpf*. Іноді необхідно мати повноваження суперкористувача.

Формат команди

tcpdump [ -adeflnNOpqRStvxX ] [ -c count ] [ -F file ]

       [ -i interface ] [ -m module ] [ -r file ]

       [ -s snaplen ] [ -T type ] [ -w file ]

       [ -E algo:secret ] [ expression ]

Тут і далі: напівжирним шрифтом виділені ключові слова й параметри, підкреслюванням виділені назви параметрів, що підставляють. Фрагменти, що взяті в квадратні дужки, є опціональними (необов’язковими).

Опції

-a Намагатись перетворювати мережні й циркулярні адреси в імена.

-c Завершити роботу після одержання count пакетів.

-d Вивести код зіставлення пакета в зручному для сприйняття вигляді на стандартний вивід й зупинитися.

-dd Вивести код зіставлення пакета у вигляді фрагмента C-програми.

-ddd Вивести код зіставлення пакета у вигляді десяткових чисел (із передуючим індексом).

-e Друкувати заголовок канального рівня на кожному рядку дампа.

-E Використовувати algo:secret для розшифрування IPsec ESP пакетів. Опція призначена лише для цілей відлагодження, використовувати цю опцію з дійсно таємним ключем не можна.

-f Друкувати «чужі» адреси інтернет в числовій формі, а не символічно (ця опція призначена для YP-сервера Sun, який зависає, транслюючи нелокальні інтернет-адреси).

-F Використовувати file для вводу фільтруючого виразу (expression). Додатковий вираз, якщо він заданий в командному рядку, ігнорується.

-i Прослуховувати інтерфейс interface. Якщо ця опція не задана, tcpdump шукає в списку системних інтерфейсів сконфігурований активний інтерфейс з найменшим номером (виключаючи loopback).

На системах Linux з ядром 2.2 і наступними, може використовуватись “any” в якості аргумента interface для захоплення пакетів зі всіх інтерфейсів. Слід зазначити, що захоплення на пристроях “any” не будуть проводитись в “безладному” режимі (promiscuous mode).

-l Буферизовати рядки стандартного виводу. Корисно в тому випадку, коли ви бажаєте переглядати дані під час захоплення їх. Наприклад:

tcpdump -l | tee dat

або

tcpdump –l > dat & tail –f dat

-n Не перетворювати адреси (а саме адреси хостів, номери портів и т.і.) в імена.

-N Не друкувати доменну класифікацію імен хостів. Тобто, якщо ви задасте цей флаг, tcpdump надрукує “nic” замість “nic.ddn.mil”.

-m Завантажити визначення модулів SMI MIB з файлу module. Ця опція може використовуватись кілька разів для завантаження кількох модулів MIB в tcpdump.

-O Не запускати оптимізатор коду зіставлення пакетів. Це корисно лише якщо ви підозрюєте помилку в оптимізаторі.

-p Не переводити інтерфейс в режим безладного захоплення. Слід зазначити, що інтерфейс може знаходитись в цьому режимі з якихось інших причин; тому “-p” не може використовуватись в якості скорочення виразу:

ether host {local-hw-addr} or ether broadcast

-q Швидкий (quick) та одночасно скорочений (quiet) вивід. Друкує менше інформації.

-r Читати пакети з файлу file (який було створено опцією -w). Стандартний ввід використовується, якщо в якості file вказано
-”.

-s Аналізувати snaplen байт даних з кожного пакета замість 68-ми за замовчанням. 68-ми байт достатньо для IP, ICMP, TCP та UDP, але вони можуть обрізати протокольну інформацію з пакетів серверу імен і NFS. Пакети, що обрізані через обмежену кількість вихоплених байт, позначаються у вихідній інформації “[|proto]”, де proto – ім’я протоколу, на якому мало місце обрізання. Використання більшого об’єму даних для аналізу одночасно збільшує час, що витрачається для обробки пакетів, і зменшує простір для буферізації пакетів. Це може призвести до втрати пакетів. Слід обмежувати snaplen найменшим значенням, що дозволить проаналізувати інформацію, яка вас цікавить. Встановити snaplen в 0 означає використовувати необхідну довжину для захоплення пакетів цілком.

-T Примусово інтерпретувати пакети, що обираються фільтром expression, як пакети вказаного типу type. Типи, що відомі в поточній версії, це cnfp (Cisco NetFlow protocol), rpc (Remote Procedure Call), rtp (Real-Time Applications protocol), rtcp (Real-Time Applications control protocol), snmp (Simple Network Management Protocol), vat (Visual Audio Tool), і wb (distributed White Board).

-R Вважати, що пакети ESP/AH основані на старій специфікації (RFC1825 ... RFC1829). Якщо задана ця опція, tcpdump не буде друкувати поле запобігання відповіді. Оскільки в специфікації ESP/AH немає поля версії протоколу, tcpdump не може визначити версію протоколу ESP/AH.

-S Виводити абсолютні номери послідовності TCP замість відносних.

-t Не друкувати відмітку часу в кожному рядку виводу.

-tt Друкувати неформатовану відмітку часу в кожному рядку виводу.

-ttt Друкувати різницю (в мікросекундах) між поточним і попереднім рядком в кожному рядку виводу.

-tttt Друкувати відмітку часу у форматі за замовчанням і відмічати дату в кожному рядку виводу.

-v Трохи більш детальний вивід. Наприклад, для IP пакету друкується час життя (time to live), ідентифікація, повна довжина і опції. Також забезпечує додаткові перевірки цілісності пакету, як-то верифікація контрольних сум IP та ICMP заголовків.

-vv Ще більш детальний вивід. Наприклад, додаткові поля друкуються для пакетів відповідей NFS.

-vvv Навіть ще більш детальний вивід. Наприклад, опції telnet SB ... SE друкуються повністю. З -X опції telnet друкуються також і в шістнадцятковому форматі.

-w Записувати необроблені пакети в файл file замість аналізу і роздрукування них. В подальшому вони можуть бути проаналізовані і роздруковані з опцією -r. Якщо file – це “-”, використовується стандартний вивід.

-x Друкувати кожний пакет (мінус його заголовок канального рівня) в шістнадцятковому форматі. Буде виводитись snaplen байт, або пакет повністю, якщо менше за snaplen.

-X Коли друкувати в шістнадцятковому форматі, також друкувати в ASCII. Так, якщо -x також встановлено, пакет друкується в HEX/ASCII. Це дуже зручно для аналізу нових протоколів. Навіть якщо -x не встановлено, деякі частини деяких пакетів можуть друкуватись в форматі HEX/ASCII.

Формат виразу expression

expression – це фільтр, що обирає, які пакети слід виводити. Якщо фільтр не задано, будуть виводитись всі пакети з мережі. В іншому разі будуть виводитись лише ті пакети, для яких значення булевого виразу expression є “істина”.

Вираз expression складається з одного або більше примітивів. Примітиви звичайно складаються з ідентифікатору id (ім’я або число), якому передують один або більше кваліфікаторів. Існує три різних типи кваліфікаторів:

type Кваліфікатори типу визначають, до чого стосується ідентифікатор id. Можливі значення кваліфікатору – host, net і port. Наприклад, “host foo”, “net 128.3”, “port 20”. Якщо кваліфікатор типу не заданий, припускається тип host.

dir Кваліфікатори визначають напрям передачі до та/або від об’єкту, що заданий ідентифікатором id. Можливі напрямки: src, dst, src or dst та src and dst. (Тобто, “джерело”, “призначення”, “джерело або призначення”, “джерело та призначення”). Наприклад, “src foo”, “dst net 128.3”, “src or dst port ftp-data”. Якщо кваліфікатор напрямку не заданий, припускається src or dst. Для протоколів точка-точка, таких, як SLIP, можуть використовуватись кваліфікатори inbound (вхідний) та outbound (вихідний) для позначення бажаного напрямку.

proto Кваліфікатори визначають певний протокол. Можливі протоколи – це: ether, fddi, tr, ip, ip6, arp, rarp, decnet, lat, sca, moprc, mopdl, iso, esis, isis, icmp, icmp6, tcp and udp. Наприклад, “ether src foo”, “arp net 128.3”, “tcp port 21”. Якщо кваліфікатор протоколу не заданий, припускаються всі протоколи, що сумісні з визначеним типом ідентифікатора. Наприклад, “net bar” означає “(ip or arp or rarp) net bar” а “port 53” означає “(tcp or udp) port 53”.

fddi” фактично є псевдонімом для “ether”; вони обробляються ідентично і мають значення “протокол канального рівня, що використовується на вказанному мережевому інтерфейсі”. Заголовок FDDI містить подібні до Ethernet адреси джерела й призначення, і часто містить подібні до Ethernet типи пакетів, тому з цими полями заголовку FDDI можна працювати так само, як і з аналогічними полями заголовку Ethernet. Заголовок FDDI також містить інші поля, але фільтрувати за ними безпосередньо через вираз expression неможливо.

Аналогічно, “tr” – це псевдонім для “ether”; все, що було вказано про заголовки FDDI, в рівній мірі стосується заголовків Token Ring.

На додачу до викладеного вище, існують деякі примітиви, які не відповідають викладеній схемі. Для них зарезервовані спеціальні ключові слова: gateway, broadcast, less, greater, а також арифметичні вирази. Всі вони розглядаються далі.

Більш складні фільтруючі вирази будуються шляхом використання слів and, or та not для комбінування примітивів. Наприклад, “host foo and not port ftp and not port ftp-data”. Для скорочення, ідентичні списки кваліфікаторів можуть опускатись. Наприклад, “tcp dst port ftp or ftp-data or domain” – це те ж саме, що “tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain”.

Приклади найуживаніших припустимих примітивів

dst host host

Істина, якщо поле призначення пакета протоколу IPv4/v6 є host, який може задаватись як адресою, так і ім’ям.

src host host

Істина, якщо поле джерела пакета протоколу IPv4/v6 є host.

host host

Істина, якщо або поле джерела або поле призначення пакета протоколу IPv4/v6 є host. Будь-якому з наведених вище виразів можуть передувати ключові слова ip, arp, rarp або ip6. Наприклад:

ip host host

що еквівалентно:

ether proto \ip and host host

Останній рядок “розшифровується” так: значення буде “істина” для пакетів протоколу IP (proto \ip), що визначається з відповідного поля заголовку канального (ether) рівня, причому пакети повинні мати або джерелом або призначенням хост host (кваліфікатор напрямку опущений, за замовчанням використовується src or dst). Знак “\” перед ip використовується для того, щоб відрізнити значення параметру protocol примітиву ether proto protocol (див. далі) від ключового слова ip.

Якщо host заданий ім’ям, якому відповідають кілька IP адрес, кожна з них буде перевірятись на відповідність.

ip broadcast

Істина, якщо пакет є циркулярним IP-пакетом. Цей примітив перевіряє як циркулярні адреси всі-нулі, так і всі-одиниці, і шукає маску підмережі.

ip multicast

Істина, якщо пакет є груповим IP-пакетом.

ip6 multicast

Істина, якщо пакет є груповим IPv6-пакетом.

ether dst ehost

Істина, якщо Ethernet-адреса призначення є ehost. ehost може задаватись ім’ям з файлу /etc/ethers або числом (числовий формат див. у ethers(3N)).

ether src ehost

Істина, якщо Ethernet-адреса джерела є ehost.

ether host ehost

Істина, якщо Ethernet-адреса джерела або призначення є ehost.

ether broadcast

Істина, якщо пакет є циркулярним пакетом Ethernet. Ключове слово ether є опціональним.

ether multicast

Істина, якщо пакет є груповим пакетом Ethernet. Ключове слово ether є опціональним. Цей примітив є скороченням для “ether[0] & 1 != 0”, тобто в першому байті заголовка Ethernet (перший з 6 байт MAC-адреси призначення) перший біт (за узгодженням IEEE першим зліва записується не старший, а молодший біт, тому він перевіряється за допомогою “& 1”) не дорівнює нулю.

gateway host

Істина, якщо пакет використовує хост host в якості шлюзу. Тобто, Ethernet-адреса джерела або призначення є host, але ні IP-адреса джерела, ні IP-адреса призначення не відповідають хосту host. host повинен задаватись ім’ям, яке повинно знаходитись і в /etc/hosts і в /etc/ethers. Еквівалентний вираз:

ether host ehost and not host host,

в якому можуть використовуватись як імена, так і чисельні значення для host / ehost.) В поточній версії цей синтаксіс не працює для IPv6.

dst net net

Істина, якщо IPv4/v6-адреса призначення пакета відповідає мережі net.  net може задаватись ім’ям з /etc/networks, або номером мережі (подробиці див. в networks(4)).

src net net

Істина, якщо IPv4/v6-адреса джерела пакета відповідає мережі net.

net net

Істина, якщо IPv4/v6-адреса джерела або призначення пакета має номер мережі net.

net net mask mask

Істина, якщо IP-адреса відповідає мережі net із заданною маскою мережі. Може додатково кваліфікуватись як src або dst. Цей синтаксіс не може застосовуватись для мереж IPv6.

net net/len

Істина, якщо IPv4/v6-адреса відповідає мережі net з маскою мережі в len біт. Може додатково кваліфікуватись як src або dst.

dst port port

Істина, якщо пакет є пакетом протоколів ip/tcp, ip/udp, ip6/tcp або ip6/udp і має порт призначення port.  port може бути числом або ім’ям з файлу /etc/services (див. tcp(4P) і udp(4P)). Якщо використовується ім’я, перевіряються як номер порту, так і протокол. Якщо використовується число або неоднозначне ім’я, перевіряється лише номер порту (наприклад, dst port 513 буде виводити як трафік tcp/login, так і трафік udp/who, а port domain буде виводити як трафік tcp/domain, так і udp/domain).

src port port

Істина, якщо пакет має порт джерела port.

port port

Істина, якщо пакет має або порт джерела, або порт призначення port. Будь-якому з наведених вище виразів можуть передувати ключові слова tcp або udp, як, наприклад:

tcp src port port

якому відповідають лише TCP пакети з портом джерела port.

less length

Істина, якщо пакет має довжину, що менша або дорівнює length. Це еквівалентно “len <= length”.

greater length

Істина, якщо пакет має довжину, що більша або дорівнює length. Це еквівалентно “len >= length”.

ip proto protocol

Істина, якщо пакет є IP-пакетом (див. ip(4P)) протоколу типу protocol. protocol може бути числом, або одним з імен: icmp, icmp6, igmp, igrp, pim, ah, esp, udp або tcp. Зверніть увагу, що ідентифікатори tcp, udp та icmp одночасно є ключовими словами і тому для правильної інтерпретації перед ними повинна ставитись зворотна коса риса “\” (backslash), яка в оболонці C-shell представляється подвійною зворотною косою рисою “\\”. Також слід зазначити, що цей примітив не відслідковує послідовність заголовків протоколів (тобто, протокол protocol повинен знаходитись безпосередньо в IP-пакеті).

ip6 proto protocol

Істина, якщо пакет є IPv6-пакетом протоколу типу protocol. Цей примітив також не відслідковує послідовність заголовків протоколів.

ip6 protochain protocol

Істина, якщо пакет є IPv6-пакетом і містить заголовок протоколу типу protocol в послідовності заголовків протоколів. Наприклад,

ip6 protochain 6

відповідає будь-якому пакету IPv6, що містить заголовок протоколу TCP в послідовності заголовків протоколів. Такий пакет може містити, наприклад, заголовок протоколу автентифікації або заголовок протоколу маршрутизації між заголовками IPv6 та TCP.

ip protochain protocol

Еквівалентно примітиву ip6 protochain protocol, але для протоколу IPv4.

tcp, udp, icmp

Скорочення для ip proto p or ip6 proto p, де p – один із зазначених протоколів.

ether proto protocol

Істина, якщо пакет має ідентифікатор протоколу EtherType protocol. protocol може бути числом або одним з імен: ip, ip6, arp, rarp, atalk, aarp, decnet, sca, lat, mopdl, moprc або iso. Зверніть увагу, що ці ідентифікатори є ключовими словами і тому для правильної інтерпретації перед ними повинна ставитись зворотна коса риса “\” (backslash), яка в оболонці C-shell представляється подвійною зворотною косою рисою “\\”.

У випадку FDDI (наприклад, “fddi protocol arp”), ідентифікація протоколу робиться за заголовком 802.2 LLC. Коли фільтрує за ідентифікатором протоколу, tcpdump вважає, що всі FDDI-пакети містять заголовок LLC в так званому SNAP-форматі. Те ж саме стосується Token Ring.

ip, ip6, arp, rarp, atalk, aarp, decnet, iso

Скорочення для ether proto p, де p – один із зазначених протоколів.

lat, moprc, mopdl

Скорочення для ether proto p, де p – один із зазначених протоколів. Поточна версія tcpdump не знає, як обробляти ці протоколи.

vlan [vlan_id]

Істина, якщо пакет є IEEE 802.1Q VLAN-пакетом. Якщо задано vlan_id, істина лише у випадку, якщо ідентифікатор VLAN пакету співпадає з vlan_id. Слід зазначити, що перше ключове слово vlan, що зустрічається у виразі expression, змінює зміщення декодування для залишку expression у припущенні, що пакет – це VLAN-пакет.

iso proto protocol

Істина, якщо пакет є OSI-пакетом протоколу protocol.  protocol може бути числом, або одним з імен clnp, esis або isis.

clnp, esis, isis

Скорочення для iso proto p, де p – один із зазначених протоколів. Слід зазначити, що tcpdump не повністю інтерпретує ці протоколи.

expr relop expr

Істина, якщо виконується співвідношення, в якому relop – один із знаків: >, <, >=, <=, =, !=, а expr – арифметичний вираз, що складений з цілих констант (що подані в стандартному синтаксисі C), звичайних бінарних операторів (+, -, *, /, &, |), оператора довжини і спеціальних аксесорів (засобів доступу) до даних пакета. Для доступу до даних всередині пакета, використовується такий синтаксіс:

proto [ expr : size ]

proto – одне із значень: ether, fddi, tr, ip, arp, rarp, tcp, udp, icmp або ip6, що вказує протокол для індексної операції. Слід зазначити, що tcp, udp та інші протоколи верхніх рівнів в поточній версії застосовуються лише для IPv4, не для IPv6. expr задає зміщення байту в пакеті відносно початку заголовку вказаного протоколу. size задається опціонально, і вказує кількість байт в обраному полі, може дорівнювати 1, 2 або 4 (за замовчанням 1). Оператор довжини, що задається ключовим словом len, дає довжину пакета.

Наприклад, “ether[0] & 1 != 0” ловить весь груповий трафік. Вираз “ip[0] & 0xf != 5” ловить всі IP-пакети з опціями. Вираз “ip[6:2] & 0x1fff = 0” ловить лише нефрагментовані дейтаграми і нульовий (початковий) фрагмент фрагментованих дейтаграм. Остання перевірка завжди неявно застосовується для індексних операцій з tcp та udp. Наприклад, tcp[0] завжди означає перший байт заголовка TCP, і ніколи не означає перший байт вкладеного в IP-пакет фрагмента.

Примітиви можуть комбінуватись з використанням:

  •  Групирування примітивів і операторів за допомогою дужок (дужки можуть мати спеціальне значення в Shell і для запобігання некоректній їх обробці Shell слід застосовувати спеціальні прийоми).
  •  Заперечення (“!” або “not”).
  •  Конкатенація (“&&” або “and”).
  •  Диз’юнкція (“||” or “or”).

Заперечення має найвищий пріоритет. Диз’юнкція і конкатенація мають рівний пріоритет і ассоціюються зліва направо. Для конкатенації потрібні явно задані знаки and, а не просто розміщення поруч.

Якщо ідентифікатор заданий без ключового слова, припускається найостанніше ключове слово. Наприклад, not host vs and ace є скороченням для not host vs and host ace, що не слід плутати з not ( host vs or ace )

Аргументи expression можуть передаватись в tcpdump або як один аргумент, або як кілька аргументів, в залежності від того, що зручніше в окремому випадку. Взагалі, якщо вираз містить метасимволи Shell, легше передати його як один аргумент, взятий у лапки.

Приклади

Надрукувати всі пакети, що надходять на або відправляються з хоста sundown:

tcpdump host sundown

Роздрукувати трафік між helios та або hot, або ace:

tcpdump host helios and \( hot or ace \)

Надрукувати всі IP-пакети між ace і будь-яким хостом, крім helios:

tcpdump ip host ace and not helios

Роздрукувати весь трафік між локальними хостами і хостами у Берклі:

tcpdump net ucb-ether

Роздрукувати весь FTP трафік через Internet-шлюз snup (зверніть увагу, що вираз взятий у лапки, щоби не дати shell неправильно інтерпретувати дужки):

tcpdump 'gateway snup and (port ftp or ftp-data)'

Роздрукувати трафік, що не має джерелом, і не має призначенням локальні хости (якщо ви маєте шлюз до однієї іншої мережі, такий трафік не повинен з’являтись у вашій локальній мережі):

tcpdump ip and not net localnet

Надрукувати початкові і кінцеві (тобто SYN і FIN) пакети кожної сесії TCP, що включає нелокальний хост:

tcpdump 'tcp[13] & 3 != 0 and not src and dst net localnet'

Надрукувати IP-пакети, довші за 576 байт, що пересилаються через шлюз snup:

tcpdump 'gateway snup and ip[2:2] > 576'

Роздрукувати циркулярні або групові IP-пакети, які не були розіслані через циркулярну або групову розсилку Ethernet:

tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'

Роздрукувати всі ICMP-пакети, які не є запитами/відповідями echo (тобто, не ping-пакети):

tcpdump 'icmp[0] != 8 and icmp[0] != 0'

Формат виводу

Формат виводу tcpdump залежить від протоколу. Далі наведно короткий опис і приклади основних форматів.

Заголовки канального рівня

Заголовок канального рівня роздруковується, якщо задана опція “-e”.

Для мереж Ethernet друкуються адреси джерела й призначення, протокол і довжина пакета.

Для мереж FDDI опція “-e” примушує tcpdump друкувати поле “frame control”, адреси джерела й призначення і довжину пакета. Поле “frame control” контролює подальшу інтерпретацію пакета. Звичайні пакети (як ті, що містять IP-дейтаграми) є “async”-пакетами з величиною пріоритета між 0 і 7; наприклад, “async4”. Вважається, що такі пакети містять кадр 802.2 LLC; заголовок LLC друкується, якщо це не ISO-дейтаграма або так званий SNAP-пакет.

Для мереж Token Ring опція “-e” примушує tcpdump друкувати поля “access control” і“frame control”, адреси джерела й призначення і довжину пакета. Як і для мереж FDDI, вважається, що пакети містять кадр 802.2 LLC. Незалежно від того, чи була задана опція “e”, для пакетів з маршрутизацією від джерела друкується маршрутна інформація.

Пакети ARP/RARP

Вивід для ARP/RARP показує тип запиту і його аргументи. Формат є інтуітивно зрозумілим. Далі наведено короткий приклад, що демонструє початок сесії “rlogin” з хоста rtsg до хоста csam:

arp who-has csam tell rtsg

arp reply csam is-at CSAM

Перший рядок показує, що rtsg відправив ARP-пакет із запитом про Ethernet-адресу хоста csam.  csam у відповідь надсилає свою Ethernet-адресу (що в цьому прикладі показана великими літерами, на відміну від Internet-адрес).

Якщо ми використали tcpdump -n, вивід буде виглядати таким:

arp who-has 128.3.254.6 tell 128.3.254.68

arp reply 128.3.254.6 is-at 02:07:01:00:01:c4

Якщо ми використали tcpdump -e, буде видимим той факт, що перший пакет є циркулярним, а другий – точка-точка:

RTSG Broadcast 0806 64: arp who-has csam tell rtsg

CSAM RTSG 0806 64: arp reply csam is-at CSAM

Для першого пакета це означає, що Ethernet-адреса джерела є RTSG, призначення – циркулярна адреса Ethernet, поле TYPE містить шістнадцяткове значення 0806 (тип пакета – ETHER_ARP), а повна довжина – 64 байта.

Пакети TCP

(N.B.: Наступний опис передбачає знайомство читача з протоколом TCP, що описаний в RFC-793. Якщо ви не знайомі з цим протоколом, ні цей опис, ні взагалі tcpdump не будуть вам корисні.)

Загальний формат рядка виводу для протоколу TCP має вигляд:

src > dst: flags data-seqno ack ack-seqno win window urg options

src і dst – це IP-адреси і порти джерела і призначення, відповідно.

flags – деяка комбінація S (SYN), F (FIN), P (PUSH) та R (RST), або одна “.” (немає прапорців).

dataseqno описує частку послідовності, що займають дані в цьому пакеті (див. приклад далі).

ackseqno – це номер послідовності наступних даних, що очікуються в протилежному напрямі цього з’єднання.

window – це кількість байт, що доступні в приймальному буфері в протилежному напрямі цього з’єднання.

urg вказує на “термінові” (urgent) дані в пакеті.

options – це опції TCP, що взяті в кутові дужки (наприклад, <mss 1024>).

src, dst і flags присутні завжди. Інші поля залежать від вмісту заголовку протокола TCP в пакеті, і виводяться лише коли це можливо.

Далі наведено початок сесії rlogin з хоста rtsg до хоста csam:

rtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024>

csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024>

rtsg.1023 > csam.login: . ack 1 win 4096

rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096

csam.login > rtsg.1023: . ack 2 win 4096

rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096

csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077

csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1

csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1

Перший рядок показує, що TCP-порт 1023 хоста rtsg відправив пакет на порт login хоста csam. S вказує, що встановлено прапорець SYN. Номер послідовності пакета був 768512, пакет не містив даних. (Нотація: first:last(nbytes) означає:номери послідовності, починаючи з first і до, але не включаючи, last, що складає nbytes байт даних користувача”.) Зворотного ACK не було, доступне вікно для прийому складало 4096 байт, встановлено опцію максимального розміру сегмента (max-segment-size), що вимагає mss в 1024 байт.

csam відповідає аналогічним пакетом, за виключенням того, що він включає зворотний ACK на запит SYN хоста rtsg. Потім rtsg підтверджує SYN хоста csam своїм ACK. Знак .означає, що прапорці не встановлені. Пакет не містив даних, тому немає номера послідовності даних.

Зверніть увагу, що номер послідовності підтвердження ACK є малим цілим числом (1). Коли tcpdump вперше бачить діалог узгодження TCP, він друкує номер послідовності з пакета. В наступних пакетах він друкує різницю між номером послідовності чергового пакета і початковим номером послідовності. Це означає, що номера послідовності після першого можуть інтерпретуватись як відносні положенння байт в потоці даних цієї сесії (де нумерація першого байту даних в кожному напрямі починається з “1”). Опція командного рядка tcpdump-Sвідмінить це правило, в результаті будуть друкуватись абсолютні номера послідовностей.

У 6-му рядку rtsg пересилає хосту csam 19 байт даних (байти від 2 до 20 в напрямку rtsg -> csam цієї сесії). В пакеті встановлено прапорець PUSH, що вимагає першочергової передачі пакета застосуванню, яке його очікує. У 7-му рядку csam підтверджує, що він отримав дані, відправлені хостом rtsg до байта номер 21 (за виключенням цього останнього номера). Більшість цих даних, вочевидь, знаходиться в буфері сокета, оскільки приймальне вікно хоста csam стало на 19 байт менше. Також в цьому пакеті csam посилає один байт даних хосту rtsg. В 8-му і 9-му рядках, csam відправляє хосту rtsg два байта термінових (urg) даних з встановленим прапорцем PUSH.

Якщо поле захоплення (snaplen) було настільки малим, що tcpdump захопив неповний заголовок TCP, він інтерпретує максимальну частину заголовка, яка піддається інтерпретації, а далі повідомляє [|tcp], що означає, що решта заголовку не може бути проінтерпретована. Якщо заголовок містить помилкову опцію (таку, довжина якої або занадто мала, або виходить за межі заголовка), tcpdump повідомляє “[bad opt]” і не інтерпретує жодної наступної опції (оскільки неможливо визначити, де вони розпочинаються). Якщо довжина заголовка вказує на те, що присутні опції, але довжина IP-дейтаграми недостатня для того, щоб опції насправді були присутні, tcpdump повідомляє про це “[bad hdr length]”.

Якщо потрібно захопити деякі з TCP-пакетів за їх ознаками (наприклад, всі початкові пакети сесій, які мають встановлений прапорець SYN і не встановлений прапорець ACK), слід побудувати правильний фільтруючий вираз. Ознаки пакетів передаються за допомогою 6 бітів-прапорців:

URG | ACK | PSH | RST | SYN | FIN,

що знаходяться в 13-му (нумерація починається з нуля) байті (октеті) заголовка TCP-пакета (тут є сенс пригадати формат заголовка):

0                             15                              31

----------------------------------------------------------------

|         source port          |        destination port       |

----------------------------------------------------------------

|                       sequence number                        |

----------------------------------------------------------------

|                    acknowledgment number                     |

----------------------------------------------------------------

|  HL   | reserved |U|A|P|R|S|F|          window size          |

----------------------------------------------------------------

|         TCP checksum         |         urgent pointer        |

----------------------------------------------------------------

Октет №13 має такий вигляд:

|7 6 5 4 3 2 1 0|

|---------------|

|   |U|A|P|R|S|F|

|---------------|

2 старших біти в цьому октеті відносяться до зарезервованого поля, й у відповідності до RFC 793 мають дорівнювати нулю. Інші 6 біт – ознаки TCP-пакета, саме які нас цікавлять. Ми хочемо захопити пакети з єдиною встановленою ознакою SYN, в такому разі октет 13 заголовка TCP буде мати вигляд 00000010 у бінарному форматі, або 2 у десятковому. Це можна задати таким примітивом: tcp[13] == 2. Тоді командний рядок для захоплення всіх TCP-пакетів, в яких встановлено єдиний прапорець SYN, може мати вигляд:

tcpdump -i xl0 tcp[13] == 2

Якщо нам потрібно захопити пакети, в яких встановлено прапорець SYN, незалежно від того, які значення мають інші прапорці, нам потрібно виділити прапорець SYN за допомогою логічного AND. Відповідний командний рядок матиме такий вигляд:

tcpdump -i xl0 'tcp[13] & 2 == 2'

Зверніть увагу, що у фільтруючому виразі необхідно застосувати одиночні лапки або зворотну косу рису (backslash), щоби сховати спеціальний символ AND (“&”) від командної оболонки shell.

Пакети UDP

Формат виводу UDP проілюстровано таким пакетом rwho:

actinide.who > broadcast.who: udp 84

Тут показано, що порт who хоста actinide відправив UDP-дейтаграму на порт who хоста broadcast, тобто на циркулярну Internet-адресу. Пакет містив 84 байта користувацьких даних.

Деякі сервіси UDP розпізнаються за номерами портів джерела або призначення, і виводиться інформація протоколу вищого рівня. Зокрема, запити служби доменних імен (RFC-1034/1035) і виклики Sun RPC до NFS (RFC-1050).

UDP-запити і відповіді до серверу імен 

(N.B.: Наступний опис передбачає знайомство читача з протоколом служби доменних імен DNS, що описаний в RFC-1035. Якщо ви не знайомі з цим протоколом, наступний опис буде здаватись вам написаним китайською мовою.)

Запити до серверу імен форматуються таким чином:

src > dst: id op? flags qtype qclass name (len)

Приклад:

h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)

Хост h2opolo запросив у сервера домену на хості helios запис адреси (qtype = A), що асоційована з іменем ucbvax.berkeley.edu. Ідентифікатор запиту був “3”. Знак “+” показує, що був встановлений прапорець recursion desired. Довжина запиту складала 37 байт, не враховуючи заголовки протоколів UDP і IP. Операція запиту була звичайна, query, тому поле op пропущене. Якби операція була б якоюсь іншою, op було б надруковане між “3” і “+”. Аналогічно, qclass був звичайним, C_IN, і тому пропущений. Будь-який інший qclass був би надрукований безпосередньо після “A”.

Кілька аномалій перевіряються і можуть спричинити додаткові поля, що заключаються в квадратні дужки. Якщо запит містить розділ відповіді, сервера імен або повноважень, ancount, nscount або arcount друкуються у вигляді “[na]”, “[nn]” або “[nau]”, відповідно, де n – відповідна кількість. Якщо встановлено будь-який з бітів відповіді (AA, RA або rcode), або встановлено будь-який з бітів “must be zero” в байтах №2 і 3, друкується “[b2&3=x]”, де x – шістнадцяткове значення байтів 2 і 3 заголовка.

Відповіді серверу імен форматуються таким чином:

src > dst: id op rcode flags a/n/au type class data (len)

Приклади:

helios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273)

helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)

У першому прикладі, helios відповідає на запит з ідентифікатором 3 хоста h2opolo 3-ма записами відповіді, 3-ма записами серверу імен і 7-ма записами повноважень. Перший запис відповіді має тип A (адреса), і його дані – Internet-адреса 128.32.137.3. Повна довжина відповіді була 273 байта, не враховуючи заголовки протоколів UDP і IP. op (Query) і код відповіді (NoError) були пропущені, так само, як і клас (C_IN) запису A.

У другому прикладі helios відповідає на запит 2 про неіснуючий домен (NXDomain) без записів відповіді, одним сервером імен і без записів повноважень. “*” показує, що біт authoritative answer (авторитетна відповідь) було встановлено. Оскільки відповідей нема, жодних даних type, class або data не надруковано.

Інші символи, що представляють флаги, це “-” (доступна рекурсія, recursion available, RA, не встановлено) і “|” (обрізане повідомлення, truncated message, TC, встановлено). Якщо розділ питання (question) не містить рівно одного запису, друкується “[nq]”.

Зверніть увагу, що запити і відповіді серверів імен мають властивість бути великими, і snaplen в 68 байт за замовчанням може не захопити достатню частину пакета для інтерпретації і роздрукування. Використовуйте флаг -s для збільшення захоплюваної частини пакета, якщо вам потрібно серйозно дослідити трафік серверу імен. Добре спрацьовує -s 128”.

Декодування SMB/CIFS

tcpdump включає досить потужне декодування SMB/CIFS/NBT-даних на портах UDP/137, UDP/138 і TCP/139. Також робиться деяке примітивне декодування IPX і NetBEUI SMB. 

По замовчанню робиться мінімальне декодування, але при використанні опції -v декодування значно більш детальне. Майте на увазі, що з використанням -v єдиний SMB-пакет може зайняти сторінку або більше, тому використовуйте цю опцію, лише якщо вам дійсно потрібні всі деталі.

При декодування SMB-сесій, що містять рядки UNICODE, може бути необхідним встановити змінну оточення USE_UNICODE в 1.

Інформацію про формати SMB-пакетів і що означають всі поля можна знайти на www.cifs.org, або подивитись каталог pub/samba/specs/ на вашому улюбленому сайті-дзеркалі samba.org.

Запити і відповіді NFS

Запити і відповіді Sun NFS (Network File System) виводяться в такому вигляді:

src.xid > dst.nfs: len op args

src.nfs > dst.xid: reply stat len op results

Приклад:

sushi.6709 > wrl.nfs: 112 readlink fh 21,24/10.73165

wrl.nfs > sushi.6709: reply ok 40 readlink "../var"

sushi.201b > wrl.nfs: 144 lookup fh 9,74/4096.6878 "xcolors"

wrl.nfs > sushi.201b: reply ok 128 lookup fh 9,74/4134.3150

В першому рядку хост sushi відправляє транзакцію з id 6709 до хоста wrl (зверніть увагу, що номер, що слідує за src – хостом-джерелом, є ідентифікатором транзакції, а не портом джерела). Запит мав довжину 112 байт, не враховуюси заголовки UDP і IP. Операція, що була потрібна, – це readlink (прочитати символічне посилання) за системним номером файла (fh file handle) 21,24/10.731657119. (Якщо пощастить, як у цьому випадку, системний номер файла можна проінтерпретувати: пара номерів пристрою – major,minor, – за якими слідує індекс – inode number – і номер генерації.)

wrl відповідає “ok” і надсилає вміст посилання.

У третьому рядку, sushi просить wrl переглянути ім’яxcolorsв файлі-каталозі 9,74/4096.6878. Зверніть увагу, що дані, що друкуються, залежать від типу операції. Формат розроблено з урахуванням інтуітивної зрозумілості, якщо переглядати вихідні дані разом із специфікацією протокола NFS.

Якщо задана опція -v, друкується додаткова інформація. Наприклад:

sushi.1372a > wrl.nfs: 148 read fh 21,11/12.195 8192 bytes @ 24576

wrl.nfs > sushi.1372a: reply ok 1472 read REG 100664 ids 417/0 sz 29388

У третьому рядку, sushi просить wrl переглянути ім’яxcolorsв файлі-каталозі 9,74/4096.6878. Зверніть увагу, що дані, що друкуються, залежать від типу операції. Формат розроблено з урахуванням інтуітивної зрозумілості, якщо переглядати вихідні дані разом із специфікацією протокола NFS.

Якщо задана опція -v, друкується додаткова інформація. Наприклад:

sushi.1372a > wrl.nfs: 148 read fh 21,11/12.195 8192 bytes @ 24576

wrl.nfs > sushi.1372a: reply ok 1472 read REG 100664 ids 417/0 sz 29388

-v також друкує поля із заголовку IP: TTL, ID, довжину і фрагментацію, які в цьому прикладі пропущені. В першому рядку, sushi просить wrl прочитати 8192 байт з файлу 21,11/12.195, починаючи з байту 24576. wrl відповідає “ok”; пакет, показаний на другому рядку, є першим фрагментом відповіді, і має довжину 1472 байт. Наступні байти будуть в наступних фрагментах, але вони передаються в IP-пакетах, що не містять заголовків NFS і навіть UDP, і тому можуть бути не роздруковані, залежно від заданого фільтруючого виразу. Оскільки задано флаг v, друкуються деякі атрибути файлу, що вертаються на додаток до даних файлу: тип файлу (“REG”, для звичайного файлу), атрибути доступу (у вісімковій нотації), UID, GID і розмір файлу.

Якщо опція -v задана в командному рядку більше одного разу, друкується ще більше подробиць.

Зверніть увагу, що запити NFS дуже об’ємні і більшість подробиць не буде надрукована, якщо не збільшити snaplen. Для аналізу трафіка NFS рекомендується -s 192”.

Пакети-відповіді NFS не ідентифікують операцію RPC, тобто з самого пакета не можна визначити, відповіддю на який тип запиту він є. Для цього tcpdump зберігає записи про “нещодавні” запити, і зіставляє їх з відповідями за ідентифікатором транзакції. Якщо відповідь не досить швидко іде за відповідним запитом, її може бути неможливо проаналізувати.

IP-фрагментація

Фрагментовані IP-дейтаграми друкуються в такому вигляді:

(frag id:size@offset+)

(frag id:size@offset)

Перша форма вказує, що далі будуть ще фрагменти. Друга вказує, що це – останній фрагмент. id – це ідентифікатор фрагмента. size – розмір фрагмента (в байтах), за виключенням IP-заголовка. offset – зміщення цього фрагмента в дейтаграмі (в байтах).

Інформація про фрагмент виводиться для кожного фрагмента. Перший фрагмент містить заголовок протоколу вищого рівня, і інформація про фрагмент друкується після інформації про протокол. Наступні фрагменти не містять заголовку протоколу вищого рівня, і інформація про фрагмент друкується після адрес джерела і призначення. Наприклад, далі наведено частину FTP з arizona.edu до lbl-rtsg.arpa через з’єднання CSNET, що не підтримує 576-байтні дейтаграми:

arizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096 (frag 595a:328@0+)

arizona > rtsg: (frag 595a:204@328)

rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560

Тут є пара важливих моментів, на які варто звернути увагу. По-перше, адреси у 2-му рядку не містять номерів портів. Це тому, що вся інформація протоколу TCP знаходиться у першому фрагменті, і при аналізі наступних фрагментів немає інформації про порти і номери послідовності. По-друге, інформація про TCP-послідовність в першому рядку вказує на те, що є 308 байт користувацьких даних, коли насправді їх 512 (308 у першому фрагменті і 204 – в другому). Якщо ви шукаєте проміжки в послідовності, або намагаєтесь зіставити підтвердження (ACK) з пакетами, це може вас заплутати.

Пакет з IP-прапорцем don't fragment позначається завершальним (DF).

Позначки часу

За замовчанням, кожному рядку виводу передує позначка часу, яка показує поточний час у формі

hh:mm:ss.frac

і є точною настільки, наскільки точним є годинник ядра. Відмітка показує момент, коли ядро вперше побачило пакет. Затримка часу між тим, коли Ethernet-інтерфейс одержав пакет з лінії зв’язку і коли ядро обробило переривання “new packet”, не враховується.

Додаток 2. Використання програми Nmap

Nmap призначений для того, щоби дозволити системним адміністраторам і зацікавленим індивідуумам (саме так висловився автор) сканувати великі мережі для визначення, які хости включені і які сервіси вони пропонують. Nmap підтримує велику кількість методів сканування, такі як: UDP, TCP connect(), TCP SYN (half open), ftp proxy (bounce attack), Reverse-ident, ICMP (ping sweep), FIN, ACK sweep, Xmas Tree, SYN sweep, IP Protocol, а також Null scan. Подробиці див. у розділі Методи сканування. Nmap також пропонує безліч розширених можливостей на кшталт віддаленого визначення OС шляхом “дактілоскопічного” аналізу TCP/IP, приховане сканування, динамічні обчислення затримки і пересилання, паралельне сканування, виявлення відключених хостів шляхом паралельного пінгування, сканування “принади”, виявлення фільтрації портів, пряме (не portmapper) сканування RPC, сканування фрагментації, а також гнучка специфікація цілі і порта.

Суттєві зусилля автора були спрямовані на те, щоби надати можливість використовувати Nmap звичайним користувачам (non-root). Але багато з критичних інтерфейсів ядра (як, наприклад, raw sockets) неодмінно вимагають привілей суперкористувача. Nmap має запускатись від імені суперкористувача коли це тільки можливо.

Результат використання Nmap – це, як правило, список цікавлячих портів (якщо такі є) на машині (машинах), що їх сканують. Nmap завжди наводить для порта відоме ("well known") ім’я служби (якщо таке є), номер, стан і протокол. Стан може бути 'open' (відкритий), 'filtered' (фільтрований) або 'unfiltered' (нефільтрований). “Відкритий” означає, що машина буде дозволяти з’єднання на цьому порту. “Фільтрований” означає, що брандмауер, фільтр або інша мережева перешкода закриває порт і не дає Nmap визначити, чи відкритий цей порт. “Нефільтрований” означає, що для Nmap порт виглядає закритим, і немає ознак того, що будь-який брандмауер/фільтр впливає на спроби Nmap визначити це. Нефільтровані порти є звичайним випадком (на будь-якому нормальному хості і навіть сервері їх має бути переважна більшість) і їх показують лише у випадках, коли більшість сканованих портів – фільтровані.

В залежності від використаних опцій, Nmap може також повідомити такі характеристики віддаленного хоста: використовувана ОС, передбачуваність номеру послідовності TCP, від імені яких користувачів виконуються програми, що пов’язані з кожним портом, DNS-ім’я і деякі інші.

Формат команди

nmap [Scan Type(s)] [Options] <host or net #1 ... [#N]>

Scan Type(s) – Типи сканування

-sT Сканування “TCP connect()”.

-sS  Сканування “TCP SYN”

-sF  Сканування “Stealth FIN”

-sX  Сканування “Xmas Tree”

-sN  Сканування “Null scan”

-sP  Ping-сканування.

За замовчанням (для суперкористувачів), Nmap використовує і ICMP, і ACK-методи паралельно. Вы можете заміняти метод ping-сканування (пінгування) за допомогою опції -P, що описана далі.

Зверніть увагу, що пінгування за замовчанням робиться завжди, і лише хости, що відповідають, скануються далі. Використовуйте цю опцію, якщо ви бажаєте лише пропінгувати без будь-якого сканування портів.

-sU  UDP-сканування.

-sO  Сканування IP-протоколів.

-sI <zombie host[:probeport]> 

Idlescan (використання хоста-“зомбі”).

probeport – це конкретний порт хоста-зомбі для змін IPID. Якщо його не вказано, Nmap буде використовувати порт, що він використовує за замовчанням для "TCP-пінгування".

-sA  ACK-сканування.

-sW  Віконне сканування.

-sR  RPC-сканування.

В поточній версії принади (decoys) не працюють з RPC-скануванням.

-sL  Список. Цей метод просто генерує і друкує список IP адрес/Імен хостів без фактичного пінгування або сканування їхніх портів. Визначення імен DNS буде виконуватись, якщо не буде задано опцію -n.

-b <ftp relay host>

Атака “FTP bounce”.

Параметр, що передається до опції 'b' – це хост, який ви бажаєте використати в якості proxy, в стандартній нотації URL. Формат: username:password@server:port. Все, крім server, опціональне. Щоби визначити, які сервери є вразливими до цієї атаки, можна переглянути статтю в Phrack 51. Модифікована версія Nmap доступна за URL http://www.insecure.org/nmap.

Опції

Опції, які мають сенс разом, як правило, можуть поєднуватись. Деякі опції специфічні для визначених режимів роботи. Nmap намагається виявити і попередити користувача про ненормальні (“psychotic”) або непідтримувані комбінації опцій.

В розділі Приклади сторінки man nmap продемонстровані типові випадки використання. Також можна дати команду nmap -h для одержання довідкової стрінки, де названі всі опції.

Додаток 3. Сканер безпеки XSpider

Короткі відомості про програму

XSpider – програмний засіб мережевого аудиту, призначений для віддаленої діагностики різних елементів мережі щодо пошуку вразливостей.

Деякими з відрізняючих особливостей XSpider-a є:

  •  численні ноу-хау, що використовуються для пошуку вразливостей,
  •  інтелектуальний підхід до розпізнання сервісів,
  •  унікальна обробка RPC-сервісів всіх стандартів з їх повною ідентифікацією,
  •  аналізатор структури і метод інтелектуального розпізнання вразливостей веб-серверів,
  •  постійне оновлення,
  •  підтримка кількох мов інтерфейсу.

Крім сканера безпеки, XSpider містить в собі додаткові утіліти:

  •  прості сканери (TCP й UDP портів),
  •  CGI-сканер с Brute-словником,
  •  визначник вихідного трафіку на віддаленому комп’ютері,
  •  WhoIs сервіс,
  •  перевірка анонімності проксі-серверу,
  •  TCP й UDP клієнти,
  •  TCP-проксі (дозволяє пропускати TCP пакети через себе, з можливістю їх корекції),
  •  робота з поштою, видалення непотрібної пошти з серверу,
  •  локальні налаштовування безпеки комп’ютера.

Підтримувані операційні системи:

Windows 95, 98, Millenium, NT, 2000, XP.

Цей програмний продукт характеризується дуже зручним і інтуїтивно зрозумілим інтерфейсом. Крім сканування мереж, програмний продукт містить велику кількість функцій по роботі і тестуванню окремих мережевих сервісів. Якщо обрано сканування – над основним вікном програми можна задати одну або кілька цілей. Межі активності сканера задаються окремо для різних мережевих протоколів – TCP, UDP, HTTP, SMTP, тощо. Слід звернути увагу, що можна активізувати або відключити фактичні спроби атак на систему, що перевіряється. Після старту сканування стан процесу відображається у рядку стану внизу вікна програми, одночасно йде формування звіту. Звіт досить детальний і містить не лише зафіксовані результати, але й рекомендації по підвищенню захищеності системи. Для своєї роботи XSpider не вимагає привілеїв адміністратора.

Інтерфейс користувача 

Зліва знаходиться колонка з піктограмами, яка дозволяє вибрати основну задачу програми. При виборі піктограми основне вікно змінюється відповідно до обраної задачі. Над основним вікном задаються основні параметри задачі (наприклад, ІР адреси). Для детального налаштовування сканера слід викликати вікно настроювань. Розглянемо основні задачі і опції, що можна для них настроювати (мова інтерфейсу – російська).

“Сканеры

Включає сканер безпеки і простий сканер портів. Сканер безпеки шукає на віддаленому комп’ютері сервіси, що вказані в файлі extServ.xsp, і намагається їх ідентифікувати. Кожний сервіс перевіряється на різні вразливості. Ступінь небезпеки тієї чи іншої вразливості відображається різними кольорами від зеленого до червоного. Легенду виводу даних можна переглянути, активізувавши посилання Легенда.

  •  Простой поиск – здійснює лише запит на DNS-сервер і пінг. Решта сервісів ігноруються, навіть якщо вони включені в налаштовуваннях аудиту, за виключенням “Определение удаленного трафика”.
  •  Всплывающее окно – після закінчення перевірки буде показано вікно з зазначенням кількості знайдених вразливостей.
  •  Настройки – дозволяють налаштовувати сканер безпеки на аудит визначених сервісів і змінювати параметри пошуку.
  •  Полное сканирование сервисов – перед початком роботи сканера безпеки здійснюється сканування портів комп’ютера за списком сервісів, указаних у файлі extServ.xsp.
  •  Скорость сканирования – на модемних з’єднаннях і при поганому зв’язку не рекомендується використовувати більше 50 потоків.
  •  HTTP не определять веб-сервер – відключає автоматичне визначення веб-сервера, при цьому здійснюється пошук по всій базі експлойтів незалежно від веб-сервера.
  •  Использовать имя домена – якщо ім’я домену не вдалося визначити автоматично, то дані для перевірок беруться з цього поля.
  •  Тайм-аут при проверке TCP – за замовчанням стоїть 15 секунд. На модемних з’єднаннях рекомендується збільшити це значення до 30.
  •  Тайм-аут при проверке UDP – за замовчанням стоїть 5 секунд. На модемних з’єднаннях рекомендується збільшити це значення до 15.
  •  Определение удаленного трафика – при завданні цієї опції відбувається спроба визначити вихідний трафік на віддаленому комп’ютері. Це працює в 60-70% випадків згідно RFC 791. Якщо трафік не визначається або він занадто малий (1-2 пакета), то, скоріше за все, визначити його не вдалося.

Час повної перевірки елементу мережі на безпеку може становити від 5 хвилин до півгодини в залежності від кількості запущених сервісів і складності їх ідентифікації.

Увага!!! Перевірки, що позначені жовтим кольором, є перевірками на DOS-атаки (відмова в обслуговуванні), і можуть призвести до зупинки деяких сервісів або до повного перезавантаження об’єкта, який перевіряють.

“CGI”

Включає сканер веб-серверів, який здійснює сканування віддаленого веб-сервера на предмет наявності вразливих скриптів. Містить базу відомих скриптів і Brute словник, які можна змінити через вкладинки “Cловарь” і “Файл”.

  •  Сканировать через прокси – дозволяє сканувати через анонімний проксі-сервер.
  •  Включать в заголовок Referer – дозволяє включати в запит до сервера поле Refer, яке показує, звідки прийшов запит на веб-сервер.
  •  Маскировать от IDS – маскувати запити до сервера, щоби сканування неможливо було виявити за допомогою СВА.


“Поиск”

Включає пошук визначеного сервісу або робочих комп’ютерів в межах однієї підмережі. В полі “Порт” вводиться номер порту, в полі “Тайм-аут” – час очікування при пошуку сервісу. Обирається або пошук сервіса, або простий пінг.

“WhoIs”

Включає сервіс WhoIs, який дає можливість визначення повної інформації про IP-адресу (країна, місто, провайдер і його адреса і контактні телефони). При введенні в поле адреси скороченої назви країни і натисканні кнопки “Поиск”, вертається повна назва країни. Наприклад, RU – ‘Russia’.

“Прокси”

Включає визначник анонімності у проксі-сервера. В полі “Адрес компьютера, на который посылается запрос через прокси” повинна бути IP-адреса свого комп’ютера, щоби можна було отримати відповідь, що пройшла через проксі-сервер. Своя IP-адреса визначається автоматично, але все одно існує ймовірність, що її доведеться поміняти (за ситуацією).

“TCP”, “TCP-прокси”, “UDP и IP”

Включають зручні сервіси, за допомогою яких можна: відправляти та приймати TCP і UDP пакети, додавати TCP пакети в існуючі з’єднання, прослуховувати IP й ICMP пакети, що надходять.

Докладнішу інформацію можна отримати з документації XSpider, а також з веб-сайту розробників: http://www.xspider.ru, http://www.xspider.net.ru.

Додаток 4. Як використовувати програму Snort

Вступ

Snort не дуже складно використовувати, але існують численні опції командного рядка, з якими можна «погратись», і не завжди видно, які з них добре сполучуються. Цей документ призначений для полегшення використання Snort для нових користувачів.

Режими роботи Snort

Перш, ніж іти далі, з’ясуємо декілька базових концепцій Snort. Є три головних режиму, в яких може діяти Snort: sniffer (прослуховувач трафіку), реєстратор пакетів, і мережева система виявлення атак. Режим sniffer просто читає пакети з мережі й відображає їх для користувача в безперервному потоці на консолі (моніторі). Режим реєстратора пакетів реєструє пакети на диск. Мережевий режим виявлення атак – найскладніша конфігурація, яка дозволяє Snort аналізувати мережевий трафік на співпадіння з визначеним користувачем набором правил і виконувати деякі дії на основі того, що було виявлено.

Режим sniffer 

Почнемо з основ. Якщо ви бажаєте лише вивести на екран TCP/IP заголовки пакетів (тобто режим sniffer), спробуйте таку команду:

./snort -v

(Тут і далі ми вважаємо, що перед цим ви перейшли до каталогу, в якому встановлено Snort). Ця команда запустить Snort і буде показувати лише IP і TCP/UDP/ICMP заголовки, більше нічого. Якщо ви бажаєте бачити також дані вмісту пакетів (корисного навантаження), спробуйте таке:

./snort -vd

Це змушує Snort відображати дані пакету разом із заголовками. Якщо ви бажаєте ще більш змістовне відображення, що показує також заголовки канального рівня, зробіть так:

./snort -vde

(Параметри командного рядка можуть бути розділені або об’єднані разом у будь-якій комбінації. Остання команда могла також бути надрукована як:

./snort -d -v –e,

і це працювало б точно так само).

Режим реєстратора пакетів

Якщо ви бажаєте здійснювати запис пакетів на диск, ви маєте призначити каталог для реєстрації, і Snort автоматично дізнається, що треба увійти в режим реєстратора пакетів:

./snort -dev -l ./log

Звичайно, це припускає, що у вас на диску в поточному робочому каталозі вже є підкаталог із назвою “log”. Якщо це не так, Snort завершиться з повідомленням про помилку. Коли Snort працює в цьому режимі, він збирає кожний пакет, який він бачить, і поміщає його в ієрархії каталогів, що базується на IP адресі одного з хостів у дейтаграмі. Якщо ви задаєте лише параметр “-l”, то Snort для визначення каталогу, в який він розміщає пакети, іноді використовує адресу віддаленого комп’ютера, а іноді локальну мережеву адресу. Щоби реєструвати відносно домашньої мережі, ви маєте повідомити Snort, яка мережа є домашньою:

./snort -dev -l ./log -h 192.168.1.0/24

Це правило інформує Snort, що ви бажаєте роздруковувати заголовки канального рівня і TCP/IP, а також і прикладні дані в каталог ./log, і ви бажаєте реєструвати пакети відносно мережі класу C 192.168.1.0. Всі пакети, що надходять, будуть занесені в підкаталоги реєстраційного каталогу з іменами, що основані на адресі віддаленого (не 192.168.1.х) хоста. Зверніть увагу, що якщо обидва хоста знаходяться в домашній мережі, то вони реєструються на основі більшого з двох номерів портів, або вихідної адреси.

Якщо ви знаходитесь у високошвидкісній мережі, або ви бажаєте реєструвати пакети в більш компактній формі для подальшого аналізу, вам слід подумати про реєстрацію в “бінарному режимі”. Бінарний режим реєструє пакети у “форматі tcpdump” в один бінарний файл в каталозі реєстрації:

./snort -l ./log -b

Зверніть увагу на зміни у командному рядку. Ми більше не повинні призначати домашню мережу, тому що бінарний режим реєструє все в один файл, який усуває необхідність указувати, як форматувати структуру каталогу виводу. Крім того, ви не повинні запускати «детальний» (verbose) режим або задавати параметри -d чи -e, оскільки в бінарному режимі реєструється повний пакет, а не лише частини його. Все, що дійсно потрібно, щоби перевести Snort в режим реєстратора – це призначення каталогу реєстрації в командному рядку з параметром -l, ключ бінарної реєстрації -b просто забезпечує модифікатор, щоби вказати йому реєструвати пакети в іншому форматі, відмінному від призначеного за замовчанням вихідного формату простого тексту ASCII.

Якщо пакети були зареєстровані в бінарному файлі, ви можете прочитати пакети з файлу будь-яким sniffer’ом, що підтримує бінарний формат tcpdump, таким як власне tcpdump або Ethereal. Snort також може читати пакети з файлу, використовуючи параметр -r, який переводить його в режим відтворення. Пакети з будь-якого файлу формату tcpdump можуть бути оброблені Snort в кожному з його режимів виконання. Наприклад, якщо ви хотіли пропустити бінарний журнал через Snort в режимі sniffer, щоби вивести пакети на екран, ви можете спробувати щось на кшталт цього:

./snort -dv -r packet.log

Ви можете керувати даними в файлі кількома способами – через реєстрацію пакетів Snort і режими виявлення вторгнень, а також з інтерфейсом BPF, який доступний з командного рядка. Наприклад, якщо ви лише хотіли переглянути ICMP пакети з журналу реєстрації, просто задайте фільтр BPF в командному рядку, і Snort буде “бачити” лише ICMP пакети в файлі:

./snort -dvr packet.log icmp

Для інформації про те, як використовувати інтерфейс BPF, читайте сторінку керівництва man.

Мережевий режим виявлення вторгнень

Щоби запустити мережевий режим (NIDS) виявлення вторгнень (так, щоби ви не робили запис кожного одиночного пакету, що посланий по мережі), спробуйте таке:

./snort -dev -l ./log -h 192.168.1.0/24 -c snort.conf

де snort.conf – ім’я вашого файлу правил. Цей командний рядок застосує набір правил, що міститься у файлі snort.conf до кожного пакету, щоби вирішити, чи повинна виконуватись дія, що заснована на типі правила у файлі. Якщо ви не призначаєте каталог виводу для програми, за замовчанням буде використано значення /var/log/snort.

Одна річ, на яку слід звернути увагу стосовно останнього командного рядка, полягає в тому, що якщо Snort збираються використовувати тривалий час в якості IDS, параметр “-v” повинен бути виключеним з командного рядка заради швидкості. Екран – повільне місце для запису даних, і пакети можуть бути відкинуті в процесі запису на дисплей.

Також не обов’язково робити запис заголовків канального рівня для більшості застосувань, так що не слід також задавати параметр -e.

./snort -d -h 192.168.1.0/24 -l ./log -c snort.conf

Цей командний рядок налаштовує Snort, щоби останній виконувався в його основній формі NIDS, реєструючи ті пакети, про які повідомляють йому правила, в простому форматі ASCII в ієрархічній структурі каталогів (точно так, як в режимі реєстратора пакетів).

Опції виводу режиму NIDS

Існує безліч способів задавати конфігурацію виводу Snort в режимі NIDS. За замовчанням, механізми реєстрації й сигналізації повинні вести реєстрацію в декодованому форматі ASCII і використовувати “повні” попередження. Повний сигнальний (alert) механізм виводить сигнальне повідомлення в доповнення до повних заголовків пакету. Існують декілька інших режимів виводу сигнальної інформації, доступні з командного рядка, а також два засоби реєстрації. Пакети можуть бути зареєстровані у стандартному декодованому форматі ASCII або у бінарному журналі через ключ командного рядка -b. Якщо ви бажаєте повністю відключити реєстрацію пакетів, використовуйте параметр командного рядка -N.

Режими сигналізації дещо складніше. Є шість режимів сигналізації, що доступні з командного рядка: повний (full), швидкий (fast), сокет, syslog, smb (winpopup), а також ніякий (none). До чотирьох з цих режимів звертаються з параметром командного рядка -A. Ці чотири опції:

  •  A fast Швидкий режим сигналізації, пише попередження в простому форматі з позначкою часу, сигнальним повідомленням, IP адресами й портами джерела і адресата.
  •  A full Це заданий за замовчанням режим сигналізації, тобто якщо ви не призначаєте режим, то буде автоматично використовуватись саме він
  •  A unsock Спрямовує попередження UNIX сокету, на якому може слухати інша програма
  •  A none Відключає сигналізацію
  •  A console Надсилає попередження “в швидкому стилі” на консоль (екран)

Щоби надсилати попередження syslog, використовуйте параметр -s. Задані за замовчанням засоби для механізму сигналізації syslog – LOG_AUTHPRIV и LOG_ALERT. Якщо ви бажаєте призначити інші засоби для виводу syslog, використовуйте вставні директиви виводу у файлах правил (див. файл snort.conf для отримання додаткової інформації).

Нарешті, існує механізм сигналізації SMB. Це дозволяє Snort робити запити до smbclient, який працює з Samba (сервером SMB), і надсилати сигнальні повідомлення WinPopup машинам Windows. Щоби використовувати цей режим сигналізації, ви повинні конфігурувати Snort за допомогою параметру –enable-smbalerts.

Ось деякі приклади конфігурації виводу:

  1.  Реєструвати засобом, заданим за замовчуванням (декодований ASCII), і надсилати попередження syslog:

snort -c snort.conf -l ./log -s -h 192.168.1.0/24

  1.  Реєструвати засобом, заданим за замовчуванням, в /var/log/snort, і надсилати попередження в швидкий сигнальний файл:

snort -c snort.conf -s -h 192.168.1.0/24

  1.  Реєструвати в бінарний файл і надсилати попередження робочій станції Windows:

snort -c snort.conf -b -M WORKSTATIONS

  1.  Реєструвати в бінарний файл і використовувати швидкий режим сигналізації, реєструючи у /var/snort:

snort -c snort.conf -b -A fast -l /var/snort

Конфігурація продуктивності

Якщо ви бажаєте, щоби Snort працював швидко (наприклад, “не відстаючи від мережі 100 Mbps”), використовуйте опції “-b” і “-A fast” або “-s” (syslog). Цей режим буде реєструвати пакети у форматі tcpdump і генерувати мінімальні попередження. Наприклад:

./snort -b -A fast -c snort-lib

В такій конфігурації Snort здатен реєструвати численні одночасні сканування й атаки на ЛОМ 100 Mbps, що працювала на рівні насичення приблизно 80 Mbps. В цій конфігурації файли реєстрації записуються у бінарному форматі у файл snort.log формату tcpdump. Щоби прочитати цей файл і розібрати дані у знайомому форматі Snort, достатньо повторно виконати Snort на файлі даних з опцією “-r” й іншими опціями, які ви звичайно використовували б. Наприклад:

./snort -d -c snort-lib -l ./log -h 192.168.1.0/24
-r snort.log

Як тільки це виконано, всі дані будуть знаходитись у реєстраційному каталозі в їх нормальному декодованому форматі.

Дещо іще

Декому не подобається заданий за замовчуванням спосіб, яким Snort застосовує свої правила до пакетів, коли першими застосовуються сигнальні правила (Alert rules), далі правила проходу (Pass rules) і, нарешті, правила реєстрації (Log rules). Ця послідовність дещо не інтуїтивна, але цей спосіб більш стійкий до помилок («проти дурня»), ніж дозволити користувачу написати сотню правил сигналізації, а потім відключити їх усі одним невірним правилом проходу. Для тих, хто знає, що вони роблять, існує параметр “-o”, який заміняє задану за замовчуванням поведінку по застосуванню правил на послідовність: правила проходу, далі сигнальні, далі реєстрації.

./snort -d -h 192.168.1.0/24 -l ./log -c snort.conf -o

Різний матеріал 

Якщо ви бажаєте виконувати Snort в режимі демона (“daemon”), ви можете додати параметр -D до будь-якої комбінації з наведених вище. Зверніть увагу, що, якщо ви бажаєте мати можливість перезапустити Snort, надсилаючи сигнал SIGHUP демону, ви повинні будете використовувати повний шлях до бінарного виконавчого файлу програми Snort, коли ви його запускаєте, наприклад:

/usr/local/bin/snort -d -h 192.168.1.0/24 -l /var/log/snortlogs -c /usr/local/etc/snort-lib -s -D

Відносні шляхи не підтримуються з міркувань безпеки.

Якщо ви збираєтесь розсилати поштою файли реєстрації пакетів у списки адресатів, вам варто спробувати параметр -O. Цей параметр “заплутує” ваші адреси IP в роздруківках пакету. Це зручно, якщо ви не бажаєте, щоби адресати із списку знали реальні адреси IP, що використовувались. Ви можете також комбінувати параметр -O з параметром -h, щоби заплутати лише адреси IP хостів домашньої мережі. Це корисно, якщо вас не турбує, хто бачить адресу хосту, з якого здійснювали напад. Наприклад:

./snort -d -v -r snort.log -O -h 192.168.1.0/24

Це змусить Snort читати пакети з файлу реєстрації й спрямовувати пакети на екран, заплутуючи лише адреси з мережі класу C 192.168.1.0/24.

Якщо ви бажаєте бачити статистику пакетів Snort без зупинки процесу, надішліть SIGUSR1 процесу Snort, і він спрямує stats на екран або syslog, якщо він виконується в режимі демона. Це дозволить вам побачити, які протоколи Snort бачив, отримати кількість попереджень, зареєстрованих пакетів і повну кількість пакетів, що були помічені й відкинуті. Це дуже зручна можливість, якщо ви налаштовуєте Snort на максимальну продуктивність.

Додаткові питання можна з’ясувати у автора Мартіна Рьоша за адресою roesch@sourcefire.com.

Додаток 5. Використання оболонки
IDScenter для налаштовування системи виявлення атак Snort

Як було зазначено, Snort портовано для систем сімейства Windows. Тепер Snort доступний у вигляді звичайного інсталяційного пакету. При цьому він зберіг характерні ознаки програм Unix: він існує у вигляді ядра, яке працює без зв’язку з графічним інтерфейсом Windows. Для керування ядром Snort можна скористатись інтерфейсом командного рядка, доступним з системної консолі (Start  Run cmd або Пуск Выполнить cmd). Для підвищення зручності користування Snort розроблено графічні інтерфейси керування (IDScenter, SnortPanel). Слід зазначити, що вони з одного боку є досить незалежною розробкою і не є частиною самого Snort, а з іншого боку наслідують певні особливості використання Snort і тому не завжди інтуїтивно зрозумілі. Використання цих оболонок вимагає розуміння того, що таке МСВА і як працює Snort.

Вікно програми IDScenter

У вікні програми можна виділити такі зони:

  1.  зверху-зліва – баннер з логотипами IDScenter і Snort;
  2.  зверху-справа – основні опції для керування Snort, тут розташовані кнопки:
  •  Start Snort (запустити Snort),
  •  Reset alarm (скинути сигнал про атаку),
  •  Test configuration (протестувати конфігурацію);
  1.  зліва – меню для вибору екрану налаштовувань у вигляді розташованих у одну колонку кнопок:
  •  General setup (загальні налаштовування),
  •  IDS rules (правила СВА),
  •  Logs/Alerts (параметри ведення протоколів),
  •  E-Mail alert (пересилання сигналів про атаку по E-Mail),
  •  Special options (спеціальні опції) – звуки, запуск зовнішніх програм у разі виявлення атак,
  •  Preferences (додаткові опції) – додаткові параметри запуску IDScenter і режиму перегляду протоколів,
  •  Overview (огляд конфігурації),
  •  View alerts (переглянути попередження про атаки),
  •  Logs folder (каталог протоколів) – відкриває каталог на диску, де Snort створив протоколи,
  •  About (про програму);
  1.  знизу-справа – кнопки роботи з поточною конфігурацією:
  •  Download (завантажити конфігурацію з мережі),
  •  Apply (застосувати) – задіяти зміни, щойно внесені до конфігурації (при внесенні змін важливо не забувати натискати цю кнопку),
  •  Load config (завантажити попередню конфігурацію) – фактично діє як звичайна кнопка Cancel (Відмінити);
  1.  зовсім знизу – традиційний для вікон програм Windows рядок стану;
  2.  решта (більше половини площини вікна) – поле вводу й інші елементи налаштовувань, що відповідають обраному пункту меню (кнопкою з зони 3).

Слід зазначити, що традиційного меню Windows зверху вікна (File, Edit, … , Window, Help) IDScenter не має. Також взагалі немає ані пункту меню, ані кнопки Help (Довідка).

Екран “General setup”

Головний екран (“General setup”) дозволяє задати основні опції для запуску Snort. В пункті Snort Setup повинен бути заданий шлях до файлу Snort.exe. Також необхідно задати мережеву адресу і номер інтерфейсу (якщо останній параметр не заданий, Snort може не працювати навіть на системі з одним єдиним інтерфейсом). Решта параметрів здебільшого впливають не на можливість роботи Snort, а на те, як ефективно він використовує ресурси. Зокрема, Process Priority дозволяє встановити пріоритет процесу; Show Snort Console – показувати вікно консолі Snort; Minimized Snort Window – згорнути вікно Snort; Don't restart Snort, if it is killed – нe перезапускати Snort, якщо його було зупинено системою.

Екран “IDS rules”

Після екрану “General setup” абсолютно необхідно звернутись до екрану “IDS rules” для завдання правил, за якими Snort оброблятиме мережеві пакети. Правила можна або задавати вручну у вікні IDS rules, або завантажити з файлу. Ім’я файлу і шлях до нього задаються у вікні Snort IDS ruleset. Після завантаження правила з’являються у вікні IDS rules. Для редагування правил можна призначити зовнішній редактор (External editor). Повернутись до завантажених з файлу правил після невдалого редагування можна за допомогою кнопки Reload, а кнопка Save дозволяє зберегти у файлі поточний набір правил для подальшого завантаження. Також у цьому вікні можна змінити порядок застосування правил (Change rules testing order), як з опцією командного рядка -o, тобто із стандартного Alert|Pass|Log|Activation|Dynamic на Pass|Alert|Log|Activation|Dynamic. Тепер найголовніше – застосувати набір правил натисканням кнопки Apply, саме після цього генерується так званий скрипт (сценарій), без якого IDScenter категорично відмовляється запускати Snort.

Тепер можна запускати Snort кнопкою Start Snort, але перед цим рекомендується протестувати конфігурацію кнопкою Test configuration. Якщо конфігурація некоректна, відкриється консольне вікно. Закрити його можна, активізувавши його і натиснувши клавішу Enter. Приклад вікна, що відкрилось внаслідок помилки, показано далі.

Якщо перевірка була успішною, слід перейти до екрану Logs/Alerts.

Екран “Logs/Alerts”

Екран Logs/Alerts дозволяє задати параметри ведення протоколу.

Доступні опції:

  •  Set directory for Snort logfiles – призначити каталог для зберігання протоколів роботи Snort;
  •  Log to a remote syslog – дозволяє використовувати систему реєстрації syslog на віддаленому Posix-сумісному сервері;
  •  Set alert mode – задає режим попереджень (Fast – короткий формат, один рядок, Full – розширений формат);
  •  Log alerts to eventlog – дозволяє використовувати системний журнал Windows для запису попереджень про підозрілі події;
  •  Disable logging – відключає режим протоколювання;
  •  Options – дозволяє задати специфічні опції:
  •  Include ARP Packetsзаписувати ARP пакети,
  •  Include Application Layer – включати в протокол рівень застосувань,
  •  Include 2nd layer header info – включати в протокол заголовки 2-го (канального) рівня,
  •  Payload: character data only – з вмісту пакетів включати в протокол лише текстову інформацію,
  •  TCPDump logformat – вести протокол у форматі TCPDump,
  •  Hide IP of home network – приховати адресу домашньої мережі,
  •  Add interface name to alert output – включати в протокол ім’я мережевого інтерфейсу,
  •  Dump the raw packets – записувати повні (необроблені) пакети,
  •  Snap length of logged packets – встановити обмеження на довжину пакетів.

Кнопка Apply застосовується для збереження налаштовувань (буде згенеровано конфігураційний файл для Snort або видано повідомлення про помилку). Кнопка Load config застосовується для відновлення попередньої конфігурації.

Запуск

Якщо виконано всі дії, що були описані вище, а сценарій і конфігураційний файл успішно згенеровані, можна виконувати запуск Snort. Для запуску Snort застосовується кнопка Start Snort, для зупинки – кнопка Stop. Під час роботи всі пакети, що відповідають заданим правилам, будуть записані в каталог, призначений на екрані General Rules.

Для більш детального знайомства із Snort звертайтесь до документації.

Додаток 6. Міжмережевий екран ipfirewall

Міжмережевий екран (МЕ), що має назву ipfirewall, входить до ядра операційної системи FreeBSD. МЕ ipfirewall має можливості як пакетного фільтру, так і шлюзу сеансового рівня. Для керування ним використовується команда ipfw – програмний інтерфейс керування МЕ ipfirewall, а також формувачем трафіку dummynet. Для того, щоби задіяти цей МЕ, необхідно зібрати ядро системи з встановленою відповідною опцією.

Синтаксис команди

ipfw [-q] add [number] rule-body

ipfw [-f | -q] flush

ipfw [-q] {zero | resetlog | delete} [number ...]

ipfw [-s [field]][-aftN]{list | show}[number ...]

Примітка: напівжирним шрифтом виділені ключові слова і параметри, курсивом виділені назви параметрів, що підставляються.

Опис

Кожен пакет, що іде, пропускається через правила ipfw. Якщо хост діє як шлюз, пакети, що пересилаються шлюзом, обробляються ipfw двічі (при надходженні з мережі і при відправленні в іншу мережу). У випадку, якщо хост діє як міст, пакети, що пересилаються мостом, обробляються ipfw один раз.

Конфігурація МЕ здійснюється у вигляді списку пронумерованих правил, що переглядається для кожного пакета, поки не буде знайдений збіг і виконана відповідна дія. У залежності від дії і деяких параметрів настроювання системи, пакети можуть бути повторно введені для подальшої обробки міжмережевим екраном, починаючи з наступного правила після знайденого збігу. Усі правила звертаються до всіх інтерфейсів, так що системний адміністратор відповідає за те, щоб скласти набір правил (ruleset) таким чином, щоб мінімізувати число перевірок.

Конфігурація завжди включає ЗАДАНЕ ЗА ЗАМОВЧУВАННЯМ правило (під номером 65535), що не може бути змінено програмістом і завжди відповідає всім пакетам. Дія, зв'язана з заданим за замовчуванням правилом, може бути або заборонити (deny), або дозволити (allow), у залежності від того, як сконфігуровано ядро. З міркувань виконання принципу мінімальних повноважень (заборонено все, що не є явно дозволеним) переконливо рекомендується практично у всіх випадках конфігурувати ядро так, щоби правило за замовчуванням було deny.

Якщо набір правил включає одне чи більш правил з опцією зберегти стан (keep-state), то ipfw припускає поводження зі зберіганням стану (stateful), тобто у випадку збігу створюються динамічні правила, що відповідають точним параметрам (адреси, порти, протокол) відповідного пакета, але дозволяється проходження пакетів в обох напрямах.

Динамічне правило знаходиться в списку правил в місці, де встановлено правило check-state, а якщо такого немає, то в місці, де зустрічається перше keep-state. Динамічне правило має обмежений час життя, але лічильник обнуляється кожного разу, коли зустрічається пакет, що відповідає цьому правилу. Опцію keep-state зручно використовувати для забезпечення можливості дозволити виступати ініціаторми з’єднання лише одній стороні (як правило, зсередини захищеної мережі).

Усі правила (включаючи динамічні) мають кілька зв'язаних лічильників: індекс пакета, індекс байта, реєстраційний індекс і мітку часу (timestamp), що вказує час останнього збігу. Лічильники можуть відображатися чи обнулятися командами ipfw.

Правила можуть додаватися командою add; віддалятися індивідуально командою delete і глобально (всі правила разом) командою flush; відображатися, опціонально зі змістом лічильників, використовуючи команди show і list.

Нарешті, лічильники можуть бути скинуті командами zero і resetlog.

Доступні такі опції:

-a При лістингу, показувати значення лічильників. Див. також команду show.

-q Застосовуючи команди add (додати), zero (обнулити), resetlog (скинути журнал), flush (скинути), не повідомляти про дії. Це корисно для коректування правил шляхом виконання багаторазових команд ipfw у сценарії (наприклад, 'sh /etc/rc.firewall'), чи, обробляючи файл багатьох правил ipfw у ході сеансу віддаленого входу в систему.

УВАГА! Якщо команда flush виконується в звичайному (багатослівному – verbose) режимі (із заданою за замовчуванням конфігурацією ядра), вона друкує повідомлення. Оскільки всі правила скидаються, повідомлення не може бути передано сеансу входу в систему. Це приводить до закриття сеансу віддаленого входу в систему, і залишок набору правил не обробляється. Для відновлення необхідний доступ до консолі.

-t При лістингу, показати мітку часу (timestamp) останнього збігу.

-N Намагатися визначити адреси і назви служб (сервісів) у виводі замість номерів.

Формат правил 

Формат правил ipfw такий:

[prob match_probability] action [log [logamount number]] proto from src to dst [interface-spec] [options]

Кожний пакет може фільтруватися на основі такої пов’язаної з ним інформації:

  •  інтерфейси передавання і приймання (за ім’ям чи адресою),
  •  напрямок (вхідний чи вихідний),
  •  IP адреси джерела і призначення (можливо, масковані),
  •  протокол (TCP, UDP, ICMP і т.д.),
  •  порти джерела і призначення (списки, діапазони чи маски),
  •  прапорці TCP,
  •  прапорці IP фрагментів,
  •  опції IP,
  •  типи ICMP,
  •  ідентифікатор користувача/групи (User/group ID) сокета, пов’язаного з пакетом.

Зверніть увагу, що може бути ненадійним фільтрування за IP адресою джерела чи за TCP/UDP портом джерела, тому що кожен з них чи всі вони можуть бути легко підроблені (spoofing).

action (дія):

allow (дозволити)

Дозволити (пропустити) пакети, що відповідають правилу). Пошук припиняється. Аліаси (псевдоніми, синоніми): pass (пропустити), permit (дозволити) та accept (прийняти).

deny (заборонити)

Заборонити (відкинути) пакети, що відповідають цьому правилу. Пошук припиняється. Аліас: drop (відкинути).

unreach code (недосяжний код)

Відкинути пакети, що відповідають цьому правилу, і спробувати відправити повідомлення ICMP unreachable з кодом code, де code – число від 0 до 255 чи один із псевдонімів: net (мережа), host (хост), protocol (протокол), port (порт), needfrag, srcfail (помилка джерела), net-unknown (мережа-невідома), host-unknown (хост-невідомий), isolated (ізольований), net-prohib (мережа-заборонена), host-prohib (хост-заборонений), tosnet, toshost, filter-prohib (фільтр-заборонений), host-precedence (старшинство хоста) чи precedence-cutoff (скорочення старшинства). Пошук закінчується.

reset (скидання)

Тільки для TCP пакетів. Відкинути пакети, що відповідають цьому правилу, і спробувати відправити повідомлення TCP reset (RST). Пошук закінчується.

count (рахунок)

Обновити лічильники для всіх пакетів, що відповідають цьому правилу. Пошук продовжується з наступного правила.

check-state (перевірити стан)

Перевіряє пакет по динамічному набору правил. Якщо відповідність знайдена, тоді пошук закінчується, інакше ми переходимо до наступного правила. Якщо правило check-state не знайдене, то динамічний набір правил перевіряється при першому правилі з опцією keep-state.

divert port (відхилити порт)

Відхилити (перенаправляти) пакети, що відповідають цьому правилу до сокету divert(4), зв’язаному з портом port. Пошук закінчується. Тобто пакети, що відповідають цьому правилу, будуть оброблятися заданим програмним засобом.

Приклади

Усі наведені приклади – команди, що додають правила або роблять інші дії. Номери правил не задані. Ipfw додасть номери автоматично.

Перегляд поточних правил:

ipfw show

Наступна команда додає правило, яке забороняє проходження всіх TCP пакетів з хоста cracker.evil.org на порт telnet хоста wolf.tambov.ru:

ipfw add deny tcp from cracker.evil.org to wolf.tambov.ru telnet

Наступна команда забороняє будь-яке з’єднання з заданої мережі на визначений хост (my host):

ipfw add deny ip from 123.45.67.0/24 to my.host.org

Ефективний шлях обмежити доступ, не використовуючи динамічні правила, полягає у використанні наступної послідовності правил:

ipfw add allow tcp from any to any established

ipfw add allow tcp from net1 portlist1 to net2 portlist2 setup

ipfw add allow tcp from net3 portlist3 to net3 portlist3 setup

...

ipfw add deny tcp from any to any

Перше правило буде швидко знаходити відповідність для усіх звичайних TCP пакетів, крім початкових SYN пакетів (спроб відкрити нове з’єднання). SYN пакети будуть пропускатися двома наступними правилами setup лише для заданих пар джерело/призначення. Всі інші SYN пакети будуть відкинуті кінцевим правилом deny. Така послідовність правил добре працює по відношенню до нормальних пакетів, але не здатна відбити DoS атаку-шторм спеціально згенерованих TCP пакетів, що не містять флагу SYN. Надійніше користуватись динамічними правилами:

ipfw add check-state

ipfw add deny tcp from any to any established

ipfw add allow tcp from my-net to any setup keep-state

Це дозволить МЕ встановлювати динамічні правила лише для тих з’єднань, які відкриваються нормальним SYN пакетом, що виходить зсередини нашої (захищеної) мережі. Динамічні правила перевіряються, коли в списку зустрічається перше правило check-state або keep-state. Для мінімізації роботи по скануванню списка правил, правило check-state має розміщатись у списку біля початку списку.

УВАГА: правила зі збереженням стану (stateful) можуть бути ціллю атак на відмову в обслуговуванні через шторм SYN запитів (SYN-flood), що відкриває величезну кількість динамічних правил.

Використання команди list для перегляду реєстраційної інформації з позначками часу:

ipfw -at list

Список рекомендованої літератури

  1.  Зегжда Д. П., Ивашко А. М. Как построить защищенную информационную систему. – СПб: НПО “Мир и семья – 95”, 1997. – 312 с.
  2.  Зегжда Д. П., Ивашко А. М. Как построить защищенную информационную систему. Технология создания безопасных систем. – СПб: НПО “Мир и семья – 95”, ООО “Интерлайн”, 1998. – 256 с.
  3.  Проскурин В. Г., Крутов С. В., Мацкевич И. В. Программно-аппаратные средства обеспечения информационной безопасности. Защита в операционных системах. – М.: Радио и связь, 2000. – 168 с.
  4.  Теоретические основы компьютерной безопасности / П. Н. Девянин, О. О. Михальский, Д. И. Правиков и др. – М.: Радио и связь, 2000. – 192 с.
  5.  Щербаков А. Ю. Введение в теорию и практику компьютерной безопасности. – М.: издатель Молгачева С. В., 2001, 352 с.
  6.  НД ТЗИ 1.1-002-99. Общие положения по защите информации в компьютерных системах от несанкцонированного доступа. – “Безопасность информации”, №1(10), 1999. С.5.
  7.  НД ТЗИ 1.1-003-99. Терминология в области защиты информации в компьютерных системах от несанкцонированного доступа. – “Безопасность информации”, №1(10), 1999. С.19.
  8.  НД ТЗИ 2.5-004-99. Критерии оценки защищенности информации в компьютерных системах от несанкцонированного доступа. – “Безопасность информации”, №1(10), 1999. С.43.
  9.  НД ТЗИ 2.5-005-99. Классификация автоматизированных систем и стандартные функциональные профили защищенности обрабатываемой информации в компьютерных системах от несанкцонированного доступа. – “Безопасность информации”, №1(10), 1999. С.87
  10.  Володимир БЕЗМАЛИЙ. Комп’ютери + Програми. №4 – 2002
  11.  Кокорева О. Реєстр Windows 2000.— Санкт-Петербург: Видавничий будинок «BHV», 2000.


 

А также другие работы, которые могут Вас заинтересовать

17774. Розробка електронного навчального модуля 27.65 KB
  Лабораторна робота № 1 Тема. Розробка електронного навчального модуля. I частина – Інформація. Підготовка навчальних презентацій для викладання іноземних мов засобами програми Power Point. Мета . Оволодіння навичками створення електронного навчального мо...
17776. Розробка електронного навчального модуля 84.5 KB
  Лабораторна робота № 2 Тема. Розробка електронного навчального модуля. II частина – Практика. Підготовка навчальних матеріалів для закріплення знань учнів з іноземних мов засобами програмно – апаратного комплексу Smart Board. Мета . Оволодіння навичками створе...
17777. ЗАГАЛЬНА ФІЗІОЛОГІЯ ЗБУДЛИВИХ ТКАНИН 1.95 MB
  Загальна фізіологія збудливих тканин. 1. Фізіологія як наука. Поняття про функцію. Методи фізіологічних досліджень. Нормальна фізіологія – наука про об’єктивні закономірності протікання функцій організму в їх взаємозв’язку і у взаємодії організму із зовнішнім середо
17778. ЗАГАЛЬНА ФІЗІОЛОГІЯ РЕГУЛЯЦІЇ ФУНКЦІЙ ОРГАНІЗМУ 3.29 MB
  загальна фізіологія регуляції функцій організму. 1. Біологічна регуляція її види і значення. Контур біологічної регуляції. Роль зворотнього зв’язку в регуляції. Біологічна регуляція – процес взаємодії елементів організму спрямований на отримання пристосувального ...
17779. НЕРВОВА ТА ГУМОРАЛЬНА РЕГУЛЯЦІЯ ВЕГЕТАТИВНИХ ФУНКЦІЙ ОРГАНІЗМУ 1.15 MB
  НЕРВОВА ТА ГУМОРАЛЬНА РЕГУЛЯЦІЯ ВЕГЕТАТИВНИХ ФУНКЦІЙ ОРГАНІЗМУ. Вегетативні функції – функції внутрішніх органів гладеньких м’язів судин та обмін речовин. 17. Загальний план будови автономної нервової системи. Вегетативні рефлекси їх рефлекторні дуги. Вегетат
17780. ФІЗІОЛОГІЯ ТРАВЛЕННЯ 1.06 MB
  фізіологія травлення. 1. Загальна характеристика системи травлення. Травлення в ротовій порожнині. Жування ковтання. ...
17781. ФІЗІОЛОГІЯ КРОВІ 756 KB
  фізіологія крові. 1. Загальна характеристика системи крові. Склад і функції крові. Поняття про гомеостаз. Кров циркулююча – знаходиться в стані активно...
17782. ФІЗІОЛОГІЯ КРОВООБІГУ 2.43 MB
  фізіологія кровообігу. 1. Загальна характеристика системи кровообігу. Фактори які забезпечують рух крові по судинах його спрямованість та безперервність. В залежності від потреби