Глава 6. Проблемы безопасности некоторых сетевых протоколах «первого» поколения и некоторых базовых «инфраструктурных» протоколов

Глава 6. Проблемы безопасности некоторых сетевых протоколах «первого» поколения и некоторых базовых «инфраструктурных» протоколов

Можно обозначить несколько направлений, по которым двигались разработчики средств обеспечения безопасности:

• 
  Доработка существующих протоколов, включение в их состав дополнительных средств. В качестве примера можно назвать технологию однократного пароля (OTP), описанную ранее. Она могла быть использована с протоколами telnet, ftp, придавая им устойчивость к перехвату паролей. Но при этом OTP не обеспечивал конфиденциальность и целостность передаваемых данных для указанных протоколов.
  
• 
  Использование технологий VPN, шифрованного туннелирования, шифрование на транспортном уровне. Например, открытое небезопасное соединение удалённого подключения по протоколу VNC может быть пущено по защищённому SSH TCP-туннелю, который установлен между той же парой клиент-сервер (в этом случае данные, «выходя» из туннеля на сервере, «входят» в тот же самый узел, не покидая его пределов). Как пример защиты на канальном уровне можно назвать SSL-версии протоколов POP3 (POP3S), IMAP (IMAPS), FTP (FTPS), HTTP (HTTPS) и др.
  
• 
  Разработка новых протоколов, заменяющих небезопасные старые. Канонический пример – протокол SSH, пришедший на смену telnet и rlogin. Для передачи файлов на базе SSH разработан протокол SFTP (кроме общей возможности – передачи файлов – SFTP совершенно не похож на FTPS (ftp over ssl)).
  

К сожалению, существуют случаи, когда ни один из вышеперечисленных вариантов не подходит, например, когда речь идёт о старом сетевом оборудовании. Старые коммутаторы Cisco Catalyst семейства 2900/3500 для управления используют исключительно небезопасные виды протоколов: telnet, snmp v1/2c, http. Добавить туда криптографическую поддержку для реализации ssh, https, snmp v3 не позволяют малые ресурсы процессора и памяти в данных устройствах. Единственный кардинальный вариант в такой ситуации – «внеполосное» (out-of-band) управление.

Проблемы протокола FTP

Неприятности, связанные с дизайном протокола FTP, во многом объясняются некоторыми довольно редкими и странными решениями, выбранными его разработчиками. Одно из них – использование двух отдельных TCP-соединений, одного для передачи команд, второго – для передачи данных. В сочетании с двумя возможными режимами (модами) работы – активным и пассивным – это приводит к проблемам передачи данных по протоколу FTP через МСЭ и NAT.

В активной моде FTP клиент устанавливает соединение от своего случайного непривилегированного порта (N > 1024) к «командному» порту 21 FTP-сервера. Затем клиент начинает «слушать» порт N+1 и посылает серверу FTP-команду PORT N+1. После чего сервер инициирует соединение со своего порта 20 на клиентский N+1 порт.


Рис.91 Работа FTP в активном режиме
Основная проблема в активной моде состоит в том, что второе соединение для передачи данных инициирует не клиент, а сервер («навстречу»), что приводит к очевидным проблемам с точки зрения настроек МСЭ, защищающего клиентский узел. Возможным решением может быть пассивная мода FTP.

В пассивной моде FTP оба соединения инициирует клиент, тем самым решая проблему «клиентского» МСЭ. Для установления FTP-соединения, клиент выбирает у себя два локальных случайных непривилегированных порта (N > 1024 и N+1). С первого порта открывается соединение с портом 21 на сервере, но, вместо последующей команды PORT, клиент отправляет серверу команду PASV. В результате чего сервер выбирает со своей стороны случайный непривилегированный порт (P > 1024) и отвечает командой PORT P клиенту. После чего клиент инициирует соединение со своего N+1 порта на порт P сервера, для передачи данных.

Решение «прохождения» FTP через NAT и МСЭ имеет разные варианты. Первый заключается в том, что FTP-клиент и FTP-сервер используют команду PASV, которая вызывает соединение для передачи данных, установливаемое от клиента к серверу (использование пассивного режима). Второй подход – изменение для NAT значений команды PORT с помощью шлюза на прикладном уровне (т.е., МСЭ/NAT должен «знать» протокол FTP и «уметь» вмешиваться в протокол прикладного уровня).

Казалось бы, самое простое решение – повсеместный переход на пассивную моду. Сейчас трудно найти сервер, который бы её не поддерживал. Но, как это ни странно, штатный FTP-клиент командной строки самой массовой на сегодня клиентской ОС Windows (включая и Windows 7) не поддерживает работу в пассивном режиме. В списке его команд отсутствует PASV.

Ещё один, кардинальный вариант решения проблем безопасности FTP – переход на новые версии протокола. Существуют как минимум две реализации функционала передачи файлов – FTP over SSL (FTPS) и SFTP (SSH File Transfer Protocol). Ниже приведено их сравнение. Несмотря на очевидные преимущества перед «старым» FTP, безопасные протоколы, его заменившие, не достигли уровня его распространения.

• 
  FTPS
  
  • 
    Преимущества:
    
    • 
      Широко известен и распространён («обычный» ftp поверх ssl).
      
    • 
      Обмен ведётся в текстовом виде, который может быть прочитан и понят человеком.
      
    • 
      Имеет возможность инициировать передачу файлов сервер-сервер.
      
    • 
      SSL/TLS поддерживает отлаженный механизм аутентификации (сертификаты X.509).
      
    • 
      Поддержка FTP и SSL/TLS встроена во многие программные каркасы для разработки.
      
  • 
    Недостатки
    
    • 
      Не обеспечивает единого и общепринятого представления списка файлов директории.
      
    • 
      Требует вторичный канал DATA, что приводит к трудностям при работе через МСЭ.
      
    • 
      Не имеет стандарта для кодирования имён файлов.
      
    • 
      Далеко не все FTP-сервера поддерживают SSL/TLS.
      
    • 
      Не предоставляет стандартного пути для получения и изменения атрибутов файлов и директорий.
      

• 
  SFTP
  
  • 
    Преимущества:
    
    • 
      Имеет отлично стандартизованную базу, определяющую практически все аспекты операций.
      
    • 
      Требует только одно TCP-соединение (не нужно отдельное соединение DATA).
      
    • 
      Соединение всегда безопасно.
      
    • 
      Список файлов унифицирован и удобен для машинной обработки.
      
    • 
      Протокол включает в себя операции по манипулированию разрешениями и атрибутами, управление файловыми блокировками и т.п.
      
  • 
    Недостатки:
    
    • 
      Обмен ведётся в двоичном виде, непригодном для непосредственного понимания человеком.
      
    • 
      Ключи SSH трудно проверять, ими сложно управлять.
      
    • 
      Стандарты определяют некоторые аспекты как необязательные и рекомендованные, что приводит к несовместимости реализаций от разных поставщиков.
      
    • 
      Нет возможности инициировать передачу файлов сервер-сервер и выполнить операцию рекурсивного удаления в директории.
      
    • 
      Нет встроенной поддержки SSH/SFTP для разработчиков в VCL и в .NET frameworks.