14.04 ставить просто не разумно сейчас.
16.04 исторически наиболее качественный LTS от каноникал. Php 5.x, при необходимости, ставится из внешних репозиториев.

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

Вы не сможете проверять под анонимом что-нибудь...

Сделайте http авторизацию. Для данного кейса это наиболее подходящее решение.

• Для nginx: https://nginx.ru/ru/docs/http/ngx_http_auth_basic_module.html
• Для apache: https://httpd.apache.org/docs/2.4/howto/auth.html

Да, это оно и есть.

Это верно, только для случая целенаправленной атаки на конкретный сайт.
В нашем же случае, этим занимаются боты, которые сканят всё подряд, поэтому, от "неуловимости джо", тут ничего не зависит...

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

Вообще, уязвимостей, которые позволяют локально поднять права, не так и мало, и не так уж редко находятся новые. И если долго не обновлять серверное ПО, то можно получить и эскалацию, и сервер под полный контроль.
Т.е. не настолько всё радужно, хотя, чаще, от кривых рук настраивающих больше вреда.

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

Дать разумный совет по окончательному выбору, не проводя нагрузочного тестирования невозможно.

Если проект только стартует, имеет смысл взять дешёвый vps, что-нибудь типа 1 ядро/1 гиг памяти(меньше лучше не брать), и по необходимости масштабироваться в дальнейшем, в зависимости от реальной необходимости.

например 5TB Bandwidth

И тем не менее, наверняка взломан.
А access лог читать, несколько бессмысленно, чтобы это определить, особенно не понимая как это надо делать в данном случае, и что можно считать подозрительным...
И если уж его анализировать, то советую посмотреть на POST запросы подозрительные, прежде всего.

Это не более чем частный случай, а не что-то характерное для этой конкретной уязвимости...

Можно, например, использовать sublime, и к нему плагин https://github.com/kkujawinski/sublime-text-3-patch-apply
Тут не потребуется каких-то джедайских умений, да и редактор неплохой.

Да, и накладывание патча полезно освоить, тем более, что это довольно не сложный процесс.

Drupal 6 уже не поддерживается, а расширенная поддержка оказывается платно сторонними организациями, так что не участвуя в этой программе, вероятно, нигде...
Подробнее тут: https://www.drupal.org/project/d6lts
Патчи публичны, но применять придётся самостоятельно.

P.S. Чаще всего, миграция с 6 на 7, не такая уж сложная задача. И очень стоит задуматься о ней...

Новость опоздала на неделю. Проблема была потверждена 7 апреля. Тогда же началось массовое заражение.
На самом деле, не удивительно - vesta довольно плохо сделана в целом.

Штатно, при установке модулей? Это не получится сделать, если нет прав записи. В этом случае, будет предложено использовать ftp с нужными доступами, для записи изменений.

Вы же не устанавливаете критические обновления как патчи... В противном случае, у вас куда больше,чем отдельные строки в обновлении. Впрочем, даже одна строка может сломать совместимость с чем-то.

Не зная более точной задачи, не так просто что-то посоветовать...
Может быть flag (https://www.drupal.org/project/flag)?

Проверка нужна для того, чтобы выяснить нет-ли где-то регрессий, нет-ли проблем с совместимостью. В любом более-менее сложном проекте, не важно на чём он, проблемы такие рано или поздно появляются, т.к. никто не тестирует заранее все возможные сочетания различных модулей/настроек и.т.п. - это просто технически не возможно. Тестируют отдельные компоненты при их разработке, и готовый сайт, из них собранный при его разработке/сопровождении.

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

Да, во многих системах безопасность приносится в жертву удобству не подготовленного пользователя, и это далеко не последняя причина, например того, почему так часто ломают тот же WP.
Вообще, соотношение удобство/безопасность, это всегда компромисс.

Да и не только он - IDE, вероятно, все умеют, хотя бы, с помощью плагинов. Даже, тот же, sublime умеет.
Ну и весьма не вредно, перечислить все возможности, а там каждый для себя выберет удобный метод. Может автору вопроса, и не пригодиться, а кому-нибудь другому вполне...

Или через утилиту, с нехитрым названием patch https://ru.wikipedia.org/wiki/Patch_(Unix)
Или с помощью какого-нибудь продвинутого редактора/IDE.

Платной версии этой темы, в каталоге, всё же, нет. Она есть на сайте разработчика.

Не то, чтобы правильнее - это просто разные плоскости. Одинаково, и независимо верны оба эти утверждения.

А так, ПО с открытым кодом может быть платным, или бесплатным, как и ПО с закрытым кодом.
Но в каталоге нет, ни платных, ни противоречащих "лицензии gplv2 и более поздней".

Совершенно не обязательно большие и сложные - показать, насколько удачно реализуется, и небольшая задача на Drupal, и почему именно он так хорошо подходит для этого, не менее полезно. А может, даже и более - не всем нужно что-то крупное, и хорошее описание типовой задачи, может заинтересовать даже большее количество потенциальных заказчиков, просто потому, что это их кейс, именно то, что нужно им...