|
Ответы на часто задаваемые вопросы о maintainer
- Зачем нужен maintainer (m.)?
- В каких объектах БД RIPE обязательно использовать ссылку
на m.?
- Могу я обойтись без своего m. в БД RIPE?
-
Как зарегистрировать m.?
- Что такое схема аутентификации m.?
- Почему в предыдущем ответе Вы не указали схему аутентификации
NONE?
- Что такое условия авторизации m.?
- Можно ли использовать в одном m. несколько несколько
схем аутентификации?
- Можно ли защитить один объект с помощью нескольких
m.?
- Какие есть способы совместной с RU-CENTER защиты объектов
вБД
RIPE?
- Зачем нужна ссылка mnt-lower?
- Как осуществляется авторизация по MAIL FROM?
- Как осуществляется авторизация по CRYPT-PW?
- Как получить криптованный пароль для схемы аутентификации
CRYPT-PW?
- Что проверяет тест-БД RIPE при попытке создания m.
c аутентификацией по схеме CRYPT-PW?
- Что делать, если пароль забыт?
- В новой версии объекта maintainer появилось поле
refferal-by, поясните для чего оно предназначено
- Что такое PGPKEY?
- Как осуществляется авторизация по PGPKEY?
- Зачем нужен объект key-cert в БД RIPE?
- Отличается ли чем-нибудь заведение route объектов в БД
RIPE от остальных?
- Защищен ли объект, если в нем указана ссылка notify?
- Почему я получаю письма-уведомления от БД RIPE, когда объектов
не создавал?
- Можем ли мы использовать для защиты объектов поля cross-nfy,
cross-mnt?
- Нам не удаётся создать route объект, хотя мы являемся владельцами
автономной системы, в чём причина?
- Зачем нужна ссылка mnt-routes?
- Как реализована защита от несанкционированного создания
route объектов?
- Зачем нужен maintainer (m.)?
m. необходим для защиты объектов в базе
данных RIPE (БД RIPE) и представляет из себя объект БД,
основным признаком которого является схема аутентификации;
при использовании ссылки на m. в каком-либо объекте
БД RIPE
(включая сам m.) объект считается защищенным от
несанкционированного изменения|удаления, при этом степень
защищенности определяется схемой аутентификации.
Применительно к регистрации доменов *RU "maintainer" - это служба
технической поддержки, что не противоречит вышеприведённому определению и
подчёркивает сущность защиты - кому доверена техническая поддержка
домена, тот и распоряжается соответствующими объектами в базе данных
домена RU.
- В каких объектах БД RIPE обязательно использовать ссылку
на m.?
Обязательно должны быть защищены следующие объекты: inetnum, route,
aut-num, as-set, route-set и др. (все -set объекты).
- Могу я обойтись без своего m. в БД RIPE?
Вы можете ставить ссылку на m., созданный RIPE, вот как она
будет выглядеть:
mnt-by: RIPE-NCC-NONE-MNT
- Как зарегистрировать m.?
Процедура регистрации для клиентов RU-CENTER описана здесь
здесь
Большинство maintainer'ов регистрируется службой поддержки базы
данных RIPE при подаче LIR'ом первой
заявки на IP-адреса,
поскольку теперь ссылка на maintainer ОБЯЗАТЕЛЬНА в объекте
*inetnum*.
Возможна регистрация maintainer'а при подаче
заявки на Автономную Систему, а
также отдельно, при условии, что maintainer будет использован для защиты
существующих объектов *inetnum*, *autnum*
Таким образом, для регистрации maintainer'а включите
объект maintainer
в раздел IV. Additional Information ПЕРВОЙ заявки от Вашей LIR
на IP-адреса.
- Что такое схема аутентификации m.?
аутентификация - идентификация, опознание.
Схема аутентификации m. - это способ проверки подлинности запроса
на изменение|удаление объекта БД RIPE, защищенного данным m.
Сейчас в БД RIPE используются следующие схемы
аутентификации (в порядке возрастания сложности):
- MAIL FROM
- CRYPT-PW
- PGPKEY
Cхема аутентификации устанавливается в поле auth объекта m.
- Почему в предыдущем ответе Вы не указали схему
аутентификации NONE?
Строго говоря, NONE не является схемой аутентификации, поскольку
при изменении|удалении объекта БД RIPE, защищенного m. с такой схемой
не происходит проверки подлинности запроса, все запросы выполняются.
Если в таком m. ещё и отсутствует поле mnt-nfy
(см. вопрос о письмах-уведомлениях БД RIPE) - владелец
m. не узнает о том, что защищённый им объект был изменён или
удалён.
- Что такое условия авторизации m.?
Авторизация - разрешение, утверждение.
Условия авторизации - условия, при которых происходит запрошенное
изменение|удаление объекта БД RIPE.
Например, при использовании схемы аутентификации MAIL FROM
проверяется совпадение e-mail адреса отправителя
запроса (берется из поля From:) и e-mail адреса,
указанного в поле auth объекта m. после
MAIL FROM.
- Можно ли использовать в одном m.
несколько схем аутентификации?
Можно, в этом случае достаточно, чтобы запрос на изменение|удаление
удовлетворял ЛЮБОМУ условию авторизации из числа допустимых в данном
m.
Обратите внимание на то, что использовать различные
схемы аутентификации в одном m. НЕ рекомендуется, поскольку
степень защищенности объекта будет определяться
наиболее простой схемой аутентификации m.
Явно не стоит совместно использовать схему MAIL-FROM
со схемой PGPKEY
- Можно ли защитить один объект с помощью
нескольких m.?
Можно, однако, так же как и при использовании нескольких схем
аутентификации в одном m., степень защищенности объекта будет определяться
наименее сложной схемой аутентификации m.
Если есть необходимость включить в существующий (уже защищенный
чужим m.) объект ссылку на наш m., это надо попросить
сделать владельца чужого m.
- Какие есть способы совместной с RU-CENTER защиты
объектов в БД RIPE?
Наиболее оптимальным является такой способ: к Вашему m. добавляется наша
схема аутентификации:
auth: PGPKEY-C396EEA0
Из ответа 8 следует, что мы на равных можем пользоваться Вашим m.
Как только Вы прекращаете сотрудничество с нами, Вы сами или мы (по
Вашей просьбе) убираем из объекта mntner вышеприведённое поле auth:
- Зачем нужна ссылка mnt-lower?
Если в объектах inetnum|domain использована ссылка mnt-lower
на некоторый m. - это означает, что при СОЗДАНИИ
объектов нижнего уровня (вложенности) по отношению к данному
потребуется, чтобы удовлетворялись условия авторизации m.,
на который стоит ссылка. На объекты следующего (вниз) уровня
это правило уже не распространяется. Например:
Объект
inetnum: 195.19.0.0 - 195.19.0.255
может завести только владелец ROSNIIROS-MNT
Но при наличии объекта
inetnum: 195.19.0.128 - 195.19.0.255
может завести каждый.
- Как осуществляется авторизация по MAIL FROM?
Проверяется совпадение e-mail адреса отправителя
запроса (берется из поля From:) и e-mail адреса,
указанного в поле auth объекта m. после MAIL FROM.
Допускаются символы расширения, например:
auth: MAIL FROM .*@nic.ru
означает, что условиям авторизации должны удовлетворять любые запросы,
отправленные с адресов домена nic.ru
- Как осуществляется авторизация по CRYPT-PW?
Проверяется совпадение пароля, указанного
отдельной строкой:
password: your_clear_text_password
в начале заявки и криптованного пароля, указанного в поле auth
объекта m. Над присланным паролем проводится операция
криптования с использованием алгоритма криптования
по секретному ключу (алгоритм DES, реализуемый функцией crypt)
Известно, что частью ключа являются два первых символа
закриптованного пароля (salt-последовательность).
Таким образом, получается искомый
криптованный пароль и если он совпадает с хранящимся в БД RIPE, то
запрос удовлетворяет условиям авторизации.
- Как получить криптованный пароль для схемы
аутентификации CRYPT-PW?
У Вас есть несколько путей:
- Если ваша версия perl поддерживает функцию crypt() с алгоритмом DES,
выполните следующую команду:
perl -e 'print crypt "password","salt", "\n"'
где "salt" - это последовательность из двух произвольно выбранных символов
- Если у Вас есть доступ к файлу паролей на машине под
управлением ОС UNIX, Вы можете использовать какую-либо
из программ (passwd, htpasswd), получающую пароли
по алгоритму DES, реализуемому функцией crypt(3)
Например, криптование слова "password"
с salt-последовательностью "sa" вышеописанными способами
приведет к такому результату:
sa3tHJ3/KuYvI
- Если perl не установлен на Вашей машине, воспользуйтесь программой
получения паролей (входит в пакет
клиента-whois
предлагаемой RIPE).
- Можно, наконец, выслать в RIPE заявку с незакриптованным паролем.
При создании m. пароль будет закриптован; имейте ввиду то, что
обращения в службы RIPE hostmaster|ripe-dbm архивируются и Ваш
пароль будет доступен работникам RIPE;
к незащищённым способам получения пароля также относится формирование
пароля на сервере RIPE: Crypt CGI Interface.
- Что проверяет тест-БД RIPE при попытке
создания m. c аутентификацией по схеме CRYPT-PW?
Проверяется, правильно ли Вы выполнили операцию криптования,
поскольку при криптовании по алгоритму DES, реализуемому функцией crypt, длина
закриптованного пароля составляет 13 байт.
Заявка должна быть отправлена по адресу: test-dbm@ripe.net
- Что делать, если пароль забыт?
Отправить письмо-объяснение по адресу: ripe-dbm@ripe.net
Вас скорее всего попросят продублировать письмо по факсу:
+31 20 535 4445
"For the attention of ripe-dbm"
На официальном бланке организации, с подписью администратора сети
(разборчивой), который зарегистрирован как admin-c или tech-c объекта
m., Вы просите заменить утерянный пароль на другой, указывая
причину замены пароля и приводя в письме оба объекта m. (существующий и
новый).
Постарайтесь не терять пароль; в качестве защитной меры можно
использовать две однотипных схемы аутентификации (в данном случае CRYPT-PW).
- В новой версии объекта maintainer появилось поле
refferal-by, поясните для чего оно предназначено
В поле refferal-by ставится ссылка на m. создателя данного
m. и никогда не меняется
Создатель может
внести необходимые изменения в m. в случае потери
контроля над m. его владельца, например, при утере владельцем
пароля. К сожалению, единственным создателем
всех m. пока является служба RIPE, что не вносит никакой
новизны в Ваши действия при утере пароля (см. предыдущий ответ).
- Что такое PGPKEY?
PGPKEY в данном случае - это public ключ, один из
пары ключей, используемых алгоритмом криптования PGP.
PGP криптование предполагает использование двух
ключей - public и private.
БД RIPE в схеме аутентификации PGPKEY используется
электронная подпись запроса, которая формируется с
помощью private ключа отправителя запроса.
Подпись будет содержать контрольные параметры письма
(размер, дату, адрес отправителя) и идентификатор
public ключа (PGP public key ID).
- Как осуществляется авторизация по PGPKEY?
Проверяется совпадение присланного (содержится в
электронной подписи запроса) идентификатора
public ключа с идентификатором, указанным в объекте m.,
в поле auth, после PGPKEY-
Например, в m. ROSNIIROS-MNT:
mntner: ROSNIIROS-MNT
auth: PGPKEY-C396EEA0
используются идентификатор public ключа: C396EEA0
Извлечение идентификатора public ключа из подписи происходит
путем ее декодирования PGP-программой с помощью public
ключа, указанного в объекте key-cert
- Зачем нужен объект key-cert в БД RIPE?
Данный объект RIPE БД хранит информацию о public
ключе и его идентификаторе и используется при
проверке подлинности запроса при авторизации PGPKEY
Например, для идентификатора public ключа C396EEA0 в БД RIPE
заведен объект:
- Отличается ли чем-нибудь заведение route объектов (объектов
маршрутизации) в БД RIPE от остальных?
Ключом route объекта являются одновременно два поля: route и origin.
В поле route указывается диапазон адресов, за маршрутизацию которых в
Интернет будет отвечать автономная система, номер которой указан в
поле origin.
Использование ссылки на объект autnum (автономная система), а значит
и создание route объекта невозможно, если заявка не удовлетворяет
условиям авторизации m., защищающего объект aut-num.
Так реализована первичная защита от несанкционированного создания
route объекта.
Например, для создания такого объекта:
route: 195.19.0.0/19
origin: AS3316-MNT
должны удовлетворятся условия авторизации m., защищающего
объект AS3316-MNT:
auth: MAIL-FROM .*@Relarn\.ru
- Защищен ли объект, если в нем указана ссылка notify?
Нет, не защищен. Такой объект может быть изменен|удален
каждым; при этом по e-mail адресу, указанному в поле
notify, придет уведомление от БД RIPE о том, кто и когда работал
с объектом.
- Почему я получаю письма-уведомления от БД RIPE, когда
объектов не создавал?
Уведомление отправляется по e-mail адресам, указанным в поле
notify созданного объекта и в поле mnt-nfy m., если на m.
поставлена ссылка в объекте. Например:
Таким образом, при указании ссылки на ROSNIIROS-MNT
уведомление о созданном объекте отправится по адресу:
ip-reg@nic.ru
По адресу, указанному в поле upd-to, уходят уведомления о
том, что запрос на изменение|удаление объекта, защищенного m.
не удовлетворил условиям авторизации m.
- Можем ли мы использовать для защиты объектов
поля cross-nfy, cross-mnt?
Эти поля предназначены только для объектов routing registry:
autnum, route
cross-nfy ссылается на person|role объект (по nic-handl'у), а cross-mnt
ссылается на объект m.
Смысл ссылки в route объекте - высылать уведомления по e-mail адресу данного
person'а (role) или по e-mail адресу, указанному в поле mnt-nfy
объекта m. в случае
создания в БД RIPE пересекающихся route объектов.
Если ссылка установлена на некотором объекте autnum,
уведомления будут высылаться при создании route пересекающегося с
route, в поле orgigin которого и стоит ссылка на данный объект
autnum
- Нам не удаётся создать route объект, хотя мы являемся
владельцами автономной системы, в чём причина?
Наиболее вероятной причиной ошибки при создании route объекта,
о которой RIPE база сообщает как
"hierarchical authorisation failed" является отсутствие в объекте *inetnum*,
описывающем Ваш блок адресов (allocation), ссылки на Ваш m.
Вам необходимо добавить (при помощи службы hostmaster@ripe.net) к
данному объекту поле mnt-lower или поле mnt-routes с указанием Вашего m.
Скорее всего, Вы получали блок адресов довольно давно, когда в RIPE базе ещё
не была реализована дополнительная защита от несанкционированного создания
route объектов, а route объект не создавали, поэтому данная ошибка выявилась
только сейчас.
- Зачем нужна ссылка mnt-routes?
При наличии в объекте *inetnum* ссылки mnt-routes на некоторый m.,
его владельцу разрешено создавать route объект, задействующий диапазон
IP-адресов объекта *inetnum*. Если ссылка mnt-routes использована в
объекте aut-num, владельцу данного m. разрешено создавать
route объект с указанием в поле origin номера данной автономной системы.
- Как реализована защита от несанкционированного
создания route объектов?
Допустим Вы получили блок адресов и номер автономной системы. Отправляете
заявку для создания *route* объекта. База последовательно осуществляет
следующие проверки:
- удовлетворяются ли условия авторизации m., указанного
в поле mnt-routes существующего объекта *aut-num*, на который Вы ссылаетесь
в поле origin
- если поле mnt-routes в вышеуказнном объекте *aut-num* отсутствует,
проверка осуществляется для m., указанного в поле mnt-by
- удовлетворяются ли условия авторизации m., указанного в поле
mnt-routes, в существующем объекте *route*, совпадающим
по диапазону адресов с диапазоном создаваемого объекта *route*
- если поле mnt-routes в вышеуказнном объекте *route* отсутствует,
проверка осуществляется для m., указанного в поле mnt-by
- удовлетворяются ли условия авторизации m., указанного в поле
mnt-routes, в существующем объекте *route*, диапазон адресов которого,
перекрывает диапазон создаваемого объекта *route* (less specific route)
- если поле mnt-routes в вышеуказнном объекте *route* отсутствует,
проверка осуществляется для m., указанного в поле mnt-lower
- если поле mnt-lower в вышеуказнном объекте *route* отсутствует,
проверка осуществляется для m., указанного в поле mnt-by
Проверки 3,4,5,6,7 осуществляются и для двух объектов *inetnum* (с совпадающим и
перекрывающим диапазонами).
Если при любой из проверок условия авторизации не удовлетворяются, заявка
на создание *route* объекта отклоняется.
|
По вопросам распределения IP-адресов:
|
