windows_NT Опубликовано 26 августа, 2009 · Жалоба В локалке есть несколько машин которые подхватили вирусню которая делает arp-spoof соседих компов и шлюза эти компы включены все в DES-3526. Вопросы Может ли этот свич впринципе убрать возможность arp-spoof с клиентской стороны на всех портах ? Можно ли на этом свиче от Arp-spoof защитить исключительно один порт в который воткнут шлюз, чтобы в него левые ответы не сыпались а шли только легальные, а все остальные оставить как есть ?? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
spruce Опубликовано 26 августа, 2009 (изменено) · Жалоба В локалке есть несколько машин которые подхватили вирусню которая делает arp-spoof соседих компов и шлюзаэти компы включены все в DES-3526. Вопросы Может ли этот свич впринципе убрать возможность arp-spoof с клиентской стороны на всех портах ? Можно ли на этом свиче от Arp-spoof защитить исключительно один порт в который воткнут шлюз, чтобы в него левые ответы не сыпались а шли только легальные, а все остальные оставить как есть ?? ARP-spoofing prevention используйте, помогает. если нет такой функции, обновите прошивку на последнюю. Изменено 26 августа, 2009 пользователем spruce Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Valaskor Опубликовано 27 августа, 2009 (изменено) · Жалоба ARP-spoofing prevention, если не ошибаюсь, защищает только сам свитч. Через acl вижу два варианта: 1. Если нужно защитить все: Через acl или ip-mac-port-binding-acl-mode на каждом порту разрешается arp с адресом соответствующего компа. Если такой комп заразится, спуфить он не сможет. Минус в том, что долго все это настраивать и сложно поддерживать в рабочем состоянии. 2. Если нужно защитить только роутер, а обмен между компьютерами неважен, то на каждый порт, кроме шлюза, вешаются одинаковые acl, дропающие arp пакеты с адресом шлюза. В результате перехават от компьютера к шлюзу исключен. На случай попытки перехвата от шлюза к компьютерам на шлюзе нужна будет статитческая arp-таблица. Изменено 27 августа, 2009 пользователем Valaskor Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
terrible Опубликовано 27 августа, 2009 (изменено) · Жалоба ARP-spoofing prevention, если не ошибаюсь, защищает только сам свитч.ошибаетесьЭтот механизм позволяет отфильтровать пакеты абонента, в случае, если абонент устанавливает IP и/или MAC принадлежащий другим компьютерам его подсети. Очень хорошо работает на клиентских портах для предотвращения спуфинга шлюзов и серверов. А по поводу IMB ACL верно, это и нужно автору, настраивается быстро и удобно, не знаю, в чём у вас проблемы. 2-й пункт неверно, неосмысленно, тут на уровне PCF нужны ACL Изменено 27 августа, 2009 пользователем terrible Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kaban Опубликовано 27 августа, 2009 (изменено) · Жалоба http://forum.dlink.ru/viewtopic.php?t=4949...p;postorder=asc Еще один из хороших вариантов борьбы с arp spoof-ингом заключается в: 1. блокировке на всех клиентских портах arp reply пакетов с помощью packet_content ACL 2. поднятие в сети сервера который будет вместо клиентов отвечать на arp запросы из своей базы (которая может задаватся статически или динамически из dhcp сервера) Преимущества очевидны - на всех коммутаторах однотипный конфиг ACL-й. Фактически мы при этом сами начинаем заниматся arp spoof-ингом, но правильным и централизовано контролируемым из одного места. Изменено 27 августа, 2009 пользователем Kaban Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[GP]Villi Опубликовано 27 августа, 2009 (изменено) · Жалоба а в каком софте реализуется второй пункт, второго варианта? (freebsd вариант с public записью в arp?) и возможна ли такая связка, сначала клиент получает по opt82 айпишник, мак заносится в базу и потом сервер начинает им отвечать. как только истекает lease, из базы удаляется? Изменено 27 августа, 2009 пользователем [GP]Villi Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Valaskor Опубликовано 28 августа, 2009 · Жалоба а в каком софте реализуется второй пункт, второго варианта? (freebsd вариант с public записью в arp?) и возможна ли такая связка, сначала клиент получает по opt82 айпишник, мак заносится в базу и потом сервер начинает им отвечать. как только истекает lease, из базы удаляется? в более-менее свежем софте, des-3526 может биндить IP-порт через dhcp-snooping. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[GP]Villi Опубликовано 28 августа, 2009 · Жалоба вы вопрос хотя бы прочитали что ли повнимательнее, и предыдущее перед вопросом сообщение. Kaban, таки комментарии будут?) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
terrible Опубликовано 28 августа, 2009 (изменено) · Жалоба А что если вот так правила сделать: 1) настроить ARP Spoofing Prevention 2) разрешить обращаться к мак-адресу шлюза 3) запретить по всем протоколам обращение ко всем остальным макам в итоге получим сгементацию на портах и защитим шлюз Я так сделал в одном не очень благополучном сегменте, работает отлично. Изменено 28 августа, 2009 пользователем terrible Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kaban Опубликовано 28 августа, 2009 · Жалоба в более-менее свежем софте, des-3526 может биндить IP-порт через dhcp-snooping. Оно глюкавое, по крайней мере в последних прошивках что доступны сейчас. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kaban Опубликовано 28 августа, 2009 · Жалоба [GP]Villi: arp с ключиком pub теоретически должен это делать. Как на практике - х.з., не проверял. Написать arp сервер отвечающий на arp запросы большого труда не составит, работы на день-два. Относительно второго вопроса, то тут уж все зависит от оеализации dhcp сервера, если удастся его настроить на запуск скриптов при выдаче IP и при его освобождении, то работать будет. Лично я пользуюсь самописным dhcp сервером, там это можно сделать, а при использовании ISC dhcp думаю без напильника не обойтись. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[GP]Villi Опубликовано 29 августа, 2009 · Жалоба как я понимаю если бы работал нормально dhcp snoop то этого не потребовалось бы. или он не распространяется на арп? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kaban Опубликовано 29 августа, 2009 · Жалоба распостраняется. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[GP]Villi Опубликовано 29 августа, 2009 · Жалоба но глючит) я в такой ситуации рассматривал, dhcp snoop + traff_segm + /32 на клиента. тогда весь трафик ходит через л3, никто никому нагадить не может, единственное что клиент может нагадить шлюзу, но по идее от этого должен спасти snoop. жаль что недоработан пока. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kaban Опубликовано 29 августа, 2009 · Жалоба Спасти от манипуляций с подменой МАК-а шлюза в ARP-ах можно с помощью arp_spoofing_prevention, который есть фактически макрос создающий ACL-и фильтрующие кривые ARP-ы. Однако есть и некоторые минусы - при смене МАК-а шлюза надо менять конфигурацию свичей, плюс это не спасает от ARP spoofing-а когда два клиента работают друг с другом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[GP]Villi Опубликовано 30 августа, 2009 · Жалоба таки snooping же спасать шлюз должен. а клиенты не могут работать напрямую, у них /32 и видят они только аплинк-порт, обычно это 26. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kaban Опубликовано 30 августа, 2009 · Жалоба Клинетам можно раздавать маску /24, и если на шлюзе поднять proxy-arp то создастся полный эффект локалки, но с полной изоляцией клиентов с помощью vlan-ов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ingress Опубликовано 30 августа, 2009 · Жалоба Спасти от манипуляций с подменой МАК-а шлюза в ARP-ах можно с помощью arp_spoofing_prevention, который есть фактически макрос создающий ACL-и фильтрующие кривые ARP-ы. Однако есть и некоторые минусы - при смене МАК-а шлюза надо менять конфигурацию свичей, плюс это не спасает от ARP spoofing-а когда два клиента работают друг с другом. совершенно неэффективное решение. для полной защиты от арпспуфинга, достаточно разрешать в на порте правильный Sender IP внутри ARP Reply, никаких мак адресов не надо учитывать. это бред. пакет всё равно отбросится потому что Sender IP неправильный, зачем при этом в нём учитывать ещё и Sender MAC Address? a если клиент поставит мак адрес другого клиента или шлюза, ACL от мак флапа не спасёт, ибо MAC Learning действует отдельно от ACL. от этого может помочь auto_fdb(костыль придуманный для другого ;) ) а чтобы реализовать только защиту шлюза достаточно запретить в ARP Reply на всех портах одну цифру уникальную в Sender IP(шлюзы обычно заканчиваются на конкретную цифру .254 и .1 в общих случаях) и IP протокол так же. для этого достаточно два профиля и два правила PCF, и на 24 порта это ест 48 правил(в 3028). а arp_spoofing_prevention жрёт при этом бОльшую часть правил, при минимальной гибкости. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kaban Опубликовано 30 августа, 2009 (изменено) · Жалоба для полной защиты от арпспуфинга, достаточно разрешать в на порте правильный Sender IP внутри ARP Reply, никаких мак адресов не надо учитывать. не совсем так, если внимательно посмотреть на структуру ARP ответа то там внутри кроме IP еще есть и МАК, и для полной защиты от arp спуфинга его тоже нужно контролировать, т.к. именно эта комбинация потом и попадает в ARP кеш клиентам. Во всем остальном, полностью согласен. Изменено 30 августа, 2009 пользователем Kaban Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ingress Опубликовано 30 августа, 2009 · Жалоба ещё раз повторяюсь - зачем? неправильный мак с правильным IP(который только разрешён) придёт - и что спуфим в арпкеше шлюза(или другого компьютера) в таком случае? себе(хосту который атакует) связность рушим? если вам нужен практический пример то хост с ettercap не может перехватить трафик между двумя хостами если к порту приложено три правила PCF(Sender IP в ARP Reply), IP(против IP спуфинга) и Ethernet (рубящий всё остальное). проверял. не подделывает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kaban Опубликовано 30 августа, 2009 · Жалоба Таки да. Полностью согласен. А что делать когда вместо статических IP используются к динамические ? Прикручивать к dhcp серверу модуль который по SNMP создает/удаляет правила на свиче ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[GP]Villi Опубликовано 30 августа, 2009 · Жалоба долбить длинк чтобы доделывали snooping ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
windows_NT Опубликовано 30 августа, 2009 · Жалоба используеться динамика с dhcp :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Say Опубликовано 27 ноября, 2009 · Жалоба На форуме DLink'а задал вопрос о поддеркже DAI (со связкой с dhcp snooping), получил сл. ответ: Есть некая аналогия этого режима. Фактически это режим strict функции IMP. В чистом виде dynamic ARP Inspection реализован в серии DES-3528/3552. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tgz Опубликовано 27 ноября, 2009 · Жалоба Домонеты и дылинк. Часть 256-ая. Пурген - лучшее средство от кашля. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...