paran0id

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

По двору прошелся жулик и попытался хакнуть эксплойтом для "майбаха" (условно) все тачки в вашем дворе. Майбахов не нашлось, этот жулик пошел дальше и забыл уже про ваш дворик.

Надо ли защищаться от атаки, не релевантной вашему сетапу? Не надо.
Надо ли делать выводы об уязвимости того или иного оборудования? Надо.
Надо ли проверять свои конфигурации на эксплойты? Надо.
Надо ли реагировать на всякую нерелевантную хрень в логах с ошибками порядка 400? Не надо.
Надо ли позаботиться об оркестрации быстрого развёртывания ваших серверов на случай взломов или проблем с железом? Конечно надо!

Вообще, если ваш сетап на виртуальных машинах в повторяемой среде и с декларативной конфигурацией вроде кубера или докера, то вы легче сможете пережить всякие такие факапы.
Схема такая.
Есть признаки взлома - бэкап логов, снапшот базы, бэкап стораджа, остановка сервисов (если позволяет продакшн), анализ атаки и последствий. Устраняем уязвимость по вектору атаки (гугление по логам и курение тредов), правим конфиги развёртывания и запускаем прод. Потом долго и тщательно разбираемся по логам, снапшотам и бэкапам что затронуто. Делаем тестовый чистый сетап по старой конфигурации и сравниваем пофайлово с атакованной системой, выясняем в какие места вмешались злодеи. Дифаем базу и смотрим на подозрительные различия. Делаем выводы, объявляем об утекших данных, если есть такие признаки (чтобы не подставлять пользователей), принимаем превентивные меры против похожих векторов атак.

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

Это взгляд дилетанта по безопасности, если чего пропустил -- поправьте. Если где не прав -- расскажите.

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

Включаем логику.
Если потребляет константно, но при этом само железо ничего не потребляет - значит БП должен всё рассеять сам, ибо закон сохранения энергии.
В худшем случае это будет 1квт+.
Вопрос: А есть ли у этого БП возможность столько рассеять вообще? Нет, нету.

Нужно соблюдать законы об интеллектуальной собственности.
"Разрешил всем брать" - это не лицензия.
Ищи, на каких именно условиях автор разрешил брать.

Используй curl с получением дерева файлов через find

find MYDIR -type f -exec curl ***

Нет смысла создавать свой дистрибутив для этих целей.
Узнай что такое Ansible playbook и как устанавливается ПО и настройки его средствами.

Само не бывает. Это кто то сделал
Либо из админов, либо вас взломали. Судя по тому, что ставили прокси)
Видимо не в закрытом, и доступ есть)

Похоже на то, что настройки биос не сохраняются. Варианты:
1) Дохлая совсем батарейка - заменить. Вставить её неправильно сложно, но всё-таки тоже проверьте.
2) Что-то при разборках-сборках сделали с джампером очистки биос - найти его по инструкции к материнке и убедиться, что он в правильном положении.

Создают ли эти логи нагрузку на диск и сервер в целом?

Создают

нужно ли отключать access логин для nginx

1. Для критичных путей оставь (логин, изменения данных).
2. Для GET запросов и других не важных можешь использовать самплинг - записываешь только определенный процент логов, а не все (выборка)