Брандмауэры и специальное программное обеспечение



Pdf просмотр
страница35/42
Дата15.02.2017
Размер6.16 Mb.
Просмотров3146
Скачиваний0
ТипАнализ
1   ...   31   32   33   34   35   36   37   38   ...   42
Замечания, связанные с suEXEC
Программа suEXEC — это оболочка, которая позволяет запускать программы от лица пользователя, отличающегося от пользователя, от лица которого запущен web-сервер. При нормальном функционировании все программы запускаются на уровне привилегий пользователя, от лица которого запущен web-сервер. В случае использования конфигурации, описанной ранее в данной главе, три четверти программ работают на уровне привилегий пользователя nobody. В некоторых ситуациях это может быть неприемлемым. Например, если пользователи обращаются к индивидуальным базам данных, запись в которые со стороны посторонних пользователей недопустима. В этом случае вы можете компилировать
Apache с использованием suEXEC и включить конфигурацию userdir. Эта возможность может быть использована в ситуациях, когда применение файлов .htaccess оказывается неудобным или неприемлемым.
Для настройки suEXEC необходимо некоторое время. Потребуются дополнительные конфигурационные директивы, среди которых:
--enable-suexec
--suexec-caller=UID
--suexec-docroot=DIR
--suexec-logfi1e=FILE
--suexec-userdir=DIR
--suexec-uidmin=UID
--suexec-gidmin=GID
--suexec-safepath=PATH
Данная возможность конфигурации обладает рядом недостатков. Однако используя ее, вы можете с большой гибкостью указывать (при помощи выражений VirtualHost) пользователя, от лица которого должна работать та или иная программа. К сожалению, компиляция с включением suEXEC и использование этого механизма в записях VirtualHost налагают ограничения на расположение каталогов
VirtualHost — все они должны быть расположены в рамках иерархии основного корневого каталога документов DocumentRoot. Такое положение вещей не всегда можно считать приемлемым.

