Безопасность сетевых протоколов

ЗАРАЗА

Спецвыпуск: Хакер, номер #058, стр. 058-084-3

Еще одна менее распространенная атака позволяет просканировать порты самого FTP-сервера. Для этого команда PASV дается множество раз. Разумеется, сервером открываются только те порты, которые были свободны, что позволяет обнаружить "занятые" порты.

Как решаются все этим проблемы? Большинство FTP-серверов пожертвовали возможностью прямой передачи файлов с сервера на сервер и требуют, чтобы соединение на порт данных приходило с того же адреса, что и контрольное соединение. То же касается и команды PORT. Трюк со сканированием портов через PASV во многих серверах еще проходит, хотя кое-где порты открываются в случайном порядке из ограниченного диапазона. Современные файрволы используют технику stateful inspection, при которой "реконструируется" протокол прикладного уровня, а не учитываются данные отдельных пакетов, что устраняет возможность обхода файрволов...

Ну а что же с FTP-клиентом?

Все классические атаки FTP касаются сервера. Дэвид Сейсердот написал, что атака на перехват соединения крайне сложно реализуется для сервера и не реализуется для клиента. К сожалению, статью Дэвида я прочитал значительно позже по рекомендации Aleph One. Но ее не читали и разработчики серверов FTP. Поэтому, когда лет через пять я изобрел велосипед и заново "открыл" эту проблему, все было в первозданном виде. По счастливому стечению обстоятельств и из-за своей природной лени вместо статьи я написал весьма простенькую утилитку ftpspy, которая использовала обычный connection flood и успешно срабатывала с вероятностью более 50% на большинстве живших тогда FTP-серверов.

А также и на FTP-клиентах, только не в пассивном, а в активном режиме. Правда, для атаки на FTP-клиента она требовала, чтобы на той же машине присутствовал FTP-сервер, чтобы иметь возможность "угадать" порт. Если порты назначаются системой подряд, то порт можно угадать и другим способом, например "прогнав" письмо через почтовый сервер. Используя техники Stealth-сканирования, можно наблюдать за достаточно многими портами одновременно.

Подробнее об истории ftpspy можно прочитать на www.security.nnov.ru/articles (кроме исторической ценности из нее не извлечь ничего, так как в основном системы имеют если не безопасные FTP-серверы, то хотя бы защиту от SYN-флуда).

Все перечисленное требует от меня упомянуть проблему обхода брандмауэра через клиент FTP. Заставив клиент загрузить файл с хорошо подогнанным длинным именем с твоего FTP-сервера, можно "подделать" команду PORT и заставить брандмауэр, персональный брандмауэр или NAT с трансляцией портов, защищающий клиента, пробросить TCP-порт на интересующий порт клиента (например 139). IP-адрес, как правило, контролируется, поэтому дальнейшая атака должна проводиться с того же сервера.

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