ARP-spoofing и методы борьбы с ним

>_<`

отличная статья для новичков =)

я в свое время делал все через arpwatch.

где же ленин? он, помнится, не верил в арп спуфинг

>я в свое время делал все через arpwatch.

Предпочитаешь не предотвращать, а решать проблемы по факту их возникновения?

а интересный сайт
респект

tnx , интересно .

такое детям показывать нельзя :)

отличная статья - респект !

Замечено. Раз в пару лет обязательно появляется подобная статья про атаки на Ethernet. Нового в них ни чего нет уже лет 10. Все дружно ахают и ... все. Через пару лет будет еще подобная статья.

Самое смешное, что автор для борьбы с ARP-spoofing предлагает использовать такой же небезопасный SNMP v2. Воистину - Тришкин кафтан - натянули на локти, коленки оголились.

Пара поправок:
1. Местами лучше "пакеты" заменить на "кадры" (таки 2-й уровень).
2. Выдрать с корнем слово "хост" и заменить на "узел" (таки русский язык).

:-) В остальном хорошая статья. Еще не дочитал, но про атаки на сами коммутаторы ни слова, равно как и про опцию управляемых коммутаторов "Port security".

>> Методы предотвращения - Статический ARP

Гы. Так тогда человек пришедший с ноутом и пытающийся по DHCP получить адрес отправится в пешее эротическое? Удобно, ничего не скажешь.

Про VLAN-ы:

> Данные не шифруются, и производительность не теряется. Малые потери на дополнительные поля в заголовке.

Если малые потери и есть, то только на шлюзе, а не на коммутаторе, да и то сомнительно, что они будут на шлюзе (если использовать правильную сетевую плату).

> Нельзя организовать обмен данными в обход шлюза между хостами в разных VLAN'ах. Если каждый хост находится в собственном VLAN'е такой обмен невозможен вообще.

VLAN не имеет отношения к технологиям обеспечения безопасности и по этой причине большинство современных коммутаторов замечательно разрешают обмен.

>> Методы предотвращения - Статический ARP

> Гы. Так тогда человек пришедший с ноутом и пытающийся по DHCP получить адрес отправится в пешее эротическое? Удобно, ничего не скажешь.

Туда ему и дорога, если его MAC заранее не попал в статическую ARP таблицу (если речь не идет о публично доступных сетях, как в Internet-кафе).

1.use SNMP v3
2.use switchport port-security ..

> Использование PPPoE

Не проще ли настроить IPSEC, чем гонять PPP по езернету?

А если вместо предлагаемых в статье патчей для ядер Linux-BSD, которые перепроверяют узконаправленные arp-сообщения (путем перепосылки широковещательного arp-запроса), просто запретить реагировать на узконаправленные сообщения (ну регистрировать их только). То есть менять arp-таблицу только при приеме широковещательного arp-сообщения?

Какого типа arp-ответы посылают нынешние OS? Узконаправленные или широковещательные? Ведь в реальной ethernet-сети (шина, глупые мосты -- в общем без коммутаторов) выигрыша в использовании узконаправленного ответа вместо широковещательного никакого нет.

Или arp-ответ по своей структуре может быть только узконаправленным? И понятия broadcast-arp-ответ не существует? Вряд ли.. Ведь говориться же в статье о посылке arp-ответов сразу же после получения IP по DHCP, чтоб проверить конфликты в сети по IP (один IP, несколько MAC)

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

с ув. Анонимуз

2 dreamer & saper 
насчет порт секурити .
http://xgu.ru/w/index.php?title=ARP-spoofing&action=edit&section=26

> А если вместо предлагаемых в статье патчей для ядер Linux-BSD, 
которые перепроверяют узконаправленные arp-сообщения (путем 
перепосылки широковещательного arp-запроса), просто запретить 
реагировать на узконаправленные сообщения (ну регистрировать их 
только). То есть менять arp-таблицу только при приеме 
широковещательного arp-сообщения?

Что мешает атакующему подделать широковещательный ARP? 

Кстати, Linux по умолчанию игнорирует ARP-ответы на которые не были 
отправлены ARP-запросы и широковещательные ARP, эдакая простенькая 
защита от отравления ARP-кеша:

arp_accept - BOOLEAN
        Define behavior when gratuitous arp replies are received:
        0 - drop gratuitous arp frames
        1 - accept gratuitous arp frames

Правда, если нападающий будет постоянно отправлять подделанные ARP-
ответы, то система может их принять в ответ на ARP-запрос.

Как было выяснено экспериментальным путем на 2.6.18 и 2.6.20 настройка arp_accept не работает, даже с arp_accept=0 линукс радостно засовывает в ARP-кеш маки из фейковых широковещательных ARP...

вот вот , и поэтому наверное так легко отнять у linux ip адрес назначив его другому компу .

> Пара поправок: > 1. Местами лучше "пакеты" заменить на "кадры" (таки 2-й уровень). > 2. Выдрать с корнем слово "хост" и заменить на "узел" (таки русский язык).

> :-) В остальном хорошая статья. Еще не дочитал, но про атаки на сами коммутаторы ни слова, равно как и про опцию управляемых коммутаторов "Port security".

1. Выдрать с корнем слово "опция" и заменить на "параметр", "пункт меню", "ключ", "режим" или "возможность" по контексту (таки русский язык).

2. Статью дочитываю, но добавил бы еще к приведенному посту, что не "спуфинг", а "подмена" (см. микрософтовские статьи по безопасности, правда, иногда какой-то баран переводит как "подделка").

угу вы еще glibc русифицируйте :)

защиты от спуфинга кроме коммутаторов с аппаратной привязкой мака на порт - нет.

>защиты от спуфинга кроме коммутаторов с аппаратной привязкой мака на порт - нет.

RTFM, для ARP-спуфинга не требуется смена MAC-адреса.

блин выше ошибся дал не ту линку
2 dreamer & saper
вот правильная линка
http://xgu.ru/wiki/ARP-spoofing#.D0.9C.D0.B8.D1.84.D1.8B_.D0.B8_.D0.B7.D0.B0.D0.
B1.D0.BB.D1.83.D0.B6.D0.B4.D0.B5.D0.BD.D0.B8.D1.8F.2C_.D0.BA.D0.B0.D1.81.D0.B0.D
1.8E.D1.89.D0.B8.D0.B5.D1.81.D1.8F_ARP-spoofing
для ТРУ лоровцев .

При ARP-spoofing'е MAC-адрес отправителя (атакующего) не меняется и поэтому с точки зрения port-security никаких аномалий нет.Функция port-security никак не отвечает за соответствие IP-адресов и MAC-адресов, а атака ARP-spoofing построена именно на этом.

> угу вы еще glibc русифицируйте :)

Вот ответ истинного москвича! Именно поэтому языковая группа Микрософта сидит в Дублине, а не в Москве, и технический русский язык в области информационных технологий состоит не только из транслитераций, как хотелось бы издателям московских компьютерных журналов (и продвинутым специалистам наподобие г-на или г-жи j262)!

А теперь серьезно: нечего засорять русский язык транслитерациями (даже не заимствованными словами), если ведущие игроки рынка этих транслитераций не используют. Похоже, что некоторым из пишущих здесь очень хочется, чтобы их поняли не все, а то большинство, которое не поймет, более охотно расставалось со своими денежками в обмен на "наукообразную" речь, на 90% состоящую из транслитерированных слов. Увы, господа, такая практика приводит не к увеличению дохода, а к оттоку клиентов, и Микрософт был ПЕРВЫМ, кто это понял. Рекомендую присмотреться к их опыту, иначе домохозяйки НИКОГДА не будут пользоваться тем программным обеспечением, которое нравится нам.

> угу вы еще glibc русифицируйте :)

>> ...технический русский язык в области информационных технологий...

технический русский,

технический украинский,

технический якутский,

технический бурятский,

технический мефодий, технический кириллий ...

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

>> угу вы еще glibc русифицируйте :)

>>> ...технический русский язык в области информационных технологий...

>технический русский,

-- имеется (создан М.В.Ломоносовым)!!!

>технический украинский,

-- создается, правда, c колоссальными проблемами (полазайте по украиноязысным форумам - увидите этот процесс во всем его великолепии)!!!

>технический якутский,

>технический бурятский,

-- эти страны вместе с оккупированной Тувой могут после завоевания независимости :-E| пользоваться техническим монгольским с минимальными изменениями

> технический мефодий, технический кириллий ...

-- после появления независимых Мефодляндии и Кирилляндии (в результате очередной гражданской войны в бывшей Югославии??? 8-(((0))) ) появятся очень быстро.

> очень хочется, чтобы поняли все -- не надо с... против ветра

-- вот и я о том же, уважаемый господин москвич, забывший русский язык (или никогда не знавший его).

ТЕХНИЧЕСКИЙ ЯЗЫК = ТЕХНОЛОГИЧЕСКОЕ МЫШЛЕНИЕ НАЦИОНАЛЬНЫХ СПЕЦИАЛИСТОВ, не надо об этом забывать. Введение искусственных чешского и словацкого языков откинуло технологический прогресс в Чехии и Словакии как минимум на век назад, если не навсегда, так как вместе со старым (немецким) языком, на котором страна говорила 500 лет, была утеряна интуиция местных инженеров и прервалась связь поколений. Чешских инженеров уровня Николы Тесла сейчас нет и не предвидится, и среди импортируемых США технических специалистов доля чехов минимальна. В этом плане гениальная задумка венского двора сработала на все 100%; сейчас мы то же самое (задуманное 130 лет назад тем же венским императорским двором :-((( ) видим на Украине, результат вполне предсказуем (Штатам, Европе, России и даже Индии с Бразилией Украина, увы, уже не конкурент, про Китай скорбно промолчим). Так что не лейте воду на мельницу тех, кто хотел бы уничтожить российскую техническую и научную школы навсегда, а таких, увы, немало.

насчет Москвы вы немного ошиблись , я родился и живу в Тбилиси :)
насчет всего остального даже незнаю , может быть вы и правы , но сфера IT подразумевает чуть ли не нативное ( родное что-ли ) понимание английского языка . и лично мне , часто трудно что-либо обьяснить на чистом русском , так как читаю английскую документацию и некоторые понятия/предметы ассоциирую с английскими словами .

а по теме , как быть с тем , что IP отнимается у linux если в сети появляется другая машина с таким-же ip ?

>> Нельзя организовать обмен данными в обход шлюза между хостами в разных VLAN'ах. Если каждый хост находится в собственном VLAN'е такой обмен невозможен вообще.

>VLAN не имеет отношения к технологиям обеспечения безопасности и по этой причине большинство современных коммутаторов замечательно разрешают обмен.

не путайте 802.1q и port-based vlan.

> насчет Москвы вы немного ошиблись , я родился и живу в Тбилиси :)

Примите мои соболезнования по поводу технического грузинского: мне кажется, предыдущие правители Грузии начиная с Гамсахурдии (если не раньше :-((( ) выдрали его с корнем и залили землю соляркой, чтобы на этом месте ничего не выросло. А была же когла-то в Тбилиси национальная школа функционального анализа и математической физики!!!...

>> часто трудно что-либо обьяснить на чистом русском , так как читаю английскую документацию и некоторые понятия/предметы ассоциирую с английскими словами.

Страшно то, что при чтении документации не возникает ассоциаций со словами РОДНОГО языка (у Вас это может быть картвельский, мингрельский, сванский, русский и т.п.). Могу только посочувствовать, если Ваш родной язык не русский, поскольку Микрософту и другим крупным поставщикам ПО на языки Грузии абсолютно наплевать, им скорее будет интересен курдский, поскольку на грузинских языках (разных :-( ) говорит, по оптимистичным оценками, 2 млн человек, а на курдском 20 млн, и среди этих 2 млн точно не найти команду, способную толково разработать основы языка для ИТ.

опять ошибаетесь :) есть грузинская локализация форточек , есть проэкты по грузинизации GNU софта например http://www.gia.ge/

зы кстати кому сдался microsoft ? тут даже в школах стоят linux ( правда нихера не учат)

и наконец кому сдался грузинскии windows ? домохозяики меня не волнуют это их половые проблемы .

пару лет назад когда я учился в универе тут были старые советские преподователи математики и физики и imho уровень преподования был отличный ( математики и физики ) .

зы кстати как будет по русски дивергенция , градиент , ротор ?
мне кажется вас никто не поймет :)

кароче это все оффтопик .

и имхо не там вы видите проблемы .

> не путайте 802.1q и port-based vlan.

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

>> не путайте 802.1q и port-based vlan.

>Поправьте, где я ошибся в своем высказывании?

"большинство современных коммутаторов замечательно разрешают обмен."

в случае port-based между портам обмена нет. весь трафик идёт на шлюз и через него роутится. отсюда полный контроль трафика.

>RTFM, для ARP-спуфинга не требуется смена MAC-адреса.

мозг используй после привязки конкретного мака к конкретному порту коммутатору становится глубоко пофигу на арп пакеты и их можно вообще не пропускать и отсюда вообще ни какие виды арп атак уже не возможны

> мозг используй после привязки конкретного мака к конкретному порту коммутатору становится глубоко пофигу на арп пакеты и их можно вообще не пропускать и отсюда вообще ни какие виды арп атак уже не возможны

Ты чо, совсем? А как остальные хосты без ARP узнают на какой езернет адрес слать пакеты для конкретного IP в подсети?

> домохозяики меня не волнуют это их половые проблемы .

1. Покуда 80% пользователей использует Микрософт, игнорировать их, мягко говоря, недальновидно, ведь именно эти пользователи определяют формирование отраслевого языка: большинство терминов, не принятых Микрософтом (а фильтрация словаря у них до последнего времени делалась чрезвычайно грамотно и с уважением к русскому языку), обречено на обращение только в узком кругу так называемых "посвященных" и наа игнорирование массами пользователей.

2. Пока домохозяйки обеспечивают Микрософту 80% доходов от продажи операционных систем общего назначения. Если вас этот рынок не волнует, то Вы сдались Микрософту без боя. Однако лично МЕНЯ домохозяйки допрашивали по вопросам и более замысловатым, чем тот, которому посвящена обсуждаемая статья. Сейчас у некоторых домохозяек стоит для работы в Интернете не что нибудь, а OpenSolaris 11 - сам видел (не лень же было выкачивать, да видно, круто вирусы достали, и человек решил перестраховаться...).

> кому сдался грузинскии windows ?

Ну и пессимист же Вы, батенька!!! Если господину Саакашвили и его соратникам он не сдался, то о перспективах грузинской культуры можно только плакать, так как на самом деле на нее всем наплевать. Ваши слова о Линуксе, на котором ни хрена не учат, это только подтверждают.

> "большинство современных коммутаторов замечательно разрешают обмен."

> в случае port-based между портам обмена нет. весь трафик идёт на шлюз и через него роутится. отсюда полный контроль трафика.

Вы не правы, если мой PC подключен к порту, который помещен в VLAN5, то я свободно (на большинстве современных коммутаторов) отправлю пакет станции в VLAN7 без участия шлюза (VLAN с номерами 5 и 7 тут для примера). Использовать VLAN как технологию обеспечения безопасности достаточно глупо, VLAN допустима только как дополнительная мера защиты, но не её основа, увы.

В статье можно добавить, что в случае использования VLAN потребуется дополнительная защита коммутаторов, т.к. нужно защищаться от перетыкания кабелей между розетками коммутатора (MAC и IP узнать с соседнего порта, да и подменить не сложно, в т.ч. и в Windows).

> Вы не правы, если мой PC подключен к порту, который помещен в VLAN5, то я свободно (на большинстве современных коммутаторов) отправлю пакет станции в VLAN7 без участия шлюза (VLAN с номерами 5 и 7 тут для примера). Использовать VLAN как технологию обеспечения безопасности достаточно глупо, VLAN допустима только как дополнительная мера защиты, но не её основа, увы.

расскажите физику процесса. особенно интересен случай с port-based vlan.

Зачем вы так упираете на термин "port-based vlan"? Чем он отличается для современных коммутаторов от VLAN с использованием 802.1q? Ведь в случае "port-based vlan" шлюз все равно подключается по 802.1q.

Кратко так: находясь в VLAN5 я отправлю кадр с тэгом VLAN7 и он дойдет до получателя.

> Зачем вы так упираете на термин "port-based vlan"? Чем он отличается для современных коммутаторов от VLAN с использованием 802.1q? Ведь в случае "port-based vlan" шлюз все равно подключается по 802.1q.

совершенно не обязательно 802.1q

>Кратко так: находясь в VLAN5 я отправлю кадр с тэгом VLAN7 и он дойдет до получателя.

подскажите модель которая с untagged порта выпустит tagged пакет, да ещё и воспримет его как руководство к действию.

> подскажите модель

Это уже лишнее ;-)

> совершенно не обязательно 802.1q

4000 сетевух воткнуть? ;-) Или есть сетевухи с поддержкой VLT/ISL? Ведь в статье говорится и вы говорили про так называемый C-VLAN, когда каждая станция в своем уникальном (как я понял) виртуальном сегменте.

>Вы не правы, если мой PC подключен к порту, который помещен в VLAN5

ага, то есть имеем ацессный порт с vid=5

>то я свободно (на большинстве современных коммутаторов) отправлю пакет станции в VLAN7

проверил на catalyst 2960. не работает. что я делаю не так? :)

Скажите, на какой модели какого вендора вдув в ацессный порт dot1q фрейм он окажется в нужном вилане?(да, можно сказать switchport mode dynamic, но тогда вопрос кардинально меняется).

> проверил на catalyst 2960. не работает. что я делаю не так?

Как проверяли? Для Cisco в ряде случаев потребуется двойная инкапсуляция. Не самая полная статья по проблеме тут: http://www.askapache.com/security/bypassing-vlan.html