Firewall: WTF? Ive never see such packet before.
Firewall: Hey, kernel, look it that
Kernel: Panic… Aee, killing interrupt handler!
Firewall: Kernel?!

Login: rofl
Password: ************
Last login: Sorry, i don’t remember
Btw: You have new mail!
[[email protected]/home/rofl/]>cat /var/mail/archive/rofl

From : rofl
To: ilya
Subject: Packet Normalization
Date: Mon, 15 Nov 2004 02:19:57 +0000

Buena Vista ilya!
Як життя, як успіхи ?
Куди пропав, чого не пишеш ?
Сподіваюсь ти ще не продався корпораціям аа… ??
Ха-ха! Жартую, не звертай уваги.
Наскільки я знаю, ти у нас великий любитель протоколів. Ось вирішив тобі задачку підкинути. А то думка вже давно спокою не дає.
Ти чув що-небудь про нормалізацію пакету ?
Я маю на увазі нормалізацію даних, які містить пакет.
Адже багато атаки, так і fingerprinting власне кажучи, засновані на тому, що надсилається спеціально сформований пакет, на який кожна система(програма) реагує по-своєму, а деякі навіть в кору йдуть. Хорошим прикладом може служити уразливість в iptables 🙂
Якщо встановити певні правила, з приводу вмісту пакет, так сказати — нормалізувати його ?
Я не кажу про firewall, портах, адресах. Я маю на увазі весь заголовок з усіма полями в ньому.

From: ilya
To: rofl
Subject: Re: Packet Normalization
Date: Mon, 15 Nov 2004 02:47:14 +0000

Salute rofl!
Чого так пізно не спиш ?
Чи це така фішка всіх адмінів — не спати ночами 🙂
Жизня протікає на відмінно. Спасибі!
А не писав давно, правда, вибач — вчуся, працюю
Про корпорації ти так не жартуй, хоча чесно кажучи, пару рочків б попахал на буржуїв, заради інтересу, я думаю у них теж є чому повчитися!
А ти чого їх так не любиш ?
Що стосується нормалізації, то я про таке ще не чув. Вірніше сказати, навіть не думав.
Треба б в Інтернеті подивитися, напевно, таке питання вже кимось піднімався.
А так ідея хороша, мені подобається!
//піду чайник поставлю, чую ніч тільки почалася 🙂
Тільки нормалізувати треба дуже обережно, як би чого не пропустити або чогось зайвого не урізати 🙂
І ще, як ти думаєш роботу нормалізатора ?
1) Просто відкидати неправильні пакети
2) По можливості коригувати (checksum, len, ttl)
Що стосується мене, другий спосіб більш гуманний, але з іншого боку, в питаннях безпеки, гуманність, я думаю, буде недоречна! Так що DROP!
Потім, весь процес нормалізації необхідно розбити на кілька частин. Кожна буде відповідати одному з рівнів моделі OSI
1)заголовок Ethernet
2) IP
3)

From : rofl
To: ilya
Subject: knock knock
Date: Mon, 15 Nov 2004 03:54:37 +0000

Уффф
Я думав тільки вранці від тебе відповідь дочекаюся.
Здивував, чесно скажу 🙂
А що стосується ночі, не треба думати, що адміни якісь особливі люди і тому працюють ночами. Просто вночі найменша навантаження на серверах, тому зручніше вносити корекції, та і хіба мало чого, раптом сервер впаде, до ранку підняв і порядок. А так, спробуй днем впустити сервер, вмить дізнаєшся всю свою родовід до 12 коліна, від начальства звісно!
А ти, як я подивлюся, хватки не втратив, я тільки ідею сказав, а ти вже почав всі підводні камені шукати.
Що стосується правила DROP і рівня роботи — повністю солідарний.
Правда ти втратив одну річ — місце розташування ?! Хе-хе
Я думаю, нормалізувати трафік необхідно до надходження його на перший мережевий фільтр. Можна звичайно на окремий комп’ютер його поставити, але це накладно.
Краще буде забирати прямо з картки пакет і фільтрувати його там, поки він ще в стек не потрапив. А то, після останніх новин на firewallы сподіватися напевно не дуже варто J)
Техніку реалізації я залишу за собою!
А ти, як сетевик, думай над правилами. Так як тут необхідні хороші знання в протоколах. Та й я теж, чого нитка подумаю.
Ось, наприклад, в Ethernet загловке:
Поле——-Дія
Type——-пропускати лише IPv4 & IPv6 & ARP

