информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Атака на InternetSpanning Tree Protocol: недокументированное применение
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / site updates
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
А? 03.03.06 17:33  Число просмотров: 3923
Автор: offtopic Статус: Незарегистрированный пользователь
<"чистая" ссылка>
А?
http://ettercap.sourceforge.net/forum/viewtopic.php?t=2329

Кстати, на одной из dlink' моделей с настроенным 802.1x через mac dup тянул траф даже не аутентифицировавшись.
Меры защиты те же что и против калссического arp-spoof.
<site updates>
Атака на коммутаторы второго уровня 27.02.06 22:23  
Publisher: dl <Dmitry Leonov>
<"чистая" ссылка>
Атака на коммутаторы второго уровня
Андрей Вернигора, Андрей Горлов eosfor@mail.ru

Сетевое оборудование
В типичной сети Ethernet одним из основных видов коммуникационного оборудования являются коммутаторы, по-простому - свичи (switches). Основной задачей этого оборудования является, грубо говоря, перенаправление пакетов с одного своего порта, на другой. Это делается при помощи таблицы коммутации, которая создается и поддерживается свичем. В таблице хранятся данные о том, на каком порту устройства находится тот или иной MAC-адрес. Причем ключевым значение в этой таблице является MAC-адрес, то есть к одному MAC-адресу может быть привязан только один порт коммутатора. Вот что, частично, представляет собой таблица свича.
Таблица 1. Часть таблицы коммутации свича 000062-a15e68
0000e8-8d574d
0000e8-d9eba2
0000f0-88be4d
000102-1e4d80
00016c-c88e2a
000244-0f0a2e
000244-0f0a31
000244-0f0a48
000244-303019
000244-3adc8c
000476-9f4a19
000476-9f4a5e
0007e9-4a6851
0007e9-4a867b...

Полный текст
эта (и множество других) атак очень хорошо описаны в... 10.06.06 17:10  
Автор: puh Статус: Незарегистрированный пользователь
<"чистая" ссылка>
эта (и множество других) атак очень хорошо описаны в учебниках циско пресс к курсу Securing Network Routers and Switches (SNRS)
Cisco port security нам поможет! 13.03.06 14:01  
Автор: n2002_2002 Статус: Незарегистрированный пользователь
<"чистая" ссылка>
если на порту меняется MAC-адрес, порт просто уходит в даун. И аттакеры начинают думать - звонить админу или не звонить...

справедливо для коммутаторов Cisco
А если свич не поддерживает порт-секьюрити. Мало того - он... 13.03.06 17:05  
Автор: Eosfor Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> если на порту меняется MAC-адрес, порт просто уходит в
> даун. И аттакеры начинают думать - звонить админу или не
> звонить...

А если свич не поддерживает порт-секьюрити. Мало того - он вообще не управляемый. Мало ли таких свичей? Кроме того, на некоторых конфигурациях и с порт-секьюрити, думаю, возможны проблемы. Например при автообучении и большом пуле допустимых адресов.
А? 03.03.06 17:33  
Автор: offtopic Статус: Незарегистрированный пользователь
<"чистая" ссылка>
А?
http://ettercap.sourceforge.net/forum/viewtopic.php?t=2329

