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

From

Alexander Burylov (2:5054/75.1)

To

Alex Mogilnikov (2:5054/37.63)

Date

2005-03-07T23:23:12Z

Area

PERM.CONNECT

   Привет Alex!

07 Мар 05 19:10, Alex Mogilnikov -> Alexander Burylov:

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

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

 AM>     Во-первых, это БОЛЬШАЯ натяжка. Допустим, в сети есть SMB ресурс
 AM> \\server\share, а пользователь Вася на своем компьютере тоже поднял
 AM> SMB \\vasia\share. Глупый Петя записал очень-важный-файл вместо
 AM> \\server\share на \\vasia\share. Это тоже DOS атака? Ведь
 AM> очень-важный-файл на \\server\share так и не появился. :)

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

 AM>     Во-вторых, подмена не имела места, ибо наличие двух концентраторов
 AM> с разными именами - штатная ситуация, которую клиентская сторона
 AM> должна уметь правильно разрулить. В конце концов, она (сторона) может
 AM> хотеть поочередно работать как с первым, так и со вторым
 AM> концентраторами, и даже с обоими одновременно...

Пока в сети не объявится концентратор злоумышленника.

 AM>     Наконец, от подмены концентратора можно защититься штатными
 AM> средствами PPP, запросив chap аутентификацию у концентратора (если уж
 AM> говорить о действительно злонамеренной подмене)...

Можно конечно, не спорю, но я рассматривал проблему маленько в другом контексте, запросом аутентификации от концентратора я не задавался. Я просто потом плюнул на всё это и перешёл на pptp :-)

 AB>> -----------------------------

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

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

 AM>     Постараюсь грамотно сформулировать и написать мылом.

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

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

 AB>> В PADI прилетает Host-Uniq, на концентраторе этот Host-Uniq
 AB>> определённым способом "кодируется" и отсылается обратно в теге
 AB>> AC-Сookie PADO-пакета. Когда клиент получает этот PADO - то он
 AB>> обязан вернуть пришедший AC-Сookie-тег неизменённым в
 AB>> PADR-пакете.

 AM>     ? Я понял совсем не так. Кука выдается клиенту концентратором в
 AM> ответ на PADR. Что потом с ней делает клиент, не написано. Впрочем,
 AM> есть подозрение, что у меня файл покоцанный в этом месте. Попробую
 AM> скачать где-нибудь...

В инете есть полный перевод этого rfc, или могу тебе выслать, у меня тоже где-то валяется. Или проще возьми (win)tcpdump и посмотри.

   До свидания, 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