Как проверить VPS на взлом: rkhunter, chkrootkit и логи

По заявлению FirstVDS от 18.10.2026, 17 октября на части её узлов виртуализации работала программа, которая подключала диски клиентских VPS и копировала с них SSH-ключи, пароли, токены и конфиги. Внутри самих серверов она не запускалась и ничего не меняла на дисках. Хостер отправил владельцам затронутых серверов уведомления на почту и в личный кабинет. Мы разбирали этот случай в материале о взломе FirstVDS через VMmanager 6, и главный вопрос клиентов после него — как понять, был ли кто-то на сервере.

Ниже — порядок, как проверить VPS на взлом в двух сценариях: взлом изнутри (подобранный пароль, дыра в CMS, украденный ключ) и утечка снаружи, когда в системе следов нет. Команды сверены с man-страницами и документацией пакетов Debian 12, Ubuntu 22.04 и 24.04, версии утилит — по репозиториям на 21.10.2026. В конце — чек-лист и план на случай находок.

Признаки компрометации, с которых начинают проверку

Повод для проверки часто приходит со стороны: письмо хостера, жалоба на спам с вашего IP, чужой счёт за облако. Изнутри взлом выдаёт себя так:

• процессор загружен на 100% без видимой причины — типичная картина для майнера;
• в списке процессов есть незнакомые имена или бинарники, запущенные из /tmp, /var/tmp, /dev/shm;
• сервер сам открывает исходящие соединения на неизвестные адреса и порты;
• в системе появились пользователи, ключи SSH или задания cron, которые вы не создавали;
• журналы входов пустые или обрываются на дате, хотя сервер всё это время работал;
• ps или ls не показывают то, что видно в /proc.

Ни один пункт сам по себе не доказывает взлом: майнером может оказаться зависший скрипт сборки. Каждую аномалию нужно объяснить.

Сначала снимок, потом команды

Перед проверкой сделайте снапшот диска в панели хостера или скопируйте журналы на другую машину — так улики сохранятся. Разница снапшота и бэкапа — в статье о снапшотах и бэкапах.

# На сервере: архив журналов, включая журнал systemd в /run/log/journal, если он там
sudo tar czf /root/logs-$(date +%F).tar.gz --ignore-failed-read /var/log /run/log/journal

# Экспорт журнала systemd целиком
sudo journalctl --no-pager -o export | sudo tee /root/journal-$(date +%F).export > /dev/null

# На своём компьютере: забрать оба файла
scp 'root@IP_СЕРВЕРА:/root/logs-*.tar.gz' 'root@IP_СЕРВЕРА:/root/journal-*.export' ./

У проверок изнутри общее ограничение: атакующий с правами root может подменить ps, ss, ls и даже файлы пакетного менеджера — FAQ rkhunter предупреждает об этом прямо. Чистый результат не исключает взлом. Надёжнее загрузить VPS в режиме восстановления (rescue), если провайдер его даёт, и смотреть диск со стороны.

Кто и откуда входил: last, lastb и журнал SSH

Журнал входов — первое место, где видны чужие подключения. Команда last читает /var/log/wtmp и показывает успешные сеансы, lastb — неудачные попытки из /var/log/btmp (нужен root). Ключ -F выводит полные даты, -i — IP вместо имён хостов.

last -Fi | head -40
sudo lastb -Fi | head -40
who

Подробнее всего входы записывает сам sshd. Если в системе установлен rsyslog, записи дублируются в текстовый файл /var/log/auth.log — проверьте его наличие командой ls /var/log/auth.log*. В Debian 12 rsyslog больше не ставится по умолчанию — об этом сказано в примечаниях к выпуску bookworm, — и журнал читают через journalctl. Клиентам хостеров на VMmanager 6 разумно смотреть входы с 11 октября: ForestsNet Cloud пишет о заражении панелей с 11 по 16 октября.

# Debian 12 и Ubuntu: журнал systemd
sudo journalctl -u ssh --since "2026-10-11" --no-pager | grep -E "Accepted|Invalid user"

# Если есть rsyslog: текстовый журнал, включая ротированные архивы
sudo zgrep -h "Accepted" /var/log/auth.log*

