Комментарии 12
Интересная статья, спасибо.
Никто не против, если расшифрую SSRF — Server-Side Request Forgery. Плохо гуглится)
Только жесткая фильтрация исходящих соединений, только хардкор. Удивительная статья :)
«но это та ситуация, когда лекарство может быть опаснее болезни».
А что в этом такого уж страшного? Многие хостинги (по крайней мере раньше) на самых простых видах услуги это запрещали по дефолту и открывали по запросу на избранные адреса или порты (например для исходящей почты). Да, это может что-то нарушить, но настроить все под нужды конкретного ресурса не квадратура круга. И защиту это даст не только от данного вида атаки.
А что в этом такого уж страшного? Многие хостинги (по крайней мере раньше) на самых простых видах услуги это запрещали по дефолту и открывали по запросу на избранные адреса или порты (например для исходящей почты). Да, это может что-то нарушить, но настроить все под нужды конкретного ресурса не квадратура круга. И защиту это даст не только от данного вида атаки.
Тут дело вот в чем:
— во многих случаях FTP (порт управляющего соединения) так или иначе нужен (например, для обновлений) и закрывать его неудобно.
— ну и 80-й порт наружу вы вряд ли закроете :)
Что уже приведет к потенциальной возможности атаки на любые Web-сервера.
Даже есть 21-й порт закрыт, то можно провести атаку через URI фейковыйфтпсервер:80/file.txt, а фейковый сервер (слушающий на порту 80) вам вернет адресжертвы,80. Кроме того, недостаточно жесткая фильтрация позволяет провести атаки не только на внешние хосты, но и на хосты в DMZ и (в худшем случае) внутренние хосты в сети.
И даже если вы закроете и 80-й порт на выход, то остается еще менее эффективный «лобовой» метод атаки посредством URI адресжертвы: портсервиса, где адресжертвы — это 127.0.0.1 или адрес за DMZ/во внутренней сети.
И вот фильтрация вышеперечисленных атак может доставить немало неудобств в обычном функционировании сети :)
Хотя я с вами согласен, формулировка выглядит излишне пафосно, погорячился :)
— во многих случаях FTP (порт управляющего соединения) так или иначе нужен (например, для обновлений) и закрывать его неудобно.
— ну и 80-й порт наружу вы вряд ли закроете :)
Что уже приведет к потенциальной возможности атаки на любые Web-сервера.
Даже есть 21-й порт закрыт, то можно провести атаку через URI фейковыйфтпсервер:80/file.txt, а фейковый сервер (слушающий на порту 80) вам вернет адресжертвы,80. Кроме того, недостаточно жесткая фильтрация позволяет провести атаки не только на внешние хосты, но и на хосты в DMZ и (в худшем случае) внутренние хосты в сети.
И даже если вы закроете и 80-й порт на выход, то остается еще менее эффективный «лобовой» метод атаки посредством URI адресжертвы: портсервиса, где адресжертвы — это 127.0.0.1 или адрес за DMZ/во внутренней сети.
И вот фильтрация вышеперечисленных атак может доставить немало неудобств в обычном функционировании сети :)
Хотя я с вами согласен, формулировка выглядит излишне пафосно, погорячился :)
Спасибо за комментарий. В целом все так. Просто вспомнился некий опыт относительно давний. И резануло слух. Закрыите 80 порта для исходящих соединений тоже практиковалось и для тьмущей тьмы сайтов-визиток или хомячковых форумов это проблемы не представляло в середие нулевых, а их чаще всего и ломали для подобных целей (незабвенная радость всех скрипткидди — пхпбб). А для кого представляло, те не сидели на виртуальном хостинге. Хотя сейчас да, понаворачивали всякого и наверное так не делают :)
Типичный пример подобного условия в те годы support.demos.ru/archive/hosting/faq.php?SECTION_ID=121
«Скрипт получает ответы от других web-серверов. Возвращается ошибка '400 Bad request'.
В целях безопасности, на стандартном хостинге запрещены исходящие соединения и открываются только по запросу клиента, с указанием адреса ресурса к которому нужен доступ. Другим решением, в данной ситуации, может послужить использование услуги Виртуальный сервер VPS, где подобных ограничений нет.»
Типичный пример подобного условия в те годы support.demos.ru/archive/hosting/faq.php?SECTION_ID=121
«Скрипт получает ответы от других web-серверов. Возвращается ошибка '400 Bad request'.
В целях безопасности, на стандартном хостинге запрещены исходящие соединения и открываются только по запросу клиента, с указанием адреса ресурса к которому нужен доступ. Другим решением, в данной ситуации, может послужить использование услуги Виртуальный сервер VPS, где подобных ограничений нет.»
Ну тут речь идет не о сайтах-визитках на VPS, в них вероятность обнаружить SSRF очень мала. :) А вот любой мало-мальски средний/крупный проект стоит хотя бы на выделенном сервере, и там вероятность закрытия 80-го порта будет поменьше. По факту, как я уже писал в статье, лучшим способом предотвращения такого типа атак будет полный отказ от команды PASV (и замена её на корректную реализацию EPSV) в библиотеках соответствующих Web-фреймворков и языков.
Я ведь не утверждаю, что закрывали 80 порт из-за SSRF. Всякие там дырявые пхпбб или мамбы, которые владельцы никогда не обновляли и не будут можно использовать (и использовали) гораздо тривиальней, заливали туда скрипты и флудили и спамили ими без всяких извратов. Поэтому мера была очень жизненная, а не надуманная.
И кстать, «полный отказ от команды PASV » можно реализовать опять же не затрагивая библиотеки и прочий софт. На том же линуксе можно совершенно буюджетно зафильтровать иптаблесом символьную последовательность команды. Это может и кривовато выглядит, но действенно. Как и 80 порт можно блокировать не вообще, а для соотв. uid/gid что бы немного погибче было и тот же админ мог при необходимости в консоли юзать wget или менеджер пакетов что-то обновлять из сети.
Могу еще заметить и про ДМЗ. Я занимаюсь некоей корпоративной сеткой, в которой сама сетевая инфраструктура в моих руках, а вот серверная лишь отчасти и подчиняется всяким политикам вышестоящих корп. структур и рукам чужих серверных админов. Так я даже для внутренних, не публичных серверных сегментов ЛВС фильтрую исходящие коннекты в пользовательские или, где возможно и в другие серверные сегменты. Это не так гемморно и страшно, как кажется. Зато в нашей ветвистой организации мы из тех немногих, кто не личился от кидо в начале 2009, хотя с АВЗ было все не очень хорошо. Другие же заражались пошаговым принципом на ура (кого пугали трудности сетевой фильтрации). Сетевая фильтрация конечно не панацея, но не последний кирпичик в общем здании безопасности. Иногда (увы) — один из немногих вообще возможных.
Просто не все такие хорошие и педантичные администраторы, как вы :) Это раз.
Во вторых, в условиях бизнес-приложений, очень трудно не оставить открытым хотя бы один порт. Обновления, бизнес-взаимодействия, различные API, сервисы и RPC… А уже хотя бы один открытый порт оставляет возможность для атаки (через него можно подключиться на фейковый FTP-сервер). А атаковать можно и внутренние сервисы внутри сети. И здесь к сетевой фильтрации подключается фильтрация уже на уровне контекста протокола, и настройка всего это в большой корпорации может быть действительно опасно для самой инфраструктуры. Хотя, вы правы, если все делать педантично и аккуратно, то защититься от релеинга атак (кроме как на самого себя) — вполне возможно. Но идеальных сетей к сожалению очень мало в этом мире :(.
Во вторых, в условиях бизнес-приложений, очень трудно не оставить открытым хотя бы один порт. Обновления, бизнес-взаимодействия, различные API, сервисы и RPC… А уже хотя бы один открытый порт оставляет возможность для атаки (через него можно подключиться на фейковый FTP-сервер). А атаковать можно и внутренние сервисы внутри сети. И здесь к сетевой фильтрации подключается фильтрация уже на уровне контекста протокола, и настройка всего это в большой корпорации может быть действительно опасно для самой инфраструктуры. Хотя, вы правы, если все делать педантично и аккуратно, то защититься от релеинга атак (кроме как на самого себя) — вполне возможно. Но идеальных сетей к сожалению очень мало в этом мире :(.
Думаю правильным способом должно бы запретить на уровне приложения соединения по сторонним адресам из вьюшек страниц. На уровне контролеров контроль протокола и разрешонных для связи хостов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
SSRF DoS Relaying