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

авторов Коллектив

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

effugas@OTHERSHOE ~

$ 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

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 компоненты скриптов командной оболочки

После рассмотрения элементарных основ можно приступать к обзору реализации некоторых базовых элементов систем передачи файлов (см. табл. 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

spork#

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

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

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

К несчастью, особенно это касается случая предоставления многим пользователям совместного доступа к машине, с правами суперпользователя, когда очень важно знать, кто и когда подключился к машине и что было взломано за это время. Инструментарий su хорош тем, что в нем реализована очень ясная и понятная процедура регистрации подключений, которая показывает, кто именно прошел путь от получения более низкого уровня безопасности

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

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

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

Хотя приведенная команда приводит к самой важной записи пользователя, но это слишком долгий путь для решения задачи аутентификации. Окружение остается в таком же непорочном состоянии, что и процесс, владельцем которого является суперпользователь и который породил это окружение. Работая в таком непорочном окружении, инструментарий su предоставляет функции TTY и сообщает о переключении к другому пользователю. Поскольку это непорочное окружение функции, то, безусловно, это та программа su, которая в действительности выполняется, и ничто иное.

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

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

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

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

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

Переадресация локального порта

По существу, переадресация (перенаправление) локального порта (local port forward) является запросом к протоколу SSH прослушать порт клиента TCP (очень жалко, но в силу достаточно серьезных причин протокол UDP не поддерживается). По мере поступления данных их перенаправляют по каналу через SSH-соединение на заданную машину, видимую с сервера. Образующийся при этом локальный трафик может быть послан на внешний IP-адрес машины, который в целях удобства обычно равен значению «127.0.0.1», а ключевое слово «localhost» ссылается на «этот хост» вне зависимости от значения внешнего IP-адреса.

Синтаксис для переадресации локального порта довольно прост:

ssh -L listening_port:destination_host:destination_port user@forwarding_host

Давайте исследуем эффект запуска процедуры переадресации порта, используя в качестве примера систему IRC (глобальная система, посредством которой пользователи могут общаться друг с другом в реальном масштабе времени). Рассмотрим порт, к которому пользователь хочет получить доступ из другой сети. Очень полезно, когда благодаря identd IRC работает незащищенным. Ниже показан пример необработанного трафика, который поступает во время подключения порта:

effugas@OTHERSHOE ~

$ telnet newyork.ny.us.undernet.org 6667

Trying 66.100.191.2...

Connected to newyork.ny.us.undernet.org.

Escape character is “^]”.

NOTICE AUTH :*** Looking up your hostname

NOTICE AUTH :*** Found your hostname, cached

NOTICE AUTH :*** Checking Ident

Подключимся к удаленному серверу и прикажем клиенту SSH прослушивать попытки подключения IRC к локальному хосту. При получении каких-либо данных они посылаются удаленному хосту, который виден как newyork. ny.us.undernet.org, порт 6667.

effugas@OTHERSHOE ~

$ ssh [email protected] -

L6667:newyork.ny.us.undernet.org:6667

Password:

Last login: Mon Jan 14 06:22:19 2002 from some.net on pts/0

Linux libertiee.net 2.4.17 #2 Mon Dec 31 21:28:05 PST 2001

i686 unknown

Last login: Mon Jan 14 06:23:45 2002 from some.net

libertiee:~>

Давайте выясним, получит ли пользователь те же самые данные от локального хоста, которые он обычно получает по прямому подключению. Получилось даже лучше – identd превысило время ожидания, поэтому фактически появляется возможность разговаривать в системе IRC.