Наибольшую опасность при использовании suEXEC представляет указание небезопасного пути
(PATH) для каталогов, содержащих в себе бинарные файлы. Каждый из бинарных файлов должен запускаться от лица указанного вами пользователя — это выглядит замечательно с точки зрения системы, однако может оказаться бедствием для пользователя, в особенности если бинарный файл является
«троянским конем».
Ядро Linux 2.4.x и khttpd
В состав ядра Linux 2.4.x (которое на момент написания данной книги до сих пор находится в стадии разработки) входит работающий на уровне ядра демон HTTP (khttpd). Этот демон не является полноценной заменой web-сервера Apache, однако он служит для улучшения его работы. Разработчики демона исходили из предположения, что большинство web-страниц являются статическими, поэтому доступ к ним можно обеспечить с использованием небольшого, быстрого, безопасного демона, работающего на уровне ядра.
Демон khttpd ожидает поступления запросов через порт 80 (привилегированный порт). Запросы, связанные с обработкой простых статических web-страниц, обрабатываются демоном khttpd. Если демон khttpd не в состоянии обработать некоторый запрашиваемый клиентом документ (например, документ, содержащий код РНРЗ, или документ, предусматривающий сложный грамматический анализ), такой запрос переадресуется другому демону HTTP (например Apache), который ожидает поступления запросов через порт 8080. После этого более мощный и совершенный web-сервер (такой как Apache) выполняет обработку подобных запросов. Перенаправление запросов осуществляется от демона khhtpd из порта 80 узлу localhost на порт 8080 (или любой другой указанный вами порт).
Демон khttpd можно скомпоновать либо в виде модуля, либо в виде демона, встроенного в ядро. В файле /etc/re.d/rc.local можно указать, запускается ли он в процессе начального запуска ОС или его запуск осуществляется позднее. Если этот демон скомпилирован в виде модуля, каталог khttpd не появится в рамках дерева /рrос до тех пор, пока данный модуль не будет загружен. Как только модуль khttpd загружается в память, в файловой системе появляется каталог /proc/sys/net/ khttpd. В этом каталоге присутствуют следующие файлы: clientport documentroot dynamiс logging maxconnect perm_forbid perm_required serverport sloppymime start stop threads unload
Каждый из этих файлов может быть настроен в соответствии с вашей конкретной конфигурацией. В первом файле содержится клиентский порт (clientport) -это порт, в который демон khttpd передает запрос
(как клиент) в случае, если обработка этого запроса выходит за рамки операции простого копирования файла в сеть. По умолчанию используется клиентский порт 80, через который web-сервер Apache ожидает поступления запросов. Это означает, что по умолчанию демон khttpd настроен как вспомогательное средство, а не как основной демон обработки запросов HTTP. Чтобы сделать демон khttpd основным web- сервером, a Apache — вспомогательным, измените клиентский порт на 8080 (или любой другой неиспользуемый порт) и прикажите серверу Apache ожидать поступления запросов через этот порт. Также внесите рекомендуемые изменения в файл serverport (см. далее).
Второй файл содержит в себе местоположение каталога DocumentRoot. По умолчанию корневым каталогом web-документов для демона khttpd является каталог /var/www. Есго следует изменить при помощи команды echo "/home/httpd/htdocs" > /proc/sys/net/httpd/documentroot.
Предназначение третьего файла менее понятно, чем первых двух. Файл dynamic содержит динамические строки, поиск которых будет осуществлять демон khttpd. По умолчанию в этом файле содержится следующий текст: Dynamic strings are : -cgi-bin- -..---. Возможно, если вы используете РНР, вам потребуется добавить в этот файл рhрЗ (echo php3 > /proc/sys/net/khttpd/dynamic).
Четвертый файл, logging, указывает, должно ли осуществляться документирование сведений в журналах с использованием syslog. В этом файле может содержаться либо 0, либо 1. По умолчанию в файле содержится 0. Пятый параметр ограничивает максимальное количество одновременных подключений. По умолчанию в этом файле содержится 1000 (этого должно быть достаточно для любых, даже самых крупных
узлов, однако для узлов с недостаточной емкостью каналов связи значение этого параметра можно снизить до 100 или меньше).
По умолчанию в файле perm_forbid содержится весьма разумное значение 16969. Это число является маской, определяющей, какими характеристиками должен обладать файл. Характеристики могут быть следующими (читаем числа в направлении слева направо): FIFO (именованный канал — named pipe, на что указывает 1 в первом разряде), SUID или SGID (4 или 2 соответственно, а комбинация равна значению 6), чтение, запись, исполнение (7) или только запись (2) для владельца — комбинированное значение равно 9, разрешение на чтение (4) и запись (2) для группы — комбинированное значение равно 6. Если вы меняете это значение, убедитесь в том, что вы хорошо понимаете, как оно обрабатывается. Еще одним оправданным и разумным значением является значение 16999. Если вы внесете в этот файл какое-либо значение, вы можете нарушить защиту вашей системы.
Файл perm_required обрабатывается приблизительно так же, как и файл perm_ forbid, однако в данном случае для того, чтобы быть предоставленным пользователю, файл должен быть доступен только для чтения всем пользователям. Если файл не открыт для чтения всем пользователям, он не будет обрабатываться.
В файле serverport содержится номер порта, через который демон khttpd ожидает поступления клиентских запросов. По умолчанию демон khttpd настроен в качестве вспомогательного сервера, поэтому в файле serverport содержится значение 8080. Если вы намерены сделать khttpd основным web-сервером, a
Apache — вспомогательным, вы должны внести в этот файл необходимые изменения, кроме того, вы должны соответствующим образом модифицировать файл httpd.conf сервера Apache. Если вы используете
Apache в качестве вспомогательного web-сервера (рекомендуется), измените в конфигурации Apache объявление BindAddress с * на 127.0.0.1. В результате сервер Apache будет принимать запросы только от демона khttpd.
Файл sloppymime может содержать одно из двух значений: 1 или 0. Если этот файл содержит значение 1, любой неизвестный тип MIME будет рассматриваться как тип text/html и будет обрабатываться демоном khttpd. Если файл sloppymime содержит значение 0, любой неизвестный тип MIME будет передан web-серверу пользовательского режима (Apache).
Следующие два файла — start и stop — по умолчанию содержат в себе значение 0. Если в файл start заносится 1, файл stop автоматически устанавливается равным О, при этом демон khttpd приступает к обслуживанию поступающих запросов. Если в файл stop вносится значение 1, файл start автоматически становится равным О и демон khttpd прекращает обработку запросов.
Файл threads по умолчанию содержит 2. Это значение определяет количество серверных программных потоков, которые могут обрабатываться одним центральным процессором. Как правило, это значение должно быть равно 1. Вы можете увеличить его только в случае, если ваш узел является очень крупным Web-узлом (настолько крупным, что все активные файлы не вмещаются в оперативную память).
Последний файл unload подготавливает khttpd к выгрузке из памяти. Прежде чем выгрузить модуль из памяти, необходимо записать значение 1 в файл stop (при этом в файл start автоматически будет записано значение 0, что блокирует запуск дополнительных программных потоков khttpd). Программные потоки, которые в данный момент уже функционируют, продолжат свою работу, и вы должны либо дождаться, пока они завершат функционирование, либо послать им сигнал SIGHUP (kill -HUP
'идентификатор PID демона khttpd'). После этого вы можете подготовить модуль khttpd к выгрузке, для чего необходимо занести 1 в файл unload. Теперь вы можете без опасений отдать команду rmmod khttpd. При загрузке модуля в память в файл unload автоматически будет внесено значение 0.
Заключение
В данной главе вы узнали о том, как осуществляется конфигурирование и компоновка сервера
Apache-1.3.9 с поддержкой SSL и РНРЗ. Вы также узнали о том, как выполняется настройка Apache. Я рассказал вам о некоторых рискованных с точки зрения безопасности конфигурациях. Напомню некоторые опасные варианты конфигурации:
- защищенный и незащищенный каталоги DocumentRoot совпадают;
- там, где необходимо использовать вложение файлов, вместо IndudesNOEXEC используется просто
Includes;
- там, где необходимо использовать символические ссылки, вместо SymLinksIfOwnerMatch используется FollowSymLinks;
- пренебрежение использованием безопасных CGI-каталогов, определяемых при помощи объявления
ScriptAlias;
- использование выражений , которые перекрывают собой конфигурацию, заданную при
помощи выражений и ;
- использование небезопасной директивы ExecCGI;
- использование директивы Alias, которая делает доступным для внешних клиентов корневой каталог вашей системы;
- отказ от использования директивы AllowOverride AuthConfig и файлов .htaccess для обеспечения более надежной защиты важных областей вашего web-сервера;
- отказ от отключения домашнего каталога пользователя root;
- отказ от использования выражения Directory, запрещающего доступ к каталогу «/».
Я также рассказал о демоне уровня ядра khttpd, который в состоянии обслуживать простые запросы
HTTP и который будет включен в состав ядра Linux 2.4.x.

