информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Spanning Tree Protocol: недокументированное применениеГде водятся OGRыПортрет посетителя
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Microsoft обещает радикально усилить... 
 Ядро Linux избавляется от российских... 
 20 лет Ubuntu 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / networking
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Отвечу сразу всем. 01.12.06 12:20  Число просмотров: 3519
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 01.12.06 12:25  Количество правок: 5
<"чистая" ссылка>
> MAC несложно подделать, да и учесть все мак-адреса в
> конторе с приличным кол-вом рабочих станций (а еще нужно
> учитывать и мобильных клиентов - ноуты, кпк) почти
> нереально...

Отвечу сразу всем.
Все началось с коллизии, которая произошла, видимо, из-за того, что у какого-то хоста остался прописан статический АйПи (зачем-то временно это было нужно), а ДХЦП выда кому-то еще этот адрес то ли из пула, то ли из резервации, уже не важно.
Разгоресля спор, заключавшийся в неправильном трактовании слова "резервация". Один товарищ думал, что если адрес зарезервирован для какого-то МАКа, то хост с другим МАКом под этим АйПи в сетке работать не сможет, а тут даже заризирвированый хост не пускает. Это миф, который был развеян демонстрацией, после неудавшейся попытки переубедить. Чел остался сильно возмущен.
Подобное поведение является нормальным, но может нарушить безопасность, которая может быть построена на АйПи. То есть логически сетка бьется на область резервации и пул. На определенных серваках файрволом ставятся определенные правила (доступ к сервисам, в интернет и пр.) на каждую из частей сети свои. Полагаться на неосведомленность нарушителя нельзя, тогда ему останется прописать нужный АйПи адрес у себя (на компе, если есть права, или на буке, например).
Приписывание МАКа порту управляемого свитча может являться достаточно сильным решением, но только в предположении того, что нарушитель не является даже средним спецом, чтобы на поменять МАК на МАК того хоста, который временно (например в виду временного отсутствия сотрудника) не включен и воспользоваться его патчем.
В принципе то же самое будет и с arp -s. Мало того статическую таблицу придется организовать на всех хостах, в предположении того, что злоумышленник полезет не только на серваки, но и на РС.
Похоже подобное решение проблемы "чужака" отсутствует.
Родалась у меня тут идейка, только не знаю - есть ли реализация. Это должен быть ДХЦП сервер, поскольку только он сможет быстро распознать соответствие АйПи МАКу. Как только хост (драйвер АйПи) стартует, он проверяет на конфликт адресов и в случае такового давит обслуживание протокола. То есть чужак включил комп, при инициализации комп опрашивает (широковещательным пакетом, который дойдет и до сервака) на конфликт адресов, сервак получив пакет проверяет на соответствие МАКа предпологаемому АйПишнику и если что не так, то от своего имени посылает пакет, о том, что, мол, есть уже такой АйПишник, ну, скажем, у меня. Решение тоже не идеальное, но, думаю, забавное и не сложное.
Полагаю что проблема достаточно интересна и может оказаться полезна многим. Следует учесть, что на уровне АйПи нет никаких предпосылок к какой-либо авторизации, то есть чтоб работать в сетке, стучаться куда-то, просто как-либо пакостить не нужно ни логинов, ни паролей, ни сертификатов.
<networking> Поиск 






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach