Kimi K3 перевіряє домашню лабораторію: знахідки в Proxmox, провал із файрволом і NAS

Як був влаштований тест

З'явилися повідомлення, що 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, тож аудит охопив приватну мережу, а не системи, що дивляться в інтернет. Знахідки все одно були варті зусиль.