Главная / Дневники / Натров Владимир / Запись
Анализ трафика 24.05.2019 17:55
fomalhaut
29.11.2005
14:58
Разбираясь на прошедших выходных с протоколами вычислительных сетей (читая RFC) первоначально пришел просто в ступор, представив всю иерархию и взаимосвязь протоколов. Взаимная инкапсуляция (например, NetBIOS и IP и TCP) и выявленные недостатки в различных протоколах, связанные с безопасностью - как тут можно говорить о какой-то боле-менее реальной защите от сетевых вторжений, если сама эта структура настолько "небезопасна", что потенциально, как уже не раз отмечалось, любая ЭВМ атакавана, если она подключена к сети! :(
Правда, в последнее время положительные изменения в этом направлении есть, например, создание IPv6, где запрещена фрагментация и есть другие изменения, положительные с точки зрения безопасности.
Вот теперь буду дальше "курить мануалы", т.е. читать RFC и пытаться представить, что и каким образом надо анализировать в сетевом трафике, чтобы иметь возможность фиксировать вторжения, эксплуатирующие недостатки сетевых протоколов.

P.S. А кто сказал, что будет легко? ;)
Ответить предыдущая | следующая

КОММЕНТАРИИ:

03.12.2005 00:05#
n0isy
Анализ трафика - не так страшен черт...
Что касается сложной реализации неуязвимой ОС в связи со стандартами, так первые протоколы старее первых вирусов лет на 5. :-)
Таким образом можно судить о том, что стандарты делались не под задачи безопастности, а под задачи простоты реализации. (Вспомним хотя бы plaint text пароль во всех основных протоколах передачи даже ПРИВАТНОЙ информации)
Ведь дапустим реализацию клиента tftpd можно(и нужно было!) уместить в 512 байт бут сектора, где же там криптоваться!
Да реализовать старые протоколы на новый лад сложно, но можно! И фрагментация не самое страшное, при правильной реализации "дефрагментации" пакетов ОСи будет все равно как ты его порежешь. он либо дойдет либо не дойдет, но ОС при этом не ляжет. Уже Десятки лет проходит процесс осмысления и действительно, сейчас сами протоколы ставят задачи безопастности на первое место. Что касается RFC там много лишнего, приходится фильтровать. Если Вас интересует именно безопастность то можете посетить ресурсы, напрямую связанные с сетевой безопастностью допустим:
security.nnov.ru
void.ru
...
05.12.2005 09:32#
fomalhaut
настроение:
заинтересованный
заинтересованный
Анализ трафика - не так страшен черт...
Фрагментация "плоха" не потому, что ОСь ляжет или нет - это зависит от продуманности реализации стека протоколов.
Но кроме атаки на саму ОС непосредственно, можно использовать фрагментацию для нарушения режима безопасности, например, идет передача каких-то данных фрагментированными пакетами: передается 3 пакета, вместо указанных в параметрах 4. Т.е. система будет ждать получения оставшихся пакетов, а злоумышленник, зная, что их будет всего 3 - получает всё ему необходимое. Можно реализовать и более хитрый вариант, перемешав нужные пакеты с "пустыми".
А RFC действительно перегружен лишней информацией... :(
На данный момент мне нужна инфомация о статистике:
1) использования для атак протоколов;
2) использования для атак конкретных полей протоколов;
3) сколько видов атак используют тот или иной протокол;
4) сколько видов атак используют те или иные поля протоколов?
Эта информация в открытом виде, насколько мне известно, не присутствует, а, возможно, есть в фирмах, занимающихся ИБ. Как образом можно получить её - ещё в раздумьях.
05.12.2005 18:31#
bozox
Анализ трафика - не так страшен черт...
Никакой протокол не защитит от человеческого фактора. Самый надежный метод взлома - позвонить в бухгалтерию, представиться новеньким ай-тишником и СПРОСИТЬ пароль. См. биографию Кевина Митника. Также dictionary attack.
06.12.2005 09:29#
fomalhaut
Анализ трафика - не так страшен черт...
Согласен - социальная инженерия куда более легкий способ обойти самые изощренные системы безопасности. Ошибки в ПО, реализации системы и "закладки" - тоже слабо поддаются анализу.
Но задача у меня именно провести исследование именно сетевых вторжений с использованием особенностей протоколов, т.е. задача сужена до анализа трафика.
06.12.2005 18:47#
bozox
Анализ трафика - не так страшен черт...
Ну, если такая постановка задачи...

А Кирилл правильно написал. Когда все это сочинялось (в 1970-е), о безопасности просто не думали. Да и вычислительные мощности были не те, что сейчас.

А смотреть надо не RFC, а Bugtraq. Кто ж вам будет в RFC уязвимости перечислять. :)
06.12.2005 21:37#
n0isy
Анализ трафика - не так страшен черт...
Остается только добавить, что ссылки рускоязычного Bugtraq и около хакерских я нарисовал в первом комментарии. ;-)
Но вот еще вопрос, а как написать протокол, в который бы был изначально "непробиваем"? Я понимаю что задача не тривиальная, и кто-то сразу скажет, что и не нужная, так как к протоколописанию нас простых смертных никто не допустит, однако есть еще самопальный софт со своим внутренним протоколом, даже пускай поверх существующего, и вопрос в том, как обезапасить себя при написании (а) теории и (б) реализации своего собственного протокола. Кстати написать собственный RFC не такая уж и проблема. Есть же протокол обмена с кофеваркой. О-очень интеренсный RFC.... ;-)
06.12.2005 22:09#
bozox
Анализ трафика - не так страшен черт...
Надо тщательно определить "непробиваемость". Любое шифрование, любой пароль в принципе ломаются прямым перебором. В этом смысле, абсолютно непробиваемый протокол невозможен в принципе (если не брать квантовые). Если поставить защиту от перебора (типа как account lockout в WinNT), то это только означает, что перебор займет дольше.

Если свести "пробиваемость" к существующей, заведомо сложной вычислительной проблеме, то поставить задачу уже можно. Например, если потребовать, чтобы протокол должен быть настолько же устойчив, насколько устойчив шифр RSA c 1024-битным ключом, то такой протокол уже есть - SSL называется. Тогда уже можно ввести концепцию "ошибки реализации" - это когда число переборов, необходимых для вскрытия, меньше теоретически заявленого. По этому определению, хэш-функции MD5 и SHA1 можно смело считать сломанными.

Есть также такое соображение, как практическая осуществимость атаки. Если теоретическая стойкость защиты требует 10^25 машинных лет для взлома перебором, а реализация ломается за всего (!) 10^15 лет, то бить тревогу, по очевидности, рано. :)

К слову, насчет "простых смертных" - это как сказать. Один из авторов протокола SCTP в бытность свою студентом ходил в моих подчиненных :) А на прошлой работе, наоборот, мой начальник выступал перед W3C, предлагал принять внутри конторы разработанный язык в качестве стандарта (уж не знаю, что из этого получилось). Так что не надо комплексовать. Другое дело, что протоколы нижних уровней - транспорт и ниже - действительно никто переписывать не станет - просто из соображений сохранения немеряного объема существующих наработок...
06.12.2005 23:15#
dean
Анализ трафика - не так страшен черт...
> абсолютно непробиваемый протокол невозможен в принципе (если не брать квантовые).

С квантовыми, по-моему, тоже большие трудности, в смысле практической реализации теоретической стойкости. (А "чисто теоретически", понятно, есть и не квантовые абсолютно стойкие криптосистемы. Это к слову о шифровании.)
06.12.2005 23:33#
bozox
Анализ трафика - не так страшен черт...
>>не квантовые абсолютно стойкие криптосистемы

Э... что это Вы имеете в виду? Давайте исходить из предположения, что у нас нету защищенного канала, по которому можно сделать предварительный обмен ключами.

Лично мне известна ровно одна абсолютно стойкая система - с одноразовым ключом, равным по длине сообщению :)
07.12.2005 08:22#
dean
Анализ трафика - не так страшен черт...
> абсолютно стойкая система - с одноразовым ключом, равным по длине сообщению

Система, которая на практике бесполезна (но не квантовая, согласитесь), о чем, собственно, и речь.
07.12.2005 09:30#
fomalhaut
настроение:
впечатленный
впечатленный
Анализ трафика - не так страшен черт...
Занимаясь по роду своей профессии системным администрированием и активно интересуясь вопросами информационной безопасности (ИБ) давно пришел к выводу, что _абсолютно_безопасных_ систем и средств ИБ НЕ СУЩЕСТВУЕТ. Не беря даже самый общий вариант, т.е. участие человека (а человеческий фактор "неизлечим"), а только техническую реализацию.
И по поводу квантовой криптографии могу сразу сказать так: на данный момент это считается невозможным (т.е. на данном этапе развития науки знаний для взлома этого метода криптографии нехватает). И даже уже встречал статьи, посвященные анализу возможностей и методов для взлома квантовой криптосистемы. И рано или поздно этот метод найдут. А вот когда найдут - многие пользователи этих систем будут чувствать себя защищенными, а на самом деле... Нет ничего хуже в ИБ, чем недооценка противника и ложное чувство защищенности.
Я слабо знаком с теорией квантовой криптографии, но при чтении новостей по этой теме почти всегда испытывают чувство, что квантовая криптография становится "раскрученным брендом" с которого хотял стянуть "сливки". А тут уж сложно будет разобраться, что есть правда, а что - ложь: специалистов в данной области не так много, а те, что есть - "вне досягаемости" для будущих пользователей криптосистем, исключая государство.
В общем лично мне этто кажется по большей части мыльным пузырем - ну не верю я в панацеи! Куда больше в плацебо. :)
07.12.2005 22:07#
dean
Анализ трафика - не так страшен черт...
> И по поводу квантовой криптографии могу сразу сказать так: на данный момент это считается невозможным

Да нет, на бумаге квантовая криптография выглядит, как достаточно совершенная. Другое дело, что при попытке технической реализации возникают чисто инженерные трудности (например, проблематично работать с отдельными фотонами, а лучше с пучком и т.п.), кардинально снижающие теоретическую стойкость. То есть, Вы правы насчет "технической реализации".
09.12.2005 16:51#
fomalhaut
Анализ трафика - не так страшен черт...
Многое, что ранее считалось невозможным сегодня вполне возможно. Будут изучены и апробированы новые принципы и методы. У Природы ко всему есть как минимум два подхода, совершенно различных. :)
13.02.2006 20:47#
serf
Анализ трафика - не так страшен черт...

Хоть и давняя ветка обсуждения, но решил таки написать несколько мыслей (заранее извиняюсь если для вас это банальные истины)...

Криптография в передаче и хранении данных выполняет роль защиты от:

1. Прочтения информации (утечка).

2. Изменения информации (подлог).

Написать оооочень стойкий криптографический код достаточно просто - это чисто математическая задача. Вот только использовать его вы сможете только до момента сертификации. Потому как сертификаторы от вас потребуют универсальный ключик к этому коду, этакую дырочку "на всякий случай". Это правило действует в любой стране. А написать криптографический код с "дырочкой" для одних и без оных для других гораздо сложнее...

Что касается квантовой криптографии, то её отличает от всех остальных только одно свойство: вы гарантированно УЗНАЕТЕ, что информация была ПРОЧИТАНА и, тем более, изменена. И только. Других преимуществ нет, но - "предупреждён - значит вооружён!" - это свойство дорогого стоит...

07.12.2005 08:55#
fomalhaut
настроение:
грустный
грустный
Анализ трафика - не так страшен черт...
Вот во время "раскуривания" RFC и пришел к выводу, что необходима статистика по протоколам. Была надежда, что такая статистика уже кем-то ведется, но в ходе переписки с Алексеем Лукацким и некоторыми ещё людьми пришел к выводу, что либо данной статистики совсем не ведется никем, либо данная информация закрыта у разработчиков (хотя что тут коммерческого?).
07.12.2005 17:55#
bozox
Анализ трафика - не так страшен черт...
А что Вас конкретно интересует? Сколько происходит взломов, основанных на эксплуатации недостатков протоколов семейства TCP/IP? Отвечу: очень мало. Зачем париться на низком уровне, если половина PHP/ASP скриптов уязвима для банальной SQL insertion attack?

На низких уровнях разве что buffer overflow можно иногда сделать, если администратор лопух и патчи не ставит...

Понимаете, низкоуровневый код пишется по не в пример более квалифицированными людьми и с гораздо более интенсивным QA, чем те же PHP-скрипты. Потому на высоком уровне гораздо больше есть, что ловить. Недалеко ходить - недавно брали на работу человечка, ASP.NET писать. Даем на интервью такой вопрос. Дана строка кода:

string SQL = "SELECT * FROM Person WHERE Name='" + Request.Form["Name"] + "'";

Вопрос: что в ней не так?

Половина народа НЕ ОТВЕТИЛИ. А это готовая дыра для вышеупомянутого SQL insertion. Ломай на здоровье.
07.12.2005 18:23#
fomalhaut
настроение:
милый
милый
Анализ трафика - не так страшен черт...
Ошибки обработки параметров протоколов, ARP-spoofing, подмена ARP-запроса, IP-spoofing, ошибки (или _не_ошибки_) фрагментации IP пакетов, атаки Ping of Death, Rose Attack, joit2, на протокол ICMP и пр. (это с нескольких страниц материалов УЦ "ИнформЗащита" - дальше - боольше :). И это не считая банальнейших DoS и DDoS.
В том-то и дело, что "ломка" с использованием ошибок в скриптах - проста и её может сделать каждый. Но и ARP-spoofing может сделать каждый, кто, например, скачает Ettercap. Есть ошибки, есть инструменты эксплуатации этих ошибок.
И суть не в том, чтобы запретить вышеуказанное ПО (оно в равной мере может как помочь атакующему, так и сисадмину или специалисту по ИБ.
Своевременно обнаружение атаки или её предупреждение - вот задача на данный момент. Так же помочь в обнаружении уязвимостей вычислительных систем и тех же скриптов.
P.S. Смотрел на скрипт... Тоже особо не разобрался. Собственно я не программер в чистом виде и совсем не знаю ASP. :) А иногда днями "ковыряюсь" с OS/2. ;)
07.12.2005 22:11#
dean
Анализ трафика - не так страшен черт...
> Смотрел на скрипт... Тоже особо не разобрался.

Там, очевидно, имеется в виду, что в поле формы (Request.Form["Name"]) пользователь волен написать какие-то свои команды, предварив их кавычкой (поправлю: или без кавычки): после объединения строк получится требуемый атакующему запрос.
09.12.2005 16:54#
fomalhaut
Анализ трафика - не так страшен черт...
Ясно. Вспомнил, что на курсах в УЦ "ИнформЗащита" такое рассказывали и даже пробовали на практике.
07.12.2005 17:57#
fomalhaut
Анализ трафика - не так страшен черт...
Ну в RFC я их и не искал. :) Но на некоторые мысли чнение сей литературы навело. Что, собственно, и требовалось. :)
Ну собственно проблемы с протоколами не ограничиваются одной безопасносттью. Коллизии и потери пакетов в протоколах, призванных быть "протоколами гарантированной доставки" - это даже с обычной функциональностью связано. :)
Архив | Дневники | Новости | Календарь
Вести дневник и оставлять комментарии могут только зарегистрированные пользователи
Логин:
Пароль:
Зарегистрироваться
Последние сообщения
Основные положения
Правила
Всего дневников: 764

Пользователей
в системе: 3386

Всего записей
и комментариев: 59465

Записей и комментариев
за последние 24 часа: 0
 ПОИСК ПОСТОВ
  по автору:
  по тексту:
 АКТИВНЫЕ ДНЕВНИКИ
 Все дневники  
e-mail: admin@arxiv.su       О проекте       RSS       Дизайны
©2009-2017 Архив. Все права защищены
Designed by tanyu6ka