Использование оболочки Secure
Shell и сетей VPN
21
В данной главе рассматриваются следующие вопросы:
- что такое Secure Shell (SSH);
- компоновка и установка SSH;
- конфигурирование SSH;
- использование SSH;
- что такое FreeS/WAN;
- компоновка и установка FreeS/WAN;
- конфигурирование FreeS/WAN;
- расширение сети WAN;
- что такое OpenSSH.
Одной из наиболее сложных с точки зрения безопасности проблем, с которыми сталкиваются в наше время пользователи и сетевые администраторы, является обеспечение безопасного способа удаленного доступа к расположенным дома или в офисе системам. Сам по себе удаленный доступ к таким системам не является проблемой. В состав каждой системы Linux входят клиент и сервер telnet. Однако использование telnet означает, что имя пользователя и пароль передаются через канал связи в незашифрованном виде. Это обстоятельство не является проблемой в случае, если для передачи данных используется выделенная телефонная линия. Однако если данные передаются далее, за сервер, который обеспечивает соединение между телефонной линией и Интернетом, любой пользователь tcpdump или какой-либо другой утилиты, прослушивающей сеть, сможет перехватить пользовательское имя и пароль.
Чтобы иметь возможность в любой точке страны получать электронную почту, многие путешественники пользуются услугами общенациональных интернет-провайдеров, которые во многих городах обеспечивают защищенный доступ к почтовым ящикам своих клиентов с использованием локальной телефонной сети. Если же использовать подобное соединение для доступа к домашней или офисной сети, данные могут передаваться через множество различных сетей, и каждый, кто обладает доступом к этим сетям, сможет перехватить передаваемые через сеть пакеты. Пакет содержит имя пользователя и пароль, а в заголовке пакета указывается адрес назначения. Обладая подобными данными, даже ребенок, мечтающий стать хакером, сможет проникнуть в чужую систему. Именно по этой причине в системе OpenLinux по умолчанию пользователь root не имеет права удаленного подключения к системе.
Недостаток данного подхода заключается в том, что пользователь может подключиться к системе, используя непривилегированную учетную запись, а затем при помощи su получить привилегии root — фактически это то же самое, что и удаленное подключение с использованием учетной записи root
Однако если подключение к системе осуществляется с использованием шифруемого соединения, получение пользовательского имени и пароля из перехваченных пакетов становится фактически невозможным. При этом для того, чтобы «вставить» себя между вами и вашим сервером и реализовать так называемую атаку man-in-the-middle (человек в середине), злоумышленник должен будет приложить немалые весьма нетривиальные усилия. Атака подобного рода является достаточно сложной, ее сможет реализовать только хорошо подготовленный, обладающий немалыми знаниями взломщик.
В рабочей среде Linux существует множество инструментов и программ, которые позволяют организовать безопасный обмен данными между системами. Мы с вами уже рассмотрели один из подобных механизмов в прошлой главе, где речь шла о web-сервере Apache, обладающем поддержкой технологии SSL. Конечно, подобное решение может оказаться несколько ограничивающим, однако пользователи могут запускать защищенные с использованием SSL web-серверы, связанные с непривилегированными портами с использованием файлов .htaccess для того, чтобы просматривать и загружать (через HTTP или FTP) документы, расположенные в их домашних каталогах.
Однако чтобы наделить пользователей более широкими возможностями, а именно позволить им работать с системой так, как они работают с ней при помощи telnet (то есть работать с системой через сеть фактически так же, как будто они работают с локальной консолью), вам потребуется некий эквивалент telnet. В последующих разделах я расскажу о двух альтернативных способах организации такого взаимодействия с учетом требований безопасности. Первый способ основан на использовании программы
под названием Secure Shell (SSH), а второй предусматривает создание полноценной виртуальной частной сети (Virtual Private Network, VPN) с использованием программного средства FreeS/WAN.
Как уже отмечалось в предыдущей главе, на прилагаемом к данной книге компакт-диске вы не найдете ни одного из этих программных продуктов. Это сделано для того, чтобы избежать нарушения действующих в США ограничений на экспорт кодирующих технологий. Следует отметить, что любой системный администратор, который работает на уровне привилегий root через незащищенную сеть и не использует эти программные средства, периодически будет иметь дело с несанкционированным проникновением в подконтрольные ему системы. Чтобы избежать этого, необходимо в обязательном порядке организовать должную защиту передаваемых через сеть данных с использованием одного из двух упомянутых средств. Программы можно получить по следующим адресам: ftp://ftp.cs.hut.fi/ pub/ssh/ssh-
1.2.27.tar.gz и ftp://ftp.xs4all.nI/pub/crypto/freeswan/freeswan-l.l.tar.gz.
Secure Shell
Программа Secure Shell (название переводится как «защищенная командная оболочка») предназначена для организации защищенного удаленного доступа к системе через сеть в режиме, напоминающем рабочий сеанс telnet. В настоящее время существует две разновидности Secure Shell (в дальнейшем SSH): версия 1 и версия 2.
Каждая из разновидностей поддерживается ее автором. Различие между этими разновидностями состоит в наборе возможностей (версия 2 обладает некоторыми дополнительными весьма полезными возможностями) и в лицензировании. В общем и целом версия 1 распространяется абсолютно бесплатно для некоммерческого использования. Однако если вы намерены использовать версию 2, вы в любом случае должны приобрести лицензию. В данном тексте я буду рассказывать о версии 1, а конкретнее, о пакете ssh-1.2.27.
Компоновка и установка SSH
Загрузив SSH, определите, где вы намерены установить эту программу (местоположение файла не имеет значения, вы можете разместить его например в каталоге $НОМЕ). После этого раскройте архив при помощи команды: tar xzvf ssh-1.2.27.tar.gz
При этом будет создан каталог ssh-1.2.27, в который вы должны перейти, чтобы продолжить.
Для тех, кто плохо владеет процедурами компоновки программных пакетов, отмечу, что пакет SSH использует новые файлы GNU autoconf. Эти файлы являются упрощенной альтернативой прямого редактирования файлов Makefile и обеспечивают простой метод формирования разнообразных конфигураций, а также проверки корректности настройки программного пакета. Механизм GNU autoconf еще недостаточно хорошо отлажен, поэтому при установке некоторых пакетов возникают проблемы, связанные с тем, что этот механизм не может обнаружить в системе установленного в ней программного обеспечения. Однако в среде
OpenLinux файл ssh-1.2.27 autoconf работает без сбоев.
Для начала отдайте команду ./configure --help. По этой команде на экран будет выведен достаточно длинный перечень параметров, позволяющих скомпоновать пакет с использованием самых разнообразных конфигураций. В данном тексте будут затронуты лишь некоторые из них. Как правило, значения параметров по умолчанию являются вполне подходящими, однако конкретно в вашей ситуации вы можете изменить некоторые из них. В верхней части экрана показаны префиксы каталогов для установки. По умолчанию установка осуществляется в каталоге /usr/local, и в большинстве случаев это вполне приемлемо, если только вы не используете для этой цели каталог /opt. Далее перечисляются типы сетевых узлов. В случае если вы компонуете программу в системе, в которой она будет установлена, типы узлов вам не понадобятся. В последнем разделе перечисляются разнообразные возможности и пакеты. Этот список следует изучить внимательнее. К наиболее важным параметрам относятся:
- --with-x — если вы хотите добавить библиотеки для разработки X11 (неплохая идея);
- --without-idea — если вы находитесь в Европе и не можете использовать алгоритмы кодирования
IDEA;
- --without-rsh — если вы хотите запретить SSH переходить в режим взаимодействия незащищенной оболочки rsh в случае, когда SSH не может обнаружить сервера ssh (еще одна неплохая идея);
- --with-secured=/путь/к/secureid — если ваша система использует карту Security Dynamics SecurID;
- --with-kerberos5 — если вы используете Kerberos 5 (Kerberos 4 не поддерживается);
- --with-libwrap — если вы желаете использовать оболочку TCP (то есть TCP Wrappers и файл
/etc/hosts.allow);
- --with-socks --with-socks4 --with-socks5 — если вы хотите обеспечить поддержку брандмауэра
SOCKS;
- --with-rsaref — если вы желаете/должны удовлетворить требованиям патента RSA (США).

