[neprden]

Хочу поделится весьма презабавнейшим случаем, постигшим давеча мою циску 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". Любопытно какие еще в принципе изменения могут самовольно вносится в конфиг , где об этом почитать ?

[terrible]

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

[neprden]

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

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

[p2d]

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

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