From : ilya
To: rofl
Subject: Re: стук, стук
Date: Mon, 15 Nov 2004 04:35:17 +0000

>>Уффф
>>Я думав тільки вранці від тебе відповідь дочекаюся.
Так ось, зацікавив ти мене 🙂
>> От, наприклад Ethernet загловке:
Aha-ha-ha Ethernet, не міг краще знайти?
Напевно довго думав над нормалізацією його :)))
Жартую, я зрозумів що це до прикладу. Не ображайся.
А з розташуванням, та не здогадався 🙁
Але, на те й потрібні друзі :))
Нелегка це робота, нормалізація, хоча, треба бояться не стільки зайвого порізати, як недорізані. Адже в першому випадку, нічого особливого не станеться, а при другому — буде бона
>> ilya підійшов до шафи, подивився на капелюхи і вибрав білу.
>> сьогодні вона якраз доречна 🙂
почну я, мабуть, з IPv4.

Поле ————————————–Дія

Version————————-ACCEPT *тільки* IPv4 & IPv6
Header Len.——————-DROP якщо не збігається з дійсною
Type Of Services————-ACCEPT тільки зі значенням «0» (нам нічого не треба J)
Total Len.———————-DROP якщо не збігається з дійсною
IP Identifier——————-Ставити «0» якщо пакет НЕ фрагментований.
Protocol————————Aha-ha тільки, TCP, UDP, ICMP.
Flag
У цьому місці цікаво:
1)ACCEPT — Встановлений біт More fragments і при цьому поле Frag. Offset *НЕ* 0
2)ACCEPT — Встановлений біт Dont Fragment або взагалі відсутні біти і при цьому поле Frag. Offset = 0
3)Може трапиться, що нам знадобиться дробити пакет самим, треба відслідковувати цю ситуацію, і там вже знімати біт Dont Fragment і дозволяти системі передати пакет далі.
4)Стежити за розміром поля Frag Offset — що б воно не перевищувало норму а то буде ще один ping of death!
5)По можливості, самим збирати фрагменти пакетів, а то різні ОС по різному виробляють цю процедуру. Та й багато NIDS не в стані правильно працювати з фрагментами. Так що краще покласти цю роль на нормалізатор.
6) У всіх інших випадках DROP.

Time To Live
Ну, скажімо, у випадку, якщо значення даного поля менше 10,
Збільшувати його до 100 🙂 Багато використовують це поле для виявлення різних NIDS. А можна просто DROP.

Checksum——————–no comments!

IP адреса
DROP у разі: 127.*.*.*, а так само, якщо він належить до класу E. Хоча тут політика теж гнучка. В залежності від розташування, можна ще DROP пакети з адресами: класу D, broadcast.
IP опції
Кгмм там нічого цікавого немає, я думаю можна сміливо DROP. Хоча, кому цікаво, можна відстежувати правильність опцій. Але краще DROP!!!
Ну ось, що я накидав.
Хоча це, звичайно, тільки умовні обмеження, але достатні для нормального функціонування.
Що це дає:
IP адреси — захист від smurf атаки. І якщо стежити за multicast & broadcast можна і від деяких DoS врятуватися.
Frag. Offset — якщо збирати самим, то позбудемося Rose атаки, а також від деяких атак, спрямованих на обхід IDS.
Ну, і як показує час, із – за некоректність будь-якого поля, може вилетіти наш Firewall.
>> Чого це, цікаво, так на iptable напали 🙂
ну а в тебе які успіхи ?

From : rofl
To: ilya
Subject: Here amI 🙂
Date: Mon, 15 Nov 2004 04:43:25 +0000

З шапкою, це ти кльова придумав :))
А за Ethernet — я й не ображаюся.
Прикольно в тебе вийшло. Мені подобається.
Ти за IPv4 узявся, а я з ICMP вирішив погратися. Один з моїх улюблених протоколів.
Ось тільки не треба знову сміятися. Ну так, він маленький, зате здібностей у нього, мама не горюй!
>> ну а в тебе які успіхи ?
дивися сам :
Взагалі кажучи, IMHO, більшість ICMP можна викинути.
Не буду описувати, що потрібно викинути.
Скажу краще, що можна залишити.
1. Echo і echo_reply — в простанародии ping! 🙂
2. Призначення недоступне (залишити все повідомлення)
3. та, мабуть і все!
ICMP

Поле————————Дія
Checksum——————you know what I mean !

Лишилося 2-а поля, ось вони і становлять пару, яка несе повідомлення.
ACCEPT тільки такі пари полів TYPE & CODE :

Type=0 Code=0 — відповідь (echo_reply) на ping
Type=3 Code=0-15 — призначення недоступне (мережа, хост, порт)
Type=8 Code=0 — запит (echo) на ping

Все інше нещадно DROP.
Ще одне зауваження, що ми не приймаємо жоден ICMP, якщо у нього IP-адресу broadcast або multicast.
Звичайно, можна і ping вимкнути, якщо вже так заважає
І так, що ми маємо з цього :
Викинувши ICMP :
1. «придушення джерела» — захист від деяких DoS
2. «перенаправлення — redirect» — не буде проблем з обманом, як описано в книзі Атака на(з) Інтеренет.
3.Все інше — закрили доступ для додаткового збору інформації про хості.
Що скажеш ?

From : ilya
To: rofl
Subject: Re: Here amI 🙂
Date: Mon, 15 Nov 2004 06:03:54 +0000

Привіт.
Тфу ти, заговорився я тут з тобою, про чайник зовсім забув
Правда на донешке трохи залишилося, тобі заварити? 🙂
Хороший кави, з коньячкомссс.
або без!
І так, вже скоро ранок, ближче до справи.
// Що скажеш ?
Скажу, що ти як завжди на висоті!
ICMP ти порізав будь здоровий, але я б теж так зробив, занадто багато непотрібного в повсякденному житті. Правда, ping я б теж порізав, а те, всякі нехороші люди роблять тунелі… :))
Так сказати DROP за замовчуванням!
Залишається транспортний рівень: TCP & UDP.
IMHO, другий залишимо на закуску.
А от з першим, ми намучаемся. Скільки працюю з TCP не перестаю дивуватися, скільки потужний він, і чому-то кожне моє втручання в його роботу, закінчувалося, м’яко кажучи, false.
Сподіваюся, сьогодні без цього обійдемося.
Поправ мене, друже, якщо я помилюся ненароком!
Отже TCP:
Варто обмовитися, якщо ми хочемо стежити за полями sequence & acknowledgment, тоді нам доведеться переглядати всі з’єднання. Від встановлення і до завершення. У цьому місці треба бути дуже акуратним, якщо встановити нормалізатор у вершині мережі, то через нас буде проходити пристойний обсяг трафіку, що вимагає залучення великого обсягу ресурсів на відпрацювання всіх з’єднань. Може статися конфуз 🙂
Хоча, з іншого боку, реалізувавши грамотно цю роботу, можна позбутися від безлічі проблем. Як то — обхід NIDS.
А так само, стане можливим захиститься від TCPHijacking.
Поля seq & ack_seq я описувати не буду. Якщо з’єднання проглядається то ці поля автоматично задіюються. Якщо приймаємо пакет, який не належить до жодного існуючого з’єднання — DROP. Так би не бентежити наші NIDS

Поле———————————-Дія
ФлагиSYN:
(не утнути б
тут нічого лишнього)
ACCEPT: syn=1 — без даних
ACCEPT: syn=1 & ack=1 — без даних
ACCEPT: syn=1 & fin=1 — без даних
DROP — все інше, де установлений прапор SYN
ACK: ACCEPT: ack=1
ACCEPT: ack=1 & syn=1
ACCEPT: ack=1 & fin=1
ACCEPT: ack=1 & urg=1
DROP — всі інші комбінації з ACK
PUSH:ACCEPT: push=1 & ack=1
ACCEPT: push=1 & ack=1 & urg=1
DROP — всі інші комбінації з PUSH
RST: ACCEPT: rst=1 — без даних
DROP — всі інші комбінації з RST
FIN: ACCEPT: fin=1 & syn=1 — без даних
ACCEPT: fin=1 & ack=1
ACCPET: fin=1 & ack=1 & urg=1
DROP — всі інші варіації з FIN
URG: всі варіанти, де він може бути виставлений прописані вище. Залишилося його скоригувати. Отже, якщо він виставлений (urg=1), то покажчик на дані поле Urgent Pointer) не повинен виходити за рамки пакету.
Якщо це станеться — DROP!
Так само DROP необхідно робити, у випадках:
1. прапор зведений (urg=1) а курсор встановлений в 0, і з
2. прапор не зведений (urg=0) і вказівник НЕ 0.
Обов’язково перевіряти, чи є дані в пакеті при urg=1.
Фуххх. Начебто нічого не упустив. Якщо що, поправ мене J)).
Ports —-Ну, я думаю тут нічого не наворотишь.
Прикриваються firewallaм. Це не наша робота!
Header————-DROP: header From : rofl
To: ilya
Subject: good morning
Date: Mon, 15 Nov 2004 06:51:37 +0000

Ти там акуратніше, а то хату спалиш!
>> Хороший кави, з коньячкомссс.
>>чи без!
Давай, без кави :)))
Собі то спробуй не забув пару крапель покласти
Я дивлюся ти розійшовся не на жарт, цілу поему видав!
Ти скільки чашок перед цим випив?
Або відразу з горлечка прикладався ?! 🙂
Що б так TCP розколупати, не одна рюм. тфу, чашка кави потрібна. J)
А якщо серйозно, то все дуже добре вийшло.
Мені навіть причепитися ні до чого — Mr. Packet J))
Що ж стосується реалізації ти вірно підмітив, моніторинг TCP сесії може стати проблемою. Ми з тобою пізніше на цю тему поговоримо.
А поки, завершальний на сьогодні етап UDP:

Поле ————————–Дія
Length————————-ACCEPT: якщо відповідає дійсності
DROP: if not!
Checksum I love this field!
Ports Залишимо як є, ми все-таки не firewall.
Ну ось і все!
Нічого особливого тут і не прикриєш J)
Ніч підійшла до кінця, скоро все місто прокинеться і всі рушать на роботу, ну а хто на навчання, ти ніби як теж сьогодні вчишся !
Бажаю не заснути на парі, і мій тобі порада, сідай на задні ряди, а то мало того що заснеш, так ще й своїм каву будеш професора в оману вводити. У нього ж немає нормалізатора Аха-ха-ха. Все, пішов ранковий флуд
Поки!
P. S. See yet!

From : ilya
To: rofl
Subject: Re: good morning
Date: Mon, 15 Nov 2004 07:15:34 +0000

Так, ти як завжди правий, в мене теж пари, вранці!
А про каву — no problem!
Дивись, сам не засни у препода на очах!
З одного боку закінчилася ніч, але, я б не сказав що це все.
А як же IPv6, протоколи маршрутизації
Коли їх будемо розглядати ?!
HTTP, POP3, FTP, я думаю, не будемо розглядати, це протоколи верхніх рівнів. Стежити за їх роботою не входить в наші плани. Наприклад — з перевіркою HTTP чудово справляється mod_security!
Краще скажемо так, кінець першої частини! %))
Яку можна завершити так.
Проводячи нормалізацію заголовка пакета, можна істотно підвищити рівень безпеки мережі.
Захист від Rose атак, деяких видів fingerprinting, обхід і обман NIDS, TCPhijacking, smurf атак, а також від інших видів атак які розташовуються на канальному та мережному рівні. Одним з переваг, також можна вважати, виявлення невідомої атаки (у разі, коли мережеве додаток може некоректно обробляти заголовки, наприклад iptables ).
Я думаю цього достатньо для початку.
І на закінчення, я посидів на пошукових системах, і ось що виявив.
Ми не піонери в цій справі, ось кілька статей на цю тему, правда, варто відзначити, що статей на цю тему не так вже й багато.
У нас майже все як у них. Правда, є маленькі розбіжності!
1) Network Intrusion Detection: Evasion, Traffic Normalization, and End-to-End Protocol Semantics (http://www.icir.org/vern/papers/norm-usenix-sec-01-html/)
2) Packet level normalization (www.sans.org/rr/papers/index.php?id=1128)
3) Програма norm — приклад реалізації нормалізації.
(http://sourceforge.net/project/showfiles.php?group_id=22071&release_id=69870)

P. S. Lux e tenebris

[[email protected]/home/rofl/]halt
Sending all proccess then KILL signal…ok
Bye!

Firewall: Hey, kernel, I have some packets!