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

 

5.1.1. netconf

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

Рис. 5.1. Окно программы netconf

 

5.1.2. ping

Одна из часто используемых администраторами команд — ping. Она посылает ICMP-пакеты в виде эхо-запросов на указанную систему для определения пропускной способности сети.

Например, выполните команду ping 195.18.1.41 и в ответ вы получите следующую информацию:

PING 195.18.1.41 (195.18.1.41) from 195.18.1.41 : 56(84) bytes of data.

64 bytes from 195.18.1.41: icmp_seq=1 ttl=64 time=0.102 ms

64 bytes from 195.18.1.41: icmp_seq=2 ttl=64 time=0.094 ms

64 bytes from 195.18.1.41: icmp_seq=3 ttl=64 time=0.094 ms

64 bytes from 195.18.1.41: icmp_seq=4 ttl=64 time=0.095 ms

--- 195.18.1.41 ping statistics ---

4 packets transmitted, 4 received, 0% loss, time 3013 ms

rtt min/avg/max/mdev = 0.094/0.096/0.102/0.007 ms

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

Следом на экране начнут появляться строки типа:

64 bytes from 195.18.1.41: icmp_seq=1 ttl=64 time=0.102 ms

Отсюда мы узнаем, что было получено 64 байта с адреса 195.18.1.41. После двоеточия отображаются следующие параметры:

□ icmp_seq — номер пакета. Это значение должно последовательно увеличиваться на 1. Если какой-либо номер отсутствует, то это означает, что пакет потерялся в Интернете и не дошел до адресата или ответ не вернулся к вам. Это может быть из-за неустойчивой работы оборудования, плохого кабельного соединения или один из маршрутизаторов в сети между компьютерами выбрал неправильный путь, и пакет не достиг места назначения;

□ ttl — время жизни пакета. При отправке пакета ему отводится определенное время жизни, которое задается числом. По умолчанию в большинстве систем ttl равно 64, но значение может быть изменено. Каждый маршрутизатор при передаче пакета уменьшает это число. Когда оно становится равным нулю, пакет считается заблудившимся и уничтожается. Таким образом, по этому значению можно приблизительно сказать, сколько маршрутизаторов встретилось на пути;

□ time — время, затраченное на ожидание ответа. По этому параметру можно судить о скорости связи и о ее стабильности, если значение параметра не сильно изменяется от пакета к пакету. Но учитывайте, что время, затраченное на отправку и получение первого пакета, почти всегда выше. Все остальные должны идти равномерно.

Если ответ на какой-нибудь пакет не был получен, то вы увидите сообщение о его потере. Дождитесь, пока программа не отправит 7–10 пакетов, чтобы по их параметрам оценить качество связи, и после этого можно прерывать сеанс нажатием клавиш +. В результате вы увидите небольшую статистику обмена сообщениями: количество отправленных, полученных и потерянных пакетов, а также минимальное, среднее и максимальное время обмена пакетами.

Рассмотрим основные параметры, которые можно использовать в команде ping:

□ -c n — завершить работу после отправки (и приема) n пакетов. Например, вы хотите послать пять запросов, тогда команда будет выглядеть следующим образом: ping -с 5 195.10.14.18;

□ -f — форсированная передача (скорость достигается за счет того, что все пакеты посылаются в сеть без ожидания ответа). Например, вам нужно быстро отправить 50 запросов, тогда команда будет выглядеть следующим образом: ping -f -с 50 195.10.14.18. Этот ключ в сочетании с большим количеством пакетов значительного размера может сильно загрузить сеть и компьютер получателя, а в некоторых системах даже привести к временному отказу от обслуживания;

□ -s n — устанавливает размер пакета. Например, вы хотите отправить пакет размером в 1000 байт. В этом случае команда будет выглядеть ping -s 1000 195.10.14.18. В некоторых старых версиях ОС были ошибки, и при получении слишком большого пакета система зависала. В настоящее время погрешности такого рода отсутствуют, и встретить подобную систему в Интернете сложно.

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

Внимание!

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

 

5.1.3. netstat

Эта команда показывает текущие подключения к серверу. Результат ее выполнения имеет примерно следующий вид:

Active Internet connections (w/o servers)

Proto Recv-Q Send-Q Local Address    Foreign Address    State

tcp        0      0 FlenovM:ftp      192.168.77.10:3962 ESTABLISHED

tcp        0      0 FlenovM:ftp-data 192.168.77.10:3964 TIME_WAIT

Вся информация разложена по колонкам. Давайте рассмотрим каждую из них:

□ Proto — базовый протокол, который использовался для соединения. Чаще всего здесь можно видеть unix или tcp;

□ Recv-Q — количество байтов, не скопированных пользовательской программой;

□ Send-Q — количество байтов, не принятых удаленным компьютером;

□ Local Address — локальный адрес формата компьютер:порт. В качестве порта может использоваться как символьное имя, так и число. В приведенном выше примере в первой строке показан порт ftp, что соответствует числу 21;

□ Foreign Address — удаленный адрес В формате IP:порт;

□ State — состояние соединения.

У этой команды много возможных параметров, и полное их описание можно увидеть в файле справки, набрав команду man netstat.

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

 

5.1.4. lsof

Позволяет просмотреть открытые файлы. Команда достаточно мощная и имеет множество параметров. Одна из интересных особенностей — возможность просмотра открытых портов, если указать ключ -i:

lsof -i

Я советую сейчас остановиться и изучить документацию по этой команде, предоставляемую утилитой man.

 

5.1.5. Telnet

Мощность Linux и его текстовой консоли заключается в том, что вы можете выполнять все действия не только сидя непосредственно за терминалом, но и удаленно. Нужно только подключиться к компьютеру на порт Telnet-сервера с помощью Telnet-клиента, и можно считать, что вы в системе.

В Windows очень мало утилит, способных работать в командной строке, поэтому в этой ОС необходим (и широко используется) графический режим. Да и сама командная строка в Windows обладает незначительными возможностями. Для решения этой проблемы был создан терминальный доступ, который позволяет на клиентской машине видеть экран сервера и работать с ним так, как будто вы сидите непосредственно за сервером. Но этот метод отнимает слишком много трафика и очень неудобен на каналах медленной связи.

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

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

Но это не все, с помощью Telnet-клиента можно подсоединяться и к другим серверам. Например, можно подключиться на порт 25 и прямо из командной строки отправить E-mail-сообщение, исполняя команды SMTP-сервера.

Если у вас есть установленный FTP-сервер, то уже сейчас вы можете выполнить команду:

telnet localhost 21

В данном случае первый параметр — это localhost, потому что я подразумеваю, что вы подключаетесь к локальному FTP-серверу. Если вы хотите работать с удаленным компьютером, то укажите его адрес. В качестве второго параметра указывается номер порта. Сервер FTP принимает управляющие команды на 21 порту, поэтому я указал это число.

Я рекомендую применять Telnet-клиент только для отладки различных сервисов, но не для управления. Поэтому на всех машинах отключайте Telnet. Он небезопасен, потому что передает данные в открытом виде, а все попытки сделать Telnet защищенным заканчивались неудачно и не приводили к желаемому результату. Один из возможных вариантов использования — через канал шифрования OpenSSL (от Secure Socket Layer, протокол защищенных сокетов). Но большую популярность получило управление сервером через протокол SSH (OpenSSH, Open Secure Shell), который мы рассмотрим позже, в разд 5.3.

Таким образом, Telnet-клиент в системе необходим, a Telnet-сервер, если он у вас установлен, следует срочно удалить и забыть как страшный сон.

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

Если у вас установлен Telnet-сервер, то попробуйте сейчас подключиться к нему, используя команду telnet localhost. Перед вами появятся следующие сообщения:

Trying 127.0.0.1

Connected to localhost

Escape character is '^]'.

ASPLinux release 7.3 (Vostok)

Kernel 2.4.18-15asp on an i686

