Коротко: это не «обновите, когда удобно». Обе CVE — unauthenticated RCE. На Apache mod_php эксплойт показали до запуска кода вашего сайта. Полных временных костылей нет — только обновление. Ниже — что именно починили, кого бьёт и как быстро проверить, что вы уже на патче.

Какие версии ставить

PHP 8.1 и старше upstream больше не патчит. Для 7.4 / 8.0 / 8.1 выложили минимальные source-backport’ы — если собираете сами или ждёте пакет от LTS-вендора. На Remi PHP-команда прямо написала: сегодня обновлений в rpms.remirepo.net не будет, берите дистрибутивные пакеты или собирайте из исходников.

Проверка после обновления:

php -v
# и обязательно через веб — тот же php-fpm/mod_php, что обслуживает сайт
<?php echo PHP_VERSION;

CLI может уже быть новым, а пул FPM — старым. После пакета — reload/restart воркеров.

CVE-2026-109618 — RCE через OOM

Advisory: GHSA-w8hw-w9fx-j79w. CVSS v4.0 — 9.2.

Суть простым языком: при нехватке памяти PHP раньше уходил через longjmp(), обрывая обработку запроса. Иногда это случалось, когда внутренняя структура запроса ещё не до конца инициализирована. Cleanup потом смотрел на это «полусобранное» состояние как на нормальное — отсюда порча памяти и путь к RCE.

OOM можно спровоцировать не только «тяжёлым скриптом»: multipart без нормального Content-Length, куча заголовков внутри part’ов, пустые file-поля, глубокая вложенность имён полей — всё это раздувает память сильнее, чем кажется по post_max_size.

Самое неприятное: на mod_php атака возможна до любого кода приложения. FPM по анализу тоже в зоне риска (полный публичный эксплойт под FPM на момент advisory не демонстрировали, но «мы на nginx+php-fpm — нам норм» — плохой вывод).

В патче: отказ от опасного longjmp() на OOM, soft/hard OOM через нормальные точки остановки, shutdown больше не видит битое состояние.

CVE-2026-109619 — RCE через «протухшее» состояние

Advisory: GHSA-6wmf-4rv5-p3rp. Тоже 9.2.

Здесь другая история: внутреннее состояние, привязанное к запросу, может пережить освобождение памяти. Следующий запрос на том же воркере успевает опереться на stale state, пока нормальная инициализация его не сбросила. Классический use-after-free на уровне рантайма — снова без логина.

Обе дыры закрыты одним пакетом релизов. Если обновились — закрыли обе.

Кто в зоне риска

По словам PHP Security Team — все установки PHP, которые отдают веб-запросы:

• PHP-FPM
• Apache mod_php (риск считают наивысшим)
• php-cgi
• FrankenPHP
• LiteSpeed / LSAPI

Не только «публичный WordPress». Ещё админки, панели, контейнеры, appliances, где PHP вшит и про него часто забывают. WordPress, Битрикс, Laravel, самопис — всё на одном интерпретаторе.

Как обновить на практике

Debian / Ubuntu (ondrej или вендорский репозиторий):

sudo apt update
sudo apt install --only-upgrade php8.3-fpm php8.3-cli   # подставьте свою ветку
sudo systemctl restart php8.3-fpm
# если Apache+mod_php:
sudo systemctl restart apache2

RHEL / Alma / Rocky: пакеты от дистрибутива или AppStream; не ждите сегодня Remi.

Docker: пересобрать образ на php:8.x.y с fixed-тегом / digest, задеплоить заново. Один docker pull без recreate контейнера не спасёт старый процесс.

Shared-хостинг: тикет хостеру + проверка phpinfo() / версии в панели. «Мы обновим на выходных» для этой дыры — плохой ответ.

После рестарта убедитесь, что все пулы/vhost’ы реально на новой версии, а не только дефолтный.

Если обновить прямо сейчас нельзя

PHP честно пишет: полного mitigation нет. Ниже — только снижение отдельных векторов, пока катите пакет.

Для CVE-2026-109618:

• memory_limit=-1 через php_admin_value в FPM/Apache так, чтобы приложение не вернуло лимит обратно;
• низкий post_max_size (например 8M без аплоадов, 32M если аплоады нужны), upload_max_filesize ниже него;
• лимиты на размер/число multipart/headers на nginx/прокси;
• не использовать RLIMIT_AS / RLIMIT_DATA как «защиту» — они как раз могут спровоцировать уязвимый путь.

Для CVE-2026-109619:

• session.upload_progress.enabled=0 и рестарт всех воркеров (не через ini_set / .user.ini);
• на PHP 8.5 — fatal_error_backtraces=0;
• убрать странные per-request deprecated settings, которые сыплют диагностикой до инициализации.

WAF в одиночку PHP не считает достаточной защитой. Временные меры — мост на часы/сутки, не замена патчу.

После патча — не забыть про компрометацию

Окно между утечкой (20 октября) и массовым обновлением уже открыто. Обновление закрывает вход — уже залитый шелл не удалит. Имеет смысл:

• логи на странные multipart/огромные POST, падения воркеров, всплески 5xx;
• новые .php в uploads / странных каталогах;
• левые пользователи в CMS, правки cron, mu-plugins, неожиданные процессы от www-data.

Тот же урок, что после wp2shell и массовых взломов Битрикса: сначала чистка, если уже задели, потом спокойная жизнь на патче.

Чеклист на сегодня

1. Узнать текущую ветку PHP на каждом сервере/контейнере.
2. Поставить fixed-релиз своей линии (или пакет вендора с бэкпортом).
3. Перезапустить php-fpm / Apache / контейнеры.
4. Проверить версию именно через HTTP, не только CLI.
5. Если сидите на 7.4/8.0/8.1 — ускорить миграцию или бэкпорт вендора.
6. Пробежать логи и файлы на следы компрометации.

Исходники и Windows-сборки — на downloads.php.net. Полный разбор — в advisory на архиве новостей и в двух GHSA выше.

Повод ускориться неприятный: информация об уязвимостях утекла до официального disclosure. Сначала пост на Hacker News (потом удалили), затем подтверждение от исследователей watchTowr. PHP прямо написали: имеют право выпустить патч раньше, если детали станут публичными или появится эксплуатация в дикой природе.

Официальный анонс: Upcoming Critical PHP Security Release. Разбор ситуации: BleepingComputer.

Что уже известно

Пока официально PHP подтвердили только рейтинг и дату релиза. CVE-номера и «это RCE» в их коротком анонсе не расписаны — детали обещают вместе с патчами.

Из параллельных источников (watchTowr → BleepingComputer, CERT-EU, ACSC):

• идентификаторы: CVE-2026-109618 и CVE-2026-109619;
• тип: remote code execution (удалённое выполнение кода);
• watchTowr оценивает как CVSS 10, PHP официально ставит каждой 9.2 по CVSS v4.0 — расхождение в шкалах, не в том, что «не страшно»;
• по оценке исследователей, затронуты ветки PHP 5 / 6 / 7 / 8 (то есть фактически «почти всё, что ещё крутится в проде»);
• на момент предупреждений активной эксплуатации в wild не видели — но окно после утечки и до патча как раз самое опасное.

Ожидаемые fixed-релизы (по сообщениям security-комьюнити, не финальный список от PHP до момента публикации патчей): 8.5.12, 8.4.27, 8.3.36, 8.2.35. EOL-ветки вроде PHP 7.4 / 8.0 / 8.1 патча могут и не получить — рассчитывать на «дистр когда-нибудь подтянет» для мёртвой ветки наивно.

Почему это важно именно вам

PHP — это не «какой-то фреймворк». На нём сидят WordPress, Битрикс, Laravel, Magento, куча самописных ЛК и API. Если дыра в интерпретаторе и она RCE — компрометируется не «один плагин», а процесс php-fpm / apache-модуль. Дальше классика: шелл, бэкдор в wp-content, кража wp-config / .env, рассылка, ботнет.

После историй с wp2shell и массовыми взломами Битрикса сценарий знакомый: disclosure → через сутки сканеры по интернету → через неделю «у нас странный админ и левый плагин». Здесь ещё и leak до релиза — значит, кто умеет, уже мог готовить эксплойт, пока вы читаете новость.

Что сделать прямо сейчас

1. Инвентаризация. Пройдитесь по серверам и узнайте, где какой PHP:

php -v
# или на сайте
<?php echo PHP_VERSION;

Отдельно — контейнеры, shared-хостинг клиентов, «забытые» лендинги на старом 7.4. Список версий и хостов лучше иметь до того, как пакеты появятся в репозитории.

2. Подготовить обновление. На Debian/Ubuntu заранее проверить, откуда тянете PHP (ondrej/php, вендорский репозиторий, remi на RHEL). На VPS с ручной сборкой — план: скачать релиз → подменить → reload php-fpm. На shared — тикет хостеру: «когда выкатите security-релиз PHP от 21.10».

3. Как только пакеты вышли — ставить без отлагательств. Для поддерживаемых веток цель простая: оказаться на fixed-версии своей линии (или новее). После обновления:

systemctl reload php*-fpm
# или
systemctl restart php8.3-fpm apache2

И проверить, что сайт реально отвечает уже новым бинарником, а не старым php-fpm из другого pool.

4. EOL — отдельно. Если сайт на PHP 7.x или 8.0/8.1 и вендор патч не выпустит — это не «подождём», а миграция на поддерживаемую ветку. Временные костыли (WAF, закрыть наружу) — только мост, не лечение.

5. Пока патча нет / нельзя сразу обновить. CERT-EU прямо советует: где нельзя пропатчить мгновенно — по возможности изолировать интернет-facing приложения. На практике: усилить WAF/Cloudflare, убрать лишний PHP с публичных vhost’ов, закрыть ненужные entrypoint’ы, не торчать phpMyAdmin в мир. Это не замена патчу.

6. После патча — быстрый чек на компрометацию. Особенно если сервер торчал в интернет всё окно утечки. Смотрите новые PHP в uploads / странных каталогах, левых пользователей в CMS, неожиданные cron, правки .htaccess / nginx, неизвестные процессы от www-data. Патч закрывает вход — бэкдор, уже залитый до обновления, сам не исчезнет (мы это уже проходили на Битриксе и WordPress).

Чего пока делать не стоит

• Не гонять по себе чужие «PoC с GitHub», пока нет официального advisory — половина будет фейком или сама шеллом.
• Не путать CVSS 9.2 от PHP и «CVSS 10» из твитов: это разные формулировки одной критичности, а не две разные дыры.
• Не ждать, что «WordPress сам обновит PHP» — CMS ядро обновляет, интерпретатор на сервере — ваша зона.

Что дальше

После 14:00 UTC 21 октября на php.net должны появиться changelog’и и список affected/fixed. Как только будут точные версии и описание вектора — имеет смысл свериться ещё раз: не все сборки дистрибутивов выходят в ту же минуту, что upstream.

Если коротко: сегодня это не «интересная CVE для чтения на выходных», а окно, в котором нужно знать свои версии PHP и быть готовым нажать обновление в первые часы после релиза. WordPress, Битрикс, самопис — неважно: дыра в PHP бьёт по всему стеку.

Нужна помощь — пробежать серверы, обновить PHP на VPS, проверить сайты после патча — пишите через контакты.

Я не таскаю закрытый ключ на промежуточную машину. Прыжок для меня — дырка в TCP, не второй дом для ssh-agent. Ниже — чем ProxyJump отличается от проброса агента, когда агент всё-таки оставляю, и чем проверяю, что ключ с ноутбука никуда не уехал.

Хосты в примерах вымышленные: jump.example.net (документационный 203.0.113.40), внутренний prod-web-01.internal, пользователь ops. Свои имена и ключи подставляйте, чужие из чатов не копируйте.

Две привычки, которые путают с «удобным прыжком»

Первая: положить тот же закрытый ключ на bastion. «Ну я же сам туда захожу, чего его беречь». Bastion — это машина, на которую смотрит интернет. На ней чаще стоят общие учётки, старый sudo, чужой tmux. Если ключ от прода лежит файлом в ~/.ssh на такой коробке, компрометация прыжка равна компрометации всего, куда этот ключ пускают. Пароль на ключ тут слабое утешение: его снимут вместе с файлом, из памяти агента или из вашей же сессии.

Вторая: ForwardAgent yes глобально в ~/.ssh/config или в системном ssh_config. Так делают, чтобы со прыжка открыть следующий ssh «как с ноутбука». Удобно. И ровно поэтому опасно. На время сессии на джампе появляется unix-сокет агента. Любой, кто может читать этот сокет — root, ваша скомпрометированная учётка, чужой процесс под тем же uid — может пользоваться ключами, пока вы онлайн. Ключ с диска не копировали. Подпись от вашего агента уже достаточно.

Есть ещё гибрид: ключ на ноутбуке, а на прыжок его один раз залили «на всякий случай» и забыли. Потом ротировали ключ дома, на джампе старый остался. Я такие находки встречаю чаще, чем хотелось бы: ls -l ~/.ssh на bastion и два id_*, один из которых уже «не наш».

Что именно делает агент, когда его пробросили

ssh-agent на ноутбуке — нормальная вещь. Он держит расшифрованные ключи в памяти, чтобы не тыкать passphrase на каждый git fetch. Плохо не агент. Плохо отдавать его сокет чужой машине.

При ForwardAgent yes клиент поднимает на удалённой стороне канал и выставляет SSH_AUTH_SOCK. Дальше ssh prod-web-01, запущенный уже на прыжке, ходит в этот сокет. Подпись делает ваш ноутбук. Выглядит безопасно: «ключ же дома». Но решение «подписать вот этот challenge» принимает процесс на bastion. Если bastion врет, вы подпишете не то соединение, о котором думаете.

Практическая картинка, которую я показываю заказчику:

• Вы в сессии на jump.example.net.
• echo $SSH_AUTH_SOCK даёт путь вроде /tmp/ssh-XXXX/agent.1234.
• С правами на этот сокет можно сделать ssh-add -L и увидеть ваши ключи.
• Дальше — обычный ssh ops@prod-web-01.internal. Прод видит ваш ключ. В authorized_keys это тот же самый ключ, которым вы заходите «сами».

Root на джампе для этого не всегда нужен. Достаточно вашей же утёкшей сессии, crон-скрипта под тем же uid или «временного» бинарника в $PATH. Поэтому фраза «ну у нас же на bastion только свои» меня не греет: свои тоже ошибаются, а агент не спрашивает, кто именно попросил подпись.

Отдельно: ssh-add -c на ноутбуке чуть лучше, чем голый агент. Перед каждой подписью всплывает confirm. Это не броня, но если сокет увели тихо, вы хотя бы увидите лишний запрос в момент, когда сами ничего не открывали.

ProxyJump: прыжок без вашего ключа на той стороне

ProxyJump (ключ -J) делает другое. Клиент на ноутбуке открывает ssh на bastion и просит его прокинуть TCP до цели. Аутентификация на prod-web-01 идёт с ноутбука, напрямую в этом тоннеле. На прыжке нет вашего закрытого ключа, нет сокета агента, нет второго ssh от вашего имени.

Грубо: bastion видит, что с вашего IP пришёл ssh и что вы попросили соединиться с prod-web-01:22. Bastion не видит, каким ключом вы представились проду, и не может этот ключ переиспользовать через минуту после того, как вы отключились.

Минимальный ~/.ssh/config, с которого я начинаю:

Host jump
    HostName jump.example.net
    User ops
    IdentityFile ~/.ssh/id_ed25519_jump
    IdentitiesOnly yes
    ForwardAgent no

Host prod-web-01
    HostName prod-web-01.internal
    User ops
    ProxyJump jump
    IdentityFile ~/.ssh/id_ed25519_prod
    IdentitiesOnly yes
    ForwardAgent no

Два ключа — не паранойя. Ключ на интернет-джамп я считаю расходным: его проще отозвать. Ключ на прод на прыжок не кладу и в агент для сессии на jump не пихаю, если можно не пихать. IdentitiesOnly yes обязателен: иначе клиент переберёт все ключи из агента, и вы сами не вспомните, чем открыли хост. Плюс лишние попытки ключей иногда заканчиваются Too many authentication failures.

Одноразово без конфига:

ssh -J ops@jump.example.net ops@prod-web-01.internal

Два и больше прыжка — список через запятую:

ssh -J jump.example.net,dmz-gw.example.net ops@prod-web-01.internal

В конфиге то же самое: ProxyJump jump,dmz-gw. Старый ProxyCommand ssh -W %h:%p jump я оставляю только там, где клиент древний и ProxyJump ещё нет. Смысл тот же: проброс TCP, не проброс агента.

Как я проверяю, что агент не уехал

После захода на цель смотрю три вещи, не «ну вроде работает».

На ноутбуке, до входа:

ssh -G prod-web-01 | egrep -i 'proxyjump|proxycommand|forwardagent|identityfile|identitiesonly'

Хочу увидеть свой ProxyJump, forwardagent no, нужные IdentityFile и identitiesonly yes. Если forwardagent yes приехало из /etc/ssh/ssh_config или из Host * в конце файла — чиню там, а не добавляю ещё один Host выше, который потом перебьют.

Вход с отладкой:

ssh -v prod-web-01 2>&1 | egrep -i 'proxy|jump|forwarding|agent|Offering|Authentication succeeded'

Ищу, что клиент идёт через jump и что нет строк про agent forwarding. «Offering public key» должно относиться к ключу прода, не к ключу джампа. Если клиент предлагает пять ключей подряд — IdentitiesOnly не сработал.

На самой цели и на прыжке, уже внутри сессии:

echo "SSH_AUTH_SOCK=${SSH_AUTH_SOCK:-}"
ssh-add -l

На prod-web-01 при чистом ProxyJump сокет агента обычно пустой, ssh-add -l отвечает, что агента нет. На прыжке при обычном заходе на сам jump — то же самое, если я не просил проброс. Если сокет вдруг есть, а я его не включал, ищу кто: Host *, Include-info в конфиге, обёртка вроде assh/sshpass, корпоративный «улучшатель» ssh.

Ещё одна проверка, которую люди пропускают: ключи на диске прыжка.

ls -l ~/.ssh
find ~/.ssh -type f \( -name 'id_*' -o -name '*.pem' \) ! -name '*.pub'

Закрытых ключей там быть не должно. Если есть — снимаю с машины, смотрю authorized_keys на проде, не торчит ли тот же pubkey, и ротирую. Pubkey на прыжке (чтобы вы сами на него заходили) — нормально. Приватник от прода — нет.

Когда агент всё-таки нужен — и как его не размазать

Иногда без проброса не обойтись. Типичные случаи, которые я оставляю точечно:

• С удалённой машины нужно сходить в git по SSH вашим ключом, а ключ на эту машину класть нельзя. Тогда агент — меньшее зло, чем файл в ~/.ssh.
• Старый сценарий, который сам делает ssh со прыжка на пачку хостов и не умеет ProxyJump. Это чинят, но не в пять минут посреди инцидента.
• Промежуточный хост должен подписать что-то ещё вашим ключом (редко, и я сначала пытаюсь перенести это действие на ноутбук).

Правило одно: агент включаю на конкретный Host, не на *. И только на время задачи.

Host git-build.internal
    HostName git-build.internal
    User ops
    ProxyJump jump
    IdentityFile ~/.ssh/id_ed25519_prod
    IdentitiesOnly yes
    ForwardAgent yes

На ноутбуке ключ в агент кладу с подтверждением:

ssh-add -c ~/.ssh/id_ed25519_prod

Сессию короче держу. После работы ssh-add -d этот ключ из агента. На прыжке в sshd_config я по возможности ставлю AllowAgentForwarding no — тогда даже ошибочный ForwardAgent yes у клиента не поднимет сокет. Если агент нужен на одну машину за прыжком, форвардинг агента разрешаю только там, не на bastion.

Ansible отдельным абзацем. Плейбук, который заходит на прод через bastion, не обязан пробрасывать агент. В инвентаре достаточно:

ansible_ssh_common_args: '-o ProxyJump=ops@jump.example.net'

или ansible_ssh_extra_args с тем же. Ключ остаётся на контрольной машине. Если вам «без ForwardAgent плейбук не едет», чаще виноват не Ansible, а то, что роли сами делают ssh/rsync/git уже на целевом хосте вашим ключом. Это другая задача: либо ключ деплоя на целевой машине, либо отдельный deploy key в git, либо вынести шаг на ноутбук.

Что должно быть на самом прыжке

Bastion я собираю скучно. Чем меньше на нём живёт, тем меньше соблазна «раз уж зашли, давайте тут ключи».

• Отдельный ключ только для входа на jump. Этот ключ не пускает на прод.
• PermitRootLogin no, вход по паролю выключен, по возможности отдельный порт или хотя бы geo/fail2ban — как принято у заказчика, не догма.
• AllowTcpForwarding yes (иначе ProxyJump не взлетит), AllowAgentForwarding no, X11Forwarding no.
• Если sshd умеет PermitOpen — ограничиваю, куда вообще можно прыгать: только рабочие подсети, не «любой порт мира через нас».
• Нет общих ops с одним ключом на пятерых. Если ключ общий, вы не отзовёте одного человека.
• На диске нет id_* без .pub. Нет authorized_keys с ключами прода «для удобства».

Кусок sshd_config на прыжке, от которого я отталкиваюсь:

AllowAgentForwarding no
AllowTcpForwarding yes
X11Forwarding no
PermitTunnel no
GatewayPorts no
# если политика позволяет — режем направления:
# PermitOpen prod-web-01.internal:22 prod-db-01.internal:22

PermitOpen легко забыть и потом час ловить administratively prohibited. Сначала проверяю, что ProxyJump жив без него, потом сужаю. Логи sshd на прыжке смотрю не «красиво ли», а кто и куда просил forward: если из сессии ops вдруг полезли на адрес, которого в заявке не было, это уже не удобство, а инцидент.

Мелочи, из-за которых «прыжок не работает»

Частая жалоба: «с -J меня не пускает, а два ручных ssh работают». Почти всегда одно из трёх.

Первое — разные пользователи. На jump вы ops, на проде deploy, а в команде указали одного. В конфиге это два User. В -J — явно ops@jump и deploy@prod.

Второе — DNS. Ноутбук не резолвит prod-web-01.internal, а bastion резолвит. ProxyJump соединяет туда, куда сказал клиент. Если клиент не знает имя, пишу в HostName адрес, который виден с прыжка, либо завожу имя в локальный /etc/hosts только как метку. Обратная ловушка: в HostName поставили внешний IP прода, которого с прыжка нет — ручной второй ssh с jump шёл на внутреннее имя, а ProxyJump пытается в белый адрес.

Третье — ключи и агент. Клиент предлагает ключ джампа на прод, прод отвечает «не тот» несколько раз и отваливается. Лечится IdentitiesOnly и отдельным IdentityFile. Если ключ в агенте один, а файлов много, агент всё равно может предложить не то: поэтому для прод-хостов я указываю файл явно.

Четвёртое, реже: ControlMaster. Мультиплекс на jump удобен, но старый сокет иногда держит чужие опции. Если после правки конфига поведение «как раньше», сношу сокеты ~/.ssh/cm-* и проверяю ещё раз.

Что я отказываюсь считать решением

Не считаю решением скопировать закрытый ключ на bastion «только на время работ». Файл переживает работы. Его найдёт следующий, кто зайдёт под той же учёткой.

Не считаю решением глобальный ForwardAgent yes «потому что так в wiki». Wiki часто писали, когда ProxyJump ещё не было в клиенте по умолчанию. Сейчас клиент это умеет давно.

Не считаю решением один ключ на всё: ноутбук, jump, прод, git, CI. Отзыв после утечки тогда равен «перевыпустить жизнь». Два-три ключа с понятной ролью дешевле нервов.

Не считаю решением «у нас на джампе свои люди, нам не надо». Свои люди оставляют tmux, ставят тестировать бинарник, дают sudo на час. Агент в этот час работает на всех.

Считаю решением короткую схему, которую можно проговорить вслух: ключ прода живёт на ноутбуке, прыжок только прокидывает TCP, агент выключен, кроме одной явно названной машины, и на диске bastion нет ни одного id_* без суффикса .pub. Это скучно. Зато когда bastion однажды вскроют — а интернет-машину вскрывают — прод не откроется тем же ключом из чужой сессии.

Я не продаю «умный дом, который сам всё спасёт». Мне нужно одно: когда я не дома, машины должны успеть сами размонтировать диски и погаснуть в правильном порядке. Ниже — как я это собираю, что ломается, если порядок перепутать, и что смотреть утром, если ночью свет всё-таки ушёл.

Хосты в примерах вымышленные: nas.home.lan, pc-office, nut-master. Свои имена, VLAN и модель ИБП подставляйте.

Почему «ИБП стоит» ≠ «файловая система целая»

Журнал ext4, NTFS dirty bit, ZFS intent log — это подушки. Они уменьшают шанс полной смерти тома, но не отменяют простой факт: если в момент отключения шёл сброс кэша, дописывался RAID-страйп или клиент держал открытый файл по SMB, вы ловите как минимум долгий fsck и «тихую» порчу одного файла. На NAS это особенно обидно: локальный диск ПК ещё можно пережить, а общий том — уже заявка «откати бэкап, но не вчерашний».

ИБП даёт время. Не бесконечное. Бытовой line-interactive на NAS + роутер + коммутатор часто держит от нескольких минут до четверти часа под реальной нагрузкой. Если за это время никто не начал shutdown, батарея просто кончится. Тогда ИБП либо уйдёт в bypass и потухнет, либо сам отрубит розетки. Для дисков разницы почти нет: питание пропало на работающей ФС.

Отдельная ловушка — «умные» розетки и сценарии вроде «через 60 секунд после пропадания 220 отключить NAS, чтобы экономить батарею». Это не shutdown. Это тот же hard power-off, только реле сработало красиво. Резать питание можно только после того, как ОС сама погасла.

Порядок, который я держу в голове

Клиенты с сетевыми дисками выключаются раньше хранилища. Хранилище — раньше, чем сеть, по которой ему пришла команда. Монитор ИБП (тот, у кого USB в ИБП) гаснет последним из компьютеров. Коммутатор и роутер живут до последнего: без них команда shutdown до NAS не доедет.

На пальцах для типичной квартиры/небольшого офиса:

• Короткий моргающий свет (секунды) — ничего не выключаю. Только пишу в лог ONBATT и, если настроено, шлю уведомление.
• Питание так и не вернулось, батарея ушла в «мало» или осталось несколько минут рантайма — начинаю сценарий.
• Сначала ПК, тонкие клиенты, виртуалки, которые держат SMB/NFS/iSCSI на NAS. Им нужно сбросить кэш и отпустить файлы.
• Потом сам NAS: unmount, flush, штатный poweroff. DSM/TrueNAS на это могут занять пару минут, не секунды.
• Потом хост, который видит ИБП по USB (NUT master). Он же в конце может дать ИБП команду снять нагрузку.
• Роутер и коммутатор не трогаю сценарием. Они умрут сами, когда ИБП снимет розетки — к этому моменту компьютеры уже должны быть off.

Перепутать два места легко. Первое: NAS выключился, а pc-office ещё дописывает проект на \\nas\share. Клиент получит обрыв, локальный кэш SMB может соврать, а на томе останется недописанный файл. Второе: выключили коммутатор «чтобы экономить батарею», и NAS, который должен был принять команду по сети, её уже не услышит. Дальше NAS живёт до нуля батареи и падает как есть.

Кто вообще имеет право нажимать shutdown

USB от ИБП физически торчит в один хост. Не в два сразу: hid-драйвер не шарится. Этот хост становится источником правды: он читает OL/OB/LB, считает рантайм и рассылает остальным «пора гаснуть».

Три рабочие схемы, которые я встречаю:

• USB в NAS (Synology/TrueNAS). NAS сам гаснет по своему «UPS». Остальные машины либо клиенты NUT/Synology UPS Server, либо их вообще нет в сценарии. Минус: если ПК с примонтированными шарами не клиент, он переживёт NAS и умрёт позже на пустой батарее.
• USB в отдельный Linux («nut-master»). Классика Network UPS Tools: master видит ИБП, slaves слушаются. Порядок я тогда рисую скриптом на master, а не надеюсь, что все slaves погаснут «примерно одновременно».
• Вендорский агент на Windows (PowerChute и аналоги). Работает, пока в контуре один ПК. Как только появляется NAS с шарами, Windows-агент про NAS не думает. Либо добавляю NUT/SSH со стороны Linux, либо сознательно оставляю NAS единственным, кто умеет гаснуть.

Правило, которое я записываю заказчику в одну строку: кто держит диски с чужими сессиями — тот не имеет права умереть первым. NAS с открытыми SMB — не первый. Хост с USB — не первый, если он должен ещё раздать команду.

NUT: master, slave и почему «все slave» — плохой порядок

На nut-master минимум такой каркас. Имена и пароли вымышленные, в прод так не копировать.

# /etc/nut/ups.conf
[officeups]
    driver = usbhid-ups
    port = auto
    desc = "office line-interactive"

# /etc/nut/upsd.conf
LISTEN 127.0.0.1 3493
LISTEN 192.168.10.10 3493

# /etc/nut/upsd.users
[upsmon]
    password = "replace-me"
    upsmon master

# /etc/nut/upsmon.conf
MONITOR officeups@localhost 1 upsmon replace-me master
MINSUPPLIES 1
SHUTDOWNCMD "/sbin/shutdown -h now"
POWERDOWNFLAG /etc/killpower
FINALDELAY 5

LISTEN только во внутреннюю сеть, не на белый IP. upsd — не веб-морда.

На NAS или втором Linux slave выглядит так:

MONITOR officeups@192.168.10.10 1 upsmon replace-me slave
SHUTDOWNCMD "/sbin/shutdown -h now"

Если и pc-office, и nas.home.lan оба slave, NUT при FSD скажет им гаснуть почти вместе. Для меня этого мало. Клиенту нужно 20–40 секунд на unmount, NAS — минуты на сброс томов. Поэтому на master я не полагаюсь на одновременный FSD, а вешаю свой NOTIFYCMD: сначала гашу клиентов по SSH, жду, потом NAS, и только потом локальный shutdown.

Грубый скелет, без прикрас:

#!/bin/bash
# /usr/local/sbin/ups-shutdown-order.sh
# вызывается из NOTIFYCMD на ONBATT+LB или FSD, не на каждый ONBATT
set -eu
clients="pc-office.home.lan htpc.home.lan"
nas="nas.home.lan"

for h in $clients; do
  ssh -o ConnectTimeout=5 "shutdown@$h" 'sudo /sbin/shutdown -h +0' || true
done
sleep 45

ssh -o ConnectTimeout=8 "shutdown@$nas" 'sudo /sbin/shutdown -h now' || true
# DSM: часто удобнее synoshutdown / shutdown из их sudoers, не systemd
sleep 90

/sbin/shutdown -h now

Таймауты не универсальные. На живом NAS я один раз засекаю, сколько он гаснет от команды до того, как погасли дисковые LED. Это и есть нижняя граница sleep плюс запас. Если DSM выключается 2,5 минуты, sleep 30 — способ убить том почти наверняка: master погас, ИБП снял нагрузку, NAS ещё писал.

Доступ shutdown@ — отдельная учётка с sudo только на shutdown -h, ключ без пароля, только с nut-master. Не админ «на все команды».

Когда начинать: ONBATT — ещё не повод рубить всё

Короткий провал 220 я не превращаю в массовый reboot. Иначе каждый сварочный сосед и каждый ввод резерва на ТП будут по ночам гасить офис.

Смотрю статус так:

upsc officeups@localhost
# важные поля:
# ups.status     OL / OB / LB / FSD / CHRG
# battery.charge
# battery.runtime

OL — сеть есть. OB — работаем от батареи. LB — мало. FSD — forced shutdown уже идёт.

Практическая схема, которой я пользуюсь:

• ONBATT без LB — лог, письмо или Telegram, ничего не гашу. Жду 30–120 секунд: свет часто возвращается.
• Порог по рантайму, не по красивому проценту. «20%» на старой батарее может быть одной минутой. Смотрю battery.runtime и засечённое время реального гашения контура.
• Старт сценария, когда остатка хватает на: ожидание клиентов + shutdown NAS + запас. Если весь контур гасится 3 минуты, порог «осталось 4 минуты» — уже игра в кости.
• Калибровку батареи и «сколько реально держит» делаю раз в сезон, локально, не в первую командировку.

Вендорские галочки в DSM вроде «выключить при 15%» без замера рантайма я не доверяю. Процент врёт чаще, чем секунды.

Что именно вешать на батарейные розетки

На «battery backup», не на «surge only»:

• роутер и коммутатор, через который NAS получает команду;
• сам NAS;
• хост с USB в ИБП;
• ПК, которые обязаны штатно погаснуть, а не «ну переживём chkdsk».

Не вешаю лазерный принтер, обогреватель, большой монитор «ну раз розетка свободна». Они съедают минуты, которые нужны дискам. PoE-коммутатор с кучей камер может сожрать батарею быстрее NAS — тогда камеры либо на отдельный маленький ИБП, либо сознательно не входят в контур «спасти ФС».

Отдельный камень: модем провайдера. Если он не на ИБП, уведомление «свет пропал» из дома вы не получите: канал умрёт вместе с 220. На shutdown это не влияет — сценарий локальный. На ваше спокойствие в поездке — влияет. Я либо питаю ONT/модем от того же ИБП, либо не жду, что телега доедет.

Windows, DSM, TrueNAS — где люди обычно срезают угол

Windows по умолчанию не слушает NUT. Варианты, которые работают у меня без вендорской простыни: WinNUT-Client как slave, либо SSH/WinRM с master и штатный shutdown /s /t 0 /f. /f закрывает приложения принудительно — для ночного обрыва питания это меньшее зло, чем диалог «сохранить документ» до конца батареи. Для интерактивного ПК днём — неприятно, поэтому порог LB, а не первый ONBATT.

Synology: «Панель управления → Оборудование и питание → ИБП». Если USB в NAS, включаю сетевой UPS-сервер Synology, чтобы другой их же NAS или NUT-совместимый клиент получил сигнал. Если USB в Linux — DSM настраиваю как NUT slave на nut-master. Проверяю, что команда реально гасит DSM, а не пишет «событие ИБП» в журнал и живёт дальше. Разница видна один раз, если посидеть рядом с LED дисков.

TrueNAS: служба UPS — тот же NUT. Не забываю SHUTDOWNCMD и что jail/VM должны уехать до zpool. Иначе пул экспортируется, пока виртуалка ещё пишет в zvol.

systemd на Linux: shutdown -h лучше, чем systemctl halt без понимания, уйдёт ли питание. Для NUT master ещё важен POWERDOWNFLAG /etc/killpower и проверка upsmon -K на старте: ИБП после пачки shutdown должен снять нагрузку, а когда 220 вернётся — подать её снова, чтобы машины включились. Без этого батарея догорит в ноль на уже выключенных ПК, и утром часть железа не встанет, пока кто-то не нажмёт кнопку на ИБП.

Как машины должны просыпаться, когда свет вернулся

Выключение — половина. В BIOS/UEFI хоста и NAS смотрю «Restore AC Power Loss» / «After Power Loss»:

• NAS — обычно Always On. Хранилище должно подняться само.
• nut-master — тоже Always On. Иначе следующий обрыв никто не отследит.
• Офисный ПК — Last State или Off. Мне редко нужно, чтобы он сам ревел в пустой комнате.

Wake-on-LAN тут ни при чём: его некому послать, пока вы спите в другом городе. Это про поведение блока питания после возврата 220.

Роутер на ИБП сам поднимется. Если у провайдера ONT долго регистрируется, это не повод задерживать shutdown: к моменту возврата света компьютеры уже должны быть холодные.

Как я это проверяю, не надеясь на «первый настоящий обрыв»

Первый тест — только локально, днём, с руками на кнопке ИБП и с копией важных томов, которая не на этом же NAS.

• upsc в норме: OL, рантайм похож на правду, USB не отваливается в dmesg.
• Выдёргиваю входную вилку ИБП из стены, не нагрузку. Статус должен стать OB. Клиенты ещё живы.
• Жду порог или форсирую сценарий. Смотрю, что pc-office погас первым, шары отпустились, потом погас NAS, потом master.
• Засекаю время от старта сценария до момента, когда на NAS нет активности дисков. Это число кладу в sleep и в порог батареи.
• Втыкаю вилку обратно. ИБП берёт сеть, поднимает нагрузку, NAS стартует сам.

Форсировать FSD командой NUT можно, но на чужом контуре в пятницу вечером я этого не делаю. Слишком легко получить тот самый обрыв, от которого писали статью.

После теста:

# Linux / TrueNAS
journalctl -u nut-monitor -u nut-server --since today
zpool status
dmesg -T | tail

# DSM: Storage Manager / журналы ИБП, не «всё зелёное в виджете»

# Windows
wevtutil qe System /q:"*[System[EventID=6008 or EventID=6006 or EventID=41]]" /c:5 /f:text

6008 — неожиданное выключение. Если он есть после «успешного» сценария, Windows погасили питанием, не shutdown /s. Сценарий врёт.

Утро после настоящего обрыва, когда меня не было дома

Короткий список, без магии:

• Поднялся ли NAS сам. Если нет — сначала ИБП и «Restore AC», не fsck.
• Тома смонтировались без ручного repair. На ZFS — zpool status, нет ли FAULTED/UNAVAIL после внезапного питания. На DSM — Storage Manager, не «папка открывается в File Station».
• Клиенты, которые писали ночью (бэкап, 1С, камеры на шару). Открыть не «файл на месте», а хвост: последняя запись, целостность архива, не обрезан ли контейнер.
• Журнал NUT: был ли OB → сценарий → shutdown, или сразу смерть на OL (тогда ИБП не участвовал: выбили автомат после ИБП, сдох USB, уехал драйвер).
• Рантайм в логе. Если от OB до смерти прошло меньше, чем длится shutdown NAS — порог надо поднимать или разгружать ИБП.
• Батарея после серии обрывов. Старый аккумулятор «держит на экране 12 минут» и отдаёт три — это уже не настройка NUT, а замена батареи. Цены тут не считаю: если ИБП пищит и рантайм сдулся, это расходник, не «ещё чуть крутануть процент».

Если том всплыл, а один каталог странный — не чиню «на горячую» и не запускаю агрессивный repair, пока нет копии. Сначала снимок/бэкап, потом fsck. ИБП спасает от внезапного питания, но не от желания починить живой диск первой попавшейся галочкой.

Что я отказываюсь считать решением

Не считаю решением плагин умного дома «выключить розетку NAS через минуту». Не считаю решением «поставим ИБП побольше и не будем ничего гасить» — батарея всё равно кончится в длинный обрыв, плюс вы греете комнату зря. Не считаю решением только уведомление в мессенджер: в 03:00 я могу не успеть, а канал может умереть вместе с модемом.

Считаю решением короткую цепочку, которую можно проговорить вслух: кто видит USB, кто гаснет первым, сколько минут это занимает, сколько батарея реально держит, и что должно включиться само, когда 220 вернётся. Это скучно. Зато утром NAS монтирует том, а не просит «ваш диск был извлечён неправильно».

Это не одна настройка. XML-RPC — старый вход в PHP-файл. Application Passwords — отдельные пароли к REST API (и, если xmlrpc не закрыт, ещё и к нему же). Двухфакторка на wp-login.php вторую дверь не закрывает. Ниже — как я решаю, что оставлять, что резать на nginx, и где «плагин запретил xmlrpc» оставляет дыру, которой хватает боту.

Хосты в примерах вымышленные: shop.example. Свои пути, пользователя и префикс логов подставляйте.

Две двери, не «один API WordPress»

На живом сайте обычно торчат три способа что-то сделать «не из браузера»:

• /xmlrpc.php — XML-RPC. Методы вроде wp.getUsersBlogs, wp.newPost, pingback. Клиент шлёт логин и пароль в теле XML на каждый запрос.
• /wp-json/ — REST API. Gutenberg, приложение, ваш скрипт, куча плагинов. С WordPress 5.6 туда ходят Application Passwords через HTTP Basic Auth.
• /wp-login.php — человек в браузере. Сюда Application Password не подходит: это не замена пароля учётки для формы входа.

Путаница начинается здесь. Человек включает 2FA и считает, что «без телефона никто не войдёт». Для формы логина — да. Для xmlrpc, если он принимает основной пароль пользователя, второго фактора нет. Бот не открывает браузер и не вводит код из приложения.

Вторая путаница: «раз есть Application Passwords, xmlrpc больше не нужен, WordPress сам его выключит». Не выключит. Это разные стеки. Пароль приложения, если xmlrpc жив, подходит и туда: в документации ядра прямо сказано, что Application Password можно подставить вместо обычного пароля в XML-RPC. То есть вы завели «безопасный» токен для REST, а старый файл его тоже съест.

Третья: галочка в плагине «Disable XML-RPC». Часто это фильтр xmlrpc_enabled. Он отключает методы, которым нужна авторизация. Файл при этом открывается, PHP крутится, pingback и часть методов без логина могут отвечать. Для бота, которому нужно занять php-fpm, этого достаточно. Для меня критерий «закрыто» — nginx/apache не отдают этот URI в PHP, а не «в админке галочка зелёная».

Зачем xmlrpc вообще существует в 2026-м

Когда-то это был нормальный способ писать с телефона и цеплять Jetpack. Сейчас на большинстве витрин, которые мне отдают, в access.log по xmlrpc.php нет ни одного своего User-Agent. Есть словари паролей, system.multicall и pingback на чужие сайты.

Две атаки, из-за которых я не оставляю файл «на всякий случай»:

• Брутфорс пачкой. system.multicall в одном HTTP-запросе прогоняет десятки wp.getUsersBlogs с разными паролями. Лимитер по запросам на IP видит один POST. Лимит без закрытия multicall — полумера: словарь укладывается в один хит.
• Pingback как чужой молоток. Сайт принимает pingback.ping и сам идёт на URL, который подсунули. Либо участвует в отражённой нагрузке, либо светит внутренние адреса, если кто-то целится в SSRF. Даже без успешного логина файл уже не бесплатный.

Jetpack, официальное приложение WordPress старых версий, часть сервисов рассылки и редкие десктопные клиенты xmlrpc ещё используют. Поэтому я не ставлю deny all вслепую на проде, пока не посмотрел неделю логов. Но «вдруг пригодится» — не причина держать вход, который умеет перебирать пароль администратора без 2FA.

Что такое Application Passwords на практике

С WordPress 5.6 у пользователя в профиле появляется блок «Пароли приложений». Вы даёте имя («backup-bot», «магазин-контент», «телефон редактора»), ядро показывает 24 символа один раз, дальше пароль лежит хешем в user meta. Пробелы в отображении можно не копировать — перед проверкой их срезают.

Зачем это, если «и так есть пароль админа»:

• Основной пароль не разъезжается по скриптам, телефону и подрядчику. Сменили пароль учётки после увольнения — бот с Application Password продолжает жить, пока его явно не отозвали. Это и плюс, и минус: ротация учётки дыру не закрывает.
• Отзыв точечный. Удалили один пароль — отвалилось одно приложение, редактор в браузере не вылетел.
• 2FA на логине можно держать жёсткой. Скрипту второй фактор не нужен, человеку — нужен. Раньше из-за xmlrpc люди 2FA не включали: «приложение не зайдёт».
• В профиле видно, когда пароль последний раз использовали и с какого IP. Не в реальном времени до секунды, с задержкой примерно до суток, но «висит полгода, last used — никогда» уже повод снести.

Ходят они по HTTPS Basic Auth: логин учётки плюс этот пароль. Без HTTPS ядро по умолчанию блок даже не показывает: иначе пароль утечёт на первой же кофейне. Если сайт за прокси и WordPress думает, что он на http, в профиле пусто. Тогда сначала чинят HTTPS/X-Forwarded-Proto, а не «включают фильтр разрешить без SSL». Разрешить Application Passwords по http — сознательно оставить секрет в открытую на участке до прокси.

Права у такого пароля — права пользователя, не «только читать посты». Завели под администратором — получили администратора. Для заливки черновиков мне хватает роли автора или редактора и отдельной учётки, не «ещё один токен на admin».

Как я смотрю, кто чем пользуется

Пока нет картины за несколько дней, я ничего не отключаю на живом магазине. Сначала логи, потом решение.

Nginx, если access_log в обычном combined:

# пути к логам подставьте свои
awk '$7 ~ /xmlrpc\.php/ {print $1,$4,$9,$11}' /var/log/nginx/shop.example.access.log | tail -n 50
awk '$7 ~ /xmlrpc\.php/ {c[$1]++} END {for (i in c) print c[i], i}' /var/log/nginx/shop.example.access.log | sort -n | tail
awk '$7 ~ /wp-json\// {print $1,$9,$7}' /var/log/nginx/shop.example.access.log | awk '{print $3}' | sort | uniq -c | sort -n | tail

Что я хочу увидеть:

• По xmlrpc: либо пусто, либо одни и те же /24 из сканеров, статус 200 на POST. Свой телефон обычно один-два IP, предсказуемый интервал, не 400 запросов в минуту.
• User-Agent. Jetpack и приложение WordPress не маскируются под Mozilla/5.0 с кривой кодировкой. Сканеры часто пишут xmlrpc, пусто или «WordPress» без версии.
• По REST: Gutenberg с админки будет, это норма. Смотрю, есть ли POST/PUT с внешних IP на /wp-json/wp/v2/posts или media. Если есть — это живой клиент, его нельзя убить вместе с xmlrpc.

Проверка «файл вообще отвечает», не из лога:

curl -sS -D - -o /dev/null https://shop.example/xmlrpc.php
curl -sS https://shop.example/xmlrpc.php \
  -H 'Content-Type: text/xml' \
  -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>' | head

200 и список методов — дверь открыта, даже если «плагин безопасности установлен». 403/404 с nginx без X-Powered-By и без тела PHP — уже похоже на правду.

REST и доступность Application Passwords:

curl -sS https://shop.example/wp-json/ | python3 -m json.tool | head
# в корне смотрю ключ authentication.application-passwords
curl -sS -u 'editor:xxxx xxxx xxxx xxxx xxxx xxxx' \
  https://shop.example/wp-json/wp/v2/users/me

Если в корне authentication пустой — либо HTTP, либо фича выключена фильтром, либо что-то по дороге срезает заголовок Authorization. Последнее на nginx с PHP-FPM встречается: CGI не пробрасывает Authorization, пока не сказать.

# внутри location ~ \.php$
fastcgi_param HTTP_AUTHORIZATION $http_authorization;

Без этой строки «пароль приложения не работает, а обычный логин в браузере живой» — не баг WordPress, а FPM не видит Basic Auth.

Если xmlrpc никому не нужен — режу на веб-сервере

Это мой дефолт для витрины без Jetpack и без старого мобильного клиента. Фильтр в теме — вторым слоем, не вместо.

# server { ... }
location = /xmlrpc.php {
    access_log /var/log/nginx/shop.example.xmlrpc.denied.log;
    return 403;
}

deny all или return 444 тоже работают. Мне удобнее 403 и отдельный лог: сразу видно, что сканеры не исчезли, просто больше не крутят PHP. На Apache в корне сайта или в конфиге хоста:

<Files xmlrpc.php>
    Require all denied
</Files>

Правило на WAF (если он есть) дублирует, не заменяет. Когда человек правит только Cloudflare и забывает origin, прямой IP сервера xmlrpc снова открыт.

После рестарта nginx проверяю тем же curl: не 200 со списком методов, а 403 без text/html от WordPress. Затем на час оставляю отдельный лог — если вдруг вылезет свой клиент, это будет видно по IP, а не «через неделю редактор звонит, что приложение молчит».

Плагины «выключить xmlrpc» я не ставлю как основную защиту. Лишний PHP на периметре, плюс половина из них делает только xmlrpc_enabled.

Почему xmlrpc_enabled я не считаю закрытием

В functions.php или mu-plugin часто копируют:

add_filter( 'xmlrpc_enabled', '__return_false' );

Это отключает авторизованные методы. Запрос всё равно доходит до WordPress: php-fpm воркер занят, плагины загрузились, объектный кеш дёрнули. Pingback на части сборок остаётся в списке. Сканер с system.multicall получает отказ, но уже после входа в PHP.

Если xmlrpc по какой-то причине оставляю, вычищаю хотя бы multicall и pingback:

<?php
// mu-plugins/disable-xmlrpc-extras.php
add_filter( 'xmlrpc_methods', function ( $methods ) {
    unset( $methods['system.multicall'], $methods['system.multitask'] );
    unset( $methods['pingback.ping'], $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

Это не «можно не закрывать файл». Это минимум, если Jetpack реально нужен и закрыть location нельзя. Плюс лимит запросов на этот URI отдельно от admin-ajax.php — иначе снова либо дыра, либо свои ловят 429.

Когда xmlrpc оставляю

Короткий список, не «все интеграции»:

• Jetpack и связанные сервисы Automattic, если они включены сознательно, а не «поставили и забыли».
• Старое официальное приложение WordPress, которое ещё ходит в xmlrpc, а не в REST. Новые клиенты умеют Application Passwords и REST — их я перевожу.
• Редкий десктопный клиент публикации, который заказчик не готов менять сегодня.

Если оставляю, пароль приложения завожу под отдельным пользователем с нужной ролью, основной пароль этой учётки длинный и никуда не светится, 2FA на человеческих админах включена. xmlrpc тогда принимает Application Password, и утечка основного пароля админки не даёт боту этот вход. Обратное тоже верно: утечка пароля приложения — это вход в API с правами этой учётки, пока не отозвали.

Белый список IP на xmlrpc.php лучше, чем открытый мир. Для Jetpack это набор адресов Automattic, он плавает; без WAF с готовым правилом я не рисую его руками «по памяти» и не выкладываю чужие схемы. Практичнее: либо официальное правило у CDN, либо закрыть xmlrpc и жить на REST.

Application Passwords: заводить, не размножать, уметь выключить

Правила, без которых я токен не создаю:

• Одно приложение — один пароль. Не «один на все скрипты», чтобы потом не гадать, какой cron его светит.
• Имя в профиле человеческое: rsync-report bot, iPhone редактор, не test и не 1.
• Учётка с минимальной ролью. Для черновиков не нужен администратор. Для медиа — часто хватает автора.
• Пароль копирую в секрет хранилища один раз. В чат, в тикет и в тело статьи его не кладут. В логах nginx он не должен появиться: Basic Auth лучше не писать в access_log.
• Раз в квартал смотрю last used. Не использовался — удаляю, не «вдруг пригодится».

Через WP-CLI, если SSH есть:

cd /var/www/shop.example/public_html
wp user list --fields=ID,user_login,roles
wp user application-password list editor --fields=uuid,name,created,last_used,last_ip
# создать и сразу забрать только секрет, без таблицы
wp user application-password create editor 'content-bot' --porcelain
# отозвать по uuid из списка
wp user application-password delete editor 00000000-0000-4000-8000-000000000000

Если Application Passwords на сайте никто не использует (нет мобильного клиента, нет внешних скриптов, черновики пишут руками), я их выключаю. Иначе любой администратор может завести себе токен, а через дырявый плагин или XSS это делают уже не только администраторы.

<?php
// mu-plugins/disable-application-passwords.php
add_filter( 'wp_is_application_passwords_available', '__return_false' );

Точечно, только выбранным ролям:

<?php
add_filter( 'wp_is_application_passwords_available_for_user', function ( $allow, $user ) {
    if ( $user instanceof WP_User && in_array( 'administrator', (array) $user->roles, true ) ) {
        return $allow;
    }
    return false;
}, 10, 2 );

Выключить и забыть отозвать уже выданные пароли — мало. Фильтр закрывает новые и использование, но я всё равно прохожусь по списку и удаляю старые: меньше сюрпризов, когда фильтр кто-то снимет «чтобы приложение заработало».

REST я не вырубаю «за компанию»

После статьи про xmlrpc находится человек, который в плагине безопасности ставит Disable REST API. Gutenberg после этого рисует белый экран, кастомайзер полуживой, часть блоков не сохраняется. REST — не xmlrpc. Это штатный транспорт админки.

Что я ограничиваю, не выключая REST целиком:

• Публичный список пользователей. На многих сайтах GET /wp-json/wp/v2/users без авторизации отдаёт логины. Для брутфорса это подарок: не надо угадывать admin. Плагин безопасности или маленький mu-plugin, который на rest_authentication_errors закрывает users для анонимов, — нормальная гигиена. Слепой «REST off» — нет.
• Лимит на /wp-json/ на краю, отдельно от html, если вижу перебор. Не общий location ~ \.php$.
• Не торчит ли создание Application Passwords для всех ролей, если фича нужна только админу.

Проверка, светит ли сайт логины:

curl -sS 'https://shop.example/wp-json/wp/v2/users' | python3 -m json.tool | head

Если в ответе массив с slug — аноним уже знает, кого подбирать. Это не «дыра нулевого дня», это дефолт, который я закрываю в тот же вечер, что и xmlrpc.

Какие комбинации я считаю нормальными

Свожу к трём схемам, без зоопарка галочек.

1. Витрина, правки из браузера, нет Jetpack, нет внешних ботов. xmlrpc на nginx 403. Application Passwords выключены фильтром. 2FA на администраторах. REST живой, список users для гостя закрыт. Это большинство сайтов, которые мне отдают «просто посмотрите безопасность».
2. Нужен скрипт или телефон. xmlrpc всё равно 403, если клиент умеет REST. Одна учётка с ролью по задаче, один Application Password, HTTPS доведён до ядра, Authorization проброшен в FPM. Основной пароль этой учётки не совпадает с паролем приложения и никуда не записан в cron.
3. Jetpack или старый клиент, без них пока никак. xmlrpc открыт, multicall и pingback сняты, лимит на URI, по возможности ограничение по источнику на WAF. Пароли приложений для этого клиента, не основной пароль админа. Остальным пользователям Application Passwords не светятся.

Схема, которую я снимаю сразу: 2FA «для галочки», xmlrpc открыт на мир, в cron лежит основной пароль администратора, в профиле три пароля приложения с именами test/test2/asdf, REST отдаёт users. Это не «чуть-чуть не донастроили». Это три входа с одним секретом и одним без второго фактора.

Что проверить за ночь, а не сразу закрыть ноутбук

После изменений я не верю одному curl с ноутбука. За ночь видно, не отвалился ли свой клиент и не начал ли сканер долбить соседнюю дверь.

• Отдельный лог 403 по xmlrpc: есть чужие POST, нет 200 в php-fpm slowlog по этому файлу.
• В access.log нет всплеска 401/403 на /wp-json/wp/v2/ с офисного IP. Если есть — вы закрыли не то, или срезали Authorization.
• Админка открывается, запись сохраняется, медиа грузится. Gutenberg ходит в REST; если его прибили, узнаете утром от редактора, не из мониторинга.
• wp user application-password list по всем, у кого не пусто: имена понятные, last_ip свой, лишние удалены.
• Повторный curl на /wp-json/wp/v2/users без куки — не список логинов.
• Плагин безопасности не включил обратно xmlrpc своим «режимом совместимости» и не выключил REST. После обновления плагинов это проверяю отдельно.

Если за ночь в xmlrpc-логе вдруг свой IP приложения — не открываю файл обратно «как было», а перевожу клиент на REST и Application Password. Старый xmlrpc ради одного телефона на витрине с заказами я оставляю только когда перевод реально нельзя сделать сегодня, и тогда это временная схема с датой, а не новая норма.

Я почти всегда нахожу одно и то же. Кто-то сделал в phpMyAdmin REPLACE по option_value или прогнал дамп через «найти и заменить» в редакторе. Поля siteurl и home в wp_options — обычные строки, они меняются и сайт «как будто живой». Виджеты, theme_mods, ACF, настройки кэша и куча plugin-опций лежат как PHP-сериализация. Наивная замена портит длину строк внутри этой каши. unserialize() возвращает false, WordPress считает «настроек нет» и рисует пустые сайдбары.

Ниже — как я перевожу домен, чтобы не чинить потом сериализацию руками. Хосты в примерах вымышленные: old.example → shop.example. Свои домены, префикс таблиц и путь к сайту подставляйте, чужой дамп из интернета на прод не накатывайте.

Почему обычный REPLACE ломает сайт

PHP пишет строку не как «текст», а как «длина плюс текст». Упрощённо:

s:19:"https://old.example";

«19» — это число байт внутри кавычек, не «примерно длина». Если в дампе или SQL вы меняете old.example на shop.example, букв становится больше, а префикс s:19: остаётся. Для интерпретатора это уже не валидная сериализация. Массив вокруг тоже разваливается: один битый кусок — и весь option «не читается».

Отсюда картина, которую путают с «плагин не перенёсся»:

• Админка работает: логин, список записей, даже медиатека. Это не сериализация, это обычные таблицы.
• Виджеты пустые или «сбросились на дефолт». Классика — sidebars_widgets и widget_*.
• Кастомайзер/меню выглядят как новый сайт на чистой теме: theme_mods_* не распаковался.
• Страница открывается, визуальный редактор — нет. У конструкторов URL ещё и в JSON/CSS, не только в serialize.
• В PHP-логах за ночь: unserialize(): Error at offset … на option_value или postmeta. Это не «хостер глючит», это вы вчера поправили домен в БД.

siteurl/home я вообще не считаю критерием успеха. Их можно поменять руками за минуту. Критерий — живые виджеты, меню, конструктор и отсутствие старого хоста в опциях, которые WordPress реально читает.

Что я снимаю до любой замены

Пока не лежит откат, я замену не запускаю. Испорченная сериализация откатывается из дампа за две минуты и чинится «на глаз» полдня.

Минимум:

• Дамп базы до замены, не «сейчас сниму, если что». И файл не в wp-content/uploads этого же сайта.
• Архив файлов: тема, uploads, mu-plugins. Конструкторы после смены домена часто оставляют CSS со старым хостом уже в файлах, не в MySQL.
• Текущие siteurl и home, плюс константы из wp-config.php. Если заданы WP_HOME/WP_SITEURL, база может врать, а сайт всё равно ходить на старый адрес — или наоборот, «замена в БД не действует».
• Список вариантов URL, которые реально встречаются. Не один «красивый» https.

Варианты, которые я выписываю в блокнот до команды, не в процессе:

https://old.example
http://old.example
https://www.old.example
http://www.old.example
//old.example
old.example

Слеш на конце — отдельная история. В опциях чаще без него, в контенте и в JSON конструктора бывает с ним. Менять «с слэшем» и «без» двумя проходами безопаснее, чем надеяться, что один проход поймает оба.

Голый old.example без схемы я оставляю на последний проход и смотрю отчёт: он может задеть e-mail вида shop@old.example, CDN, упоминания в тексте. Если почта на этом домене остаётся — голый хост не трогаю или меняю точечно.

Префикс таблиц не угадываю:

# каталог сайта подставьте свой
cd /var/www/example-site/public_html
wp config get table_prefix
wp option get siteurl
wp option get home
wp config get WP_HOME
wp config get WP_SITEURL

Если две последние константы заданы и расходятся с тем, куда вы переезжаете, сначала правлю wp-config.php. Иначе search-replace в базе вы сделаете, а WordPress продолжит считать каноническим старый URL.

WP-CLI: основной путь

На VPS и нормальном хостинге с SSH я не открываю phpMyAdmin для этой задачи. wp search-replace ходит по ячейкам, понимает PHP-сериализацию (и в свежих версиях — JSON), первичные ключи не трогает.

Сначала сухой прогон, чтобы увидеть масштаб, а не «сразу на прод»:

cd /var/www/example-site/public_html

wp search-replace 'https://old.example' 'https://shop.example' \
  --all-tables-with-prefix \
  --precise \
  --dry-run \
  --report-changed-only

--all-tables-with-prefix нужен потому, что дефолт — таблицы, которые WordPress зарегистрировал в $wpdb. У Magento-в-WP это не про нас, а у WooCommerce, форм, кэша, самописных плагинов таблица wp_something_extra легко остаётся со старым хостом. --all-tables без префикса я на шареде с общей MySQL не включаю: можно вылезти в чужую базу на том же пользователе.

--precise гоняет замену через PHP, не через быстрый SQL. Медленнее, зато меньше шансов проскочить колонку, где сериализация не похожа на «очевидную». На магазине в сотни мегабайт дампа это не мгновенно — зато не потом ночью ловить пустую корзину.

Если сухой прогон выглядит здраво (есть попадания в wp_options, postmeta, может быть post content — и нет сюрприза в wp_users.user_email на тысячи строк), снимаю ещё один свежий дамп и запускаю без --dry-run.

GUID записей я обычно пропускаю:

wp search-replace 'https://old.example' 'https://shop.example' \
  --all-tables-with-prefix \
  --precise \
  --skip-columns=guid \
  --report-changed-only

guid в WordPress — идентификатор, не «красивая ссылка». Менять его при переезде домена не обязательно, а фиды и импорты от этого иногда едут. Если у вас старый зоопарк, где в GUID руками писали permalink — смотрите отчёт dry-run по колонке и решайте точечно, не «всем REPLACE».

Дальше те же команды для http://, www и протоколо-относительного //old.example. Один проход по «основному» https почти никогда не вычищает всё: редирект на https могли включить год назад, а в виджете 2019 года лежит http.

Если WP-CLI есть на старом сервере, а на новом ещё нет, удобен экспорт уже с заменой:

wp search-replace 'https://old.example' 'https://shop.example' \
  --all-tables-with-prefix \
  --precise \
  --skip-columns=guid \
  --export=/root/shop-example-after-replace.sql

Накатываю этот SQL на новое место, а не «сырой дамп плюс sed». sed по .sql — тот же класс ошибки, что REPLACE в phpMyAdmin, только в файле на 400 МБ её ещё и не видно.

Если WP-CLI нет

На дешёвом shared без SSH люди ставят плагин вроде Better Search Replace. Под капотом та же идея, что у interconnect/it: идти по ячейкам и пересобирать serialize. Это лучше, чем правка дампа. Это хуже, чем WP-CLI, потому что плагин работает из-под веба, на больших таблицах упирается в timeout, и его ещё надо не забыть удалить.

Правила, без которых я этот путь не рекомендую:

• Сначала дамп. Плагин «умеет dry-run» — dry-run обязателен, как у CLI.
• Ставить, прогнать, снести. Search-Replace, оставленный в корне сайта, — готовая дыра: это скрипт с доступом к базе, который не должен торчать в интернет ни минуты после работы.
• Не мешать в одном заходе «домен» и «путь на диске». Это разные строки. Путь /home/u1234/public_html в сериализации тоже бывает, его меняют отдельно, когда переезд ещё и на другой аккаунт хостинга.

Перенос «архивом плагина миграции» (Duplicator и родственники) сериализацию обычно переживает, потому что замену они делают своим движком, не вашим REPLACE. Имеет смысл, когда нет SSH. Не имеет смысла, когда вы уже на VPS и можете одну команду. Я не тащу лишний плагин на прод ради смены домена.

Что search-replace не видит

База — не весь сайт. После удачной замены в MySQL у меня регулярно всплывает старый хост в файлах.

cd /var/www/example-site/public_html
grep -R --binary-files=without-match -l 'old.example' \
  wp-content/themes wp-content/plugins wp-content/mu-plugins \
  wp-content/uploads wp-config.php 2>/dev/null | head

Типичные находки:

• WP_HOME/WP_SITEURL в wp-config.php — перекрывают базу, спор «я же заменил в опциях» решается здесь.
• CSS/JSON конструктора в wp-content/uploads/elementor/ (и аналоги у других билдеров). Это файлы. Их WP-CLI не трогает. У Elementor после смены домена я ещё регенерирую CSS из админки или, если есть их CLI, отдельной командой замены URL, не надеясь только на MySQL.
• Жёстко прошитый адрес в дочерней теме: логотип, пиксель, кастомный endpoint. Это уже код, не контент.
• Объектный кэш. Redis/Memcached продолжает отдавать старые сериализованные blobs. После замены — flush. Иначе «в базе уже новый домен, в браузере старый» до истечения TTL, и вы начнёте чинить то, что уже починено.

Мультисайт — не тот же чеклист. Там wp_blogs, wp_site, домены блогов, и CLI нужно звать с --url конкретного сайта плюс --network, когда меняете сразу сеть. Если у вас не мультисайт, не копируйте чужие однострочники с --network «на всякий случай».

Как понять, что сериализация жива

Первая проверка — не «главная открылась». Я смотрю то, что сериализация обычно убивает, и то, что REPLACE обычно забывает.

# канонические URL — уже новый домен, без редиректа в голове
wp option get siteurl
wp option get home

# остатки старого хоста по всем таблицам с префиксом
wp db search 'old.example' --all-tables-with-prefix --table_column_once

# виджеты реально читаются, не «таблица на месте»
wp widget list sidebar-1
wp option get sidebars_widgets

Если sidebars_widgets печатает массив с именами сайдбаров — сериализация этого option жива. Если пусто, false или PHP Notice на unserialize — откатились к дампу, не «восстанавливаем виджеты руками».

Грубый проход по опциям, которые WordPress считает сериализованными, но уже не может распаковать:

wp eval '
foreach ( wp_load_alloptions() as $name => $value ) {
  if ( ! is_serialized( $value ) ) { continue; }
  $restored = @unserialize( $value );
  if ( $value === "b:0;" || $restored !== false || $value === serialize( false ) ) { continue; }
  echo $name, PHP_EOL;
}
'

Пустой вывод — хороший знак. Имена вроде widget_block, theme_mods_…, external_updates в этом списке — плохой: именно они после «успешного» REPLACE приезжают битыми.

В админке руками:

• Внешний вид → Виджеты / редактор блоков виджетов: блоки на месте, не пустой холст.
• Меню и расположения меню. «Меню существует, но нигде не назначено» часто значит, что theme_mods не прочитался.
• Медиа: открыть пару старых записей, не главную. В контенте https://old.example/wp-content/uploads/… после нормальной замены быть не должно.
• Конструктор: открыть на редактирование страницу, которую точно верстали не вчера. Белый экран при живой публичной странице — почти всегда JSON/CSS со старым хостом или битая meta.

Смешанный контент (главная по https, картинки по http старого домена) я проверяю не глазами, а по исходнику и по логам. Браузер может дорисовать из кэша.

Что смотреть overnight

Днём вы видите то, что кликнули. Ночью всплывает cron, письма и боты.

За ночь мне нужны:

• Письма сайта: сброс пароля, WooCommerce, формы. В теле и в заголовке From/ссылках не должен торчать старый хост. Это часто не siteurl, а отдельная опция плагина или константа SMTP.
• Cron: wp cron event list и системный crontab. Старый URL в HTTP-cron (wget на wp-cron.php) продолжает дергать прежний домен, пока DNS жив.
• Карта сайта и robots: плагины SEO пишут абсолютные URL. Rank Math/Yoast после переезда я открываю и пересохраняю карту, не надеясь, что «само подхватит».
• Редирект со старого домена. Пока он не 301 на тот же путь нового, Google и закладки клиентов будут кормить оба хоста. Сам search-replace редирект не настраивает — это nginx/хостер.
• Логи PHP на unserialize и на mixed content в error_log. Одна-две строки offset — повод не «подождать», а свернуть на дамп и прогнать замену нормально.
• REST и превью: /wp-json/ должен отдавать новый home в url/home. Иначе мобильные приложения и часть плагинов продолжают стучать на старое имя.

Если старый домен ещё резолвится в тот же DocumentRoot без редиректа, вы будете неделю ловить «то новый, то старый» в кэше и в сериализации, которую кто-то снова сохранит из админки, зайдя по старому имени. Схема одна: один канонический хост, второй только 301, константы и опции смотрят на канон.

Переезд домена в WordPress — это не «поменять две опции в wp_options». Две опции как раз переживают любой REPLACE. Ломается то, что вы не видите в phpMyAdmin с первого экрана: длины строк внутри serialize. Я меняю URL инструментом, который эти длины пересчитывает, потом отдельно ищу хвосты в файлах и кэше, и только после живых виджетов и пустого поиска по старому хосту считаю переезд состоявшимся — не в момент, когда открылась главная.

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

Ниже — порядок, которым я хожу по взломанному WP, когда нужно не «почистить то, что нашёл сканер», а понять, чем держится зараза, откуда зашли и что сделать, чтобы после смены пароля админа сайт не поднял шелл снова через час. Примеры путей и имён — типовые, не с конкретного клиента. Хосты и IP в логах подставляйте свои, чужие из интернета копировать вместе с «готовым лечением» не стоит.

Сначала стоп, снимок, доступ мимо wp-admin

Первое желание — зайти в админку и «поудалять левых пользователей». Если в теме или в mu-plugins сидит стилер куку, вы только подтвердите злоумышленнику, что хозяин на сайте, и отдадите свежую сессию.

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

Снять снимок, который можно откатить. На VPS — снапшот диска у хостера плюс архив каталога сайта и дамп базы на свою машину, не «бэкап плагином на этот же wp-content/uploads». На shared-хостинге — хотя бы tar корня сайта и mysqldump через панель или SSH. Если снимка нет, любое удаление файла потом не докажет, что именно он слал спам.

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

• В nginx/apache — отдать 503 на все PHP, кроме своего IP. Не «maintenance mode плагином»: его как раз и обходят.
• Временно подменить index.php в корне на статическую заглушку, оригинальный файл сохранить как index.php.orig рядом. Корень WP трогать аккуратно: не путать с index.php темы.
• На хостинге без SSH — закрыть каталог через панель / .htaccess по IP, если хостер это умеет. Если не умеет — хотя бы сменить пароли FTP и панели до того, как начнёте качать файлы на домашний ПК.

Дальше захожу по SSH или SFTP. wp-admin использую только когда уже понял, что сессия оттуда не исполняет чужой PHP. Почту, Telegram-ботов сайта и SMTP-плагин на время инцидента тоже считаю скомпрометированными: с них часто уходит фишинг от имени магазина.

Пока не закрыли вход, параллельно снимаю «кто ещё живой»: соседние сайты на том же аккаунте, cron пользователя, панели ISPmanager/cPanel. Один шелл в соседнем каталоге /var/www/site2 через час снова положит «уже почищенный» WP.

Что считать уликой, а не ощущением

«Выглядит странно» — плохой критерий. Мне нужны время, путь и факт изменения. Минимальный набор, который я забираю целиком, до того как начну удалять:

• Корневой wp-config.php, .htaccess в корне, в wp-admin и в uploads (их часто дописывают отдельно).
• Drop-in файлы в wp-content: object-cache.php, advanced-cache.php, db.php, sunrise.php. Их сканеры ядра не считают «ядром», и туда любят класть одну строку include.
• Каталог wp-content/mu-plugins — must-use подключается всегда, без галочки в админке. Если зараза там, «деактивировать плагины» ничего не делает.
• Список пользователей ОС и crontab: crontab -l, /etc/cron.d/, /var/spool/cron/. PHP-шелл, который раз в пять минут дописывает себя в index.php, переживает любую «очистку файлов сайта».
• Логи веб-сервера за неделю-две, не за последний час. Нужны access и error, плюс PHP-fpm slowlog, если есть. POST на странный .php в uploads — классика.

По файлам смотрю не «все php в uploads», а свежие и с чужим владельцем:

# каталог сайта подставьте свой, не копируйте путь с чужого сервера
SITE=/var/www/example-site/public_html

find "$SITE" -type f -mtime -14 -printf '%TY-%Tm-%Td %TH:%TM %u:%g %p\n' | sort

find "$SITE/wp-content/uploads" -type f \( -name '*.php' -o -name '*.phtml' -o -name '*.phar' -o -name '.*.php' \) -print

find "$SITE" -type f \( -name '.*.ico' -o -name 'wp-*.php' -o -name '*timthumb*' \) -path '*/uploads/*' -print

ls -la "$SITE/wp-content/" "$SITE/wp-content/mu-plugins" 2>/dev/null
ls -la "$SITE/wp-content/"object-cache.php "$SITE/wp-content/"advanced-cache.php "$SITE/wp-content/"db.php 2>/dev/null

Свежий wp-login.php с датой «сегодня» при том, что ядро вы не обновляли — уже повод сверить контрольные суммы, а не «ну это же ядро, его не трогают». Свежий файл в wp-includes с именем вроде wp-vcd.php / class-wp-http-proxy.php рядом с настоящим классом — ещё чаще.

Владелец тоже врёт, если зараза работает от php-fpm того же пользователя, что и сайт. Тогда все файлы «как надо». Смотрите дату и содержимое, не только ls -l.

Ядро сверяю с эталоном, плагины — с zip из репозитория

WordPress умеет сам сказать, какие файлы ядра не совпали. С заражённой админки этой кнопке я не доверяю: подменённый update-core.php вам улыбнётся и покажет зелёное. С хоста, где есть wp-cli и исходящий HTTPS, или просто скачав zip той же версии:

# версию брать из wp-includes/version.php, не «ну наверное 6.4»
grep wp_version "$SITE/wp-includes/version.php"

# на чистой машине:
# curl -fsSLO "https://wordpress.org/wordpress-X.Y.Z.zip"
# unzip и rsync -avnc --delete ядра БЕЗ wp-content и без wp-config.php

wp core verify-checksums --path="$SITE"
wp plugin verify-checksums --all --path="$SITE"
wp theme verify-checksums --all --path="$SITE"

verify-checksums по плагину работает только для того, что лежит в wordpress.org. Платный Elementor, самопис, «нулёвая» тема с warez-сайта — для них эталона нет. Нулёвая тема — отдельный красный флаг: в ней бэкдор часто был с момента установки, и «вирус пришёл сам» тут ни при чём.

Что делать с расхождениями в ядре: не править файл руками «вырезать eval». Заменить пакет ядра целиком из официального zip. Исключения — wp-config.php и каталог wp-content. Если правили сами wp-config.php (соль, префиксы, константы) — файл не из zip, его сверяют глазами, не перезаписывают молча.

Плагин с расхождением: снимаю копию, ставлю тот же zip с wordpress.org. Если плагин платный — zip с кабинета разработчика, не «с форума, он тот же». Самопис, который «нам верстальщик оставил», читаю целиком. Там же часто лежит загрузчик файлов без проверки типа.

Где прячут PHP, когда «в файлах чисто»

Поиск по eval(base64_decode — полезный, но наивный. Нормальный PHP тоже бывает некрасивым. Я ищу сочетание: обфускация + место, куда CMS не должна писать исполняемое.

grep -R --include='*.php' -nE 'eval\s*\(|assert\s*\(|gzinflate\s*\(|gzuncompress\s*\(|str_rot13\s*\(|create_function\s*\(|preg_replace\s*\(.+/e' "$SITE" | head

grep -R --include='*.php' -nE 'FilesMan|c99shell|WSO\s|wp_vcd|wp-tmp|predli|\$GLOBALS\[.as.\]' "$SITE" | head

# одна строка в конце легитимного файла — классика
find "$SITE" -name '*.php' -size -8k -mtime -14 -print

# php внутри картинки / «.ico»
find "$SITE/wp-content/uploads" -type f -name '*.php.*' -o -name '*.jpg.php' -o -name '*.png.php'

Типовые гнёзда, которые я открываю всегда, даже если grep молчит:

• wp-content/uploads и кэш плагинов: *.php там не должен жить. Исключение — редкие плагины, которые сами кладут PHP в uploads; это повод такой плагин выкинуть, а не «ну так задумано».
• wp-content/upgrade, wp-content/upgrade-temp-backup, wp-content/blog.dir на мультисайте — мусор после обновлений, его не смотрят.
• Старая неактивная тема. «Мы на Astra, Twenty Twenty лежит на всякий» — в Twenty часто и сидит инжект в functions.php. Неактивная тема всё равно исполняется, если её кто-то дернул напрямую по URL.
• wp-config.php выше корня (правильная схема) и копия wp-config.php в корне/бэкапах *.bak, wp-config.php.old, config.php.save. Через них читают ключи БД без всякого шелла.

Отдельно — .htaccess. Не только редирект на чужой домен. Ещё auto_prepend_file / auto_append_file, php_value, RewriteRule на левый файл в uploads, закрытие .php «для всех кроме». Я сравниваю текущий файл с тем, что должен быть у выбранных постоянных ссылок. Если permalinks — «название записи», в корневом htaccess должен быть стандартный кусок WP, а не три килограмма чужих правил.

База. Файловый сканер её не видит. Смотрю:

• Лишние администраторы в wp_users + wp_usermeta (wp_capabilities = administrator). Пользователь wp_update / wpadmin1 / почта на одноразовом домене — не «сотрудник хостера».
• siteurl и home в wp_options. Если там чужой домен — редирект может быть не в файлах.
• active_plugins, recently_activated, опции с автозагрузкой autoload=yes и телом в десятки килобайт: туда кладут PHP, который потом evalят из темы одной строкой.
• Контент записей и виджетов: iframe, eval, короткие ссылки, спам-страницы в черновиках и ревизиях. Ревизии чистить отдельно: «удалил пост» не удаляет wp_posts с post_type=revision.
• Cron внутри WP: cron в wp_options или wp cron event list. Хук, которого нет ни в одном вашем плагине, раз в 10 минут дергает URL — это не «оптимизация».

wp user list --role=administrator --path="$SITE"
wp option get siteurl --path="$SITE"
wp option get home --path="$SITE"
wp plugin list --path="$SITE"
wp cron event list --path="$SITE"
wp db query "SELECT option_name, LENGTH(option_value) AS sz, autoload FROM wp_options ORDER BY sz DESC LIMIT 30;" --path="$SITE"

Префикс таблиц берите из wp-config.php, не считайте что он всегда wp_.

Дыру ищу до «лечения», иначе она зашьёт файл обратно

Удалить шелл и не закрыть вход — значит пригласить того же бота через пару часов. Пока файлы ещё на месте, по логам видно, какой URL принял POST до появления файла.

Ищу в access-логе не «все 404», а успешные запросы к тому, чего в чистом WP нет, и POST на плагины с известными дырами. Имена ниже — примеры шаблона, не диагноз конкретного сайта:

# nginx: подставьте свой лог
grep -E 'POST /(wp-admin/admin-ajax\.php|xmlrpc\.php|wp-login\.php)' /var/log/nginx/example.access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head

grep -E ' 200 | 302 ' /var/log/nginx/example.access.log | grep -Ei 'uploads/.+\.php|wp-content/plugins/.+/upload|filemanager|wp-setup|radio\.php|about\.php'

# php в uploads, который уже отработал
grep 'wp-content/uploads/.*\.php' /var/log/nginx/example.access.log | grep -E ' 200 | 500 '

Что чаще всего оказывается входом на обычных магазинах и лендингах, которые мне приносят:

• Слабый пароль администратора + открытый xmlrpc.php с system.multicall. Брут идёт не через форму логина, лимит на wp-login.php его не видит.
• Устаревший плагин формы, слайдера, «добавить товар из Excel», файловый менеджер, который кто-то поставил «на пять минут».
• Нулёвая тема / «пак плагинов». Бэкдор там с завода.
• Утекла сессия админа: тот же пароль, что в панели хостинга, что в FTP, что в почте. После взлома пароль «тот же, я его недавно менял» меня не успокаивает.
• Соседний сайт в том же пользователе UNIX. Дыра была не в этом WP.

Версии плагинов фиксирую сразу, до обновления: wp plugin list + даты файлов. Обновить всё «на всякий случай» до разбора — значит затереть следы, какой именно компонент принял запрос. Обновлять надо, но после снимка и записи версий.

Если вход не находится за час — это нормально. Тогда я всё равно меняю секреты и убираю известные дыры, но в отчёте пишу честно: persistence сняли, вектор не доказан. Не пишу «всё закрыто», если в логах дырка.

Чистить на месте или накатывать чистый слепок

Правило, которым я пользуюсь. Если есть проверенный бэкап до даты взлома — проще поднять его на чистый каталог, накатить контент (uploads без PHP, дамп таблиц контента без левых пользователей) и заново поставить ядро и плагины из официальных zip. «Лечить» живой каталог имеет смысл, когда бэкапа нет или взлом свежий, и заказчик не может быть сутки в 503.

Чего не делаю:

• Не ставлю поверх заразы «свежий WordPress» в тот же каталог. Старый mu-plugin и object-cache.php переживут.
• Не верю кнопке Repair у сканера как единственному действию. Она вычищает известные сигнатуры. Не вычищает новый include в wp-blog-header.php из трёх символов.
• Не оставляю «карантин» плагина внутри wp-content, если этот карантин всё ещё исполняется по прямому URL.
• Не правлю обфусцированный файл «вырезать кусок». Файл целиком из эталона или удалить.

Порядок очистки на месте, если слепка до взлома нет:

1. Снимок, логи, список админов, crontab, drop-in, mu-plugins — уже сняты.
2. Ядро заменить официальным zip той же (или уже новой, если дыра в ядре) версии.
3. Каждый плагин и тему — либо zip с официального источника, либо удалить. Неактивное — тоже удалить с диска, не «выключить».
4. Из uploads удалить любой PHP/phtml/phar и файлы с двойным расширением. Картинки не «лечить антивирусом», а не исполнять: в nginx для uploads — location ~ \.php$ deny.
5. База: лишние админы, option с длинным autoload, спам-посты и ревизии, подмена siteurl, чужие cron-хуки.
6. Секреты: ключи в wp-config.php (AUTH_KEY и остальные — сгенерировать заново), пароли всех админов, пароль БД, FTP, панели хостинга, SMTP, токены платёжек и Telegram, application passwords, ключи REST. Сессии: сменить соли, чтобы старые куки умерли.
7. Только после этого обновлять плагины до текущих версий и включать сайт для своих IP на проверку.

Запрет исполнения PHP в uploads — это не «оптимизация», это то, без чего чистка часто бессмысленна:

location ~* ^/wp-content/uploads/.*\.php$ {
    deny all;
}

На apache — в uploads/.htaccess что-то в духе php_flag engine off плюс <FilesMatch> на php. Точный синтаксис зависит от того, mod_php у вас или php-fpm через cgi. Если не уверены — лучше сломать загрузку шелла, чем угадать директиву и оставить выполнение. Проверка простая: положить свой test.php с echo 1; в uploads, открыть в браузере, получить 403/скачивание, файл удалить.

Проверка, что не всплыло через ночь

Сайт открываю с своего IP. Смотрю исходник главной и пары внутренних: нет ли внешнего скрипта с левого домена, нет ли display:none простыни ссылок, не подменён ли каноникал. В базе ещё раз siteurl/home. В файлах — даты за последние часы: если после «чистки» снова появились php в uploads, persistence жива (cron, соседний сайт, украденный FTP, незакрытая дыра).

Технически полезно:

# повтор через несколько часов, не сразу
find "$SITE" -type f -mmin -180 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
crontab -l
wp user list --role=administrator --path="$SITE"
wp plugin list --path="$SITE"

Снаружи: Search Console на странные URL, письмо хостера про исходящий спам, очередь почты на сервере (mailq, логи exim/postfix). Исходящий спам после «уже чистого сайта» почти всегда значит, что PHP-шелл или SMTP-креды живы.

Сканер после этого можно поставить. Один. Как датчик на будущее, не как доказательство чистоты. Я смотрю на него так же, как на fail2ban: хорошо, что пишет, плохо, если им заменяют работу руками.

И ещё: пароли, которые «и так сложные», после инцидента всё равно меняю. В том числе в панели домена и у регистратора. Бывали случаи, когда после чистки сайта через сутки меняли NS — это уже не WordPress, это украденный аккаунт регистратора, и файловый grep этого не увидит.

Что я не обещаю одним плагином

Плагин-сканер не видит crontab ОС, соседний vhost, подмену NS и письмо, которое уже ушло ночью. Он плохо видит инжект в базе и drop-in на одну строку. Он может быть сам заражён, если его поставили в уже дырявый WP.

Разбор — это снимок, сверка ядра, поиск persistence, закрытие входа, смена секретов и проверка через несколько часов. Скучно, зато сайт не «зеленеет» в сканере и не краснеет у клиентов на следующий день.

Если нужно разобрать конкретный случай — файлы, логи и доступ по SSH, не «скрин админки и надежда». Это обычная работа по сопровождению, без магии и без прайса на каждый найденный eval.

Смотрю конфиг — почти всегда одно и то же. На пире стоит AllowedIPs = 0.0.0.0/0 «чтобы точно работало», DNS прописан 8.8.8.8, на VPS ip_forward выключен, а проверку сделали командой ping 10.66.66.1. Пинг до адреса туннеля проходит. Это доказывает только то, что два пира видят друг друга. Это не доказывает, что рабочий трафик идёт в туннель, что DNS не утекает мимо, и что обратный путь из офисной сети существует.

Ниже — как я собираю офис VPS так, чтобы маршруты, DNS и split-tunnel не врали, и чем проверяю, что пакет реально ушёл в wg0, а не красиво показал handshake в wg show. Без «поставьте GUI» и без схемы «все в 0.0.0.0/0 и будет счастье».

Два разных туннеля, которые путают в одном конфиге

Мне на стол приносят три задачи, и их пытаются решить одним [Peer]:

• С ноутбука в офисе ходить на сервисы на VPS: SSH, панель, приватный git, админка, которая слушает только внутренний адрес.
• С VPS ходить в офисную сеть: NAS, принтер, контроллер, камера, которой «интернет не нужен».
• Выгнать весь офисный интернет через VPS, «чтобы как на работе».

Это не один туннель с разными галочками. Это разный AllowedIPs, разный форвардинг и разный DNS. Первые две задачи я почти всегда делаю split-tunnel: в туннель уезжает только нужная подсеть. Третья — полный туннель, и за неё отдельно платят CPU, трафиком и сломанным Zoom, если MTU не поправили.

Адреса в примерах ниже документационные, не боевые. Публичный VPS — 203.0.113.10, белый офиса — 198.51.100.20, туннель — 10.66.66.0/24, LAN офиса — 192.168.40.0/24. Свои цифры подставьте, чужие из интернета не копируйте вместе с ключами.

AllowedIPs — это маршрут, а не «список друзей»

В WireGuard AllowedIPs делает две вещи сразу. Снаружи это криптоключ: пакет с таким источником примут только от этого пира. Изнутри wg-quick по этому списку ставит маршруты. Написали 0.0.0.0/0 — получите дефолт через туннель (у wg-quick ещё и отдельная таблица, обычно 51820). Написали 10.66.66.0/24 — в туннель пойдёт только эта сеть.

Поэтому «handshake есть, а сайт на VPS открывается по белому IP» — нормально для split-tunnel и баг, если вы хотели полный туннель. Браузер пошёл на 203.0.113.10 напрямую, UDP 51820 при этом живой. Туннель тут ни при чём.

Смотрю, что система думает про маршрут, не что написано в комментарии к конфигу:

wg show
ip -4 addr show dev wg0
ip -4 route show
ip -4 route show table all | grep -E 'wg0|51820'
ip -4 route get 10.66.66.1
ip -4 route get 203.0.113.10
ip -4 route get 8.8.8.8

ip route get врёт меньше, чем ощущения. Если до внутреннего адреса VPS маршрут не через wg0, дальше можно не гадать — трафик в туннель не собирался.

Split-tunnel: офис ходит на VPS, интернет офиса не трогаем

Это тот вариант, который я ставлю по умолчанию. Офисный пир (ноутбук или маленький шлюз) держит туннель, в AllowedIPs только сеть туннеля и, если надо, приватные сети на стороне VPS. Исходящий веб офиса идёт как раньше, через местного провайдера.

VPS:

[Interface]
Address = 10.66.66.1/24
ListenPort = 51820
PrivateKey = <ключ VPS>

[Peer]
PublicKey = <ключ офиса>
AllowedIPs = 10.66.66.2/32

Офис (за NAT, поэтому keepalive):

[Interface]
Address = 10.66.66.2/24
PrivateKey = <ключ офиса>

[Peer]
PublicKey = <ключ VPS>
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.66.66.0/24
PersistentKeepalive = 25

Если на VPS сервисы торчат в docker-сети или во втором внутреннем интерфейсе, в AllowedIPs офиса добавляю эту сеть, не «весь мир». И на VPS тогда уже нужен форвардинг и фильтр, иначе пакет дойдёт до ядра и умрёт в FORWARD.

На VPS для split-tunnel NAT наружу обычно не нужен. Нужен, когда офис должен ходить не на сам VPS, а через него дальше. Пока задача «SSH на 10.66.66.1» — без маскарада.

PersistentKeepalive = 25 ставлю на том конце, который за NAT или с динамическим белым. Без него UDP-маппинг у провайдера офиса схлопывается, handshake в wg show становится старше пары минут, и «туннель встал сам» ровно до первой попытки зайти с другой стороны.

Когда VPS должен видеть LAN офиса

Вторая заявка: бэкап с VPS на NAS, мониторинг контроллера, SSH на станок, который «в интернет не смотрит». Тогда на стороне VPS в пире офиса мало /32 туннельного адреса. Нужна офисная подсеть:

# на VPS, peer = офисный шлюз
[Peer]
PublicKey = <ключ офисного шлюза>
AllowedIPs = 10.66.66.2/32, 192.168.40.0/24

Офисный шлюз должен форвардить. Это уже не «WireGuard на ноутбуке бухгалтера». Ноутбук не маршрутизатор: пакет с VPS на 192.168.40.15 дойдёт до ноутбука и останется там, NAS его не увидит, а ответ NAS пойдёт в локальный шлюз офиса и умрёт, потому что шлюз про 10.66.66.0/24 ничего не знает.

На шлюзе офиса:

sysctl -w net.ipv4.ip_forward=1
# постоянное место — /etc/sysctl.d/, не «в сессии до ребута»

iptables -C FORWARD -i wg0 -o eth0 -s 10.66.66.0/24 -d 192.168.40.0/24 -j ACCEPT 2>/dev/null || \
iptables -A FORWARD -i wg0 -o eth0 -s 10.66.66.0/24 -d 192.168.40.0/24 -j ACCEPT
iptables -C FORWARD -i eth0 -o wg0 -s 192.168.40.0/24 -d 10.66.66.0/24 -j ACCEPT 2>/dev/null || \
iptables -A FORWARD -i eth0 -o wg0 -s 192.168.40.0/24 -d 10.66.66.0/24 -j ACCEPT

Имена интерфейсов свои. eth0 в статье — заглушка. На машине смотрю ip -br link, не копирую с чужого скриншота.

Обратный маршрут в LAN часто забывают. NAS отвечает на запрос с 10.66.66.1 через дефолтный шлюз офиса. Шлюз этот пакет не ждал — в лучшем случае дроп, в худшем NAT в интернет. Варианты, которые работают:

• Статический маршрут на роутере офиса: 10.66.66.0/24 via 192.168.40.2, где .2 — шлюз с WireGuard.
• Или маскарад на офисном WG-хосте в сторону LAN, если роутер трогать нельзя. Работает, в логах NAS все запросы с одного адреса шлюза. Для бэкапа терпимо, для разбора «кто стучится» — нет.

Пересечение подсетей ловлю сразу. Офис на 192.168.1.0/24, docker на VPS тоже 192.168.1.0/24 — туннель поднимется, маршруты будут врать по очереди. Одну из сетей надо сменить. Спорить, «чья 192.168.1 важнее», бесполезно: важнее та, которую проще перенумеровать.

Полный туннель: 0.0.0.0/0, таблица 51820 и NAT на VPS

AllowedIPs = 0.0.0.0/0 на офисном пире означает: весь IPv4, кроме того что wg-quick сам вычтет для Endpoint, должен идти в туннель. wg-quick для этого поднимает policy routing, не просто ip route add default. Поэтому «я убрал default из main, а туннель живой» — ещё не победа. Смотреть надо ip rule и таблицу, которую создал WireGuard:

ip rule
ip route show table 51820
ip route get 8.8.8.8
ip route get 203.0.113.10

До Endpoint маршрут обязан остаться в физический интерфейс. Иначе туннель пытается нести сам себя и тихо умирает после первого же пересчёта маршрутов.

На VPS для чужого интернета нужны три вещи, не одна:

• net.ipv4.ip_forward=1
• NAT с туннеля в внешний интерфейс, иначе провайдер VPS не пропустит чужие RFC1918 как source
• FORWARD в файрволе в обе стороны, не только INPUT на 51820/udp

# на VPS, внешний интерфейс уточнить: ip -br addr
sysctl -w net.ipv4.ip_forward=1

iptables -t nat -C POSTROUTING -s 10.66.66.0/24 -o ens3 -j MASQUERADE 2>/dev/null || \
iptables -t nat -A POSTROUTING -s 10.66.66.0/24 -o ens3 -j MASQUERADE

iptables -C FORWARD -i wg0 -o ens3 -j ACCEPT 2>/dev/null || iptables -A FORWARD -i wg0 -o ens3 -j ACCEPT
iptables -C FORWARD -i ens3 -o wg0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT 2>/dev/null || \
iptables -A FORWARD -i ens3 -o wg0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Правила в статье — эскиз под iptables. На машине с nftables я пишу в ту таблицу, которая уже живая, а не добавляю второй файрвол «рядом». ufw route allow и iptables -A FORWARD одновременно — классический способ получить «у меня же разрешено», когда пакет режет другая цепочка.

Полный туннель я не ставлю «на всякий случай». Он нужен, когда офисный канал дырявый, нужен выход с фиксированного белого VPS, или политика «весь трафик только через нас». Для доступа к одной админке на VPS это дорогой способ сломать DNS, MTU и чужой Zoom.

DNS: туннель живой, а имена резолвятся мимо

Самая частая ложь после wg show. Туннель есть, curl https://10.66.66.1 работает, а curl https://panel.internal идёт неизвестно куда или не идёт вовсе. Причина почти всегда в резолвере, не в маршрутах.

DNS = в wg-quick — не магия. На systemd-resolved это попытка прикрутить домены к интерфейсу. На машине без resolved это может записаться в /etc/resolv.conf и затереть офисный DNS. На Windows-клиенте это отдельная история с «использовать DNS этого адаптера». Я не верю строке в конфиге, пока не увижу, куда реально уходит запрос.

Проверка с офисного пира:

resolvectl status
resolvectl query panel.internal
getent hosts panel.internal

# куда уходит UDP/53, пока стучите в имя
tcpdump -ni wg0 port 53
tcpdump -ni eth0 port 53

Если дамп на физическом интерфейсе показывает запросы на 8.8.8.8, а на wg0 тихо — split-tunnel сделал ровно то, что вы написали: маршрут до публичного DNS прямой. Внутреннее имя при этом либо не резолвится, либо резолвится в публичный адрес, и вы снова обходите туннель.

Рабочая схема для split-tunnel, которой я пользуюсь:

• На VPS крутится DNS, который знает внутренние имена. Слушает 10.66.66.1, не 0.0.0.0 в интернет.
• У офисного пира DNS = 10.66.66.1, и этот адрес уже входит в AllowedIPs.
• Если нужен только суффикс internal, в resolved указываю домен на интерфейс туннеля, а не подменяю весь резолвер офиса.

Для полного туннеля публичный DNS тоже должен быть достижим через туннель. Иначе получаете курицу и яйцо: чтобы поднять туннель, нужен DNS Endpoint, а DNS вы уже отправили в туннель, которого нет. Поэтому Endpoint я пишу IP, не именем. Имя в Endpoint оставляю только там, где белый VPS прыгает и без DNS туннель не собрать — тогда DNS офиса должен резолвить этот хост до подъёма wg0.

IPv6 утекает отдельно, MTU ломает «сайты открываются через раз»

Настроили IPv4, про IPv6 забыли. Браузер берёт AAAA, пакеты идут мимо туннеля в родной канал. curl -4 при этом красивый. Если полный туннель — в AllowedIPs нужен и ::/0, и на VPS форвардинг/NAT6, либо IPv6 на офисном пире надо выключить осознанно, не «само как-нибудь».

Для split-tunnel я проверяю оба стека:

ip -6 route get 2001:db8::1
curl -4 -s https://ifconfig.me
curl -6 -s https://ifconfig.me

Документационный 2001:db8::1 в route get нужен, чтобы увидеть, в какой интерфейс ядро отправит «чужой» v6. Если полного туннеля нет, прямой маршрут — ожидаемо. Если полный туннель заявлен, а v6 уходит в eth0 — дыра.

MTU. UDP + WireGuard + внешний Ethernet обычно просит 1420, на части каналов — ниже. Симптом не «туннель мёртв», а «SSH живой, HTTPS висит, крупные POST отваливаются, мессенджеры отваливаются на картинках». Ловлю так:

ip link show wg0
ping -M do -s 1372 10.66.66.1
ping -M do -s 1200 10.66.66.1

Если 1372 с DF не проходит, опускаю MTU на wg0, пока не начнёт. На VPS с jumbo или с PPPoE за NAT цифры другие — подбираю, не копирую 1280 «потому что все так пишут», если канал нормально держит больше.

Проверка, что рабочий трафик в туннеле, а не только handshake

Чеклист, которым я пользуюсь после wg-quick up. По порядку, не выборочно.

# 1. пир живой
wg show
# handshake секунды-минуты, не часы; transfer растёт, когда вы сами генерируете трафик

# 2. адрес и маршрут
ip route get 10.66.66.1
# ожидаю dev wg0

# 3. ICMP внутри туннеля — необходимое, но не достаточное
ping -c 3 10.66.66.1

# 4. TCP на сервис, который слушает только внутренний адрес
curl -v --connect-timeout 5 http://10.66.66.1:8080/
ss -tlnp | grep 8080   # это уже на VPS: сервис не на 0.0.0.0:80 случайно?

Дальше — дамп. Это единственный способ перестать спорить. На офисном пире в одном окне генерирую трафик, в двух других:

tcpdump -ni wg0 host 10.66.66.1
tcpdump -ni eth0 udp port 51820
tcpdump -ni eth0 host 203.0.113.10 and not udp port 51820

Нормальная картина split-tunnel, когда я хожу на внутренний сервис: на wg0 видны пакеты до 10.66.66.1, на физическом интерфейсе до VPS — только UDP 51820. Если на физическом интерфейсе всплыл обычный TCP на белый 203.0.113.10:443, вы открыли публичный nginx, не туннель.

Для полного туннеля добавляю:

# с офисного пира
curl -4 -s https://ifconfig.me
# должен вернуться белый VPS, не белый офиса

ip route get 1.1.1.1
# dev wg0 или таблица 51820, не eth0

tcpdump -ni eth0 tcp port 443
# во время curl на внешний сайт здесь не должно быть голого TCP
# только UDP 51820

Если ifconfig.me показал белый офиса — трафик мимо. Если показал белый VPS, но на eth0 всё равно виден TCP 443 — смотрю второй интерфейс, IPv6, браузерный DoH, «умный» антивирус со своим туннелем. Бывает, что curl в туннеле, а Firefox живёт своей жизнью.

На самой VPS в это время:

tcpdump -ni wg0
tcpdump -ni ens3 udp port 51820
# conntrack, если ping есть, а TCP нет
conntrack -L | grep 10.66.66

Ещё одна ловушка: сервис на VPS слушает 127.0.0.1 или только публичный адрес. Туннель доставляет пакет на 10.66.66.1, nginx его не принимает. Это не «WireGuard сломался». Это ss -tlnp до настройки туннеля, не после.

Что я проверяю, когда «подключилось, но не работает»

Короткий разбор по симптомам, без перебора всего man.

• Handshake старше нескольких минут, transfer ноль — NAT, файрвол хостера на UDP 51820, неверный Endpoint, часы сильно разъехались реже, но бывает. С офиса: nc -u -v 203.0.113.10 51820 ничего не доказывает (UDP без ответа), нужен дамп на VPS в момент wg-quick up.
• Handshake живой, ping до 10.66.66.x нет — AllowedIPs не покрывает адрес, или адреса туннеля пересеклись у двух пиров. Два клиента с 10.66.66.2/24 одновременно — классика копипаста.
• Ping есть, TCP нет — MTU, или сервис не слушает адрес туннеля, или FORWARD/фильтр режет не ICMP, а tcp.
• До VPS по внутреннему IP есть, до NAS в офисе нет — на VPS в AllowedIPs нет LAN, на офисе нет forward, на роутере офиса нет обратного маршрута.
• Браузер открывает сайт по домену «не туда» — DNS мимо туннеля или A-запись смотрит на белый, а вы думали, что ходите внутрь.
• После сна ноутбука туннель «есть», трафика нет — keepalive, stale UDP mapping, помогает wg-quick down; wg-quick up, а постоянно — keepalive и иногда NetworkManager dispatcher, не вечная сессия с 2023 года.

Ключи и чужие IP в тикет не кладу. В логах для разбора достаточно последних байт публичного ключа из wg show и документационных адресов. Боевой Endpoint заказчика в статью и в переписку с подрядчиком не тащу.

Что оставляю в конфиге, когда уже заработало

Минимальный набор, который я не выкидываю «потом допишем»:

• Endpoint только IP, порт явно 51820 или тот, что реально открыт у хостера. У части облаков UDP на дефолтном порту режут, тогда слушаю другой и это же пишу в Endpoint.
• AllowedIPs по задаче, не максимальный. Split-tunnel — сети, которые правда надо унести. Полный туннель — осознанный 0.0.0.0/0 плюс IPv6-решение.
• PersistentKeepalive на NAT-стороне.
• DNS только тот, который достижим через получившиеся маршруты.
• Проверка дампом один раз после подъёма, не «пинг прошёл — закрываем задачу».

Конфиг без этой проверки — это VPN на скриншоте. Скриншот wg show с handshake я в отчёт тоже прикладываю, но рядом кладу ip route get до рабочего адреса и кусок tcpdump, где видно UDP 51820 снаружи и целевой трафик внутри. Если второго нет, туннеля для работы тоже нет — есть только красивый интерфейс wg0.

Нужный результат простой: крутилка света в «0» (или Auto), при включении зажигания ничего лишнего не горит, после запуска двигателя автоматически ближний спереди и габариты сзади. Штатный ручной свет при этом остаётся как был.

Та самая таблица, которую все копируют

В интернете по Astra H / Zafira B гуляет одна и та же схема вариантов DRL — «Стандарт» и Version 1–5 в разрезе «зажигание» / «мотор заведён» и положения переключателя. Её перепечатывают на Drive2, в FAQ по OP-COM, на чешских и немецких форумах. Мы тоже от неё оттолкнулись.

По таблице кажется, что достаточно один раз выбрать Version 1 или Version 5 — и поведение «всё включится как надо». На деле таблица описывает логику варианта, а не то, что перед и зад программируются в разных блоках. Из‑за этого половина инструкций заканчивается на UEC, а про REC либо вскользь, либо никак.

Что получилось у нас на Version 1 и 5

Пробовали классику — ставили одинаковый вариант и смотрели глазами.

• Version 1: при включении зажигания уже горели передние габариты; после запуска двигателя они оставались, плюс включался ближний. Для «дневного» режима это слишком рано: ещё не завёл — уже светится.
• Version 5: при зажигании ничего, после запуска двигателя зажигается ближний..

И главное: задние габариты автоматически не включались ни в одном из этих режимов, пока трогали только то, что обычно трогают первым — передний блок. Спереди картина менялась, сзади — тишина. Вот тут и всплывает архитектура Astra H.

Почему перед и зад настраиваются отдельно

На Astra H (и близкой по электрике Zafira B) свет и кузовная периферия разнесены по двум «центрам»:

• UEC (Underhood Electrical Center, иногда FZM / Front Zone Module) — подкапотный блок. Передние фары, часть передней кузовной логики, датчик дождя/света и параметр Daytime Running Light именно для передка.
• REC (Rear Electrical Center, RZM / Rear Zone Module) — задний блок (обычно слева сзади). Задние фонари, центральный замок, охранка и свой такой же пункт Daytime Running Light.

Это не «одна настройка на всю машину». У каждого модуля свой Variant Configuration и свой CarPass-ввод. Можно поставить на UEC Version 5, а на REC оставить Disabled / Standard — и получите ровно нашу картину: спереди DRL ожил, сзади габариты ждут ручной крутилки. Таблица из интернета этого почти не объясняет: там одна строка «версия», как будто она глобальная.

Отсюда и редкий, но рабочий трюк: разные варианты на перед и зад. Мы не изобретали велосипед с нуля — в FAQ по OP-COM давно пишут, что DRL надо прописывать и в UEC, и в REC. А вот комбинацию «5 спереди + 1 сзади» под конкретное поведение мало где разжёвывают.

Что понадобится

• Диагностика с поддержкой Opel: OP-COM (качественный клон/оригинал) или Tech2 + CANdi.
• CarPass — четыре цифры security code с карточки, которую выдавали с машиной. Без него Program Variant Configuration не пустит. Потеряли — только через дилера / сервис с доступом к базе (это не «взлом», а штатная защита кодировки).
• Зажигание включено (шина живая), аккумулятор не на нуле.
• Желательно сохранить текущий конфиг кнопкой Save в OP-COM, если она есть — чтобы откатить, если вариант не зайдёт.

Как мы запрограммировали перед (UEC) — Variant 5

Путь в OP-COM:

Diagnostics → год выпуска → Astra-H → Body → UEC → Programming → Program Variant Configuration → CarPass (4 цифры) → Daytime Running Light → Variant 5 → Program

Variant 5 на передке как раз ближе к «скандинавскому» дневном режиму: не тянет габариты и приборку так, как ранние версии при одном только зажигании, и даёт ближний уже в логике DRL. Сам по себе он нам ещё не закрыл задачу — но как половинка связки сработал отлично.

Нюансы из заводских/форумных заметок по Version 5 (имейте в виду): пока DRL активен, подсветка дисплея/кнопок может вести себя иначе, чем в ручном ближнем; дальний по таблице включается только из положения переключателя «ближний»; при крутилке на габаритах DRL обычно глушится. Если стоит ксенон — на Version 2–4 в гайдах часто советуют не заигрывать (свет может гореть ещё до запуска мотора).

Как настроили зад (REC) — Variant 1

Тот же ритуал, другой блок:

Diagnostics → год выпуска → Astra-H → Body → REC → Programming → Program Variant Configuration → CarPass → Daytime Running Light → Variant 1 → Program

Именно Variant 1 на REC у нас наконец поднял задние габариты в автоматике. Пока REC оставался без своего DRL-варианта (или на «стандарте»), сзади тишина — сколько ни крути UEC.

После Program иногда помогает коротко выключить зажигание и снова завести, чтобы модули перечитали кодировку.

Итог на нашей машине

Связка UEC = Variant 5 + REC = Variant 1 на Astra H 2008 универсал бензин дала то, что хотели:

• зажигание включено, мотор не заведён — ничего не горит;
• двигатель запущен — автоматически ближний спереди и задние габариты;
• ручной режим света как штатный, без сюрпризов.

Если у вас другой год / хэтч / GTC / ксенон / датчик света — цифры вариантов могут понадобиться другие, но принцип тот же: не программируйте только UEC и не ждите чудес от задних фонарей. Сначала таблица из интернета, потом обязательно REC, и уже подбором (или нашей связкой 5+1) ловите нужную картину.

Лимит сработал. Просто он отстрелил своих вместе с ботами. Офис сидит за одним белым IP, xmlrpc дергает приложение каждые несколько секунд, а общий php-location обслуживает и логин, и admin-ajax.php, и оформление заказа.

Ниже — как я режу именно логин и xmlrpc, оставляя сайт живым, и где limit_req бесполезен, сколько его ни крути. Без «поставьте плагин лимита логинов» и без слепого deny all на xmlrpc, пока не ясно, кто им пользуется.

Что бьют на самом деле, и почему это две разные двери

На типичном WordPress без WAF смотрят три URL:

• /wp-login.php — форма входа. GET рисует форму, POST проверяет пароль.
• /xmlrpc.php — старый API. С него удобно перебирать пароли пачками через system.multicall и дёргать pingback.
• Иногда /wp-admin/ и REST /wp-json/ — это уже другие истории, их в ту же зону, что логин, я не кладу.

GET на логин — не атака. Человек открыл форму, браузер подтянул редирект, плагин 2FA нарисовал второй шаг. Если лимитировать любой метод, первый же заход «съедает» burst, а POST с паролем уже ловит 429. Поэтому ключ зоны я завязываю на POST, не на URL целиком.

xmlrpc почти всегда POST. Закрывать его наглухо можно, если им никто не пользуется: нет официального приложения WP, нет Jetpack, нет старых клиентов публикации. Если приложение нужно — return 403 хуже брутфорса: свои отвалятся сразу, боты просто перейдут на wp-login.php.

Почему общий limit_req на php убивает нормальных людей

admin-ajax.php на живом сайте стучит постоянно: пульс админки, автосохранение записи, корзина, фильтры каталога. Один редактор за минуту легко делает десятки POST. Посадили его в зону 1r/s burst=3 вместе с логином — получите «сайт тормозит», хотя CPU спокойный, а в логе 503 на ajax.

Вторая ловушка — общий IP. Офис, коворкинг, 4G-оператор с CGNAT, гостиница. Двадцать человек за одним адресом. Лимит «один запрос в секунду на IP» для брутфорса с ботнета ещё терпим, для офиса это коллективный бан после трёх неудачных паролей подряд.

Третья — статус по умолчанию. Nginx на превышение отдаёт 503. Мониторинг орёт «сайт мёртв», человек лезет в php-fpm и диск. Это не падение бэкенда, это отказ лимитера. Ставлю limit_req_status 429 и в логах сразу видно, что именно отсекли, а не «бэкенд не отвечает».

Две зоны, не одна

Зоны объявляю в http, не в server. Размер 10m для $binary_remote_addr — десятки тысяч IP, на обычный сайт с головой. Rate считаю отдельно:

# http { ... }
limit_req_zone $limit_key_wplogin zone=wplogin:10m rate=6r/m;
limit_req_zone $limit_key_xmlrpc  zone=xmlrpc:10m  rate=1r/s;
limit_req_status 429;
limit_req_log_level warn;

Шесть POST в минуту на логин — человек с кривым паролем ещё влезет, словарь на тысячи попыток уже нет. xmlrpc чуть свободнее по частоте HTTP-запросов: живое приложение иногда стучит пачкой. Это не дыра — дыра в xmlrpc не частота, а толстое тело, про это ниже.

Ключ пустой строкой означает «этого запроса в зоне нет». Так я выключаю лимит для GET и для белого списка.

map $request_method $limit_key_wplogin {
    POST $binary_remote_addr;
    default "";
}

# xmlrpc почти весь POST; GET на него мне не жалко тоже резать
map $request_method $limit_key_xmlrpc {
    default $binary_remote_addr;
}

Если офис сидит на постоянном адресе, вычитаю его из ключа через geo. В примере — документационный диапазон, не чей-то боевой:

geo $offnet {
    default 0;
    203.0.113.0/24 1;   # офис, подставьте свой
}

map $offnet $limit_key_wplogin {
    1      "";
    default $limit_wplogin_ip;
}

map $request_method $limit_wplogin_ip {
    POST $binary_remote_addr;
    default "";
}

Два map на одну переменную nginx не даст — ключ собираю в одном месте. Рабочий вариант без сюрпризов:

geo $is_office {
    default 0;
    203.0.113.0/24 1;
}

map "$is_office:$request_method" $limit_key_wplogin {
    "1:POST" "";
    "0:POST" $binary_remote_addr;
    default  "";
}

map $is_office $limit_key_xmlrpc {
    1       "";
    default $binary_remote_addr;
}

Белый список — не «интернет офиса целиком». Только тот префикс, с которого реально заходят в админку. Домашний динамический IP туда не тащу: через месяц он уедет соседу.

location: только эти два файла, тот же php, что у остальных

location = с точным именем бьёт точнее regex. Обработчик php не выдумываю — копирую то, что уже работает для *.php. На Debian это часто snippets/fastcgi-php.conf плюс ваш fastcgi_pass. Сокет не копируйте из чужой статьи: у вас может быть другой пул.

server {
    # ...

    location = /wp-login.php {
        limit_req zone=wplogin burst=4 nodelay;
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php-fpm.sock;  # как у вас в общем php
    }

    location = /xmlrpc.php {
        limit_req zone=xmlrpc burst=8 nodelay;
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php-fpm.sock;
    }

    # общий php — БЕЗ limit_req этих зон
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php-fpm.sock;
    }
}

burst=4 nodelay на логине: четыре лишних POST проходят сразу, дальше 429, без очереди. Без nodelay nginx начинает задерживать запросы — форма «думает» секундами, человек жмёт ещё раз, вы сами себе множите POST. Для логина я предпочитаю жёсткий отказ, не задержку.

На xmlrpc burst больше: приложение может открыть несколько соединений подряд при синхронизации. Если xmlrpc вам не нужен совсем — не лимитируйте, закройте:

location = /xmlrpc.php {
    return 403;
}

Проверяю необходимость просто: grep xmlrpc access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head и user-agent. Если неделю стучат только словари и Hello world — закрываю. Если есть wp-iphone / wp-android с адресов редакции — оставляю зону.

Настоящий IP, иначе режете Cloudflare, а не бота

$binary_remote_addr — это TCP-пир. Стоит сайт за Cloudflare, nginx-прокси или балансировщиком хостера — пир один на всех. Лимит превращается в глобальный рубильник: первый бот выжигает burst, посетители с того же эджа ловят 429.

Смотрю, откуда приходит запрос:

log_format debugip '$remote_addr cf="$http_cf_connecting_ip" xff="$http_x_forwarded_for"';

Дальше set_real_ip_from на префиксы своего прокси и real_ip_header — тот заголовок, которому вы доверяете. Не доверяю X-Forwarded-For с интернета без фильтра: его подставляет кто угодно. Для Cloudflare — их диапазоны и CF-Connecting-IP. Для своего nginx-прокси — только его адрес в set_real_ip_from.

Пока real_ip не настроен, limit_req на логин я не включаю в боевой server. Иначе «защита» — это лотерея, кто первый постучал в этот воркер.

Где лимит бесполезен: system.multicall

Брутфорс по xmlrpc часто укладывается в один HTTP POST. Внутри system.multicall — сотни wp.getUsersBlogs с разными паролями. Для nginx это один запрос. Зона 1r/s его пропускает, php-fpm честно пережёвывает пачку, в auth.log WordPress — сотни неудачных логинов, в access.log — одна строка 200.

Поэтому «я поставил rate limit, xmlrpc больше не брутфорсят» — самообман, если multicall жив. Nginx $request_body в if на практике пустой: тело ещё не прочитано в той фазе, конфиг из гугла с if ($request_body ~ multicall) просто не срабатывает. Я это не рисую как рабочую схему.

Что работает без магии:

• xmlrpc не нужен — return 403 на location, плюс фильтр в WordPress на всякий случай;
• нужен только pingback — всё равно спорно, pingback сам по себе источник шума; чаще его выключают;
• нужно приложение — оставляю xmlrpc под limit_req и отдельно отключаю multicall на стороне PHP (му-плагин на xmlrpc_methods выкидывает system.multicall), либо режу на WAF, который тело реально видит;
• Application Passwords и REST — другая дверь, xmlrpc для них не обязателен. Если мобильный вход уже через REST, xmlrpc я закрываю, не лимитирую.

Лимит по запросам и разбор методов xmlrpc — два разных слоя. Первый без второго на этой двери недоделан.

Как проверить, что своих не задело

Не тестирую с того же ноутбука, с которого админю. Иначе сам себя выкину и буду чинить по аварийной консоли. С другого адреса, лучше с маленького VPS:

# форма должна открываться сколько угодно
for i in $(seq 1 20); do curl -s -o /dev/null -w "%{http_code}\n" https://example.com/wp-login.php; done

# POST — должны пойти 429 после burst
for i in $(seq 1 20); do
  curl -s -o /dev/null -w "%{http_code}\n" -X POST \
    -d "log=nosuchuser&pwd=wrong&wp-submit=Log+In" \
    https://example.com/wp-login.php
done

# ajax и главная не в этой зоне
for i in $(seq 1 30); do
  curl -s -o /dev/null -w "%{http_code}\n" -X POST https://example.com/wp-admin/admin-ajax.php
done

Ожидание: GET логина — сплошные 200 (или 302, если уже есть редирект). POST — несколько 200/302, потом 429, не 503. ajax — без 429. Главная и карточки товара — без 429.

Потом то же с офисного IP, если он в geo: POST не должен упираться в 429, иначе белый список не попал в ключ. Частая ошибка — geo по $remote_addr до real_ip, и офис виден как адрес Cloudflare.

В логе ищу не «много 404», а явно статус и зону. С limit_req_log_level warn в error.log будет limiting requests, excess: ... zone=wplogin. Если зоны в логе нет, а 503 есть — вы смотрите не на лимитер, а на php-fpm/upstream.

Что я не кладу в эти зоны

• admin-ajax.php, async-upload.php, cron wp-cron.php — это не брутфорс логина.
• REST /wp-json/ целиком. Там и легитимный редактор, и Application Passwords. Если резать — отдельные location на конкретные маршруты, не оптом.
• wp-admin/ GET статики и admin-post.php с авторизованной сессией.
• Статику и wp-content/uploads — к логину отношения не имеет.

Отдельно: плагины «кастомной страницы входа» часто POST-ят не на /wp-login.php, а на / или на /my-account/. Тогда мой location логин не защищает, зато WooCommerce-чекаут внезапно оказывается под лимитом, если кто-то прикрутил зону на location /. Смотрю в access.log реальный URI при неудачном входе, не название плагина на коробке.

fail2ban рядом, не вместо

Nginx лимитер не помнит «этот IP вчера перебирал пароли». Он держит короткое окно. fail2ban по error.log с zone=wplogin или по auth-логу WordPress закрывает упёртых на часы. Но jail, который банит после трёх 429, снова отстрелит офис. Либо офис в ignoreip, либо порог заметно выше человеческого «забыл пароль, нажал пять раз».

Я не баняю 429 с ajax и не баняю 404 на xmlrpc.php, если сами его закрыли 403: боты будут стучать вечно, jail раздует ipset, а толку ноль — они и так получают отказ.

Что оставляю на обычном сайте

Рабочий минимум, которым я заканчиваю, если это один WordPress на VPS без приложения:

• real_ip настроен, в логе виден клиент, не эдж;
• wp-login.php — POST-only зона ~6r/m, burst 4 nodelay, статус 429;
• xmlrpc.php — 403, если за неделю нет своих клиентов;
• если клиент есть — зона 1r/s + выключенный system.multicall в PHP;
• офисный префикс в geo, не «весь провайдер»;
• общий php-location без этих зон;
• проверка циклом curl с чужого IP и глазами error.log, что падает зона, а не 503 от fpm.

Плагин лимита логинов в WordPress я не считаю заменой: он срабатывает уже внутри PHP, после того как fpm взял воркер. Под словарём это дороже, чем отказ на nginx. Плагин имеет смысл как второй слой (капча, временная блокировка учётки), не как единственный.

Если после включения 429 сыпятся на живых редакторов — не поднимаю rate «пока не пройдёт». Сначала смотрю, какой URI и какой IP. Почти всегда это либо общий php-location, либо NAT офиса, либо xmlrpc приложения, которое я забыл, что оно существует.