Заметка с полей по решению проблем при размещении сайта wordpress за внешним проксирующим nginx. Если кому-то инетресно узнать полную схему размещения сайтов таким образом и зачем все это нужно в подробностях, пишите в комментариях. Напишу отдельную статью по этой теме.
https://serveradmin.ru/oshibka-wordpress-izvinite-vam-ne-razresheno-prosmatrivat-etu-straniczu/

#статья #webserver #wordpress

Небольшая статья на тему анализа производительности сайта на wordpress с помощью wp-cli и профайлера. Иногда бывает так, что с сервером все в порядке. Более того, другие сайты на нем летают, а конкретный тормозит. Необходимо профилировать работу самой cms, чтобы понять в чем проблема. Чтобы не опускаться до уровня профилирования непосредственно php кода, можно предварительный, а зачастую и достаточный для решения проблемы, анализ сделать с уровня самой cms. Рассказываю как раз об этом.

https://serveradmin.ru/wordpress-tormozit-kak-bystro-najti-prichinu/

#статья #wordpress

Я тут подколхозил немного yaml и bash для разработки сайтов под wordpress. Статья больше для разработчиков на тему того, как быстро и удобно развернуть рабочее окружение, начать разработку сайта локально и потом перенести его куда-то, чтобы показать.

Тема разработки под wordpress не сильно мне знакома. И вообще особо нигде не рассматривается в контексте современной разработки, хотя это самый популярный движок в мире. Из-за того, что он на php и монолитный, в современные концепции ci/cd не вписывается.

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

https://serveradmin.ru/ci-cd-proekta-na-wordpress

#статья #wordpress #devops

Технический пост, который уже давно нужно было сделать, но всё руки не доходили. На канале много содержательных заметок по различным темам. Иногда сам через поиск ищу то, о чём писал. Ниже набор наиболее популярных тэгов по которым можно найти что-то полезное (и не очень).

#remote - все, что касается удалённого управления компьютерами
#helpdesk - обзор helpdesk систем
#backup - софт для бэкапа и некоторые мои заметки по теме
#zabbix - всё, что касается системы мониторинга Zabbix
#мониторинг - в этот тэг иногда попадает Zabbix, но помимо него перечислено много различных систем мониторинга
#управление #ITSM - инструменты для управления инфраструктурой
#devops - в основном софт, который так или иначе связан с методологией devops
#kuber - небольшой цикл постов про работу с kubernetes
#chat - мои обзоры на популярные чат платформы, которые можно развернуть у себя
#бесплатно - в основном подборка всяких бесплатностей, немного бесплатных курсов
#сервис - сервисы, которые мне показались интересными и полезными
#security - заметки, так или иначе связанные с безопасностью
#webserver - всё, что касается веб серверов
#gateway - заметки на тему шлюзов
#mailserver - всё, что касается почтовых серверов
#elk - заметки по ELK Stack
#mikrotik - очень много заметок про Mikrotik
#proxmox - заметки о популярном гипервизоре Proxmox
#terminal - всё, что связано с работой в терминале
#bash - заметки с примерами полезных и не очень bash скриптов или каких-то команд. По просмотрам, комментариям, сохранениям самая популярная тематика канала.
#windows - всё, что касается системы Windows
#хостинг - немного информации и хостерах, в том числе о тех, кого использую сам
#vpn - заметки на тему VPN
#perfomance - анализ производительности сервера и профилирование нагрузки
#курсы - под этим тэгом заметки на тему курсов, которые я сам проходил, которые могу порекомендовать, а также некоторые бесплатные курсы
#игра - игры исключительно IT тематики, за редким исключением
#совет - мои советы на различные темы, в основном IT
#подборка - посты с компиляцией нескольких продуктов, объединённых одной тематикой
#отечественное - обзор софта из реестра отечественного ПО
#юмор - большое количество каких-то смешных вещей на тему IT, которые я скрупулезно выбирал, чтобы показать вам самое интересное. В самом начале есть шутки, которые придумывал сам, проводил конкурсы.
#мысли - мои рассуждения на различные темы, не только IT
#разное - этим тэгом маркирую то, что не подошло ни под какие другие, но при этом не хочется, чтобы материал терялся, так как я посчитал его полезным
#дети - информация на тему обучения и вовлечения в IT детей
#развитие_канала - серия постов на тему развития данного telegram канала

Остальные тэги публикую общим списком без комментариев, так как они про конкретный софт, понятный из названия тэга:
#docker #nginx #mysql #postgresql #gitlab #asterisk #openvpn #lxc #postfix #bitrix #икс #debian #hyperv #rsync #wordpress #zfs #grafana #iptables #prometheus #1с #waf #logs #netflow

​​Самый популярный движок для сайтов во всём мире — Wordpress. Именно на нём создано больше всего сайтов. Сам я все сайты делал исключительно на нём, хотя администрировать приходилось разные движки. Если меня спросит кто-нибудь посоветовать движок для информационного сайта или сайта-визитки, то совет будет однозначный. Я не вижу смысла использовать что-то другое.

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

Ставим плагин WP Super Cache. Включаем кэширование, указываем директорию для кэша, настраиваем предварительную загрузку кэша (отдельный раздел настроек). С такими настройками плагин будет автоматически создавать и периодически обновлять статические страницы, размещая их в определённой директории.

