Комментарии 59
Вот потому я не держу на «боевых» серверах gcc.
Интересно, можно ли как-то заблокировать установку gcc на уровне apt-get, yum, rpm и т. п. А то при получении прав рута через shell и поставить могут.
Лучше заблокировать получение прав рута третьими лицами. А с правами рута все ваши блокировки уже не помогут.
А что значит заблокировать? Если по части su и sudo всё прописано как надо, ssh-логин на рута заблокирован, внешние сетевые сервисы работают от имени других пользователей и в chroot, повышение привилегий хакерскими методами невозможно? Или что-то ещё имеется в виду?
sledopit говорит о том, что если кто-то получил root, то пытаться что блокировать в apt-get/yum/etc уже бессмысленно.
С учетом того, что подобная гадость может быть написана не только на C, придется много чего не держать на серверах. PHP тот же.
Оставить компилятор на сервере, это как рядом с дверью положить фомку :)
… с внутренней стороны.
Если у человека уже есть возможность запустить gcc и то, что он этим gcc скомпилит, то поздно прятать gcc. В конце концов, скомпилить си можно и на другом компе, и перебросить бинарник.
Если у человека уже есть возможность запустить gcc и то, что он этим gcc скомпилит, то поздно прятать gcc. В конце концов, скомпилить си можно и на другом компе, и перебросить бинарник.
Если у двери под ковриком лежит ключик (ПО, которое позволяет передачу управления чужому коду), то абсолютно пофиг, где лежит фомка.
что помешает залить сразу бинарник?
На самом деле, атакующему ничего не стоит выполнить wget и докачать недостающие компоненты.
Просто у меня уже в привычку вошло: после установки и настройки сервера, я запрещаю всем пользователям выполнять любой бинарник. А зайти root'ом, можно только имея физический доступ к машине :)
Просто у меня уже в привычку вошло: после установки и настройки сервера, я запрещаю всем пользователям выполнять любой бинарник. А зайти root'ом, можно только имея физический доступ к машине :)
Кто его знает, ботнеты бывают разные по интеллекту. У моего друга на домашнюю линух-машину проник как-то злобный бот (как потом выяснилось, с завидным упорством перебирал пароли). И проникнув, залил руткит. Бинарником. Тридцатидвухразрядный. На x64 систему. В общем, придя домой, чувак обнаружил тачку в неработоспособном состоянии и разобрался, что же произошло.
А дистр вы бинарный используете? И какой тогда смысл? При шеле на ваш сервак gcc под Ваш дистр выкачивается только в путь. Да и как уже выше писали малвари на том же пхп или питоне море.
У меня вот гента, gcc я держу, вот только пхп для вордпреса у меня в строгом chroot'е и исключительно под своим пользователем, еще можно раздел, который смотрит в веб подключать с noexec. Но опять же, все это не панацея. Панацея — строгие ограничения пыхи (в т.ч. ее пользователя, обязательно отдельного для каждого ресурса) (эх, жалко, что сухозин умер :-( ) и НЕиспользование кривых скриптов.
У меня вот гента, gcc я держу, вот только пхп для вордпреса у меня в строгом chroot'е и исключительно под своим пользователем, еще можно раздел, который смотрит в веб подключать с noexec. Но опять же, все это не панацея. Панацея — строгие ограничения пыхи (в т.ч. ее пользователя, обязательно отдельного для каждого ресурса) (эх, жалко, что сухозин умер :-( ) и НЕиспользование кривых скриптов.
> сухозин умер
Как это умер??? Постоянно его вижу у клиентов. В т.ч. и на свежих дистрибутивных сборках PHP. Жив и работает.
Как это умер??? Постоянно его вижу у клиентов. В т.ч. и на свежих дистрибутивных сборках PHP. Жив и работает.
Последний патч для 5.3.9 версии вышел.
А сейчас актуальная 5.3.22.
Я бы сказал что он скоропостижно скончался.
А сейчас актуальная 5.3.22.
Я бы сказал что он скоропостижно скончался.
В какой максимальной версии php Вы его видели? Мне очень интересно. Не даром мейнтейнеры в генте от него отказались в районе 5.3.13.
Последние изменения расширения suhosin — 19.01.2012 (больше года назад), патча — 23.07.2010 (~2,5 года назад).
Да, штука полезная, его трупик долго пинался мейнтейнеры различных дистрибутивов, но, например, в генте сдались. Подозреваю, пхп ушло слишком далеко вперед. По крайней мере 5.4 точно.
Последние изменения расширения suhosin — 19.01.2012 (больше года назад), патча — 23.07.2010 (~2,5 года назад).
Да, штука полезная, его трупик долго пинался мейнтейнеры различных дистрибутивов, но, например, в генте сдались. Подозреваю, пхп ушло слишком далеко вперед. По крайней мере 5.4 точно.
Не понимаю, если сухозин так полезен почему его до сих пор не включили в PHP? Если его преимущества не очевидны, для чего его включили в PHP ментейнеры Ubuntu? Ну бред же. Так и живем, держу gcc на сервере для сборки 5.3 и да, наличие этого патча критично для проекта.
Потому что сухозин — это не только ценный мех, но и еще 2-3 килограмма разных глюков и несовместимостей. Что-то, наверняка, из него было взято в мейнстрим, остальное было посчитано недостаточно стабильным. Была еще целая история про исключение сухозина из пхп в дебиане. Так как мейнстрим пхп устал разбираться с багами, порождаемыми сухозином, которые репортили в мейнстрим.
Если не секрет, как наличие сухозина может быть критично для проекта?
Если не секрет, как наличие сухозина может быть критично для проекта?
> В какой максимальной версии php Вы его видели?
В 5.3.х. Точные версии не запоминал. Но часто его вижу у клиентов.
В 5.3.х. Точные версии не запоминал. Но часто его вижу у клиентов.
Хм, а не проще запретить выполнение system, exec… От залитого бинарника отсутствие gcc правда не спасет.
tcc хватит ;)
Если на разделе, доступном для записи из скрипта разрешён запуск программ, то это ничем не поможет.
Вот поэтому для любых маломальски серьезных проектов нужно быть как можно больше PCI Compliant. А вордпресс нифига не PCI Compliant, собственно как и куча других поделок.
Я имею ввиду не только поделок на PHP, вроде Джумлы, Вордпресса и прочих гадостей, но и про другие фреймворки на других языках. Как правило для любой платформы есть набор правил и практик, которые помогают снизить риск получить инфаркт.
Да ладно, вордпресс просто более лучше изучен. В этом вашем PCI Compliant софте дырок не меньше (а чаще — значительно больше), просто их никто никогда не ищет за ненадобностью.
Само собой, увидел Wordpress — нужно заявить, что он отстой. А тем временем, черным по белому написано, что косяк в сторонней теме сайта:
/wp-content/themes/newsworld/
То, что с темами нужно быть аккуратными — это и так понятно, и это совсем не проблема Wordpress.
/wp-content/themes/newsworld/
То, что с темами нужно быть аккуратными — это и так понятно, и это совсем не проблема Wordpress.
> и это совсем не проблема Wordpress
На мой взгляд, это отчасти и проблема архитектуры WP, т.к.он допускает такие штуки в темах.
На мой взгляд, это отчасти и проблема архитектуры WP, т.к.он допускает такие штуки в темах.
Сеньор наверное забывает, что темы в WP — это большее, чем просто набор стилей и верстки. Зачастую тема — это дополнительный функционал для CMS итд.
А если бы они там и правда хотели работать в эту сторону — внедрили бы альтернативные темы на каком-нибудь Twig'е, но никому они не нужны будут.
А если бы они там и правда хотели работать в эту сторону — внедрили бы альтернативные темы на каком-нибудь Twig'е, но никому они не нужны будут.
> Сеньор наверное забывает
Это многое объясняет. Я WP только издалека видел, подумалось по аналогии с другим софтом.
Это многое объясняет. Я WP только издалека видел, подумалось по аналогии с другим софтом.
С чего так плохо про твиг?
Его в Drupal 8 его и внедряют как (пока) альтернативный шаблонизатор, Глядишь и меньше станет станет прямых SQL запросов в темах. :)
Его в Drupal 8 его и внедряют как (пока) альтернативный шаблонизатор, Глядишь и меньше станет станет прямых SQL запросов в темах. :)
Совсем не плохо, нет. Просто такие темы не будут особенно популярны для WP, так как тема уже традиционно чуть больше, чем просто оформление.
По идее, в темах вообще никаких запросов не должно быть, как и вообще какой-либо работы с данными. Но т.к. вордпресс это блоговый движок, а из него пытаются сделать всё до интернет магазина, приходится в теме делать большой кусок функционала. Как попало обычно… =)
А если про друпал это было, то уж там sql запросов в теме быть не должно вообще.
А если про друпал это было, то уж там sql запросов в теме быть не должно вообще.
99,9% уязвимостей как бы WordPress, на самом деле уязвимости различных расширений и тем, написанных абы кем и абы как. При том платность тех или иных компонент нисколечки не гарантирует её качество (чаще, пожалуй, даже наоборот).
Еще интересный вид инъекции появился. Это редирект в заголовках:
HTTP/1.1 200 OK
Date: Tue, 29 Jan 2013 17:18:02 GMT
Server: Apache
Refresh: 25; url=«example.com/»
Т.е. кодируем например строку:
$x0b=«header»; $x0b(«Refresh:»25;«url=\»example.com\"");
и вызываем через eval().
В результате сам сайт (HTML,JS и т.д.) чистый, найти такой код очень трудно, антивирусы не реагируют.
HTTP/1.1 200 OK
Date: Tue, 29 Jan 2013 17:18:02 GMT
Server: Apache
Refresh: 25; url=«example.com/»
Т.е. кодируем например строку:
$x0b=«header»; $x0b(«Refresh:»25;«url=\»example.com\"");
и вызываем через eval().
В результате сам сайт (HTML,JS и т.д.) чистый, найти такой код очень трудно, антивирусы не реагируют.
> Согласитесь, весьма необычная реализация.
Не совсем соглашусь. :)
Червь Морриса:
Не совсем соглашусь. :)
Червь Морриса:
The body was a script that created a C program, the ``grappling hook,'' which transfered the rest of the modules from the originiating host, and the commands to link and execute them.via
Я года 4 назад столкнулся с самокомпилирующимся червем, который подобрал пароль ssh (с тех пор легкие пароли и стандартные порты не использую), загрузил в /tmp исходники, собрался и запустился. И через sudo прописался куда-то в район /etc/rc.local. Правда, его удалось голыми руками выкорчевать.
Нестандартные порты отнюдь не панацея — куда полезнее софт следящий за попытками брутфорса.
Да, забыл упомянуть fail2ban. Ну и для совсем параноиков есть вариант отключать авторизацию по паролю и использовать только ключи, тогда обычные боты точно не пробьются.
ИМХО, это не для параноиков, а единственно правильный вариант.
Совсем для параноиков port knocking. А авторизация только по ключам — норма.
Совсем для параноиков это Авторизация по ключу, на нестандартный порт с port knoking!
Зато как здорово кому-то будет, если у вас когда-нибудь сопрут ключ… Сходу mass ownage.
Если предусмотрительно заранее защитить ключ keyword'ом, то mass ownage не предвидится.
Впрочем, никакие автоматические средства не спасут от глупости пользователя. Исключительно соблюдение как минимум элементарных правил информационной безопасности очень здорово снижает подобные риски.
Впрочем, никакие автоматические средства не спасут от глупости пользователя. Исключительно соблюдение как минимум элементарных правил информационной безопасности очень здорово снижает подобные риски.
У меня ключ в eToken-е. Вряд ли сопрут.
видел сервер, куда таким образом были закачаны в исходниках пакеты целиком:
psybnc
unrealircd
ещё какая-то хрень, не разбирался, что это
некоторые зависимости вышеперечисленного (что отсутствовало в системе)
ну, как обычно, были собраны и запущены. Правда, в скриптах rc не было изменений.
psybnc
unrealircd
ещё какая-то хрень, не разбирался, что это
некоторые зависимости вышеперечисленного (что отсутствовало в системе)
ну, как обычно, были собраны и запущены. Правда, в скриптах rc не было изменений.
ClamAV по детекту радует, а вот многие распиаренные победители различных тестов пролетели.
Совсем недавно чистил сервер клиента от вирусов и нашел там не менее интересную штуку.
Залили стандартный шелл, Залили самодельный IRC-бот, прописали к нему кучку скриптов, и по команде «war $host» производилась атака на указанный IP, команда «shell» выполняла любую произвольную команду.
Я попытался зайти на канал, меня сразу же забанили, так как меня не было в белом списке, но получил список пользователей.
На канале было порядка 500 таких же ботов.
Залили стандартный шелл, Залили самодельный IRC-бот, прописали к нему кучку скриптов, и по команде «war $host» производилась атака на указанный IP, команда «shell» выполняла любую произвольную команду.
Я попытался зайти на канал, меня сразу же забанили, так как меня не было в белом списке, но получил список пользователей.
На канале было порядка 500 таких же ботов.
Насчет Си кода в PHP файлах, эта штука появилась еще лет 7-8 назад, тут явно ничего нового нет, еще в r57 первых версий, там кстати есть тоже самое на perl'е. а шеллы могут быть не только на PHP, а например на древней технологии SSI, про которую многие забыли, а она живее всех живых.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пример того, как сервер под управлением *nix может стать частью ботнета