Первым шагом для получения доступа к удаленной системе при работе в 88Н является подтверждение пользователем своей подлинности при помощи процесса аутентификации. С него начинает свою работу каждый, кто использует ББН.

Основной способ получения доступа: аутентификация при помощи пароля «Вначале была командная строка». Основной сутью протокола ББН является то, что командная строка удаленной машины всегда была и будет. Ее синтаксис прост: dan@OTHERSHOE ~ # ssh user@host $ ssh dan@10.0.1.11 dan@10.0.1.11”s password:

FreeBSD 4.3-RELEASE (CURRENT-12-2-01) #1: Mon Dec 3 13:44:59 GMT 2001 $

Если задать опцию - Д то при выполнении приложения X-Windows автоматически будет создан туннель. Представляет интерес интерфейс обработки паролей SSH. При необходимости задания пароля безразлично, где именно в цепочке команд SSH он будет задан. В любом случае SSH почти всегда сможет его запросить. Это не тривиально, но очень полезно. Однако паролям присущи свои собственные проблемы. Если хосты А и В совместно используют пароли, то хост А может обмануть пользователя хоста В, и наоборот. В главе 12 были подробно описаны наиболее интересные подробности о слабых сторонах паролей. Таким образом, SSH поддерживает значительно больший механизм аутентификации (подтверждения подлинности) клиента серверу.

Прозрачный способ получения доступа: аутентификация при помощи личного ключа Системы с асимметричным ключом предлагают мощный способ подтверждения одним хостом своей подлинности большому числу других хостов. Большинство людей может узнать человеческое лицо, но не «надеть» его на себя. Точно так же многие хосты могут распознать личный ключ по его общедоступной части, но самостоятельно воспроизвести его личную, секретную часть они не смогут. SSH генерирует две части личного ключа, которые другие хосты могут распознать: одну - для протокола SSH1, другую - для SSH2.

Аутентификация сервера клиенту Хотя для клиента использование ключевой пары, состоящей из общедоступного и личного ключа, необязательно, сервер все равно обязан предоставить такой ключ, чтобы клиент, однажды доверившись хосту, впоследствии всегда мог его идентифицировать. В этом проявляется отличие от протокола SSL, который предполагает, что клиент доверяет некоторому авторитетному источнику сертификатов, например VeriSign, веря его сертификатам при обмене данными с любым другим хостом. Напротив, протокол SSH допускает риск первого представления хосту, а затем, учитывая этот риск, пытается распространить его на все последующие сессии. При этом становится возможным значительно сократить накладные расходы за счет менее защищенной модели аутентификации сервера по умолчанию. (Это пример одного из многих компромиссов. Неуправляемые системы безопасности не устанавливают, а неразвернутые системы защиты, как правило, ужасно ненадежны.) Первые подключения к SSH-серверу в общем случае выглядят следующим образом:

effugas@OTHERSHOE ~ $ ssh effugas@ 10.0.1.11 The authenticity of host’10.0.1.11 (10.0.1.11)’ can’t be established.
RSA key fingerprint is
6b:77:c8:4f:el:ce:ab:cd:30:b2:70:20:2e:64:ll:db.

Are you sure you want to continue connecting (yes/по)? yes Warning: Permanently added ’10.0.1.11’ (RSA) to the list of known hosts.

effugas@ 10.0.1.11 ’ s password :
FreeBSD 4.3-RELEASE (CURRENT-12-2-01) #1: Mon Dec 3 13:44:59 GMT 2001 $

Как известно, ключи Host Key генерируются автоматически после инсталляции SSH-сервера. Часто это сопровождается проблемами из-за чрезмерной молчаливости программ инсталляции. Иногда они перезаписывают или используют не по назначению существующие ключи. В результате при работе клиентов возникают жуткие ошибки, которые указывают на возможность существования кого-то или чего-то, фальсифицирующего сервер. Но обычно это означает всего лишь законную потерю ключа или его разрушение в результате последовательного продвижения пользователей к только им известной цели и получения ими доступа к новым, возможно, фальсифицированным ключам. Это не вполне понятно, но именно так все и происходит. Для систем, которым необходимо обеспечить повышенную безопасность, чрезвычайно важно задуматься над использованием достойных способов безопасного размещения файлов ~/.ssh/known_hosts и ~/.ssh/known_hosts2. Эти файлы содержат список ключей, которые клиенты могут распознать. Большая часть этой главы посвящена обсуждению вопросов размещения названных файлов в произвольных нетрассируемых сетях (disroutable networks). После обнаружения работоспособного в сети читателя способа размещения этих файлов следующая идея проектирования могла бы оказаться плодотворной: каждый клиент обращается к центральному хосту с запросом нового файла, который известен хосту и который пересылает его клиенту. Аутентификация клиента серверу Использование клиентом асимметричных ключей полезно, но необязательно. Двумя главными шагами в этом направлении являются генерация клиентом ключей и последующее информирование об этом сервера, для того чтобы он смог принять сгенерированные ключи. Первый шаг, то есть генерация ключей, инициализируется при использовании команды ssh-keygen для SSH1 и команды ssh-keygen -t dsa для SSH2:

effugas@OTHERSHOE ~ $ ssh-keygen Generating public/private rsal key pair.
Enter file in which to save the key (/home/effugas/.ssh/ identity):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/effugas/.ssh/ identity.
Your public key has been saved in /home/effugas/.ssh/ identity, pub.
The key fingerprint is:
c7:d9:12:f8:b4:7b:f2:94:2c:87:43:14:5a:cf:ll:ld effugas@OTHERSHOE effugas@OTHERSHOE ~
$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/effugas/.ssh/ iddsa):
Enter passphrase (empty for no passphrase): <ENTER>
Enter same passphrase again: <ENTER>
Your identification has been saved in /home/effugas/.ssh/ iddsa.
Your public key has been saved in /home/effugas/.ssh/ iddsa.pub.
The key fingerprint is:
e0:e2:a7:lb:02:ad:5b:0a:7f:f8:9c:dl:f8:3b:97:bd
effugas@OTHERSHOE

Затем наступает время второго шага: следует проинформировать сервер о необходимости проверить подключенных клиентов на предмет обладания ими личного ключа (.ssh/identity для SSH1, ssh/id_dsa для SSH2). Такая проверка заключается в посылке серверу его общедоступного элемента, который затем добавляется в файл домашней директории пользователя. Домашняя директория пользователя задается самим пользователем:.ssh/authorized_keys для SSH1 и. ssh/authorized_keys2 для SSH2. На самом деле не существует элегантного способа реализовать в протоколе SSH то, что было сказано. Это самая слабая сторона комплекса инструментальных средств, а вполне возможно, что и самого протокола непосредственно. Для преодоления данного недостатка Уильям Стеарнс (William Steams) проделал в этом направлении очень большую работу. Его скрипт, посвященный этой проблеме, находится по адресу

www.steams.org/ssh-keyinstall/ssh-keyinstall-0.1.3.tar.gz. Реализованные в нем вещи аморальны, и он даже не пытается скрывать это. Приведенный ниже пример, используя недавно загруженные ключи пользователя, устраняет необходимость в идентификации пароля. Попутно появляется дополнительное преимущество, которое заключается в отсутствии необходимости использовать какие-либо дополнительные приложения (отметим, что от читателя потребуется ввести пароль):

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. После этого ему следует удостовериться в том, что он находится в домашней директории, и установить режимы работы с файлом таким образом, чтобы никто другой не смог прочитать то, что он собирается записать. При необходимости читатель может создать директорию (опция -р позволяет по желанию создавать директории), а затем он получит переданные по каналу данные и добавит их к файлу ~/.ssh/authorized_keys, которые демон будет использовать для аутентификации удаленного личного ключа. Почему сказанное не включено в число стандартных функциональных возможностей и является большой загадкой? Возможно, потому, что оно реализуется расширенной командой, состоящей из нескольких частей, которая, тем не менее, хорошо работает:

effugas@OTHERSHOE ~ $ cat ~/.ssh/identity.pub ssh -1 effugas@10.0.1.10 “cd ~

&& umask 077 && mkdir -p .ssh && cat » ~/.ssh/
authorizedkeys”
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]$

Инструментарий и ловушки

Много пользователей, одна учетная запись: предотвращение утечки сведений о пароле

При реализации следует учитывать одну важную вещь: содержимое каждого пользовательского файла учетных записей может состоять из многих компонент, к каждой из которых предусмотрен независимый доступ путем предоставления ей своего указателя входа в файл. Если у пользователя много учетных записей, то часто он может воспользоваться этим для подтверждения серверу своей подлинности. К счастью, многие описываемые в этой главе сквозные методы ограничивают использование такой небезопасной методики. (Чем больше хостов могут подключиться к системе, тем больший ущерб может нанести ей компрометация подключившихся хостов.)

Однако до сих пор успешно используется тот факт, что пользовательские файлы учетных записей authorizedkeys и authorized_keys2 состоят из нескольких компонент. Благодаря этому группе пользователей может быть предоставлен коллективный доступ к учетной записи без знания ее долгосрочного пароля. Новые члены группы добавляют к учетной записи свои общедоступные компоненты с необходимыми им разрешениями. После этого их личные ключи учитывают добавленные компоненты. При исключении пользователей из группы их общедоступные компоненты удаляются из списка авторизованных ключей. Никто из исключенных пользователей не должен помнить новый пароль!

Необходимо сделать следующее пояснение: постепенно от файлов known_hosts2 и authorized_keys2 отказываются, преобразуя их в файлы known hosts и authorized keys. Сервера, которым не нужны специфические файлы протокола SSH2, обращаются к новым файлам, отбрасывая 2 в конце имени файла.

Из-за недоверия к серверам остерегаются использовать пароли, но кто говорит, что клиент намного лучше? Хорошая криптография - это прекрасно, но по существу берется нечто, что запоминается в памяти пользователя и помещается на жесткий диск клиента. А ведь это нечто может быть перехвачено. Помните, что нет безопасного способа запомнить пароль клиента без использования другого пароля, защищающего запомненный пароль. Решений этой проблемы не так много. В одной из реализаций протокола SSH для ее решения используются идентификационные фразы (passwords). Они позволяют расшифровать личный ключ, с помощью которого удаленный сервер проверяет знание клиентом секрета. Идентификационная фраза состоит из анализируемых клиентом паролей. Читатель может добавить идентификационные фразы к обоим ключам протокола SSH2:

# add passphrase to SSH 1 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 authenti cati on 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]$ AD 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. Она вытекает из его основополагающих принципов построения, когда был заново реализован целый ряд приложений г* операционной системы 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

Действительно, можно образовать канал вывода между хостами, например так, как это показано в приведенном ниже простейшем примере:

effugas@OTHERSHOE ~ $ ssh effugas@10.0.1.11 “Is -1” grep usocks

effugas@10.0.1.11”s password:
drwxr-xr-x 2 effugas effugas 1024 Aug 5 20:36
usocksd-0.9.3
-rw-r-r- 1 effugas effugas 54049 Jan 14 20:21 usocksd-0.9.3 .tar. gz

Подобные функциональные возможности необычайно полезны для создания сетевых туннелей. Основная идея туннелей заключается в том, что нечто создает поток данных через обычно непреодолимые границы сетей. В данном случае разделенные границами сети немного напоминают аппаратные средства, поделенные на совершенно не связанные между собой блоки. (Требуется приложить много усилий для эффективного обособления программ и информационных файлов. Если этого удается добиться, то отказ в одной части программного кода почти никак не влияет на работу всего кода в целом и не приводит к отказу еще чего-нибудь благодаря абсолютной защите памяти, планированию работы центрального процессора и т. д. Между тем простое выполнение почтового сервера или Web-сервера читателя на различных системах при условии, что их много и они могут быть распределены по всему земному шару, предоставляет совершенно другой класс разделения процессов.) SSH превращает каналы в коммуникационную подсистему между хостами. В этих условиях становится справедливым следующее правило . Почти всегда можно использовать канал для передачи данных между процессами. При этом протокол SSH позволяет процессам разных хостов оставаться локальными.

Примечание

Не все используемые команды могут быть объединены путем создания канала. Тем из них, которые захватывают терминал и выводят на него данные, как, например, командам lynx, elm, pine или tin, для правильной работы требуется так называемая поддержка функций телетайпа TTY Названные команды в различных режимах рисования и стилях применяют так называемые неиспользуемые символы. По существу эти символы не используют 8 бит байта так, как это необходимо при применении каналов. Протокол SSH по-прежнему поддерживает использующие функции TTY-команды, но для этого требуется определить опцию -t.

Удаленное выполнение объединенных в канал команд может оказаться очень эффективным. В этом случае простейшие команды неожиданно приобретают способность преодолевать границы серверов и могут быть использованы с большой пользой. Например, большинство операций передачи файлов могут быть реализованы с использованием небольшого числа базовых инструментальных средств, которые присутствуют почти во всех дистрибутивах систем UNIX и Cygwin. Некоторые из базовых элементов перечислены в табл. 13.3.

Таблица 13.3.

Полезные для переадресации команд SSH компоненты скриптов командной оболочки

Символ Командо Описание
1 Символ канала Переадресация вывода приложения, указанного слева от символа канала, приложению, указанному справа от этого же символа
s
Точка с запятой Позволяет нескольким командам выполняться в режиме канала

Логическое И Позволяет нескольким командам выполняться в режиме канала. Завершает описанный режим работы при аварийном завершении хотя бы одной из команд
>
Переадресация вывода в файл Переадресация вывода приложения, указанного слева от символа переадресации вывода в файл, имя которого указано справа от указанного символа
»
Добавление данных вывода в конец файла Переадресация вывода приложения, указанного слева от символа переадресации вывода в конец файла, имя которого указано справа от указанного символа
cat
Конкатенация (связывание} Связывает вывод потока, который может быть потоком вывода приложения или канала, слева от символа конкатенации с потоком справа от этого же символа, который затем может быть перенаправлен в файл или по каналу передан в другое приложение cat file: Вывод файла в строку битов
is
Список файлов Выводит листинг каталогов
tar
Архив на ленте tar -cf - /path: преобразует данные директории и содержащихся в ней файлов в поток байтов tar -xf -: преобразует заархивированный поток байтов в директории и файлы
head
Чтение начальных байтов head -с 100-'. выводит первые 100 байт потока

head -с 100 file: выводит первые 100 байт файла

tail
Вывод последних байтов tail -с 100 -: Выводит последние 100 байт потока

tail -с 100 file: Выводит последние 100 байт

После рассмотрения элементарных основ можно приступать к обзору реализации некоторых базовых элементов систем передачи файлов (см. табл. 13.4).

Таблица 13.4.

Передача файлов с использованием общих компонентов командной оболочки

Команда Эквивалент SSH (OpenSSH? 13.2?) Разъяснение
GET
ssh user®host '“cat
«Получает содержание некоторого

file” >file
удаленного файла как вывод удаленного хоста и перенаправляет полученные байты в локальный файл»
PUT
cat file  ssh user® host
* П олуч ает соде ржа н и е н е которо го

“cat > file”
удаленного файла как вывод локального хоста, получает доступ к потоку данных на удаленном хосте и перенаправляет полученные байты в удаленный файл«
LIST
ssh user® host Is /path
«Получает список всех файлов, доступных по определенному удаленному пути, как вывод с удаленного хоста«
MGET
ssh user@host “tar
«Выводит файлы и каталоги удаленного

cf - /path”  tar-xf -
каталога, которые преобразованы архиватором tar в в формат потока байтов, и передает их по каналу локальной программе извлечения данных из сжатого архива структуры каталогов для восстановления удаленных файлов на локальном хосте»
MPUT
tar -cf - /path  ssh
«Преобразует файлы и каталоги локаль

user@host “tar-xf
ного каталога в отформатированный архиватором поток байтов, который по каналу передается удаленной программе преобразования этого потока данных в сжатый архив структуры каталогов для повторного создания локальных файлов на удаленном хосте*
REsuME
ssh user@host “tail -c
«Определяет количество байтов, пере
GET
nsmoteize
данных команде get, после чего пере

-local filesize
хватывает только необходимое число

file” »file
байтов»
ResuME
tail -c localfze-
«Определяет количество байтов, пере
PUT
nsmoteizefile »
данных команде put, после чего посыла

file
ет только необходимое число байтов«-

Одно из самых полезных свойств протокола SSH заключается в том, что когда протокол удаленно выполняет команды, то он делает это в сильно ограниченном контексте. На самом деле пользующиеся доверием пути компилируются в загрузочный код демона протокола SSH, который выполняется без указания абсолютного пути. В это время абсолютный путь хранится в директориях /usr/local/bin, /usr/bin и /bin. (В протоколе SSH также реализована возможность переадресации переменных окружения. Поэтому если командной оболочке нужен какой-либо путь, то на сервер может быть послано имя переменной, в которой он записан. Это небольшая жертва безопасности в угоду довольно приличного скачка функциональных возможностей.)

Приоткрывая завесу

Инструментарий su (silent user): глупый пользователь, права суперпользователя для новичков

Вероятно, инструментарий su является беззубым тигром в мире безопасности программного обеспечения. Так же как и инструментарий с командной строкой, который, как ожидалось, должен был позволить кому-то переключить и изменить разрешения пользователя, инструментарий su позиционируется как наиболее перспективная альтернатива непосредственному подключению к необходимой учетной записи. Даже почтенная система OpenBSD совершает подобную ошибку:

$ ssh root@ 10.0.1.220 root@10.0.1.220’s password:
Last login: Fri Dec 28 02:02:16 2001 from 10.0.1.150 OpenBSD 2.7 (GENERIC) #13: Sat May 13 17:41:03 MDT 2000 Welcome to OpenBSD: The proactively secure Unix-like operating system.
Please use the sendbug(l) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latestversion of the code. With bug reports, please try to ensure thatenough information to reproduce the problem is enclosed, and if aknown fix for it exists, include that as well.
Terminal type? [xterm]
Don’t login as root, use su spork#

Этот совет, как и его предназначение, смешен. Идея заключается в том, что пользователю в процессе своей повседневной деятельности следует обращаться к своей обычной учетной записи. А при необходимости выполнения каких-либо функций администратора ему предлагается соответствующим образом проинсталлировать и настроить свою командную оболочку (которая, как правило, не имеет достаточных полномочий для администрирования системы), для того чтобы можно было запустить программу, которая запросит пароль суперпользователя. В результате командная оболочка пользователя приобретет статус доверенного программного средства. Было бы прекрасно, если можно было бы подстраховаться на случай, когда командная оболочка пользователя действительно соберется выполнить su. Поразмышляйте над этим. Существует бесчисленно много возможностей для нанесения ущерба командной оболочки, не позволяя ей выполнить запуск su. Злоумышленник может пойти и другим путем, используя один из автоматических и невидимых конфигурационных файлов, bashrc/.profile/.tcshrc. Каждый из них может определять загрузку альтернативных программ до того, как будет загружена подлинная программа su. Альтернативные программы могли бы перехватывать трафик клавиатуры во время ввода пароля суперпользователя и записывать его в файл или пересылать перехваченные данные по сети. Если существует водораздел между учетной записью обычного пользователя и суперпользователя, то какой смысл упоминать о нечто, что ранее доверием не пользовалось, но может быть модифицировано для придания ему статуса доверяемого при помощи ресурса, целиком принадлежащего «вражеской территории» и контролируемого там? Это точная аналогия назначения лисы, ответственной за сохранность кур в курятнике. Объекту, которому не доверяют, предоставляют ключи от области, безопасность которой должна быть обеспечена при любых условиях. И при этом предполагают, что ничего плохого не произойдет. Разве это не смешно?

Если знать, что ничего страшного не произойдет, то не обязательно уделять столько внимания первоочередному рассмотрению всевозможных ограничений!

К несчастью, особенно это касается случая предоставления многим пользователям совместного доступа к машине, с правами суперпользователя, когда очень важно знать, кто и когда подключился к машине и что было взломано за это время. Инструментарий su хорош тем, что в нем реализована очень ясная и понятная процедура регистрации подключений, которая показывает, кто именно прошел путь от получения более низкого уровня безопасности к более высокому. Создание в учетной записи суперпользователя индивидуальных входов авторизованных ключей authorized keys недостаточно, потому что на самом деле никак не регистрируется, какой именно ключ был использован для получения доступа к какой-либо учетной записи. (Этот недостаток планируется исправить позднее.) Потребность в подобной отчетности настолько велика, что она может перевесить преимущества концепции наложения ограничений на учетные записи отдельных пользователей, которая не может рассматриваться как реальная система безопасности. Другими словами, учетная запись суперпользователя есть нечто, к чему читатель всегда может получить доступ. К тому же читатель может захотеть получить возможность предотвратить конфликтную и непроизвольную работу в режиме командной строки, защищающую от затирания данных сервера!

Можно ли обеспечить подотчетность, о которой только что шла речь, без обязательного принуждения к использованию паролей при передаче данных через небезопасное сетевое пространство? Да, если использовать SSH. Когда протокол SSH выполняет переадресацию команды, то при этом он по умолчанию использует очень ограниченное окружение, которое ему предоставляет командная оболочка. Окружение по умолчанию - это комбинация sshd и директории /bin/sh, владельцем которых является пользователь с правами суперпользователя. Отчасти окружение по умолчанию игнорирует клиента. По умолчанию оно обладает иммунитетом к каким-либо повреждениям, которые могут произойти в командной оболочке по вине ее конфигурационных файлов или еще чего-нибудь. Это делает окружение по умолчанию идеальным окружением для su!

ssh user@host -t “/bin/su -1 user2”

Хотя приведенная команда приводит к самой важной записи пользователя, но это слишком долгий путь для решения задачи аутентификации. Окружение остается в таком же непорочном состоянии, что и процесс, владельцем которого является суперпользователь и который породил это окружение. Работая в таком непорочном окружении, инструментарий su предоставляет функции TTY и сообщает о переключении к другому пользователю. Поскольку это непорочное окружение функции, то, безусловно, это та программа su, которая в действительности выполняется, и ничто иное. Обратите внимание, что только /bin/sh доверено поддерживать чистоту окружения команды. Например, bash загрузит свои конфигурационные файлы даже в случае ее применения для выполнения команды. Рассмотренный метод потребуется команде chsh (смена командной оболочки) для обеспечения своей безопасности. Но для пользователя это не означает необходимости переключиться от bash к /bin/sh, используя, profile конфигурацию в своей домашней директории. Пользователь может поместить команду exec bash - login - / и получить доступ к bash во время интерактивного подключения, пока ему доступно безопасное окружение для удаленного выполнения команд.

Существует другая важная проблема, о которой мало что известно. SSHD загружает файл ~/.ssh/environment даже для переадресованных команд, устанавливая параметры пользовательского окружения. Поэтому в первую очередь могут быть атакованы параметры окружения, предназначенные для хранения пути запуска удаленного инструментария su. Переназначая путь к некоторому поврежденному двоичному файлу, владельцем которого выступает пользователь, может оказаться уязвимым ввод чего-либо в командной строке. Отключить синтаксический разбор файла ~/.ssh/environment непросто. Обычно гораздо легче определить абсолютный путь к su - /bin/su, хотя иногда путь /usr/bin/su лучше не взламывать. Другой основной способ атаки предусматривает предварительную загрузку библиотеки, изменяющую функции, от которых могло бы зависеть выполнение данного приложения. Поскольку инструментарий su является приложением класса setuid, то система будет автоматически игнорировать любую предварительно загруженную библиотеку.

Наконец, важно использовать опцию -/ инструментария su для определения необходимости очистки всего окружения входа в систему сразу после установки соединения. Иначе помехи от пользовательской командной оболочки распространятся до оболочки суперпользователя!

Переадресация портов: доступ к ресурсам удаленных сетей

Протокол SSH, установив соединение, предоставляет возможность создать портал (портал - общедоступный региональный узел компьютерной сети) ограниченной возможности соединения от клиента к серверу или от сервера к клиенту. Это не глобальный портал. Простое выполнение протокола SSH по мановению волшебной палочки не инкапсулирует сетевой трафик машины читателя. Существование самолетов еще не означает, что человек может полететь, лишь помахав руками. Но существуют способы и системы, которые позволяют добиться максимальной полезности от применения протокола SSH при создании систем сетевого туннелирования.

Туннелирование | Защита от хакеров корпоративных сетей | Переадресация локального порта


Защита от хакеров корпоративных сетей



Новости за месяц

  • Июнь
    2019
  • Пн
  • Вт
  • Ср
  • Чт
  • Пт
  • Сб
  • Вс