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

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

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

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

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

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

[email protected] ~

$ 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.

[email protected] ~

$ 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.

[email protected] ~

$ telnet 127.0.0.1 6667

Trying 127.0.0.1...

Connected to 127.0.0.1.

Escape character is “^]”.

NOTICE AUTH :*** Looking up your hostname

NOTICE AUTH :*** Found your hostname, cached

NOTICE AUTH :*** Checking Ident

NOTICE AUTH :*** No ident response

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

$ irc Effugas 127.0.0.1

*** Connecting to port 6667 of server 127.0.0.1

*** Looking up your hostname

*** Found your hostname, cached

*** Checking Ident

*** No ident response

*** Welcome to the Internet Relay Network Effugas (from

newyork.ny.us.undernet.org)

Случай, когда конфигурация организована в виде растущего сверху вниз большого дерева меню, намного сложнее. Работа с таким деревом раздражает, потому при желании поменять сервер необходимо каждый раз модифицировать дерево. Фактически в этом случае нужно повторно построить соответствие между именами и IP-адресами. Вместо имени newyork.ny.us. undernet.org приложению возвращается его фактический IP-адрес. Нужно, чтобы вместо него был возвращен адрес 127.0.0.1. Для этого модифицируют hosts-файл, который почти всегда проверяется сервером DNS перед началом просмотра. Этот файл позволяет пользователю вручную установить соответствие между именами и их IP-адресами. Синтаксис записей hosts-файла прост: