SSH: безопасная оболочка

Система SSH (Secure Shell) является безопасной заменой утилит rlogin, rcp и telnet. Она использует криптографическую аутентификацию для подтверждения личности пользователя и шифрует любые соединения между двумя компьютерами. Протокол, используемый системой SSH, разрабатывался для противодействия ряду воз­ можных атак. Он уже подробно описан в документах RFC4250-4256 и предложен орга­ низацией IETF в качестве стандарта.



Глава 22. Безопасность 973

Пакет SSH трансформировался из свободно распространяемой открытой системы (SSH1) в коммерческий продукт с немного иным (более надежным) протоколом (SSH2). К счастью, сообщество разработчиков открытых систем взяло ситуацию под контроль и выпустило пакет OpenSSH (поддерживаемый операционной системой OpenBSD), в ко­ тором реализованы оба протокола.

Основными компонентами пакета SSH являются серверный демон sshd и две ути­ литы пользовательского уровня: ssh предназначена для удаленной регистрации и scp — для копирования файлов. Среди остальных компонентов отметим команду ssh-keygen, генерирующую пары открытых ключей, и несколько утилит, необходимых для поддерж­ ки безопасных серверов X Windows.

Демон sshd способен аутентифицировать пользователей различными способами. Выбор остается за администратором.

• Метод А. Если имя удаленного компьютера, с которого регистрируется пользо­ ватель, указано в файле ~ / .rhosts, ~/.shosts, /etc/hosts.equiv или /etc/ shosts.equiv, то пользователь автоматически получает доступ в систему без про­ верки пароля. Подобная схема моделирует работу старого демона rlogind и, по нашему мнению, неприемлема для широкого применения.

• Метод Б. В дополнение к методу А, демон sshd может применять шифрование с открытым ключом для проверки адреса удаленного компьютера. Для того что­ бы это произошло, открытый ключ компьютера (генерируется при инсталляции пакета) должен находиться в файле /etc/ssh_known_hosts локального узла или в файле ~/.ssh/known_hosts пользователя. Если удаленный компьютер предо­ ставляет соответствующий секретный ключ (обычно хранится в файле /etc/ssh_ host_key, который недоступен для чтения рядовым пользователям), то пользова­ телю разрешается войти в систему без проверки пароля.

Мы полагаем, что данный метод сильнее, чем метод А, но все же недостаточно безопасен. Если удаленный компьютер взломан, локальная система также окажет­ ся под угрозой.

• Метод В. Демон sshd может применять шифрование с открытым ключом для идентификации самого пользователя. На этапе регистрации пользователь должен иметь доступ к файлу своего секретного ключа и предоставить пароль для его де­ шифровки. Ключ можно также создать без пароля, что является разумным реше­ нием для автоматической регистрации из удаленных систем.

•

Этот метод самый безопасный, но он утомляет пользователей. Кроме того, он де­ лает невозможной регистрацию в системе мобильных пользователей, если толь­ ко они не возят с собой копию файла с секретным ключом (возможно, на USB- ключе, который должен быть зашифрован).

Если вы решили использовать пару ключей, широко используйте команду ssh -v в процессе поиска ошибок.

Метод Г. Наконец, демон sshd может просто попросить пользователя ввести свой регистрационный пароль. Это напоминает утилиту telnet, за исключением того, что пароль и все данные, передаваемые в ходе сеанса, подвергаются шифрованию. Основной недостаток этого метода заключается в том, что пароли оказываются относительно слабыми (часто их длина ограничена 8 символами) и есть готовые программы (например, crack) для взлома таких паролей. Тем не менее этот метод, как правило, лучше всего подходит для повседневного использования.

974 Часть II. Работа в сети

Правила аутентификации задаются в файле /etc/sshd_config. Он уже заполнен разного рода конфигурационным, “мусором”, большую часть которого можно проигно­ рировать. Параметры, касающиеся аутентификации, перечислены в табл. 22.2.

Таблица 22.2. Параметры аутентификации, задаваемые в файле /etc/sshd_config

Параметр Метода По умол­ Назначение чанию

RhostsAuthentication A no Разрешает регистрацию через файлы ~/.shosts, /etc/shosts.equiv и т.п.

