AI-ботнеты: как изменились атаки на серверы в 2025–2026 году.
AI-ботнеты: как изменились атаки на серверы в 2025–2026 году.
sysadmin В 2024 году типичная атака на WordPress выглядела так: несколько IP-адресов долбят wp-login.php с одним и тем же user agent, одна и та же маска пароля, предсказуемый интервал между запросами. fail2ban банил через минуту, nginx отдавал 429, атака заканчивалась.
К концу 2025 года картина стала другой. По данным Cloudflare из отчёта Bot Traffic Report 2026, 94% всех попыток входа на WordPress-сайты — боты. Но теперь это не скрипты с фиксированным списком паролей. Это системы которые учатся на ошибках в реальном времени: меняют user agent после каждого блока, варьируют интервалы между запросами чтобы не попасть под rate limiting, атакуют одновременно через xmlrpc.php, wp-login.php и REST API — координированно, из разных точек планеты.
По данным исследователей, 35% ботнет-операций в 2025 году использовали алгоритмы машинного обучения для обхода систем обнаружения. Это уже не массовый перебор — это адаптивная атака.
КАК РАБОТАЕТ AI-БОТНЕТ
Классический ботнет — это армия заражённых устройств, каждое из которых выполняет одну инструкцию: стучи сюда, с такими параметрами, с такой частотой. Инструкция приходит с C2-сервера (command and control), всё предсказуемо.
AI-ботнет работает иначе. Каждый узел не просто выполняет инструкцию — он анализирует ответ сервера и принимает решение что делать дальше. Получил 403? Сменить user agent. Получил 429? Снизить частоту на 40% и подождать. Получил редирект? Проследовать и попробовать снова. Нет ответа три секунды? Переключиться на другой endpoint.
Реальный пример: ботнет RondoDox, задокументированный The Hacker News в январе 2026 года. Система прошла три фазы эволюции за девять месяцев: ручное сканирование в марте-апреле 2025 → массовое ежедневное зондирование WordPress, Drupal и IoT-устройств в апреле-июне → почасовое автоматизированное развёртывание с июля по декабрь 2025. За девять месяцев ботнет научился находить уязвимости и эксплуатировать их быстрее чем большинство команд успевает накатить патч.
По данным Patchstack из отчёта за 2026 год: медианное время от публичного раскрытия уязвимости до активной эксплуатации — 5 часов. Не дней. Часов.
ЧЕМ AI-БОТНЕТ ОТЛИЧАЕТСЯ ОТ ОБЫЧНОГО
Ротация идентичности
Старый ботнет использовал один IP пока его не заблокируют. AI-ботнет меняет IP, user agent, заголовки запроса и даже TLS fingerprint по заданному алгоритму — так чтобы каждый запрос выглядел как новый браузер из новой страны.
Проверить свой сервер на такую активность:
# Топ user agents за последние сутки
grep "POST /wp-login.php" /var/log/nginx/access.log | \
awk -F'"' '{print $6}' | sort | uniq -c | sort -rn | head -20
# Если видишь десятки разных реалистичных user agents с разных IP — это признак AI-ботнетаМноговекторная координация
Вместо удара по одной точке — одновременная атака на несколько endpoints. Пока fail2ban банит IP за удары по wp-login.php, другой узел ботнета тихо перебирает пароли через xmlrpc.php с другого IP. Потом переключается на REST API. Цель — найти незащищённую точку входа.
# Посмотреть атаку по всем WordPress endpoints одновременно
# Выводит: IP-адрес | количество запросов | список атакованных endpoints
grep -E "wp-login|xmlrpc|wp-json" /var/log/nginx/access.log | \
awk '{print $1, $7}' | sort | \
awk '{count[$1]++; endpoints[$1]=endpoints[$1]" "$2} END {for(ip in count) if(count[ip]>5) print ip, count[ip], endpoints[ip]}' | \
sort -k2 -rn | head -20Пример вывода:
185.220.101.42 23 /wp-login.php /xmlrpc.php /wp-login.php /xmlrpc.php
94.102.49.11 17 /wp-json/wp/v2/users /wp-login.php /xmlrpc.phpПервая строка — IP атакует wp-login.php и xmlrpc.php вперемешку, типичная многовекторная атака. Вторая — начал с разведки через wp-json, потом перешёл к брутфорсу. Если видишь один IP в нескольких endpoints — это не случайность.
ML-взлом паролей
Инструменты вроде PassGAN — нейросеть обученная на 15,68 миллионах паролей из датасета RockYou — взламывают 50% распространённых паролей мгновенно. Семизначный пароль из букв, цифр и спецсимволов — за шесть минут на потребительском GPU. Традиционный словарный брутфорс с такой скоростью не работает.
Выбор payload по профилю жертвы
Продвинутые ботнеты определяют тип цели и выбирают payload автоматически: для корпоративного сервера — ransomware, для медицинского сайта — эксфильтрация данных, для слабого VPS — криптомайнер. По данным SiliconAngle, некоторые ботнеты умеют определять наиболее прибыльный сценарий атаки ещё до начала основной фазы.
ЧТО ЭТО ЗНАЧИТ ДЛЯ АДМИНИСТРАТОРА
Старые подходы работают хуже. Несколько конкретных примеров:
IP-based блокировка — fail2ban банит IP после N попыток. AI-ботнет делает N-1 попыток с каждого IP и переходит к следующему. Если в ботнете 10 000 узлов и порог fail2ban — 5 попыток, ботнет может сделать 49 999 попыток прежде чем первый IP попадёт в бан.
Rate limiting по IP — та же проблема. Лимит 10 запросов в минуту с одного IP? Ботнет использует 100 IP и делает по одному запросу в минуту с каждого. Лимит не срабатывает.
User agent фильтрация — бесполезна против ботнетов которые ротируют реалистичные user agents из реальных браузеров.
Что реально работает в 2026 году:
КАК ЗАЩИТИТЬСЯ
1. Поведенческий анализ вместо IP-блокировки
Вместо «заблокировать IP после 5 неудач» — анализировать паттерн поведения. Один IP делает по одной попытке? Подозрительно. Сто IP атакуют одновременно с паузой ровно в 60 секунд? Слишком синхронно для людей.
Cloudflare Bot Management и Cloudflare WAF с managed rules делают это автоматически. Для nginx без Cloudflare — комбинация rate limiting по подсети и анализ логов:
# Найти подсети /24 с аномальной активностью за последний час
awk -v d="$(date -d '1 hour ago' '+%d/%b/%Y:%H:%M')" '$0 > d' \
/var/log/nginx/access.log | \
grep "POST /wp-login.php" | \
awk '{print $1}' | \
sed 's/\.[0-9]*$/\.0\/24/' | \
sort | uniq -c | sort -rn | head -20
# Если видишь одну подсеть с сотнями запросов — блокировать её целиком в nftables2. Защита на уровне challenge
Cloudflare Turnstile или CAPTCHA на wp-login.php — бот не может пройти challenge без JavaScript и браузерного окружения. Это отсекает большинство простых ботов. Продвинутые AI-ботнеты используют headless браузеры, но это на порядок дороже для атакующего.
3. Закрыть все vectors кроме одного
Если xmlrpc.php закрыт, wp-json users endpoint закрыт, остаётся только wp-login.php — это концентрирует атаку в одной точке и упрощает мониторинг. Чем меньше поверхность атаки, тем легче детектировать аномалии.
# Комплексная блокировка в nginx
location = /xmlrpc.php {
deny all; # Запретить все запросы — 403 Forbidden
access_log off; # Не писать в лог — не засорять диск запросами ботов
}
location ~* ^/wp-json/wp/v2/users {
deny all;
access_log off;
}
# limit_req_zone — зона для rate limiting, объявляется в блоке http{}
# $binary_remote_addr — ключ: IP-адрес клиента в бинарном формате (4 байта, экономит память)
# zone=wplogin:10m — имя зоны и размер памяти (10 МБ ≈ 160 000 IP-адресов)
# rate=1r/m — максимум 1 запрос в минуту с одного IP
limit_req_zone $binary_remote_addr zone=wplogin:10m rate=1r/m;
location = /wp-login.php {
# burst=3 — разрешить очередь до 3 запросов сверх лимита (для легитимных пользователей)
# nodelay — не задерживать запросы в очереди, сразу отдавать 503 если лимит превышен
limit_req zone=wplogin burst=3 nodelay;
fastcgi_pass unix:/run/php/php8.3-fpm.sock; # Передать запрос PHP-FPM через Unix сокет
include fastcgi_params; # Подключить стандартные FastCGI параметры
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; # Путь к PHP файлу
}Важный нюанс: limit_req_zone объявляется в блоке http{} в nginx.conf, а не внутри server{}. Если поставить внутрь server{} — nginx не запустится с ошибкой «limit_req_zone» is not allowed here.
Проверить конфиг и перезагрузить:
nginx -t && systemctl reload nginx4. Мониторинг аномалий в реальном времени
AI-ботнеты обнаруживают себя не отдельными IP-адресами, а паттернами. Мониторить нужно не «сколько запросов с этого IP» а «как выглядит трафик в целом»:
# Количество уникальных IP атакующих wp-login за последние 5 минут
awk -v d="$(date -d '5 minutes ago' '+%d/%b/%Y:%H:%M')" \
'$0 > d && /POST \/wp-login.php/' /var/log/nginx/access.log | \
awk '{print $1}' | sort -u | wc -l
# Если больше 20 уникальных IP за 5 минут — скоординированная атака5. Application Passwords и 2FA
Даже если ботнет получил правильный логин через wp-json — Application Passwords (WordPress 5.6+) и двухфакторная аутентификация делают брутфорс паролей бессмысленным. Это самая дешёвая защита с наибольшим эффектом.
6. nftables — блокировка до nginx
nginx и PHP — это уже конец цепочки. К тому моменту как запрос дошёл до wp-login.php, сервер потратил ресурсы на TCP-соединение, TLS-хендшейк, разбор HTTP-заголовков. nftables режет трафик на уровне ядра — до nginx, до PHP, до всего.
Заблокировать конкретный IP вручную:
nft add element inet filter blocklist { 185.220.101.42 }
# Проверить что добавлен
nft list set inet filter blocklistЗаблокировать целую подсеть если с неё идёт скоординированная атака:
nft add element inet filter blocklist { 185.220.101.0/24 }Автоматизировать блокировку на основе логов nginx — скрипт который берёт топ атакующих подсетей и добавляет их в nftables:
#!/bin/bash
# Найти подсети с более чем 50 запросами к wp-login за последний час
awk -v d="$(date -d '1 hour ago' '+%d/%b/%Y:%H:%M')" '$0 > d' \
/var/log/nginx/access.log | \
grep "POST /wp-login.php" | \
awk '{print $1}' | \
sed 's/\.[0-9]*$/\.0\/24/' | \
sort | uniq -c | sort -rn | \
awk '$1 > 50 {print $2}' | \
while read -r subnet; do
nft add element inet filter blocklist { $subnet }
echo "Blocked: $subnet"
doneRate limiting на уровне nftables — ограничить количество новых TCP-соединений на порты 80 и 443 с одного IP. Правильный способ через meter — per-IP счётчик без предварительного выделения памяти под каждый IP:
# Добавить в секцию chain input{} конфигурации nftables
# Meter считает новые соединения per-IP, превышение лимита — drop
tcp dport { 80, 443 } ct state new \
meter http_limit { ip saddr limit rate over 20/second } dropЕсли нужно добавлять превысивших лимит в blocklist с автоматическим истечением. Внимание: limit rate без meter — это глобальный лимит на весь трафик, не per-IP. Для per-IP используй meter из блока выше. Этот вариант полезен для защиты от SYN flood в целом:
# Сначала объявить динамический set с таймаутом в секции table:
# set blocklist {
# type ipv4_addr
# flags dynamic, timeout
# timeout 1h
# }
# Затем правило в chain input{}:
tcp dport { 80, 443 } ct state new \
limit rate over 20/second \
add @blocklist { ip saddr } dropРазница с nginx rate limiting принципиальная: nginx считает запросы на уровне HTTP — соединение уже установлено. nftables считает TCP SYN пакеты — соединение ещё не открыто. Это означает что при DDoS-атаке с тысячами соединений nftables защищает nginx от перегрузки, а не наоборот.
fail2ban с nftables backend автоматизирует весь процесс — после настройки jail для wp-login.php он сам добавляет IP в nftables set после превышения порога:
# Проверить что fail2ban использует nftables
fail2ban-client get sshd banaction
# Должно быть: nftables-multiport или nftables-allports
# Статус jail для WordPress
fail2ban-client status nginx-wploginРЕАЛЬНЫЕ ЦИФРЫ 2025–2026
По данным из открытых отчётов:
- 94% попыток входа на WordPress — боты (Cloudflare Bot Traffic Report 2026)
- 35% ботнет-операций используют ML для обхода обнаружения
- Медианное время от раскрытия уязвимости до эксплуатации — 5 часов (Patchstack 2026)
- 11 334 новых уязвимости в экосистеме WordPress в 2025 году, рост 42% за год (Patchstack 2026)
- 91% уязвимостей — в плагинах, не в ядре WordPress
Последняя цифра важна: обновление плагинов в день выхода патча — это уже не рекомендация, это минимальный стандарт.
КАК ПОНЯТЬ ЧТО ТЕБЯ АТАКУЕТ ИМЕННО AI-БОТНЕТ
Обычный ботнет оставляет грубые следы: одни и те же user agent, одна подсеть, предсказуемые интервалы. AI-ботнет выглядит иначе — и это можно увидеть в логах.
Признак 1: разнообразие user agents при атаке на одну точку.
# Сколько уникальных user agents атакует wp-login за последний час?
grep "POST /wp-login.php" /var/log/nginx/access.log | \
awk -F'"' '{print $6}' | sort -u | wc -l
# Обычный ботнет: 1-3 уникальных UA
# AI-ботнет: 20-50+ разных реалистичных UAПризнак 2: атака распределена по времени неравномерно, но без очевидных паттернов.
# Посмотреть распределение запросов по минутам
grep "POST /wp-login.php" /var/log/nginx/access.log | \
awk '{print $4}' | cut -d: -f1,2,3 | sort | uniq -c
# Обычный ботнет: ровные интервалы (каждую секунду, каждые 5 секунд)
# AI-ботнет: нерегулярные интервалы, имитирующие человекаПризнак 3: атака идёт одновременно на несколько endpoints с разных IP.
# Количество уникальных IP атакующих разные endpoints одновременно
grep -E "wp-login|xmlrpc|wp-json" /var/log/nginx/access.log | \
awk '{print $1}' | sort -u | wc -l
# Если 50+ уникальных IP атакуют разные точки — координированный ботнетПризнак 4: объём запросов не вызывает rate limiting, но атака очевидна по количеству IP.
Если всё это видишь одновременно — это AI-ботнет. Одиночная блокировка по IP не поможет.
ЧТО ДЕЛАТЬ ЕСЛИ АТАКА УЖЕ ИДЁТ
Пошаговый план на случай если сайт уже под атакой и нужно действовать быстро.
Шаг 1 — оценить масштаб:
# Сколько запросов к wp-login за последние 1000 строк лога?
tail -n 1000 /var/log/nginx/access.log | grep -c "wp-login"
# Смотреть поток в реальном времени (Ctrl+C для выхода):
tail -f /var/log/nginx/access.log | grep "wp-login"
# Сколько уникальных IP за последние 10 минут?
awk -v d="$(date -d '10 minutes ago' '+%d/%b/%Y:%H:%M')" \
'$0 > d' /var/log/nginx/access.log | \
grep "wp-login" | awk '{print $1}' | sort -u | wc -lШаг 2 — немедленно включить Cloudflare Under Attack Mode если сайт за Cloudflare:
В дашборде: Security → Settings → Security Level → I’m Under Attack. Cloudflare добавит JS challenge для всех посетителей. Боты отсеются мгновенно, легитимные пользователи пройдут через 5 секунд.
Шаг 3 — заблокировать wp-login.php через nginx для всех кроме своего IP:
# Временная блокировка в nginx — добавить в server{}
location = /wp-login.php {
allow ТВОЙ_IP;
deny all;
}nginx -t && systemctl reload nginxШаг 4 — дать fail2ban добрать оставшихся:
# Посмотреть что уже забанено
fail2ban-client status nginx-wplogin
# Принудительно забанить подсеть вручную
fail2ban-client set nginx-wplogin banip 185.220.101.0/24Шаг 5 — после стабилизации провести анализ: откуда пришла атака, какие endpoints атаковались, что пропустила защита.
КАК НАСТРОИТЬ АЛЕРТЫ ДО ТОГО КАК САЙТ УПАДЁТ
Атаку лучше обнаружить за 10 минут до падения а не после. Несколько способов.
Простой алерт через bash + systemd timer — если количество уникальных атакующих IP превысило порог:
#!/bin/bash
# /usr/local/bin/check-wp-attack.sh
THRESHOLD=30
COUNT=$(awk -v d="$(date -d '5 minutes ago' '+%d/%b/%Y:%H:%M')" \
'$0 > d && /POST \/wp-login.php/' /var/log/nginx/access.log | \
awk '{print $1}' | sort -u | wc -l)
if [ "$COUNT" -gt "$THRESHOLD" ]; then
echo "ALERT: $COUNT unique IPs attacking wp-login.php in last 5 min" | \
mail -s "WordPress attack detected: $(hostname)" [email protected]
fiЗапускать через systemd timer каждые 5 минут:
# /etc/systemd/system/wp-attack-check.service
[Unit]
Description=Check for WordPress brute force attack
[Service]
Type=oneshot
ExecStart=/usr/local/bin/check-wp-attack.sh# /etc/systemd/system/wp-attack-check.timer
[Unit]
Description=Run WordPress attack check every 5 minutes
[Timer]
OnBootSec=5min
OnUnitActiveSec=5min
[Install]
WantedBy=timers.targetsystemctl enable --now wp-attack-check.timer
systemctl list-timers | grep wp-attackЕсли используется Cloudflare — настроить алерты в Security → Notifications → Under Attack Mode Activation и Custom Firewall Rules Triggered.
HONEYPOT И ГЕОБЛОКИРОВКА
Honeypot — ловушка для ботов
Идея простая: создать URL который никогда не запрашивает легитимный пользователь, но который боты находят при сканировании. Любой запрос к нему — автоматически бот.
Создать honeypot endpoint в nginx:
location = /wp-admin/install.php {
# Легитимный пользователь никогда не заходит сюда на рабочем сайте
# Любой запрос = бот
access_log /var/log/nginx/honeypot.log; # Отдельный лог для ботов
return 403;
}
# Примечание: location не матчит query string в nginx.
# Для блокировки ?action=register используется if в server{} контексте:
# if ($arg_action = "register") {
# access_log /var/log/nginx/honeypot.log;
# return 403;
# }Автоматически банить всех кто стучится в honeypot через fail2ban:
# /etc/fail2ban/filter.d/nginx-honeypot.conf
[Definition]
failregex = ^<HOST> - - \[.*\] "(GET|POST) /(wp-admin/install\.php|wp-login\.php\?action=register).* HTTP/.*" \d+
ignoreregex =# /etc/fail2ban/jail.d/nginx-honeypot.conf
[nginx-honeypot]
enabled = true
port = http,https
filter = nginx-honeypot
logpath = /var/log/nginx/honeypot.log
maxretry = 1
bantime = 604800 # 7 дней
action = nftables-multiport[name=honeypot, port="80,443", protocol=tcp]Один запрос — сразу 7-дневный бан. Легитимный пользователь туда не пойдёт никогда.
Геоблокировка через nftables
Если сайт работает в конкретном регионе — весь трафик из других регионов можно отсечь на уровне ядра. Для WordPress-блога на русском языке нет причин принимать соединения из Бразилии или Индонезии в 3 ночи.
Использовать готовые GeoIP-списки. Наиболее актуальный способ в 2026 году — через ipset совместно с nftables, или через Cloudflare если сайт за ним.
Через Cloudflare — самый простой способ: Security → WAF → Tools → IP Access Rules → Block country.
Через nftables с использованием списков от ipdeny.com:
# Скачать список IP для блокировки (например, все кроме RU, EU, US)
wget -q http://www.ipdeny.com/ipblocks/data/aggregated/cn-aggregated.zone \
-O /etc/nftables/geo-block-cn.txt
# Создать set из файла и добавить правило
nft add set inet filter geo_block { type ipv4_addr\; flags interval\; }
nft add rule inet filter input ip saddr @geo_block drop
# Загрузить IP-адреса в set
while read -r cidr; do
nft add element inet filter geo_block { $cidr }
done < /etc/nftables/geo-block-cn.txtВажно: геоблокировка — это грубый инструмент. Она отсекает и легитимных пользователей из заблокированных регионов. Используй только если уверен что целевая аудитория сайта географически ограничена.
Почему WordPress — главная мишень для AI-ботнетов
Не потому что WordPress менее безопасен чем другие CMS. А потому что WordPress — это масштаб: по данным W3Techs, более 43% всех сайтов в интернете работают на WordPress. Это означает что один ботнет с одним набором правил атакует миллионы потенциальных целей одновременно.
AI-ботнет окупается быстро: стоимость аренды составляет десятки долларов в день, а один скомпрометированный сервер с хорошей репутацией домена стоит на даркнет-рынках от $500 до нескольких тысяч долларов. Математика простая — атаковать WordPress выгодно.
Второй фактор: предсказуемая структура. Все WordPress-сайты имеют одинаковые endpoints — wp-login.php, xmlrpc.php, wp-json, wp-admin. Ботнет знает где искать без предварительной разведки.
КУДА ЭТО ВСЁ ИДЁТ
То что происходит сейчас — только начало. Несколько тенденций которые уже видны и будут нарастать.
Атаки без участия человека
Сегодня AI-ботнет всё ещё управляется людьми — кто-то запускает кампанию, задаёт цели, анализирует результаты. Следующий шаг — полностью автономные системы которые самостоятельно выбирают цели, адаптируют тактику и монетизируют доступ. Первые признаки уже есть: RondoDox за девять месяцев прошёл от ручного сканирования до почасового автоматизированного развёртывания без видимого участия операторов.
AI против AI
Это уже происходит. Cloudflare Bot Management, Wordfence, Imperva — все используют машинное обучение для детектирования аномалий. Атакующие знают об этих системах и обучают своих ботов обходить именно их. Возникает гонка вооружений где обе стороны итерируют быстрее чем люди успевают анализировать.
По данным Darktrace из отчёта State of AI Cybersecurity 2025, 78% директоров по информационной безопасности сообщили что AI-атаки существенно влияют на их организации. При этом более 60% заявили что чувствуют себя готовыми к защите — рост на 15% по сравнению с 2024 годом. Но среди ключевых барьеров по-прежнему называют нехватку знаний об AI и дефицит персонала.
Размытие границы между ботом и человеком
Headless браузеры с AI умеют имитировать человеческое поведение — движения мыши, паузы между кликами, скроллинг, реалистичное время чтения страницы. CAPTCHA которая в 2020 году останавливала 99% ботов, в 2026 году останавливает значительно меньше. Cloudflare Turnstile и подобные системы сместились от «докажи что ты человек» к поведенческому анализу всей сессии — но и атакующие адаптируются.
Что это значит для администратора
Профессия меняется. Раньше достаточно было настроить правила — fail2ban забанит, nftables заблокирует, и можно спать спокойно. Теперь правила статичны, а атаки динамичны. Всё больше времени уходит не на настройку защиты а на анализ паттернов, интерпретацию аномалий, понимание логики атакующего.
Хорошие новости: инструменты защиты тоже становятся умнее. Cloudflare, Wordfence Premium, Imunify360 — всё это уже не просто правила а адаптивные системы. Задача администратора смещается от «написать правило» к «правильно настроить и интерпретировать то что AI-защита находит».
Плохие новости: порог входа для атакующих падает. Раньше для сложной скоординированной атаки нужны были знания и ресурсы. Сейчас достаточно арендовать готовый AI-ботнет как сервис — такие предложения уже есть на даркнет-рынках.
Интернет становится местом где большинство трафика генерируют машины, атакующие машины защищаются машинами, и люди всё больше оказываются в роли операторов и аналитиков — а не исполнителей рутинных задач.
ИТОГ
AI-ботнеты не изменили цели атак — wp-login.php, xmlrpc.php, REST API, непатченные плагины. Они изменили скорость и адаптивность. То что раньше блокировалось за минуту теперь может незаметно работать часами.
Хорошая новость: базовая гигиена по-прежнему работает. Закрытый xmlrpc.php, закрытый wp-json users endpoint, rate limiting на wp-login.php, обновлённые плагины и 2FA — это не серебряная пуля, но это убирает сайт из категории «лёгкая добыча».
Боты атакуют всё подряд. Задача не стать неуязвимым — задача стать достаточно сложной целью чтобы ботнет переключился на следующий сайт в очереди.
Если вам понравилась статья — вы можете поддержать автора.
