Защита от хакеров корпоративных сетей
Шрифт:
Что в итоге? Пользователь становится незащищенным от повреждений хоста-бастиона и десятков маршрутизаторов, которые могут располагаться на пути между ним и нужным ему хостом. Это не является неожиданным из-за того, что обычно хост-бастион используется не только как маршрутизатор аутентификации, но и как еще что-то. Это очень полезно.
Однако что произойдет в случае отсутствия хоста-бастиона?
Что, если управляемая машина находится дома, она подключена к линии DSL (Digital Subscriber Line – цифровая абонентская линия), между машиной и сетью размещен один из превосходных маршрутизаторов Cable/DSL NAT Routers компании LinkSys (на момент написания книги это было единственное устройство, про которое известно, что оно позволяет надежно транслировать сетевые адреса (функция NAT) по протоколу IPSec) и отсутствует какая-либо возможность разместить демон SSH непосредственно на внешнем интерфейсе?
Что, если пользователь, исходя из самых лучших побуждений, пожелает запретить доступ из глобального
Что, если потребность в удаленном управлении настолько мала, что она не может сравниться со стоимостью аппаратных средств или стоимостью администрирования хоста-бастиона?
Нет проблем. Только не используйте длительное время один и тот же сервер. Хост-бастион – это нечто большее, чем просто система, с помощью которой клиент может успешно связаться с сервером. Хотя для управления соединениями удобно иметь постоянную инфраструктуру и установленные учетные записи пользователя, но в рассматриваемом случае в этом нет особой необходимости. Протокол SSH вполне успешно может экспортировать доступ к своим собственным демонам при помощи механизма переадресации (перенаправления) удаленного порта. Давайте предположим, что сервер может получить доступ к клиенту, а клиент к серверу – нет. Именно так обычно и бывает в мире многоуровневой защиты, где верхние уровни могут связываться с нижними:
# 10.0.1.11 at work here
bash-2.05a$ ssh -R2022:10.0.1.11:22 effugas@10.0.1.10
effugas@10.0.1.10’s password:
[effugas@localhost effugas]$
# 10.0.1.10 traveling back over the remote port forward.
[effugas@localhost effugas]$ ssh -o HostKeyAlias=10.0.1.11 -
p 2022
effugas@127.0.0.1
effugas@127.0.0.1’s password:
FreeBSD 4.3-RELEASE (CURRENT-12-2-01) #1: Mon Dec 3
13:44:59 GMT 2001
$Таким образом, пользователь домашнего компьютера, подключенного к сети и защищенного от внешнего мира межсетевым экраном, может установить на нем протокол SSH, который предоставит ему локальный порт, подключившись и работая через который, можно будет получить доступ к SSH-демону на машине, расположенной на работе.
Инструментарий и ловушки
«Реверс» клиентов
Проблема доступа к клиенту, когда сервера могут инициализировать соединение с клиентом, а клиент с ними нет, обычно разрешается с помощью «реверса» клиентов, при котором клиенты ожидают появления серверов для того, чтобы установить с ними соединение и послать им данные в стиле X-Windows. И действительно, слишком часто кто-то открыто запрашивает режим клиента SSH, для того чтобы разрешить программе sshd подключиться к нему. Подобные решения, если только они с самого начала не были заложены в протокол и его реализацию, в лучшем случае дезинформируют, а в худшем – ужасно небезопасны. Применение для перенаправления SSHD переадресации удаленного порта вместо доступа к Web-сети является уникальным расширением хорошо устанавливаемых и в общем-то безопасных методологий, которые постоянно используются. Внедрение редко используемого клиента в sshd и сервера в ssh является слишком специфичным и совсем необязательным бедствием, которое только выжидает удобный момент для своего свершения.
Сказанное – это прежде всего ответ на постоянный поток запросов, который автор чаще всего наблюдал. (Однако отнеситесь к этому скептически: кто-то попытается свести счеты с половиной способов, изложенных в этой главе, если не во всей книге.)
Эхо на чуждом языке: перекрестное соединение взаимно защищенных межсетевыми экранами хостов
Типовое использование протокола передачи файлов FTP для управления защищенными межсетевыми экранами сетями предусматривает наличие хостов, которые не могут получить соединение и всегда генерируют поток выходящих данных к хосту, который может их получить. (Характеризуя протокол FTP, можно сказать, что, по крайней мере, это несколько странный протокол. Для сохранности своих соединений, упорядоченных в том же самом направлении, необходимо перевести протокол в так называемый пассивный режим (Passive Mode). Пассивный режим протокола FTP предусматривает, что сервер сообщает клиенту номер порта, по которому в случае установления соединения клиент передаст содержимое файла. Напротив, работа в активном режиме (Active Mode) ориентирована на клиента, который ранее инициировал выходящее соединение к серверу и сейчас посылает запрос к серверу для установки сервером выходящего соединения обратно к клиенту по некоторому случайному порту, для того чтобы разместить переданный сервером файл. Межсетевым экранам было
Все хорошо работает в случае, когда одна или другая сторона может получать запросы подключения. Но что произойдет, если ни одна из сторон не сможет этого сделать? Что, если оба хоста расположены позади домашних маршрутизаторов, которые поддерживают возможность сетевой трансляции адресов NAT и им даже присвоены те же самые личные IP-адреса? Еще хуже. Что произойдет, если оба хоста работают за уровнем ядра корпоративного межсетевого экрана Cisco и возникает критическая потребность в интересах дела предоставить двум хостам возможность обмениваться информацией? Как правило, в данном случае усилия администраторов штабов информационных технологий обоих хостов будут направлены на то, чтобы один хост нашел брешь в системе защиты своего межсетевого экрана, что позволило бы другому хосту связаться с первым. Поскольку обязательно произойдет так, что самые параноидные члены штаба информационных технологий настраивают межсетевой экран и управляют им, то в результате будет получен нелепо медленный и болезненный процесс, абсолютно неприемлемый на практике, если только потребность в нем не окажется бесспорной и, возможно, постоянной.
Иногда возможно более изящное решение. Основная идея универсального решения, которое может быть использовано в случае отсутствия непосредственного сетевого соединения, заключается в использовании третьего хоста, так называемого отражателя подключения (connection bouncer). Отражатель подключения получает исходящие от обоих хостов соединения и затем рикошетом отправляет трафик с первого хоста на второй и наоборот.
Приоткрывая завесу
Квитирование установления связи: всего лишь брокер подключения
Рикошет всего соединения может стать причиной превращения отражателя подключений в опасное узкое место, потому что в любом направлении он должен видеть весь трафик дважды: один раз – при получении пакетов и еще один раз – при отсылке их обратно. По этой причине интерес к отражателю подключений отсутствует даже со стороны наиболее амбициозных проектов соединения равноправных узлов хостов P2P (peer-to-peer – соединение равноправных хостов (узлов)). Существуют сугубо экспериментальные системы, которые позволяют находящимся посередине соединения хостам запросто становиться брокером подключения (broker the connection). Брокеры подключения предоставляют двум хостам, запрашивающим выходящие линии связи, средства склеивания друг с другом. Подобные методы описаны в конце главы 12 и их полная работоспособность везде и всегда не гарантируется (авторы разработали их только во время написания книги). Напротив, приведенные ниже методы более работоспособны и надежны.
В общем случае проксисервера являются разновидностью отражателя подключения. Запрос на выходящее соединение перенаправляется по направлению отсылки ответного сигнала входящего соединения от удаленного Web-сервера или что-то в этом роде. В данном случае это не всегда полезно. Существуют небольшие приложения, которые делают из сервера отражатель подключения, но логика их работы слегка запутана, и они не всегда переносимы. Кроме того, почти всегда они не поддерживают криптографических возможностей, которые пусть не всегда нужны, но полезно, когда они есть под рукой.
К счастью, в данном случае нет необходимости ни в том, ни в другом. Если читатель вспомнит, то сначала была описана система с клиентом, который не мог непосредственно инициировать соединение с сервером. Вместо этого для создания сквозной безопасной линии связи по протоколу SSH клиент подтверждал свою подлинность хосту-бастиону и использовал сетевой путь, доступный ему благодаря бастиону. Затем была описана система, в которой для подключения клиента хост-бастион уже не предусматривался. Сервер самостоятельно инициировал свое собственное соединение с внешним миром, экспортируя при помощи переадресации удаленного порта путь клиенту для того, чтобы он проложил к нему обратный туннель. Так получилось, что этот путь был экспортирован непосредственно клиенту, хотя в этом не было необходимости. На самом деле сервер мог бы использовать переадресацию удаленного порта своему собственному SSH-демону на любом хосте, который был бы доступен как серверу, так и клиенту. После этого клиенту было бы достаточно просто обратиться к этому доступному как со стороны сервера, так и со стороны клиента хосту, который внезапно стал хостом-бастионом. Ниже рассмотрено объединение двух названных методов в один: