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

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

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

dan@OTHERSHOE ~

$ scp dhcp.figure.pdf dan@10.0.1.11:/tmp

dan@10.0.1.11”s password:

При копировании директории следует задать флажок -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 dan@10.0.1.11

dan@10.0.1.11’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

root@127.0.0.1:/tmp

root@127.0.0.1’s password:

В результате был получен доступ с правами суперпользователя к хосту с 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 dan@10.0.1.11

dan@10.0.1.11’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

root@127.0.0.1:/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.

Комментируя описанное, следует обратить внимание читателя на одно важное замечание. Очень важно управлять ключами идентификации (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).