Обратите внимание, что для протокола 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. Эта возможность есть на большинстве почтовых сервисов, и вам она должна быть знакома на практике.
5.3. Протокол SSH
Мы уже говорили о том, что протокол Telnet не очень хорошо подходит для удаленного управления сервером, потому что далеко не безопасен. А желание и потребность в этом есть. В больших сетях, как правило, используются несколько серверов, и бегать от одного монитора к другому накладно и неудобно. Любой администратор хочет сидеть за одним компьютером и управлять всем комплексом одновременно, и при этом по безопасным каналам связи.
Во время таких сеансов администратор передает по сети много конфиденциальной информации (например, пароли root), которая ни в коем случае не должна быть видна прослушивающим утилитам. Для обеспечения безопасной связи создано множество различных программ, но самой популярной стала SSH, которая сейчас поставляется в большинстве дистрибутивов Linux.
Теперь вы можете спокойно управлять своей сетью, удаленно подключаться к серверам, и нет необходимости на каждом из них держать мониторы. У меня сделано именно так (экономия на железе), и есть только один дежурный монитор, который я могу подсоединить к любому системнику, если надо решать проблему не по сети.
Преимущество SSH заключается в том, что этот протокол позволяет удаленно выполнять команды, но при этом требует аутентификацию и шифрует канал связи. Важным моментом является то, что даже пароли при проверке подлинности пользователя передаются в зашифрованном виде.
На данный момент существуют две версии протокола SSH с номерами 1 и 2. Вторая версия использует более стойкий алгоритм шифрования и исправляет некоторые ошибки предыдущей версии. В Linux на данный момент поддерживаются обе версии.
Итак, в ОС Linux за протокол SSH отвечает программа OpenSSH. для которой родной платформой можно считать другую Unix-систему — OpenBSD, а впоследствии сервис клонировался на все Unix-платформы, в том числе и в Linux. Но даже сейчас в конфигурационных файлах можно иногда увидеть в комментариях имя OpenBSD.
Протокол SSH требует для работы настройки серверной и клиентской частей. Сервер ожидает подключения и выполняет директивы пользователя, а с помощью клиента вы осуществляете соединение с сервером и посылаете запросы на выполнение команд. Таким образом, для нормальной работы вы должны правильно сконфигурировать обе части протокола.
5.3.1. Конфигурационные файлы
Все настроечные файлы протокола SSH находятся в директории /etc/ssh. Здесь можно увидеть следующий перечень: