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 dont remember
Btw: You have new mail!
[rofl@/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: knock, knock
Date: Mon, 15 Nov 2004 04:35:17 +0000

>>Уффф
>>Я думал только утром от тебя ответ дождусь.
Да вот, заинтересовал ты меня :)
>> Вот, например в Ethernet загловке:
Aha-ha-ha Ethernet, не мог чего лучше найти?
Наверно долго думал над нормализацией его :)))
Шучу, я понял что это к примеру. Не обижайся.
А с расположением, да не догадался :(
Но, на то и нужны друзья :))
Нелегкая этo работа, нормализация, хотя, надо боятся не столько лишнего порезать, как недорезать. Ведь в первом случае, ничего особенного не произойдет, а при втором — будет бона
>> 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




[rofl@/home/rofl/]halt
Sending all proccess then KILL signal...ok
Bye!

Firewall: Hey, kernel, I have some packets!