RhostsRSAAuthentication Б yes Разрешает регистрацию через файл ~/.shosts и другие, но также требует от компьютера предо­

ставить ключ

IgnoreRhosts А, Б no Задает игнорирование файлов ~/.rhosts и hosts.equivб

IgnoreRootRhosts А, Б noB

Запрещает аутентификацию пользователя root через файлы .rhosts и .shosts

RSAAuthentication В yes Разрешает аутентификацию пользователей по ме­ тоду шифрования с открытым ключом

PasswordAuthentication Г yes Разрешает использование обычных регистрацион­ ных паролей

а Методы аутентификации, к которым относится параметр.

6 Файлы ~/.shosts и shosts.equiv продолжают использоваться. в По умолчанию равен значению параметра ignoreRhosts.

Рекомендуемая нами конфигурация, в которой разрешаются методы В и Г, но не А и Б, такова.

RhostsAuthentication no

RhostsRSAAuthentication no

RSAAuthentication yes

PasswordAuthentication yes

Никогда не следует разрешать суперпользователю регистрироваться в удаленном ре­ жиме. Доступ суперпользователя должен осуществляться только с помощью команды sudo. Для того чтобы установить этот режим, используйте следующий параметр.

PermitRootLogin no

Когда вы впервые устанавливаете соединение с новой системой посредством прото­ кола SSH, вам предложат принять открытый ключ для доступа к удаленному узлу (ко­ торый обычно генерируется в процессе инсталляции системы OpenSSH или сразу по­ сле этого). Настоящий параноик может проверить его вручную, но большинство из нас слепо доверяют этому ключу и сохраняют его в файле ~/.ssh/known_hosts. Протокол SSH больше не вспоминает о серверном ключе, пока он не изменится. К сожалению, не­ брежность пользователей по отношению к ключам новых систем делает их уязвимыми для атак злоумышленников, если ключ на самом деле был предоставлен системой хакера.

Для устранения этого недостатка была изобретена запись DNS, получившая название SSHFP. В ее основе лежит предположение, что серверный ключ хранится в виде записи DNS. Когда клиент соединяется с неизвестной системой, протокол SSH ищет запись SSHFP, чтобы самостоятельно проверить ключ сервера, а не полагаться на пользователя.

Утилита sshfp, доступная на сайте xelerance.com/software/sshfp, генериру­ ет записи SSHFP DNS, либо сканируя удаленный сервер, либо выполняя анализ ранее

Глава 22. Безопасность

принятого ключа из файла known_hosts. (Разумеется, в любом случае предполагает­ ся, что источник ключа известен и заслуживает доверия.) Использование этой утили­ ты не представляет трудностей: для генерирования ключа на основе сканирования сети применяется флаг -s, а для анализа файла known_hosts — флаг -k (по умолчанию). Например, следующая команда генерирует BIND-совместимую запись SSHFP для до­ мена solaris.booklab.atrust.com.

solaris$ sshfp solaris.booklab.atrust.com

solaris.booklab.atrust.com IN SSHFP 1 1 94a26278ee713a37f6a78110flad9bd... solaris.booklab.atrust.com IN SSHFP 2 1 7cf72d02e3d3fa947712bc56fd0e0a3i...

Добавьте эти записи в зонный файл домена (будьте осторожны с именами и коман­ дой $ORIGIN), перезагрузите домен и примените команду dig для верификации ключа.

solaris$ dig solaris.booklab.atrust.com. IN SSHFP | grep SSHFP

; <<>> DiG 9.5.1-P2 <<>> solaris.booklab.atrust.com. IN SSHFP

; solaris.booklab.atrust.com. IN SSHFP

solaris.booklab.atrust.com. 38400 IN SSHFP 1 1 94a26278ee713a37f6a78110f... solaris.booklab.atrust.com. 38400 IN SSHFP 2 1 7cf72d02e3d3fa947712bc56f...

По умолчанию утилита ssh не проверяет записи SSHFP. Для того чтобы заставить ее сделать это, добавьте параметр VerifyHostKeyDNS в файл конфигурации /etc/ssh/ ssh_config. Как и в большинстве случаев, связанных с использованием параметров клиента SSH, при первом обращении к системе вы можете также указать в командной строке аргумент -о "VerifyHostKeyDNS yes".