Login:

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

Излишняя болтливость Telnet — это самая большая дыра, с которой надо бороться в первую очередь. Приветствие, которое вы можете видеть при подключении, находится в файлах /etc/issue и /etc/issue.net. Измените текст сообщения, например, следующим образом:

echo Текст > /etc/issue

echo Текст > /etc/issue.net

Здесь Текст — это новое приветствие. Можно указать ложную версию ядра, чтобы запутать хакера:

echo Debian Linux > /etc/issue

echo Kernel 2.4.4 on an i686 > /etc/issue.net;

У меня установлен клон Red Hat дистрибутива с ядром 2.4.18-15asp, а хакер будет думать, что я использую Debian и старое ядро 2.4.4.

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

chattr +i /etc/issue

chattr +i /etc/issue.net

 

5.1.6. r-команды

В Linux есть так называемые r-команды: rlogin, rsh, rcp, rsync, rdist. Мы не будем их рассматривать, потому что все они создают большие проблемы в безопасности. Если Telnet-клиент нужен для тестирования сервисов, то эти команды я включил в обзор только для того, чтобы вы удалили их из системы, и никогда не появлялся соблазн их использовать, и чтобы ими не смог воспользоваться хакер.

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

 

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

Как мы уже говорили в гл.1, при подключении по коаксиальному кабелю могут использоваться две схемы: все компьютеры объединяются напрямую в одну общую шину или кольцо, когда крайние компьютеры тоже соединены между собой (разновидность первого варианта). При использовании общей шины (рис. 5.2) все компьютеры подключены последовательно, и посылаемый пакет проходит по всем компьютерам, которые встречаются на пути, а установленные на них сетевые карты проверяют адресата: если пакет направлен им, то принять, иначе — пропустить.

Рис. 5.2. Схема соединения компьютеров "Общая шина"

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

Соединение по коаксиальному кабелю встречается все реже, потому что оно ненадежно и позволяет передавать данные максимум на скорости 10 Мбит/с. Да и сама схема подключения в общую шину не внушает доверия. При выходе из строя одного из компьютеров может нарушиться работа всей сети. Замыкание в кольцо отчасти снимает вопросы надежности, но не решает проблемы скорости и неудобства построения, обслуживания и использования такой сети.

При объединении компьютеров через центральное устройство хаб (Hub) или коммутатор (Switch) используется топология "Звезда" (см. рис. 5.3). В этом случае компьютеры с помощью витой пары получают одну общую точку. Такая схема надежнее и позволяет работать на скорости в 100 Мбит/с.

Рис. 5.3. Схема соединения компьютеров "Звезда"

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

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

В случае с коммутатором (более интеллектуальное устройство) пакеты будет видеть только получатель, потому что Switch имеет встроенные возможности маршрутизации, которые реализуются в основном на уровне MAC-адреса (Media Access Control Address, управление доступом к среде), который называют физическим адресом. Это 48-разрядный серийный номер сетевого адаптера, присваиваемый производителем. Он уникален, потому что у каждого изготовителя свой диапазон адресов. К каждому порту коммутатора подключен компьютер с определенным MAC-адресом. Пакет направляется только на порт адресата, и другие участники сети его не увидят.

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

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

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

□ на клиентском компьютере на определенном порту (условно Порт 1) вы должны запустить программу для шифрования трафика. Теперь, вместо того чтобы передавать данные на удаленный компьютер, вы должны с помощью FTP-клиента подсоединиться к Порту 1 своего компьютера и направлять данные на него, а уже там открытая программа их зашифрует и передаст по сети в закрытом виде;

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

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

Рис. 5.4. Шифрование канала

Получается, что шифрование не изменяет протокол, он остается тем же самым TCP/IP, просто на стороне клиента и сервера появляется посредник, который кодирует и декодирует данные. Использование такого метода очень удобно тем, что можно шифровать трафик любого протокола. Если в криптографическом алгоритме будет найдена ошибка или внесены качественные поправки, например, использование более длинного ключа, то не надо вносить изменения в сам протокол. Достаточно обновить программу и все новые возможности станут доступными.

