Глава 6. Проблемы безопасности некоторых сетевых протоколах «первого» поколения и некоторых базовых «инфраструктурных» протоколов
Во времена разработки первых протоколов семейства TCP/IP аспекты безопасности были не самыми приоритетными и определяющими. Практически все, без исключения, протоколы, которые можно условно отнести к «первому» поколению, не обеспечивают конфиденциальности и целостности передаваемых данных. Например, в разделяемой среде ранних версий сети Ethernet злоумышленник мог без особых проблем перехватить абсолютно любые передаваемые данные, имена, пароли. Некоторым оправданием довольно пренебрежительного отношения к проблемам безопасности может служить, среди прочего, невысокая производительность тогдашних массовых процессоров, малые объёмы доступной компьютерам памяти – криптографические алгоритмы, как элементы обеспечения безопасности, при работе потребляют значительные системные ресурсы, особенно это касается алгоритмов с публичным ключом. Со временем росли и развивались возможности сетевых устройств, обеспечивающих работу локальных и глобальных сетей, что положительно влияло на безопасность коммуникаций. К примеру, переход от разделяемой среды передачи к коммутируемому Ethernet-у существенно затруднил возможность перехвата и модификации трафика в локальной сети, хотя и не устранил её полностью.
Можно обозначить несколько направлений, по которым двигались разработчики средств обеспечения безопасности:
-
Доработка существующих протоколов, включение в их состав дополнительных средств. В качестве примера можно назвать технологию однократного пароля (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 (File Transfer Protocol) – протокол для передачи файлов, один из старейших в семействе TCP, активно используется и сегодня, несмотря на значительные изъяны как в общем дизайне, так и в обеспечении безопасности. Все без исключения современные браузеры поддерживают работу по протоколу 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 сервера, для передачи данных.
Рис.92 Работа FTP в пассивном режиме
Активный FTP удобнее для администратора FTP-сервера, но неудобен для администратора с клиентской стороны, т.к. FTP-сервер будет пытаться установить соединение на случайные порты >1024 на стороне клиента, что почти наверняка будет заблокировано клиентским МСЭ. Пассивный FTP предпочтительнее для клиента, но неудобен администратору со стороны FTP-сервера. Оба соединения к серверу инициирует клиент, но одно из них будет идти на порт со случайным номером >1024 (неизвестный заранее), что вызовет очевидные проблемы в настройке безопасности МСЭ со стороны сервера.
Решение «прохождения» 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.
Достарыңызбен бөлісу: |