Михаил Флёнов - Linux глазами хакера

Рассмотрим пример. Допустим, что пользователь увидел в своей программе FTP-клиент следующее сообщение и не знает, что делать дальше:

331 Anonymous access allowed, send identity (e-mail name) as password.

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

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

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

Допустим, что вы хотите переслать текстовый файл с компьютера Unix на компьютер Windows. В Unix для текстовых файлов в качестве идентификатора конца строки используется символ (Carriage Return, возврат каретки, код 13). В Windows то же самое обозначается двумя символами и (Line Feed, перевод строки, код 10). Если после передачи открыть в Windows этот текстовый файл, то все строки сольются в одну, потому что нет символа .

На рис. 10.2 показан файл sendmail.cf (используется для конфигурации сервиса Sendmail), скаченный с Linux-сервера в бинарном режиме и открытый в программе Windows Notepad. Как видите, очень тяжело разобрать, что здесь и для чего, а вместо перехода на новую строку можно увидеть нечитаемый символ в виде квадрата.

Рис. 10.2. Файл sendmail.cf, полученный с Linux-сервера в бинарном режиме

Чтобы решить проблему конца строки, необходимо скачивать файл с сервера в символьном (ASCII) режиме. В этом случае текст передается построчно, и ОС-получатель сама добавляет нужные символы перевода строки. На рис. 10.3 можно увидеть файл sendmail.cf, полученный с сервера в ASCII- режиме. Теперь информация стала читабельной, и все символы перехода на новую строку расставлены самой ОС верно, в соответствии со своими внутренними правилами.

Рис. 10.3. Файл sendmail.cf, полученный с Linux-сервера в ASCII-режиме

Бинарные файлы (например, картинки или музыку) необходимо передавать в двоичном режиме. Здесь нет различий, в какой ОС создан объект, и он будет правильно воспринят в любой операционной системе, умеющей работать сданным форматом.

Если передать двоичный файл из Linux в Windows в текстовом режиме, то любой символ (а он может встретиться и в двоичном файле) будет заменен на пару символов и , и после этого бинарный файл может стать нечитаемым.

Мы уже говорили о том, что для работы с FTP-сервером необходимо два канала. Порт 21 является командным, и по нему передаются только FTP-команды. Для передачи файлов создается отдельное соединение. Этот процесс можно описать следующим образом:

□ программа-клиент открывает порт на компьютере, куда сервер должен передать содержимое файла;

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

□ сервер инициализирует соединение с компьютером клиента и начинает передачу данных.

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

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

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

В пассивном режиме соединение происходит иначе:

□ клиент запрашивает скачивание или просит принять файл;

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

□ клиент устанавливает соединение с указанным портом, по которому происходит передача данных.

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

По моим наблюдениям самым распространенным FTP-сервером является wu-ftp (Washington University FTP Server), потому что он поставляется вместе с основными дистрибутивами Linux, в том числе Red Hat и его клонами. Если у вас именно такой дистрибутив, то с установкой проблем не будет. Остается только правильно сконфигурировать сервис. Но даже если сейчас в системе нет FTP-сервера, его легко установить из RPM-пакета (для Redhat-систем) или другого архива.

Для конфигурирования FTP в современных дистрибутивах есть графическая утилита kwuftpd. Для ее запуска выберите основное меню KDE, а затем нажмите System/kwuftpd. Главное окно программы вы можете увидеть на рис. 10.4. Но, как всегда, мы будем рассматривать более тонкую настройку через конфигурационные файлы. Разобравшись с этим, вы без проблем сможете настроить свой FTP-сервер и с помощью графической утилиты kwuftpd.

Рис. 10.4. Главное окно программы kwuftpd

Итак, конфигурация FTP-сервера содержится в шести файлах:

□ ftpaccess — определяются права доступа к серверу, круг пользователей FTP и основные настройки безопасности;

□ ftpservers — описываются виртуальные FTP-серверы;

□ ftpusers — указываются пользователи, которым явно запрещен доступ к FTP-серверу;

□ ftphosts — определяются права доступа к серверу с определенных хостов. Можно как запрещать, так и разрешать доступ;

□ ftpgroups — описываются группы FTP;

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