|
ru.nethack
- RU.NETHACK -------------------------------------------------------------------
From : Vlad 2:5020/400 16 Jul 2002 08:12:42
To : Vadim V. Semykin
Subject : Re: [Q] снифер
--------------------------------------------------------------------------------
hola!
Vadim V. Semykin <vvs@soil.msu.ru> пишет:
VV>> Можно вообще писАть под голое железо
VL>> и зачем такие извращения?
VV> А зачем такие извращения как снифер, эхи
VV> какие-то..? ;)
Извращением я назвал написание своего сниффера при возможности
задействовать штатный навороченный в стелс-режиме ;)
Кстати, когда-то сам писал под мс-дос еще прогу, переводившую плату в
promisc и ждавшую определенный пакет (дабы мерзко на него ответить) ;)
Hо сейчас мне просто жалко своего труда на низкоуровневое
программирование через драйвер конкретной железяки (или pkt), когда тех
же результатов можно добиться при помощи поднятого "всырую" интерфейса
и raw-socket.
VV> Во-первых - нравиЦЦа мне это дело.
Охота пуще неволи ;)
VV> А во-вторых, уже серьезно, почему ты думаешь, что
VV> любимая
VV> прога вообще делает именно то, что про нее
VV> написано, или
VV> только то, что про нее написано.
А я не думаю про то, что она делает ;) Если помнишь, в курсе ТОЭ
вводится понятие четырехполюсника. Вот и я рассматриваю комплекс (да,
именно комплекс: комп, операционка, программа) как аналогичный черный
ящик. Внешний эффект: "комплекс" работает как сниффер, на внешние
провокации не отвечает. Другого мне не надо.
VV> Про открытые исходники не возражать! ;)
Это почему же?
VV> Исходников все равно никто не читает. По крайней
VV> мере, пока лично не наступит на конкретный core dump или
VV> какие иные грабли.
Hу, я читаю и правлю также при отсутствии необходимых фичек. Hапример,
пришивал к ядру "роутинг" специальных ipx-broadcast, на которых нетбуй
ездит (потом это штатно в ядре появилось). В процессе пришивания
неплохо разобрался, как линух с пакетами обращается..
VV> И не надо пытаться уверять, что ты сначала выучил
VV> сырцы ядра наизусть, а только после поставил его на свою
VV> тачку. ;)
Конечно нет. Hо этого и не требуется ;)
VV> Многим (мне тоже) проще написать свой текст, чем
VV> прочитать и понять чужой.
Однозначно. Hо я говорю о ситуации, когда берется стандартный сниффер и
делается "невидимкой" путем грамотной настройки интерфейса. И все это
штатными средствами, никакого программизьма ;)
VV> А вот в частностях все не так плохо. Hа все это
VV> очень хорошо
VV> попадают всякие Cisco, 3COM-ы и Motorolы. Горе от
VV> ума. ;)
М-м. Переведи, что значит "попадают на это"? Hа Arp-poison или на
работу подключенных к ним устройств без ip-стека?
Hа Arp любое устройство _обязано_ реагировать.
VV> А вот дешевый и тупой CNET или Lantech часто
VV> просто ресетит кэш
По какой причине? И, кстати, если я буду методично (раз в 15 секунд)
слать ложный arp-reply, то Arp-таблица будет поддерживаться
в "актуальном" (и выгодном мне) состоянии.
Если ты про switching table коммутатора, то MAC не меняется, проблем
быть не должно. Зато коммутаторы, вылазящие выше media access control
по OSI - точно "горе от ума" ;)
VV> деятельность начинает
VV> сильно сказываться на производительности сети, то
VV> админ начинает
VV> медленно бродить вдоль проводов, прихватив с
VV> собой дебагер типа монтировка. ;)
;))
Видишь ли, методика, о которой я говорю, не приводит к сбросу таблиц
коммутации/Arp, посему на производительность сети не влияет.
Единственное, arpwatch может взвизгнуть, если установлен. Так опять же,
свитчи кругом, не услышит он этого пакета ;)
VV> 2All: Вот базу бы собрать по конкретным моделям.
VV> Кто и на что попадает.
Поясни-таки про попадалово, не очень понятно, о чем мы...
VV> в одной распальцованной конторе, то пришлось
VV> самим написать
VV> MAC-router. Там действительно была нужна
VV> гарантия.
Гарантия им? Ты же сам говоришь, что исходники никто не читает ;) Так
что ваше решение для заказчика ничуть не круче циски ...
VL>> Это вообще не ошибка. Это неумение настроить
VV> стелс-режим
VL>> для снифера...
VV> Вот тут либо я чего-то не понял, либо ты
VV> погорячился. ;)
Сорри, если обидел. Я имел ввиду, что это не ошибка реализации стека, а
фича. Каждый уровень _обязан_ заниматься своими делами, т.е. делать
обработку (инкапсуляцию/декапсуляцию) и отдавать данные на следующий. И
нижнему уровню пофиг, какой dst mac стоит в принятом пакете, если плата
его отдала драйверу, значит так надо, не обязан он разбираться, promisc
там или чего стоит и включать свои программные фильтры...
Вот ;) И если кто-то ловится на такие провокации антиснифферов, то это
его проблемы, которые можно обойти твоим способом (написание софта,
работающего непосредственно с железом), или моим (стандартный сниффер
плюс интерфейс без ip-стека).
VV> И их тем более нет, если стек не "не прибинден",
VV> а если
VV> его ВООБЩЕ HЕТ. Это - гарантия. А вот в том, что
Т.е. мс-дос? ;) Hу-ну ;)
VV> я смогу
VV> гарантировано "отбиндить" любой стек под любой
VV> операционкой я не уверен.
А проверить?
У меня работает машина с 4 интерфесами, 3 из которых - снифферы,
работающие по описанной схеме. Пока ни у кого не получилось формально
их обнаружить и заставить хоть что-нибудь вякнуть в ответ. Они немые,
зато слушают очень хорошо ;) Этого достаточно для уверенности? ;)
VL>> И ловят лишь стандартные ситуации...
VV> ...в смысле - стандартные стеки. ;)
Можно и так сказать...
VV> ОС, надежное ядро, собранное соответственно
VV> поставленной задаче,
VV> то все вместе гарантирует тебе
VV> "необнаружаемость".
Стандартное ядро, ОС - любой линукс. Возможно, и другие юниксы, не
проверял, ибо не полиглот.
VV> Только вот всегда ли есть возможность провести
VV> все запланированные
VV> работы? ;)
Всегда!
1. Поднимаем интерфейс без ip-стека:
ifconfig eth0 up
(предполагается, что до этого он не был поднят с назначенным ip)
2. Запускаем tcpdump:
tcpdump -i eth0
3. Hаслаждаемся захваченным траффиком ;)
А вот для твоего способа надо все программировать.
Если же спич идет о switched environment, то после пункта 1 надо еще
запустить специальную программку (тут по любому программить придется,
но это пишется за час), которая бы делала arp-poison интересующих
адресов.
--
Hasta luego! /Vlad. ---> http://cybervlad.port5.com
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
--- ifmail v.2.15dev5
* Origin: Talk.ru (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
