>>Михаил, спасибо за Ваш ответ. Только я не понял, а чего бы
>>добился вор, если бы отправил ARP-ответ шлюзу с его MAC и
>>моим IP адресами? Ну отправил бы. А TCP-соединение поддержать и, как
>>следствие, перехватить связь, все равно бы не смог. Имхо, единственное, к
>>чему бы это привело с точки зрения моей машины - разрыв
>>TCP-соединения. Прав ли я, и если нет, то в чем?
>нет, просто у прова обновится арп-таблица и в ней будет неверный мак-адрес,
>т.е. мак-адрес врага.
>а посылать этот пакет лучше в момент, когда у тебя нет коннектов
>с сервером прова.
>а потом, никто не мешает врагу чаще, чем ты посылать прову арп-реплай
>и сильно испортить тебе жизнь.
Это да. Только в сети моего провайдера такого беспредельщика пока не было. За такие проделки пров может и от сети отключить :)
>>А если бы вор послал на шлюз провайдера свой пакет от моего
>>имени (возможно, Вы подразумевали мой IP-адрес), не зная MAC-адреса, к которому
>>привязан мой счет, то просто счет был бы заблокирован. Ведь я
>>и пытаюсь выяснить у Linux-гуру, как скрыть MAC-адрес. Безусловно, это неприятность,
>>но тогда трафик украсть и подавно не удастся.
>>
>>Неужели нет путей добиться subj-жа, кроме редактирования /usr/src/linux/net/ipv4/arp.c? :)
>
>имхо, тебе даже редактирование ядра на 100% не поможет! если враг имеет
>возможность прослушивать сеть все время - он имеет шанс поймать момент
>обновления коммутатором своих таблиц, например после сброса или сбоя питания, и
>шанс поймать твой мак-адрес, т.к. коммутатор, у которого таблицы пусты, работает
>на широковещание.
>и если, как ты сам сказал, враг использует мак-адрес прова, то тебе
>это тоже не поможет... а надо-то всего один раз это сделать...
Да, это та еще проблема... Оптимальным вариантом было бы фильтровать ARP-запросы файрволом, учитывая MAC и IP-адреса. Тогда такая машина была бы слишком хлопотной добычей для вора.
>
>кстати, а почему не получается закрыться от чужих арп-запросов через iptables? что
>в параметах пишешь? что происходит? я такое не пробовал, но не
>вижу причины, почему это не должно работать...
Михаил, мне очень хотелось бы ошибиться, полагая, что с помощью iptables ARP-запросы фильтровать нельзя но, похоже, это так. К сожалению, iptables не работает на уровнях ниже сетевого, а критерий --mac-source учитывается только после того, данные поднялись с канального уровня на сетевой.
Наиболее "низкоуровневая" таблица, в которой разрешена фильтрация (хоть и в исключительных случаях!), это NAT, цепочка PREROUTING. Т.е. правила таблицы действуют еще до того, как машина приняла решение - данные адресованы ей (тогда - в цепочку INPUT) или должны быть маршрутизированы (тогда - в цепочку FORWARD). Итак, для чистоты эксперимента полностью сбрасываю все настройки iptables, политики по умолчанию - ACCEPT. Ввожу правило
$IPTABLES -t nat -A PREROUTING -m mac --mac-source ! 00:40:5B:A6:97:9B -j DROP
(переменная $IPTABLES определена; правило принято без ошибок). Вводя это правило я пытался достичь эффекта, что любой кадр, адрес отправителя которого отличается от 00:40:5B:A6:97:9B, будет сброшен. Т.е, по идее, и ARP от всех оставльных машин должен быть просто сброшен.
И что мы получим? Пингую с другой машины этот ПК с iptables. Пинг не проходит. В ARP таблице отправившей машины MAC-адрес компьютера с iptables есть :(((( Попытки добиться результата, добавляя правило в таблицу filter, цепочку INPUT проваливаются и подавно!
Похоже на то, что критерий --mac-source относится к канальному уровню лишь "условно" - да, MAC адрес анализируется, но тогда, когда уже поздно.
Поэтому в данной версии iptables (1.2.6a) фильтровать ARP-запросы, видимо, невозможно, как это ни печально. Интересно, появится ли такая функциональность в следующих версиях??
АУ, опровергните меня, хоть кто-нибудь! Буду очень рад :)
>
>надежные, на мой взгляд, варианты:
>1)коммутатор, как я понимаю, простенький? был бы получше - можно было бы
>на нем VLAN сделать, чтобы в ней были только ты и
>пров.
>1а) если коммутатор позволяет, то жестко в его таблицах приписать твой новый
>МАК-адрес и МАК прова к портам.
>2) сделать VPN до прова. или еще что-то защищенное и туннелирующее...
>3) поменять коммутатор на что-то более серьезное, типа рутера.
>но все эти варианты плохи тем, что без участия прова их не
>сделаешь :(
Методы-то надежные, но речь идет не о корпоративной сети, а о локальной сети нескольких домов. И если поставить дорогой и функциональный коммутатор, его просто украдут. Не говоря уже о том, что провайдер не потянет такие расходы. Ему же и цены надо низкие держать, и прибыль получать!
>4) если у прова действительно есть прога для защиты (что-то я сомневаюсь
>в ее действенности), то добавь пограничную машинку с виндами. или поищи
>аналоги этой проги под Линукс.
Защита, насколько я понимаю, состоит в следующем. Клиенту присваиваются логин и пароль. По умолчанию доступ в Интернет у нег озаблокирован.
"Прога", запущенная у клиента в Windows, лезет поверх SSL на шлюз провайдера, передает логин и пароль. Если они правильные, доступ с этих IP/MAC адресов разрешается. Периодически программа посылает keep alive. Если шлюз не получает keep alive в течение заданного времени, подразумевается, что клиент отключился, и доступ блокируется.
Это разработка провайдера, поэтому версии под Линукс, естественно, нет.
Что касается пограничной машины. Просто у меня есть сеть масштаба квартиры, и для подключения ее к Интернет (трансляции адресов и портов), защиты от вторжений и других задач я за копейки купил подержанный P166. Все работает просто замечательно (Linux Slackware 8.1 без X Window, пакеты только самые необходимые).
И как-то не хочется мне для этих задач использовать Windows!
Как крайний метод оставляю запуск программы для защиты счета на Windows-машине сети. Хотя, скорее всего, просто запущу сниффер и буду периодически просматривать результаты его деятельности на предмет нехороших действий "хакеров", на самом деле просто позорного ворья. Заодно и улики будут.
>и все-таки - поройся в договоре, думаю, там должно что-то найтись, что
>обяжет прова пойти тебе навстречу.
>кстати, по закону ты не обязан платить больше, чем реально потребляешь. а
>такие воры трафика - следствие непринятия провайдером мер для надежного учета
>трафика и, соответсвенно, лежит на его ответственности!
Да пров-то обещал отключить паразита, если будет продолжать. Просто хотел себя надежно обезопасить и не анализировать расход трафика и результаты работы сниффера. Не получилось. А жаль.
Михаил, спасибо за Ваше участие.
Вариант для распечатки
Информационная безопасность (Public)
on
30-Мрт-03, 19:23 (MSK)
