Ivan Pesin

я делал. что не работает?

А можно подробнее с этого места? ;-) Ну, если уж наш "пионэр" настолько "хацкер" что б фейковые сервера подымать, то логично предположить, что поднятый сервер будет маленько подправленный: он не будет проверять присланные пароли, а аккуратно их складировать парами :-). Если же использовать CHAP, то задача для нашего "пионэра" _немного_ усложниться. Вместо готовеньких паролей он будет хэши получать. Потому, если он прям "кул хацкер", он вспомнит, что все "случайные генераторы" ПК на самом деле являются "псевдослучайными" и при большом желании можно просчитать, когда настоящий сервер запросит перехваченный хэш. Да и вообще, если учесть, что очень многие пользователи устанавливают пароли не стойкие к атаке по словарю, то можно за пару дней крякнуть полученый хэш.

ifconfig ethX -arp Во-первых, строго говоря указанная команда вообще отключает протокол arp. И если ее использовать без других вспомагательных команд вы лишь добьетесь того, что ваш ethernet интерфейс перестанет работать. Во-вторых, нужно разобраться, почему у вас столько arp-записей на этих интерфейсах. В-третьих, можно действительно использовать указанную команду, при этом руками прописав mac-адреса провайдера. Но лично я считаю, что сначала нужно разобраться со вторым пунктом.

Ну, притормозим %-) 1) Полностью согласен 2) Согласен, с той поправкой, что не "скорее всего", а "точно" 3) Полностью согласен... но стоимость... мда... но если учесть, что народ задает вопросы по 4-х процессорным серверам с 64Гбайтами ОЗУ... 4) При таком раскладе, если используется не третий вариант, наш "пионэр" получает кучу паролей с логинами.

В любом случае, даже если использовать PPPoE, можно проставить на сетевой mac сервера и "все то-же самое" (с)

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

# ifconfig eth0 hw ether xx:xx:xx:xx:xx:xx

ну, чесно скажу, не знаю. В пределах моего опыта работы с идентд ничем помочь не могу. :-( Может кто плотнее с ним знаком...

ну если у вас такие звери на трех (!) компах... даа... ну виланы тогда... (это отвлечение от темы) еще раз повторю, что те клиенты, которые _уже_ работали с сервером до подмены адреса продолжат свою работу, потому что пара ip-mac у них в кэше. другим будет сложно, согласен... да и если запись из кэша очистится, тоже плохо .. :-( "А пошто нам админы??!" (с) кто-то Кстати, тут еще важно, как я уже говорил, чей арп-реплай клиент услышит первым. А свичу-то чего? Будет форвардить пакеты, как форвардил. Проблема не в свиче, а в секьюрности IP. Клиент спрашивает: "Эй, чуваки! У кого ИП такой-то, а?". Ему сервер и подлый клиент шлют ответы: "Эгей, клиент, эта.. у меня такой ИП! Базарь ко мне на МАК ххх." А "ххх" для сервера и подлого клиента разные. Поэтому чей реплай клиент услышит первым с тем он и будет пытатся общатся. решения же есть разные, в зависимости от стоимости это могут быть и виланы, и заточеный скрипт, работающий в связке с arpwatch, блокирующий на управляемом коммутаторе нужный порт в случае изменения IP. Просто важно понять, что каждой задаче соответствует стоимость решения и построить трансатлантическую магистраль за 7 долларов 55 центов у вас не получится какие бы вы линуксы с шурекомами не использовали. А на счет фаерволла, я посто не прочитал начальный постинг :-). Слепые мы, однако. Вместо "сети" я прочел "сервера". Вот. Ну ведь на ту же букву начинается ... %-) опа.. это ж надо, какая утечки инфы... вот они атаки в своем проявлении. Тема будет, вернее она уже почти есть, но нужно доработать. А перед этим нужно разобратся с обязательной работой. %-) Кушать тоже хочется.

безусловно. но клиенты _уже_ работающие с сервером, к моменту подмены клиентом IP, будут и дальше нормально работать за счет арп кэша. Те кто не работал -- это как повезет, если первый арп-реплай будет от сервера - то ок, если от клиента - то бэд.

гм... хм... давай конфиг идентд в студию.

Возвращаясь к вопросу: в скрипты начальной загрузки echo -n "Setting up IP spoofing protection..." for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f done echo "done." Если совсем быть злым -- можно еще правила в фаерволл прописать дропающие пакеты в цепи input для всех _физических_ интерфейсов с адресами сервера Вроде все.

iproute2 тут как бы вообще ни сном ни духом. firewall установлен? может где-то в его настройках ошибка и он не разрешает на eth3/ppp0 коннектится на порт?

Да это. Эта строка означает, что твой идентд работает на всех интерфейсах системы. Почему ты решил, что он работает только на eth4?

лучше покажи, что показывает netstat -na