При желании вы можете выбрать и другие параметры. Выберите тот набор параметров, которые вы намерены включить или отключить. Я рекомендую вам создать для этой цели исполняемый сценарий, подобный тому, текст которого приведен в листинге 21.1.
Листинг 21.1. Возможная конфигурация SSH
./configure --with-x \
--without-rsh \
--with-rsaref
Если вы желаете или обязаны использовать RSAref, вы должны следовать инструкциям, описанным в данном абзаце. Электронная справка о конфигурации подсказывает вам, что вы можете сообщить SSH о том, где располагаются библиотеки RSAref, однако этот раздел сценария некорректен. В каталоге, в котором вы выполняли команду .configure -help, создайте подкаталог rsaref2 (mkdir rsaref2). Это имя изменять нельзя — оно должно быть именно таким, как показано здесь. После этого перейдите в подкаталог rsaref2 и выполните команду tar xzvf/путь/к/ rsaref20.tar.Z. После этого перейдите обратно в каталог конфигурации и запустите ваш сценарий конфигурирования.
После выполнения конфигурационного файла скорректируйте любые неточности (это, как правило, отсутствие библиотек и неправильные пути к файлам). После того как конфигурационный сценарий будет выполнен без ошибок от начала до самого конца, вы можете выполнить команду make. Выполнение этой команды может занять некоторое время. Когда ее функционирование завершится, перейдите на уровень привилегий root (su) и выполните команду make install. По этой команде все будет установлено и подготовлено к использованию, включая создание закрытых системных ключей.
После того как программа SSH будет установлена в системе, необходимо убедиться в том, что бинарный файл sshd запускается в процессе начального запуска системы. Проще всего добиться этого при помощи следующей команды:
echo "/usr/local/sbin/sshd" > /etc/rc.d/rc.local
По умолчанию серверный демон Secure Shell будет запускаться с использованием ключа размером
768 бит (стандартный изначальный размер для RSA). Если вы хотите использовать ключ большего размера, добавьте в командную строку sshd параметр -Ь 1024. Число 1024 можно заменить любым удобным для вас количеством битов в ключе. Имейте в виду, что применение ключа большего размера требует большей вычислительной мощности, при этом может замедлиться скорость передачи данных через канал, однако уровень защиты существенно возрастает. Использовать ключи с размером меньшим, чем 768, не рекомендуется, так как на существующем уровне технологий злоумышленники могут легко дешифровать ключи длиной в 512 бит, и даже ключ размером 768 нельзя расценивать как неуязвимую защиту на все сто процентов. При каждом запуске демона sshd требуется некоторое заметное время для генерации ключа, поэтому запуск с использованием inetd не рекомендуется. Чтобы запустить демон sshd без перезагрузки, просто наберите команду запуска sshd в командной строке.
ПРИМЕЧАНИЕ
Добавление соответствующей записи в файл /etc/services не обязательно, однако будет неплохо, если вы
зарегистрируете порт с номером 22 как порт, связанный с ssh. Для этого в файл /etc/services необходимо добавить
следующие строки:
ssh 22/tcp

ssh 22/udp

В процессе установки SSH в каталоге /etc создаются следующие файлы: - sshd_config — конфигурация по умолчанию для серверного демона SSH; - ssh_config — конфигурационный файл по умолчанию для SSH;
- ssh_host_key — закрытый ключ для данного узла; правом доступа к нему обладает только пользователь root, для всех остальных пользователей доступ должен быть закрыт;
- ssh_host_key.pub — открытый ключ для данного узла;
- ssh_random_seed — создается каждый раз при запуске sshd (правом доступа должен обладать только пользователь root и никто другой);
В файл ssh_host_key в процессе установки записывается 768-битный ключ. Если вы хотите увеличить размер этого ключа до, скажем, 1024 бит, вы должны выполнить команду ssh-keygen -b 1024. После генерации ключа запишите его в файл /etc/ssh_host_key. В процессе генерации ключа будут созданы файлы ssh_host_key и ssh_ host_key.pub. Когда система предложит вам ввести ключевую фразу, не вводите ее.
Если вы укажете ключевую фразу, каждый раз при запуске sshd вам придется вводить ее заново, а это очень неудобно, так как в большинстве случаев запуск sshd происходит в процессе начальной загрузки системы наряду с другими программами.

