Inet-Admins mailing list archive (inet-admins@info.east.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[inet-admins] Secondary NS management WWW-interface
Hi!
Раз уж я написал это глюкало - может кто-то захочет
попользоваться и найдет ошибки/проблемы.
ftp://ftp.lexa.ru/pub/domestic/lexa/secnsmgr-1.0.tar.gz
Вот README:
SNS-ADMIN - Secondary NameService Administrator
(C) 1997 by Alex Tutubalin, <lexa@lexa.ru>
Краткое описание.
Удаленное администрирование named.boot - позволяет удаленному пользователю
менять в ограниченных пределах ваш named.boot. Программа предназначена для
облегчения обмена secondary NS - при заведения очередной зоны вам не
понадобится писать письма второй стороне, а все можно будет сделать через
WWW.
1. Лицензия и гарантии.
Никаких гарантий, как обычно, не предоставляется. Вы можете использовать
эту программу для любой цели. Если вы модифицируете ее, то пришлите мне
правки пожалуйста. Никаких других ограничений не накладывается.
Никакой поддержки не обещается.
2. Что это такое.
Это программа, позволяющая модифицировать /etc/named.boot на удаленной машине
не имея на это привилегий root'а :)
Программа состоит из двух частей:
A. скрипт sns-admin.pl - позволяет пользователю (-лям) модифицировать
"свои куски" named.boot - добавлять/удалять и модифицировать строчки
secondary some.domain i.p.add.res file.to.save в named.boot. При этом
реальной модификации named.boot не производится. Умеет генерировать
"кусочки" в формате named 4.9 и 8.1
Б. файл Makefile.namedboot - это пример того, как с помощью make можно
перезапустить (ndc reload) named, если какая-то часть named.boot
(включае includes) менялась. Возможны два способа изготовления
named.boot:
а) все "пользовательские" файлы включены в /etc/named.boot
директивой include. Тогда при изменении набора secondary
достаточно команды ndc.reload (см. target reload в Makefile.namedboot)
б) /etc/named.boot собирается из мастер-файла (в примере -
/etc/namedb/named.boot.master) и пользовательских файлов.
Способ а) удобнее т.к. можно редактировать сам named.boot, способ б)
несколько безопаснее т.к. реальный named.boot будет создан из
пользовательских файлов только при запуске make, а при 'ndc reload'
запущенном "просто так" будет использован неизмененный /etc/named.boot
3. Как это поставить:
A. Вам будут нужны: perl 5.00x (проверялось с perl 5.004.4),
пакеты для Perl - CGI_Lite и Net::DNS. Ну и естественно make.
Б. Нужно скопировать sns-admin.pl куда-то в отдельную директорию
на WWW-сервере. Для этой директории желательно максимально ограничить
доступ - защитить ее паролем и разрешить заход на нее только с
фиксированных IP-адресов. Для apache это может выглядеть как-то так
<Directory /where/my/sns-admin.pl>
Order allow,deny
allow from 192.168.1.1 over.ns.exchanger.ip and.so.on.ru
AuthType Basic
AuthUserFile /export/www/dns-pass/dns-pass
AuthName login
require valid-user
</Directory>
Файл dns-pass (в данном примере) создается программой htpasswd
(формат - как первые два поля /etc/passwd). Подробнее - см. документацию
на ваш WWW-server.
В самом скрипте редактируются переменные настройки, находящиеся
там в самом начале. Они задают output directory, версию named,
адрес, по которому писать почту (если писать) и набор security-
settings - список разрешенных и запрещенных зон, список разрешенных
и запрещенных IP-адресов для Nameservers.
Б. Makefile.namedboot нужно подредактировать в соответствии с реалиями
и поместить вызов make -f /where/is/Makefile.namedboot в /etc/crontab
или куда-то в этом духе (правильно запускать ея раз в несколько часов).
4. Security.
Security распадается на две независимые подзадачи:
1) обеспечение того, чтобы никто посторонний не подредактировал файлики
с данными (локально или через WWW). Проблема заключается в том, что
файлы данных должны быть writable для процесса WWW-сервера. Это неприятно
т.к. он обычно работает от nobody. Если это является препятствием, то
можно попробовать использовать suEXEC от apache или что-то в этом духе.
Защищенность от remote-нехороших людей. Обеспечивается в первом приближении
средствами WWW-сервера. Сколько-нибудь серьезную защиту может обеспечить
только SSL, на мой взгляд (т.е. нужно заводить свою CA, либо доверять
уже известным, ставить Apache-SSL или аналог и пускать к скрипту только
тех, кто предъявил valid certificate).
2) Защита от ошибок valid users. Обеспечивается в некотором объеме в
скрипте. Скрипт проверяет:
- имя зоны на "разумные символы" (разрешены a-zA-Z0-9._-/)
- имя зоны на вхождение в список разрешенных (или невхождение в список
запрещенных) доменов.
- IP-address primary - на то, что это IP-address
- вхождение/невхождение IP-адреса primary в списки разрешенных/запрещенных
IP-адресов
- Если добавляемая/редактируемая зона уже имеет NS, доступные для
resolver'а на данной машине, то эти NS проверяются на соответствие
вводимым данным.
- Для зоны проверяется наличие SOA-записи на NS, указанном в качестве
primary.
- Про все измерения пишется почта администратору.
Списки для разрешенных/запрещенных имен доменов проверяются на
соответствие имени новой зоны regexp /^\S+$name_from_list$/. Т.е.
зона bbb/ru будет разрешена если в permitted_list=("ru") и
не разрешена, если в permitted_list=(".ru")
IP-адреса проверяются на соответствие маске "4 числа от 0 до 255 разделынных
точками". Permitted/denied lists проверяются по regexp /^$name_from_list\S+$/
Естественно, все эти проверки неполны, но что вы хотите от скрипта,
написанного на коленке за 2 часа ?
Alex Tutubalin, 31 Oct - 1 Nov 1997
=============================================================================
"inet-admins" Internet access mailing list. Maintained by East Connection ISP.
Mail "unsubscribe inet-admins" to Majordomo@info.east.ru if you want to quit.
|
