Система-сервер через выделенку через модем - на мир, т.е. в интернет. Система на линухах (Федора4). Второй интерфейс - в локалку.На системе стоит файрволл. Всё работает отлично, НО. Файрволл пользователей определяет по ИП/АРП (если ИП и МАК не совпадают - то коннект запрещён). Нашелся молодчик, который маскируется под чужие ИП/АРП(МАК) и качает их трафик (аккаунтинг траффика происходит по ИП даресам и МАКу).
Я поставил PPPoE сервер - он был в дистре. Теперь я изменил правила, и каждый пользователь подключается через PPP и после подключения ему выдаётся другой ИП, НО... Молодчик всёравно пролез.
Я попробовал и оказклось: что, к примеру, открыт доступ для адреса х.х.х.207, чел логинится в ПППоЕ с паролем ему присваивается адрес х.х.х.207, и он ходит в инет. Если же просто прописать на машине этот самый адрес (В стп/ип настройках поставить х.х.х.207, и указать шлюзом мой гейтвей) - то уже без всякой ПППоЕ коннета можно лазить в инете на чужом трафике. Т.е. Подделал ИП адрес виртуального соединения - и пользуй скока хошь.
Что делать с этой бедой? Кровь из носа надо отделить траффик и разрешить, чтобы некоторые ИП адреса могли ходить через серв - только если они через ПППоЕ - иначе не пускать. Но как это сделать???
Уже перечитал кучу - конкретно по теме ничего не нашел.
Немного подумав, и короче говоря - немного перефразирую.Как сделать так, чтобы некоторый список ИП адресов мог использоваться - ТОЛЬКО ЕСЛИ ОНИ ПРОШЛИ АВТОРИЗАЦИЮ через ПППоЕ. Иначе - ДРОП.
можно вобще на интерфейсе который в локалку ip адрес убрать и его в качестве шлюза не смогут использовать, а PPPoE нормально будет работать
ну вы блин, даёте.
Если уж вы поставили ПППоЕ, то юзеров в интернет надо пускать не с локального интерфейса, а только с интерфейса PPP. пересмотрите правила на своём фаерволе.
>
>ну вы блин, даёте.
>Если уж вы поставили ПППоЕ, то юзеров в интернет надо пускать не
>с локального интерфейса, а только с интерфейса PPP. пересмотрите правила на
>своём фаерволе.Совершенно верно.
Но есть еще более надежный и лучший вариант. Правда прийдется потратится на управляемый свитч. Речь иде о технологии VLAN. Вкратце: на свиче пакетам езернет приделваются тэги (максимальный размер пакета при этом уведичивается на 4 байта, что плохо воспринимается некоторыми древними сетевухами.) Для ее поддержки надо иметь управляемый свич, который умеет тэгировать трафик - это называется 802.1q - и включить поддержку виланов в линуксе (модуль ядра будет называться 8021q).После проведения подготовительных мероприятий (покупка и установка свича, настройка на нем виланов) вы при помощи команды vconfig поднимаете у себя интерфейсы на каждый вилан:
bash-3.00# vconfig add eth0 2
Added VLAN with VID == 2 to IF -:eth0:-Если после этого запустить команду ifconfig, то вы увидите кроме основного интерфейса еще ваш вилан:
eth0.2 Link encap:Ethernet HWaddr 00:0E:A6:12:34:56
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)Вид имени вилана настраивается - вы можете например сделать так, чтобы он выглядел как vlan2
НЕ ИСПОЛЬЗУЙТЕ ВИЛАН 1 - это может вызвать ряд проблем.
После создания виланов каждый пользователь сажается в отдельный вилан. Допустим, мы используем сетку 192.168.5.x
Тогда:
Пользователь 1:
network 192.168.5.0/30
router 192.168.5.1
client 192.168.5.2
broadcast 192.168.5.3Пользователь 2:
network 192.168.5.4/30
router 192.168.5.5
client 192.168.5.6
broadcast 192.168.5.7И так далее.
Результат:
1. весь трафик идет через роутер и может быть просчитан.
2. Клиенты изолированы друг от друга
3. Так как тегирует трафик свич, то пользователь не имеет физической возможности притвориться кем-то другим.Недостатки:
1. Нужен управляемый свич (см. например DLink 3226 - г еще то, но гораздо дешевле, чем Cisco)
2. Большой расход адресного пространства - при использовании частных адресов это абсолютно фиолетово.
Да вы что, мужики, развели демагогию по мелочи, просто зарубаешь на файре проход пакетов с eth на eth, и все, а разрешаешь только с ppp на eth, пусть после этого попробует в сеть вылезти без PPP.
>Да вы что, мужики, развели демагогию по мелочи, просто зарубаешь на файре
>проход пакетов с eth на eth, и все, а разрешаешь только
>с ppp на eth, пусть после этого попробует в сеть вылезти
>без PPP.:)
Думаешь все так просто?
>>Да вы что, мужики, развели демагогию по мелочи, просто зарубаешь на файре
>>проход пакетов с eth на eth, и все, а разрешаешь только
>>с ppp на eth, пусть после этого попробует в сеть вылезти
>>без PPP.
>
>:)
>Думаешь все так просто?Ничего сложного
iptables -A FORWARD -i eth+ -o eth+ -j DROP
iptables -A FORWARD -i ppp+ -o eth1 -j ACCEPT
iptables -A FORWARD -i eth1 -o ppp+ -j ACCEPTето если eth1 внешний интерфейс.
>Ничего сложного
>iptables -A FORWARD -i eth+ -o eth+ -j DROP
>iptables -A FORWARD -i ppp+ -o eth1 -j ACCEPT
>iptables -A FORWARD -i eth1 -o ppp+ -j ACCEPT
>
>ето если eth1 внешний интерфейс.:) :)
И как же это решит проблему подмены клиентом своего ИП и МАК адреса?
А если зафлудить свич, то можно временно превратить его в хаб, и перехватывать пакеты инициализации ПППоЕ... Особо весело, если для аутентификации используется ПАП.А потом к вам прибежит ни в чем неповинный клиент и начнет доказывать вам, что не он выкачал эти 10 гигабайт порнухи. И "добрая слава" о надежности ваших сетевых решений быстро разлетится по окрестностям...
Уважаемый, вы просили чтобы пользователь не мог ходить в инет не авторизовавшись по PPP, а не защиту от смены IP и MAC адресов, если вам надо так, тогда милости просим RADIUS+MySQL+ авторизация MS-CHAPv2, каждому свой логин и пароль, и даже если у вас вся сеть построена на хабах, ваш особо одаренный пользователь останется только со своим снифером и кучей логов, причем IP и MAC можно менять до посинения.
Проблема пока временно решена. Спасибо за советы.У меня считалка своя, т.е. когда-то не смог настроить ипстаты и написал свою на сях. Немного подглюкивает, но считает исправно. Особенность в том, что работает только с иптабласами/чейнами, любые варианты, которые меняют таблицу - не катят под них надо переписывать.
Плюс - есть часть компов, которые через сеть ходяит на внешние адреса (типа анлимитед по городу), т.е. я их должен пропускать через етх1 на етх0 и оттуда не город по-любому. Короче каша-мала. Но немного разрулил.
Решил так - на те ИП которые идут в инет и которые надо защищать добавил -i и -o для ппп интерфейса получилось:
/sbin/iptables -A OUTPUT -s х.х.х.х -i ppp0 -j ACCEPT
/sbin/iptables -A INPUT -d х.х.х.х -o ppp0 -j ACCEPTКороче пока конкретный ИП не прошёл через ппп - он идет нафиг(ДРОП на политиках таблсов по умолчанию), а чтобы пройти через ппп - лог/пасс соответственно.
ЗЫ. И из-за этого пустяка пришлось просидеть кучу времени, сижу и думаю как сразу не догадался.......
ЗЫЫ. Интересно что наш юный хакер ещё придумает...
>ЗЫЫ. Интересно что наш юный хакер ещё придумает...Изучение РФК по ПППоЕ натолкнуло меня на ряд интересных мыслей по западлостроению на ПППоЕ каналах. И думаю, что если это чудо озлобится и прийдет к тем же выводам, что и я, то связь у вас будет работать очень нестабильно, хотя полевых испытаний своих умозаключений я не проводил.
Подумайте о плавном переходе на виланы - это единственный путь из известных мне, позволяющий решительно и бесповоротно разрешить подобного рода проблемы. ПППоЕ конечно весьма неплох и дешев, но виланы лучше.
Виланы удобны в корпоративных сетях. В домовых же, где провода по щиткам идут, подрубиться к другому порту плевое дело. Да и дорого это, и порты на D-Link-ах и Compex-ах виснут. ПППоЕ чем-то лучше, но учтите, что он имеет известные проблемы с безопасностью, требователен к ресурсам и прибольшом числе абонентов крайне не надежен.
Можно Open-VPN, но это совсем круто. Раздать по дискетке каждому пользователю, и безопасность как в банке. Траблы те-же, но безопасность параноидальная. Forward между eth закрыть в любом случае!!!А INPUT для внутренних оставить тока на ПППоЕ/OpenVPN порт.
Тогда уже лучше 802.1x юзать.
Каждый пакет будет авторизоваться на радиусе (с кешированием ответа на некоторое время, естессно...)
Vector 1916 или Vector 1908 свитчи подходят.
08-й стоит около 100$
www.asotel.com.ua
другие методы кроме упраыляемого свитча с умеением 802.11q ВИЛАН - некорректны.
можно на той же фрии бсд поднять виланы например, но не факт, что драйверы сетевух клиентов смогут понимать виланы.
У нас сначала доступ к интернет-серверу фильтровался по IP+MAC
/sbin/iptables -t nat -P PREROUTING DROP
/sbin/iptables -t nat -F PREROUTING
/sbin/iptables -t nat -i eth1 -A PREROUTING -s 192.168.7.1 -m mac --mac-source 11:22:33:44:55:66 -j ACCEPT
....
потом настроил PPPoE сервер, запустил указанный в статье
http://www.opennet.me/base/net/pppoe_firewall.txt.html
файл. В chap-secrets ввел пользователя
test * test 192.168.100.1добавил на PREROUTING условие
/sbin/iptables -t nat -i eth1 -A PREROUTING -s 192.168.100.1 -m mac --mac-source 11:22:33:44:55:66 -j ACCEPTно доступа не получил. В самом файле для запуска PPPoE нету настроек, касающихся PREROUTING.
Как можно прикрутить к PPPoE проверку на IP+MAC?
Думаю, тоже самое можно сделать с INPUT, но не уверен в том, какой IP адрес разрешать 192.168.7.1 или 192.168.100.1
На рабочей системе не хочется экспериментировать, хочется отключать сервер - на минимально возможное время или вообще не отключать...
есть проблема
у нас в городе есть провайдер интернета (соединение происходит по PPPoE)
какой то левый чел поднял свой ПППоЕ серв (дефаулт сервис) и соединение постоянно пропадает
т.е перехватывает все
как можно вычислить этого гада?? т.е ИП и МАК
уж очень нервы перепортил :(
PS: сам пров не может справиться (или не хочет)
УХАХА))