Комментарии 12
В WordPress по умолчанию подключается jQuery версии 1.12
Начиная с WordPress 5.6 вроде бы подключается одна из последних версий jQuery (так, текущий релиз WordPress 5.8.1 поставляется с jQuery 3.6.0).
Надо бы серверу помочь перестать заниматься фигней вместо работы:
берем не VPS/VDS - а именно VDS, это действительно отдельный виртуальный сервер, он же KVM
VPS не берем (OpenVZ) - это фактически контейнер с общим ядром Линукс, память и диск - там проблемы, зато дешево
меняем порт 22 на что-нибудь свое (там на 22 порт будет порядка 20-30 запросов в секунду с китайских серверов), fail2ban не поможет, там гигантский пул IP адресов
баним IP желающих подобрать что-либо в url по 404 ошибке (ошибки в лог на сервере + fail2ban на этот лог) - тоже полно желающих 20-30 запросов в секунду
перекидываем wp-config.php на уровень выше, так к нему тоже 20-30 запросов от подборщиков
возвращаем обработку ошибок 404 по указанию левых файлов на уровень Апач (вместо обработки WP)
меняем url админки на другой (через плагин)
и тогда большая часть тупых ботов останется без работы и наконец-то сервер займется реальными пользователями :)
И переход на следующий уровень сложности - включаем FastCGI в апаче - улучшатель обработки многопользовательского режима - сам апач однопоточный
Переход на следующий уровень - да, выкидываем Апач и работаем через связку Nginx-PHP-FPM
А потом можно уже и WP заняться или какой-либо другой CRM. Базу там поменять с MySQL на её форк. При использовании KVM сделать виртуальный диск в оперативку и базу туда закинуть = основные тормоза сайта на 50% к запросам к базе
Раз едем, то можно заняться и безопасностью сервера:
1. Берём и запихиваем nginx в контейнер, или используем systemd sandboxing или почти готовое решение bunkerity/bunkerized-nginx: 🛡️ -- и подключаем modsecurity (или naxsi для желающих хардкора) и crowdsec (последний что-то типа fail2ban на стероидах, который может подрубаться и к iptables - классная вещь). Можно и вот это впихнуть mitchellkrogza/nginx-ultimate-bad-bot-blocker . Если не использовали bunkerized-nginx, то посмотрите в сторону и этого модуля kyprizel/testcookie-nginx-module .
Если используете WAF modsecurity и его собратьев, то минимизируете риск взлома сайта, но будут возможны атаки на сам сервер и его зависимости. Если хотите и этот риск минимизировать, то ставьте IPS перед сервером типа Snort, но тут нужно придумать способ, чтобы IPS смотрел незашифрованный трафик. Хз, может поставить nginx, который расшифровывает трафик пользователей и пускает незашифрованный через IPS на другой NGINX или Apache - тут у меня пока опыта мало :)
2. Генерим конфиг nginx тут NGINXConfig | DigitalOcean и сверяем с новыми рекомендациями Mozilla тут Mozilla SSL Configuration Generator - врубаем OCSP stapling тоже из-за прибавки к скорости. Если на сайте операции с кредитками не будут проводится, то врубайте 0-RTT в TLS 1.3 - ага, штука с уязвимостью, но бустит скорость, и не забываем о HTTP/2. Также компилим динамические модули brotli, pagespeed (этот по желанию), http headers и другие, и подключаем.
Обязательно запиливаем все крутые хедеры типа HSTS со всеми опциями и продолжительностью минимум в год (заносимся в список HSTS Preload List Submission), не забываем про защиту кукисов. Со CSP сложнее, но вы можете использовать Laboratory (Content Security Policy / CSP Toolkit) или CSP Wizard от report-uri.com, ну там ещё SRI запилить. (Удачи с CSP - нервовыносящая штука, но мощная).
3. Конечно же получаем сертификат Let's encrypt, но с OCSP must staple и подписью ECDSA P-256. Для OCSP must staple при генерации добавляем --must-staple, с подписью сами разберётесь. Пока что браузеры кладут на OCSP staple, а тем более на OCSP must staple, но мы верим в светлое будущее. Я настолько верю, что даже указываю в DNS HTTPS RR, ведь Firefox уже их смотрит.
4. Берём тулзу Lynis, аудируем систему и укрепляем её. Устанавливаем OSSEC HIDS и настраиваем на посылку отчётов в Slack (есть плагин), правда, у меня эта сволочь не компилится на последней стабильно Ubuntu. Тут уже заходим в /etc/sysctl.conf и начинаем укрепление - гайдов много, но будьте аккуратны особенно с kernel.modules_disabled = 0. Вместо того, чтобы его прописывать в sysctl.conf, сделайте вот такой скрипт и поставьте на автозапуск через crontab с помощью @reboot path_to_your_script. Таким образом, kernel.modules_disabled врубится после загрузки всех основных модулей в ядро, а потом запретит добавлять новые:
#!/bin/bash
sleep 300
echo 1 > /proc/sys/kernel/modules_disabled
Я уже забыл, что ещё сделал ради удовлетворения своего любопытства.
Основные принципы работы с wordpress:
1. Скачать Google Fonts и раздавать со своего сервера либо CDN - намного отзывчивость повышается. Не пытайтесь даже рассчитать SRI на Google Fonts - там таблица стилей меняется для каждого клиента, поэтому ничего у вас не выйдет.
2. Придумать способ, чтобы сжать ресурсы сайта сразу на сервере и хранить сжатыми. Таким образом, серверу не придётся каждый раз тратить ресурсы на сжатие-пережатие, а это, возможно, очень трудозатратно. Идеально - минимизировать всё (включая очистку и минификацию svg - World's Best SVG Compressor (vecta.io)), сжать и раздавать. Где-то очень давно читал про этот способ, но позабыл его.
3. Использовать Webp (уже все браузеры его поддерживают) и Mozjpeg. Для конкретных размеров png используем панду TinyPNG, а для остального Squoosh
4. Лучше самому прописать все фавиконки сайта, чем полагаться на сам Wordpress, он не учитывает некоторые разновидности. Есть подвох - если у вас будет ico указана, то все браузеры благополучно забьют на модный svg, png и будут только показывать ico.
5. Лучше ручками прописать все preload, prefetch, preconnect в head - очень классные вещи. Preload, prefetch и другие теги
6. Ну и проводим аудит безопасности Wordpress с Security Ninja. Я пока не могу понять, лучше modsecurity или Wordfence WAF, но, думаю, что лучше использовать специализированные для Wordpress для большей защищённости, тогда как modsecurity, возможно, даст большую производительность. Также не забываем защитить БД (куча гайдов), PHP (офигенная вещь - jvoisin/snuffleupagus ) и изменить способ хеширования паролей на Argon2id (например PHP Native password hash). Ну и меняем ссыль на админскую панель, вешаем на неё hCaptcha и двухфакторку.
Больше пока ночью ничего в голову не приходит :) Надеюсь, что хоть кому-то поможет этот длиннотекст.
P.S. я до сих пор не понимаю, зачем админить сервак, на котором ты единственный живой пользователь, не под root. Можно же сделать так:
1. Использовать модифицированный sshd Obfuscated OpenSSH Patches и сделать магическим словом рандомный пароль 100+ символов. Сканеры портов в душе не поймут, что тот странный порт оказывается sshd сервер с обфускацией рукопожатия.
2. Аутентифицироваться только по ключу.
3. Запилить двухфакторку на sshd - How To Set Up Multi-Factor Authentication for SSH
Ну и ставим офигенно длинный пароль на root, который хешируется sha512 с кол-во hashing rounds 100к+.
Какой тогда вектор атаки может применить хакер чтобы через все дебри запихнуться под root?
P.P.S. я просто менеджер, который увлекается ковырянием вот в этом всём - к советам подходите очень критично.
Для ребят, которые хотят максимума, заходите в этот репозиторий и утаскивайте себе понравившиеся решения Whonix/security-misc: Kernel Hardening; Protect Linux User Accounts against Brute Force Attacks; Improve Entropy Collection; Strong Linux User Account Separation; Enhances Misc Security Settings
Не забывайте ещё пошаманить с apparmor:
1. apt install apparmor apparmor-profiles apparmor-profiles-extra apparmor-utils
2. Профиль для nginx apparmor-profiles/usr.bin.nginx
Это пока моя конфигурация для systemd sandboxing nginx (вносим через команду systemctl edit nginx):
[Service]
ProtectHome=true
ProtectSystem=full
SystemCallFilter=@system-service
LogsDirectory=nginx
NoNewPrivileges=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectKernelLogs=true
ProtectControlGroups=true
RestrictSUIDSGID=true
KeyringMode=private
ProtectClock=true
RestrictRealtime=true
PrivateDevices=true
PrivateTmp=true
ProtectHostname=true
RuntimeDirectory=nginx
LogsDirectory=nginx
LockPersonality=true
ConditionSecurity=apparmor
DevicePolicy=closedА это для unbound:
unbound/unbound.service.in
Спасибо за такие развернутые комментарии. Сервер можно настраивать бесконечно. А безопасности никогда не бывает достаточно. Hestia CP из коробки уже умеет многое (PHP-FPM, HTTP/2, ssl_stapling, HSTS...) и сравнительно безопасна.
В статью мне надо еще добавить про плагин Limit Login Attempts Reloaded, полегче, чем комбайн Wordfence. Сейчас кто только не пытается подбирать пароли к админке WP.
Отличный материал, но ещё можно было бы отметить возможность кеширования страниц тем же Varnish, так же есть нюансы с тюнингом базы данных, фильтрации не желательных ботов, и многое другое. Мы шаблонизируем это все и делаем немного больше в пакете. Если кому интересно предлагаю присмотрется к https://zahid.host/ru/services/woocommerce/ . Если есть желающие улучшить наше предложение обращайтесь, обсудим ;)
Плагины кеширования WP дают больше свободы действий с авторизованными пользователями. Как этим управлять в Varnish даже не представляю. Выше еще написали комментарий про FastCGI.
Это все очень круто и здорово если у тебя сайт не обвешан дополнительно всякой аналитическо-маркетинговой хренью, которая всеми способами норовит максимально снизить pagespeed score. Там какаято хрень вызовет смещение макета, а там модальное окно с cookie compliance сожрёт ещё TTI и т.д. и т.п.
Как привести в порядок Core Web Vitals за три дня, если у тебя Wordpress