Geum.ru

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

Вид материалаРеферат

Содержание


Secure Shell
Использование SSH
Конфигурация SSH и SSHD
Подобный материал:
1   ...   83   84   85   86   87   88   89   90   ...   101

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, обеспечивает более высокий уровень безопасности.