# Список IP, с которых были успешные входы, с числом сеансов
sudo journalctl -u ssh --since "2026-10-11" --no-pager | grep "Accepted" \
  | awk '{for(i=1;i<=NF;i++) if($i=="from") print $(i+1)}' | sort | uniq -c | sort -rn

Строка Accepted publickey for root from 203.0.113.5 port 51234 ssh2: ED25519 SHA256:... содержит способ входа, пользователя, IP и отпечаток ключа, которым вошли. Незнакомые IP сверьте со своими: домашним, офисным, CI, поддержкой хостера — FirstVDS, например, опубликовала адреса своей поддержки.

Дыры в журнале — отдельный повод разобраться. Если journalctl --list-boots показывает одну загрузку, хотя сервер перезагружался, проверьте, где хранится журнал: по man journald.conf, в режиме volatile записи лежат только в памяти, в /run/log/journal. Провал на несколько дней или пустой /var/log/wtmp — повод проверить настройки хранения, ротацию и архивы; умышленное удаление — одна из возможных причин. Проверки wtmp и lastlog в chkrootkit, по его README, ловят такие правки не всегда.

Вход по паролю после проверки закройте — помогут гайды по SSH на VPS и по Fail2ban.

Чужие ключи в authorized_keys и настройках sshd

Свой ключ в authorized_keys — простой способ вернуться на сервер даже после смены пароля; на этот признак указывают FirstVDS и ForestsNet. Найдите все такие файлы, посмотрите даты изменения и выведите отпечатки ключей.

# Локальные файловые системы: -xdev не переходит в другие точки монтирования,
# поэтому поиск запускается для каждой из них
findmnt -rn -t ext4,xfs,btrfs -o TARGET
for m in $(findmnt -rn -t ext4,xfs,btrfs -o TARGET); do
  sudo find "$m" -xdev \( -name authorized_keys -o -name authorized_keys2 \) -ls
done

# Дата изменения файлов ключей у root и пользователей
sudo find /root /home -path "*/.ssh/*" -name "authorized_keys*" -printf '%TY-%Tm-%Td %TH:%TM %p\n'

# Отпечатки ключей — повторить для каждого найденного файла
sudo ssh-keygen -lf /root/.ssh/authorized_keys

Отпечатки сверьте со своими ключами. Комментарий в конце строки (user@laptop) ничего не доказывает — его пишет тот, кто добавил ключ. Перед удалением чужого ключа сохраните копию файла.

Вместо authorized_keys атакующий может поменять настройку sshd — подставить свой файл ключей или команду, которая их выдаёт. sshd -T печатает итоговую конфигурацию с учётом /etc/ssh/sshd_config.d/, а с ключом -C, по man sshd, ещё и применяет блоки Match для заданного подключения.

sudo sshd -T | grep -iE "authorizedkeys(file|command)|permitrootlogin|passwordauthentication"

# То же с учётом блоков Match: подставьте проверяемого пользователя, адрес и имя хоста
sudo sshd -T -C user=root,addr=203.0.113.5,host=example.org | grep -iE "authorizedkeys(file|command)|permitrootlogin|passwordauthentication"
ls -la --time-style=full-iso /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

В норме authorizedkeysfile указывает на .ssh/authorized_keys .ssh/authorized_keys2, а authorizedkeyscommand равен none. Иное значение, которое вы не задавали, — повод копать дальше.

Новые пользователи и права sudo

Второй способ закрепиться — новый пользователь с UID 0 или запись в sudo. Проверьте учётные записи с UID 0, обычных пользователей с оболочкой входа и всё, что разрешает sudo.

# Все, у кого UID 0 — в норме только root
awk -F: '$3 == 0 {print $1}' /etc/passwd

# Обычные пользователи и их оболочки
awk -F: '$3 >= 1000 && $3 < 65534 {print $1, $6, $7}' /etc/passwd

# Кто в группе sudo и что разрешено в sudoers
getent group sudo
sudo grep -rvhE '^\s*(#|$)' /etc/sudoers /etc/sudoers.d/

# Когда менялись файлы учётных записей
ls -la --time-style=full-iso /etc/passwd /etc/shadow /etc/group /etc/sudoers.d/

Подозрительны второй UID 0, служебная учётная запись вроде www-data с /bin/bash вместо /usr/sbin/nologin и NOPASSWD: ALL в незнакомом файле /etc/sudoers.d/. Как устроены пользователи и права, рассказано в гайде о создании пользователя и отказе от root.

