Агаву на кактус или массовая уязвимость уровня всего ДЦ

приветствую,

А что, в других ДЦ не так? Мне кажется что если уж вы решили покрасить в черный Агаву, то можно и других провайдеров аналогичных услуг смело туда же (мне проф. этика не дает сюда примеры писать)? Буду рад услышать про исключения (и мне это было бы оч. интересно).

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

Спасибо.

конечно не так... либо еще хуже, либо всё хорошо... последних больше.

в датахаусе не так, в вебальте не так...

А этот пост есть попытка Агавы сказать что у всех так?

ARP-spoofing - простейшая класическая атака. Позволяет направлять трафик уязвимой машины в уязвимой сети через другой хост, который находится в этом сегменте MAC уровня. Проще говоря можно прослушивать и иногда менять трафик другого сервера. Боротся с этим с точки зрения уязвимой машины особого смысла нет, хотя можно наворотить с мониторингом MAC адресов итд.

Статические MAC записи на уязвимых хостах не помогут - атаке подвергаются свичи.

Проще "чуствительные" данные прогонять через защищенные соединения. Например вместо http использовать https протокол итд. При таком подходе создается шифрованное соединение "пользователь-сервер" и прослушивание трафика в уязвимых ARP-spoofingу сетях значительно затруднено, часто практически невозможно.

В любом случае если вы озабочены тем, что ваш траффик может быть прослушан вам следует уделить внимание этим вопросам...

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

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

Как и писал выше, что от этого на 100% L2/L3 ACL или изначальное построение сети с правильной топологией.

Построение секурного LAN задача достаточно трудоемкая, но если убрать с клиентского порта portfast, запретить там cdp, bpdu и еще пару левачных моментов, то возможность проведения L2 атак снижается практически до нуля. Если добавляем L2/L3 ACL, то получаем полный ноль.

только когда пароли от ftp уплывают, то озабоченность сразу появляется.

ps. SSL и SSH не всегда способны противостоять MIM атакам т.к. их определенные версии уже спокойно прослушивались.

там как рас и написано, что статические маки, это единственная защита от такой атаки, может я чего-то не понимаю, не просветите, я думаю так...

допустим L2 свитч, статически прописаны маки port1 MAK1, port2 MAK2, port3 MAK3, предположим port1 ip10.0.0.1 гейт, port2 ip10.0.0.2 откуда атака, port3 ip10.0.0.3 атакуемый хост. в момент атаки с хоста 10.0.0.2 , посылаются arp пакеты указывающие на то что машина с ip 10.0.0.1 имеет мак MAK2, как результат все данные исходящие с хоста 10.0.0.3 попадают хакеру и далее после обработки выплёвываются гейту, но сам гейт отсылает пакеты на 10.0.0.3, конечно нельзя исключить что, также можно было атаковать и сам гейт....

исходя из того что я написал аrp таблица меняется на 10.0.0.3 ну и как вариант на 10.0.0.1 где соответствующие хосты считают что заданый хост имеет мак MAK2.... я что-то не то пишу?

а даже если и так, вас это не оправдывает.

где конкретно?

да

на указанной вами ссылке

The only method of completely preventing ARP spoofing is the use of static, non-changing ARP entries (each entry maps a MAC address to corresponding IP address).

Попробовал на хостере команду выполнить - ноль реакции. Наверное все ок.

Попробовал на работе - взбесившийся spaning tree отрубил сначало по портам меня и атакуемого, потом всю комнату, минут через 5 врубил обратно. Это у него параноя наверное.

гыгы, спасибо =)

port-security на портах с отключением спасет мир.

десять раз уже выше писалось, что не спасет.

kostich добавил 11.04.2008 в 12:25

это значит все прокатывает, но параметры были выбраны хреновенькие.