Сниферы в сети

[Queeq 0]

и вот если первое не достижимо для некоторых сетей ввиду финансовых проблем, то не воспользоваться вторым - просто преступно. вирусы же заставляете на компах у клиентов выводить? почему же не поставить обязательным условием наличие фаера? либо прямо в договоре прописать что в случае если фаер не стоит то пров не несет ответственности.

 

Абсолютно согласен. Кстати интересно, что сказано в законодательстве по этому поводу? Сдаётся мне, что есть что-то про то, что провайдер должен обеспечить безопасность передачи данных пользователя. В таком случае и пункт в договоре окажется незаконным. Прибавить к этому тупость/рассеянность/вредность юзера и можно получить серьёзные проблемы...

 

я к тому что подмена мака не должна приводить к заворачиванию нета на левое лицо.

 

Если у жертвы будет в арп-таблице связка "IP шлюза + мак злоумышленника" - трафик завернётся на комп атакующего. Дело техники уже наладить нормальное взаимодействие между жертвой и шлюзом через свой комп.

 

ИМ, отдельно можно и сделать. совершенно не обязательно при этом подставлять всю сеть. да и такому требующему юзеру важно объяснить чем это грозит и предоставить выбор.

 

Тут можно долго спорить. Может быть ещё куча ситуаций, когда DHCP сильно облегчает жизнь админам. Конечно на тупых свичах его лучше избегать, но опять же - не все могут себе это позволить.

 

либо резервирование будет применено другими менее кривыми способами, так ведь?

 

Это да, но часто всё упирается в финансовую сторону вопроса либо просто неоправданность, например, L3-решения в конкретной ситуации. Более того, L3-резервирование может оказаться ещё кривее, чем STP.

[XoRe 0]

Уважаемые, давайте разделим такие риски, как "инет нахаляву", "лазать в локалке нахаляву", и "тырить данные (с помощью man in the middle)".

 

А то получается, как про сейф:

- от пожара тебе надо несгораемый!

- а от воров мне надо прикрученный к полу!

 

Давайте говорить, какие меры против чего направляются.

 

От "инет нахаляву" спасет vpn или любое другое туннелирование.

 

От "тырить данные" гарантированно спасет только блокировка ip+mac на клиентском порту свича.

Негарантированно помогает публикование арп таблиц на шлюза, да всякие ipguard'ы.

 

От "лазить в локалке нахаляву" спасет отключение клиентского порта.

[Queeq 0]

От "тырить данные" тоже шифрование спасёт. Ну или port-security + arp inspection + dhcp snooping (в случае использования dhcp) на свиче. Но я так понял тут рассматриваются меры, применимые к сети на тупых свичах.

 

От лазанья в локалке спасёт выдёргивание шнурка (обычно)

[niidil 0]

Уважаемые, давайте разделим такие риски, как "инет нахаляву", "лазать в локалке нахаляву", и "тырить данные (с помощью man in the middle)".

Продлегаю рассмотреть ещё один риск - ARP-spoofing клиентских компов, направленный на забивание arp-таблицы клиентов fake'овыми парами IP+MAC.

В результате чего у клиентов начинает глючить интернет и сетка.

 

Очень эфективно может использоваться в конкурентной борьбе.

 

Кстати, кто-нибудь проверял, возможен ли ARP-spoofing, если сеть построена на умных свичах и IP+MAC привязаны кокретномым портам на свичах???

[XoRe 0]

2niidil: возможен.

Просто если с порта пакеты могут выходить только с одного мак адреса, источник арп спуфинга очень быстро палится.

 

Да и вообще арп спуфинг сам по себе быстро определяется.

А так же быстро определяется, стал ли какой-то свич работать, как хаб.

[mos 0]

2niidil: возможен.

Просто если с порта пакеты могут выходить только с одного мак адреса, источник арп спуфинга очень быстро палится.

 

Да и вообще арп спуфинг сам по себе быстро определяется.

А так же быстро определяется, стал ли какой-то свич работать, как хаб.

Вот расскажите, как определить какой свич стал хабом? как хотя бы понять в каком направлении от точки (центра) двигаться для поиска такого свича/юзера?

Для простоты можно предположить, что вся сеть построена по топологии звезда: от центра отходит 6 лучей, каждый из которых по дороге разделяется на 4, а потом еще каждый на 3, которые заканчиваются абонентскими свичами. Все построено на мыльницах. В наличии имеется 2 свича L2 уровня (имеющих весь возможный функционал на этом уровне).

[Queeq 0]

2niidil: возможен.

Просто если с порта пакеты могут выходить только с одного мак адреса, источник арп спуфинга очень быстро палится.

 

Да и вообще арп спуфинг сам по себе быстро определяется.

А так же быстро определяется, стал ли какой-то свич работать, как хаб.

А мне расскажите как выловить арп-спуфинг на умном свиче, если на нём включена только привязка мака и ip к порту, когда легитимный юзер на одном порту генерирует ответы на запросы жертвы с того же свича, при этом в заголовке фрейма source mac ставит свой, mac в арп-пакете тоже свой, а IP-адрес в арп-пакете - шлюза.