Руководство системного администратора • третье издание { h h y с п п т п р



Pdf просмотр
страница42/82
Дата12.11.2016
Размер7.94 Mb.
Просмотров13857
Скачиваний0
ТипРуководство
1   ...   38   39   40   41   42   43   44   45   ...   82
A >480
Чость II Роботов сетях
ndc reload, которая заставит его связаться с главным сервером, убедиться в том, что данные изменены, и запросить пересылку зонных данных. При изменении имени или адреса компьютера ие забывайте модифицировать зоны как прямого, таки обратного преобразования. Если забыть о файлах, в которых хранятся данные для обратного преобразования, это приведет к появлению скрытых ошибок некоторые комал-ы будут работать, а некоторые — нет. Если изменить файлы данных, ноне обновить порядковый иомер в записи SOA, то изменения вступят в силу только иа главном сервере (после перезагрузки, но иена подчиненных. Не следует редактировать файлы данных, относящиеся к подчиненным серверам. Эти файлы ведет сам демон named; системные администраторы не должны вмешиваться в его работу. Лучше всего только просматривать файлы данных, не делая в них никаких измеиений. По этим файлам часто можно обнаружить скрытые ошибки конфигурации. Например, досадный пропуск точки, который можно запросто не заметить в файлах конфигурации главного сервера, может привести к появлению в файле данных подчиненного сервера явно ложного элемента наподобие f о о . c s . C o l o r a d o . e d u . c s . C o l o r a d o . e d u Документ RFC2136 разрешает производить зонные изменения через библиотеку функций. Эта возможность называется динамическим обновлением оио необходимо для протоколов автоматического конфигурирования, таких как DHCP. О том, как работает данный механизм, речь пойдет чуть ниже. Зонные пересылки Серверы DNS синхронизируются посредством механизма зонных пересылок. В исходной спецификации DNS ив) требовалось, чтобы все данные, относящиеся к той или иной зоне, пересылались одновременно.
Инкремеитные обновления были определены в документе R FC1995 и реализованы в BIND 8.2. Подчиненный сервер, который хочет обновить свои данные, запрашивает зонную пересылку с главного сервера и создает резервную копию данных иа диске. Если данные на главном сервере не изменились, что можно определить путем сравнения порядковых номеров (не самих данных, корректировка не производится и резервные копии файлов практически остаются без изменений лишь время их модификации устанавливается равным текущему времени. Зонные пересылки осуществляются по протоколу TCP через порт 53. Соответствующее событие регистрируется системой Syslog с пометкой '"named- xfer". Организация IETF определила, что инкремеитные обновления могут производиться либо по протоколу TCP. либо UDP. нов реализован лишь первый вариант Вовремя зонной пересылки и передающий, и принимающий серверы остаются доступными для запросов. Подчиненный сервер начинает использовать новые данные только после завершения всей операции. В BIND 8 пересылка осуществляется путем вызова отдельной программы named-xfer, а в BIND 9 демои named управляет дайной операцией напрямую. Как следствие, параметр n a m e d - x f e r , определявший путь к одноименной программе, перестал поддерживаться в конфигурационном файле BIND 9.
Глово 16. Системо доменных имен
481
Если зона очень велика (например, "com") или обновляется динамически см. следующий раздел, объем изменений обычно мал в сравнении с размером всей зоны. В этом случае используются инкрементные обновления, при которых пересылаются только изменения (в том случае, когда ишенення превышают размер зоны, производится обычная зонная пересылка. Этот механизм напоминает программу patch: старая база данных сравнивается и синхронизируется с новой. В BIND 8 для включения инкрементных зонных пересылок следует указать демону named на необходимость ведения журнала транзакции (это делается в глобальной секции o p t i o n s ) , а затем установить соответствующим атрибут в инструкции s e r v e r любого сервера, которому нужны такие пересылки. Конфигурационные строки выглядят так m a m t a i n - i x f r - b a s e t r u e ; # в секции options s u p p o r t - i x f r t r u e ; t в инструкции s e r v e r Если требуется изменить стандартные имена журнала транзакции и временного файла, используемого при инкрементных пересылках, разместите в инструкции zone следующие директивы i x f r - b a s e и
иыя_файла"; # в инструкции гопе i x f r - t m p - f i l e "имя файла": # в инструкции zone В BIND 9 инкрементные пересылки поддерживаются по умолчанию для любой зоиы, сконфигурированной на прием динамических обновлении, а демон named самостоятельно ведет журнал транзакций. В инструкции s e r v e r теперь поддерживаются две отдельные директивы p r o v i d e - i x f г и • - q u e s t - i x f r . Первая включает или отключает механизм инкрементных пересылок для зои, в которых сервер является главным. Вторая делает тоже самое для тех зон, где сервер является подчиненным p r o v i d e - i x f r yes; # в инструкции server r e q u e s t - i x f r yes; f в инструкции server Пакет BIND не работает с зонами, которые одновременно могут обновляться динамически и редактироваться вручную. Сервер BIND 9 может инициировать инкрементную пересылку в результате динамического обновления или другой поступившей пересылки, ноне тогда, когда изменения вызваны редактированием зонных файлов. Вероятно, эта возможность появится в следующих версиях пакета. Было проделано много работы, чтобы в случае краха сервера вовремя инкрементной пересылки зонные данные ие превращались в мусор. Запрос иа инкрементную пересылку к серверу, который не поддерживает данный механизм, будет автоматически преобразован в обычный запрос иа обновление. Динамические обновления Система DNS основана на предпосылке, что соответствия между именами и адресами относительно стабильны н меняются нечасто. Но это правило постоянно нарушается, если в организации используется протокол DHCI* и при подключении к сети компьютеру динамически назначается адрес Имеется два классических решения добавить обобщенные записи п базу данных DNS или непрерывно редактировать файлы. В большинстве случаев ни одно из решений не является удовлетворительным.
482
Чость II. Робото о teifix
Первое решение должно быть знакомо каждому, кто имеет удаленный доступ к Internet. Конфигурация DNS в этом случае выглядит примерно следующим образом d h c p - h o s t l . d o m a i n . I N А 1 9 2 . 1 6 8 . 0 . 1 d h c p - h o s t 2 . d o m a i n . I N A 1 9 2 . 1 6 8 . 0 . 2 Это простое решение, но оно означает, что указанные имена постоянно связаны сданными адресами, а компьютер, получающий новый адрес, меняет имя В такой среде трудно соблюдать требования безопасности, да и просто регистрироваться в системе под определенным именем. Механизм динамических обновлений, появившийся в последних версиях
BIND, предлагает альтернативное решение. Он позволяет демону DHCP уведомлять сервер BIND о сделанных адресных назначениях, обновляя таким образом содержимое базы данных DNS "иа лету. Имеется также интерфейс командной строки, даюший возможность выполнять динамические обновления вручную. Посредством данного механизма можно добавлять, удалять и модифицировать записи о ресурсах. Глубина обновлений — зона. Немного страшно разрешать динамические обновления всей базы данных DNS, поэтому многие организации создают поддомен (скажем, d h с р. организация) и осуществляют динамические обновления только в его пределах. Динамические обновления зоны разрешаются в файле named.conf посредством директивы а 1 l o w - u p d a t e . После того как зона была динамически обновлена, ее нельзя редактировать вручную — нужно сначала остановить сервер BTND, чтобы текущая копия базы данных была записана на диск. Затем можно отредактировать зонный файл и перезапустить демон earned. Естественно, исходное форматирование зонного файла будет разрушено (он будет выглядеть как файл, который ведется демоном named на подчиненных серверах)
Инкремеитные зонные пересылки по умолчанию поддерживаются для зон, в которых используются'динамические обновления. Но через механизм инкрементных пересылок не распространяются изменения зоиы, осуществляемые посредством ручного редактирования главного файла, даже если остановить демон named, отредактировать зонный файл и затем перезапустить демон.
16.13. Вопросы безопасности
DNS по своей сути — открытая система. Именно такой — открытой — она вышла в свет, нов процессе своего развития приобретала все больше средств зашиты или, по крайней мере, становилась более защищенной. По умолчанию каждый, у кого есть доступ в Internet, может исследовать чужой домен отдельными запросами с помощью таких утилит, как dig, hosl или nslookup. В некоторых случаях можно получить дамп всей базы данных DNS. Для устранения этих недостатков в последние версии BIND были введены различные средства управления доступом, основанные на проверке адресов или криптографической аутентификации. В табл. 16.10 перечислены элементы подсистемы безопасности, которые настраиваются в файле named.conf.
Глово 16. Системо доменных имен
483
Таблица 16.10. Средство эощиты в фойпе nomed.conf Средство Инструкции Что определяет
— a l l o w - q u e r y o p t i o n s , zone a l l o w - t r a n s f e r o p t i o n s , zone a l i o w - u p d e t e zone b l a c k h o l e o p t i o n s bogus a c l s e r v e r v a r i o u s Кто может посылать запросы зоне или ссрнеру Кто может запрашивать зонные пересылки Кто может делать динамические обновления Какие серверы нужно полностью игнорировать Какие серверы никогда нельзя опрашивать Списки управления доступом Демон named может функционировать в среде, где корневой каталог изменен с помощью команды chroot. и при этом иметь непривилегированный идентификатор пользователя. Таким образом, устраняется малейшая вероятность разрушений, вызванных неконтролируемыми лействияуш со стороны с'перпользователя. Благодаря сигнатурам транзакций демон способен контролировать динамические обновления И конечно же. он полностью поддерживает спецификацию D N S S F C Обо всем этом речь пойдет в следующих разделах. Еще роз о списках управления доступом Список управления доступом — это именованный список соответствия адресов, который может служить аргументом различных директив, в частности a l l o w - q u e r y , a l l o w - t r a r . s f e r и b l a r k h o l e . Они позволяют справляться с такими нарушениями зашиты DNS. как имитация доменного имении атака вида "отказ от обслуживания. Синтаксис списков был рассмотрен при описании инструкции a c l в параграфе 16.9. В каждой организации должен существовать по крайней мере один такой список для недоступных адресов и один — лля локальных. Например a c l o o g u s n e t s \
0 . 0 . 0 . 0 / 8 ;
1 6 9 . 2 5 4 . 0 . 0 / 1 6 ;
1 9 2 . 0 . 2 . 0 / 2 4 ;
2 2 4 . 0 . 0 . 0 / 3 ;
1 0 . 0 . 0 . 0 / 8 ;
1 7 2 . 1 6 . 0 . 0 / 8 ;
1 9 2 . 1 6 8 . 0 . 0 / 1 6 ;
) ;
/ / список недоступных и фиктивных сетей адреса с полета ново ч н ы ми знаками хама ль но- локальные делегируем ы е адресате сто вы е адреса, наподобие пространство групповых адресов частное адресное пространство частное адресное пространство частное адресное пространство l c u n e t s 1 1 2 8 . 1 3 8 . 0 . 0 / 1 6 ;
1 9 8 . 1 1 . 1 6 / 2 4 ;
2 0 4 . 2 2 8 . 6 9 / 2 4 ;
/ / список сетей университета штата Колорадо основная кампус на я сеть
Каиальио-локальные адреса используются компьютерами Macmrosh и персональными компьютерами, которые должны работать по протоколу LP. ноне могут найти сервер DHCP. В этом случае они просто назначают себе адрес из сети 169.254.0-0/16. Адреса в данном диапазоне должны жестко фильтроваться, чтобы несущие их пакеты никогда не смогли выйти за пределы локальной кабельной системы. Кабельные и модемы также начинают пользоваться этим адресным диапазоном. Не делайте частные адреса недоступными, если они используются для конфигурирования внутренних серверов
484
Чость II Робота в сет
Далее нужно в глобальной секции o p t i o n s конфигурационного файла разместить следующие директивы a l l o w - r e c u r s i o n { сип е . з ; ) / b l a c k h o l e г b o g u s n e t s ; Также желательно ограничить зонные пересылки только легитимными подчиненными серверами. Это достигается с помощью приведенных ниже списков a c l o u r s l a v e s {
1 2 8 . 1 3 В - 2 4 2 . 1 ; a n c h o r
):
a c l m e a s u r e m e n t s {
1 2 8 . 9 . 1 6 0 . 1 5 7 ;
1 9 8 . 3 2 . 4 . 0 / 2 4 ;
1 9 2 . 5 . 5 . 0 / 2 4 ; Собственно ограничение реализуется такой строкой a l l o w - t r a n s £ e r ( o u r s l a v / e s ; s u г е г г . е п t з ; Пересылки разрешены только нашим подчиненным серверам, а также компьютерам двух глобальных исследовательских проектов, которые посвяшены определению размеров сети Iniernei и процента неправильно сконфигурированных серверов Подобное ограничение лишает остальных пользователей возможности получать дамп всей базы данных посредством утилиты n.slookup. dig или host. Например
% n s l o o k u p
D e f a u l t S e r v e r : иы.ч сервера
A a o r e s s : адрес сервера
> I s c s . C o l o r a d o . e d u .
[пил сервера
C a n ' t l i s t d o m a i n c s . c o _ o r a d o . e a . . : U n s p e c i f i e d e r t o :
По-прежнему нужно защищать сеть на более низком уровне с помошью списков управления доступом на маршрутизаторе и стандартных средств зашиты на каждом узле. Если такой возможности нет. ограничьте график пакетов шлюзовой машиной, которая находится под постоянным административным контролем Ограничение возможностей демона n a m e d Чтобы предотвратить ущерб, который может быть нанесен в случае а гаки на сервер, можно запустить демон named в среде с измененным корневым каталогом и'или от имени непривилегированного пользователя. Флаг -1 задает корневой каталог для демона, а флаги -в И -g — значения UID и G1D присваиваемые процессу named. Последний из перечисленных ф лаю вне поддерживается в BIND 9. К примеру, команды
# n a m e d - ив'
4 n a m e d - u 5 3 - t / v a r / n a m e d ' BIND 9 *
// проект Билла Маннинга
// проект Билла Кап ниша
// проект Марка Лотторза
Глово 16. Системо доменных имен
485
запускают демон с идентификатором пользователя 53. идентификатором группы 53 (только в BIND 8) и корневым каталогом /var/named. Новый корневой каталог не может бьггь пустым, так как он должен содержать все файлы, необходимые для нормальной работы демона named:
/dev/null, библиотеки совместно используемых функций, зонные файлы, named.conf и т.д. Если скомпилировать демон так, чтобы библиотеки компоновались статически, тоне придется думать, какие библиотечные файлы копировать в каталог /var/named Хакер, взломавший демон named, получает доступ к системе от именитого пользователя, который осуществил запуск демона. Если это пользователь root и корневой каталог не был изменен, последствия могут оказаться разрушительными. Многие администраторы не заботятся об использовании флагов -и. -g и -t. нов таком случае они должны быстрее ставить "заплаты, чем хакеры будут атаковать систему в случае обнаружения очередной "дыры. Безопасные межсерверные взаимодействия посредством спецификаций TSIG и TKEY Пока спецификация DNSSEC (описана в следующем разделе) находилась в стадии принятия, организация IETF разработала более простой механизм, названный TSIG (RFC2845). Он позволял организовывать безопасное взаимодействие серверов благодаря использованию сигнатур транзакций. Контроль доступа, основанный на таких сигнатурах, надежнее, чем контроль на основании исходных адресов. В сигнатурах транзакций применяется симметричная схема шифрования, те. ключ шифрования тот же. что и ключ дешифрования. Такой ключ называется совместным секретным ключом. Для каждой пары серверов, которые хотят организовать защищенный канал взаимодействия, должен использоваться друой ключ. Спецификация TSIG гораздо менее затратна в вычислительном плане, чем шифрование с открытым ключом, но она подходит только для локальной сети, где число пар взаимодействующих друг с другом серверов невелико. На глобальную сеть эта спецификация не распространяется. Сигнатурами TSIG подписываются запросы и ответы на них. Они передаются только между серверами, ноне между сервером и распознавателем. Сигнатура проверяется в момент поступления пакета и тут же отбрасывается она не сохраняется в кэше и не становится частью базы данных DNS. Спецификация TSIG допускает применение различных методов шифрования, нов реализован лишь один из них алгоритм НМАС-
MD5. Утилита dnssec-keygen". являющаяся частью пакета BIND, генерирует ключ для пары серверов. Например, если имеются два сервера, сере! и серь2.
команда
* dnaaac-keygen -Н В -h -п серв1-серв2
создаст разрядный ключи сохранит его в файле Kcepel-сере2+157 4
00000. pri - vate. В этом файле содержится строка "Key:", за которой Следует собственно ключ, закодированный по основанню 64.
Сгенерированный ключ представляет собой всего лишь длинное случайное число. Создать ключ можно вручную, записав строку нужной Вона называется dnskeygen.
4Ь6
Чость II. Роботов сетях

0
k e y s e r v l - s e r v 2 { a l g o r i t h m h m a c - m d 5 ; s e c r e t " с г е и ер и ров а нний_ключ";
1; Режим доступа к файлу должен быть 600, а идентификатор его владельца — таким же. как и у демона named. В файл named.conf, ближе к началу, нужно добавить следующую строку i n c l u d e " s e r v l - s e r v 2 . k e y " ; На данном этапе был лишь определен сам ключ. Чтобы его можио было использовать для подписи и проверки обновлений, следует заставить каждый сервер идентифицировать другую сторону посредством директивы k e y s . Для этого необходимо в файл named.conf первого сервера включить строки s e r v e r адрес_серв2 [
k e y s { s e r v l - s e r v 2 ; ) ;
) ; и аналогично в файл named.conf второго сервера — такие строки s e r v e r адрес_серв1 {
k e y s { s e r v l - s e r v 2 ; } ;
):
Любые предложения a l l o w - q u e r y , a l l o w - t r a n s f e r ив инструкции z o n e также должны ссылаться на ключ, например a l l o w - t r a n s f e r I k e y s e r v l - s e r v 2 ; 1 ; Если вы впервые имеете дело с сигнатурами транзакций, запустите демон aamed на какое-то время на уровне отладки I <о режиме отладки рассказы- вается в параграфе 16.14) и посмотрите, не будут ли выданы сообщения об ошибках. Старые версии пакета BIND не понимают подписанных сообщений и генерируют сообщения об ошибках, иногда даже отказываясь загружать зонные данные.
TKEY — это механизм в BIND 9. позволяющий двум узлам автоматически генерировать совместный секретный ключ без телефонных звонков и удаленного копирования ключа. При этом используется алгоритм обмена ключами Диффи-Хеллмана, в котором каждая сторона создает случайное длины и притворившись, что она закодирована по основанию 64. Можно также воспользоваться утилитой mmencode для кодирования произвольной строки. Способ создания ключа не важен; главное, чтобы он существовал иа обеих машинах.
Скопируйте ключ на оба сервера посредством команды scp л и б о вырежьте и вставьте его в нужном месте. Не используйте программы telnet и ftp для копирования ключа даже внутренние сети могут быть небезопасными Ключ должен присутствовать в файле named.conf на обеих машинах. В связи стем, что этот файл является общедоступным, а ключ — нет, поместите ключ в отдельный файл, который будет подключаться к файлу named.conf посредством инструкции i n c l u d e .
Команда scp является частью пакета SSH; см. параграф 21.8.
Например, можно создать файл servl-serv2.key и включить в него такой фрагмент
Глово 16. Системо доменных имен . 4 8 7
число, выполняет нал ним определенные математические операции и посылает результат противоположной стороне. Полученное число заданным образом объединяется с имеющимся, и получается один и тот же ключ. Человек, прослушивающий линию, будет *нать о содержании сеанса, ноне сможет выполнить обратные математические преобразования. Технология D N S S E C
DNSSEC — это набор расширений DNS. позволяющих аутентифициро- вать источник происхождения зонных данных и проверить их целостность, используя шифрование с открытым ключом Таким образом, DNSSEC дает возможность клиентам задавать вопросы вида "Действительно ли зонные данные поступили от владельца зоны" и "Те ли это данные, которые послал владелец.
DNSSEC предлагает три разных сервиса распределение ключей посредством записей KEY, хранящихся в зонных файлах, проверка подлинности серверов и данных, а также проверка целостности зонных данных. Система основана на цепочке доверия корневые серверы предоставляют подтверждающую информацию для доменов верхнего уровня, те — для доменов второго уровня и т.д. В системах шифрования с открытым ключом имеется два ключа один шифрует (подписывает) сообщение, а другой дешифрует (проверяет) его Опубликованные данные подписываются секретным "личным" ключом Любой может проверить правильность сигнатуры с помошью "открытого" ключа, который свободно распространяется. Если открытый кпюч правильно расшифровал зонный файл, значит, зона была зашифрована соответствующим личным ключом. Суть в том, чтобы убедиться в подлинности открытого ключа, используемого для проверки. Подобные системы шифрования позволяют одной из сторон поставить свою "подпись" на открытом ключе, передаваемом другой стороне, гарантируя таким образом легитимность ключа. Отсюда термин "цепочка доверия' Данные, составляющие тону, чересчур велики для шифрования с открытым кпючом: процесс шифрования получится слишком медленным Вместо этого, поскольку данные сами по себе не секретны, над ними выполняется хэш-кодирование (к примеру, используется контрольная сумма
MD5), а результат подписывается (шифруется) секретным ключом зоны. Полученный шшифропанпый хэш-код называется цифровой подписью или сигнатурой. Цифровые под i шеи обычно присоединяются к данным, подлинность которых они устанавливают. Для проверки сигнатуры ее нужно дешифровать открытым ключом подписавшего, прогнать данные через гот же алгоритм х^ш-кодирования и сравнить вычисленный ли код с расшифрованным. В случае совпадения подписавшее лицо считается аутентифипированным. а данные — целостными. В DNSSEC каждая зона имеет свои открытые н секретные ключи Секретным ключом подписывается кажлыи набор ресурсов (те. всякий набор записей одного типа, относящихся к одному узлу. Открытый ключ используется для проверки ситпатур и включается в зонную базу данных в виде записи KEY.
* В основе методики лежи г тот факт, что в модульной арифметике возведение в степень — легкая операция, а найти логарифм, чтобы определить степень, почти невозможно.
4Ь6
Чость II. Роботов сетях
Родительские юны подписывают открытые ключи своих дочерних зон. Демон named проверяет подлинность записи КЕ
1
* дочерней зоны, сравнивая ее с сигнатурой родительской зоны. Для проверки подлинности последней демон обращается к родительской зоне более высокого уровня и т.д. вплоть до корневой зоны. Fe открытый ключ имеется в файле корневых "подсказок. Для создания и использования подписанных зон требуется пройти несколько этапов. Сначала нужно сгенерировать пару ключей для зо!Ш. Это делается с помощью такой команды в B I N D 9:
* d n e s e c - k e y g e n - a DSA - b 7 6 8 - n ZONE m y d o m e i n . c o m .
ИЛИ В BIND 8
* d n s k e y g e n - D 7 6 B - z - n m y d o m a i n . c o m . В табл. 16 11 описано назначение аргументов JTHX команд.
Тоблицо 16.11. Описоние орг/ментов команд dnssec-keygen и dnskeygen Аргумент Назначение Для

И с пользование алгоритма
7 6 8 Создание битовой пары ключей. со г . Создание ключей для зоны Для Использование алгоритма D S A с 7 6 8 - разрядным ключом
-z
С о здание ключа зоны. Создание ключей для зоны Команды dnssec-keygen и dnskeygen возвращают следующий результат a l g 0 0 3 k e y i d e n t i f i e r f l a g s - 1 6 6 4 1 Они также создают файлы, содержащие открыгьп"! и секретный ключи
K m y d o m a i n . c o m . + 0 0 3 + 1 2 3 4 5 . k e y # о г крытый ключ
K m y d o m a i n . c o m . + 0 0 3 + 1 2 3 4 5 . p r i v a t e « секретный ключ Файл открытого ключа обычно включается в зонный файл с помошью директивы $ INCLUDE. Чаше всего он идет сразу же после записи SO А. Технология DNSSEC основана на принципе цепочки доверия, те открытый ключ зоны должен быть подписан ее родительской зоной, чтобы считаться гарантированно надежным. В BIND 8 нет механизма, который заставил бы родительскую зону подписать ключ дочерней зоны единственный выход — взаимодействие администраторов. В BIND 9 имеется программа dnssec-makekeysel. упрощающая этот процесс. Программа dnssec-makekeysel упаковывает ключи, которые нужно подписать (это могут быть не только зонные ключи, устанавливает значение ITL для полученного набора, залает период действия сигнатуры, а затем посылает пакет в родительскую зону на подпись. Например, команда
• d n s c e c - m a J c e k a y s e t - t 3 6 0 0 + В 6 4 0 0 0
K m y d o m a i n . c o m . + 0 0 3 + 1 2 3 4 5
Гпово 16 Сисгемо домеичы> имен



Поделитесь с Вашими друзьями:
1   ...   38   39   40   41   42   43   44   45   ...   82


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал