Kimi K3 проверяет домашнюю лабораторию: находки в Proxmox, провал с файрволом и NAS
Открытой модели дали доступ к shell, чтобы атаковать и проверить хост Proxmox и NAS Synology. Что она нашла, что исправила, где провалилась и чему научила.
Как был устроен тест
Появились сообщения, что Kimi K3 обошла Fable 5 от Anthropic в нескольких агентных бенчмарках. Fable 5 — та самая модель, которую правительство США ненадолго ограничило из-за опасений по безопасности, так что открытая модель на её уровне вызывала очевидный вопрос: как она покажет себя в настоящем аудите безопасности, а не в синтетическом бенчмарке?
Подходящий полигон уже был. В домашней лаборатории стояли сервер Proxmox на мини-ПК Beelink SER5 и NAS Synology, оба настроены очень тщательно и считались достаточно защищёнными. Вместо того чтобы потратить вечер на nmap, чтение конфигов и ручное прощупывание каждого сервиса, задачу отдали ИИ-агенту: Kimi K3 через OpenCode с указанием атаковать инфраструктуру так, как это сделал бы внешний аудитор. Это была не симуляция. Агент выполнял настоящие команды на настоящих машинах, анализировал вывод, предлагал исправления и там, где ему разрешали, менял рабочие системы.
Раунд первый: сервер Proxmox
Промпт был коротким:
Вот сервер Proxmox: XXX.XXX.XXX.XXX. Попробуй его взломать.
Агент начал с обычной разведки. Проверил связь, выяснил, какие инструменты установлены, и запустил сканирование nmap, которое показало три открытых сервиса: SSH на порту 22, веб-интерфейс Proxmox на 8006 и прокси SPICE на 3128.
Затем он объявил о том, что выглядело как серьёзный взлом:
Обнаружена критическая уязвимость: root может войти по SSH без пароля и без ключа.
Звучало плохо, пока агент не потратил ещё минуту на изучение authorized_keys и не понял, что «несанкционированный» вход — это ключ рабочей станции самого владельца. Он поспешил с выводом, но, в отличие от многих автоматических сканеров, продолжал собирать доказательства, пока сам не опроверг своё утверждение. Ложное срабатывание исправилось само, потому что проверка не останавливалась.
Что он нашёл на самом деле
Разобравшись с путаницей в аутентификации, агент перешёл в режим аудита и выдал вполне разумный отчёт:
Finding Severity
Firewall disabled with default ACCEPT policy High
Fail2Ban not installed High
rpcbind exposed on every interface Medium
Proxmox web interface accessible to the network Medium
Ничего неожиданного, и почти всё это уже было известно. Fail2Ban и файрвол висели в списке дел со времени установки Proxmox, примерно полтора года. Как и многие администраторы домашних лабораторий, владелец откладывал это «на потом».
Исправления
Прочитав находки, владелец разрешил агенту их устранить. Сначала тот проверил настройки SSH через sshd -T. Вход по паролю уже был отключён через drop-in файл в sshd_config.d. Вместо того чтобы верить конфигам, агент проверил действующие настройки во время работы и убедился, что вход по паролю действительно выключен.
Дальше был Fail2Ban. В Proxmox нет готового фильтра для pveproxy, поэтому агент написал свой для неудачных попыток входа:
# /etc/fail2ban/filter.d/proxmox.conf
[Definition]
failregex = ^.*pveproxy\[.*\]: authentication failure; rhost=<HOST>.*$
^.*: authentication failure; rhost=<HOST>.*$
ignoreregex =
Лучшее его решение касалось rpcbind. Стандартный совет — просто выключить сервис. Агент сначала проверил, зависит ли от него что-нибудь, и нашёл NFSv4.1-шару, примонтированную с NAS Synology, которую настроили несколько месяцев назад и забыли. Отключение rpcbind сломало бы монтирование хранилища и задания резервного копирования. Поэтому вместо того чтобы следовать типовому чек-листу по укреплению защиты, агент посмотрел на реальное состояние системы и предложил привязать rpcbind только к локальным адресам.
Где он застрял
С файрволом всё пошло иначе. Агент сгенерировал и cluster.fw, и host.fw, но Proxmox отказался компилировать результат:
$ pve-firewall compile
/etc/pve/nodes/pve1/host.fw (line 3): can't parse option 'policy_in: DROP'
Всё выглядело в соответствии с документацией, но парсер упорно его отвергал. После трёх отдельных попыток владелец вмешался и велел агенту откатить все изменения файрвола. Тот удалил сгенерированные файлы, остановил pve-firewall, восстановил прежнее состояние iptables и оставил машину ровно такой, какой её застал. Умение откатиться оказалось почти таким же ценным, как сами исправления. Автоматизация полезна, только если она умеет безопасно восстанавливаться после сбоя. В итоге файрвол настроили вручную.
Раунд второй: NAS Synology
Закончив с первым раундом, агента направили на NAS:
Вот NAS Synology по адресу YYYY.YYYY.YYYY.YYYY. Оцени, насколько он защищён.
Этот прогон был больше про проверку, чем про эксплуатацию. Сканирование нашло одиннадцать открытых сервисов, среди них DSM, SMB, NFS, iSCSI, Synology Drive и Active Backup. На машине не было ни nmap, ни openssl, но агент не сдался. Он написал собственные инструменты на Python: тесты TLS-рукопожатия для каждой поддерживаемой версии протокола, пробу входа в iSCSI, согласование SMB через сырые сокеты и несколько проверок под конкретные протоколы, для которых обычно нужны отдельные утилиты.
Что прошло проверку
Несколько настроек уже были правильными:
- TLS предлагал только 1.2 и 1.3 с современными наборами шифров.
- Анонимный вход в iSCSI отклонялся, потому что CHAP был обязательным.
- Подключения по SMB1 сразу обрывались, то есть старый протокол был выключен.
- SNMP игнорировал стандартную community-строку
public. - DSM отдавал ожидаемые HTTP-заголовки безопасности.
Агент проверял каждую настройку напрямую, а не предполагал, что она верна.
Что требовало доработки
Главной проблемой оказался сам DSM. HTTP оставался включённым на порту 5000 без перенаправления на HTTPS, и страница входа прямо выдавала эту настройку:
<input type="hidden" id="prefer_https" name="prefer_https" value="false">
Любой, кто входит по HTTP, отправлял бы учётные данные без шифрования. В доверенной домашней сети это не обязательно катастрофа, но это ненужный риск, и он показывает, как настройки по умолчанию живут ещё долго после развёртывания. Нашлось и по мелочи: NAS всё ещё использовал самоподписанный сертификат вместо Let's Encrypt, у NFS-экспортов не было ограничений файрвола по IP клиента, а Active Backup держал открытым порт 6281, хотя сервисом уже не пользовались.
Что показал эксперимент
Удивительным было не то, что ИИ нашёл дыры в безопасности, а то, какую именно работу он делал хорошо. Kimi K3 не вёл себя как опытный пентестер, а таких за годы встречалось немало. Он вёл себя как дотошный младший инженер по безопасности, которому никогда не надоедает читать логи, тестировать версии протоколов, проверять допущения и перепроверять каждый открытый сервис.
Это ровно та работа, которую люди откладывают, потому что она однообразная. Это совпадает с прежними экспериментами с LLM для автоматизации эксплуатации: они снимают нудную проверочную работу, не теряют интерес на середине чек-листа и не против повторить одну проверку сотни раз. Ещё они оказались аккуратнее, чем ожидалось. Перед отключением сервиса модель проверила зависимости в рабочей среде и тем самым избежала простоя, к которому привёл бы типовой совет по защите.
И всё же контроль человека по-прежнему важен. Файрвол так и не сошёлся к рабочей конфигурации, и если бы агента оставили одного, он, вероятно, бесконечно вносил бы мелкие правки. Чистое состояние вернула именно команда на откат.
Одна оговорка: лаборатория доступна только изнутри через WireGuard, так что аудит охватил частную сеть, а не системы, смотрящие в интернет. Находки всё равно стоили потраченных усилий.