Re: К проблемам с ППИЦем добавились новые

From

Alexander Burylov (2:5054/75.1)

To

Alex Mogilnikov (2:5054/37.63)

Date

2005-03-07T12:08:16Z

Area

PERM.CONNECT

   Привет Alex!

06 Мар 05 20:08, Alex Mogilnikov -> Alexander Burylov:

-----------------------------
 AM>>>     Как я понял, этот человек поднял PPPoE сервер с тем же
 AM>>> именем, что и провайдер с целью получения чужих логинов и
 AM>>> паролей.

 AB>> Там имя особой роли не играет. Если Service-Name пусто, то,
 AB>> концентратор будет принимает запросы на соединение с любым
 AB>> Service-Name. А вот если этот Service-Name прописан на
 AB>> концентраторе, то он будет давать отлуп всем клиентам с другим
 AB>> Service-Name.

 AM>     Кроме Service-Name PADO содержит еще и имя концентратора
 AM> (AC-Name), я имел в виду именно его. Клиент, получив PADO от
 AM> нескольких концентраторов в ответ на свой PADI, должен выбрать тот, с
 AM> которым он хочет работать (ему он и посылает затем PADR).

Ответ ниже.

 AB>>  С точки
 AB>> зрения безопасности для пользователей пустое поле имени на
 AB>> концентраторе ISP естественно предпочтительней.

 AM>     Что ты имеешь в виду? Имя сервиса в PADO должно быть тем же самым,
 AM> что и в PADI, на который концентратор отвечает. И при чем тут
 AM> безопасность?

Так должно быть и так советуют, но не факт, что оно так и есть, он может давать отлуп при несовпадении Service-Name.

 AB>> Ещё любопытней узнать почему на концентраторе доступа провайдера
 AB>> не предпринято элементарных мер для защиты от DOS атак (rfc 2516
 AB>> чёрным по белому: "9.Security Considerations").

 AM>     А при чем тут DOS атаки? Как я понял, проблема была в том, что из
 AM> двух предложенных клиенту концентраторов клиент выбирал "левый"
 AM> концентратор вместо концентратора провайдера...

Это тоже DOS (один из случае), сервис провайдера ведь в данном случае не был выбран т.к был подменён.

-----------------------------

Насчёт всего этого и безопасности.

Когда я столкнулся с проблемой двух pppoe-концентраторов, то после, так скажем, пляски с бубном я вообще решил отказаться от pppoe и перешёл на pptp. Причины две: во-первых pppoe не маршрутизируемый протокол (пришлось ставить релей для другой подсетки, а этот релей есть только под юникс) и безопасность, которая напрямую свзана со следующим(возможно применительно к данной ситуации):

Эту проблему нужно рассматривать вот с какой точки зрения:

ISP - концентратор ISP
HACK - концентратор хакера
USER - глупый юзер, который хочет соединиться с ISP.

1) Нужно рассмотреть варианты Service-Name на ISP
2) Нужно рассмотреть все варианты Service-Name и AC-Name которые может использовать HACK (в зависимости от ISP)
3) _Самое главное_ нужно рассмотреть все варианты конфигурации соединения USER-a. (по умолчанию, с правильными данными и тд)
4) Еще несколько критериев...
5) Всё это протестировать много много раз.

Из всего этого сделать вывод.
По понятным причинам ничего этого в эхе я расписывать не буду, если хочешь можно пообщаться мылом.

 AM>     Кстати, про AC-Cookie таг я как-то не очень понял. Не мог бы ты в
 AM> нескольких словах пояснить, в чем его смысл?

Вот это я как раз и не смог (или не понял) правильно использовать.

В PADI прилетает Host-Uniq, на концентраторе этот Host-Uniq определённым способом "кодируется" и отсылается обратно в теге AC-Сookie PADO-пакета. Когда клиент получает этот PADO - то он обязан вернуть пришедший AC-Сookie-тег неизменённым в PADR-пакете. Концентратор будет уверен, что это именно этот клиент. А вот тут стоп. В данном месте, в rfc сказано, что от клиента можно потребовать ограничить остальные сессии для этого MAC-адреса. (т.е если клиенту пришло два PADO то PADR отсылает он только тому, который требует ограничения, я это так понял). Каким образом сделать такое ограничение и заставить соединяться клиента (при любых условиях) именно с этим концентратором я не знаю.
Знаю где это работает, но там концентратор железный (оборудование стоит), а у меня программные (на сервере) были.

   До свидания, Alexander.

--- GoldED+/W32 1.1.5-30228
 * Origin: Homenet Gate (2:5054/75.1)
SEEN-BY: 5010/146 5054/1 4 8 9 18 28 29 30 35 36 37 50 63 66 67 70 72 75 80 81
SEEN-BY: 5054/84 85

PATH: 5054/75 1 37