Включение безопасного доступа по FTP через брандмауэры ISA 2006 (часть 1)

Эта статья была отредактирована доктором Томасом Шиндером.

ПРЕДУПРЕЖДЕНИЕ:
Официально брандмауэр ISA не поддерживает протокол FTPS, поскольку переговоры по протоколу зашифрованы, и, таким образом, никакие фильтры приложений не могут обрабатывать эти согласования. В этой серии статей представлен жизнеспособный обходной путь. Однако побочным эффектом метода, описанного в этих статьях, является то, что никакие незашифрованные (FTP) соединения работать не будут. Альтернативой нашему решению является создание пользовательского определения протокола сервера для FTPS, а затем использование метода Песаха Шелница для предотвращения конфликтов с определением протокола сервера FTP по умолчанию.

Введение

Одной из важных новых функций, включенных в IIS 7.0 (которая входит в состав Windows Server 2008), является безопасный FTP. Безопасный FTP использует шифрование TLS для защиты данных, перемещаемых по каналу данных FTP. Это большой шаг вперед по сравнению с предыдущими версиями службы FTP IIS, которые поддерживали только незашифрованные соединения.

На рисунке ниже показан интерфейс IIS 7.0 для настройки защищенной службы FTP IIS 7.0.

фигура 1

Однако, если вы когда-нибудь пытались опубликовать FTP-службу IIS 7.0 через брандмауэр ISA, вы могли заметить, что все работает не совсем так, как вы хотели. На самом деле вы столкнетесь со страшной ошибкой 500 Access Denied.

На рисунке ниже показана ошибка в FTP-клиенте при попытке подключения к опубликованному защищенному FTP-серверу.

фигура 2

Давайте теперь рассмотрим, в чем проблема, и посмотрим, есть ли способ ее решить. Для того, чтобы полностью понять, что происходит, вам потребуется следующее:

• Сниффер на FTP-клиенте
• Мониторинг в системе ISA-сервера
• Сниффер на FTP-сервере

Наша тестовая установка выглядит так:

FTP-клиент <===> ISA 2006 <===> Win2k8 (IIS7/FTP7)

Рисунок 3

Шаг 1:

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

1.1 просмотр пакетов

Рисунок 4

Как видите, FTP-клиент проходит рукопожатие TCP в первых 3-х пакетах (SYN/SYN ACK/ACK). После того, как TCP-квитирование завершено, начинается фактическая FTP-связь. Первая команда FTP — это сервер, идентифицирующий себя как сервер MS FTP.

Затем клиент отвечает на это, говоря AUTH TLS. Клиент в основном говорит: «Привет, дружественный FTP-сервер, я хотел бы начать зашифрованный сеанс TLS». Клиент делает это дважды, но получает от сервера ответы ACCESS IS DENIED.

Когда вы смотрите на пакеты FTP-сервера, вы можете увидеть первые 3 пакета рукопожатия, затем один пакет, в котором сервер идентифицирует себя, но мы никогда не видим другого FTP-пакета, поступающего на FTP-сервер с сеансом AUTH TLS.

Рисунок 5

1.2 Следить за просмотром

Если мы посмотрим на представление TCP Follow, мы можем ясно увидеть, что клиент отправляет Auth SSL, а сервер никогда не получает эти пакеты.

Рисунок 6

Шаг 2:

Приведенная выше информация ясно показывает, что ответ 550 Отказано в доступе, который отправляется FTP-клиенту. Однако, что может быть не так очевидно, что ответ был сгенерирован не FTP-сервером! FTP-сервер должен иметь возможность принять запрос на согласование безопасного соединения TLS. Так в чем проблема? Очевидно, посередине есть устройство, которое генерирует этот ответ и отправляет его обратно клиенту.

Используя эту информацию, давайте посмотрим на лог-файлы брандмауэра ISA и посмотрим, есть ли у нас запреты на этом уровне. На рисунке ниже показаны соответствующие записи журнала.

Рисунок 7

На первый взгляд кажется, что трафик идет нормально, мы видим, что ISA принимает первый пакет, а затем закрывает соединение, как если бы это было обычное завершенное соединение TCP.

Откуда исходит этот ответ об отказе в доступе? Чтобы узнать немного больше, нам нужно добавить дополнительный столбец в окно просмотра журнала ISA, который называется кодом результата.

