Реален ли риск взлома сайта?

Question

[Ярик Ярик]

Вкратце, есть сервер (centos почти последней версии), на сервере сайт с cms ( wordpress последней версии ). Плагинами вордпресса особо не пользуюсь: только сеошные (вроде AIOSEO) или плагины для кеширования. На сайте нет возможности новым пользователям публиковать свои файлы (картинки или может что-нибудь еще), статьи и другое. По сути только один зарегистрированный пользователь - админ. Все плагины регулярно обновляю. Вопрос: в таких условиях есть вообще риск взлома ? Я пытался найти статьи на тему безопасности, методов взлома сайтов, но на каждом одно и то же: SQL–инъекция, XSS, уязвимости в CMS, в плагинах и бла бла бла... Однако реальных примеров взлома найти не смог.. Второй вопрос, даже просьба получается - кто знает, не мог бы дать ссылку на форум может какой-то, где рассматривают те самые уязвимости, реальные методы.

Answer 1

[Артём Колосов]

Форум - ачат.
Основная уязвимость WordPress - это дырявые плагины.
Нужно понимать, что находясь на хостинге - всегда есть вероятность "подцепить" что-то от соседа, независимо от степени защищенности вашего сайта.

Comments

[Ярик Ярик]

Выделенный сервер, полностью мой. За форум Спасибо !

[Артём Колосов]

Ярик Ярик, банальные анализ сайта/сервера может показать конфигурацию, адреса админ панелей, PMA и пр.
Первое, с чего начнут, вероятно - брутфорс, от него спасёт файрволл.
Далее будет поиск эксплойтов под конкретные версии "комплектующего" вашего сервера и сайта, возможно поможет metasploit
Важно понимать, что уязвимости есть абсолютно везде и оперативно выпускаются патчи, соответственно обновлен = защищен.
Закрыть все ненужные порты
DNS и IP спрятать за cloudflare, но если домен уже успел в архивах засветить реальный IP (т.е. сервер) - уже не спасёт.
Отслеживать изменения файлов.

Векторов атак - десятки, не существует в мире 100% защищенных сайтов)

Линков не найду, но помню, как в Wordpress через медиа можно было грузить исполняемые файлы в виде пикчи, а потом и SVG, которые инклудили шеллы. Но сейчас SVG запретили, как и многие другие форматы) Т.е. с разрешениями тоже необходимо поработать, не уверен, насколько сейчас реальна эта угроза)

[Ярик Ярик]

cerbiz_kolosov, Просто было б интересно посмотреть реальный взлом с действительно хорошей защитой ) Забыл упомянуть то, что сайт с ssl и под cloudflare.

[Артём Колосов]

Ярик Ярик, пальцем тыкать, очевидно, никто не будет в такие проекты)
Клауда - лишь усложняют процесс, но не защищают.
SSL и подавно не способен защитить.
В пример могу лишь привести Rutube, из последнего.
Ситуация стандартная, взломали не "в лоб", взломали используя уязвимость в офисной инфраструктуре, которая работала с сервером.
Прилетает обычно оттуда, откуда не ждёшь) С почтового сервера, например)
Рекомендую вам заказать пентест у профессионалов и ознакомиться с аудитом вашего сайта, так вы получите ответы на все интересующие вас вопросы)

[Артём Колосов]

Ярик Ярик, в 2021 кстати писали про серьезные уязвимости в том же AIOSEO, повышение привелегий (админ права) из под любого юзера и скуля = доступ к БД)
Тут подробности

[Ярик Ярик]

cerbiz_kolosov, Спасибо, буду знать.

[CityCat4]

cerbiz_kolosov, рутуб - типичный пример скверного менеджмента. Он болтался на обочине истории года с лохматого, никому не был нужен. Но тут санкции-херанкции, сникерсы-фигикерсы - оба, и его позиционируют как "русская труба", то есть замена youtube. Очевидно, инфраструктура к этому не была готова. К тому же ломали его целенаправленно, а не просто так.
Очень надеюсь, на рутубе сделали выводы :)

UPD: Почитал про взлом рутуба. Интересно, что после 13 мая все "оналитеги" как-то разом заткнулись :) видимо потому что предполагали, что рутуб вынесли навсегда - а он оказался живее всех живых. И атака, как обычно, проводилась не на сам сайт, а через зараженную флэшку - ну так извини, иранский центр по обогащению урана так сломали, что уж рутуб ;)

Но лучше рутуб конечно же не стал :) Как был обочиной истории - так и остался...

[Артём Колосов]

CityCat4, кто вам сказал, что через флешку? Через окружение же. Более того, об уязвимости известили Group-IB задолго до, но фиксы отложили в долгий ящик)

[CityCat4]

Артём Колосов, Ну я вот уверен, что все в конце концов сведется к флешке. Чем больше коллектив, тем труднее в нем поддерживать дисциплину - сколько ни долби про флешки и письма - всегда найдется один дебил. Атака явно проводилась целенаправленно, уже появилась информация, что закладка, посредством которой был взлом, была установлена еще до начала Донбасской спецоперации - то есть с дальним прицелом.

Ну и чуваков, конечно подвело самомнение. Тот самый тезис "да кому мы нафиг сдались". Да, GIB выдала им рекомендации, говорят некоторые даже успели реализовать, но понять - откуда этот "экспонециальный рост" - тяму не хватило.

Answer 2

[rPman]

Есть относительно универсальный вектор защиты своего веб-хостинга (да и наверное всего)
- это read only хранилище везде где можно (в догонку флаг noexec в маунте диска)
- цифровые подписи файлов
к сожалению php ограничен функционал в этом направлении и поддерживает цифровую подпись только у phar сборок, переделать проект на их использование может оказаться не просто (но не невозможно, в некоторых случаях и вовсе автоматом все будет)
- максимально кастриарованное окружение (спасибо docker часто это так и есть) но все же, для работы сайта может совсем не нужны 99% утилит которые установлены в системе, которые мог бы использовать злоумышленник для запуска своего кода (грубый пример, ты запретил запускать неподписанный код, убил bash но злоумышленник использует awk)
- разделяй на модули все, база данных отдельно от бакэнда, бакэнд отдельно от статичных веб файлов веб сервера и т.п.
спасибо докер народ стал этим пользоваться не задумываясь
- отключай интернет, там где он не нужен, буквально, никакого доступа в интернет бакэнду и веб сервисам не требуется, закрывай все фаерволом или даже отдельными сетями
- нестандартное окружение, даже не так - раздавай фейки, метки версий утилит, отдаваемых как либо в паблик пусть будут неправильными
пример - у тебя linux nginx, а ты в заголовках говори что ты windows apache, у тебя последняя версия wordpress, а ты возвращай версию от 2008 года и т.п. автоматические средства анализа хакеров могут на этом споткнуться, понятно что эта защита не идеальная но сильно уменьшает вероятность успешного обнаружения у тебя дыр.
- мониторинг всего нестандартного, процессы с необычными именами и командными строками, добавь ловушку песочницу, как только код злоумышленника в нее попадет - сигнал или даже остановка сервиса и ручные разбирательства

все это нужно чтобы если атакующий проникнет каким то способом внутрь, дальше что либо сделать он уже не сможет, ведь в первую очередь в атаку идут автоматизированные скрипты - залез, огляделся, сигнализировал об успехе... а как сигнализировать если файловая система ro, интернета нет, а подключение к базе данных не на локалхосте и в конфиг файле оказывается переменные называются по другому.

Comments

[Ярик Ярик]

Честно говоря, не все понял )) , но буду изучать. Спасибо за ответ !

Answer 3

[Drno]

Либо через плагины

Либо ломанут ssh на сервере и через него уже

Comments

[Ярик Ярик]

Сложный пароль чтоль не гарантия взлома через ssh ?

[Drno]

Ярик Ярик, неа. его можно подобрать... рано или поздно
в идеале доступ к ssh разрешается только с определенных IP, либо внутри VPN
еще по хорошему надо настроить fail2ban для ssh

[Ярик Ярик]

Drno, Хех ) На парольчик из символов 30 с разным регистром, включая цифры, спец-символы - потребуются годы, поэтому уж лучше мониторить уязвимости плагинов