Михаил Фленов СанктПетербург бхвпетербург 2010 удк 681 06 ббк 32. 973. 26018. 2 Ф69
 Скачать 3.69 Mb.
|
. 5.4. Шифрование канала Получается , что шифрование не изменяет протокол, он остается тем же са- мым TCP/IP, просто на сторонах клиента и сервера появляются посредники, которые кодируют и декодируют данные. Использование такого метода очень удобно тем, что можно шифровать трафик любого протокола. Если в криптографическом алгоритме будет найдена ошибка, или в него будут внесены изменения для более качественного шифрования (например, с ис- пользованием более длинного ключа), то не надо вносить изменения в прото- кол . Достаточно обновить программу шифрования, и все новые возможности станут доступными. Рассмотрим пример с WEB-сервисом, который работает на порту 80. На сер- вере можно запустить программу шифрования, например на порту 1080, и все данные , которые будут приходить на него, будут декодироваться и переда- ваться на порт 80. Если вы хотите предоставлять доступ к WEB только по протоколу SSL, то к порту 80 можно закрыть доступ извне при помощи сете- Глава 5 192 вого экрана (о работе сетевого экрана мы подробно говорили в главе 4), а разрешить только подключения с сервера шифрования. Адреса сайтов, которые защищены специальными ключами, начинаются с https://. Буква s как раз и говорит о том, что соединение безопасно. Помимо этого , при подключении через обозреватель с включенным SSL в правом нижнем углу окна в строке состояния появляется значок. Например , в популярном среди пользователей Windows браузере Internet Explorer это пиктограмма висячего замка, а в некоторых версиях браузера FireFox строка адреса окрашивается в какой-то из оттенков желтого (рис. 5.5). Я не дальтоник, просто не знаю, как назвать эту неожиданность. Рис . 5.5. Безопасное соединение в Firefox Но этот опознавательный значок в Internet Explorer появляется не всегда. Более точно определить тип используемого соединения можно по свойствам документа . Большинство браузеров имеют команду просмотра свойств загруженной страницы, вызвав которую можно увидеть и используемое Администрирование 193 шифрование . Например, в Internet Explorer необходимо выбрать меню File | Properties (Файл | Свойства). Перед вами откроется окно, как на рис. 5.6. Об- ратите внимание на поле Connection. Информация в нем свидетельствует, что используется протокол SSL 3.0 RC4 со 128-битной схемой шифрования. Рис . 5.6. Свойства документа в Internet Explorer 5.2.1. stunnel В ОС Linux для шифрования и дешифрования трафика чаще всего использу- ется программа stunnel. Однако она лишь организует канал и выступает по- средником , а для самого кодирования используется пакет OpenSSL, доступ- ный в большинстве дистрибутивов Linux. Вероятно, он у вас уже установлен, а если нет, то его легко установить с помощью соответствующего RPM-пакета с инсталляционного диска. Более подробную информацию по OpenSSL и по- следние обновления можно найти на сайте www.openssl.org. В основу OpenSSL положено применение пары ключей: открытого и закры- того . С помощью открытого ключа можно только закодировать данные, и он Глава 5 194 посылается клиентом на сервер по открытому каналу (отсюда и его назва- ние ). Сервер использует его для кодирования, но для расшифровки необхо- дим закрытый ключ, который известен только клиенту. У программ OpenSSL и stunnel очень много параметров, и рассматривать их все бессмысленно, потому что запомнить все проблематично, да и обычно не нужно . Лучше разберем реальный пример и познакомимся с наиболее часто используемыми аргументами. Итак , давайте для начала запустим на сервере программу stunnel, которая бу- дет расшифровывать входящий трафик и передавать его на какой-нибудь порт , например 25 (здесь работает SMTP-сервер sendmail). Для этого выпол- ните следующую команду: stunnel –p /usr/share/ssl/cert.pem –d 9002 –r 25 В данном случае используется три параметра: -p — ключ, после которого указывается SSL-сертификат авторизации, ко- торый по умолчанию уже создан во время установки ОС или программы stunnel и находится в файле /usr/share/ssl/cert.pem; -d — показывает, что туннель должен работать как домен. После этого ключа ставится IP-адрес (необязательный параметр) и порт, на котором нужно ожидать подключения. Если адрес не указан, как в нашем примере, то прослушиваться будут все интерфейсы локального компьютера. В ка- честве порта был выбран номер 9002. Все пришедшие на него данные счи- таются зашифрованными, и они будут декодироваться для передачи на другой порт локального компьютера; -r — после этого ключа указывается имя компьютера (необязательный параметр ) и порт, куда нужно передавать расшифрованные данные. Если хост не указан, то данные будут пересылаться на порт локального компь- ютера , в данном случае на порт 25, где должен работать SMTP-сервер. Ес- ли данные предназначены другому компьютеру, то в качестве параметра укажите 192.169.77.1:25 , где 192.169.77.1 — это IP-адрес компьютера. Однако помните, что при этом незашифрованные данные будут пересы- латься по сети, чего мы как раз пытались избежать. Теперь рассмотрим запуск клиента. Тут все намного проще: stunnel –с -d 1000 –r 192.168.77.1:9002 Здесь у нас появился один новый ключ: -c — означает, что туннель создается для клиента. По умолчанию про- грамма stunnel запускается в серверном режиме. Помимо этого, в нашем примере присутствуют уже известные параметры: –d с указанием порта, на котором необходимо ждать подключения (значе- Администрирование 195 ние 1000), и –r , в котором указывается адрес и порт для передачи зашифро- ванных данных. Теперь достаточно настроить свою клиентскую программу так, чтобы при отправке почты она направлялась на порт (в данном случае 1000) компьюте- ра , где запущен stunnel-клиент, который будет шифровать данные и пересы- лать их на порт 9002 сервера с адресом 192.168.77.1. Там закодированные данные будет принимать stunnel-сервер, расшифровывать и передавать их на 25 порт сервера. Если на вашей системе включен сетевой экран и запрещены подключения по указанным портам, то соединения будут отклонены сетевым экраном. 5.2.2. Дополнительные возможности OpenSSL При запуске программы stunnel на сервере мы задали использование серти- фиката авторизации, но не сказали, как проверять его подлинность. Для ука- зания уровня используется ключ -v , после которого идет число: 0 — нет никакой проверки; 1 — если сертификат присутствует, то он проверяется на подлинность. Если получен отрицательный результат, то соединение разрывается. Наличие сертификата не является обязательным, соединение может быть установлено и без него; 2 — сертификат является обязательным. Если сертификата нет, или он не является подлинным, соединение не может быть установлено; 3 — наличие сертификата обязательно, и помимо этого он должен присут- ствовать в локальном хранилище (специальный список). В этом случае нужно указать директорию, в которой находятся сертификаты, с помощью опции –a Сервер SSL может расшифровывать трафик и передавать его на порт прини- мающей программы не только локального, но и другого компьютера. Таким образом , сервер SSL и сервер-получатель трафика могут быть на разных компьютерах . Неплохо, чтобы сервер после расшифровки данных прятал IP- адрес клиента, с которого были отправлены данные, и это возможно, если указать опцию –T Во время установки пакета OpenSSL на вашем диске создаются сертификаты и пары ключей, которые используются для шифрования. Все это находится в директории /usr/share/ssl/. С помощью опции –n можно непосредственно указать протокол, с которым будет происходить работа. В настоящий момент поддерживаются POP3 (Post Глава 5 196 Office Protocol, протокол обработки входящих сообщений), SMTP (Simple Mail Transfer Protocol, простой протокол электронной почты)) или NNTP (Network News Transfer Protocol, сетевой протокол передачи новостей). Для большинства основных протоколов существуют номера портов, уже ставшие стандартом. Есть даже названия защищенных вариантов протоколов, которые , как правило, получаются за счет добавления к наименованию ос- новного буквы s, которая и указывает на безопасное соединение через SSL. Эта информация приведена в табл. 5.1. Таблица 5.1. Список протоколов с номерами портов Протокол Порт TCP при обычном соединении Название SSL- варианта протокола Порт TCP при SSL- соединении HTTP 80 HTTPS 443 SMTP 25 SMTPS 465 LDAP 329 LDAPS 636 TELNET 23 TELNETS 992 SHELL 514 SSH 22 FTP 21 FTPS 990 FTP-DATA 20 FTPS-DATA 989 IMAP 143 IMAPS 993 POP3 110 POP3S 995 IRC 194 IRCS 994 Обратите внимание, что для протокола FTP требуется два защищенных кана- ла . Один используется для управляющего соединения, а второй — для пере- дачи данных. К этому мы еще вернемся в главе 10, когда будем рассматри- вать этот протокол. 5.2.3. Шифрование файлов Некоторые серверы могут использоваться для хранения архивных данных, которые , несмотря на такой статус, должны быть скрыты от постороннего взгляда . Наилучший вариант защиты — шифровать файлы, чтобы никто не смог увидеть их содержимое, и пакет OpenSSL предоставляет нам такую возможность Шифрование необходимо не только для резервных копий файлов или архив- ных данных, но и для файлов с секретной информацией, которые необходимо Администрирование 197 передать по незащищенным каналам связи, например, через электронную почту или публичный FTP-сервер. Для шифрования необходимо выполнить команду /usr/bin/openssl , которая имеет следующий вид: /usr/bin/openssl алгоритм –in файл1 –out файл2 Количество используемых алгоритмов исчисляется десятками. Наиболее рас- пространенным является DES (Data Encryption Standard, Стандарт шифрова- ния данных). Я тоже отдаю предпочтение именно ему. О поддерживаемых алгоритмах можно узнать на сайте разработчиков или по команде man openssl Параметр –in задает входной файл, который необходимо шифровать, а после ключа –out указывается имя файла, куда сохраняется результат. При дешифровании необходимо добавить ключ –d . Помимо этого, в качестве –in задается закодированный файл, а в параметре –out — имя файла для со- хранения результата: /usr/bin/openssl алгоритм –d –in файл2 –out файл1 В качестве примера зашифруем список паролей /etc/passwd в файл /home/passwd по алгоритму DES. Для этого выполняем команду: /usr/bin/openssl des –in /etc/passwd –out /home/passwd В ответ на эту директиву программа попросит вас указать пароль и затем по- вторить ввод, дабы исключить возможные ошибки. Выполните команду cat /home/passwd и убедитесь в том, что содержимое этого файла нечитаемо. Для расшифровки файла выполните команду: /usr/bin/openssl des –d –in /home/passwd –out /etc/passwd Таким нехитрым способом мы можем безопасно хранить копию файла с па- ролями . К теме резервного копирования мы вернемся в главе 13, которая бу- дет полностью посвящена этому вопросу. 5.2.4. Туннель глазами хакера Хакеры могут использовать туннели для своих целей. Например, несколько лет назад я был подключен к Интернету по технологии ADSL (Asymmetric, Asymmetric Digital Subscriber, асимметричная цифровая абонентская линия). Это сейчас легко найти тарифы с безлимитным трафиком, а в начале 2000-х с этим были проблемы. В абонентскую плату входило всего 400 Мбайт тра- фика . Ну что такое 400 Мбайт? Для меня это неделя работы в экономном ре- жиме , потому что общаться приходится много, а из почтового ящика я иногда Глава 5 198 выкачиваю до 20 Мбайт в день. А превышение лимита обходилось доста- точно дорого. Как можно обойти ограничение и получить бесплатный трафик? Подобно большинству провайдеров, мой предоставлял абсолютно бесплатный трафик со своих серверов, к которым можно обращаться сколько угодно. Жаль, что на этих серверах ничего полезного нет, но это легко исправить. В мою абонентскую плату входит 10 Мбайт серверного пространства для создания визитной карточки в Интернете. Максимум, что можно там размес- тить , — домашнюю страничку. Но мне это не нужно. Главное, что трафик с этого сайта неограничен. И если установить на сервер программу туннели- рования , то можно организовать соединение, как показано на рис. 5.7. Hacker Server Proxy stunnel Рис . 5.7. Подключение к Интернету через WEB- сервер Хакер подключается через программу stunnel к бесплатному WEB-серверу, который находится на площадке провайдера. Оттуда весь трафик перена- правляется на какой-нибудь прокси-сервер в Интернете или напрямую пере- дается WEB-сайтам. За это также вносить деньги не надо, потому что связь с WEB-сервером в обе стороны бесплатна. Администрирование 199 Таким образом, можно скачивать не 400 Мбайт трафика, а целые гигабайты, и все на халяву. Если вы решили использовать этот метод, то не забудьте, что на WEB-сервер необходимо повесить хоть какую-то страничку. Иначе адми- нистратор моментально заметит, что большой трафик идет на пустую WEB- страницу , и сможет вычислить туннель. Еще один способ нестандартного использования туннелирования — расши- рение возможностей сетевого доступа. Например, в некоторых локальных сетях может быть запрещен какой-либо протокол доступа в Интернет. Мне довелось работать в организации, где было разрешено только обращение к WEB-сайтам по протоколу HTTP. Все остальное было запрещено. Руково- дство мотивировало это тем, что пользователи не должны иметь возможность передачи файлов в Интернет. Как можно обойти такое ограничение? Снова ставим туннель на WEB- сервере , и можно использовать любой другой протокол, пряча весь трафик в HTTP, откуда туннель уже направляет данные на нужные порты с нужным протоколом Например , нам нужен доступ к FTP. На каком-нибудь сервере в Интернете на 80 порту (доступ к которому разрешен, потому что это стандартный порт для WEB-сервера) ставим сервер туннеля и настраиваем его на подключение к нужному FTP-серверу. А на своем компьютере устанавливаем клиент. С помощью клиента соединяемся с 80 портом своего сервера и можем пере- давать данные, которые будут перенаправляться на нужный FTP-сервер. Такие туннели уже не нуждаются в шифровании и могут быть реализованы с помощью несложных программ, например, сценариев на языке Perl. Для передачи пакетов не обязательно использовать HTTP. Подойдет практически любой протокол на основе TCP. Можно даже запрятать нужный протокол в DNS- или ICMP-пакеты, если они разрешены в вашей сети. Если ICMP за- блокировать можно, то с DNS это практически нереально, так как при под- ключении к сети Интернет без службы DNS работать сложно. Как видите, абсолютно безопасная на первый взгляд и даже предназначенная для защиты технология превращается в средство взлома ограничений, кото- рыми "наградил" вас администратор. Если вы обладаете хорошими знаниями программирования на PHP или Perl, то можете написать WEB-сценарии, которые на сервере будут обращаться к необходимым вам ресурсам, чтобы работать с необходимым сервером через WEB-браузер. Получится что-то похожее на работу с почтой через WEB. Эта возможность есть на большинстве почтовых сервисов, и вам она должна быть знакома на практике. Глава 5 200 5.3. Протокол SSH Мы уже говорили о том, что Telnet не подходит для удаленного управления сервером , потому что далеко не безопасен. А желание и потребность в этом есть . В больших сетях, как правило, используются несколько серверов, и бе- гать от одного монитора к другому накладно и неудобно. Любой админист- ратор хочет сидеть за одним компьютером и управлять всем комплексом од- новременно , используя при этом безопасные каналы связи. Во время таких сеансов администратор передает по сети много конфиден- циальной информации (например, пароли root), которая ни в коем случае не должна быть видна прослушивающим утилитам. Для обеспечения безо- пасной связи создано множество различных программ, но самой популяр- ной стала ssh, которая сейчас поставляется в большинстве дистрибутивов Linux. Теперь вы можете спокойно управлять своей сетью, удаленно подключаясь к серверам, и нет необходимости на каждом из них держать по монитору. У меня сделано именно так (экономия на железе), и есть только один дежур- ный монитор, который я могу подсоединить к любому системному блоку, если надо решать проблему не по сети. Преимущество протокола SSH заключается в том, что он позволяет удаленно выполнять команды, но при этом требует аутентификации и шифрует канал связи . Важным моментом является то, что даже пароли при проверке под- линности пользователя передаются в зашифрованном виде. На данный момент существуют две версии протокола SSH с номерами 1 и 2. Вторая версия использует более стойкий алгоритм шифрования и исправляет некоторые ошибки предыдущей версии. В Linux на данный момент поддер- живаются обе версии. Итак , в ОС Linux за протокол SSH отвечает OpenSSH, для которого родной платформой можно считать другую UNIX-систему — OpenBSD — и который клонировался во все UNIX-платформы, в том числе и в Linux. Но даже сейчас в конфигурационных файлах можно иногда увидеть в комментариях имя OpenBSD. Протокол SSH требует для работы настройки сервера и клиента. Сервер ожи- дает подключения и выполняет директивы пользователя, а с помощью клиен- та вы осуществляете соединение с сервером и посылаете запросы на выпол- нение команд. Таким образом, для нормальной работы вы должны правильно сконфигурировать обе части протокола. Администрирование 201 5.3.1. Конфигурационные файлы Все настроечные файлы протокола SSH находятся в директории /etc/ssh. Здесь можно увидеть следующий перечень: файл конфигурации SSH-сервера — sshd_config; файл конфигурации SSH-клиента — ssh_config; файлы ключей для различных алгоритмов: • ssh_host_dsa_key; • ssh_host_dsa_key.pub; • ssh_host_key; • ssh_host_key.pub; • ssh_host_rsa_key; • ssh_host_rsa_key.pub. Почему так много файлов с ключами? Просто SSH работает с разными алго- ритмами шифрования и поддерживает два наиболее популярных и крипто- стойких алгоритма DSA (ssh_host_dsa_key, ssh_host_dsa_key.pub) и RSA (ssh_host_rsa_key и ssh_host_rsa_key.pub). (Замечу, что первое сокращение означает Digital Signature Algorithm или алгоритм цифровой подписи, тогда как второе, несмотря на схожесть, состоит из первых букв имен основателей одноименного алгоритма шифрования: Ronald Rivest, Adi Shamir и Leonard Adleman). Оставшиеся два файла ssh_host_key и ssh_host_key.pub хранят ключи для первой версии SSH. Для каждого алгоритма требуется по два фай- ла : с расширением pub — хранит открытый ключ, без расширения — содер- жит приватный ключ. С помощью открытого ключа можно закодировать данные и отправить их на сервер , но для расшифровки нужен только закрытый ключ, который не мо- жет быть подобран простыми алгоритмами. Он должен быть только у вас, его необходимо беречь и никому не показывать. 5.3.2. Основные параметры конфигурации сервера SSH Давайте теперь рассмотрим содержимое файла конфигурации SSH-сервера (sshd). Его можно увидеть в листинге 5.1. Файл небольшой, поэтому для удобства я привел его полностью, убрав только некоторые комментарии. Глава 5 202 Листинг 5.1. Файл конфигурации sshd #Port 22 #Protocol 2,1 #ListenAddress 0.0.0.0 #ListenAddress :: # HostKey for protocol version 1 # Ключ для первой версии протокола #HostKey /etc/ssh/ssh_host_key # HostKeys for protocol version 2 # Ключи для второй версии протокола #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_dsa_key # Lifetime and size of ephemeral version 1 server key # Время жизни и размер регенерируемого серверного ключа версии 1 #KeyRegenerationInterval 3600 #ServerKeyBits 768 # Logging # Ведение логов #obsoletes QuietMode and FascistLogging #SyslogFacility AUTH SyslogFacility AUTHPRIV #LogLevel INFO # Authentication: # Аутентификация #LoginGraceTime 600 #PermitRootLogin yes #StrictModes yes #RSAAuthentication yes #PubkeyAuthentication yes #AuthorizedKeysFile .ssh/authorized_keys # rhosts authentication should not be used Администрирование 203 # Аутентификацию rhosts не следует использовать #RhostsAuthentication no # Don't read the user's /.rhosts and /.shosts files # Не читать принадлежащие пользователю файлы /.rhosts и /.shosts #IgnoreRhosts yes # For this to work you will also need host keys in # /etc/ssh/ssh_known_hosts # Чтобы это работало, нужны также ключи в /etc/ssh/ssh_known_hosts #RhostsRSAAuthentication no # similar for protocol version 2 # аналогично для версии 2 протокола #HostbasedAuthentication no # Change to yes if you don't trust /.ssh/known_hosts for # RhostsRSAAuthentication and HostbasedAuthentication # Измените на yes, если не доверяете /.ssh/known_hosts для # аутетификации RhostsRSAAuthentication и HostbasedAuthentication #IgnoreUserKnownHosts no # To disable tunneled clear text passwords, change to no here! # Чтобы запретить туннелирование паролей, замените здесь на no #PasswordAuthentication yes #PermitEmptyPasswords no # Change to no to disable s/key passwords # Замените на no, чтобы запретить пароли s/key #ChallengeResponseAuthentication yes # Kerberos options # KerberosAuthentication automatically enabled if keyfile exists # Опции протокола Kerberos # KerberosAuthentication разрешается автоматически, если существует файл # с ключами #KerberosAuthentication yes #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes # AFSTokenPassing automatically enabled if k_hasafs() is true # AFSTokenPassing разрешено автоматически, если вызов k_hasafs() # возвращает true Глава 5 204 #AFSTokenPassing yes # Kerberos TGT Passing only works with the AFS kaserver # Механизм билет-возврат билета в Kerberos работает только с AFS kaserver #KerberosTgtPassing no #PAMAuthenticationViaKbdInt yes #X11Forwarding no X11Forwarding yes #X11DisplayOffset 10 #X11UseLocalhost yes #PrintMotd yes #PrintLastLog yes #KeepAlive yes #UseLogin no #MaxStartups 10 # no default banner path # по умолчанию баннер не задан #Banner /some/path #VerifyReverseMapping no # override default of no subsystems # перевод не особо логичен, поэтому скажу так: # позволяет влючить sftp-сервер. Это защищенный протокол FTP с # шифрованием. При этом отдельные демоны wu-ftp или ftpd не нужны Subsystem sftp /usr/libexec/openssh/sftp-server Рассмотрим основные параметры, которые вам могут пригодиться: Port — порт, на котором ожидаются подключения. По умолчанию это 22. Некоторые администраторы любят изменять это значение, перенося сер- вер на другой порт. В какой-то степени это оправдано. Например, если у вас нет WEB-сервера, то можно поместить SSH на порт 80. Хакеры бу- дут думать, что это WEB-сервер, и не будут его ломать; Protocol — поддерживаемые протоколы. Обратите внимание, что первым идет число 2, а затем 1. Это значит, что сервер будет сначала пытаться подключиться по второй версии протокола, и только затем по первой. Я рекомендую убрать комментарии с этой строки и удалить число 1, чтобы Администрирование 205 использовалась только последняя версия. Уже давно пора обновить кли- ентское программное обеспечение и перейти на более безопасные техно- логии . Зацикливание на старых программах приносит только убытки; ListenAddress — адрес для прослушивания подключения. У вашего сер- вера может быть несколько сетевых карт. По умолчанию идет прослуши- вание всех интерфейсов. Вы должны указать только те, с которых вы бу- дете подключаться по SSH. Например, очень часто одна сетевая карта смотрит во внутреннюю сеть, а другая — в Интернет. Если вы будете под- ключаться по SSH-протоколу только из внутренней сети, то следует про- слушивать только этот адрес (задается в формате адрес:порт ). Разрешается описывать несколько таких записей, чтобы указать требуемые интерфейсы; HostKey — путь к файлам, содержащим ключи шифрования. Нужно про- писывать только закрытые ключи, которые использует сервер для рас- шифровки пакетов; KeyRegenerationInterval — интервал времени, через который сервер об- новляет ключи. В версии 1 во время сессии могут регенерироваться клю- чи . Это позволяет сделать невозможным раскрытие пакетов за счет смены ключей , которые по умолчанию меняются каждые 3600 секунд. Если установить 0, то регенерации не будет. Так как мы отказались от первой версии протокола (см. параметр Protocol ), то этот атрибут не влияет на работу ; ServerKeyBits — длина серверного ключа. По умолчанию установлено 768 , минимальное значение — 512 ; SyslogFacility — тип сообщений, которые будут сохраняться в журнале; LogLevel — уровень событий, которые будут попадать в журнал. Возмож- ные уровни соответствуют системным, которые мы будем рассматривать в разд. 12.5; LoginGraceTime — интервал времени, в течение которого пользователь должен ввести правильный пароль, иначе соединение будет разорвано; PermitRootLogin — флаг, определяющий, разрешено ( yes ) или запреще- но ( no ) входить в систему по протоколу SSH под пользователем root. Мы уже говорили, что root — это бог в системе, и его возможности нужно ис- пользовать аккуратно. Если в систему нельзя входить с такими правами, то и по SSH тем более. Срочно меняйте этот параметр на no ; StrictModes — флаг, регламентирующий необходимость проверки состоя- ния файлов и их владельцев, пользовательских файлов и домашней дирек- тории до ввода пароля. Желательно установить yes , потому что многие на- чинающие пользователи делают все свои файлы доступными для записи. Глава 5 206 RSAAuthentication — разрешена ли аутентификация по алгоритму RSA. Параметр действует для первой версии протокола; PubkeyAuthentication — дозволена ли аутентификация по публичному ключу . Параметр действует для второй версии протокола; AuthorizedKeysFile — файл с публичным ключом, который может ис- пользоваться для аутентификации; RhostsAuthentication — флаг, разрешающий аутентификацию по фай- лам $HOME/.rhosts и /etc/hosts.equiv. По умолчанию стоит no , и без особой надобности менять этот параметр не стоит, потому что это небезопасно; IgnoreRhosts — флаг, запрещающий читать файлы /.rhosts и /.shosts. Без необходимости значение лучше не изменять, потому что это может повлиять на безопасность; AuthorizedKeysFile — файл для хранения списка авторизованных клю- чей . Если пользователь входит в систему с имеющимся в этом файле клю- чом , то его пустят автоматически без ввода дополнительных паролей; RhostsRSAAuthentication — флаг, регламентирующий использование ключа хоста из директории /etc/ssh/ssh_known_hosts при аутентификации. Пара- метр применяется в первой версии SSH; IgnoreUserKnownHosts — параметр, указывающий на необходимость игно- рирования пользовательских списков доверенных компьютеров. Если он ра- вен no , то необходимо доверять компьютерам из списка /.ssh/known_hosts при RhostsRSAAuthentication-аутентификации. Не верьте никому, поэтому параметр лучше всего изменить на yes ; PasswordAuthentication — требование пароля. Если значение равно yes , то будет требоваться пароль. При использовании авторизации через ключи параметр можно отключить; PermitEmptyPasswords — разрешение пустых паролей. По умолчанию установлено no , что запрещает использование пустых паролей, и изменять это значение не стоит; KerberosAuthentication — использование проверки подлинности по про- токолу Kerberos. В последнее время именно эта аутентификация набирает большую популярность благодаря своей безопасности; KerberosOrLocalPasswd — если пароль Kerberos не был принят, то вклю- чается проверка локального файла паролей из файла /etc/shadow; KerberosTicketCleanup — удаление билета Kerberos из кэша при выходе из системы; Banner — позволяет указать файл, в котором находится текст приветствия, отображаемого пользователям. Администрирование 207 5.3.3. Параметры доступа к серверу sshd Кроме директив, приведенных в листинге 5.1, можно использовать следующие: AllowGroups — позволить вход в систему только пользователям указан- ных групп (перечисляются через пробел в одной строке); AllowUsers — разрешить вход в систему пользователям, имена которых перечислены через пробел; DenyGroups — запретить вход в систему пользователям указанных через пробел групп; DenyUsers — запретить вход в систему пользователям, имена которых пе- речислены через пробел. Этот параметр бывает удобен, когда дано разре- шение на вход группе, но нужно отказать в подключении к SSH-серверу одному из ее пользователей. Я рекомендую вам явно прописать группы или имена пользователей, которые могут входить в систему по SSH. 5.3.4. Конфигурирование клиента SSH Настройки SSH-клиента содержат еще меньше параметров. В файле /etc/ssh/ssh_config находятся глобальные настройки для всех пользователей в системе. Но вы можете для любого из них переопределить произвольный параметр в файле .ssh_config из директории пользователя. В листинге 5.2 приведено содержимое глобального файла настроек без некоторых коммен- тариев Листинг 5.2. Конфигурационный файл /etc/ssh/ssh_config # Site-wide defaults for various options # Значения некоторых параметров для всех пользователей по умолчанию # Host * # ForwardAgent no # ForwardX11 no # RhostsAuthentication yes # RhostsRSAAuthentication yes # RSAAuthentication yes # PasswordAuthentication yes # FallBackToRsh no # UseRsh no Глава 5 208 # BatchMode no # CheckHostIP yes # StrictHostKeyChecking ask # IdentityFile /.ssh/identity # IdentityFile /.ssh/id_rsa # IdentityFile /.ssh/id_dsa # Port 22 # Protocol 2,1 # Cipher 3des # Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour # EscapeChar Host * Protocol 2,1 Некоторые из этих параметров мы уже видели при рассмотрении серверного конфигурационного файла. Здесь также можно увидеть параметр Protocol , в котором указываются используемые версии SSH. В данном случае не стоит запрещать версию 1. На безопасность клиента это не повлияет, зато не будет проблем при подключении к серверу, который работает только на такой вер- сии . Я надеюсь, что это будет не ваш сервер :). Вот характерные для клиента команды: Host — сервер, к которому относятся следующие настройки; CheckHostIP — разрешение проверки IP-адреса с перечисленными в файле known_hosts адресами; Compression — разрешение ( yes ) или запрет ( no ) использования сжатия данных ; KerberosAuthentication — разрешение ( yes ) или запрет ( no ) использова- ния аутентификации по протоколу Kerberos; NumberOfPasswordPrompts — количество попыток ввода пароля. Если па- роль не введен верно, то соединение разрывается; IdentityFile — имя файла, содержащего закрытые ключи пользователя; PasswordAutentication — режим аутентификации по паролю. 5.3.5. Пример работы клиента SSH Теперь рассмотрим на примере, как можно подключиться к удаленному сер- веру . Для этого используется команда: ssh пользователь@сервер Администрирование 209 Например , чтобы подсоединиться к серверу fltnovm под именем flenov, нужно выполнить следующую команду: ssh flenov@flenovm В ответ на это вы можете увидеть сообщение: The authenticity of host ‘localhost(127.0.0.1)’ can’t be established RSA1 key fingerprint is f2:a1:6b:d6:fc:d0:f2:a1:6b:d6:fc:d0. Are you sure you want to continue connection (yes/no)? Данным сообщением программа информирует вас, что подлинность хоста не была установлена, и отображает снимок RSA-ключа. Для продолжения соединения необходимо набрать на клавиатуре "yes". На экране появится уведомление : Permanently added ‘localhost’ (RSA1) to the list of known hosts. Здесь сообщается, что ключ добавлен в список известных хостов. Это значит, что в вашей домашней директории, в папке .ssh/ появился (или обновился) файл known_hosts с ключом удаленной системы. Затем предлагается ввести пароль пользователя. Если аутентификация про- шла успешно, вы оказываетесь в системе и можете выполнять команды на удаленном компьютере, как будто вы сидите за его клавиатурой. Подключаться к SSH-порту Linux вы можете и из Windows. Для этого суще- ствует множество различных клиентов. 5.3.6. Вход по ключу Намного удобнее и безопаснее способ авторизации по ключу, а вход по паро- лю может быть даже и вовсе заблокирован. Обращение к системе по SSH не вполне безопасно. Злоумышленник может подсмотреть пароль, когда вы будете вводить его в другой программе. Тогда зачем шифровать SSH- соединение , если секретное слово может быть выявлено при работе с други- ми программами? Для каждого подключения должны быть свои пароли. Но помнить их все очень сложно, поэтому лучше для авторизации использовать ключи, которые и так защищены дальше некуда. Нужно сделать только небольшие изменения в конфигурации. Для начала нужно создать новый ключ. Для этого используется команда ssh- keygen . У нее есть такие параметры: -t — тип ключа. Здесь можно указывать rsa или dsa для второй версии SSH или rsa1 — для первой. Для примера будем использовать ключ rsa ; Глава 5 210 -f — файл, в котором будет сохранен закрытый ключ. Открытый ключ получит такое же имя, но с расширением pub; –b — длина ключа, которая может быть не меньше 512 . По умолчанию установлено значение 1024 , оставим его и не будем указывать этот пара- метр Итак , для генерации ключа выполним команду: ssh-keygen –t rsa –f /.ssh/myrsakey Обратите внимание, что я указал сохранение ключа в поддиректории .ssh своей домашней директории (об этом свидетельствует знак ""). Это дирек- тория , в которой SSH будет искать все настройки. Если вы еще не подключа- лись к серверу, то этот путь и ключ отсутствуют. Для исправления ситуации нужно перейти в свою домашнюю директорию и создать папку .ssh: cd /home/flenov mkdir .ssh Если при генерации ключа не указывать файл для его сохранения, то по умолчанию он будет создан в директории /.ssh/ с именем id_rsa для RSA- шифрования . Для DSA-шифрования файл будет располагаться там же, но его имя будет id_dsa. Я специально задал имя, чтобы показать, как с ним рабо- тать Если программа запустилась успешно, то на экране вы должны увидеть сле- дующее приглашение: Generating public/private rsa key pair. Enter passphrase (empty for no passphrase): В данном сообщении говорится, что начат процесс генерации публичного и закрытого RSA-ключей. Вам предлагается ввести пароль или оставить его пустым . Я рекомендую лучше указать достаточно длинный пароль (не менее 10 символов, а лучше целое предложение). После нажатия клавиши Если все прошло успешно, то вы должны увидеть следующее сообщение: Your identification has been saved in /.ssh/myrsakey. Your public key has been saved in /.ssh/myrsakey.pub. В первой строке нас проинформировали о том, что закрытый ключ сохранен в файле /.ssh/myrsakey, а во второй — что открытый сохранен в /.ssh/myrsakey.pub. Получив ключи, вы должны отправить файл /.ssh/myrsakey.pub на удален- ный компьютер, чтобы SSH-сервер мог использовать его для аутентифика- ции . Для передачи можно смело использовать открытые каналы связи, потому Администрирование 211 что публичный ключ ничего не стоит без фразы, которую вы ввели, и без секретного ключа. Даже если хакер сможет получить файл myrsakey.pub, пользы от этого не будет никакой. Администратор сервера должен добавить содержимое публичного ключа в файл .ssh/authorized_keys. Для этого можно выполнить на сервере следую- щую команду: cat myrsakey.pub >> .ssh/authorized_keys Теперь можно подключаться к серверу, используя публичный ключ для под- тверждения личности. Но перед этим убедитесь, что в конфигурационном файле сервера включены следующие директивы: RSAAuthentication yes PubkeyAuthentication yes Для подключения к серверу выполните команду: ssh –i /.ssh/myrsakey С помощью параметра –i мы указываем файл публичного ключа. Если этого не сделать, то будет использоваться id_rsa — файл по умолчанию, его имя задает директива IdentityFile в конфигурационном файле SSH-клиента. Теперь сервер будет запрашивать у вас не пароль, а слово, которое вы указа- ли при генерации публичного ключа: Enter passphrase for key Если в конфигурационном файле SSH-сервера изменить параметр PasswordAuthentication на no , то пароль проверяться не будет, а связь будет устанавливаться только на основании ключей. Для обеспечения безопасной связи этого достаточно. 5.3.7. X11 в терминале Использование командной строки для управления удаленной системой по- зволяет значительно сэкономить трафик. Но иногда нужен графический режим . Я не рекомендую его использовать в целях безопасности и для повы- шения производительности, но пользователи Windows могут просто не сми- риться с командной строкой. Если вы любите красивые окна, то SSH-сервер может перенаправить X11 (графическую оболочку ОС Linux) на ваш терми- нал . Для этого в конфигурационном файле sshd_config должны быть указаны следующие три директивы: X11Forwarding yes — разрешение переправлять графический режим X11; X11DisplayOffset 10 — первый номер дисплея, доступный для SSH- сервера . По умолчанию 10 , и это значение можно так и оставить; Глава 5 212 X11UseLocalhost yes — если параметр равен yes , то в качестве X-сервера будет использоваться локальный. Если параметр равен yes , то клиент бу- дет работать с нашим X11, а служебная информация, передаваемая по се- ти , будет шифроваться. Если вы хотите подключаться к графической оболочке Linux из Windows, то вам понадобится программа типа X11 для этой ОС. В качестве примера могу пореко- мендовать клиент X-Win32, который можно скачать с сайта www.starnet.com. Я не рекомендую использовать X11, потому что эта технология отлажена еще очень плохо, и существуют методы подделки и взлома соединения. 5.3.8. Защищенная передача данных В состав пакета SSH входят еще две полезные программы — это sftp-server (FTP-сервер с поддержкой шифрования передаваемых данных) и sftp (FTP- клиент для подключения к SFTP-серверу). Давайте посмотрим на последнюю строку файла конфигурации SSH-сервера /etc/ssh/sshd_config: Subsystem sftp /usr/libexec/openssh/sftp-server Директива Subsystem определяет дополнительные сервисы. В данной строке запускается sftp-server из пакета OpenSSH. Работа с клиентом sftp не отличается от работы SSH-клиента. Выполните команду sftp localhost , и перед вами появится приглашение авторизации, которую мы рассматривали в разд. 5.3.5. Введя правильный пароль, вы ока- зываетесь в командной строке FTP-клиента и можете передавать или прини- мать файлы, используя команды протокола FTP. Этот протокол мы будем подробно рассматривать в главе 10, а сейчас вам достаточно знать, что боль- шинство команд схожи с директивами Linux для управления файлами. Попытайтесь сейчас воспользоваться клиентом sftp для подключения к своей системе . Авторизовавшись, можно попробовать выполнить команды ls или cd , чтобы убедиться в работоспособности программы. Для выхода из sftp на- берите команду exit . Основные команды протокола FTP можно увидеть в Приложении 1. Если вам необходимо передать на сервер или скачать с него секретную ин- формацию (например, документы или файл паролей), то используйте для это- го безопасное соединение по SFTP. Простые FTP-клиенты передают файлы в открытом виде (без шифрования), поэтому любой хакер сможет прослу- шать трафик и узнать информацию, которая поможет взломать ваш сервер. Вы должны учитывать, что далеко не все серверы и клиенты поддерживают шифрование SSH, поэтому убедитесь в поддержке этого протокола со стороны вашего программного обеспечения. Например, если вы работаете в Windows Администрирование 213 и хотите использовать безопасное соединение с Linux для обновления фай- лов , можете воспользоваться программой WinSCP (www.winscp.net). Она обладает простым и удобным графическим интерфейсом, а любители движе- ния OpenSource смогут даже найти исходные коды программы. 5.4. Демон inetd/xinetd Для того чтобы сервер смог обрабатывать запросы клиентов, программа должна быть постоянно загружена и связана с определенным портом. В этом нет ничего сложного, но глупо постоянно держать программу в памяти, если она большая, а работает очень редко. В ряде случаев лучше, когда один сер- вис в системе будет следить за портами и запускать необходимый сервис при обращении к определенному каналу. В ОС Linux такая возможность есть, и для этого используется демон inetd или более новая версия — xinetd. Как определить, что запускать? Для этого используется файл /etc/services, в котором находится список сервисов и их портов в следующем формате: имя порт/протокол псевдоним Имя — название сервиса, который необходимо запускать; Порт — номер канала, который должен прослушиваться; Протокол — сервис inetd умеет работать с протоколами TCP и UDP, порты которых не пересекаются (они совершенно различны), так что необходимо в явном виде указывать протокол; Псевдоним — вымышленное имя для сервиса, которое можно не указывать. Например , в файле /etc/services вы найдете следующие строки: tcpmux 1/tcp # TCP port service multiplexer tcpmux 1/udp # TCP port service multiplexer rje 5/tcp # Remote Job Entry rje 5/udp # Remote Job Entry echo 7/tcp ftp 21/tcp ftp 21/udp fsp fspd Я специально выбрал эти строки, чтобы вы увидели варианты описания раз- личных сервисов. Если вы используете старый дистрибутив ОС Linux, то в нем, скорей всего, еще работает init.d. Но мы уже говорили, что давнишний дистрибутив не может Глава 5 214 быть безопасным, и с ним что-либо делать бесполезно. Лучшая защита — обновление , и тогда основным сервисом станет xinetd, который становится, если еще не стал, стандартом для всех. Я рекомендую переход на xinetd, потому что в нем появилось много допол- нительных возможностей, которые повышают удобство администрирования и безопасность. Например, в сервис xinetd встроены проверка всех удачных и неудачных соединений, возможность контроля доступа и даже предостав- ление его строго в определенное время. 5.4.1. Конфигурирование xinetd Основной конфигурационный файл для xinetd — это /etc/xinetd.conf. В нем описываются настройки по умолчанию для запускаемых сервисов, а также директория , в которой будут находиться конфигурационные файлы, влияю- щие на работу конкретных сервисов. Рассмотрим приведенное в листинге 5.3 содержимое этого файла. Листинг 5.3. Файл конфигурации /etc/xinetd.conf # # Simple configuration file for xinetd # Пример конфигурационного файла для xinetd # # Some defaults, and include /etc/xinetd.d/ # Некоторые параметры по умолчанию # и подключение директории /etc/xinetd.d/ defaults { instances = 60 log_type = SYSLOG authpriv log_on_success = HOST PID log_on_failure = HOST cps = 25 30 } includedir /etc/xinetd.d После ключевого слова defaults в фигурных скобках описываются настрой- ки по умолчанию для всех сервисов. Любое из этих значений можно изме- нить для каждого отдельного сервиса. Администрирование 215 Последняя строка подключает директорию /etc/xinet.d. В этом каталоге для каждой службы есть собственный конфигурационный файл, где можно изме- нить параметры. Имена файлов соответствуют названиям сервисов, а содер- жимое — похоже на /etc/xinetd.conf. В листинге 5.4 приведено содержимое конфигурационного файла /etc/xinet.d/telnet для сервиса Telnet. Листинг 5.4. Конфигурационный файл для сервиса Telnet # default: on # По умолчанию включен # description: The telnet server serves telnet sessions; it uses \ # unencrypted username/password pairs for authentication. # Описание: telnet-сервис обслуживает сессии telnet. Он использует # незашифрованные имя пользователя и пароль для аутентификации service telnet { disable = no flags = REUSE socket_type = stream wait = no user = root server = /usr/sbin/in.telnetd log_on_failure += USERID } Рассмотрим основные параметры, которые можно изменять: disable — параметр, установка которого в yes запрещает исполнение сервиса . Как уже говорилось, сервис telnet небезопасен, и поэтому имеет смысл его запретить; flags — атрибуты выполнения сервиса; socket_type — тип используемого сокета. Для протокола TCP здесь должно быть значение streem , а для протокола UDP — dgram ; protocol — используемый для передачи данных протокол (TCP или UDP); server — полный путь к запускаемой программе; user — права доступа. В большинстве случаев можно увидеть имя пользо- вателя root. Это нормально, потому что в ОС Linux для работы с номерами портов менее 1024 необходимы права администратора. В настоящее время большинство сервисов понижают свои права в соответствии с установками; Глава 5 216 instances — максимальное количество одновременно работающих эк- земпляров программы; log_type — файл или системный журнал для записи событий; log_on_success и log_on_failure — информация, которая будет сохра- няться в журнале при удачном и неудачном входе в систему соответствен- но . Здесь можно указывать значения: PID , HOST или USER ; per_source — максимальное количество соединений от одного пользова- теля . Их может быть несколько, потому что пользователи любят макси- мально нагружать каналы и повышать скорость работы с помощью созда- ния нескольких одновременно работающих соединений; server_args — аргументы, с которыми будет запускаться сервер. При рассмотрении параметра user я упомянул о необходимости прав адми- нистратора для доступа к портам с номером менее 1024. Это действительно так , но зачем это нужно? Не имея прав root, пользователь не сможет запус- тить сервер, который работает с портом от 1 до 1024. Такая защита необхо- дима , потому что в данном диапазоне функционируют очень важные серви- сы , и их нельзя запускать простому пользователю. Представьте себе, что хакер с правами простого пользователя смог бы запус- тить FTP-сервер, причем, возможно, ему удалось бы подменить конфигу- рационный файл при запуске, чтобы расширить свои права. Сделай он это, и у него появится возможность загружать на сервер файлы и скачивать их к себе на компьютер, что нежелательно. 5.4.2. Безопасность Мы уже знаем, что программа xinetd позволяет определять права и время доступа к сервисам. Для этого в конфигурационном файле можно использо- вать три директивы: no_access , only_from и access_time Директива no_access запрещает доступ с указанных компьютеров. Напри- мер , следующая строка в конфигурационном файле закрывает доступ с адре- са 192.168.1.1: no_access 192.168.1.1 Если необходимо запретить доступ целой сети, то достаточно указать только ее номер. Например, если нужно закрыть вход всем компьютерам с адресами 192.168.1.X, где Х может быть любым числом, следует использовать сле- дующую строку: no_access 192.168.1. Администрирование 217 Обратите внимание, что в этом случае указанный IP-адрес состоит из трех октетов , разделенных точками, а не четырех, правда после третьего числа указывается точка. Для полного запрета доступа необходимо указать в конфигурационном файле следующую строку: no_access 0.0.0.0 Теперь посмотрим, как можно предоставлять доступ с помощью директивы only_from . Она удобна тем, что изначально запрещает все, кроме указанных в качестве параметра адресов. Получается, что мы действуем от запрета. Ука- зав эту команду без параметра, мы вообще запретим доступ: only_from = Я рекомендую включить эту строку в основной конфигурационный файл /etc/xinetd.conf, а потом для каждого отдельного сервиса в его собственном конфигурационном файле прописать разрешения. Например, давайте откроем доступ с адресов 192.168.1.2 и 192.168.1.19. Для этого добавляем в конфигу- рационный файл следующую строку: only_from = 192.168.1.2 192.168.1.19 Можно разрешать доступ целым сетям: only_from = 192.168.1. А что, если всей сети разрешен доступ, а компьютеру с номером 1 запрещен? В этом случае можно использовать следующие две строки: no_access = 192.168.1.1 only_from = 192.168.1. Запрет имеет больший приоритет, и даже несмотря на то, что у сети есть раз- решение , компьютер из этой сети с номером 192.168.1.1 подключиться не сможет Теперь рассмотрим, как можно задать время доступа. Если вы настраиваете сервер , который будет работать в офисе компании, то вполне логичным будет разрешить подключение к нему только в рабочее время. Например, следую- щая строка делает сервисы доступными только с 8:00 до 18:00: access_time = 8:00-18:00 В данном случае я бы увеличил второе значение до 19:00, потому что со- трудники часто задерживаются на работе, и не хочется, чтобы они дергали меня каждый день из-за доступа. Функции обеспечения безопасности, встроенные в сервис xinetd, удобны и об- ладают достаточно мощными возможностями, хотя и дублируют права до- ступа , которые можно настраивать из файлов /etc/hosts.allow и /etc/hosts.deny. Глава 5 218 Мне больше нравится заниматься настройкой безопасности с помощью конфи- гурационных файлов сервиса xinetd, потому что параметры доступа хранятся в тех файлах, на которые они влияют. 5.4.3. Недостатки xinetd У любой технологии есть недостатки, и inetd/xinetd не являются исключени- ем . При подключении пользователя к одному из портов вашего сервера про- грамма inetd (или xinetd) просматривает таблицу портов, чтобы найти сервис, который необходимо запустить, и передать ему управление. Это может по- влечь за собой большие затраты на поиск сервиса и его запуск. В идеальном случае любой запрос должен выполняться максимально быстро, иначе это грозит нам увеличением времени отклика. Но не это самое страш- ное . Лишнюю пару секунд пользователь может подождать, а вот хакер ждать не будет. Он может направить большое количество запросов на соединение с сервером , и программа inetd (или xinetd) съест все ресурсы компьютера по- иском и запуском сервисов. Таким образом, увеличивается вероятность удач- ного проведения DoS-атаки со стороны хакера. |