Рассмотрим пример с Web-сервисом, который работает на 80 порту. На сервере можно запустить программу шифрования на 1080 порту, и все данные, которые будут приходить на него, будут декодироваться и передаваться на 80 порт. Если вы хотите предоставлять доступ к Web только по протоколу SSL, то 80 порт можно закрыть от вторжения извне сетевым экраном (о работе сетевого экрана мы подробно говорили в гл.4), а разрешить только подключения с сервера шифрования.

Адреса сайтов, которые защищены специальными ключами, начинаются с "https://". Буква "s" как раз и говорит о том, что соединение безопасно. Помимо этого, при подключении через обозреватель с включенным SSL в правом нижнем углу окна, в строке состояния появляется значок. Например, в популярном браузере Internet Explorer это пиктограмма висячего замка (рис. 5.5).

Рис. 5.5. Строка состояния Internet Explorer для безопасного соединения

Но этот опознавательный значок даже в Internet Explorer появляется не всегда. Более точно определить тип используемого соединения можно по свойствам документа. Большинство браузеров имеют команду просмотра свойств загруженной страницы, по вызову которой можно увидеть и используемое шифрование. Например, в Internet Explorer необходимо выбрать меню File/Properties (Файл/Свойства). Перед вами откроется окно, как на рис. 5.6.

Рис. 5.6. Свойства документа в Internet Explorer

Обратите внимание на поле Connection. Информация в нем свидетельствует, что используется протокол SSL 3.0 RC4 со 128-битной схемой шифрования.

 

5.2.1. stunnel

В ОС Linux для шифрования и дешифрования трафика чаще всего используется программа stunnel. Но она только организует канал и выступает посредником, а для самого кодирования используется пакет OpenSSL, доступный в большинстве дистрибутивов Linux, и можно надеяться, что он у вас уже поставлен. Если нет, то это легко сделать с помощью установки соответствующего RPM-пакета с инсталляционного диска. Более подробную информацию по OpenSSL и последние обновления можно найти на сайте www.openssl.org,

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

У программ OpenSSL и stunnel очень много параметров, и рассматривать их все мы не будем. Лучше разберем реальный пример и познакомимся с наиболее часто используемыми аргументами.

Итак, давайте для начала запустим на сервере программу stunnel, которая будет расшифровывать входящий трафик и передавать его на какой-нибудь порт, например 25 (здесь работает SMTP-сервер Sendmail). Для этого выполните следующую команду:

stunnel -р /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 с указанием порта, на котором необходимо ждать подключения (значение 1000), и -r, в котором указывается адрес и порт для передачи зашифрованных данных.

Теперь достаточно настроить свою клиентскую программу так, чтобы при отправке почты она направлялась на порт (в данном случае 1000) компьютера, где запущен stunnel-клиент, который будет шифровать данные и пересылать их на порт 9002 сервера с адресом 192.168.77.1. Там закодированные данные будет принимать stunnel-сервер, расшифровывать и передавать их на 25 порт сервера.

 

5.2.2. Дополнительные возможности OpenSSL

При запуске программы stunnel на сервере мы задали использование сертификата авторизации, но не сказали, как проверять его подлинность. Для указания уровня контроля применяется ключ -v, после которого идет число:

□ 0 — нет никакой проверки;

□ 1 — если сертификат присутствует, то он проверяется на подлинность. Если получен отрицательный результат, то соединение разрывается. Наличие сертификата не является обязательным, соединение может быть установлено и без него;

□ 2 — на данном уровне сертификат является обязательным. Если сертификата нет или он не является подлинным, соединение не может быть установлено;

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

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

Во время установки пакета OpenSSL на вашем диске создаются сертификаты и пары ключей, которые используются для шифрования. Все это находится в директории /usr/share/ssl/.

С помощью опции -n можно непосредственно указать протокол, с которым будет происходить работа. В настоящий момент поддерживаются POP3 (Post Office Protocol, протокол обработки входящих сообщений), SMTP (Simple Mail Transfer Protocol, простой протокол электронной почты)) или NNTP (Network News Transfer Protocol, сетевой протокол передачи новостей).

Для большинства основных протоколов существуют номера портов, уже ставшие стандартом. Есть даже названия защищенных вариантов протоколов, которые, как правило, получаются за счет добавления к наименованию основного протокола буквы s, которая и указывает на безопасное соединение через SSL. Эта информация приведена в табл. 5.1.

Таблица 5.1. Список протоколов с номерами портов

Обратите внимание, что для протокола FTP требуется два защищенных канала. Один используется для управляющего соединения, а второй — для передачи данных. К этому мы еще вернемся в гл. 10, когда будем рассматривать этот протокол.

 

5.2.3. Шифрование файлов

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

Шифрование необходимо не только для резервных копий файлов или архивных данных, но и для файлов с секретной информацией, которые необходимо передать по незащищенным каналам связи, например, через E-mail-почту или публичный 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 Digital Subscriber, асимметричная цифровая абонентская линия). В абонентскую плату входит всего 400 Мбайт трафика. Ну что такое 400 Мбайт? Для меня это неделя работы в экономном режиме, потому что общаться приходится много, а из почтового ящика я иногда выкачиваю до 20 Мбайт в день. Оплата сверх абонентской платы обходится достаточно дорого.

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

В мою абонентскую плату входит 10 Мбайт серверного пространства для создания визитной карточки в Интернете. Максимум, что можно там разместить, — домашнюю страничку. Но мне это не нужно. Главное, что трафик для этого сайта неограничен.

Итак, если установить на сервер программу туннелирования, то можно организовать соединение, как показано на рис. 5.7.

Рис. 5.7. Подключение к Интернету через Web-сервер

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

Таким образом можно скачивать не 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. Эта возможность есть на большинстве почтовых сервисов, и вам она должна быть знакома на практике.

 

Мы уже говорили о том, что протокол Telnet не очень хорошо подходит для удаленного управления сервером, потому что далеко не безопасен. А желание и потребность в этом есть. В больших сетях, как правило, используются несколько серверов, и бегать от одного монитора к другому накладно и неудобно. Любой администратор хочет сидеть за одним компьютером и управлять всем комплексом одновременно, и при этом по безопасным каналам связи.

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

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

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

На данный момент существуют две версии протокола SSH с номерами 1 и 2. Вторая версия использует более стойкий алгоритм шифрования и исправляет некоторые ошибки предыдущей версии. В Linux на данный момент поддерживаются обе версии.

Итак, в ОС Linux за протокол SSH отвечает программа OpenSSH. для которой родной платформой можно считать другую Unix-систему — OpenBSD, а впоследствии сервис клонировался на все Unix-платформы, в том числе и в Linux. Но даже сейчас в конфигурационных файлах можно иногда увидеть в комментариях имя OpenBSD.

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

 

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 (это сокращение состоит из имен основателей алгоритма шифрования: Ronald Rivest, Adi Shamir и Leonard Adleman) (ssh_host_rsa_key и ssh_host_rsa_key.pub). Оставшиеся два файла ssh_host_key, ssh_host_key.pub хранят ключи для первой версии SSH. Для каждого алгоритма требуется по два файла: с расширением pub — хранит открытый ключ, без расширения — содержит приватный ключ.

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

 

5.3.2. Основные параметры конфигурации сервера SSH

Давайте теперь рассмотрим содержимое файла конфигурации SSH-сервера (sshd). Его можно увидеть в листинге 5.1. Файл небольшой, поэтому для удобства я привел его полностью, убрав только некоторые комментарии.

Листинг 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/ssb_host_dsa_key

#Lifetime and size of ephemeral version 1 server key

#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

#RhostsAuthentication no

#Don't read the user's ~/.rhosts and ~/.shosts files

#IgnoreRhosts yes

#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

#Change to yes if you don't trust ~/.ssh/known_hosts for

#RhostsRSAAuthentication and HostbasedAuthentication

#IgnoreUserKnownHosts no

#To disable tunneled clear text passwords, change to no here!

#PasswordAuthentication yes

#PermitEmptyPasswords no

#Change to no to disable s/key passwords

#ChallengeResponseAuthentication yes

#Kerberos options

#KerberosAuthentication automatically enabled if keyfile exist

#KerberosAuthentication yes

#KerberosOrLocalPasswd yes

#KerberosTicketCleanup yes

#AFSTokenPassing automatically enabled if k_hasafs() is true

#AFSTokenPassing yes

#Kerberos TGT Passing only works with the 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

Subsystem sftp /usr/libexec/openssh/sftp-server

Рассмотрим основные параметры, которые вам могут пригодиться:

□ Port — порт, на котором ожидаются подключения. По умолчанию это 22. Некоторые администраторы любят изменять это значение, перенося сервер на другой порт. В какой-то степени это оправдано. Например, если у вас нет Web-сервера, то можно поместить SSH на 80 порт. Хакеры будут думать, что это Web-сервер, и не будут его ломать;

□ Protocol — поддерживаемые протоколы. Обратите внимание, что первым идет число 2, а затем 1. Это значит, что сервер будет сначала пытаться подключиться по протоколу второй версии, и только потом по первому. Я рекомендую убрать комментарии с этой строки и удалить число 1, чтобы использовалась только последняя версия. Уже давно пора обновить клиентское программное обеспечение и перейти на более безопасные технологии. Зацикливание на старых программах приносит только убытки;

□ ListenAddress — определяет адреса для прослушивания подключения. У вашего сервера может быть несколько сетевых карт. По умолчанию идет прослушивание всех интерфейсов. Вы должны указать только те, с которых вы будете подключаться по SSH. Например, очень часто одна сетевая карта смотрит во внутреннюю сеть, а другая — в Интернет. Если вы будете подключаться по SSH-протоколу только из внутренней сети, то следует прослушивать только этот адрес (задается в формате адрес:порт). Разрешается описывать несколько таких записей, чтобы указать требуемые интерфейсы;

□ HostKey — указывается путь к файлам, содержащим ключи шифрования. Нужно прописывать только закрытые ключи, которые использует сервер для расшифровки пакетов;

□ KeyRegenerationInterval — в версии 1 во время сессии могут регенерироваться ключи. Это позволяет сделать невозможным раскрытие пакетов за счет смены ключей, которые по умолчанию меняются каждые 3600 секунд. Если установить 0, то регенерации не будет. Так как мы отказались от 1 версии протокола (см. параметр protocol), то этот атрибут не влияет на работу;

□ ServerKeyBits — длина серверного ключа. По умолчанию установлено 768, минимальное значение — 512;

□ SyslogFacility — задает тип сообщений, которые будут сохраняться в журнале;

□ LogLevel — уровень событий, которые будут попадать в журнал. Возможные уровни соответствуют системным, которые мы будем рассматривать в разд. 12.5;

□ LoginGraceTime — интервал времени, в течение которого пользователь должен ввести правильный пароль, иначе соединение будет разорвано;

□ РеrmitRootLogin — определяет, разрешено (yes) или запрещено (no) входить в систему по SSH-протоколу под пользователем root. Мы уже говорили, что root — это бог в системе, и его возможности нужно использовать аккуратно. Если в систему нельзя входить с такими правами, то и по SSH тем более. Срочно меняйте этот параметр на no;

□ StrictModes — указывает, должен ли sshd проверять состояние файлов и их владельцев, пользовательских файлов и домашней директории до ввода пароля. Желательно установить yes, потому что многие начинающие пользователи делают свои файлы все доступными для записи;

□ RSAAuthentication — разрешена ли аутентификация по алгоритму RSA. Параметр действует для 1 версии протокола;

□ PubkeyAuthentication — дозволена ли аутентификация по публичному ключу. Параметр действует для 2-й версии протокола;

□ AuthorizedKeysFile — файл с публичным ключом, который может использоваться для аутентификации;

□ RhostsAuthentication — разрешение аутентификации по файлам $HOME/.rhosts и /etc/hosts.equiv. По умолчанию стоит no, и без особой надобности менять этот параметр не стоит, потому что это небезопасно;

□ IgnoreRhosts — если параметр равен yes, то запрещается читать файлы ~/.rhosts и ~/.shosts. Без необходимости значение лучше не изменять, потому что это может повлиять на безопасность;

□ AuthorizedKeysFile — файл для хранения списка авторизованных ключей. Если пользователь входит в систему с имеющимся в этом файле ключом, то его пустят автоматически без ввода дополнительных паролей;

□ RhostsRSAAuthentication — если этот параметр yes, то при аутентификации будет требоваться ключ хоста из директории /etc/ssh/ssh_known_hosts. Параметр используется в 1 версии SSH;

□ IgnoreUserKnownHosts — если параметр равен no, то необходимо доверять компьютерам из списка ~/.ssh/known_hosts при RhostsRSAAuthentication-аутентификации. Не верьте никому, поэтому параметр лучше всего изменить на yes;

□ PasswordAuthentication — если значение равно yes, то будет требоваться пароль. При использовании авторизации через ключи параметр можно отключить;

□ PermitEmptyPasswords — по умолчанию установлено no, что запрещает использование пустых паролей, и изменять это значение не стоит;

□ KerberosAuthentication — использовать проверку подлинности по протоколу Kerberos. В последнее время именно эта аутентификация набирает большую популярность благодаря своей безопасности;

□ KerberosOrLocalPasswd — если пароль Kerberos не был принят, то включается проверка локального файла паролей из файла /etc/shadow;

□ KerberosTicketCleanup — очищать билет Kerberos из кэша при выходе из системы;

□ Banner — позволяет указать файл, в котором находится текст приветствия, отображаемый пользователями.

 

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

#  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,aes192-cbc,aes256-cbc

#  EscapeChar ~

Host *

Protocol 1,2

Некоторые из этих параметров мы уже видели при рассмотрении серверного конфигурационного файла. Здесь также присутствует параметр Protocol, в котором указываются используемые версии SSH. Только в данном случае не стоит запрещать 1 версию. На безопасность клиента это не повлияет. Зато не будет проблем при подключении к серверу, который работает только на такой версии. Я надеюсь, что это будет не ваш сервер ☺.

Перечислю характерные для клиента команды:

□ Host — указывает, к какому серверу будут относиться следующие настройки;

□ CheckHostIP — разрешена проверка IP-адреса с перечисленными в файле know_hosts адресами;

□ Compression — позволяет (yes) или запрещает (no) использование сжатия данных;

□ KerberosAuthentication — позволяет (yes) или запрещает (no) использование аутентификации по протоколу Kerberos;

□ NumberOfPasswordPrompts — задает количество попыток ввода пароля. Если пароль не введен верно, то соединение разрывается;

□ IdentityFile — определяет имя файла, содержащего закрытые ключи пользователя;

□ PasswordAutentication — указывает на использование аутентификации по паролю.

 

5.3.5. Пример работы клиента SSH

Теперь рассмотрим на примере, как можно подключиться к удаленному серверу. Для этого используется команда:

ssh пользователь@сервер

Например, чтобы подсоединиться к серверу flenovm под именем 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 с ключом удаленной системы.

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

 

5.3.6. Вход по ключу

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

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

Для начала нужно создать новый ключ. Для этого используется программа ssh-keygen. Ей нужно передать два параметра:

□ -t — тип ключа. Здесь можно указывать rsa или dsa для второй версии SSH или rsa1 — для первой. Для примера будем использовать rsa ключ;

□ -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 ~/ssn/myrsakey.

Your public key has been saved in ~/ssh/myrsakey.pub.

В первой строке нас проинформировали о том, что закрытый ключ сохранен в файле ~/ssh/myrsakey, а открытый — в ~/ssh/myrsakey.pub.

Получив ключи, вы должны отправить файл ~/ssh/myrsakey.pub на удаленный компьютер, чтобы SSH-сервер мог использовать его для аутентификации. Для передачи можно смело использовать открытые каналы связи, потому что публичный ключ ничего не стоит без фразы, которую вы ввели, и без секретного ключа. Даже если хакер сможет получить файл 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 — разрешает переправлять ОС Linux графический режим X11;

□ X11DisplayOffset 10 — первый номер дисплея, доступный для SSH-сервера. По умолчанию 10, и это значение можно так и оставить;

□ X11UseLocalhost yes — если параметр равен yes, то в качестве X-сервера будет использоваться локальный. В этом случае клиент будет работать с нашим X11, а служебная информация, передаваемая по сети, будет шифроваться.

Если вы хотите подключаться к графической оболочке Linux из Windows, то вам понадобится программа типа X11 для этой ОС. В качестве примера могу порекомендовать X-Win32-клиент, который можно скачать с сайта http://www.starnet.com/.

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

 

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

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

 

Для того чтобы сервер смог обрабатывать запросы клиентов, программа должна быть постоянно загружена и связана с определенным портом. В этом нет ничего сложного, но зачем постоянно держать программу в памяти, особенно если она слишком большая, а работает очень редко. Намного лучше, когда один сервис в системе будет следить за портами, и если пользователь обращается к определенному каналу, то эта программа запустит необходимый сервис. В ОС 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, то в нем, скорей всего, еще работает inetd. Но мы уже говорили, что давнишний дистрибутив не может быть безопасным, и с ним что-либо делать бесполезно. Лучший защита — обновление, и тогда основным сервисом станет 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

 logotype       = SYSLOG authpriv

 log_on_success = HOST PID

 log_on_failure = HOST

 cps            = 25 30

}

includedir /etc/xinetd.d

После ключевого слова defaults в фигурных скобках описываются настройки по умолчанию для всех сервисов. Любое из этих значений можно изменить для каждого отдельного сервиса.

Последняя строка подключает директорию /etc/xinet.d:

includedir /etc/xinetd.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 — если этот параметр установить в true, то сервис будет запрещен для исполнения;

□ flags — атрибуты выполнения сервиса;

□ socket_type — тип используемого сокета. Для протокола TCP здесь должно быть значение stream, а для протокола UDP — dgram;

□ protocol — используемый для передачи данных протокол (TCP или UDP);

□ server — полный путь к запускаемой программе;

□ user — права доступа. В большинстве случаев можно увидеть имя пользователя root. Это нормально, потому что в ОС Linux для работы с номерами портов менее 1024 необходимы права администратора. В настоящее время большинство сервисов понижают свои права в соответствии с установками;

□ 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, где X может быть любым числом. В этом случае нужно использовать следующую строку:

no_access 192.168.1.

Обратите внимание, что в этом случае указанный 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. Мне больше нравится заниматься настройкой безопасности с помощью конфигурационных файлов сервиса xinetd, потому что параметры доступа хранятся в тех файлах, на которые они влияют.

 

5.4.3. Недостатки xinetd

У любой технологии есть недостатки, и inetd/xinetd не являются исключением. При подключении пользователя к одному из портов вашего сервера программа inetd (или xinetd) просматривает таблицу портов, чтобы найти сервис, который необходимо запустить, и передать ему управление. Это может повлечь за собой большие затраты на поиск сервиса и его запуск.

В идеальном случае, любой запрос должен выполняться максимально быстро, иначе это грозит нам увеличением времени отклика. Но не это самое страшное. Лишнюю пару секунд пользователь может подождать, а вот хакер ждать не будет. Он может направить большое количество запросов на соединение с сервером, и программа inetd (или xinetd) съест все ресурсы своим поиском и запуском сервисов. Таким образом, увеличивается вероятность удачного проведения DoS атаки со стороны хакера.