Автозапуск: cron, systemd и таймеры

Чтобы пережить перезагрузку и завершение процесса, майнеру или бэкдору нужен автозапуск. Cron — первое место для проверки: системные задания в /etc/crontab и /etc/cron.*, пользовательские — в /var/spool/cron/crontabs/.

cat /etc/crontab
sudo ls -la --time-style=full-iso /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly
sudo ls -la /var/spool/cron/crontabs/

# Задания всех пользователей одним списком
for u in $(cut -d: -f1 /etc/passwd); do
  sudo crontab -l -u "$u" 2>/dev/null | grep -vE '^\s*(#|$)' | sed "s/^/$u: /"
done

Тревожный признак — задание, которое качает что-то через curl или wget и передаёт в sh, или запускает файл из /tmp. Синтаксис расписаний — в гайде по настройке cron.

В systemd вредонос прячут под службы с правдоподобными именами. «Фейковые системные службы» Senko Digital перечисляет в наборе атакующего в постмортеме атаки через VMmanager — правда, на узлах хостеров. Проверьте включённые службы, таймеры и юниты не из пакетов.

systemctl list-timers --all
systemctl list-unit-files --type=service --state=enabled

# Юниты, изменённые после даты инцидента
sudo find /etc/systemd /usr/lib/systemd -type f -newermt "2026-10-11" -ls
sudo find /root /home -path "*/.config/systemd/*" -type f -newermt "2026-10-11" -ls

# Юниты в /etc/systemd/system, которых нет ни в одном пакете
for f in /etc/systemd/system/*.service /etc/systemd/system/*.timer; do
  [ -f "$f" ] && ! dpkg -S "$f" >/dev/null 2>&1 && echo "не из пакета: $f"
done

# Посмотреть, что именно запускает служба
systemctl cat имя.service

В последнюю выборку попадут и ваши собственные юниты. Ещё места автозапуска: /etc/ld.so.preload (в норме его нет или он пуст, а библиотека оттуда грузится в каждый процесс), /etc/rc.local, /etc/profile.d/, ~/.bashrc, ~/.profile.

cat /etc/ld.so.preload 2>/dev/null
ls -la --time-style=full-iso /etc/profile.d/ /etc/rc.local 2>/dev/null

Процессы и сетевые соединения

Работающий вредонос выдаёт себя нагрузкой и соединениями: ss -tulpn показывает открытые порты с процессами, второй вызов — текущие подключения.

sudo ss -tulpn
sudo ss -tnp state established

# Процессы по загрузке CPU с временем запуска
ps -eo pid,ppid,user,%cpu,%mem,lstart,cmd --sort=-%cpu | head -20

# Процессы, чей бинарник удалён с диска или лежит во временных каталогах
sudo ls -l /proc/*/exe 2>/dev/null | grep -E 'deleted|/tmp/|/var/tmp/|/dev/shm/'

# Что лежит во временных каталогах
sudo ls -la /tmp /var/tmp /dev/shm

Главные зацепки — незнакомый процесс на порту и исходящие соединения на нестандартные порты. Пометка (deleted) значит, что бинарник удалили после запуска; так бывает и у служб, обновлённых без перезапуска. Подробнее — в гайде о процессах в Linux, лишние порты закрывает файрвол на Linux-сервере.

Изменённые файлы: find -newermt и проверка пакетов

Поиск по дате сужает круг подозрительных файлов. Ключ -newermt находит файлы, изменённые после указанной даты. Время изменения (mtime) подделывается командой touch, а время смены метаданных (ctime) так просто не подменить — его проверяет -newerct.

# Файлы в ключевых каталогах, изменённые после 11 октября: полный список в файл
sudo find /etc /usr /root /home /var/www -xdev -type f -newermt "2026-10-11" 2>/dev/null > ~/changed-mtime.txt

# Системные бинарники и библиотеки по ctime
sudo find /usr/bin /usr/sbin /usr/lib -xdev -type f -newerct "2026-10-11" -ls 2>/dev/null > ~/changed-ctime.txt

# Сколько нашлось и предварительный просмотр — разбирать нужно весь список
wc -l ~/changed-mtime.txt ~/changed-ctime.txt
head -100 ~/changed-mtime.txt

# Сверка с тем, что ставил apt
grep -E "^(Start-Date|Commandline|Install|Upgrade)" /var/log/apt/history.log

Изменения в /usr обычно объясняются обновлениями из /var/log/apt/history.log. Подозрительны файлы, которые поменялись в день без обновлений.

Второй способ — сверить файлы с контрольными суммами пакетов. dpkg --verify, по man-странице dpkg, сейчас проверяет только md5 содержимого. Строка ??5?????? значит, что содержимое изменилось, буква c перед путём — что это конфиг, который вы могли править сами.

# Изменённые файлы пакетов, без конфигов
sudo dpkg --verify | grep -v ' c /'

# debsums: только ошибки и список изменённых файлов
sudo apt install debsums
sudo debsums -s
sudo debsums -c

# Пакеты без файла контрольных сумм
sudo debsums -l

# Бинарники с битом SUID, которых нет ни в одном пакете (повторить для каждой точки монтирования)
sudo find / -xdev -type f -perm -4000 -print0 2>/dev/null | xargs -0 -r env LC_ALL=C dpkg -S 2>&1 | grep 'no path found'

Изменённый /usr/bin/ps, /usr/bin/ss или /usr/sbin/sshd — серьёзный сигнал. Man-страница debsums называет утилиту инструментом «ограниченной пользы» для безопасности: суммы лежат на том же диске, и root может их переписать. Независимо сверить файлы можно только с чистой системы: загрузите VPS в режиме восстановления, подключите диск и сравните бинарники с файлами из пакетов, скачанных из репозитория (apt-get download пакет, dpkg-deb -x пакет.deb каталог). Переустановка пакетов на самом сервере меняет исследуемые файлы и не убирает другие закрепления; при подтверждённом взломе сервер разворачивают из чистого образа, как советует и README chkrootkit.

rkhunter: установка, первый прогон и разбор предупреждений

Rootkit Hunter ищет известные руткиты, сравнивает свойства системных файлов с сохранённой базой и проверяет подозрительные настройки. Последний релиз — 1.4.6 от 20 февраля 2018 года, по журналу изменений проекта. В репозиториях на 21.10.2026: 1.4.6-11 в Debian 12, 1.4.6-10 в Ubuntu 22.04, 1.4.6-12 в Ubuntu 24.04.

sudo apt update
sudo apt install --no-install-recommends rkhunter