Рисунок 8

Как только мы добавим этот столбец, мы сможем увидеть полную информацию о том, что делает брандмауэр ISA.

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

FWX_E_CONNECTION_KILLED => 0x80074E24 => ISA Server разорвал соединение.

Несмотря на то, что такое завершение не является чем-то необычным, кажется, что брандмауэр ISA принял активное участие в завершении сеанса, и мы знаем, что единственным местом, откуда мог прийти пакет 550 Access is denied, был брандмауэр ISA.

На этом этапе нам нужно рассмотреть, какой компонент брандмауэра ISA прерывает соединение. Для начала стоит поискать фильтр приложений, который обрабатывает FTP-соединения. Как вы, возможно, знаете, брандмауэр ISA — это брандмауэр с отслеживанием состояния пакетов и инспекцией прикладного уровня, что позволяет ему выполнять инспекцию прикладного уровня для любого количества протоколов прикладного уровня. Одним из таких протоколов является FTP. Вы можете просмотреть это в узле надстроек на левой панели консоли брандмауэра ISA.

Рисунок 9

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

Например, фильтр SMTP позволяет добавлять и удалять команды, принимаемые брандмауэром. К сожалению, фильтр FTP этого не делает. Все, что вы можете сделать, это включить или отключить его. Вы можете отключить фильтр здесь и полностью отключить фильтр для всех правил брандмауэра ISA, или вы можете сделать это для каждого правила отдельно. Позже мы покажем вам, как отключить is для отдельных правил.

Рисунок 10

Простой факт заключается в том, что фильтр приложений FTP в ISA 2006 не поддерживает AUTH TLS, и, таким образом, по умолчанию ответ брандмауэра ISA на такой запрос — отказ в доступе. Брандмауэр ISA ожидает поток команд FTP по умолчанию, как показано на рисунке ниже, и мы не можем добавить принятые команды.

Примечание:
В ответе не сказано: фильтруется ISA 2006, так как это может дать потенциальным хакерам информацию, которую им знать не нужно.

Рисунок 11

Единственный способ решить эту проблему в ISA 2006 — отключить фильтр приложений FTP в правиле доступа. Откройте диалоговое окно «Свойства» для правила доступа для правила публикации FTP-сервера, перейдите на вкладку «Трафик » и снимите флажок «Фильтр доступа к FTP» в рамке «Фильтры приложений », как показано на рисунке ниже.

Рисунок 12

Если теперь мы повторим наше соединение и перехватим трафик на FTP-сервере, мы увидим первый пакет со строкой идентификации, второй пакет — это сообщение FTP-клиента; «Привет, я хочу выполнить аутентификацию TLS». Третий пакет — это сервер, который отвечает и говорит «ок, давайте сделаем TLS», и оттуда поток переходит в зашифрованный режим.

Рисунок 13

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

Резюме

В этой статье мы продемонстрировали проблему с защищенной публикацией на FTP-сервере с использованием брандмауэра ISA 2006. Используя сетевые снифферы, мы говорим, что попытка согласования TLS со стороны клиента была отклонена, но она не была отклонена опубликованным FTP-сервером. Вместо этого мы увидели, что попытка согласования безопасности была отклонена брандмауэром ISA. Брандмауэр ISA имеет фильтр прикладного уровня FTP для поддержки FTP-соединений, но он не настраивается (в отличие от SMTP-фильтра, который допускает некоторый уровень настройки). Поскольку встроенный фильтр прикладного уровня FTP в брандмауэре ISA не поддерживает согласование TLS, вам необходимо отключить фильтр прикладного уровня FTP либо для всего набора правил, либо для определенных правил. Мы предпочитаем отключать фильтр FTP для определенных правил, поскольку клиенты SecureNAT не смогут использовать протокол FTP для исходящего доступа, если фильтр отключен глобально. После отключения фильтра FTP-приложений мы продемонстрировали, что безопасное FTP-соединение было успешно установлено через брандмауэр ISA к опубликованному безопасному FTP-серверу IIS 7.0. Однако есть еще один шаг — пока мы включили безопасное FTP-соединение, мы еще не включили безопасную передачу данных по каналу. Во второй части этой серии мы рассмотрим, что вам нужно сделать, чтобы включить передачу данных по защищенной ссылке FTP.