После того как вы выполните все вышеописанные шаги на каждой из систем, на которых вы хотите установить SSH, и запустите демон sshd, вы можете собрать все файлы ssh_host_key.pub и скопировать их содержимое в один большой файл под именем /etc/ssh_known_hosts с режимом доступа chmod 644, который следует записать на каждый из сетевых узлов. Благодаря этому вы сможете избежать подделки IP-адресов и обеспечить больший уровень безопасности. На этом все процедуры, выполняемые на уровне привилегий root, завершены.
ВНИМАНИЕ
Если злоумышленник получил возможность воспользоваться учетной записью root на одной из ваших систем, вы
больше не можете доверять ключам SSH. Все ключи следует заменить новыми, в противном случае вы не можете
быть уверенными в том, что системы корректно идентифицируют себя.
Использование SSH
Теперь вы сможете, как обычный пользователь, работать с любым удаленным узлом, на котором установлена программа SSH и на котором у вас есть своя учетная запись. Вы подключаетесь к системе примерно так же, как это происходит при использовании telnet, однако оболочка SSH передает на удаленную систему ваше пользовательское имя. Система запрашивает у вас пароль, который соответствует этому пользователю. Если пользовательское имя, которое вы хотите использовать на удаленной системе, отличается от вашего локального пользовательского имени, вы можете использовать ключ -l для того, чтобы указать другое пользовательское имя. В отличие от telnet, программа SSH не накладывает никаких ограничений на то, можете ли вы использовать для подключения учетную запись root. Это происходит потому, что как только устанавливается соединение TCP, первое, что делает SSH, это обмен открытыми ключами и создание защищенного шифруемого туннеля. После этого все, что передается через этот туннель, включая имя подключающегося пользователя, шифруется.
При первом запуске SSH эта программа создает каталог с именем .ssh, в котором размещается файл random_seed. Если вы ранее не выполнили необязательную процедуру создания файла /etc/ssh_known_hosts или подключились к системе, которая не упоминается в файле /etc/ssh_known_hosts, то в каталоге .ssh также будет расположен файл known_hosts (в этом случае вначале система сообщит вам, что соответствующей записи в файле known_hosts не существует, на вопрос, надо ли создавать такую запись, следует ответить утвердительно). Программа SSH автоматически копирует файл ssh_host_key.pub в файл known_hosts, в дальнейшем каждый раз при создании соединения будет осуществляться проверка. Если ключ в файле known_hosts не соответствует ключу, переданному удаленным узлом, программа предупредит вас о том, что полученный ключ не существует и что кто-то пытается реализовать атаку типа man-in-the-middle (вклинивание между системами). Программа SSH чрезвычайно подозрительна на этот счет, однако в этом случае она спросит у вас, хотите ли вы все же продолжить создание соединения. Если вы уверены в том, что ключ на удаленной системе действительно изменился, вы можете избежать вывода предупреждения. Для этого необходимо удалить соответствующий ключ из файла known_hosts. В этом случае при следующей попытке подключения программа SSH сообщит вам, что в файле known_hosts отсутствует соответствующая удаленному узлу запись. При этом вам будет предложено продолжить создание соединения. Если вы ответите утвердительно, программа скопирует новый ключ с удаленной системы в файл known_hosts.
Чтобы упростить работу с SSH, любой постоянный пользователь этого механизма связи может создать свой собственный идентификационный файл. Предположим, что пользователь регулярно подключается к нескольким разным удаленным системам с использованием разных пользовательских имен и паролей. Конечно же, для подключения к удаленным системам с использованием различных пользовательских имен можно использовать аргумент командной строки -l, однако если пользователь имеет дело с множеством различных систем, ему будет сложно запомнить множество сложных и отличающихся друг от друга паролей, из-за этого процедура подключения может усложниться. В этом случае, чтобы упростить дело, пользователь может создать свой собственный идентификационный файл.
Для этого необходимо воспользоваться командой ssh-keygen (с необязательным указанием ключа -Ь), по которой в подкаталоге $HOME/.ssh будут созданы файлы идентификации identity и identity.pub. При этом система предложит пользователю ввести ключевую фразу. Содержимое сгенерированного таким образом файла identity.pub необходимо скопировать в файл $HOME/.ssh/authorized_keys на удаленной системе (в случае необходимости этот файл следует создать). Теперь, когда пользователь подключается к удаленной системе, оболочка SSH будет запрашивать его ввести не пароль пользователя удаленной системы, а ключевую фразу для файла идентификации. Таким образом, для подключения ко всем разнообразным системам, на которых файл authorized_keys содержит в себе данные из файла identity.pub для некоторого пользователя, этому пользователю требуется запомнить всего лишь один пароль.
При создании файлов идентификации пользователь вовсе не обязан указывать ключевую фразу. Он может либо указать ее, либо оставить соответствующее поле пустым. В этом отношении необходимо
учесть связанные с этим соображения безопасности. Право чтения-записи файла $HOME/.ssh/identity принадлежит только владельцу этого файла, то есть пользователю, которого идентифицирует этот файл.
Если учетная запись этого пользователя становится доступной для злоумышленника и если при этом пользователь не использует ключевую фразу, злоумышленник автоматически получает возможность доступа ко всем удаленным системам, на которых содержится идентификационная информация для данного пользователя. В этом случае чтобы восстановить защиту, пользователь будет вынужден генерировать новые идентификационные файлы и внести соответствующие изменения во все удаленные системы, с которыми он взаимодействует. При отсутствии ключевой фразы пользователь получает возможность организовать удаленное подключение без собственного участия. Иными словами, он сможет запускать от своего имени автоматические сценарии взаимодействия с удаленными системами, и эти сценарии смогут подключаться к удаленным системам без участия пользователя (так как при отсутствии ключевой фразы никакого пароля при удаленном подключении не требуется). Это удобно, однако при этом повышается вероятность того, что удаленные системы будут взломаны с использованием локальной учетной записи этого пользователя.

