Ульрих

направление поисков проще некуда. найти того кто ваял сайт и под угрозой расправы заставить разобраться где косяк!

Во-первых, у шаблонных сайтов есть ряд неудобств.
Ввиду универсальности верстки, они как правило содержат очень большое количество ненужного кода.
Как объяснить эту проблему клиенту решайте сами.
Я обычно говорю, что такие сайты сложней поддерживать, чем сайт, созданный "специально по его заказу".
Во-вторых, давите на уникальность.
Обычно на клиентов действует фраза "Вам же не нужен сайт, который будет копией другого проекта в интернете".
Расскажите ему, что сайт - это лицо компании, он не должен быть копией чего-то (может даже оказаться копией конкурентов, что принесет ряд неудобств и ему и конкурентам).
Должен "цеплять" зашедшего клиента, запоминаться.
Но вы не должны навязывать это.
Если клиенту все равно и он хочет дешево, то у вас есть два пути.
Послать его нахер или сделать ему так, как он хочет)

curl/wget

Антивирус для сервера нужен в немногих случаях - это если он исполняет роль файл-сервера с шарами или на нем работают пользователи терминалов.
В первом случае он и не нужен. Даже хватит встроенного Windows Defender, т.к. вся зараза будет идти с рабочих станций. Лучше озаботится защитой пользователей.
Во втором случае можно опять же обойтись Windows Defender. Он отловит почти все самое распространенное в сети.
1. Настроить проверку по расписанию когда сервер не нагружен работой пользователей.
2. Обязательно никаких прав админа у юзеров.
3. Исключить из проверки файлы подкачки и т.п. - все, что по вашему мнению не может быть изменено с правами пользователя. Это разгрузит файловую систему и придаст скорости. Любой антивирус - это потеря в производительности.
И бэкапы, бэкапы и только бэкапы)))

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

Ряд моментов Вы уже сделали, но я все равно их опишу для полноты списка.

1. Создать отдельного пользователя и хороший пароль на sudo. Не использовать больше root напрямую. Совсем.

2. SSH. Отключаем метод аутентификации по паролю. Если Вам не нужны другие методы, то их тоже можно отключить, оставив только publickey. Отключаем возможность аутентификации root'ом. Включаем использование только 2й версии SSH протокола.

3. Устанавливаем Fail2Ban и настраиваем чтобы после нескольких неуспешных попыток подключения по SSH банило по IP на длительное время. Кол-во попыток и время бана можно тюнить в меру своей паранойи. У меня, например, банит на час после 2х неуспешных попыток.

4. Iptables. Действуем по принципу "запрещено все, что не разрешено". Запрещаем по умолчанию весь INPUT и FORWARD трафик снаружи. Открываем на INPUT'е 22 порт. В дальнейшем открываем порты/forwarding по мере необходимости. Если у нас предполагаются сервисы на соседних серверах нужные только для внутренней коммуникации (Memcached, Redis, и т.д.), то открываем для них порты только для определенных IP. Просто так торчать наружу для всех они не должны.

5. Настраиваем автоматические обновления apt-пакетов. Уровень security. То есть так, чтобы обновления безопасности накатывались автоматически, но при этом не выполнялись обновления со сменой мажорной версии (дабы обезопасить себя от "само сломалось").

6. Устанавливаем ntpd. Серверное время должно быть точным. Также временную зону сервера лучше всего установить в UTC.

7. TLS (не SSL) используем везде где можем. Через Let's Encrypt получаем бесплатные валидные сертификаты. В конфигах веб-серверов, mail-серверов, и других приложений торчащих наружу (в том числе и OpenVPN), запрещаем/убираем использование слабых шифров. Все ключи/параметры генерируем не менее 2048 бит. Самоподписные сертификаты подписываем с помощью SHA-256 (не SHA-1). Diffie-Hellman параметры (dh.pem) под каждый сервис лучше сгенерить отдельно. Проверяем TLS сервисов через Nmap. Минимальный grade должен быть A, не должно быть warning'ов.

8. Правильный менеджмент пользователей/групп. Приложения/сервисы не должны запускаться под root'ом (разве что они действительно этого требуют и иначе никак). Для каждого сервиса создается свой пользователь.

9. Если предполагается upload файлов через PHP (либо другие скриптовые языки), в директории, куда эти файлы загружаются (и которая доступна снаружи), должно быть жестко отключено любое выполнение скриптов/бинарников, что на уровне ОС (x права), что на уровне веб-сервера.

Это была база.
Дальше, в меру своей паранойи можно за'harden'ить сервер ещё следующими моментами:
- SELinux, chroot
- доступ к SSH только с определенных IP (нужно иметь 3-4 VPN-сервера под рукой)

UPD И да, все это помнить/настраивать руками каждый раз может быть запарно. Используйте Ansible и автоматизируйте процесс (там родные и YAML, Jinja2 и Python).