Про агентов. 2 Часть.

Это уже вторая часть опусов про агентов, и я могу сказать, что в первой части половину можно не читать. Вот ссылка. В нашем быстро изменяющемся мире почти любое из утверждений устаревает за месяц, два, а в мире ИИ это происходит еще быстрее. Поэтому если Вы решили изучить мои труды последовательно, то прошу отнестись с пониманием к разночтениям, которые возникают между первой частью и второй. Особенно когда это касается сравниваемых framework. Прошло почти полгода, вышли новые версии, инструменты стали совсем другие. И мое понимание инструментов сильно изменилось, теперь, когда я использую оба одновременно, кажется, что я могу рассказать о них больше.

Как я и обещал в анонсе, который, к сожалению, был уже достаточно давно, в этой статье я расскажу о нескольких темах в организации агентов. Мы поговорим о безопасности, как я ее организовал, памяти, о моем опыте использования моделей, поговорим об организации полностью локального агента, которому можно доверить свои данные и межагенском взаимодействии. Будет и создание своего хранилища документов, и выбор инструментов для этого. Поговорим об организации постоянной памяти агентов. Я еще раз сделаю сравнение Hermes и Openclaw, но теперь расскажу о своих ощущениях от использования каждого. Расскажу, как использую их вместе. И, как обещал, будет раздел о реализованных «pet» проектах, моих поделках, сделанных с помощью агентов.

Безопасность

Если Вы не читали первую часть, я напомню, что мой агент на тот момент жил в OpenClaw, расположенном на VPS (Virtual Private Server) Beget. Это облачный провайдер, ЦОД которого расположен в Петербурге. Для нас это важно и далее Вы поймете почему.

С момента написания первой части не прошло и 2-х недель как мою машину сломали. Обычные роботы, которые подобрали пароль через SSH 22 порт. На мою машину был установлен маленький майнер, который полночи держал загрузку моего виртуального процессора 200%. Заметил я достаточно быстро, мне не понравилось поведение графиков загрузки процессора, и я спросил об этом агента. Он тоже недолго копался, быстро вычислил виновника и начал кричать, что нас взломали и все пропало. Это был банальный майнер, который поставил себя, поменял секреты у root пользователя, добавил своего, чтобы с уверенностью продолжать свою работу, и бодро начал грузить процессор на полную. Мне, если честно, повезло, что это робот. Могли бы сломать спрятаться и не «следить» и я бы их не заметил. Что интересно, забавен факт обхода моих усилий по защите VPS. Я еще в самом начале убрал авторизацию по паролю у пользователя root, сгенерировал SSH ключ для него. Но я совершенно не подумал о пользователе Openclaw, который был создан из шаблона Beget для работы этого framework. Именно его робот и выбрал для атаки.

Я вычистил все, поменял секреты, а потом на всякий случай восстановился из предыдущего снимка и занялся безопасностью всерьез. Как я уже писал в первой части, жизнь научила меня делать снапшоты и это как раз тот случай, когда они мне пригодились. Ниже будут правила, которые я выработал, а пока просто описание действий. Я подумал, что больше не хочу торчать наружу совсем. Сначала сделал L2TP/IPSEC сервер и стал подключаться к нему для администрирования. Полностью закрыл все подключения снаружи, оставил только 443 со своими сервисами. На нем поднял авторизацию для всех, без исключения страниц. Сначала это был Basic, но его упорно не хочет определять и сохранять browser, поэтому я выбрал authelia с хранением cookie. Пришла идея соединить все домашние роутеры с VPS, построил внутреннюю сеть с мониторингом состояния узлов сети и точек Wifi. Даже сделал дашборд визуализации состояния. На эту идею меня натолкнул наш центр мониторинга Ю-Питер. Даже оформление немного позаимствовал. Приводить скриншоты в статье не буду по соображениям безопасности.

L2TP/IPSEC соединения с ноута надо дополнительно поднимать и, чтобы было удобнее я настроил Tailscale на всех VPS и компьютерах. Это достаточно простое, но надежное решение для администрирования. Соединение поднимается автоматом, есть визуализация, удобный инструмент настройки правил. Для рабочего траффика я его не использую, так как с L2TP/IPSEC удобнее настраивать правила интерфейсов, когда требуется фильтрация по типу траффика. Именно в нем я разрешил порт SSH для администрирования. Поменял его значение, отключил вход root по SSH, сделал отдельного админа и всех перевел с пароля на SSH ключ. В том числе пользователя для OpenClaw. Это сделать не трудно, но надо делать аккуратно, делая снапшоты после каждого успешного шага. Openclaw такой – он все время норовит себя сломать, особенно работая на модели deepseek. Кстати, забегая вперед скажу: похоже эту милую особенность заметили и создатели, так как теперь есть режим «под контролем».

Не бойтесь закрывать порт управления снаружи. На крайний случай у вас всегда есть терминальный доступ с консоли управления сервером (обязательно проверьте, что он действительно есть), или предыдущий снапшот сервера, когда он еще работал.

