Защита от хакеров корпоративных сетей
Шрифт:
effugas@OTHERSHOE ~
$ ssh –1 effugas@10.0.1.10
effugas@10.0.1.10”s password:
Last login: Mon Jan 14 05:38:05 2002 from 10.0.1.56
[effugas@localhost effugas]$А сейчас дышите глубже. Теперь читатель с помощью ssh-keygen должен прочитать сгенерированный ключ и передать его по каналу дальше, используя ssh с адресом 10.0.1.10 и имя пользователя effugas. После этого ему следует удостовериться в том, что он находится в домашней директории, и установить режимы работы с файлом таким образом, чтобы никто другой не смог прочитать то, что он собирается записать. При необходимости читатель может создать директорию (опция – p позволяет по желанию создавать директории), а затем он получит переданные по каналу данные и добавит их к файлу ~/.ssh/authorized_keys,
effugas@OTHERSHOE ~
$ cat ~/.ssh/identity.pub | ssh -1 effugas@10.0.1.10 “cd ~
&& umask 077 && mkdir -p .ssh && cat >> ~/.ssh/
authorized_keys”
effugas@10.0.1.10’s password:
Мама моя родная, никакого пароля не требуется:
effugas@OTHERSHOE ~
$ ssh -1 effugas@10.0.1.10
Last login: Mon Jan 14 05:44:22 2002 from 10.0.1.56
[effugas@localhost effugas]$Эквивалентным процессом для SSH2, который для пакета OpenSSH является протоколом по умолчанию, является следующий:
effugas@OTHERSHOE ~
$ cat ~/.ssh/id_dsa.pub | ssh effugas@10.0.1.10 “cd ~ &&
umask 077 && mkdir -p .ssh && cat >> ~/.ssh/
authorized_keys2”
effugas@10.0.1.10’s password:
effugas@OTHERSHOE ~
$ ssh effugas@10.0.1.10
Last login: Mon Jan 14 05:47:30 2002 from 10.0.1.56
[effugas@localhost effugas]$Инструментарий и ловушки
Много пользователей, одна учетная запись: предотвращение утечки сведений о пароле
При реализации следует учитывать одну важную вещь: содержимое каждого пользовательского файла учетных записей может состоять из многих компонент, к каждой из которых предусмотрен независимый доступ путем предоставления ей своего указателя входа в файл. Если у пользователя много учетных записей, то часто он может воспользоваться этим для подтверждения серверу своей подлинности. К счастью, многие описываемые в этой главе сквозные методы ограничивают использование такой небезопасной методики. (Чем больше хостов могут подключиться к системе, тем больший ущерб может нанести ей компрометация подключившихся хостов.)
Однако до сих пор успешно используется тот факт, что пользовательские файлы учетных записей authorized_keys и authorized_keys2 состоят из нескольких компонент. Благодаря этому группе пользователей может быть предоставлен коллективный доступ к учетной записи без знания ее долгосрочного пароля. Новые члены группы добавляют к учетной записи свои общедоступные компоненты с необходимыми им разрешениями. После этого их личные ключи учитывают добавленные компоненты. При исключении пользователей из группы их общедоступные компоненты удаляются из списка авторизованных ключей. Никто из исключенных пользователей не должен помнить новый пароль!
Необходимо сделать следующее пояснение: постепенно от файлов known_hosts2 и authorized_keys2 отказываются, преобразуя их в файлы known_hosts и authorized_keys. Сервера, которым не нужны специфические файлы протокола SSH2, обращаются к новым файлам, отбрасывая 2 в конце имени файла.
Из-за недоверия к серверам остерегаются использовать пароли, но кто говорит, что клиент намного лучше? Хорошая криптография – это прекрасно, но по существу берется нечто, что запоминается в памяти пользователя и помещается на жесткий диск клиента. А ведь это нечто может быть перехвачено. Помните, что нет безопасного способа запомнить пароль клиента без использования другого пароля, защищающего запомненный пароль. Решений этой проблемы не так много. В одной из реализаций протокола SSH для ее решения используются идентификационные фразы (passwords). Они позволяют расшифровать личный ключ, с помощью которого удаленный сервер проверяет знание клиентом секрета. Идентификационная фраза состоит из анализируемых клиентом паролей. Читатель может добавить идентификационные фразы к обоим ключам протокола SSH2:
# add passphrase to SSH1 key
effugas@OTHERSHOE ~
$ ssh-keygen.exe -p
Enter file in which the key is (/home/effugas/.ssh/
identity):
Key has comment “effugas@OTHERSHOE”
Enter new passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved with the new passphrase.
# add passphrase to SSH2 key
effugas@OTHERSHOE ~
$ ssh-keygen.exe -t dsa -p
Enter file in which the key is (/home/effugas/.ssh/id_dsa):
Key has comment “/home/effugas/.ssh/id_dsa”
Enter new passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved with the new passphrase.
# Note the new request for passphrases
effugas@OTHERSHOE ~
$ ssh effugas@10.0.1.11
Enter passphrase for key “/home/effugas/.ssh/id_dsa”:
FreeBSD 4.3-RELEASE (CURRENT-12-2-01) #1: Mon Dec 3
13:44:59 GMT 2001
$Конечно,
Умалчиваемая правда заключается в том, что большинство людей продолжает доверять своим клиентам и полностью отказываются от идентификационных фраз. Это сильно раздражает администраторов информационных технологий, которые, отключая возможность использования паролей, думают, что тем самым они подталкивают людей к действительно хорошим криптографическим решениям, у которых нет огромных, настежь раскрытых дыр в системе защиты. На самом деле идентификационные фразы ничуть не лучше паролей. В протоколе SSH предусмотрены улучшенные варианты использования идентификационных фраз, которые позволяют распространить один-единственный ввод идентификационной фразы на сравнительно большое число попыток идентификации. Осуществляется это при помощи агента, который может быть размещен где угодно и который занят вычислением личного ключа для выполняющихся под его управлением клиентов SSH. (Это означает, и это важно, что только SSH-клиенты, выполняющиеся под управлением агента, получают доступ к его ключу.) Идентификационная фраза передается агенту, который расшифровывает личный ключ и позволяет клиентам получить доступ без фактического знания пароля. Ниже приведен пример простой реализации сказанного, в котором предполагается, что ключ создается так же, как и в предыдущем примере. Сгенерированный ключ действителен как при обращении к адресу 10.0.1.11, так и к адресу 10.0.1.10.
Прежде всего запустим агента. Обратите внимание на поименованную дочернюю оболочку. Если читатель не укажет ее имя, то будет получено сообщение об ошибке: «Нельзя открыть соединение к вашему агенту аутентификации (Could not open a connection to your authentication agent)».effugas@OTHERSHOE ~ $ ssh-agent bash
После запуска агента добавляем ключи. В случае отсутствия аргумента будет добавлен ключ SSH1:
effugas@OTHERSHOE ~
$ ssh-add
Enter passphrase for effugas@OTHERSHOE:
Identity added: /home/effugas/.ssh/identity
(effugas@OTHERSHOE)При наличии аргумента добавляется ключ SSH2:
effugas@OTHERSHOE ~
$ ssh-add ~/.ssh/id_dsa
Enter passphrase for /home/effugas/.ssh/id_dsa:
Identity added: /home/effugas/.ssh/id_dsa (/home/effugas/
.ssh/id_dsa)Теперь попытаемся подключиться к паре хостов, которые были запрограммированы для получения обоих ключей:
effugas@OTHERSHOE ~
$ ssh -1 effugas@10.0.1.10
Last login: Mon Jan 14 06:20:21 2002 from 10.0.1.56
[effugas@localhost effugas]$ ^D
effugas@OTHERSHOE ~
$ ssh -2 effugas@10.0.1.11
FreeBSD 4.3-RELEASE (CURRENT-12-2-01) #1: Mon Dec 3
13:44:59 GMT 2001
$Добившись подключения к удаленному хосту, следует решить, что делать дальше. С помощью SSH-соединения можно стартовать команду на удаленном сервере или выполнить различные сетевые действия. Можно даже сделать и то, и другое, иногда предоставляя самому себе сетевой путь к только что инициированному серверу.
Переадресация команд: применение переадресации команд для непосредственного выполнения скриптов и каналов
Переадресация (перенаправление) команд – одна из наиболее полезных возможностей протокола SSH. Она вытекает из его основополагающих принципов построения, когда был заново реализован целый ряд приложений r* операционной системы UNIX. У протокола SSH есть хорошо понятная возможность выполнения удаленных команд так, как будто это локальные команды. Например, вместо ввода
effugas@OTHERSHOE ~
$ ssh effugas@10.0.1.11
effugas@10.0.1.11”s password:
FreeBSD 4.3-RELEASE (CURRENT-12-2-01) #1: Mon Dec 3
13:44:59 GMT 2001
$ uptime
3:19AM up 18 days, 8:48, 5 users, load averages: 2.02,
2.04, 1.97
$можно ограничиться следующими командами:
effugas@OTHERSHOE ~
$ ssh effugas@10.0.1.11 uptime
effugas@10.0.1.11”s password:
3:20AM up 18 days, 8:49, 4 users, load averages: 2.01,
2.03, 1.97