Утилита SSH имеет много вспомогательных функций, полезных для системных ад­ министраторов. Одна из них позволяет безопасно туннелировать соединения TCP с по­ мощью зашифрованного канала SSH, тем самым разрешая устанавливать соединения с небезопасными или защищенными брандмауэрами службами на удаленных сайтах. Эта функциональная возможность повсеместно предоставляется клиентам протокола и допу­ скает простое конфигурирование. На рис. 22.1 показано типичное использование тунне­ ля SSH. Этот рисунок должен помочь разобраться в принципах его функционирования.

Рис. 22.1. Туннель SSH для RDP-соединения

В этом сценарии удаленный пользователь желает установить RDP-соединение (уда­ ленная настольная система) с системой Windows, входящей в корпоративную сеть. Доступ к этому узлу или порту 3389 блокируется брандмауэром, но поскольку пользо­ ватель имеет доступ по протоколу SSH, он может маршрутизировать свое соединение через сервер SSH.

976 Часть II. Работа в сети

Для того чтобы установить соединение через сервер SSH, пользователь должен заре­ гистрироваться на удаленном сервере SSH с помощью команды ssh. В командной строке ssh он должен указать произвольный, но конкретный локальный порт (в данном случае 9989), на который утилита ssh должна перенаправить безопасный туннель к порту 3389 удаленной Windows-машины. (В стандартной реализации системы OpenSSH для этого до­ статочно задать аргумент -L локальный_порт :удаленный_узел :удаленный_порт.) Все порты источника в данном примере помечены как случайные, потому что выбор произвольного порта, с которым необходимо установить соединение, производится программой.

Для доступа к настольной Windows-машине пользователь должен открыть удаленного настольного клиента (в данном случае rdesktop) и ввести localhost:9989 как адрес серве­ ра, с которым он хочет установить соединение. Локальная утилита ssh получит соедине­ ние с портом 9989 и туннелирует трафик по существующему соединению через удаленный сервер sshd. В свою очередь, сервер sshd направляет соединение на узел Windows.

Разумеется, туннели, подобные этим, также могут оказаться преднамеренными или непреднамеренными лазейками. Системные администраторы должны использовать тун­ нели с осторожностью и обязаны следить за неавторизованным и неправильным ис­ пользованием этой возможности пользователями.

В последние годы протокол SSH стал целью регулярных атак на пароли методом перебора. Хакеры выполняют повторяющиеся попытки аутентификации как обычные пользователи, такие как root, joe или admin. Свидетельством таких атак являются реги­ страционные записи о сотнях и тысячах неудачных попыток зарегистрироваться. Для защиты от этих атак лучше всего отключить аутентификацию паролей. Пока, похоже, хакеры сосредоточились на порте 22, поэтому эффективной контрмерой является пере­ нос сервера SSH на другой порт. Однако история показывает, что защита по принципу “безопасность через неясность” (“security through obscurity”) редко бывает долговремен­ ной. Проверка на ваших системах может выявить слабые пароли, которые могут быть взломаны с помощью прямого перебора.

Брандмауэры

Помимо защиты отдельных компьютеров, можно предпринять меры для обеспече­ ния безопасности на сетевом уровне. Основным инструментом сетевой защиты является брандмауэр, физическое устройство или часть программного обеспечения, не допускаю­ щие нежелательные пакеты в системы или сети. Брандмауэры в настоящее время ис­ пользуются всюду. Их можно обнаружить как в настольных компьютерах и серверах, так и в маршрутизаторах и корпоративном сетевом оборудовании.

Глава 22. Безопасность 979

Брандмауэры, фильтрующие пакеты

Брандмауэр, фильтрующий пакеты, ограничивает виды трафика, проходящего че­ рез интернет-шлюз (или через внутренний шлюз, разделяющий домены в пределах организации), основываясь на информации, извлеченной из заголовков пакетов. Это напоминает прохождение таможни, когда вы на своем автомобиле пересекаете грани­ цу Администратор указывает, какие целевые адреса, номера портов и типы протоколов являются допустимыми, а брандмауэр просто отбрасывает (в некоторых случаях также регистрирует) все пакеты, которые не соответствуют заданным критериям.

В системах семейства Linux фильтрация пакетов осуществляется с помощью утилиты iptables, в системах Solaris и HP-UX — с помощью программы IPFilter, а в системе AIX — с помощью команды genfilt. Подробно они будут рассмотрены чуть позже.

Несмотря на то что эти инструменты способны выполнять сложную фильтрацию и значительно повышают степень безопасности, в целом мы разочарованы использовани­ ем систем UNIX и Linux в качестве сетевых маршрутизаторов и особенно в качестве кор­ поративных маршрутизаторов, играющих роль брандмауэров. Сложность универсальных систем снижает их защищенность и надежность по сравнению со специальными устрой­ ствами. Для защиты корпоративных сетей лучше применять специальные брандмауэры, например устройства компании Check Point и Cisco.

Принципы фильтрации служб

Большинству “известных” служб назначается сетевой порт в файле /etc/services или его системно-зависимом эквиваленте. Демоны, которые реализуют соответствую­ щие службы, постоянно опрашивают порты, ожидая поступления запросов на подклю­ чение со стороны удаленных компьютеров7. В основном, такие порты являются “при­ вилегированными”. Это значит, что их номера находятся в диапазоне от 1 до 1023 и что порты могут использоваться только процессами, работающими от имени пользователя root. Порты с номерами 1024 и выше являются непривилегированными.

Фильтрация на уровне служб основана на предположении, что клиент (компью­ тер, инициирующий соединение по протоколу TCP или UDP) будет использовать не­ привилегированный порт для установления соединения с привилегированным портом сервера. Например, если компьютеру с адресом 192.108.21.200 нужно разрешить только входящие SMTP-соединения, то следует установить фильтр, который позволит посылать TCP-пакеты по этому адресу через порт 25 и отправлять TCP-пакеты с этого адреса че­ рез любой порт8. Способ инсталляции такого фильтра будет зависеть от типа используе­ мого маршрутизатора.

Некоторые службы, например FTP, еще больше усложняют эту головоломку. При пересылке файла по протоколу FTP на самом деле устанавливается два соединения: для команд и для данных. Клиент инициирует командное соединение, а сервер — информационное.9 Следовательно, если необходимо получать файлы из Интернета по протоколу FTP, следует разрешить вход в систему через все непривилегированные ТСР-

7 Во многих случаях задачу ожидания берут на себя демоны inetd или xinetd. Подробнее об этом рассказывается в разделе 32.1.

8 Порт 25 — это порт SMTP, определенный в файле /etc/services.

9 Это относится к традиционному протоколу FTP, известному как “активный протокол FTP”. Некоторые системы поддерживают “пассивный протокол FTP”, в котором оба соединения ини­ циируются клиентом.

980 Часть II. Работа в сети

порты, так как неизвестно, какой из них будет использован для установления информа­ ционного соединения.

Подробнее о конфигурировании FTP-сервера рассказывается в разделе 23.4.

Это сводит на нет преимущества фильтрации пакетов, поскольку некоторые общеиз­ вестные службы, печально известные своей незащищенностью, работают с непривиле­ гированными портами (например, служба X11 на порту 6000). Кроме того, любознатель­ ные пользователи получают возможность запускать собственные служебные программы (например, сервер telnet на нестандартном и непривилегированном порту), к которым они и их друзья могут обращаться из Интернета.

Самый безопасный способ использования фильтра пакетов — использовать протокол передачи данных SSH. В настоящее время в Интернете опубликован его черновик, но он уже широко используется и достиг достаточно высокой степени зрелости. Обычно он используется как компонент протокола SSH, обеспечивающего аутентификацию и шифрование. В отличие от протокола FTP, протокол SFTP использует только один порт и для команд, и для данных, разрешая парадокс фильтрации пакетов. Существует мно­ го реализаций протокола SFTP. Мы рекомендуем использовать клиентскую утилиту ко­ мандной строки SFTP, поставляемую в системе OpenSSH.

Наиболее разумный способ решения проблем с протоколом FTP — разрешить вы­ ход по протоколу FTP во внешний мир только с этого изолированного компьютера. Пользователи смогут регистрироваться на нем, когда им понадобится выполнять сете­ вые операции, запрещенные во внутренней сети. Поскольку копирование всех пользо­ вательских учетных записей на FTP-сервер противоречит сути административного деле­ ния в организации, можно создавать учетные записи только по заявкам. Естественно, на FTP-сервере должен быть инсталлирован полный комплект средств защиты.

