Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | |
Re: у вас ещё ХАБЫ в сетке 28.02.06 10:41 Число просмотров: 3760
Автор: leo <Леонид Юрьев> Статус: Elderman
|
Ну если сетка на hub-ах, то и делать ничего не надо, весь трафик доступен просто так. Это конечно "лучше" :)
В статье IMHO ничего особенного, для раздела "ликбез" в самый раз. Все описываемые "эффекты" очень давно извесны и исследованы, как правило реально с их помощью ничего не добиться.
|
|
<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
|
человек у которого бы появилась такая задача сам бы я думаю догодался найти схему решения....
не так уж мне кажется это и сложно.....
|
|
|
подробно о проекте
Анализ криптографических сетевых...
