На самом деле да :) Это «интервью», вкупе с последующим через пару дней в другой компании, когда меня «унижали студенты», спрашивая про частные случаи в конкретной технологии, вогнало меня в состояние «грогги» и последующие пару месяцев я просто не искал работу :). Это оказалось кстати, так как в итоге я попал в Digital Security, чему очень рад.
Довольно истеричного вида HR-менеджер заявила, когда спустилась на проходную, что я её отвлек от важных переговоров, и в услугах работников, которые не способны подойти к назначенному времени, они не нуждаются. Самое быстрое интервью из всех возможных :)
Самое забавное заключается в том, что сколько таких примеров не приводи, куча народу все равно сами пытаются реализовывать криптографические системы, при этом экономя на специалистах на криптографии.
А пример отличный, огромное спасибо за доступный язык и терминологию, буду кидать ссылку на эту статью людям «сами-с-усами-в-крипто». ;)
С точки получения реальных навыков аудита/пентеста, ИМХО, OSCP/OSCE будут гораздо полезнее, так как там основная часть курсов не просто общие слова, а занятия по взлому машин в виртуальной лаборатории.
Просто не все такие хорошие и педантичные администраторы, как вы :) Это раз.
Во вторых, в условиях бизнес-приложений, очень трудно не оставить открытым хотя бы один порт. Обновления, бизнес-взаимодействия, различные API, сервисы и RPC… А уже хотя бы один открытый порт оставляет возможность для атаки (через него можно подключиться на фейковый FTP-сервер). А атаковать можно и внутренние сервисы внутри сети. И здесь к сетевой фильтрации подключается фильтрация уже на уровне контекста протокола, и настройка всего это в большой корпорации может быть действительно опасно для самой инфраструктуры. Хотя, вы правы, если все делать педантично и аккуратно, то защититься от релеинга атак (кроме как на самого себя) — вполне возможно. Но идеальных сетей к сожалению очень мало в этом мире :(.
Ну тут речь идет не о сайтах-визитках на VPS, в них вероятность обнаружить SSRF очень мала. :) А вот любой мало-мальски средний/крупный проект стоит хотя бы на выделенном сервере, и там вероятность закрытия 80-го порта будет поменьше. По факту, как я уже писал в статье, лучшим способом предотвращения такого типа атак будет полный отказ от команды PASV (и замена её на корректную реализацию EPSV) в библиотеках соответствующих Web-фреймворков и языков.
Тут дело вот в чем:
— во многих случаях FTP (порт управляющего соединения) так или иначе нужен (например, для обновлений) и закрывать его неудобно.
— ну и 80-й порт наружу вы вряд ли закроете :)
Что уже приведет к потенциальной возможности атаки на любые Web-сервера.
Даже есть 21-й порт закрыт, то можно провести атаку через URI фейковыйфтпсервер:80/file.txt, а фейковый сервер (слушающий на порту 80) вам вернет адресжертвы,80. Кроме того, недостаточно жесткая фильтрация позволяет провести атаки не только на внешние хосты, но и на хосты в DMZ и (в худшем случае) внутренние хосты в сети.
И даже если вы закроете и 80-й порт на выход, то остается еще менее эффективный «лобовой» метод атаки посредством URI адресжертвы: портсервиса, где адресжертвы — это 127.0.0.1 или адрес за DMZ/во внутренней сети.
И вот фильтрация вышеперечисленных атак может доставить немало неудобств в обычном функционировании сети :)
Хотя я с вами согласен, формулировка выглядит излишне пафосно, погорячился :)
А пример отличный, огромное спасибо за доступный язык и терминологию, буду кидать ссылку на эту статью людям «сами-с-усами-в-крипто». ;)
Во вторых, в условиях бизнес-приложений, очень трудно не оставить открытым хотя бы один порт. Обновления, бизнес-взаимодействия, различные API, сервисы и RPC… А уже хотя бы один открытый порт оставляет возможность для атаки (через него можно подключиться на фейковый FTP-сервер). А атаковать можно и внутренние сервисы внутри сети. И здесь к сетевой фильтрации подключается фильтрация уже на уровне контекста протокола, и настройка всего это в большой корпорации может быть действительно опасно для самой инфраструктуры. Хотя, вы правы, если все делать педантично и аккуратно, то защититься от релеинга атак (кроме как на самого себя) — вполне возможно. Но идеальных сетей к сожалению очень мало в этом мире :(.
— во многих случаях FTP (порт управляющего соединения) так или иначе нужен (например, для обновлений) и закрывать его неудобно.
— ну и 80-й порт наружу вы вряд ли закроете :)
Что уже приведет к потенциальной возможности атаки на любые Web-сервера.
Даже есть 21-й порт закрыт, то можно провести атаку через URI фейковыйфтпсервер:80/file.txt, а фейковый сервер (слушающий на порту 80) вам вернет адресжертвы,80. Кроме того, недостаточно жесткая фильтрация позволяет провести атаки не только на внешние хосты, но и на хосты в DMZ и (в худшем случае) внутренние хосты в сети.
И даже если вы закроете и 80-й порт на выход, то остается еще менее эффективный «лобовой» метод атаки посредством URI адресжертвы: портсервиса, где адресжертвы — это 127.0.0.1 или адрес за DMZ/во внутренней сети.
И вот фильтрация вышеперечисленных атак может доставить немало неудобств в обычном функционировании сети :)
Хотя я с вами согласен, формулировка выглядит излишне пафосно, погорячился :)