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

[email protected] ~ $ ssh-agent bash

После запуска агента добавляем ключи. В случае отсутствия аргумента будет добавлен ключ SSH1:

[email protected] ~

$ ssh-add

Enter passphrase for [email protected]:

Identity added: /home/effugas/.ssh/identity

При наличии аргумента добавляется ключ SSH2:

[email protected] ~

$ ssh-add ~/.ssh/id_dsa

Enter passphrase for /home/effugas/.ssh/id_dsa:

Identity added: /home/effugas/.ssh/id_dsa (/home/effugas/

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

[email protected] ~

$ ssh -1 [email protected]

Last login: Mon Jan 14 06:20:21 2002 from 10.0.1.56

[[email protected] effugas]$ ^D

[email protected] ~

$ ssh -2 [email protected]

FreeBSD 4.3-RELEASE (CURRENT-12-2-01) #1: Mon Dec 3

13:44:59 GMT 2001

Добившись подключения к удаленному хосту, следует решить, что делать дальше. С помощью SSH-соединения можно стартовать команду на удаленном сервере или выполнить различные сетевые действия. Можно даже сделать и то, и другое, иногда предоставляя самому себе сетевой путь к только что инициированному серверу.

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

Переадресация (перенаправление) команд – одна из наиболее полезных возможностей протокола SSH. Она вытекает из его основополагающих принципов построения, когда был заново реализован целый ряд приложений r* операционной системы UNIX. У протокола SSH есть хорошо понятная возможность выполнения удаленных команд так, как будто это локальные команды. Например, вместо ввода

[email protected] ~

$ ssh [email protected]

[email protected]”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

можно ограничиться следующими командами:

[email protected] ~

$ ssh [email protected] uptime

[email protected]”s password:

3:20AM up 18 days, 8:49, 4 users, load averages: 2.01,

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

[email protected] ~

$ ssh [email protected] “ls –l” | grep usocks

[email protected]”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

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

Примечание

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

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

Таблица 13.3.

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

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

Таблица 13.4.

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

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

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

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

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

$ ssh [email protected]

[email protected]’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(1) 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

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

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

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

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