Чем протокол ssh отличается от протокола telnet. Методы доступа

В книге подробно рассмотрены настройки сетевых сервисов, позволяющих создать сервер требуемой конфигурации и функциональности на основе ОС Linux. Вы сможете настроить сервер любого типа: от сервера локальной сети до Интернет-сервера и сервера удаленного доступа. Детальна описано администрирование Linux.

Изложение материала построено на основе дистрибутивов Red Hat и Mandrake. Много уникальной информации: запуск Windows-игр под Linux и создание Linux-сервера для игрового зала, настройка антивирусов Dr. Web и AVP под Linux, программа учета трафика MRTG, система защиты и обнаружения атак LIDS, а также многое другое. Особое внимание уделено безопасности Linux-серверов. Достаточно подробно описана сама ОС Linux и приведен справочник ее команд. Прочитав книгу, вы станете обладателями знаний по настройке и компилированию ядра, созданию собственных rpm-пакетов, командному интерпретатору bash, использованию массивов RAID. Вы узнаете внутренний мир Linux. Книга подойдет как для профессиональных, так и для начинающих администраторов, поскольку изложение материала начинается с установки ОС Linux, а в первой главе дано описание основных сетевых технологий и протоколов (Курс Молодого Администратора).

Все приведенные в книге листинги проверены на практике и размещены на прилагаемом CD. Помимо этого на нем содержится много справочной информации (HOWTO, RFC), a также статей, посвященных Linux. Размещен богатый набор вспомогательных утилит и программного обеспечения для сервера (Apache, MySQL, MRTG и др.).

Книга:

Разделы на этой странице:

Сервис Telnet обеспечивает базовую эмуляцию терминалов удаленных систем, поддерживающих протокол Telnet над протоколом TCP/IP. Обеспечивается эмуляция терминалов Digital Equipment Corporation VT 100, Digital Equipment Corporation VT 52, TTY. Протокол Telnet описан в документе RFC 854, который вы найдете на прилагаемом компакт-диске.

Любые команды, выполняемые с помощью Telnet, обрабатываются telnet-сервером, а не локальным компьютером. Пользователь лишь видит результат выполнения этих команд.

Для использования Telnet на удаленном компьютере должен быть установлен telnet-демон. На компьютере пользователя нужно установить программу-клиент. Практически в каждой операционной системе существует утилита telnet, которая является клиентом для протокола telnet (см. рис. 8.2).

Сервис Telnet был и остается одним из самых популярных способов удаленной регистрации и работы на удаленной машине. Основным его недостатком является то, что любая информация, в том числе и пароли, передается в открытом виде без какого-либо кодирования.

SSH (Secure Shell) - программа, позволяющая вам зарегистрироваться на удаленных компьютерах и установить зашифрованное соединение. Существует также «безопасная» версия telnet - stelnet.

SSH использует криптографию открытого ключа для шифрования соединения между двумя машинами, а также для опознавания пользователей.

Рис. 8.2.Telnet-клиент для Windows

Оболочку ssh можно использовать для безопасной регистрации на удаленном сервере или копировании данных между двумя машинами, в то же время предотвращая атаки путем присоединения посередине (session hijacking) и обманом сервера имен (DNS spotting).

Оболочка Secure Shell поддерживает следующие алгоритмы шифрования:

BlowFish - это 64-разрядная схема шифрования. Этот алгоритм часто используется для высокоскоростного шифрования данных больших объемов.

Тройной DES (Data Encryption Standard) - стандарт для шифрования данных. Данный алгоритм довольно старый, поэтому не рекомендуется его использовать. Обычно DES используется для шифрования несекретных данных.

IDEA (International Data Encryption Algorithm) - международный алгоритм шифрования информации. Этот алгоритм работает со 128-разрядным ключом и поэтому он более защищен, чем BlowFish и DES.

RSA (Rivest-Shamir-Adelman algorithm) - алгоритм Ривеста-Шамира-Адельмана. Представляет собой схему шифрования с открытым и секретным ключами.

При выборе алгоритма шифрования нужно исходить из конфиденциальности информации, которую вам нужно передать. Если информация секретна, лучше использовать алгоритмы IDEA или RSA. Если же вы просто не хотите передавать данные в открытом виде, используйте алгоритм BlowFish, поскольку он работает значительно быстрее, чем DES.

Оболочка ssh очень эффективна против анализаторов протоколов, так как она не только шифрует, но и сжимает трафик перед его передачей на удаленный компьютер. Программу ssh можно скачать по адресу http://www.cs.hut.fi/ssh/ . Версия ssh для UNIX распространяется бесплатно, а за Windows-версию (имеется в виду клиент для Windows) нужно заплатить.

Оболочка ssh незаменима в тех случаях, когда удаленно нужно администрировать сервер или когда сервер не имеет собственного монитора. При использовании telnet все данные, которые передаются через telnet-соединение, доступны в открытом виде. А значит, имена пользователей и пароли будут доступны всем, кто прослушивает трафик с помощью анализатора. Шифрование ssh выполняет, используя несколько различных алгоритмов, включая DES и 3DES.

Программа состоит из демона sshd, который запускается на Linux/UNIX-машине, и клиента ssh, который распространяется как для Linux, так и для Windows. Чтобы установить ssh, возьмите исходные тексты и поместите их по традиции в каталог /usr/src/. Затем распакуйте архив и установите программу, выполнив следующую последовательность действий:

cd /usr/src/
tar xzf ssh-2.4.0.tar.gz
cd ssh-2.4.0
./configure
make
make install

Чтобы ssh начал работать, необходимо запустить демон sshd на той машине, к которой предполагается подключение. Желательно добавить команду запуска в сценарий загрузки системы для автоматического запуска. Демон sshd работает по 22 порту (см. листинг 8.6). Если не ошибаюсь, ssh невозможно использовать вместе с xinetd/inetd - его нужно запускать подобно httpd– серверу в режиме standalone.

ssh 22/tcp # SSH Remote Login Protocol
ssh 22/udp # SSH Remote Login Protocol

Обычно с настройкой sshd не возникает никаких неприятных моментов. Подробно настройка демона будет рассмотрена чуть ниже в этой главе. Теперь попробуйте зарегистрироваться на этой машине через ssh. Для этого нужно установить этот же пакет на другую машину под управлением Linux/UNIX (или установить Windows-клиент ssh) и ввести команду:

$ ssh hostname.domain

ssh запросит вас ввести пароль пользователя. В качестве имени пользователя для установки соединения будет использовано имя текущего пользователя, то есть имя, под которым вы сейчас зарегистрированы в системе. В случае, если аутентификация пройдет успешно, начнется сеанс связи. Прекратить сеанс можно комбинацией клавиш Ctrl+D.

Если вам нужно указать другое имя пользователя, используйте параметр –l программы ssh:

ssh –l user hostname.ru

Так можно указать программе ssh, от имени какого пользователя нужно регистрироваться на удаленной машине (см. рис. 8.3).

При использовании Windows-клиента имя компьютера, имя пользователя и пароль нужно ввести в диалоговом окне программы. Если соединение не устанавливается, попробуйте выбрать метод кодирования blowfish. Если и это не поможет, выберите 3DES.

Работа в ssh аналогична работе в telnet. Вы можете администрировать удаленную машину также легко, как и локальную. Опции программы ssh указаны в табл. 8.5.

Рис.8.З. Регистрация на удаленной машине

Опции программы ssh Таблица 8.5

Оболочка ssh использует два файла конфигурации ssh_conf и sshd_conf. Думаю, что нет смысла говорить о том, что они находятся в директории /etc/ssh. Рекомендую в файле sshd_conf прописать следующую строчку:

allowedadress 10.1.1.1 10.1.2.1 10.1.3.1

Это означает, что доступ по ssh может быть выполнен только с машин с адресами 10.1.1.1, 10.1.2.1, 10.1.3.1. Это оградит ваш компьютер от нежелательных вторжений извне.

Программа stelnet во всем полностью аналогична программе telnet, но она выполняет шифрование трафика, который передается во время telnet-соединения.

Демон sshd - это программа-демон для оболочки ssh. Обычно sshd запускается на машине, к которой подключаются клиенты ssh. Последние версии демона sshd поддерживают две версии протокола ssh - ssh версия 1, и ssh версия 2.

У каждого узла есть свой RSA-ключ (обычно 1024 бит), который используется для идентификации узла. Этот ключ еще называется открытым. Дополнительно, при запуске демона, генерируется еще один RSA-ключ - ключ сервера (обычно 768 бит). Этот ключ создается заново каждый час и никогда не сохраняется на диске.

Каждый раз при установке соединения с клиентом демон отправляет ему в ответ свой открытый ключ и ключ сервера. Клиент сравнивает полученный открытый ключ со своей базой данных, чтобы проверить, не изменился ли он. Затем клиент случайным образом генерирует 256-разрядное число и кодирует его, используя одновременно два ключа - открытый ключ и ключ сервера. Обе стороны используют этот случайный номер как ключ сессии, который используется для кодирования всех передаваемых во время сессии данных.

Затем клиент пытается аутентифицировать себя, используя.rhosts-аутентифи-кацию, аутентификацию RSA или же аутентификацию с использованием пароля.

Обычно.rhosts-аутентификация небезопасна и поэтому она отключена.

Версия 2 работает аналогично: каждый узел имеет определенный DSA-ключ, который используется для идентификации узла. Однако, при запуске демона ключ сервера не генерируется. Безопасность соединения обеспечивается благодаря соглашению Диффи-Хелмана (Diffie-Hellman key agreement).

Сессия может кодироваться следующими методами: 128-разрядный AES, Blowfish, 3DES, CAST128, Arcfour, 192-разрядный AES или 256-разрядный AES.

Опции демона sshd указаны в табл. 8.6.

Опции демона sshd Таблица 8.6

Файл конфигурации демона /etc/ssh/sshd_config выглядит примерно так, как это показано в листинге 8.7

Листинг 8.7 Файл конфигурации /etc/ssh/sshd_config

# $OpenBSD: sshd_config,v 1.38 2001/04/15 21:41:29 deraadt Exp $
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
# This is the sshd server system-wide configuration file. See sshd(8)
# for more information.
Port 22
# Protocol 2,1
# ListenAddress 0.0.0.0
# ListenAddress::
HostKey /etc/ssh/ssh_host_key
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
ServerKeyBits 768
LoginGraceTime 600
KeyRegenerationInterval 3600
PermitRootLogin yes
#
# Don"t read ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# Uncomment if you don"t trust ~/.ssh/known_hosts for
RhostsRSAAuthentication
# IgnoreUserKnownHosts yes
StrictModes yes
X11Forwarding yes
X11DisplayOffset 10
PrintMotd yes
# PrintLastLog no
KeepAlive yes
# Logging
SyslogFacility AUTHPRIV
LogLevel INFO
# obsoletes QuietMode and FascistLogging
RhostsAuthentication no
#
# For this to work you will also need host keys in /etc/ssh/
ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
#
RSAAuthentication yes
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes
PermitEmptyPasswords no
# Uncomment to disable s/key passwords
# ChallengeResponseAuthentication no
# Uncomment to enable РАМ keyboard-interactive authentication
# Warning: enabling this may bypass the setting of "PasswordAuthentication"
# PAMAuthenticationViaKbdInt yes
# To change Kerberos options
# KerberosAuthentication no
# KerberosOrLocalPasswd yes
# AFSTokenPassing no
# KerberosTicketCleanup no
# Kerberos TGT Passing does only work with the AFS kaserver
# KerberosTgtPassing yes
# CheckMail yes
# UseLogin no
# MaxStartups 10:30:60
# Banner /etc/issue.net
# ReverseMappingCheck yes
Subsystem sftp/usr/libexec/openssh/sftp-server

Есть несколько способов получить доступ к среде CLI. Наиболее распространенные методы:

• Telnet или SSH

Консоль

К CLI можно получить доступ через консольный сеанс, также известный как строка CTY. Консоль использует низкоскоростное последовательное соединение, которое происходит через непосредственное подключение компьютера или терминала к консольному порту на маршрутизаторе или коммутаторе.

Консольный порт является портом управления, который обеспечивает внеполосный доступ к маршрутизатору. Консольный порт доступен, даже если никакие сетевые службы не были сконфигурированы на устройстве. Консольный порт часто используется, чтобы получить доступ к устройству, когда сетевые службы не были запущены или перестали работать.

Примеры использования консоли:

Начальная конфигурация сетевого устройства

Процедуры аварийного восстановления и поиск и устранение неисправностей, когда удаленный доступ не возможен

Процедуры восстановления пароля

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

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

Для многих устройств с IOS консольный доступ не требует никакой формы безопасности по умолчанию. Однако, консоль должна быть сконфигурирована с паролями, чтобы предотвратить несанкционированный доступ к устройству. Когда пароль теряется, существует специальный набор процедур для того, чтобы обойти пароль и получить доступ к устройству. Устройство должно быть расположено в заблокированной комнате или стойке для оборудования, чтобы предотвратить физический доступ.

Telnet и SSH

Telnet - метод для получения удаленного доступа к сеансу CLI маршрутизатора. В отличие от консольного соединения, сеансы Telnet требуют активных сетевых служб на устройстве. У сетевого устройства должен быть по крайней мере один активный интерфейс, сконфигурированный с адресом Уровня 3, таким как адрес IPv4. Устройства с Cisco IOS включают процесс сервера Telnet, который запускается при запуске устройства. IOS также содержит клиент Telnet.

Узел с клиентом Telnet может получить доступ к сеансам vty, работающим на устройстве Cisco. Из соображений безопасности IOS требует, чтобы сеанс Telnet использовал пароль в качестве минимальный метода аутентификации. Методы установки учетных записей и паролей будут обсуждаться в последующих статьях данной рубрики.

Протовол Безопасной Оболочки (SSH) является более безопасным методом для удаленного доступа к устройству. Этот протокол обеспечивает удаленный вход в систему, подобный Telnet, за исключением того, что он использует более безопасные сетевые службы.

SSH обеспечивает более сильную аутентификацию по паролю, чем Telnet, и использует шифрование, транспортируя данные сеанса. Сеанс SSH шифрует все передачи данных между клиентом и устройством IOS. Это защищает идентификатор пользователя, пароль и детали сеанса управления. Следуя передовой практике, всегда используйте SSH вместо Telnet, когда только это возможно.

Большинство более новых версий IOS содержат сервер SSH. В некоторых устройствах эта служба включена по умолчанию. Другие устройства требуют, чтобы сервер SSH был включен.

Устройства IOS также включают клиент SSH, который может использоваться, чтобы установить сеансы SSH с другими устройствами. Точно так же можно использовать удаленный компьютер с клиентом SSH, чтобы запустить безопасный сеанс CLI. Клиентское программное обеспечение SSH не поставляется по умолчанию на всех компьютерных операционных системах. Вы, возможно, должны будете получить, установить и сконфигурировать клиентское программное обеспечение SSH для Вашего компьютера.

AUX

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

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

Обычно, единственный случай, когда порт AUX используется локально вместо консольного порта - когда есть проблемы с использованием консольного порта, например, если некоторые параметры консоли неизвестны.

Введение

В предыдущем номере в статье о безопасности Интернет-серверов были затронуты вопросы, связанные с выбором платформы и операционной системы Интернет-сервера, безопасностью сервера в целом, было рассказано о работе с пользователями, а также о работе и настройках firewall. Кратко напомню, что мы рассматриваем администрирование небольшой офисной или домашней сети, когда у вас имеется один или два выделенных компьютера. В первом случае, когда один компьютер, - это firewall плюс почтовый сервер, Web-сервер, а может быть, и ftp-сервер. Проще говоря, выделенный компьютер используется как некий общий ресурс. Во втором случае, который подразумевает наличие большой сети, один компьютер используется как шлюз плюс firewall, а второй - как сервер почты, Web-сервер и т.д. В принципе, второй способ предпочтительнее, так как вы физически отделяете шлюз как объект первого возможного удара при нападении хакеров и от общего сервера сети. В любом случае, в дальнейшем можно абстрагироваться от количества выделенных компьютеров, помня при этом, что даже если их два, загружать их другими заданиями неразумно.

Все нижесказанное продолжает линию предыдущей статьи, при этом подразумевается, что в качестве сервера используется Linux-машина, а пользователь знаком с Linux и сетями на базовом уровне. Идеи приводимых примеров заимствованы из различных руководств по Linux. Итак, какие же вопросы мы рассмотрим на этот раз? Во-первых, серверные приложения, которые вы захотите установить на сервере. Во-вторых, сетевые атаки (в том числе и типы вирусов в Linux и троянские кони) и методы борьбы с ними. Почему эти вопросы объединены в одной статье? Дело в том, что обычно взлом происходит либо из-за небрежности администратора, либо из-за прорех в защите серверных приложений. Клиент, как следует из самого этого слова, не распоряжается ресурсами системы, поэтому очевидно, что именно серверы могут стать предметом атаки.

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

Всякий, кто знаком с UNIX понимает, что почти любая сетевая программа может быть использована и как клиент и как сервер. В первом случае вы услугами пользуетесь, во втором - предоставляете их. Ясно, что в сетевом сервисе необходимы обе части. Вопрос в том, какие серверные программы нужны на сервере вашей сети. Устанавливая Linux, вы можете конечно выбрать хоть все, так как установка на диск еще не подразумевает запуска. Но какие из них потом активировать? Есть простой рецепт, которого я сам всегда придерживаюсь в работе с серверами, - чем меньше активированных серверов, тем лучше (если говорить в более общем плане: чем сложнее вещь, тем проще ее сломать). Сколько бы не твердили о надежности UNIX, здесь регулярно обнаруживаются и заделываются дыры. Поэтому чем меньше программ вы запустите, тем меньше за ними нужно будет следить. В реальной жизни это, разумеется, не должно сводиться к тому, что вы запрещаете пользователям буквально все. Это, конечно, безопасно, но зачем тогда вообще администратор? Однако ненужные вещи, типа wais, уж точно ставить не следует.

Telnet и ssh

А теперь более конкретно рассмотрим, что реально нужно и внутренним и внешним пользователям. Нужны telnet и ssh (secure shell). Может, это и не очень удобный доступ, но он необходим, по крайней мере администраторам. Это программа, обеспечивающая доступ в терминальном режиме, когда у вас на компьютере появляется окно 80x25 символов, полностью отражающее вызываемый сервер. Вы можете выполнять любые команды и запускать программы, не использующие графику, - в общем, это обычный удаленный терминал. Отличие telnet от ssh следует из названий, но все же поясним: telnet передает информацию незащищенной, даже пароль передается по сети открытым текстом, а ssh шифрует всю передаваемую информацию. Если вы хотите быть более-менее уверены в защите, то запретите использование telnet или вообще не запускайте его. Ну а если вы все же хотите использовать его, то, конечно, нужно применять firewall. Стандартные команды могут быть такие:

для ipfwadm -

Ipfwadm -I -a accept -P tcp -S 10.0.0.0/8 -D 0.0.0.0/0 23 ipfwadm -I -a accept -P tcp -S some.trusted.host -D 0.0.0.0/0 23 ipfwadm -I -a deny -P tcp -S 0.0.0.0/0 -D 0.0.0.0/0 23

для ipchains -

ipchains -A input -p all -j ACCEPT -s 10.0.0.0/8 -d 0.0.0.0/0 23

Ipchains -A input -p all -j ACCEPT -s some.trusted.host -d 0.0.0.0/0 23 ipchains -A input -p all -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 23

Можно также использовать файлы /etc/hosts.allow и /etc/hosts.deny, для чего следует прописать, соответственно:

в первом файле -

In.telnetd: 10.0.0.0/255.0.0.0, some.trusted.host

во втором файле -

In.telnetd: ALL

Замечу, что даже если эти правила будут включены, то все равно любая программа, прослушивающая сеть где-нибудь на пути следования пакета с паролем, может его перехватить.

Еще два важных файла, информация которых связана с безопасностью системы, - /etc/securetty и /etc/shells. Первый задает терминалы, с которых может входить пользователь root. В большинстве систем по умолчанию пользователь root может входить только с консоли. Второй файл задает список допустимых программ-оболочек, которые могут запускаться при входе пользователя. Красивый пример, который я почерпнул из руководства по Linux, - использование passwd в качестве shell. Это обеспечивает пользователям легкую смену пароля, а также гарантирует, что они больше ничего не будут делать в терминальном режиме. Для этого в файл /etc/shells нужно занести саму программу passwd, то есть вписать строчку:

/usr/bin/passwd

а в файл /etc/passwd вписать про пользователя:

Username:x:1000:1000::/home/username:/usr/bin/passwd

Теперь, когда пользователь входит в сеть, он может только поменять пароль. Вывод на терминал имеет примерно следующий вид:

Trying 1.2.3.4… Connected to localhost. Escape character is "^]". Red Hat Linux release 5.2 (Apollo) Kernel 2.2.5 on an i586 login: tester Password: Changing password for tester (current) UNIX password: New UNIX password: Retype new UNIX password: passwd: all authentication tokens updated successfully Connection closed by foreign host.

Даже если попытка поменять пароль была неудачной, произойдет отключение от системы. Следует обратить внимание и на стартовый вывод при подключении: telnet честно пишет имя системы и версию. Вообще, это удобно, но в таком случае вы даете потенциальному хакеру информацию, которую он может использовать в своих целях. Как этого избежать? При входе пользователя telnet отображает файл /etc/issue.net, создаваемый при старте системы. Он создается командами, стоящими в файле rc.local:

# This will overwrite /etc/issue at every boot. So, make any changes you # want to make to /etc/issue here or you will lose them when you reboot. echo "" > /etc/issue echo "$R" >> /etc/issue echo "Kernel $(uname -r) on $a $(uname -m)" >> /etc/issue cp -f /etc/issue /etc/issue.net echo >> /etc/issue

Поэтому, если вы не перегружаете систему, можно просто отредактировать файл /etc/issue.net, иначе - отредактировать сам rc.local. В любом случае, использовать telnet рекомендуется только тогда, когда это действительно необходимо и он не может быть заменен ssh.

Программа ssh с точки зрения пользователя аналогична telnet. В отличие от telnet, использующего 23-й порт, она использует 22-й, но основное внутреннее отличие состоит в том, что весь трафик кодирован. Во всем же остальном они схожи. Для ssh можно использовать те же самые правила firewall (с заменой номера порта) и установки в файлах /etc/hosts.allow, /etc/hosts.deny. Приятной особенностью является наличие собственного конфигурационного файла /etc/sshd/sshd_config, содержащего следующие конфигурационные строки:

Port 22 # номер порта, который может быть не только 22 ListenAddress 0.0.0.0 # какие адреса обслуживает демон HostKey /etc/ssh/ssh_host_key # файл кодов клиентов RandomSeed /etc/ssh/ssh_random_seed # файл случайных чисел, используемых при генерации кодов ServerKeyBits 768 # длина кода в битах LoginGraceTime 300 # время ввода имени и пароля KeyRegenerationInterval 3600 # частота регенерации кодов PermitRootLogin no # может или нет пользователь root входить через ssh IgnoreRhosts yes # игнорировать или нет информацию из файла пользователя.rhosts StrictModes yes # строгий режим, блокирующий пользовательские огрехи, например ввод пароля 5 раз # или случайное нажатие enter QuietMode no # yes - чтобы не писать log-файл вообще и no - в противном случае X11Forwarding no # передавать информацию X-сервера по ssh-каналу FascistLogging no # степень полноты log-файлов PrintMotd yes # выдавать на экран некоторую фразу дня KeepAlive yes # поддерживать связь, обеспечивая стандартное разъединение SyslogFacility DAEMON # кто отвечает за создание log-файлов RhostsAuthentication no # допускать проверку пользователя через rhosts RhostsRSAAuthentication no # достаточна или нет проверка через rhosts или /etc/hosts.equiv # по умолчанию это установлено в yes RSAAuthentication yes # использовать только проверку RSA PasswordAuthentication yes # использовать пользователям свои обычные пароли или нет PermitEmptyPasswords no # допускать пользователей без пароля или нет

Также есть некоторые полезные установки, в частности:

AllowGroups, DenyGroups, AllowUsers, DenyUsers, AllowHosts, DenyHosts, IdleTimeout time (время, по истечении которого связь будет прервана в случае неактивности).

Как следует из вышесказанного, в целом у ssh такое количество настроек, что вы можете точно прописать, кто и как может входить в систему. Но это касается сервера, а пользователи сети должны запускать ssh-клиенты. В отличие от telnet, который есть в Windows, ssh в стандартной поставке отсутствует. В Linux этой проблемы нет - клиент там тоже есть. Важно отметить, что ssh-демон имеется и в первой и во второй версиях. Неприятно, конечно, что нет обратной совместимости, но я уверен, что вы как администратор будете снабжать пользователей теми клиентами, которые смогут общаться с сервером. Вот некоторые ssh-клиенты для Windows:

• Fresh Free FiSSH. http://www.massconfusion.com/ssh/
• Tera Term. http://hp.vector.co.jp/authors/VA002416/teraterm.html telnet-клиент. http://www.zip.com.au/~roca/ttssh.html - дополнительная dll для поддержки ssh
• Putty. http://www.chiark.greenend.org.uk/~sgtatham/putty.html - всего около 200K
• Mindterm http://www.mindbright.se/mindterm/ - Java ssh-клиент
• The Java Telnet Application. http://www.mud.de/se/jta/ - есть поддержка ssh
• Secure CRT. http://www.vandyke.com/ - коммерческий клиент

О терминальном доступе необходимо упомянуть и в связи с программами типа rlogin, rexec, rsh. Их использование лишено всякой защиты и иногда даже позволяет пользователям попадать с машины на машину без ввода пароля. Это хотя и удобно, однако с точки зрения безопасности - просто никуда не годится. Такие сервисы обычно запускаются по умолчанию. Чтобы отменить их, нужно отредактировать файл /etc/inetd.conf и перезапустить демон inetd. В целом telnet и ssh исчерпывают возможности терминального доступа к системе. Поэтому перейдем к другим серверным приложениям, полезным для пользователей.

Почта, или e-mail

Что нужно, чтобы у людей была почта, без которой общение людей зачастую уже и не мыслится? Довольно распространенный способ - поставить почтовый сервер, завести там ящик на каждого пользователя и настроить pop-демон, чтобы люди могли эту почту забирать. Но для того чтобы сервер мог принимать и отправлять письма, на нем необходимо установить почтовую программу типа sendmail, postfix или qmail, обрабатывающую почту на UNIX-машине. Традиционно с этой целью использовался sendmail. Сейчас он тоже применяется на большинстве машин, но две другие упомянутые программы являются его хорошими и даже усовершенствованными заменителями. Как обычно, основные проблемы связаны с защитой, однако последние версии sendmail (8.9.x) являются вполне устойчивыми.

Sendmail имеется во всех Linux, причем последние дистрибутивы наверняка содержат версию 8.9.x. Программа использует несколько файлов конфигурации, которые она анализирует в процессе работы. Но прежде чем говорить о конфигурации, отметим, что программу можно запустить и как демон, и в режиме ожидания. В первом случае она будет постоянно слушать порт, а во втором - активироваться один раз и просто обрабатывать всю приходящую информацию. Второй способ предпочтительнее с точки зрения безопасности. Для этого в строке запуска нужно просто убрать параметр -bd.

Теперь о конфигурации. Основным является файл sendmail.cf, который может иметь (а может и не иметь) ссылки на другие файлы. Также анализируется файл access, где можно поместить такие адреса, с которых (или на которые) письма отправляться не будут. Например, записи:

10.0.0 RELAY spam.com REJECT

означают, что письма с адресов.spam.com не будут приниматься, а письма из внутренней сети могут приниматься и отправляться.

Другой полезный и используемый файл - aliases. В нем задается, какие имена будут интерпретироваться как имя заданного ящика. Например, если задать

Petrov: star

письма, приходящие Петрову по адресу petrov@host, будут направляться в ящик star@host, даже если кто-то не знает реального адреса. Это целесообразно, в частности, если вы хотите, чтобы письма приходили менеджеру, который хочет иметь почтовый ящик не с именем manager, а со своим собственным. Это означает, что менеджер будет давать свой адрес только тем, кому посчитает нужным, а на Web-странице будет висеть manager. Очевидно, что максимум удобства это принесет в случае смены менеджера. На один и тот же ящик можно перенаправить сколько угодно имен.

В файле virtusertable задается отображение одного адреса на другой, к примеру:

Star@host manager

Используя эти два файла (aliases и virtusertable), можно осуществить дублирование почты, что позволит сохранять всю поступающую почту. Весь фокус в том, что вначале просматривается файл virtusertable, а затем aliases. Если с последней записью в virtusertable в файл aliases вписать:

Manager: star, «/var/spool/mail2/star»

то почта, приходящая и на адрес manager, и на адрес star, будет записываться в нормальную директорию /var/spool/mail и в /var/spool/mail2.

Одно из основных отличий программы postfix от sendmail - модульность (которая присуща и qmail). В отличие от sendmail только маленькая часть кода, всего один модуль, запускается как root, а все остальные части запускаются по мере необходимости и имеют свои настройки. Вообще, конфигурационные файлы postfix обычно лежат в /etc/postfix. Файл manager.cf управляет работой различных модулей, задавая пользователей, под которыми они запускаются, и количество процессов. Файл main.cf является основным файлом конфигурации и задает основные параметры работы самой почты. Вот его примерный вид с пояснениями (точнее, те компоненты, которые скорее всего придется отредактировать):

# имя машины myhostname = mail.example.org # домен mydomain = example.org # от имени какого адреса вы отправляете письма myorigin = $mydomain # на каких интерфейсах работать программе inet_interfaces = all # файл виртуальных имен virtual_maps = hash:/etc/postfix/virtual # файл замен имен alias_maps = hash:/etc/postfix/aliases # директория, в которую нужно складывать почту, когда ее получает пользователь home_mailbox = Maildir/ # где хранить почту mail_spool_directory = /var/spool/mail # команда изъятия почты mailbox_command = /usr/sbin/scanmails # файл с указанием адресов, почта с которых и на которые должна проходить # беспрепятственно relay_domains = /etc/postfix/relaydomains # локальные машины mynetworks = 10.0.0.0/24, 127.0.0.0/8 # что выводить, если пользователи подсоединяются к 25-му порту smtpd_banner = $myhostname ESMTP $mail_name

Программу postfix можно получить по адресу http://www.postfix.org .

Теперь поговорим о протоколах POP и IMAP. Первый работает на 110-м порту, второй - на 143-м. В принципе, оба преследуют одну и ту же цель, но реализованы они по-разному. POP (post office protocol) - довольно старый и бедный протокол. Все, что он позволяет, это соединяться с сервером, получать почту и удалять ее из ящика на сервере. Протокол IMAP более продвинутый. Он позволяет управлять почтой прямо на сервере. Можно не скачивать всю почту, а забирать только заголовки писем, создавать каталоги на сервере и распределять почту по ним. С точки же зрения безопасности эти протоколы одинаковы, поэтому во избежание неприятностей желательно использовать firewall. Можно также поместить трафик этих протоколов внутрь ssh. Очень важно проверять почту на вирусы. Хотя в UNIX вирусы не страшны, но поскольку многие пользователи используют Windows, то разумно прогнать письма через программу-сканер, например AMAVIS. Проще всего это сделать (естественно, подразумевается, что программа AMAVIS уже установлена), если в postfix в строке конфигурации

Mailbox_command = /usr/bin/procmail

Mailbox_command = /usr/sbin/scanmails

Коротко о том, как пользователь получает и отправляет почту на рабочем месте. К счастью, все популярные программы являются POP- или IMAP-клиентами (я имею в виду, по крайней мере, Netscape и Outlook). Плюс к этому, если администратор дал возможность доступа к серверу по telnet или ssh, вы можете просматривать почту и работать с ней в терминальном режиме (забрать ее в этом случае труднее). Для этого нужно соединиться с сервером и запустить в терминале какую-нибудь почтовую программу, типа mail или pine. Последняя гораздо более удобная и представляет собой полноэкранную программу с меню, только в текстовом режиме.

Доступ к файлам и сетевая печать

В UNIX-системе имеются два стандартных средства - NFS и LPD. Первое позволяет создавать сетевые файловые системы, второе - печатать на принтере. Что же касается использования ресурсов UNIX-машины из Windows, то для этого более всего, как мне кажется, подходит Samba (SMB). Эта программа позволяет получать доступ к файлам, а также предоставляет возможность сетевой печати с Windows-машины через UNIX-сервер. Поскольку эта статья в основном посвящена безопасности серверов, необходимо отметить, что разделение ресурсов внутри сети не является опасным, разумеется, при нормальной настройке внешних правил firewall. Здесь могут возникать проблемы иного плана, связанные с тем, что не все должны иметь доступ к той или иной информации, но это целиком регулируется настройками атрибутов файлов и каталогов. Каким бы проницательным администратором вы бы ни были, вы не сможете предотвратить ситуацию, когда, например, кто-то забудет закрыть сеанс работы с ssh и отойдет от компьютера. Другое дело, если вы дадите доступ на чтение каких-то файлов, но это слишком очевидные вещи, чтобы на них специально останавливаться. Поэтому теперь мы перейдем к рассмотрению серверных приложений, которые полезны не только внутренним пользователям, но и внешним. Я имею в виду в первую очередь Web-сервер и, быть может, ftp. Без первого сейчас трудно представить самую маленькую компанию или даже просто сеть, а наличие второго зависит от того, есть ли у вас реальная потребность отдельно выложить некоторые данные на ftp-сервер.

Web- и ftp-серверы

Среди ныне существующих нескольких Web-серверов по популярности и работоспособности бесспорным лидером является Apache. Этот сервер сочетает в себе скорость, стабильность, высокую защищенность, и при этом он бесплатный. Не всегда удается для своих целей найти такую программу, но здесь она есть. И нужно признать, что авторы программы прилагают очень много усилий, чтобы добиться максимальной эффективности и надежности. Прежде всего отметим, что если вы используете Web-сервер только для внутренних целей, таких как администрирование системы или разделение файлов, то его обязательно следует оградить от внешнего мира правилами firewall. Если же это сервер для всех, то необходимо понимать, что он открыт всем. Именно поэтому необходимо должным образом следить за ним, а именно: внимательно и правильно его настроить и контролировать log-файлы, чтобы определить возможную атаку заранее. Что же касается безопасности, то сам сервер имеет весьма малый доступ к системе, поскольку запускается как root только его первая копия, а остальные обычно запускаются от имени nobody. Кроме того, в настройках сервера, то есть в файлах httpd.conf, smr.conf, access.conf, четко указывается, к каким директориям сервер доступ имеет, а к каким нет. Если в файле httpd.conf прописать, например:

Options None AllowOverride None Options Indexes FollowSymLinks Includes AllowOverride None

то вы явно укажете, что сервер имеет доступ только к директории /WWW, куда и нужно поместить весь материал сайта (или сайтов), чью работу обеспечивает сервер. Если вы хотите быть уверенным, что никто не изменит прав доступа, включив, например, в какую-либо директорию файл.htaccess, то в srm.conf следует вписать:

order allow,deny deny from all

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

Следует отдельно остановиться на использовании протокола https (secure http). Этот протокол обычно работает на 443-м порту (в отличие от стандартного http, работающего на 80-м). Существует по крайней мере два способа обогатить Apache такой возможностью, как secure http. Первый - воспользоваться дополнением от open-ssl, второй - использовать модуль mod_ssl. Оба варианта приводят к почти одинаковым результатам. В общем и целом - появляется возможность устанавливать соединения, используя https по 443-м порту. При этом для сервера создается сертификат, который будет проверяться клиентами при подключении. Это позволит исключить (разумеется, не с абсолютной гарантией) прослушивание трафика. Для создания сертификата при использовании openssl нужно дать команды:

Openssl genrsa -des3 > httpsd.key openssl req -new -key httpsd.key > httpsd.csr

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

# прослушивание 443-го порта (по умолчанию сервер слушает только 80-й) Listen 443 # запрещение глобального использования ssl SSLDisable # место, куда сервер будет складывать временную информацию при ssl-соединении. Без # этой установки сервер не будет работать SSLCacheServerPath /usr/bin/gcache # порт, через который сервер общается с CashServer SSLCacheServerPort 12345 # время ожидания CashServer SSLSessionCacheTimeout 300

После этих настроек ваш сервер в принципе готов к работе с https, но пока этот протокол запрещен. Целесообразно создать виртуальный хост, имеющий такое же имя, что и ваш стандартный, но с явным указанием 443-го порта, другими словами, сейчас у вас запущен Web-сервер. Он работает на 80-м порту и использует протокол http. Добавив apache-ssl и описанные выше настройки, вы дали пользователям возможность общаться с вашим сервером через протокол https. Вряд ли вся информация вашего сервера настолько засекречена, что вы хотите всю ее выдавать только в режиме защищенного соединения. Сервер Apache позволяет создавать виртуальные машины, то есть вы можете объявить какую-то поддиректорию корневой для некоторого хоста, дать ему имя, прописать набор конфигурационных файлов и все остальное, что необходимо, но физически он будет находиться на вашем компьютере и управляться будет вашем же сервером. В нашем случае даже не нужно давать другое имя, так как оно то же самое, только другой порт. Вот как могла бы выглядеть такая настройка:

DocumentRoot /www/secure/ ServerName www.example.com ServerAdmin [email protected] ErrorLog logs/https_error.log TransferLog logs/https_access.log # Разрешение ssl для этого виртуального хоста SSLEnable # Требование использовать только ssl SSLRequireSSL SSLCertificateFile /usr/conf/httpsd.crt SSLCertificateKeyFile /usr/conf/httpsd.key SSLVerifyClient none

Помимо http существует и ftp - полезный и удобный сервис, особенно если у вас много файлов, которые пользователи должны скачивать (к примеру, вы предоставляете данные каких-то исследований). Преимущество ftp перед http - это скорость. Протокол ftp имеет минимум служебной информации. Однако с ним и много проблем. Основная - его «возраст»: ftp так же стар, как и telnet. Отсюда сразу возникают сложности, связанные с безопасностью: имя пользователя и пароль передаются в открытом виде, а трафик передаваемой информации ничем не защищен. К тому же ftp умеет только передавать файлы. Поэтому если вы имеете некоторую информацию, которая доступна всем, то разумно создать одного пользователя, под чьим именем будут входить все. Часто в таких ftp-архивах этого пользователя зовут anonymous, а в качестве пароля он передает свой e-mail-адрес. В этом случае проблем с безопасностью уже гораздо меньше. Тем более в случае, когда нужно предоставить ftp-доступ нескольким пользователям, сделать chroot, чтобы они могли класть файлы только в свои директории. Что касается серверов, то, конечно, они имеются в стандартных поставках, но, быть может, вы захотите поставить не стандартный ftpd, а какой-либо иной.

Одним из популярных ftp-серверов является proftpd. Его конфигурационные файлы похожи на файлы Apache, что позволяет легче к ним адаптироваться, поскольку скорее всего ваш Web-сервер именно Apache. Основной файл конфигурации - /etc/proftpd.conf. Его примерный вид может быть таким:

ServerName "ProFTPD Default Installation" ServerType inetd DefaultServer on Port 21 Umask 022 MaxInstances 30 User nobody Group nobody AllowOverwrite on

В вышеприведенном листинге указано, что сервер запускается через inetd, на стандартном 21-м порту, максимальное число копий 30, а запускается он от имени группы и пользователя nobody. 022 - маска атрибутов файла при создании, которая будет стандартно накладываться изначально. Такая конфигурация не дает доступа пользователю anonymous. Чтобы сделать это, необходимо написать примерно следующие конфигурационные настройки:

User ftp Group ftp RequireValidShell off UserAlias anonymous ftp MaxClients 10 DisplayLogin welcome.msg DisplayFirstChdir .message DenyAll

После такого добавления появляется возможность работать как anonymous, причем только читать, то есть скачивать, файлы. Приведу еще один пример настройки прав пользования директориями:

AllowAll DenyAll

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

На этом я закончу тему серверных приложений. Безусловно, следует отметить, что серверных приложений гораздо больше: существует еще DNS, серверы новостей, серверы NIS, X-сервер и множество других интересных и полезных приложений. Однако я постарался сделать упор на том, что реально может понадобиться при работе сети, которая не претендует на роль глобального киберполиса или провайдера. Теперь перейдем к рассмотрению второго вопроса, означенного в начале статьи, - к сетевым атакам и взломам.

Сетевые атаки и взломы

Прежде всего - несколько общих слов. В UNIX, в отличие от Windows, нет проблемы с вирусами. Внутренняя структура распределения памяти и прав доступа к файлам в состоянии сама справиться с тем, что обычно творят вирусы в старом DOS или Windows. Основным барьером для вирусов (в стандартном их понимании) является отсутствие доступа к физическим устройствам для программ, запущенных от имени обычного пользователя, а также то, что атрибуты файлов ставятся не вообще, а для пользователя, группы и всех пользователей. Такого в Windows нет (отчасти это реализовано в Windows 2000). Хотя неприятности, вызываемые традиционными вирусами, почти исключены, UNIX-системы все равно взламывают и рушат. Это связано с наличием совсем других технологий, которые можно условно разделить на две категории. Первая - это так называемые троянские кони, которые представляют собой программы, с виду, а может и на самом деле, выполняющие вполне разумные и легальные действия. Однако параллельно они ведут другую «работу»: прослушивают сеть или собирают информацию о паролях и посылают ее в сеть и т.п. Сами эти программы вряд ли могут принести непосредственный вред - скорее они будут посредниками между вашей системой и внешним взломщиком. Вторая категория - сетевые взломы. Эти акции изначально не апеллируют к внутреннему содержанию машины, а стараются разрушить систему или получить доступ к ней, посылая ей некоторую информацию, наподобие заведомо неправильных сетевых пакетов, либо путем специально сформированных запросов пытаются «выманить» какие-то скрытые данные. Зачем вообще нужно взламывать системы? Это вопрос скорее психологический, чем практический. Дело в том, что реально довольно большая часть взломов машин происходит не из корыстных целей, а просто из интереса к самому процессу. Среди людей, которых принято называть хакерами, не только те, кто совершает взломы для какой-то реальной выгоды, но и «энтузиасты», совершающие взлом сети ради самого взлома. Это кажется неожиданным, но это так, и об этом свидетельствует статистика. Кроме того, человека зачастую довольно сложно обвинить в содеянном, так как порой бывает невозможно доказать, что именно он и именно с этого компьютера производил те или иные незаконные действия. Однако в данной статье мы обсуждаем сами взломы, а не их психологические и юридические аспекты, и потому перейдем к конкретным вещам.

