|
ru.nethack
- RU.NETHACK -------------------------------------------------------------------
From : Vadim V. Semykin 2:5020/400 17 Jul 2002 21:12:20
To : Vlad
Subject : Re: [Q] снифер
--------------------------------------------------------------------------------
Hi Влад!
Я тут коротко по клавишам потыкаю. Только
про то, что вызывает безусловное возражение 8)
Остальное новым тредом, а то этот разросся..
VL> задействовать штатный навороченный в стелс-режиме ;)
Когда ты пишешь "снифер в стелс-режиме", может сложиться
неправильное впечатление, что есть такой режим и какие-то еще,
и прочее. Кого-то это может запутать. Потом он получит по голове.
Если ты имел в виду работу комплекса снифер+прога для замусоривания
arp-таблиц, кэша комутаторов, еще чего, ну тогда да, формально
можно сказать - работает только снифер - режим чисто пассивный
ака стэлс. Hо тогда открытым текстом и надо было обозначить о чем
речь.
Ситуация проще. Давай и обозначать ее проще:
_снифер_ обнаружить нельзя никак;
можно обнаружить ip-stack, который сидит поверх интерфейса
в promiscue mode и смело предположить, что интерфейс
в этой моде потому, что там еще и снифер;
решение проблемы - ip-stack must die 8)
(аф-фигительной силы лозунг получается ;)
VL> М-м. Переведи, что значит "попадают на это"? Hа Arp-poison
VL> или на работу подключенных к ним устройств без ip-стека?
Hа arp-poison конечно же.
Есть ли где-то там, в дали, ip-stack комутатору по-барабану.
VL> коммутаторы, вылазящие выше media access control
VL> по OSI - точно "горе от ума" ;)
и, формально, уже не комутаторы ;) Под каким бы названием их
не продавали. Hо, зато, они могут попасть на arp-poison ;)
А комутатор не работает ни с чем, кроме маковых адресов.
Поэтому ему и arp (ака протокол разрешения сетевых адресов в
канальные) ему по-барабану.
VL> Hа Arp любое устройство _обязано_ реагировать.
Получается, что не любое. Hо то, которое реагирует -
перспективнее в контексте эхотага ;)
VL> Видишь ли, методика, о которой я говорю...
Методика, о которой ты говоришь, чуть выше по стеку
протоколов. Это тоже стоит обсудить. Hо давай
сначала добьем комутаторы.
VV>> 2All: Вот базу бы собрать по конкретным моделям.
VV>> Кто и на что попадает.
VL> Поясни-таки про попадалово, не очень понятно, о чем мы...
Теперь понятно? 8)
Какие комутаторы вылезают за канальный уровень, чтобы
соптимизировать и суметь прошвырнуть чуть больше пакетов
в секунду чем аналогичная модель другого производителя.
А от того имеют кучу багов эхотажных.
VV>> самим написать
VV>> MAC-router. Там действительно была нужна
VV>> гарантия.
VL> Гарантия им? Ты же сам говоришь, что исходники никто не читает ;)
Так
VL> что ваше решение для заказчика ничуть не круче циски ...
Hе круче. Hо дешевле. Для заказчика.
И исходные тексты им пофигу. Зачем им исходные тексты,
если у них есть паспортные данные автора? ;)
VL>>> Это вообще не ошибка. Это неумение настроить
VV>>> стелс-режим для снифера...
VV>> Вот тут либо я чего-то не понял, либо ты
VV>> погорячился. ;)
VL> Сорри, если обидел.
Hе. Я не об этом. См. выше.
Я о том, что ты, когда говоришь "снифер", постоянно имеешь в виду
целый пакет тулзов. А я говорю только о собственно "снифере" ака
дампере пролетающих пакетов в лог. А он, сам по себе, стелс,
поскольку в сети ничего не делает.
VL> Я имел ввиду, что это не ошибка реализации стека
Тут полное совпадение позиций ;)
VL> Т.е. мс-дос? ;) Hу-ну ;)
Да чем же плох самый продвинутый в мире загрузчик? ;)
By!
--- ifmail v.2.15dev5
* Origin: As is (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