Теперь идём в настройки Nginx и настраиваем отдачу этих статических страниц напрямую через веб сервер, в обход php движка. Для этого настраиваем корневой location примерно так:

location / {
try_files /wp-content/cache/supercache/$http_host/$cache_uri/index-https.html $uri $uri/ /index.php?$args;
}

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

С этими настройками вы закрываете вопрос тормознутости сайта на Wordpress процентов на 90. Остальное останется под другие оптимизации, которые можно уже не делать. Сайт и так будет грузиться очень быстро. Он фактически стал статическим.

В WP Super Cache есть возможность указать настройки обновления или сброса кэша, например, при появлении нового комментария или новой статьи. Также можно выбрать пользователей или группы, для которых кэширование работать не будет. Кэшированием можно гибко управлять, в отличие от такого же кэша, только средствами Nginx. Он по быстродействию будет такой же, только без настроек, что неудобно.

Более подробно этот метод описан в документации самого плагина:
https://wordpress.org/documentation/article/nginx/#wp-super-cache-rules
Там имеет смысл добавить ещё немного настроек для исключения кэширования некоторых запросов. Примерно так. Эти настройки должны быть выше в конфигу виртуального хоста, чем предыдущий корневой location.

set $cache_uri $request_uri;
if ($request_method = POST) {
    set $cache_uri 'null cache'; }
if ($query_string != "") {
    set $cache_uri 'null cache'; }
if ($request_uri ~* "(/wp-admin/|/forum/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(_index)?.xml|[a-z0-9_-]+-sitemap([0-9]+)?.xml)") {
    set $cache_uri 'null cache'; }
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in") {
    set $cache_uri 'null cache'; }

Далее можно заняться оптимизацией картинок и включением сжатия brotli. Но это если хотите сделать всё максимально возможное. В общем случае и так нормально будет.

Тема ускорения Wordpress плотно оккупирована в поисковой выдаче сеошниками. А они про настройки Nginx ничего не знают и не умеют, поэтому найти подобное решение с плагином где-то через поиск вряд ли получится. А если искать по-серьёзному материалы админов, то найдёте скорее всего кэширование напрямую через сам Nginx или какой-нибудь Varnish. Но это будет не так гибко и удобно.

#webserver #wordpress

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

Сайты на Wordpress брутят повсеместно. Из-за того, что этот движок очень легко установить, много установок, сделанных дилетантами (сеошники, блогеры и т.д.). О безопасности там никто особо не заботится, поэтому и вероятность взлома значительная, чтобы заинтересованные люди решили потратить на это своё время.

Для примера покажу, как легко и просто начать подбор паролей. Возьмём всем известный сетевой сканер nmap. Нам понадобится любой список паролей, по которому мы будем делать перебор. Можно взять для тестов простые списки в репозитории BruteX или огромный список в wordlist.

В составе nmap есть готовый скрипт для брута админки Wordpress. Достаточно указать адрес сайта, учётную запись, например, admin и список паролей для перебора. Запускаем перебор:

# nmap example.com --script http-wordpress-brute --script-args \
'user=admin, passdb=password.lst, http-wordpress-brute.thread=3, brute.firstonly=true'

В логах веб сервера увидите POST запросы к /wp-login.php от user_agent="Mozilla/5.0 (compatible; Nmap Scripting Engine; https://nmap.org/book/nse.html)". Этот скрипт удобно использовать для тестирования своей защиты.

Теперь расскажу, как работает защита от такого перебора с помощью fail2ban. Устанавливаете его в систему и делаете очень простой фильтр wp-login.conf, положив его в директорию /etc/fail2ban/filter.d:

[Definition]
failregex = <HOST>.*POST.*(wp-login\.php|xmlrpc\.php).*

Он ищет все POST запросы к указанным url. Это защита от подборка учёток через wp-login и xmlrpc (последний лучше вообще отключить или закрыть доступ через nginx). Далее создаём настройку jail wp-login.conf и кладём её в директорию /etc/fail2ban/jail.d:

[wp-login]
enabled = true
port = http,https
action = iptables-multiport[name=WP, port="http,https", protocol=tcp]
filter = wp-login
logpath = /var/log/nginx/example.com/access.log
maxretry = 5

Это пример настроек, когда используется iptables. Теперь, как только в логе access.log появится более 5 попыток POST запросов к wp-login.php или xmlrpc.php, IP адрес обратившегося будет забанен. Это удобно проверить с помощью скрипта для nmap.

Подобным образом можно настроить защиту от перебора учётных записей любого сервиса, который записывает информацию об аутентификации в текстовый лог файл. Главное не забыть очень важный момент. Лог файл не должен быть очень большим. Обязательно необходима ротация по размеру файла. Если лог становится очень большим, то fail2ban может сам повесить сервер. Он написан, если не ошибаюсь, на Python и работает не очень быстро. Если вас начинают ддосить и access лог разрастается за минуту до гигабайтов, fail2ban вам сам повесит сервер. Его надо оперативно выключать. В отдельной заметке расскажу, как сделать более универсальную защиту без необходимости парсить access.log.

Более подробно с примерами эта настройка описана у меня на сайте в статье: Защита админки wordpress с помощью fail2ban.

Отдельно отмечу, что для fail2ban есть веб интерфейс — fail2web

#security #webserver #wordpress #fail2ban