Без --no-install-recommends apt потянет рекомендованный почтовый агент и попросит настроить почтовый сервер. В сборках Debian и Ubuntu онлайн-обновление сигнатур отключено патчем (WEB_CMD="/bin/false", баг Debian #765895), и ошибка rkhunter --update — ожидаемое поведение: базы обновляются вместе с пакетом.

Перед первой проверкой rkhunter записывает свойства файлов в базу /var/lib/rkhunter/db/rkhunter.dat, и здесь ловушка. По FAQ rkhunter, программа видит только изменения и не знает, подлинный ли файл. --propupd на взломанной системе запишет подменённые бинарники как эталон, и локальная база dpkg тут не спасает: её тоже можно изменить. На подозрительном сервере эталон не создавайте. Без файла rkhunter.dat программа предупредит, что база пуста, и не выполнит проверку свойств файлов (FAQ, п. 4.1), но остальные проверки пройдут. Эталон создают на заведомо чистой системе — сразу после установки из образа — или после независимой проверки файлов.

# Только чистая, только что установленная система: создать эталон
sudo rkhunter --propupd

# Проверка без пауз между разделами
sudo rkhunter --check --sk

# Только предупреждения — удобно для повторных прогонов
sudo rkhunter --check --sk --rwo

# Подробности по предупреждениям
sudo grep -E "Warning" /var/log/rkhunter.log

Журнал по умолчанию — /var/log/rkhunter.log (man rkhunter), детали каждого [ Warning ] ищите там. FAQ делит предупреждения на два типа. Проверка свойств файла часто срабатывает ложно — после обновления пакетов или ручной правки. Предупреждения остальных проверок, по словам авторов, означают проблему и требуют расследования.

Типичные ложные срабатывания на Debian и Ubuntu — по README.Debian пакета, FAQ и комментариям в rkhunter.conf:

• скрытые каталоги /etc/.java, /dev/.udev, /dev/.initramfs — их создают java, udev и initramfs;
• системные команды-скрипты — часть из них (egrep, fgrep, which, ldd, adduser) Debian уже внёс в белый список SCRIPTWHITELIST;
• изменившиеся хеши после apt upgrade — эталон пересчитывают --propupd, но, по FAQ, только после того, как подлинность файлов подтверждена средствами проверки целостности или пакетного менеджера;
• вход root по SSH — rkhunter сверяет PermitRootLogin с опцией ALLOW_SSH_ROOT_USER (по умолчанию no) и ругается при расхождении.

Исключения пишут в /etc/rkhunter.conf.local — его не перезаписывает обновление пакета — и проверяют конфиг командой rkhunter -C. FAQ просит не добавлять исключения автоматически: каждое предупреждение сначала разбирают руками.

# /etc/rkhunter.conf.local
ALLOWHIDDENDIR=/etc/.java
# значение должно совпадать с PermitRootLogin в sshd_config;
# если опция там не задана — unset
ALLOW_SSH_ROOT_USER=prohibit-password

sudo rkhunter -C

Ежедневный запуск настраивается в /etc/default/rkhunter (CRON_DAILY_RUN, REPORT_EMAIL). APT_AUTOGEN пересчитывает базу после установки пакетов, но README.Debian предупреждает: файл можно подменить между установкой и пересчётом.

chkrootkit: что значит INFECTED и когда это ложная тревога

chkrootkit ищет следы известных руткитов в системных бинарниках, интерфейсы в режиме прослушивания, удаления в wtmp и lastlog, скрытые процессы. Последняя версия на сайте проекта — 0.59 от 1 января 2026 года, в репозиториях на 21.10.2026 старше: 0.57 в Debian 12, 0.55 в Ubuntu 22.04, 0.58b в Ubuntu 24.04.

sudo apt install --no-install-recommends chkrootkit

# Полный вывод
sudo chkrootkit

# Только строки со статусом INFECTED
sudo chkrootkit -q

По README, каждый тест заканчивается одним из статусов:

По README.Debian, chkrootkit намеренно склонен к перестраховке. Типичные ложные тревоги из README.FALSE-POSITIVES пакета:

• PACKET SNIFFER на сетевых службах — systemd-networkd, NetworkManager, wpa_supplicant, dhclient слушают трафик легально;
• файлы с точкой в начале имени внутри /usr/lib — например, /usr/lib/debug/.build-id из libc6-dbg;
• процессы без терминала в utmp — так выглядит всё, что запущено внутри tmux или screen;
• легальные службы на портах, которые использовали старые руткиты (тест bindshell).

Каждый INFECTED проверяйте вручную: чей это файл (dpkg -S путь), сходится ли сумма (debsums имя_пакета), кто слушает порт (ss -tulpn). Повторяющиеся тревоги в Debian 12 глушат через /etc/chkrootkit/chkrootkit.conf и /etc/chkrootkit/chkrootkit.ignore. Там же настраивается ежедневная проверка, которая присылает только отличия от эталона /var/log/chkrootkit/log.expected.

Когда системным бинарникам нет доверия, помогают два ключа. -p задаёт путь к чистым копиям команд. -r задаёт другой корень: README советует подключить диск взломанной машины к доверенной системе и проверять оттуда — для VPS это режим восстановления.

# Диск VPS подключён в rescue-системе в /mnt
sudo chkrootkit -r /mnt

Lynis: аудит настроек, а не поиск вируса

Lynis от CISOfy — сканер безопасности для Linux под лицензией GPL. Вредонос он не ищет, а проверяет настройки: SSH, права, обновления, файрвол, журналы. Тесты MALW-3275 и MALW-3276 в его исходниках лишь смотрят, установлены ли chkrootkit и rkhunter. После взлома он полезен как список слабых мест.

В репозиториях старые версии: 3.0.8 в Debian 12, 3.0.7 в Ubuntu 22.04, 3.0.9 в Ubuntu 24.04. Свежий выпуск на GitHub — 3.1.7 от 25 июня 2026 года, он запускается прямо из клонированного каталога без сборки.

# Из репозитория дистрибутива
sudo apt install lynis
sudo lynis audit system

# Или свежая версия с GitHub
cd /opt && sudo git clone https://github.com/CISOfy/lynis
cd /opt/lynis && sudo ./lynis audit system

# Предупреждения и рекомендации из отчёта
sudo grep -E '^(warning|suggestion)\[\]' /var/log/lynis-report.dat

# Подробности по конкретному тесту: пакетная версия
sudo lynis show details ID-ТЕСТА

# То же для версии из Git — она не попадает в PATH
sudo /opt/lynis/lynis show details ID-ТЕСТА

По документации, подробности пишутся в /var/log/lynis.log (перезаписывается при каждом запуске), находки — в /var/log/lynis-report.dat. Индекс защищённости (Hardening index) в конце вывода — оценка настроек, о взломе он ничего не говорит.

Чего не увидит ни один сканер: атака через гипервизор

Все проверки выше смотрят изнутри и могут не обнаружить чтение диска со стороны гипервизора. Так было в октябре 2026 года у части клиентов FirstVDS: по заявлению компании, программа для кражи данных работала на части узлов виртуализации, подключала диски клиентских серверов в режиме «только чтение» и копировала файлы наружу. Внутри VPS она не запускалась и ничего не меняла, так что rkhunter, chkrootkit, журналы входов и find -newermt следов самого чтения не покажут. Отсутствие находок не подтверждает безопасность VPS, но проверки ловят вторичный вход и другой вредонос.

FirstVDS в Telegram-канале написала: получившим уведомление считать данные скопированными, а отсутствие уведомления значит лишь, что на узлах следов не нашли. Второй канал утечки — база панели: по словам ForestsNet Cloud, из неё утекли IP серверов, email, root-пароли, заданные через панель, и пароли VNC. ForestsNet там же предупреждает: одной переустановки ОС мало, секреты нужно менять.

В таком сценарии проверяют не систему, а секреты на ней: ключи SSH, токены API, пароли БД, файлы .env, доступы к облакам и репозиториям, историю команд.

# Где на сервере лежат секреты (повторить для каждой точки монтирования)
sudo find / -xdev ! -path "/usr/*" \( -name ".env" -o -name "id_rsa" -o -name "id_ed25519" -o -name "*.pem" \
  -o -name ".git-credentials" -o -name "credentials" -o -name "wp-config.php" \) 2>/dev/null

# История команд — сюда попадают пароли, набранные в командной строке
sudo find /root /home -maxdepth 2 -name ".*_history" -ls

Каждый секрет отзовите в источнике и выпустите заново — в консоли облака, на GitHub и GitLab, у платёжного провайдера, в БД — и там же ищите следы его использования. Внутри VPS остаётся искать вторичный вход по украденному паролю root или ключу после 17 октября — он виден в journalctl -u ssh. Хронология инцидента и рекомендации хостеров — в нашей новости о взломе VMmanager 6.

Чек-лист проверки VPS на взлом

Если следы нашлись

Найденный руткит или бэкдор не лечат на месте. FAQ rkhunter формулирует это без оговорок: «никогда не доверяйте скомпрометированной машине». После очистки может остаться второй вход, который проверка не заметила. Рабочий порядок такой:

1. Сохраните снапшот и журналы для разбора, если ещё не сделали.
2. Закройте атакующему доступ: смените пароли и ключи с чистого устройства, ограничьте SSH своими адресами.
3. Разверните новый VPS из чистого образа и перенесите данные из бэкапа, сделанного до даты проникновения. Как держать такие копии отдельно от сервера, мы описали в гайде по бэкапам VPS.
4. Отзовите и перевыпустите все секреты, которые были на сервере: ключи, токены, пароли БД и сервисов.
5. Закройте путь, через который вошли: вход только по ключам, Fail2ban, файрвол, обновления ПО и CMS.
6. Если на сервере были персональные данные клиентов, проконсультируйтесь с юристом по требованиям 152-ФЗ — так советует и FirstVDS своим пострадавшим клиентам.

Если доверие к провайдеру потеряно, новый сервер можно подобрать в каталоге VPS и VDS или в рейтинге защищённых VPS-хостингов, а при атаках по сети пригодится раздел о DDoS-защите. rkhunter и chkrootkit в Debian и Ubuntu умеют запускаться ежедневно и слать отчёт на почту — проверку разумно держать по расписанию.