На открытые порты обязательно установите все необходимые инструменты безопасности, о них я скажу в перечне. Сейчас у меня в логах атаки продолжаются. Они немногочисленны и стандартны, но защита все равно нужна. А далее продумайте систему связи, когда вы для VPS будете находиться в доверенной сети, и она автоматически поднимается при доступе вашего устройства в интернет. Я уже писал, что для меня это Tailscale, но однозначно его рекомендовать я все же не могу. Его админка недоступна из мобильной сети никогда, а траффик из страны часто режется даже на wifi. Поэтому, возможно, лучше реализовать классические L2TP/IPsec соединения, но настроить автоматическое подключение или поддержку канала «On demand». (подумываю перейти на них после последних ограничений).

Итак, это только мои рекомендации, на вкус и цвет, как известно «все фломастеры разные», поэтому исполнять все или выборочно – выбирать вам:

1. Закрываем 22 порт для всего и насовсем. Кроме разве 127.0.0.1, чтобы терминальная сессия с админки осталась работать. Пока все не настроено, перенесите SSH на 2222. Его атакуют значительно реже.
2. Для администраторов сгенерируйте SSH ключ, переведите на него, всех админов. Очень желательно на разные ключи. Не храните приватный ключ в сети, только на локальной машине, лучше в нескольких местах. Установить на него пароль.
3. Создайте независимого администратора с отдельным ключом и не пользуйтесь им для повседневного доступа. Пригодится при восстановлении. Если умеете администрировать, можно использовать и его, главное, чтобы он отличался от пользователя, которого использует агент. И в завершении самое интересное: если используете несколько Framework, заведите пользователя для каждого. Не только чтобы понимать кто напортачил, но, и чтобы они сами понимали, кто что сделал и зачем.
4. Запретите использовать секреты в скриптах и конфигурационных файлах. Храните отдельно в ENV или в специально организованных хранилищах. Текущие версии агентов уже предлагают такие хранилища
5. Для всех открытых портов ставим базовые службы защиты:
   1. Fail2ban – 3 неправильных попытки авторизации и IP в бан
   2. Iptables – только разрешенные сети имеют доступ. Очень важно не упустить этот пункт, так как с течением времени появляются новые сервисы и надо отслеживать, чтобы только нужные были доступны из мира. Разведите фильтрацию входящих портов и исходящих подключений агента. Особенно важны исходящие запросы, утечка секретов и доступ к внутренней сети. Название инструмента не принципиально: может быть nftables, ufw или другие firewall.
   3. Авторизация на nginx. Это сервер веб страниц, наверняка они начнут у Вас появляться сразу, необходимо предусмотреть, чтобы они были защищены, и все открытые страницы либо отдавали 404 (страница недоступна), либо перенаправлялись на страницу авторизации. Используйте политику deny-by-default. У меня стоит Autheliа, умеет работать с cookie, не требует постоянной переавторизации.
6. Создайте надежное соединение для администрирования и уберите из доступа извне порты 2222 и любые другие, кроме 443. И его убирайте, если нет опубликованных веб сервисов.
7. Используйте резервные каналы для доступа к VPS или к домашней рабочей станции. Например, я для взаимодействия служб между использую основной L2TP/IPSEC, его легче прописать в конфигах, а для подключения для администрирования и работы использую Tailscale. При этом его практически не использую для маршрутизации, из-за сложной настройки и, как оказалось, из-за блокировок. Кстати, во время блокировок L2TP/IPSEC оказался как нельзя кстати. Его пока не блокируют. Причем я не призываю использовать только L2TP/IPSEC, подойдёт и другой защищённый туннель — например, WireGuard или AmneziaWG. Для резервного канала лучше выбирать решение с иной реализацией, а не считать WireGuard и AmneziaWG полностью независимыми вариантами.
8. Включите audit и храните 5–7 дней лога. Так агенту будет легче “обучиться” тому, что именно на вашей инфраструктуре делать не надо.
9. Для самых мнительных можно включить механизм «sudoers» для агентских учетных записей и прописать, какие команды разрешены без вашего approve, а какие требуют вашего обязательного подтверждения. Это скорее последний эшелон защиты уже при взломе, так как в агентах внутри уже встроен такой механизм, о нем расскажу при описании интерфейсов.

Ещё один важное наблюдение: безопасность агента не заканчивается на защите SSH. Агент читает страницы, документы и сообщения, где могут оказаться инструкции, написанные как «промт-инъекции». Он может ошибиться сам или слишком буквально выполнить чужой текст. Поэтому для разных агентов нужны разные учётные записи и права, а опасные действия лучше ограничивать не только кнопкой подтверждения в интерфейсе агента, но и правами самой операционной системы. Если у агента нет доступа к чужим секретам или права переписать сетевые настройки, одной ошибкой он причинит меньше вреда.

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

Хотел Вам напомнить, что Вам по-прежнему (как иногда и мне) совсем необязательно до конца понимать, о чем я пишу. Вы просто можете отгрузить всю статью своему агенту, а потом попросить сделать Вам рекомендацию, какие инструменты Вам надо подключить. И потом попросить его подключить их. Пусть агент предложит изменения с объяснением риска, резервной копией и планом отката; применение сетевых правил и SSH — только после проверки Вами, иначе можно потерять доступ. Ну и делайте снапшоты перед ключевыми изменениями.

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

Это черновик статьи. Будет пополняться прямо здесь. Следующий раздел будет про память агента