Комментарии 14
Принцип работы анализатора пакета в том, что он получает весь трафик, приходящий на указанный пользователем сетевой интерфейс, исключая трафик, отфильтрованный межсетевым экраном
Вообще-то в случае оговоренного в статье линукса, самая популярная библиотека - libpcap - выхватывает пакеты до оговоренного же в статье nftables. Так что видно будет абсолютно всё, неважно что вы там в nftables делаете.
В продуктивной системе не должно быть приложений или библиотек, позволяющих проводить захват пакетов
Что совершенно не мешает злоумышленнику просто припереть с собой свою собственную libpcap. Или вообще статически слинкованный бинарник со всем нужным на борту. Так что совет вроде и здравый, но в реальности абсолютно бессмысленный.
Вообще-то в случае оговоренного в статье линукса, самая популярная библиотека - libpcap - выхватывает пакеты до оговоренного же в статье nftables. Так что видно будет абсолютно всё, неважно что вы там в nftables делаете.
В моих тестах дефолтных debian tcpdump не фидел фильтрованный трафик. Да и к тому же это только в статье рассматривается локальный netfilter. Эти же способы могут использоваться и для обхода шлюзовых FW. Разве что какой-нибудь особо умный NGFW сможет что-то сделать.
Многие скажут, ну раз «root», то это не интересно, ведь хакер может делать с сервером всё, что захочет.
И да, и нет.
В первом приближении, действительно, можно сделать что угодно. И в этом случае открытие параллельного сокета выглядит слишком проблемным для реальной эксплуатации вариантом. Даже в демонстрации эксплуатации видно, что часть трафика уходит в nginx. Который явно запишет его в какой-нибудь domain.tld-error.log. Т.е. надо ещё и логи как-то подчищать. Которые вполне могут просто уходить на другую машину. Поэтому куда логичнее просто сделать прокси на порту.
Во втором - netfilter умеет в фильтрацию по UID/GID. Конечно, наличие root доступа и тут поможет, но придётся заглянуть как минимум в конфиг firewall.
Ну и для того, чтобы жить было веселее, у нас есть selinux и аналоги, с помощью которых root'а можно и ограничить.
Для защиты от кражи сокетов необходимо настраивать серверные приложения в стандартный режим монопольного использования сетевых портов. На использование опций SO_REUSEPORT или SO_REUSEADDR для серверных сокетов следует наложить табу.
Многопоточные/многопроцессные приложения, которым это необходимо, при этом как себя поведут? Так же предлагаю вам дополнить статью конкретным примером, как это можно сделать :)
дочитал до момента когда хаккер уже рут и прекратил. далее все не имеет смысла
Ну просто статья "Фаервол не поможет если вас ломанули и получили рута" выглядит менее интригующий
Хакер - это не только некая личность в Интернете. Это может быть и уволившейся админ, доступ которому заблокировали не сразу. Не исключено, что подобный товарищь мог оставить себе лазейку, чтоб вернуться обратно, особенно если на сервере есть что-то ценное.
Поэтому основной смысл статьи в том, чтобы расскзать куда нужно смотреть, чтобы "точно" закрыть все форточки, а не ограничиваться банальной блокировкой учеток и выявлением активности reverse shell.
Мы будем исходить из того, что сервер уже взломан, и хакер повысил свои полномочия до «root».
А давайте сразу договоримся, что зловредный хакер получил физический доступ к серверу, убил Админа и сидит на стуле за клавой этого сервера. :)
На windows ещё очень давно, помню такую тулзу WPE PRO, вот она прекрасно работала с перехватом сокета процесса любого, с возможностью как мониторить входящие пакеты так и дублировать/создавать новые исходящие.
Просьба дописать статью рассказом, где все-таки будет показано как метод обходит какой-то из реальных Firewall от Palo Alto Networks, Fortinet или других поставщиков.
Опыт с nftables не подходит, потому что этот firewall не проверяет трафик приложений идущих по порту. Такие типы firewall давно не используются в компаниях, где высокий уровень зрелости службы информационной безопасности.
Под межсетевыми экранами Palo Alto или Fortinet вы скорее всего понимаете устройства с анализом трафика приложений, так называемые NGFW. Писать про них не буду, так как у меня под рукой их нет, а также из-за того, что производители очень не любят отрицательные отзывы о своей продукции.
У меня был практический опыт тестирования подобного оборудования, и оно из 6 тестов, осуществленных с помощью дефолтного Kali Linux смогло отловить только 0.5 атаки. После этого был conf-call с производителем, где настоятельно просили не раскрывать результаты тестов. Но это так, лирика.
Возвращаясь к вашему вопросу, в статье есть все исходники, и любой желающий может провести тесты самостоятельно. Если NGFW обладает должным функционалом и нормально настроен, то приведенные примеры скорее всего работать не будут, так как они специально написаны таким образом, чтобы демонстрировать проблему, а не быть готовыми эксплойтами. НО для специалистов переделать их, чтобы пробивать NGFW, не составит больших проблем. Достаточно будет только понять, по каким критериям устройство классифицирует трафик, и подделать сообщение таким образом, чтобы он был похож на легитимный для FW трафик. В статье реализован blind shell, а для того, чтобы он сработал, достаточно, чтобы FW пропустил всего одно сообщение прикладного уровня. Классифицировать трафик по одному сообщению можно разве что путем анализа синтаксиса.
Основная часть статьи сосредоточена на вопросе запуска двух сервисов на одном сокете. В результате, часть сетевых пакетов будут отправляться к одному сервису, а часть – ко второму. Если между веб-клиентом и веб-сервером происходит множество взаимодействий, это может быть заметным – например, половина изображений может не загрузиться.
Если у вас есть доступ к серверу, все исходящие подключения разрешены, и вам необходимо удалённо выполнять команды, вы можете легко создать обратный SSH-туннель, и всё)
Что касается обхода МЭ (нужно считать, что он все таки внешний), можно дополнительно усилить правила, например, полностью запретив исходящие подключения (кроме к доверенным IP-адресам). Однако, имея доступ к серверу, злоумышленник может перехватывать сетевые пакеты через libcap или XDP.
Поскольку разрешенный трафик и трафик злоумышленника будут схожи на транспортном уровне, то МЭ с правилами по портам и статусу соединения будет уже неэффективен; необходимо внедрять более сложные решения, работающие на уровне приложений, например WAF.
Основная часть статьи сосредоточена на вопросе запуска двух сервисов на одном сокете. В результате, часть сетевых пакетов будут отправляться к одному сервису, а часть – ко второму. Если между веб-клиентом и веб-сервером происходит множество взаимодействий, это может быть заметным – например, половина изображений может не загрузиться.
Да, именно так, и это является демаскирующим признаком.
НО RAT может быть написан таким образом, чтобы отдавать нецелевой трафик обратно основному процессу, под который он маскируется и тогда эта проблема решится.
Касательно защиты, то NGFW частично может помочь, но только частично. Без организации комплексной безопасности узла (замкнутая программная среда, контроль использования ресурсов и т.д.) все усилия тщетны.
Firewall не спасёт