Привет всем! Ситуация такая: в локальной сети моего провайдера пользователи распознаются по IP и MAC адресам, поэтому уже находился желающий воспользоваться интернетом за мой счет. Чтобы защититься от таких поползновений, в идеале хотелось бы сменить свой MAC адрес и держать его в секрете: настроить компьютер так, чтобы он отвечал на ARP-запросы только шлюза провайдера.От iptables этого добиться не удалось (попытка отвергать ARP-запросы с помощью критерия mac-source провалилась, также как и фиксировать пакеты/кадры c моими IP/MAC адресами), а провайдер не хочет у себя прописывать статическую запись (arp -s ...).
Можно ли это сделать? Может быть, существуют какие-то патчи к ядру?
Заранее спасибо.
а среда передачи у прова широковещательная? тогда как ни защищайся у себя - тебя все равно прослушают...
да и если не широковещательная - кто мешает хосту врага ответить на арп-запрос на долю секунды раньше и перехватить всю связь на себя? или даже просто послать на шлюз свой ip-пакет от твоего имени...имхо, если воровство имеет место, то надо наезжать на прова на административном уровне!
>а среда передачи у прова широковещательная? тогда как ни защищайся у себя
>- тебя все равно прослушают...
>да и если не широковещательная - кто мешает хосту врага ответить на
>арп-запрос на долю секунды раньше и перехватить всю связь на себя?
>или даже просто послать на шлюз свой ip-пакет от твоего имени...
>
>
>имхо, если воровство имеет место, то надо наезжать на прова на административном
>уровне!Сеть на коммутаторе Compex (эх, жаль, что не Cisco с port security!), на своем компьютере статически добавил MAC-адрес шлюза прова, т.е. мой компьютер не отправляет ARP-запросы в принципе (остальные узлы подсети не интересуют, т.к. сеть использую только для доступа в Интернет.)
И что я хочу добиться? Шлюз провайдера отправит широковещательно ARP-запрос, заодно обновив свою запись в таблице коммутатора. Мой ПК отправит ему ответ, MAC-адрес не разглашен.
Если вор держит запущенным сниффер, анализирующий ARP-запросы, то может попытаться отправить и свой запрос мне, но ответ не получит. В принципе, может сменить свой MAC адрес на провайдерский, но до этого еще надо додуматься и так обнаглеть.
Но никто не мешает и мне держать запущенным такой сниффер, чтобы иметь возможность отслеживать аномальное поведение таких "друзей" и звонить прову с просьбой разобраться.
В общем-то я знаю координаты того, кто занимался воровством, его предупреждал, но хотелось бы надежно защититься от таких "хакеров"... А у провайдера есть программа для защиты, но только под Windows ;-((
В принципе, можно попробовать отключить у себя ARP, а прову периодически отсылать ARP reply с помощью пакета arp-sk (www.arp-sk.org), чтобы у него запись с моим адресом обновлялась. Но тогда надо позаботиться о наличии соответствующих записей в таблице коммутатора.
Подозреваю, что такая проблема не только у меня. Интересно бы придумать метод противодействия воришкам.
>а среда передачи у прова широковещательная? тогда как ни защищайся у себя
>- тебя все равно прослушают...
>да и если не широковещательная - кто мешает хосту врага ответить на
>арп-запрос на долю секунды раньше и перехватить всю связь на себя?
>или даже просто послать на шлюз свой ip-пакет от твоего имени...
>
>
>имхо, если воровство имеет место, то надо наезжать на прова на административном
>уровне!
Михаил, спасибо за Ваш ответ. Только я не понял, а чего бы добился вор, если бы отправил ARP-ответ шлюзу с его MAC и моим IP адресами? Ну отправил бы. А TCP-соединение поддержать и, как следствие, перехватить связь, все равно бы не смог. Имхо, единственное, к чему бы это привело с точки зрения моей машины - разрыв TCP-соединения. Прав ли я, и если нет, то в чем?А если бы вор послал на шлюз провайдера свой пакет от моего имени (возможно, Вы подразумевали мой IP-адрес), не зная MAC-адреса, к которому привязан мой счет, то просто счет был бы заблокирован. Ведь я и пытаюсь выяснить у Linux-гуру, как скрыть MAC-адрес. Безусловно, это неприятность, но тогда трафик украсть и подавно не удастся.
Неужели нет путей добиться subj-жа, кроме редактирования /usr/src/linux/net/ipv4/arp.c? :)
>Михаил, спасибо за Ваш ответ. Только я не понял, а чего бы
>добился вор, если бы отправил ARP-ответ шлюзу с его MAC и
>моим IP адресами? Ну отправил бы. А TCP-соединение поддержать и, как
>следствие, перехватить связь, все равно бы не смог. Имхо, единственное, к
>чему бы это привело с точки зрения моей машины - разрыв
>TCP-соединения. Прав ли я, и если нет, то в чем?
нет, просто у прова обновится арп-таблица и в ней будет неверный мак-адрес, т.е. мак-адрес врага.
а посылать этот пакет лучше в момент, когда у тебя нет коннектов с сервером прова.
а потом, никто не мешает врагу чаще, чем ты посылать прову арп-реплай и сильно испортить тебе жизнь.>А если бы вор послал на шлюз провайдера свой пакет от моего
>имени (возможно, Вы подразумевали мой IP-адрес), не зная MAC-адреса, к которому
>привязан мой счет, то просто счет был бы заблокирован. Ведь я
>и пытаюсь выяснить у Linux-гуру, как скрыть MAC-адрес. Безусловно, это неприятность,
>но тогда трафик украсть и подавно не удастся.
>
>Неужели нет путей добиться subj-жа, кроме редактирования /usr/src/linux/net/ipv4/arp.c? :)имхо, тебе даже редактирование ядра на 100% не поможет! если враг имеет возможность прослушивать сеть все время - он имеет шанс поймать момент обновления коммутатором своих таблиц, например после сброса или сбоя питания, и шанс поймать твой мак-адрес, т.к. коммутатор, у которого таблицы пусты, работает на широковещание.
и если, как ты сам сказал, враг использует мак-адрес прова, то тебе это тоже не поможет... а надо-то всего один раз это сделать...кстати, а почему не получается закрыться от чужих арп-запросов через iptables? что в параметах пишешь? что происходит? я такое не пробовал, но не вижу причины, почему это не должно работать...
надежные, на мой взгляд, варианты:
1)коммутатор, как я понимаю, простенький? был бы получше - можно было бы на нем VLAN сделать, чтобы в ней были только ты и пров.
1а) если коммутатор позволяет, то жестко в его таблицах приписать твой новый МАК-адрес и МАК прова к портам.
2) сделать VPN до прова. или еще что-то защищенное и туннелирующее...
3) поменять коммутатор на что-то более серьезное, типа рутера.
но все эти варианты плохи тем, что без участия прова их не сделаешь :(4) если у прова действительно есть прога для защиты (что-то я сомневаюсь в ее действенности), то добавь пограничную машинку с виндами. или поищи аналоги этой проги под Линукс.
и все-таки - поройся в договоре, думаю, там должно что-то найтись, что обяжет прова пойти тебе навстречу.
кстати, по закону ты не обязан платить больше, чем реально потребляешь. а такие воры трафика - следствие непринятия провайдером мер для надежного учета трафика и, соответсвенно, лежит на его ответственности!
>>Михаил, спасибо за Ваш ответ. Только я не понял, а чего бы
>>добился вор, если бы отправил 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-машине сети. Хотя, скорее всего, просто запущу сниффер и буду периодически просматривать результаты его деятельности на предмет нехороших действий "хакеров", на самом деле просто позорного ворья. Заодно и улики будут.
>и все-таки - поройся в договоре, думаю, там должно что-то найтись, что
>обяжет прова пойти тебе навстречу.
>кстати, по закону ты не обязан платить больше, чем реально потребляешь. а
>такие воры трафика - следствие непринятия провайдером мер для надежного учета
>трафика и, соответсвенно, лежит на его ответственности!Да пров-то обещал отключить паразита, если будет продолжать. Просто хотел себя надежно обезопасить и не анализировать расход трафика и результаты работы сниффера. Не получилось. А жаль.
Михаил, спасибо за Ваше участие.
попробуй договориться с провайдером и перейти на VPN
по поводу фильтрации MAC - возможно без явной загрузки критерия --mac-source неработает. попробуй сначала -m mac-source. Просто в iptables есть критэрии которые нужно явно подгружать и этот кажется к ним какраз относится... к сожалению проверить сейчас немогу... тут ipchains