Jump to content
Калькуляторы

любопытный казус radius + pppoe 7206, pppoe + radius

Хочу поделится весьма презабавнейшим случаем, постигшим давеча мою циску 7206 настроенную в качестве BRAS; терминируем pppoe.

есть настройки VT :

interface Virtual-Template1

description cl ADSL

mtu 1492

ip unnumbered Loopback10

ip access-group ADSLBLOCK in

ip verify unicast reverse-path allow-self-ping

ip flow ingress

ip ospf network point-to-point

no logging event link-status

timeout absolute 1440 0

snmp trap ip verify drop-rate

no peer default ip address

keepalive 20

ppp max-bad-auth 3

ppp authentication pap Method1

ppp authorization Method1

ppp accounting Method1

ppp ipcp username unique

ppp ipcp address required

ppp ipcp address unique

ppp timeout retry 3

ppp timeout authentication 15

ppp timeout idle 3600

end

Существует также радиус сервер, на котором есть учетные записи для pppoe клиентов, ну и также в оных можно указать ip адрес и маску которую должен получить сей клиент при авторизации.

Все это работает себе до тех пор пока по ошибке не был заведен клиент с адресом допустим 1.1.1.1 и маской ВНИМАНИЕ 0.0.0.0 т.е с пустым полем. Дальше самое интересное, клиент логинится :

000700: Apr 8 17:44:04.671 MSD: RADIUS: Framed-IP-Address [8] 6 1.1.1.1

000701: Apr 8 17:44:04.671 MSD: RADIUS: Framed-IP-Netmask [9] 6 0.0.0.0

000702: Apr 8 17:44:04.671 MSD: RADIUS: Service-Type [6] 6 Framed [2]

000704: Apr 8 17:44:04.671 MSD: pppx PPP: Phase is FORWARDING, Attempting Forward

000705: Apr 8 17:44:04.671 MSD: pppx PPP: Send Message[Connect Local]

000706: Apr 8 17:44:04.675 MSD: pppx PPP: Bind to [Virtual-Access102]

далее смотрим на IPCP :

000730: Apr 8 17:44:04.711 MSD: Vi102 IPCP: O CONFACK [ACKrcvd] id 1 len 22

000731: Apr 8 17:44:04.711 MSD: Vi102 IPCP: Address 1.1.1.1

000732: Apr 8 17:44:04.711 MSD: Vi102 IPCP: PrimaryDNS 5.5.5.5

000733: Apr 8 17:44:04.715 MSD: Vi102 IPCP: SecondaryDNS 5.5.5.6

000734: Apr 8 17:44:04.715 MSD: Vi102 IPCP: State is Open

000735: Apr 8 17:44:04.719 MSD: Vi102 IPCP: Install route to 1.1.1.1

и ! сюрприз :

000736: Apr 8 17:44:04.903 MSD: %PARSER-5-CFGLOG_LOGGEDCMD: User:console logged command:ip route 0.0.0.0 0.0.0.0 1.1.1.1

т.е циска сама конфигурит дефолтный маршрут причем с метрикой connected указывающий на только что подключившегося клиента. На роутере болтается full view, а если бы не было, то инет отвалился бы у всех клиентов.

с общей точки зрения , циску понять можно. Если бы не проверялись параметры, передаваемыые комманде ip route, то такой эффект при использовании 0-й маски понятен. После завершения сессии маршрут удаляется.

Вопрос : можно ли защитится средсвами циски от подобного рода казусов ? Допустим принудительно выставлять 32 маску на VT или подменять присылаемый Framed-IP-Netmask ?

Cisco IOS Software, 7200 Software (C7200-ADVENTERPRISEK9-M), Version 12.4(24)T, RELEASE SOFTWARE (fc1)

И еще чрезвычайно любезно со стороны циски было уведомить меня о произошедшем посредством сислога, в котором была вышеприведенная запись, в которой же было указано , что команду ip route 0.0.0.0 0.0.0.0 1.1.1.1 а также ее отмену при завершении сессии издавал пользователь "console". Любопытно какие еще в принципе изменения могут самовольно вносится в конфиг , где об этом почитать ?

Share this post


Link to post
Share on other sites

Парамерты ААА назначает радиус, параметры радиусу назначает биллинг, параметры биллингу назначают операторы биллинга, криворукость операторов сводится к минимальным значениям дополнительными костылями в биллинге - т.е. вытрахайте мозги разработчику, дабы он, собака такая, нулевую маску на Flamed IP Address не ставил, определите минимум.

Share this post


Link to post
Share on other sites

Парамерты ААА назначает радиус, параметры радиусу назначает биллинг, параметры биллингу назначают операторы биллинга, криворукость операторов сводится к минимальным значениям дополнительными костылями в биллинге - т.е. вытрахайте мозги разработчику, дабы он, собака такая, нулевую маску на Flamed IP Address не ставил, определите минимум.

Кривость биллинга - это понятно, но речь то идет вообще о иерархии безопасности. Понятно, что если оператор биллинга может поменять пароль с помощью которого подписываются радиус пакеты от железки, то будет общий обвал сервиса. Поэтому оператору биллинга не даем права на такую штуку. А вот назначать ип адреса которые будут выдаватся клиентам - работа как раз его , и вот то что в рамках этого он может обрушить весь сервис - весьма удручает. Попробую конечно убедить разрабротчиков, но все же хочется быть застрахованным от такого рода штук. странно только то что при вводе команды ip route екзек процесс проверяет корректность параметров а ipcp нет. Ну и по поводу самоконфигурирования железки от имени юзера console тоже вопрос открыт.

Share this post


Link to post
Share on other sites

Это не баг, это фича, которую многие используют, мы в том числе. Попробуйте не использовать этот атрибут, либо осуществлять контроль ввода данных оператором - это вообще то первое, чему учат программеров.

ЗЫ Вот кстати http://wiki.freeradius.org/index.php/FAQ#H...n_IP_netmask.3F

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this