Ipguard и android..
-
А никто не подскажет, это только у меня такое или это нормально и копать глубоко нет смысла?
Суть в чем - надо заблокировать возможность клиентам менять руками свой ip в сети, т.к. для разных диапазонов разные правила в шейпере и т.д.
Для этого по идее есть замечательная штука - ipguard. Они сидит себе тихо мирно и отслеживает соответствие IP-MAC по своей табличке. Соответственно при нарушении, (читай попытке присвоить адрес не из доступного диапазона) посылает на злоумышленника сообщения, что данный ip занят.
Так вот windows корректно обрабатывает и выдает сообщение о конфликте ip адресов. Android или ubuntu например, забирают вбитый айпишиник не поперхнувшись, соответственно спокойно работают дальше.. Это нормально? -
Ядро Linux само по себе не проверяет занят ли IP адрес назначаемый локальному интерфейсу, т.е. никогда не шлет gratuitous ARP. Проверка занятости IP происходит с помощью arping только при поднятии интерфейса (ifup), а это очевидно не одно и то же, что ifconfig.
-
Ему к слову и при поднятии интерфейса фиолетово, занят он или нет…
А нет идей, как тогда можно решить задачу? -
Пока решил ipguard-ом и ipfw
В общем ipguard всетаки пригодился.
Она очень хорошо умеет следить за интерфейсом и сигнализировать, когда кто-то c неправильным маком пытается занять непредназначеный для него ип из нужной сетки.
Было бы конечно хорошо, если бы помимо посылки в ответ gratuitous и писания в лог, он мог ещё и выполнять по этому событию сторонний скрипт, возможно я недоглядел, но по моему действительно не может. В общем будем использовать костыли.По порядку:
Для тех, кто не использует Captive portal:
Устанавливаем пакет ipguard-dev.
Настраиваем.
создаем скрипт ipguard_ext.sh например
с таким содержимим:
# Включаем ipfw и создаем нужный контекст (не спрашивайте про 3 и 4 строчки - без 3-й нихрена не работает) /sbin/sysctl net.link.ether.ipfw=1 /sbin/kldload ipfw ipfw_context -a blockbadmac ipfw_context -a blockbadmac -n <ваш LAN> # Этим угробищем мы следим за логом ipguard-а и при появлении нужных фраз посылаем все это авку, который в свою очредь проверяет, нет ли уже по данному маку записей в ipfw таблице, и если нет, пишем туда запрещающее правило для данного мака. tail -f /var/log/ipguard_lan.log | grep -v --line-buffered fake | grep --line-buffered xxx | awk '{if (system("/sbin/ipfw -x blockbadmac show | grep --line-buffered \"" $6 "\" >>/dev/null")) system("/sbin/ipfw -x blockbadmacs add 666 deny mac any "$6);}'
По опыту, максимум через 5 секунд после смены ip, интернет у клиента пропадает.
скрипт можно добавить в автозагрузку…
амнистируем засранцев или ребутом или ipfw -x blockbadmac delete 666
С Captive portal посложнее будет, там уже есть свой контекст ipfw и где то в нем прописываются для маков свои правила (для неавторизованых своя таблица например, для авторизованых другая...) и ковырять их уже нужно аккуратно и с пониманием.
Все.
-
А если просто зарезервировать в ДХЦП адреса
http://www.thin.kiev.ua/router-os/50-pfsense/679-ip-address-mak-dhcp-pfsense-.htmlи разрешить доступ к интернет только зарезервированным IP??
http://www.thin.kiev.ua/router-os/50-pfsense/473-ippfsense.html#mak -
Простите.. Я не рассказал контекст вопроса.
Есть публичный вифи. Для гостей. Изначально.
Вифи по всем параметрам урезан, скорости, порты и т.д.
Начальство на айпадах тоже хотит интернет, но не урезанный.
Решение очевидно- в маленькую сетку, не входящую в dhcp диапазон суем всех випов и делаем этой сетке полный доступ. Дело за малым - не пущать в эту сетку посторонних. Static ARP и Denny unknown clients, поправьте меня, если я не прав, исключают возможность гостевого доступа.Как выход - пакет ipguard
даем ему примерно такой конфиг:
aa:aa:aa:aa:aa:aa 192.168.1.10 bigboss
00:00:00:00:00:00 192.168.1.64/26 dhcp
00:00:00:00:00:00 192.168.1.128/25 dhcp
00:00:00:00:00:00 169.0.0.0/8 for wodows lan
т.е. разрешаем доступ неизвестным макам только в сеть 192.168.1.64-192.168.1.254
(последняя строчка для компутера в бухгалтерии, подключенного по Ethernet - windows при старте , при поднятии интерфейса присваивает себе сначала по умолчанию адрес из этой левой подсети, соответственно скрипт на это реагирует и блокирует)в dhcp static map прописываем випов
aa:aa:aa:aa:aa:aa-192.168.1.10
Вот только проблема в том, что ipguard очень вежливый. С нарушителем он ничего не делает. Он просто плюёт в него пакетиками с сообщениями, что ip якобы занят. Так вот андройду и убунте на это дело фиолетово. Вот и пришлось мак нарушителя блокировать костылями.
-
@fvf:
Так вот андройду и убунте на это дело фиолетово. Вот и пришлось мак нарушителя блокировать костылями.
А кто помешает владельцам андроида и убунты поменять мак?
Еще проще взять из сети маки ваших пользователей.А наказать вас в вашей нелегкой борьбе, сможет любой школьник. :-)
http://www.thin.kiev.ua/android-kat/753-wifikill-wifi.htmlИМХО - нужно разделить общественные и рабочие беспроводные сети.
-
А кто помешает владельцам андроида и убунты поменять мак?
Пусть меняют.. у них будет такой же ограниченный интернет.. надо знать, на какой мак менять..
Еще проще взять из сети маки ваших пользователей.
Т.к. они сидят на dd-wrt-шном роутере с включеным AP Isolation, по arp -a они увидят только pf и полудохлый комп бухгалтерии, на котором такой же ограниченный интернет (бухгалтерам, в силу их возраста непривычно лазить в одноглазниках с телефона, по этому поставили старый компутер чисто для интернета).
А наказать вас в вашей нелегкой борьбе, сможет любой школьник. :-)
http://www.thin.kiev.ua/android-kat/753-wifikill-wifi.htmlAP Isolation
ИМХО - нужно разделить общественные и рабочие беспроводные сети.
Давно разделены. Только в рабочей интернета нет.
-
Т.к. они сидят на dd-wrt-шном роутере с включеным AP Isolation, по arp -a они увидят только pf и полудохлый комп бухгалтерии, на котором такой же ограниченный интернет (бухгалтерам, в силу их возраста непривычно лазить в одноглазниках с телефона, по этому поставили старый компутер чисто для интернета).
Советую сменить dd-wrt на TomatoUSB shibby's mod - http://tomato.groov.pl/ . Если Ваш роутер поддерживается, конечно (http://tomato.groov.pl/?page_id=69). Намного лучше и удобнее.
-
Спасибо, с радостью бы, но это TP-Link…
-
OpenWRT. Тем более что недавно обновилась до BB.
-