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

# 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

[email protected] ~

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

[email protected] ~

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

dhcp.figure.pdf

[email protected]:/tmp

[email protected]’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? Давайте попробуем так сделать:

[email protected] ~

$ 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

$

[email protected] ~

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

Комментируя описанное, следует обратить внимание читателя на одно важное замечание. Очень важно управлять ключами идентификации (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 можно найти по адресу http://rsync.samba.org, что неудивительно, поскольку считается, что ее автор Андрей Тридгель (Andrew Tridgell) также принимал активное участие в подготовке и начале реализации проекта Samba, в рамках которого решалась задача совместного использования файлов Windows машинами UNIX.

[email protected] ~

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

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

[email protected] ~

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

Программа 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:

[[email protected] effugas]$ hts 10080 -F 127.0.0.1:22

Запустите клиентскую часть программы httptunnel:

[email protected] ~/.ssh $ htc -F 10022 -P 10.0.1.11:8888 10.0.1.10:10080

Покажем, какие файлы скопируются после попытки скопировать их с использованием опции -v:

[email protected] ~

$ rsync -v -r -e “ssh -o HostKeyAlias=10.0.1.10 -o

Port=10022” stuff/[email protected]:/tmp

[email protected]’s password:

building file list ... done

doxscan_0.4a.tar.gz

fping-2.4b2.tar.gz

Инструментарий и ловушки

Улучшение производительности SSH

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

• при использовании опции – C включается режим сжатия. За счет некоторых затрат процессорного времени и, вероятно, некоторой задержки SSH может воспользоваться программой zlib для сжатия данных. В результате скорость обработки многих видов трафика может быть значительно увеличена;

• применив опцию шифрования – с, можно поменять используемые симметричные криптографические алгоритмы. Алгоритм тройной DES обладает многими достоинствами, но его эффективность даже отдаленно не принадлежит к их числу. По умолчанию для SSH2-подключений будет использоваться алгоритм AES128-cbc – 128-битный алгоритм AES в режиме сцепленных блоков шифрования (cipher block chaining mode). Общепризнанно, что этому алгоритму можно доверять в той же степени, что и алгоритму тройного DES. Алгоритмы blowfish и особенно arcfour являются гораздо более быстрыми алгоритмами, причем их работа предусмотрена как в протоколе SSH1, так и в протоколе SSH2;

• используя опцию -1, можно получить снижение эффективности применения протокола SSH1. Честно говоря, использовать эту опцию не рекомендуется, но все же это лучше передачи открытого текста по каналу связи;

• очевидно, чем больше будет случаев взлома сетевых программ сетевого взаимодействия компьютеров, тем медленнее будет работать система. Зачастую полезно использовать SSH как метод решения известной проблемы «цыпленка и яйца», которая относится к явлениям, где трудно определить причину и следствие. Применительно к рассматриваемому случаю это означает отсутствие изменений до тех пор, пока отображается результат, но результат не может быть отображен до тех пор, пока не будут завершены изменения. В случае взлома во время использования SSH (назовем это доказательством идеи и ничем более) результирующая величина может быть показана и изменения санкционированы.