Кстати, на одной из dlink' моделей с настроенным 802.1x через mac dup тянул траф даже не аутентифицировавшись.
Меры защиты те же что и против калссического arp-spoof.
статья вроде нормальная 28.02.06 20:26  
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
<"чистая" ссылка>
port-security никто не отменял
Но увы, не у всех есть такие свичи. При их наличии можно и... 28.02.06 20:45  
Автор: Eosfor Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> port-security никто не отменял
Но увы, не у всех есть такие свичи. При их наличии можно и VLAN-ами разрулить дополнительно. А что делать если их нет? Тогда только тотальное IPSEC.
А вот проверка подлинности IEEE 802.1x не поможет от подобных атак? 01.03.06 06:22  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
насколько я понимаю - нет 01.03.06 15:02  
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
<"чистая" ссылка>
Там ведь нет соответствия MAC-адреса юзернэйму. То есть если у тебя есть хоть один валидный юзернэйм и пароль - то тебя пускают в сетку. А там - меняй маки сколько угодно. И потом - я с трудом представляю себе свитч с поддержкой 802.1x и без port-security. ИМХО тут всё просто. Есть опредеоённые атаки. Есть механизмы предотвращения этих атак. Есть устройства и комплексы, поддерживающие эти механизмы. Хочешь - покупай. Не хочешь - не покупай. Насколько я в курсе, трикомовские свитчи мидл-энд класса вполне поддерживают port-security.
статья обновлена, добавлена реализация 28.02.06 20:07  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
По моему есть более эффективная схема прослушивания с... 28.02.06 12:37  
Автор: svtvl Статус: Незарегистрированный пользователь
<"чистая" ссылка>
По моему есть более эффективная схема прослушивания с использованием 1 компьютера(1 сетевая). Допустим мы перехвативаем трафик между клиентом-сервером(путём изменения таблицы коммутации) и в статье порблемная ситуацияя передавать перехваченные фрэймы обратно клиенту-серверу. Я предлагаю решить так, перехватываем фрэйм меняем в нём МАС назначения на широковещательный и отправляем обратно и всё, ни каких 2 машин и связи между ними.
А Вы уверены, что tcp сессия может быть установлена... 28.02.06 13:58  
Автор: Eosfor Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> перехватываем
> фрэйм меняем в нём МАС назначения на широковещательный и
> отправляем обратно и всё, ни каких 2 машин и связи между
> ними.
А Вы уверены, что tcp сессия может быть установлена широковещательным пакетом?
Сетевая модель OSI почитайте. речь идёт о широковещательном... 01.03.06 06:08  
Автор: svtvl Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> А Вы уверены, что tcp сессия может быть установлена
> широковещательным пакетом?
Сетевая модель OSI почитайте. речь идёт о широковещательном фрэйме, пакет отаётся неизменным.
Тут надо в исходники фтыкать. Так сразу не сказать, как поведёт себя драйвер TCP/IP, приняв на входе широковещательный фрейм... Если бы я его реализовывал, я бы отправил его прямиком туда, где происходит обработка broadcatst & multicast. 01.03.06 06:17  
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 01.03.06 06:20  Количество правок: 1
<"чистая" ссылка>
Насколько я понимаю модель OSI IP/TCP относится к 3/4 уровню... 01.03.06 07:12  
Автор: svtvl Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Насколько я понимаю модель OSI IP/TCP относится к 3/4 уровню модели, а фрэймы относяться ко 2 уровню как и сетевая карта, то есть IP/TCP даже не узнает что фрэйм был широковещательный.
Узнает 01.03.06 11:52  
Автор: Killer{R} <Dmitry> Статус: Elderman
<"чистая" ссылка>
Я уже давно все это перепробовал. TCP пакет посланный с определенного на определенный ип но с броадкастовым маком игнорируется таргетом.
Разработчики ОС часто так не думают -)) 01.03.06 08:47  
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 01.03.06 09:01  Количество правок: 2
<"чистая" ссылка>
> Насколько я понимаю модель OSI IP/TCP относится к 3/4
> уровню модели, а фрэймы относяться ко 2 уровню как и
> сетевая карта, то есть IP/TCP даже не узнает что фрэйм был
> широковещательный.
Данные не перепаковываются, ибо это ущерб производительности. Фрейм Ethernet принимается в буфер памяти и лежит там для передачи всем желающим. Драйвер сетевого интерфейса, прочитав тег протокола во фрейме, просто передаёт указатель на фрейм соотв. драйверу протокола. Драйвер протокола вполне может использовать любые поля фрейма для ускорения своей работы. К примеру, читать теги QoS (есть и такие расширения Ethernet) и давать соотв. приоритет в их обработке. И т.п. И если известно, что фрейм был широковещательный, то драйвер с огромным удовольствием пропихнёт его в то место, где идёт обработка широковещательного траффика. А там только UDP и TCP мультикаст. Т.е. те приложения, которые не подписывались на мултикаст, не должны получать multicast-пакеты. Они их и не получат -))
:-? 15.03.06 22:33  
Автор: KuZia Статус: Незарегистрированный пользователь
<"чистая" ссылка>
>> К примеру, читать теги QoS (есть и такие расширения Ethernet)
:-?
Наверное 8-и байтное поле из хида IP ? То, что ToS byte/DSCP?...
В Ethernet LLC/SNAP есть поле TYPE=2 byte, но не относится оно к "IP CoS/ Network QoS".

Ии.... Очень забавно, в принципе... Как-то очень грубо, можно напильником же: "широковещательного трафика. А там только UDP и TCP мультикаст"

Т.е. 6-ть октетов (byte) D_ADDR в (ETH fr) = FF.FF.FF.FF.FF.FF соответствует "только мультикасту"? О каком уровне говорим?
О "сетевом" или "транспортном"? Зачем тогда, позвольте, Инженеры резервировали "под мультикаст" особый диапазон адресов сетевого уровня? -- 01:00:5E [00:00:00 - 7F:FF:FF]... Уж и не хочется вспоминать, что сим "мультикастом" можно (нужно) управлять на обоих уровнях.

Очень проСИМ, разберитесь, что есть "в то место" и зачем "с огромным удовольствием".

А по тема:
А в целом - все очень интересно. Особенно нравятся картинки (без сарказма).
Это я вообще фантазировал -)) Но факт в том, что в популярных осях обработка фреймов Ethernet и пакетов IP взаимодействует друг с другом, хотя в теории, не должна. 16.03.06 07:31  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
Ммммм... простите но это лажа. тоесть написано все правильно, но... 28.02.06 09:26  
Автор: DamNet <Denis Amelin> Статус: Elderman
<"чистая" ссылка>
человек у которого бы появилась такая задача сам бы я думаю догодался найти схему решения....
не так уж мне кажется это и сложно.....
1  |  2 >>  »  




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach