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

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

# Server: Export link to a mutually accessible “floating

# bastion server”

[effugas@localhost effugas]$ ssh -R20022:127.0.0.1:22

[email protected]

[email protected]’s password:

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

13:44:59 GMT 2001

$

# Client: Import link from the mutually accessible

# “floating bastion server” (not using netcat,

# because we’re assuming zero software installation

# for this host)

effugas@OTHERSHOE ~

$ ssh -L30022:127.0.0.1:20022 [email protected]

[email protected]’s password:

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

13:44:59 GMT 2001

$

# Client: Initiate a connection over the imported/

# exported link, verifying the endpoint goes where we

# think it does.

effugas@OTHERSHOE ~

$ ssh -o HostKeyAlias=10.0.1.10 -p 30022 [email protected]

Enter passphrase for key “/home/effugas/.ssh/id_dsa”:

Last login: Mon Jan 14 12:00:19 2002 from 10.0.1.56

[effugas@localhost effugas]$

На

полпути: что теперь?

После блуждания в поисках достижения поставленной цели читатель наконец обнаружит себя в конечной точке, к которой он все это время предпринимал попытки проложить туннель. И что, считать теперь спорный вопрос решенным? Другими словами, уместно спросить: «Что теперь?» Конечно, читатель может администрировать все, что ему нужно, пользуясь удаленной командной оболочкой. Он может подключиться к различным хостам, которые могут предоставить читателю точки сетевого доступа к необходимым ему ресурсам. Но протокол SSH предлагает нечто большее, особенно когда используется переадресация команд. Наиболее важный вывод этой главы состоит в том, что все рассмотренные в ней методы могут быть успешно сведены в единую цепочку. Ниже приведены примеры, которые показывают, каким образом ранее описанные способы могут быть соединены вместе точно так же, как и строительные кубики в конструкторе LEGO, способствуя появлению новых и интересных способов.

Стандартная передача файла при помощи протокола SSH

Стандартным инструментальным средством копирования файлов внутри SSH-туннеля является программа Secure Copy (scp). Ее общепринятый базовый синтаксис весьма близок к синтаксису команды cp. Путь на удаленную машину определяется обычным образом: user@host:/path. Ниже приведен пример копирования локального файла dhcp.figure.pdf в директорию /tmp, расположенную на удаленном хосте 10.0.1.11:

dan@OTHERSHOE ~

$ scp dhcp.figure.pdf [email protected]:/tmp

[email protected]”s password:

dhcp.figure.pdf 100% |***************************| 3766 00:00

При копировании директории следует задать флажок – r, что очень похоже на формат команды cp. При копировании опция – r указывает на необходимость рекурсивного просмотра всего дерева директории сверху вниз. Программа scp сделана по образцу команды rcp и выполняет все, что необходимо, но если честно, то не очень хорошо. Ошибочная настройка путей часто является причиной аварийного завершения серверной части программы scp, а специфицировать опции командной строки ssh нереально. Сказанное не означает невозможности воспользоваться некоторыми наиболее интересными системами туннелирования. Программа scp предоставляет возможность повторной настройки ssh посредством более многословного интерфейса файла конфигурации. Читатель, введя man ssh, может найти полный список настраиваемых опций. Ниже показан пример спецификации опции HostKeyAlias, позволяющей проверить адресата локального переадресованного порта SSH:

# setting up the tunnel: Local port 2022 is routed to port

# 22(ssh) on 10.0.1.10, through the bastion host of

# 10.0.1.11

dan@OTHERSHOE ~

$ ssh -L2022:10.0.1.10:22 [email protected]

[email protected]’s password:

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

13:44:59 GMT 2001

$

# Copy a file through the local port forward on port 2022,

# and verify we’re ending up at 10.0.1.10.

dan@OTHERSHOE ~

$ scp -o “HostKeyAlias 10.0.1.10” -o “Port 2022”

dhcp.figure.pdf

[email protected]:/tmp

[email protected]’s password:

dhcp.figure.pdf 100% |**************************| 3766 00:00

В результате был получен доступ с правами суперпользователя к хосту с IP-адресом 10.0.1.10, который был связан по каналу с хостом 10.0.1.11. Что произойдет, если хост 10.0.1.11 вместо оказания должного уважения команде, которая перенаправляет пакеты к демону другого SSH-хоста, перешлет их к собственному хосту? Другими словами, что произойдет, если в результате повреждения сервера он начнет работать так, как если бы была указана опция – L2022:127.0.0.1:22 вместо L2022:10.0.1.10:22? Давайте попробуем так сделать:

dan@OTHERSHOE ~

$ ssh -L2022:127.0.0.1:22 [email protected]

[email protected]’s password:

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

13:44:59 GMT 2001

$

dan@OTHERSHOE ~

$ scp -o “HostKeyAlias 10.0.1.10” -o “Port 2022”

dhcp.figure.pdf

[email protected]:/tmp

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Someone could be eavesdropping on you right now (man-in-themiddle

attack)!

It is also possible that the RSA host key has just been

changed.

The fingerprint for the RSA key sent by the remote host is

6b:77:c8:4f:e1:ce:ab:cd:30:b2:70:20:2e:64:11:db.

Please contact your system administrator.

Add correct host key in /home/dan/.ssh/known_hosts2 to get

rid of this message.

Offending key in /home/dan/.ssh/known_hosts2:3

RSA host key for 10.0.1.10 has changed and you have

requested strict checking.

lost connection

Комментируя

описанное, следует обратить внимание читателя на одно важное замечание. Очень важно управлять ключами идентификации (identity keys) протокола SSH! Хотя бы только потому, что правильный ключ помещается в файл known_hosts2. Прежде всего он записывается туда для того, чтобы была возможность различать ответивший демон SSH: был ли прислан ответ при обмене данными с правильным хостом или ответ был получен во время обмена данными с неверным хостом? Одним из самых больших недостатков протокола SSH является то, что благодаря некоторым особенностям обновления серверов они постоянно изменяют свои идентификационные ключи. Это вынуждает пользователей смириться с любыми изменениями в ключах, даже если автором изменений станет атакующий. Dug Song воспользовалась доступной для использования ловушкой в своем великолепном пакете dsniff, предназначенном для перехвата, анализа и прослушивания трафика. Пакет dsniff доступен по адресу www.monkey.org/~dugsong/dsniff/. Он демонстрирует, с какой легкостью пользователь может воспользоваться различными трюками для одурачивания сессии SSH1 в результате получения им возможности стать «обезьянкой посередине» («monkey in the middle»).

Инкрементная передача файла по протоколу SSH

Несмотря на то что программа rsync является всего лишь стандартной компонентой стандартного окружения большинства систем UNIX, она является наиболее уважаемой порцией программного кода среди созвездия программ с открытыми исходными текстами. По существу, rsync относится к классу программ обновления файлов по шагам с нарастающим итогом. Клиент и сервер обмениваются небольшими порциями итоговых данных о содержимом совместно используемого ими файла. При этом определяются блоки, требующие обновления, а затем только они и пересылаются. Если после последнего выполнения программы rsync изменились только 5 Мб 10-гигабайтного диска, то полная пропускная способность канала обмена данными между клиентом и сервером, затрачиваемая на их синхронизацию, будет всего лишь немного больше пяти мегов (megs).

Программу rsync можно найти по адресучто неудивительно, поскольку считается, что ее автор Андрей Тридгель (Andrew Tridgell) также принимал активное участие в подготовке и начале реализации проекта Samba, в рамках которого решалась задача совместного использования файлов Windows машинами UNIX.

Описанная программа проста в использовании, особенно совместно с ssh. Базовый синтаксис инструментария очень похож на scp:

dan@OTHERSHOE ~

$ rsync -e ssh dhcp.figure.pdf [email protected]:/tmp

[email protected]’s password:

В отличие от scp, по умолчанию программа rsync более молчалива. Использование флажка – v позволяет получить больше отладочных выходных данных. Как и в случае с scp, флажок – r необходим для задания копирования деревьев директорий. На сканирование директорий требуется время, что приводит к значительной задержке перед началом собственно копирования. Особенно это касается платформы Windows. У программы rsync более удачный синтаксис для использования дополнительных разновидностей транспортировки данных по протоколу ssh. Опция – e непосредственно определяет использование командной строки для удаленного выполнения команды. Для того чтобы использовать не только протокол SSH, но и протокол SSH1, достаточно воспользоваться следующей командой:

dan@OTHERSHOE ~

$ rsync -e “ssh -1” dhcp.figure.pdf [email protected]:/tmp

[email protected]’s password:

Программа rsync является необычайно эффективным методом предотвращения избыточного трафика. Она может оказаться особенно полезной для эффективного обновления динамически изменяющихся данных, которое можно регулярно наблюдать на Web-сайтах. Новейшая компонента rproxy Мартина Пула (Martin Pool) непревзойденного Sweetcode (www.Sweetcode.org) является интересной попыткой миграции протокола работы rsync непосредственно в протокол HTTP. Это хорошая идея, к тому же изящно и эффективно реализованная. Мартин приводит следующие данные: «Ранние реализации rproxy позволяют достигнуть сохранения пропускной способности для порталов Web-сайтов на уровне 90 %». Это немаловажно и определенным образом выравнивает дополнительную обработку загрузки новых данных. Хотя еще предстоит выяснить, насколько успешными окажутся эти усилия, но уже сейчас ясно, что rsync через программу httptunnel и протокол SSH работает вполне прилично. (Еще раз напомним читателю, что программа httptunnel доступна благодаря nocrew. Ее можно найти по адресу www.nocrew. org/software/httptunnel.html.) Остроумным решением является следующее. Запустите серверную часть программы httptunnel: