Jump to content
Калькуляторы

как зафильтровать arp DES-3526

В локалке есть несколько машин которые подхватили вирусню которая делает arp-spoof соседих компов и шлюза

эти компы включены все в DES-3526.

 

Вопросы

 

Может ли этот свич впринципе убрать возможность arp-spoof с клиентской стороны на всех портах ?

 

Можно ли на этом свиче от Arp-spoof защитить исключительно один порт в который воткнут шлюз, чтобы в него левые ответы не сыпались а шли только легальные, а все остальные оставить как есть ??

Share this post


Link to post
Share on other sites
В локалке есть несколько машин которые подхватили вирусню которая делает arp-spoof соседих компов и шлюза

эти компы включены все в DES-3526.

 

Вопросы

 

Может ли этот свич впринципе убрать возможность arp-spoof с клиентской стороны на всех портах ?

 

Можно ли на этом свиче от Arp-spoof защитить исключительно один порт в который воткнут шлюз, чтобы в него левые ответы не сыпались а шли только легальные, а все остальные оставить как есть ??

ARP-spoofing prevention используйте, помогает. если нет такой функции, обновите прошивку на последнюю.
Edited by spruce

Share this post


Link to post
Share on other sites

ARP-spoofing prevention, если не ошибаюсь, защищает только сам свитч.

Через acl вижу два варианта:

1. Если нужно защитить все: Через acl или ip-mac-port-binding-acl-mode на каждом порту разрешается arp с адресом соответствующего компа. Если такой комп заразится, спуфить он не сможет. Минус в том, что долго все это настраивать и сложно поддерживать в рабочем состоянии.

2. Если нужно защитить только роутер, а обмен между компьютерами неважен, то на каждый порт, кроме шлюза, вешаются одинаковые acl, дропающие arp пакеты с адресом шлюза. В результате перехават от компьютера к шлюзу исключен. На случай попытки перехвата от шлюза к компьютерам на шлюзе нужна будет статитческая arp-таблица.

Edited by Valaskor

Share this post


Link to post
Share on other sites
ARP-spoofing prevention, если не ошибаюсь, защищает только сам свитч.
ошибаетесь

Этот механизм позволяет отфильтровать пакеты абонента, в случае, если абонент устанавливает IP и/или MAC принадлежащий другим компьютерам его подсети.

Очень хорошо работает на клиентских портах для предотвращения спуфинга шлюзов и серверов.

 

А по поводу IMB ACL верно, это и нужно автору, настраивается быстро и удобно, не знаю, в чём у вас проблемы.

 

2-й пункт неверно, неосмысленно, тут на уровне PCF нужны ACL

Edited by terrible

Share this post


Link to post
Share on other sites

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-ингом, но правильным и централизовано контролируемым из одного места.

Edited by Kaban

Share this post


Link to post
Share on other sites

а в каком софте реализуется второй пункт, второго варианта? (freebsd вариант с public записью в arp?)

 

и возможна ли такая связка, сначала клиент получает по opt82 айпишник, мак заносится в базу и потом сервер начинает им отвечать. как только истекает lease, из базы удаляется?

Edited by [GP]Villi

Share this post


Link to post
Share on other sites

а в каком софте реализуется второй пункт, второго варианта? (freebsd вариант с public записью в arp?)

 

и возможна ли такая связка, сначала клиент получает по opt82 айпишник, мак заносится в базу и потом сервер начинает им отвечать. как только истекает lease, из базы удаляется?

в более-менее свежем софте, des-3526 может биндить IP-порт через dhcp-snooping.

Share this post


Link to post
Share on other sites

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

 

Kaban, таки комментарии будут?)

Share this post


Link to post
Share on other sites

А что если вот так правила сделать:

 

1) настроить ARP Spoofing Prevention

2) разрешить обращаться к мак-адресу шлюза

3) запретить по всем протоколам обращение ко всем остальным макам

 

в итоге получим сгементацию на портах и защитим шлюз

 

Я так сделал в одном не очень благополучном сегменте, работает отлично.

Edited by terrible

Share this post