Взлом сети, как бы аккуратно он ни проводился и какие бы способы ни применялись, неизбежно приводит к некоторым изменениям в системе. Это может быть появление нового списка прослушиваемых портов, появление незнакомых программ, изменение размеров существующих программ, особенно типа ps или netstat, или даже новых пользователей. Так или иначе, суть в том, что что-то должно поменяться, и это неизбежно. Поэтому первое разумное действие, которое я советую осуществить сразу после установки и конфигурации системы, - это создание файла с информацией о системе. Что-то типа фотографии на тот момент, когда вы считаете все происходящее правильным. Если же говорить еще конкретнее, я имею в виду информацию, которую выдают программы netstat, vmstat, free, du, df. Второй совет - создавать резервные копии конфигурационных файлов системы и изначальных настроек. Их сравнение между собой тоже может дать некоторую информацию о том, что произошло в системе за последнее время.

Начнем с наблюдения за файловой системой, которое подразумевает не только слежение за использованием файловой системы (которое можно осуществить командами du и df), но и проверку на предмет неизменности тех или иных файлов (например, системных). Существует ряд программ, выполняющих эти функции:

• AIDE - программа, позволяющая создавать контрольные суммы для файлов, проверяя таким образом их целостность; позволяет использовать несколько алгоритмов. http://www.cs.tut.fi/~rammer/aide.html . (Остальные программы выполняют аналогичные функции, все они являются бесплатными.)
• Gog&Magog - создает список атрибутов и владельцев файлов, позволяет автоматически делать сравнение. http://www.multimania.com/cparisel/gog/
• Sentinel - создает контрольные суммы, используя алгоритм RIPEMD-160bit MAC, имеет графический интерфейс. http://zurk.netpedia.net/zfile.html
• SuSEauditdisk - программа, помещаемая на дискету, что дает возможность производить проверку системы полностью автономно, загружаясь непосредственно с дискеты. Стандартно поставляется с SuSELinux. http://www.suse.de/~marc
• ViperDB - проверяет владельцев файлов и атрибуты, создавая log-файлы, в которых записывает произошедшие изменения. У программы есть три параметра: -init - создает базы данных по файлам, -check - проверяет файлы по базе и вносит изменения в базу, если они произошли на диске, -checkstrict - проверяет файлы по базе и возвращает старые параметры, если произошли изменения. http://www.resentment.org/projects/viperdb
• Sxid - создает контрольные суммы файлов и проверяет атрибуты и владельцев. ftp://marcus.seva.net/pub/sxid/
• nannie - запоминает время создания файла. ftp://tools.tradeservices.com/pub/nannie/
• confcollect - запоминает системную информацию, например установленного программного обеспечения, таблицы маршрутизатора и т.п. http://www.skagelund.com/confcollect/
• Pikt - средство, содержащее внутренний язык скриптов для создания программ, выполняющих стандартные, но не реализованные в виде конкретных команд функции (наблюдение за почасовым использованием системы, ликвидация долгоживущих процессов, установка размера почтового ящика и т.д.). Существует для разных платформ: Solaris, Linux и FreeBSD. http://pikt.uchicago.edu/pikt/

Можно также рассказать о программах, выполняющих функции резервного копирования, но, по моему мнению, это не имеет непосредственного отношения к безопасности системы, к тому же различные стандартные средства входят в поставки UNIX. К безопасности имеет отношение только то, что резервные копии делать необходимо, но об этом уже было сказано выше.

А теперь выясним, что делать для предупреждения сетевых атак. Конечно, нужно на шлюз установить firewall. Так или иначе, но защита на уровне пакетов необходима. Если firewall каким-либо способом обойден, то необходимы следующие программы:

• DTK - эмулирует стандартные сервисы и программы, и в случае нестандартных запросов, направляемых этим программам, происходит выдача заведомо ложной информации с целью запутать взломщика. http://all.net/dtk/
• Psionic PortSentry - отслеживает сканирование портов. Основная задача - проверять порты на сканирование и отображать все в log-файле. http://www.psionic.com/abacus/portsentry/
• Psionic HostSentry - создает базу информации об использовании машины пользователями, выдавая сообщение при нестандартном использовании ресурсов. http://www.psionic.com/abacus/hostsentry/
• Scanlogd - сканирует сетевые пакеты, создавая log-файлы в зависимости от настроек. http://www.openwall.com/scanlogd/
• Firewalls - это собирательное название программ, выполняющих функции firewall.
• TCP-WRAPPERS - программы, ограничивающие доступ к тем или иным ресурсам по имени либо номеру компьютера. Некоторые такие программы доступны по адресу. ftp://ftp.porcupine.org/pub/security/
• NFR - программа, по построению аналогичная снифферу (sniffer - программа прослушивания сетевого трафика). Производит запись log-файлов и в режиме реального времени осуществляет детектирование атак и сканирования портов. http://www.nfr.com/
• Подробный и полезный FAQ по сетевым атакам и их детектированию находится по адресу http://www.robertgraham.com/pubs/network-intrusion-detection.html .

Трудно однозначно ответить на вопрос, что и как следует делать при сетевых атаках. Здесь очень многое зависит от специфики как конкретной сети, так и той организации, в которой она находится. Даже при атаке одного и того же вида в одном случае вы захотите вначале спасти данные, а во втором - заблокировать источник атаки, то есть все зависит от приоритетов. Весьма сложную проблему атаки представляют в тех организациях, где остановка работы сети недопустима. Там вам придется проводить все операции online, по возможности сохраняя связь с внешним миром. Довольно много зависит и от характера атаки. Одно дело взлом ради взлома, а другое - целенаправленное похищение секретных данных. Может быть, правда, и более изощренный вариант, когда атака проводится с целью отвлечения администратора от более изощренного и продуманного взлома, проводимого параллельно. Но не думайте, что атака может прийти только снаружи. Она вполне может начаться изнутри. Вполне возможный сценарий - запуск троянского коня на Windows-компьютере внутренней сети. Очевидно, что такое можно сделать, просто послав письмо по почте. Теперь давайте чуть подробнее остановимся на программах-снифферах (sniffer).

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

• Tcpdump - наиболее старая программа, поставляемая со всеми UNIX.
• Sniffit - имеет возможности фильтрации пакетов и перевода информации в текстовый формат; снабжена графическим интерфейсом. http://sniffit.rug.ac.be/~coder/sniffit/sniffit.html
• Ethereal - анализатор сетевых протоколов.
• Snort - предназначена для слежения за сетью, может определять сканирование портов. http://www.clark.net/~roesch/security.html
• SPY - сниффер, но не бесплатный. Существует бесплатная однопользовательская лицензия на сеть, состоящую не более чем из пяти машин. http://pweb.uunet.de/trillian.of/Spy/

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

• AntiSniff - программа, сканирующая сеть на наличие снифферов. Принцип ее действия очень прост: она посылает запрос и по ответу и по времени ответа определяет, обрабатывается он какой-нибудь еще программой или нет. http://www.l0pht.com/antisniff/

Подробный и полезный FAQ по снифферам можно найти по адресу. http://www.robertgraham.com/pubs/sniffing-faq.html .

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

Программы, которые сканирует систему саму по себе изнутри:

• Tiger - программа, до сих пор находящаяся в разработке. ftp://net.tamu.edu/pub/security/TAMU/
• check.pl - Perl скрипт, проверяющий дерево каталогов и файлы в нем и указывающий на различные сомнительные атрибуты и имена владельцев. http://opop.nols.com/proggie.html

Программы сетевого сканирования, указывающие на легкодоступные сервисы на другой системе (неплохая проверка настроек firewall, например):

• Strobe - старый, но быстрый и все еще эффективный сетевой сканер. Иногда включается в комплект поставки UNIX. ftp://suburbia.net/pub/
• Nmap - программа, использующая новые методы сканирования портов и имеющая много настроек. Позволяет получать параметры операционной системы (название, версию). http://www.insecure.org/nmap/index.html
• Portscanner - небольшой сканер портов, имеющий множество форматов выдачи обработанной информации. http://www.ameth.org/~veilleux/portscan.html
• Queso - не совсем сканер; это программа, предназначенная для определения типа операционной системы на удаленном компьютере. http://www.apostols.org/projectz/queso/

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

• Nessus - программа для отслеживания атак, основанная на принципе «клиент-сервер». Серверы есть для Linux, FreeBSD, NetBSD и Solaris, а клиенты для Linux и Windows. Помимо сканирования портов и отслеживания атак программа может производить поиск по DNS с целью нахождения компьютеров, связанных со взламываемой машиной. http://www.nessus.org/
• Saint - потомок программы Satan, которая прежде была одной из самых популярных для сбора информации о машинах. Saint использует архитектуру «клиент-сервер», заменяя, правда, клиента Web-программой. Основная цель - сбор информации об уязвимых местах в защите системы. http://www.wwdsi.com/saint/
• Cheops - программа, составляющая карту сетевого IP-окружения с указанием запущенной на компьютерах операционной системы. http://www.marko.net/cheops/
• SARA (Security Auditor’s Research Assistant) - программа, аналогичная Saint. Может сканировать одновременно несколько машин, кроме того выдает результат работы в HTML-формате. http://home.arc.com/sara/
• BASS (Bulk Auditing Security Scanner) - программа, идеология которой основана на том, что Интернет не защищен. Главная задача - сканирование систем на наличие в них «дыр» защиты. http://www.securityfocus.com/data/tools/network/bass-1.0.7.tar.gz

Программой сканирования firewall и проверки правильности его настройки, является Firewalk. С помощью посылки различных пакетов программа стремится вычислить правила, в соответствии с которыми работает firewall. http://www.packetfactory.net/firewalk/

В архиве по адресу http://www.rootshell.com/ собраны известные данные о погрешностях в защите систем и ссылки на дополнения от производителей операционных систем, которые эти погрешности устраняют. Правда, иногда вместо такой ссылки можно увидеть сообщение «Upgrade to the next version», что обидно, особенно если система коммерческая. Такое, например, часто бывает с IBM AIX.

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

КомпьютерПресс 3"2001

SSH допускает выбор различных алгоритмов шифрования. SSH-клиенты и SSH-серверы доступны для большинства сетевых операционных систем.

1. Протоколы удаленного доступа: telnet и ssh

Операционная система UNIX первоначально разрабатывалась как Интернет-сервер. Средства для работы с Сетью встроены непосредственно в ядро этой операционной системы, а все необходимое программное обеспечение для организации сервера входит в состав дистрибутива. UNIX-система работает со всеми сетевыми протоколами (особенно с TCP/IP) лучше, чем любая другая операционная система для платформы Intel. Недаром говорят, что UNIX создан для сети, как птица для полета. Все перечисленные выше качества касаются также и ОС Linux. Существует множество направлений, где используются Linux-серверы: WWW-серверы, FTP-серверы, почтовики, шлюзы. Поэтому удаленное управление Linux-сервером имеет большое значение.

Для удаленного доступа к Linux используются два протокола telnet и SSH. Telnet - протокол линии передачи данных Интернет, который дает возможность

компьютеру функционировать как терминал, работающий под управлением удаленного компьютера. Протокол telnet был первоначально разработан для ARPAnet и является важной частью протокола передачи данных TCP/IP.

Имеются три главных проблемы связанные с использованием telnet, делая его плохим выбором для современных систем с точки зрения безопасности:

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

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

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

Нежелательно использование протокола telnet в системах, для которых важна безопасность, таких как общественный Интернет. Сеансы telnet не поддерживают шифрование данных. Это означает это любой, кто имеет доступ к любому маршрутизатору, коммутатору или шлюзу в сети между двумя удаленными компьютерами, соединенными

сеансом связи по протоколу telnet, может перехватить проходящие пакеты и легко получить логин и пароль для доступа в систему (или завладеть любой другой информацией, которой обмениваются эти компьютеры) при помощи любой общедоступной утилиты подобно tcpdump и Ethereal.

SSH - (Secure Shell) - сетевой протокол, позволяющий производить удалённое управление компьютером и передачу файлов. Сходен по функциональности с протоколом telnet , однако использует алгоритмы шифрования передаваемой информации.

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

Поскольку использование для удаленного управления протокола telnet неправильно с точки зрения безопасности, в лабораторной работе рассмотрим только удаленное управление по SSH.

На данный момент существует две версии протокола SSH: Описание технологии протокола SSH-1:

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

Аутентификация сервера происходит исходя из его возможности расшифровки сессионного ключа, который зашифрован публичным ключом сервера. Аутентификация клиента может происходить различными способами, в том числе DSA, RSA, OpenPGP или

по паролю. Сессия продолжается до тех пор, пока и клиент и сервер способны аутентифицировать друг друга. Установленное соединение по протоколу SSH-1 позволяет защитить передаваемые данные стойким алгоритмом шифрования, проверкой целостности данных и сжатием.

Описание технологии протокола SSH-2:

Оба протокола, по сути, выполняют одни и те же функции, но протокол SSH-2 делает это более элегантно, более безопасно и более гибко. Основное различие между протоколами заключается в том, что протокол SSH-2 разделяет все функции протокола SSH между тремя протоколами, в то время как протокол SSH-1 представляет собой один единый и неделимый протокол. Модуляцией функций протокола SSH в трех протоколах – протоколе транспортного уровня, протоколе аутентификации и протоколе соединения, делает протокол SSH-2 наиболее гибким и мощным механизмом создание безопасных туннелей. Ниже дано краткое описание и назначение каждого из трех протоколов, составляющих протокол SSH-2:

Протокол транспортного уровня – предоставляет возможность шифрования и сжатия передаваемых данных, а также реализует систему контроля целостностью данных.

Протокол соединения – позволяет клиентам устанавливать многопоточное соединение через оригинальный SSH туннель, таким образом, снижая нагрузку, которую создают клиентские процессы.

Протокол аутентификации – протокол аутентификации отделен от протокола транспортного уровня, т.к. не всегда бывает необходимым использование системы аутентификации. В случае если нужна аутентификация, процесс защищается оригинальным безопасным каналом, установленным через протокол транспортного уровня.

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

Сервером SSH служит демон sshd, который запускается на UNIX-машине.

В качестве SSH-клиента в настоящее время используют OpenSSH, PuTTY, SecureCRT, SFTPPlus, TeraTerm и др. В лабораторном практикуме будут использованы наиболее распространенные OpenSSH – для подключение Linux-клиента и PuTTY – для подключения Windows-клиента.

OpenSSH (Open Secure Shell - открытый безопасный shell) - набор программ,

предоставляющих шифрование сеансов связи по компьютерным сетям с использованием протокола SSH. Он был создан под руководством Тео де Раадта как открытая альтернатива коммерческого ПО от SSH Communications Security.

PuTTY (от TTY - телетайп, англ. putty - замазка) - свободно распространяемый клиент для протоколов SSH. Изначально разрабатывался для Windows, однако позднее портирован на Unix.