ПРИМЕЧАНИЕ
Если вы хотите упростить процесс подключения пользователя к множественным удаленным системам, вы можете
воспользоваться для этой цели специальным графическим программным средством под названием sshbuddy. Это
программное средство запоминает имя удаленного сервера и соответствующее ему имя пользователя. Таким
образом, доступ к удаленной системе может быть осуществлен при помощи всего двух щелчков мыши.
Конфигурация SSH и SSHD
В состав программного пакета SSH входят две конфигурационные программы: одна для клиента
(ssh_config) и одна для сервера (sshd_config). Когда любая из этих программ начинает работу, она прежде всего анализирует конфигурационные параметры из командной строки, затем — из индивидуальных пользовательских файлов .ssh, а затем из системных конфигурационных файлов. Если на одном из этих этапов настраивается значение некоторого параметра, все последующие настройки значения этого параметра игнорируются.
Фaйл /etc/ssh_config, содержимое которого показано в листинге 21.2, содержит значения параметров по умолчанию. Эти значения используются системой в случае, если ни один из параметров нигде не переопределяется.
Листинг 21.2. Фрагмент файла /etc/ssh_config, демонстрирующий значения по умолчанию
# Host
*
ForwardAgent yes
ForwardX11 yes
RhostsAuthentication yes
RhostsRSAAuthentication yes
RSAAuthentication yes
TISAuthentication no
PasswordAuthentication yes
FallBackToRsh yes
UseRsh no
BatchMode no
StrictHostKeyChecking no
IdentityFile
/.ssh/identity
Port 22
Cipher idea
EscapeChar
He обращайте внимание на то, что все строки этого листинга являются комментариями. Именно эти значения будут использоваться программой SSH в случае, если конфигурация не модифицируется при помощи командной строки, пользовательских конфигурационных файлов или других записей в системных конфигурационных файлах. Конфигурацию можно модифицировать для каждого узла по отдельности.
Если вы хотите определить значения конфигурационных параметров для некоторого конкретного узла, вы должны внести соответствующие записи в раздел Host перед разделом Host, относящимся ко всем остальным узлам (под заголовком all other).
О некоторых параметрах следует рассказать особо. Параметр ForwardXll разрешает автоматическое и прозрачное перенаправление дисплейных сообщений X11 обратно на локальный узел. Подобного эффекта можно добиться, выполнив на локальном узле команду xhost +remotehost, а затем на удаленном узле присвоив переменной окружения DISPLAY значение localhost (export DISPLAY=CLIENTHOST:0.0).
Работа в подобном режиме зависит от того, найдет ли программа SSH на удаленном узле приложение xauth
(для некоторых систем, не являющихся системами Linux, это может оказаться проблематичным). Если запрашивается перенаправление X11, однако программа SSH не разрешает этого, на экране появится
соответствующее сообщение. Если перенаправление X11 разрешено, соединения X11 будут осуществляться через защищенный шифруемый туннель. Таким образом, если вы воспользуетесь командой ssh foo, а затем на узле foo запустите xterm, информация, отображаемая xterm, будет отображаться на вашей локальной системе (предполагается, что вы подключились к рабочему сеансу X).
При этом запускать оболочку X на узле foo вовсе не обязательно, достаточно чтобы для вас были доступны клиентские программы. Следует иметь в виду, что через медленное соединение (например, аналоговый модем) работа в подобном режиме может оказаться нежелательной.
Обратите внимание, что по умолчанию программа SSH использует шифр IDEA. Если вместо этого вы желаете использовать тройной шифр DES, раскомментируйте строку Cipher и замените значение idea на значение 3des, или запустите ssh с аргументом -с 3des..
Конфигурационный файл по умолчанию для серверного демона SSH показан в листинге 21.3.
Листинг 21.3. Файл конфигурации по умолчанию /etc/sshd_config
Port 22
ListenAddress 0.0.0.0
HostKey /etc/ssh_host_key
RandomSeed /etc/ssh_random_seed
ServerKeyBits 768
LoginGraceTime 600
KeyRegenerationlnterval 3600
PermitRootLogin yes
IgnoreRhosts no
StrictModes yes
QuietMode no
X11Forwarding yes
X11Displa/Offset 10
FascistLogging no
PrintMotd yes
KeepAlive yes
SyslogFacility DAEMON
RhostsAuthentication no
RhostsRSAAuthentication yes
RSAAuthentication yes
PasswordAuthentication yes
PermitEmptyPasswords yes
UseLogin no
# CheckMail no
#PidFile /u/zappa/.ssh/pid
#AllowHosts *.our.com friend.other.com
#DenyHosts lowsecurity.theirs.com *.evil.org evil.org
#Umask 022
#SilentDeny yes
Прежде всего обратите внимание на то, что этот конфигурационный файл не содержит в себе закомментированных строк (за исключением нескольких строк в конце). Это потому, что все эти значения нужны серверу для нормального функционирования. В отличие от клиентской части, сервер SSH не содержит в себе встроенных в код конфигурационных значений по умолчанию — вся конфигурация в обязательном порядке читается из файла. Многие из этих значений легко можно изменить. Некоторые из них влияют на то, каким способом пользователи взаимодействуют с системой и что они принимают от сервера. Эти значения можно изменить в соответствии с политиками локальной системы. Эффекты модификации различных параметров могут быть самыми разными. Я не буду подробно рассказывать об этом, так как лишь немногие из этих параметров напрямую связаны с безопасностью. Исключением являются параметры, имеющие отношение к RHosts. Если вы не хотите позволять пользователям подключаться к системе с использованием файлов .rhosts в стиле rsh, отключите все эти параметры. В большинстве ситуаций использование файлов rhosts — это плохая идея. Подключение, основанное на файлах identity и authorized_keys, обеспечивает более высокий уровень безопасности.
FreeS/WAN
Принцип действия программного механизма FreeS/WAN несколько отличается от пакета SSH. Пакет
FreeS/WAN предназначен для формирования защищенного шифруемого туннеля между двумя закрытыми частными сетями, при этом шифруемый туннель пролегает через открытые, публично доступные каналы связи (как правило, Интернет). Набор операций, выполняемых с использованием SSH, ограничен действиями, которые вы можете выполнить при помощи telnet (это не относится к версии 2 пакета SSH). В отличие от SSH, программный механизм FreeS/WAN осуществляет шифровку всего трафика между двумя
сегментами WAN.
Компоновка и установка FreeS/WAN
Чтобы установить FreeS/WAN, вы должны встроить его в ядро Linux. Для этой цели вам прежде всего потребуется чистый, никоим образом не модифицированный исходный код ядра. Исходный код ядра, входящий в комплект OpenLinux (включая исходный код, записанный на компакт-диск, прилагаемый к данной книге), для этой цели не подходит: компания Caldera использует модифицированный исходный код ядра, который нельзя скомпоновать вне рабочей среды RPM. Возможно, в дальнейших версиях ситуация изменится, однако если вы в любом случае будете использовать чистый, нетронутый код ядра, у вас будет меньше проблем. Получить такой код можно по адресу http://www.us.kernel.org или вы можете использовать любое зеркало этого web-узла. Создайте каталог (mkdir linux-2.2.14) и убедитесь в том, что ссылка linux указывает на этот каталог. Распакуйте исходный код ядра, перейдите в этот каталог, выполните компоновку и установку ядра в соответствии с требованиями вашей системы. Убедившись в том, что ядро работает (компонуется, устанавливается и загружается), вернитесь в каталог /usr/src.

ПРИМЕЧАНИЕ
Если при загрузке нового ядра у вас возникли проблемы, убедитесь в том, что используемый вами файл /etc/lilo.conf
корректен, и вновь запустите lilo. Убедитесь в том, что загрузчик lilo видит ваше ядро.
Находясь в каталоге /usr/src, распакуйте архив FreeS/WAN. После этого перейдите в подкаталог freeswan-1.1 и отдайте одну из следующих команд:
make menugo
(соответствует make menuconfig) make xgo
(соответствует make xconfig) make ogo
(соответствует make config) make oldgo
(соответствует make oldconfig)
В результате выполнения одной из этих команд исходный код ядра будет исправлен и начнется компиляция и сборка ядра. Выберите сетевые параметры из категории Networking Options, которые вы намерены установить (не сбрасывайте параметр Kernel/User netlink socket). Если вы намерены использовать данную систему как выделенный маршрутизатор, имеет смысл установить параметр IP: optimize as router not host (оптимизировать как маршрутизатор, а не как обычный узел), благодаря этому ваша система будет работать несколько быстрее. Если же настраиваемая вами система должна совмещать выполнение функций маршрутизатора WAN и рабочей станции, устанавливать данный параметр не следует, так как при этом будут возникать некоторые ошибки пакетов.
Вы можете использовать также IP: advanced router options (дополнительные параметры маршрутизатора) и выбрать некоторые из дополнительных параметров. Если вы выбрали эту возможность, в процессе начальной загрузки вы должны отключить rp_filter. Для этого в файл /etc/rc.d/rc.local необходимо добавить следующую строку:
echo "0" > /proc/sys/net/ipv4/conf/all/rp_filter
Ближе к концу раздела Networking Options вы можете обратить внимание на некоторые новые параметры. Первый параметр имеет отношение к шифрующему протоколу IPSEC и называется IP Security
Protocol (FreeS/WAN IPSEC). Соответствующий код может быть либо встроен в ядро, либо скомпилирован как отдельный модуль. Включив этот параметр, вы получите возможность воспользоваться несколькими другими параметрами, имеющими отношение к IPSEC. В большинстве случаев нет необходимости изменять значения по умолчанию. Если вы хорошо представляете себе предназначение и смысл этих параметров, можете настроить их в соответствии с вашими предпочтениями, однако вы ни в коем случае не должны включать параметр IPSEC: Enable Insecure algorithms (IPSEC: разрешение на использование незащищенных алгоритмов). Если вы включите этот параметр, теряется смысл использования зашифрованного канала связи.
Когда вы закончите настройку, сохраните новую конфигурацию ядра. Вы должны сохранить новую конфигурацию ядра вне зависимости от того, внесли ли вы в нее какие-либо изменения, в противном случае необходимые для использования FreeS/WAN изменения не будут внесены в исполняемый код ядра.
После того как вы сохраните конфигурацию и завершите работу с утилитой настройки, автоматически начнется процедура компоновки ядра. Однако в процессе компоновки не будут выполнены все необходимые действия. Поэтому когда компоновка завершится, вы должны выполнить команду cd ../linux, а затем выполнить команду make modules_install. После этого следует переместить ядро, запустить lilo, чтобы загрузчик распознал новое ядро, и, наконец, перезагрузить систему с использованием нового ядра.
В процессе сборки ядра в системе будут установлены также несколько утилит и страницы электронной документации man pages.

Конфигурирование FreeS/WAN
Чтобы рассказать вам о настройке FreeS/WAN, я начну с самой простой конфигурации — требуется обеспечить защищенный канал обмена данными между двумя системами, подключенными к одному и тому же сетевому кабелю. В дальнейшем эта конфигурация будет расширена и усовершенствована. На каждом этапе конфигурирования FreeS/WAN вы должны будете проверять конфигурацию, чтобы убедиться в том, что она работает корректно.
В процессе загрузки ядра и инициализации системы на консоли, скорее всего, появится несколько сообщений, связанных с IPSEC. До тех пор пока вы не настроите IPSEC, вы должны игнорировать эти сообщения. Первое, что вы должны сделать, это отключить IPSEC на всех ваших системах до тех пор, пока вы не будете готовы соединить их.
Для выполнения первого этапа конфигурирования я буду использовать две системы: сетевой узел
HostA с IP-адресом 192.168.0.1 и сетевой узел HostB с IP-адресом 192.168.0.2. Обе эти системы подключены к одному сетевому кабелю. Тестовое соединение между ними будет называться HostA2HostB
(если бы я хотел быть действительно оригинальным, я назвал бы его foo-test). Каждая из этих систем использует для соединения с сетью Ethernet интерфейс eth0.
На узле HostA уберите файл /etc/ipsec.conf по умолчанию (по умолчанию в этом файле располагаются значения, подразумевающие слишком «мягкую» безопасность) и вместо него используйте следующие значения:
config setup interfaces="ipsec0=eth0"
#(later you can change the above to interfaces="ipsec0=eth0 ipsec1=ppp0" klipsdebug=all #(or none if you like) plutodebug=all #(again, none if you like) conn HostA2HostB
HostA=192.168.0.1
HostB=192.168.0.2 keyingtries=0 # this is actually a very large number
Обратите особое внимание на отступы. Отступы являются важным атрибутом большинства файлов, связанных с ipsec. Скопируйте этот файл на узел HostB. После этого отредактируйте файл ipsec.secrets следующим образом:
192.168.0.1 192.168.0.2 "между кавычками следует разместить 256 случайно выбранных битов, полученных при помощи команды 'ipsec ranbits > tmpfile'"
ВНИМАНИЕ
Вы должны обеспечить надежную защиту файла ipsec.secrets. Этот файл должен принадлежать пользователю
root, а правом его чтения должен обладать только пользователь root. Любой, кто получит в свое распоряжение
этот ключ, сможет проникнуть в ваш защищенный туннель и читать любые ваши зашифрованные сообщения.
Чтобы случайным образом сгенерировать биты для файла ipsec.secrets, вы можете воспользоваться командой ipsec ranbits. Обе системы (192.168.0.1 и 192.168.0.2), упомянутые в строке файла ipsec.secrets (в эту строку можно добавить дополнительные системы), должны обладать идентичными копиями этого файла (по крайней мере должны совпадать биты 256-битного ключа). Убедитесь в том, что 256 бит размещаются между кавычками.
После того как на обе системы скопированы оба конфигурационных файла ipsec (с корректным набором разрешений на доступ к файлу /etc/ipsec.secrets), воспользуйтесь командой modeprobe для того, чтобы добавить в систему модуль ipsec (если вы скомпоновали ipsec в виде модуля), и выполните команду
/etc/rc.d/ init.d/ipsec start на каждой из систем.
Чтобы убедиться в том, что ipsec функционирует, можно проверить несколько признаков. Во-первых, воспользовавшись утилитой ipconfig, вы можете обнаружить, что в системе появился новый интерфейс ipsec0 со всеми соответствующими параметрами. Кроме того, в таблице маршрутизации возникли несколько новых записей, связанных с интерфейсом ipsec0. Наконец, вы можете получить некоторую диагностическую информацию при помощи самой утилиты ipsec. Для этого достаточно использовать команды ipsec look и ipsec tncfg.
Расширение сети
Если взглянуть в файл ipsec.conf по умолчанию, можно обнаружить несколько дополнительных переменных, таких, как, например, переменная nexthop (следующий участок ретрансляции). В нашем конфигурационном файле соответствующие переменные могут обладать именами HostAnexthop или
HostBnexthop. Если две системы, обменивающиеся зашифрованной информацией, физически разделены несколькими участками ретрансляции (несколькими хопами) Интернета (или любой другой сети) — иными
словами, если адрес шлюза одной системы не совпадает с адресом шлюза другой системы, — тогда переменная nexthop должна содержать IP-адрес шлюза для каждой из этих машин. Если для связи с
Интернетом вы используете РРР, у вас в распоряжении будет локальный и удаленный IP-адрес соединения
«точка-точка». Локальный адрес будет принадлежать сетевому узлу HostA (надеюсь, вы придумаете более осмысленное имя), а удаленный адрес — это значение переменной HostAnexthop. Ваш узел HostB (а в конфигурационном файле по умолчанию — rightnexthop) содержит IP-адрес nexthop другого узла. И конечно же, IP-адрес каждой из систем должен быть упомянут в файле ipsec.secrets.
На текущий момент мы с вами сформировали туннель, напрямую соединяющий две системы. Это весьма ограниченная конфигурация, однако вместе с тем она самая простая из всех возможных. Если вы хотите расширить туннель таким образом, чтобы включить другие сетевые узлы, расположенные за двумя системами, участвующими в созданном вами соединении, вы должны добавить в конфигурацию еще несколько переменных.
Прежде всего вам потребуется сетевая маска для подсети, расположенной за шлюзом. Эту сетевую маску следует присвоить переменной HostAsubnet= в формате сеть/битовая_маска, например,
192.168.0.0/24. Эта запись указывает на то, что узел HostA выполняет функции шлюза для всех систем с IP- адресами в диапазоне 192.168.0. Соответственно в конфигурации каждой из этих систем узел HostA должен быть указан в качестве шлюза.
ВНИМАНИЕ
Если вы используете переменную subnet, шлюзовая система исключается из указанного вами диапазона. Иными
словами, трафик, исходящий от шлюзовой системы или адресованный шлюзовой системе, не будет передаваться
через туннель. Чтобы исправить ситуацию, вы должны либо настроить отдельный туннель, в котором не будет
переменной subnet, либо указать 192.168.0.1/32.
Также следует определить, выполняет ли шлюз функции брандмауэра (является ли он маскирующим узлом или нет). Если да, вы должны добавить переменную firewall и присвоить ей значение yes:
HostAfirewall=yes.
Добавление дополнительных сетей
Чтобы увеличить количество подсетей в вашей защищенной сети WAN (то есть чтобы соединить защищенными каналами три и более подсетей), необходимо расширить файлы ipsec.conf и ipsec.secrets.
Наиболее сложной является задача обеспечения уникальности IP-адресов в рамках вашей защищенной сети. Например, если в состав вашей сети WAN входит 50 немаршрутизируемых подсетей (например, из диапазона адресов 192.1б8.х.х), необходимо добиться того, чтобы каждый из узлов, входящих во все эти подсети, обладал бы уникальным IP-адресом. Вторая сложная задача — придумывание пар имен для осмысленного именования виртуальных соединений.
Например, допустим, вы хотите соединить три подсети. Три шлюзовых узла будут именоваться rnoe, larry и curly. Узел mое будет обладать файлом ipsec.conf с двумя разделами conn, содержимое которого может быть таким, как показано в листинге 21.4.
Листинг 21.4. Фрагмент файла ipsec.conf без раздела config setup conn moe-larry moe=192.168.0.1 moenexthop=Internetgatewaymaewest moesubnet=192.168.0.0/24
#remember, moe is not secure to larry moefirewall=yes larry=192.168.1.1 larrysubnet=192.168.1.0/24 larrynexthop=Internetgatewaymaeeast larryfirewall=yes keyingtries=0 conn moe-curly moe=192.168.0.1 moenexthop=Internetgatewaymaewest moesubnet=192.168.0.0/24
#remember, moe is not secure to larry moefirewall=yes curly=192.168.2.1 curlysubnet=192.168.2.0/24 curlynexthop=Internetgatewaymaesouth curlyfirewall=yes keyingtries=0
На узле larry можно использовать точную копию показанного в листинге раздела conn moe-larry, а на узле curly — точную копию раздела conn moe-curly. При этом каждый из узлов larry и curly должен
обладать разделом conn larry-curly, в котором будет описываться соединение между этими двумя узлами.
Файл ipsec.secrets должен содержать два дополнительных набора секретов. Узел тое должен обладать общим ключом с узлом larry и еще одним общим ключом с узлом curly, однако ключ, используемый для обмена данными между узлами larry и curly, узлу тое не требуется (вы, конечно, можете добавить соответствующий ключ на узел тое, однако этот ключ просто не будет использоваться). Подобное правило обмена ключами действует и в отношении двух других серверов IPSEC.
И конечно же, если вы хотите обеспечить защищенную передачу трафика, исходящего от одного из шлюзовых узлов (например, тое) и адресованного другому шлюзовому узлу (например, larry), вам потребуется определить еще одно соединение (например, moe-larry-gates), которое формирует еще один дополнительный простой туннель. Для этого туннеля необходимо либо не определять переменные moesubnet и larrysubnet, либо определить данный туннель специально для соответствующего узла
(192.168.0.1/32 и 192.168.1.1/32).
OpenSSH
На момент написания данной книги пакет OpenSSH находится в стадии разработки. Автор этого пакета намерен разработать программное средство OpenSSH, которое можно будет использовать в качестве полноценной замены пакета SSH. Отличие состоит в том, что по сравнению с SSH лицензирование пакета
OpenSSH будет более открытым и его развитие будет продолжено (в настоящее время осуществляется поддержка ssh-1.2.27, однако развитие этого пакета не осуществляется, — вместо него разрабатывается пакет версии 2.0.x, в отношении которого действует коммерческая схема лицензирования).
Программное средство OpenSSH наряду с обычными возможностями SSH позволит воспользоваться защищенными версиями протоколов FTP и RCP. Разработчики отказались от использования любого криптографического кода, с которым могут быть связаны патентные проблемы (например, IDEA или RSA), однако при этом им удалось обеспечить надежную криптографическую защиту.
Заключение
В данной главе я рассказал вам о том, как настроить, скомпоновать и установить программный пакет
SSH — программное средство для защищенного удаленного администрирования систем и взаимодействия между системами. Вы узнали о том, как осуществляется настройка и использование данного программного средства. После этого я рассказал вам о том, как скомпилировать пакет FreeS/WAN и включить его в состав ядра Linux, а также выполнить настройку этого программного механизма для того, чтобы обеспечить надежное соединение WAN через публичную сеть, или просто соединить зашифрованным каналом две системы.











Поделитесь с Вашими друзьями:
1   ...   31   32   33   34   35   36   37   38   ...   42


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

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


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