AUser0

Вообще-то для WEB-интерфейса Zabbix необходима установка пакета zabbix-web и PHP (в какой-либо форме).

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

И Apache должен бы справляться с такими "запросами" с лёгкостью. Конечно если их не 100500 штук за 5 секунд.
А что бы такой мусор не ломал сервер, IP нужно блокировать на сетевом уровне, например командой

iptables -I INPUT -s 20.252.4.193,89.187.162.69 -j REJECT

Потому что у работодателя именно CentOS и используется. Не?

Дату начала и конца сертификата указали, для какого именно доменного имени сгенерирован сертификат - умолчали. Ню-ню!

И вы не в курсе, что google.ru через http не работает, ага?

P.S. Нет, про настройку https рассказывать не буду, лень пересказывать то, что и так есть в этой вашей Интынэте.

Нет, вы не правы. Первые 3 строчки с двоеточиями - это только указание action по умолчанию. Сами правила попадают в ту таблицу, которая указана сразу после -A

В location / сделайте:

if ($http_user_agent ~* "(bingbot|petalsearch|semrush|mj12bot)") {
    return 403;
}

Ну это если по быстрому, без fail2ban.

А в SELinux вы нестандартный порт разрешили?
semanage port -a -t http_port_t -p tcp 8081

Сделать архивирование tar-ом с сохранением результата по SSH на другой компьютер/сервер, да даже на принтер, служба безопасности порой такие озорники!

В конфигах интерфейсов в /etc/network/interfaces/ пропишите IPV6INIT=no.

А вы не заметили, что директории yum.mariadb.org/10.1 уже не существует? Нет директории - нет и пакетов из неё... Ищите другой репозиторий!

У вас указан тип проверки http-01, значит система Let's Encrypt для проверки владения доменом SITE.ORG обращается к вашему серверу за файлом http://SITE.ORG/.well-known/acme-challenge/имя_фай... с длинным проверочным кодом (в лог файлах этот запрос можно найти).

Но поскольку сам сайт из NGINX-сервера вы удалили - то и доступ к проверочному файлу уже невозможен.
Поэтому и происходит ошибка проверки владения доменом SITE.ORG...

P.S. Упс, только-что заметил, у SITE.ORG нет DNS-записи, указывающей на ваш NGINX-сервер.

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

Наобум можно отфильтровать командой:

cut -f1 -d' ' /var/www/httpd-logs/mysite.access.log |sort |uniq -c |sort -nr >num.txt

И смотрите файл num.txt. Если IP там не окажется - меняйте цифру в аргументе -f1 на -f2, и т.д.

Во-первых, зря вы запускаете такие задачи да из-под самого root-а.

Во-вторых, по логам cron-а задача с wget запускается один (1) раз.
Если она запускается дважды - значит где-то кто-то её ещё раз запускает.
Где-нибудь в каком-нибудь PHP-скрипте?

И третье, стоит заключить URL для wget в кавычки:

wget -q -O - "my-site.ru/index.php?route=common/task/doSome" > /dev/null 2>&1

Во-первых, посмотрите настройки ifconfig enp0s3 при включенном BOOTPROTO=dhcp. Так вы узнаете, какие параметры можно прописать в конфиг для ручной конфигурации BOOTPROTO=static.

Во-вторых, а вообще сеть в виртуальной машине есть? Работает ли ping 192.168.1.1? А ping 8.8.8.8? И смотрите на результат traceroute 8.8.8.8, происходит затык?

В-третьих, если сеть есть, и пинги ping 8.8.8.8 работают - проверяйте работу собственного NS-сервера на 192.168.1.1, прилетевшего по DHCP. Сделайте dig @192.168.1.1 ya.ru, должен быть корректный результат. Далее dig @8.8.8.8 google.ru для проверки, что и наружние NS тоже доступны.

Ну и финальное, если все предыдущие проверки (кроме dig @192.168.1.1 ya.ru) прошли положительно - то можно прописывать доступный NS в конфиг системы: sudo echo "nameserver 8.8.8.8" >/etc/resolv.conf.

У вас всё?