В некоторых организациях, которые заботятся о безопасности, используется двух­ ступенчатая фильтрация. Один фильтр в этой схеме подключен к Интернету как шлюз, а второй находится между этим шлюзом и остальной частью локальной сети. Идея со­ стоит в том, чтобы оставить внешний шлюз относительно открытым, а внутренний — сделать очень консервативным. Если промежуточный компьютер административно от­ делен от остальной части сети, появляется возможность реализовать различные службы Интернета с меньшим риском. Частично защищенная сеть обычно называется “демили­ таризованной зоной” (DMZ).

Наиболее безопасным способом использования фильтрации пакетов является на­ стройка первоначальной конфигурации, которая не позволяет никаких входящих сое­ динений. Затем можно постепенно ослабить фильтрацию, выяснив полезные службы, которые не работают, и перенеся все службы, доступные в Интернете, в демилитаризованную

зону.

Брандмауэры, осуществляющие инспекцию пакетов с отслеживанием состояния соединений

В основе инспекции пакетов с отслеживанием состояния соединений лежит концеп­ ция, которую можно описать с помощью следующего примера. Представьте себе, что вы ищете террориста в переполненном аэропорту, внимательно прислушиваясь ко всем раз­ говорам, происходящим вокруг вас, и понимая их содержание (на всех языках). Брандмауэ­ ры, осуществляющие инспекцию пакетов с отслеживанием состояния соединений (stateful inspection firewalls), проверяют весь трафик, проходящий через них, и сравнивают его с те­ кущей сетевой активностью в ожидании события, которое “должно” произойти.

Глава 22. Безопасность 981

Например, если пакеты, обмениваемые в ходе выполнения последовательности ко­ манд протокола FTP, называют порт, который впоследствии должен использоваться для информационного соединения, то брандмауэр должен проверить, что информационное соединение произойдет именно на этом порту. Попытки удаленного сайта соединиться с другими портами заранее считаются фальшивыми и должны пресекаться.

Так что же на самом деле предлагают разработчики под видом инспекции пакетов с учетом состояния протокола. Их продукты либо осуществляют мониторинг ограни­ ченного количества соединений или протоколов, либо распознают конкретный набор “неблагоприятных” ситуаций. В этом нет ничего плохого. Очевидно, что из любой тех­ нологии, способной распознавать аномалии трафика, можно извлечь пользу. Однако в данном случае важно помнить, что все эти обещания преимущественно являются лишь рекламным ходом.

Насколько безопасны брандмауэры

Фильтрация пакетов не должна быть основным средством защиты от хакеров. Это всего лишь вспомогательная мера. При наличии брандмауэра порой создается ложное впечатление, будто уровень безопасности является исключительно высоким. Если, до­ верившись брандмауэру, ослабить бдительность на других “рубежах”, это отрицательно скажется на защищенности информации.

Каждый компьютер необходимо защищать индивидуально и регулярно проверять с помощью таких средств, как Bro, Snort, Nmap, Nessus и OSSEC. Следует также обучать пользователей правилам безопасной работы в системе. В противном случае вы просто создадите внешне устойчивую, но крайне запутанную внутри систему.

В идеале локальные пользователи должны иметь возможность подключаться к любой службе Интернета, но доступ к локальным службам со стороны интернет-узлов должен быть ограничен демилитаризованной зоной. Например, к серверу архивов может быть разрешен SFTP-доступ, а к почтовому серверу, получающему входящую почту, — доступ только по протоколу SMTP.

Для того чтобы интернет-канал работал с максимальной эффективностью, советуем все же обратить основное внимание на удобство работы и доступность. В конце концов, сеть становится безопасной благодаря бдительности системного администратора, а не благодаря брандмауэру.

22.12. Особенности брандмауэров в системе Linux