Link to post
Share on other sites
в более-менее свежем софте, des-3526 может биндить IP-порт через dhcp-snooping.

Оно глюкавое, по крайней мере в последних прошивках что доступны сейчас.

Share this post


Link to post
Share on other sites

[GP]Villi:

 

arp с ключиком pub теоретически должен это делать. Как на практике - х.з., не проверял. Написать arp сервер отвечающий на arp запросы большого труда не составит, работы на день-два.

 

Относительно второго вопроса, то тут уж все зависит от оеализации dhcp сервера, если удастся его настроить на запуск скриптов при выдаче IP и при его освобождении, то работать будет. Лично я пользуюсь самописным dhcp сервером, там это можно сделать, а при использовании ISC dhcp думаю без напильника не обойтись.

Share this post


Link to post
Share on other sites

как я понимаю если бы работал нормально dhcp snoop то этого не потребовалось бы. или он не распространяется на арп?

Share this post


Link to post
Share on other sites

распостраняется.

Share this post


Link to post
Share on other sites

но глючит)

я в такой ситуации рассматривал, dhcp snoop + traff_segm + /32 на клиента. тогда весь трафик ходит через л3, никто никому нагадить не может, единственное что клиент может нагадить шлюзу, но по идее от этого должен спасти snoop. жаль что недоработан пока.

Share this post


Link to post
Share on other sites

Спасти от манипуляций с подменой МАК-а шлюза в ARP-ах можно с помощью arp_spoofing_prevention, который есть фактически макрос создающий ACL-и фильтрующие кривые ARP-ы. Однако есть и некоторые минусы - при смене МАК-а шлюза надо менять конфигурацию свичей, плюс это не спасает от ARP spoofing-а когда два клиента работают друг с другом.

Share this post


Link to post
Share on other sites

таки snooping же спасать шлюз должен.

а клиенты не могут работать напрямую, у них /32 и видят они только аплинк-порт, обычно это 26.

Share this post


Link to post
Share on other sites

Клинетам можно раздавать маску /24, и если на шлюзе поднять proxy-arp то создастся полный эффект локалки, но с полной изоляцией клиентов с помощью vlan-ов.

Share this post


Link to post
Share on other sites
Спасти от манипуляций с подменой МАК-а шлюза в 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 жрёт при этом бОльшую часть правил, при минимальной гибкости.

Share this post


Link to post
Share on other sites
для полной защиты от арпспуфинга, достаточно разрешать в на порте правильный Sender IP внутри ARP Reply, никаких мак адресов не надо учитывать.

не совсем так, если внимательно посмотреть на структуру ARP ответа то там внутри кроме IP еще есть и МАК, и для полной защиты от arp спуфинга его тоже нужно контролировать, т.к. именно эта комбинация потом и попадает в ARP кеш клиентам. Во всем остальном, полностью согласен.

Edited by Kaban

Share this post


Link to post
Share on other sites

ещё раз повторяюсь - зачем? неправильный мак с правильным IP(который только разрешён) придёт - и что спуфим в арпкеше шлюза(или другого компьютера) в таком случае? себе(хосту который атакует) связность рушим?

 

если вам нужен практический пример то хост с ettercap не может перехватить трафик между двумя хостами если к порту приложено три правила PCF(Sender IP в ARP Reply), IP(против IP спуфинга) и Ethernet (рубящий всё остальное).

проверял. не подделывает.

Share this post


Link to post
Share on other sites

Таки да. Полностью согласен.

 

А что делать когда вместо статических IP используются к динамические ? Прикручивать к dhcp серверу модуль который по SNMP создает/удаляет правила на свиче ?

 

Share this post


Link to post
Share on other sites

На форуме DLink'а задал вопрос о поддеркже DAI (со связкой с dhcp snooping), получил сл. ответ:

Есть некая аналогия этого режима. Фактически это режим strict функции IMP. В чистом виде dynamic ARP Inspection реализован в серии DES-3528/3552.

Share this post


Link to post
Share on other sites

Домонеты и дылинк. Часть 256-ая. Пурген - лучшее средство от кашля.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this