Обычно мы не рекомендуем использовать компьютер, работающий под управле­ нием Linux (а также UNIX или Windows), в качестве брандмауэра, поскольку в целом операционная система не обеспечивает надлежащий уровень безопасности.10 Однако лучше инсталлировать усиленную систему Linux, чем вообще ничего, если речь идет о домашнем компьютере или организации, бюджет которой не предусматривает покуп­ ку оборудования соответствующего уровня. В любом случае локальный фильтр, такой как команда iptables, может оказаться превосходным инструментом для обеспечения безопасности.

Устанавливая систему Linux в качестве брандмауэра, убедитесь, что она включа­ ет самые последние обновления и “заплаты”, касающиеся брешей в системе защиты.

10 И все же многие сетевые устройства, например маршрутизаторы компании Linksys, в своих ядрах используют систему Linux и iptables.

982 Часть II. Работа в сети

Компьютер, функционирующий в качестве брандмауэра, — идеальное место для практи­ ческой проверки всех рекомендаций, изложенных в этой главе. (В разделе 22.11 собраны сведения, касающиеся брандмауэров в целом. Читателям, не знакомым с концепцией брандмауэра, советуем предварительно прочитать приведенный там материал.)

Правила, цепочки и таблицы

В ядре Linux версии 2.4 появился новый механизм фильтрации пакетов — Netfilter. Контролирующая его работу команда iptables является “наследницей” более старой команды ipchains, которая использовалась в ядрах версии 2.2. В команде iptables применяется концепция упорядоченной цепочки правил, согласно которым проверяют­ ся сетевые пакеты. Наборы цепочек образуют таблицы, предназначенные для обработки определенных видов трафика.

К примеру, стандартная таблица для команды iptables называется filter. Цепочки правил этой таблицы используются для фильтрации сетевых пакетов. В таблице filter содержатся три стандартные цепочки: FORWARD, INPUT и OUTPUT. Каждый пакет, обра­ батываемый ядром, поступает на проверку в одну цепочку.

Правила в цепочке FORWARD применяются ко всем пакетам, которые поступают в один интерфейс и перенаправляются в другой. Правила в цепочках input и OUTPUT предназначены для пакетов, адресованных локальному компьютеру или исходящих от него соответственно. Обычно этих трех цепочек вполне достаточно для фильтрации данных между двумя интерфейсами. В случае необходимости можно определять более сложные конфигурации.

Помимо таблицы filter, существуют также таблицы nat и mangle. В первой со­ держатся цепочки правил, предназначенные для управления системой NAT (Network Address Translation — трансляция сетевых адресов). Подробнее об этой системе расска­ зывалось в разделе 14.4, а в разделе 14.12 приводился пример использования таблицы nat. В этом разделе мы воспользуемся цепочкой PREROUTING данной таблицы для филь­ трации пакетов с поддельными IP-адресами.

Таблица mangle содержит цепочки, предназначенные для модификации содержимо­ го сетевых пакетов вне контекста системы NAT или механизма фильтрации пакетов. Эта таблица редко применяется в крупных системах, поэтому мы не будем ее рассматривать.

Целевые директивы для правил

В каждом правиле цепочки имеется целевая директива, определяющая, что следует делать с пакетами, подчиняющимися этому правилу. Если пакет прошел проверку, его судьба предрешена и другие проверки не выполняются. В качестве директивы разреша­ ется указывать имя другой цепочки.

Правила таблицы filter могут содержать следующие целевые директивы: ACCEPT, drop, REJECT, LOG, MIRROR, QUEUE, REDIRECT, RETURN и ULOG. Директива ACCEPT разре­ шает пакету следовать своим маршрутом. Директивы DROP и REJECT запрещают пропу­ скать пакет, но первая приводит к “безмолвному” удалению пакета, а вторая — к выдаче ICMP-сообщения об ошибке. Директива LOG позволяет следить за тем, какие правила применяются к пакетам, а директива ULOG включает режим расширенной регистрации.

Директива REDIRECT перенаправляет пакеты прокси-серверу. Она удобна, когда весь трафик веб-узла должен проходить через кеширующую программу, такую как Squid. Ди­ ректива RETURN объявляет конец пользовательской цепочки. Директива MIRROR меняет

Глава 22. Безопасность 983

местами IP-адреса отправителя и получателя перед отправкой пакета. Наконец, дирек­ тива QUEUE передает пакеты локальным программам пользователя через модуль ядра.

Поиск по сайту: