Как защитить локальную LLM от посторонних

MAATRIX

Подняли Ollama на сервере — и то же самое в одну команду проверит любой, кто просканирует порт 11434: ни пароля, ни ключа, ни лимита запросов. У локальной LLM нет встроенной защиты от посторонних — она целиком на вас: адрес, на котором слушает сервис, фаервол перед ним, авторизация на входе и права самого процесса. Разберём каждый слой по порядку — с командами, конфигами и текстом реальной уязвимости, которая это доказывает.

Что видит посторонний: у Ollama нет ни пароля, ни ключей

Ollama спроектирована для доверенной сети: демон поднимает HTTP API и обслуживает любой запрос, не спрашивая, кто спрашивает. Ни заголовка Authorization, ни API-ключа, ни пользователей с правами — этого уровня попросту нет, и это не недоделка, а осознанное решение: авторизацию оставили периметру, то есть вам.

Если порт 11434 доступен снаружи, посторонний может четыре вещи, и все — без единого пароля:

• Посмотреть список моделей — curl -s http://203.0.113.50:11434/api/tags.
• Запустить инференс на вашем железе — curl -s http://203.0.113.50:11434/api/generate -d '{"model":"llama3.1","prompt":"2+2","stream":false}', и ответ придёт как ни в чём не бывало, за ваш счёт по электричеству и времени CPU или GPU.
• Скачать новую модель через /api/pull — за ваш счёт по трафику и месту на диске, вплоть до его заполнения.
• Удалить существующие модели — через /api/delete, если ничего не мешает запросу дойти до диска.

Это не гипотеза. В мае 2024 года исследователи Wiz Research описали CVE-2024-37032 («Probllama») — path traversal через параметр digest в /api/pull, позволявший записывать файлы за пределами каталога моделей и в некоторых конфигурациях доводивший до выполнения кода на сервере. Уязвимость закрыли в версии 0.1.34; всё, что старше и стоит на публичном порту, — не «неудобно», а открытая дверь. Проверить свою версию: ollama -v.

Дело не в том, что Ollama «плохая», — периметр просто не её работа. Дальше — как сделать эту работу самому, слой за слоем.

Как обычно открывают дверь самому: OLLAMA_HOST=0.0.0.0 и Docker -p

Причина открытого порта почти всегда не халатность, а обычная задача: поднять Open WebUI на другом хосте, дать доступ ноутбуку разработчика, подключить мобильного клиента. Первое, что подсказывают документация и форумы, — выставить OLLAMA_HOST=0.0.0.0:11434. На домашнем компьютере за NAT это относительно безобидно. На VPS с публичным IP 0.0.0.0 значит не «моя локальная сеть», а «весь интернет».

С Docker та же ловушка работает незаметнее. Официальный образ запускают командой вида docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama, и запись -p 11434:11434 публикует порт на всех интерфейсах хоста, не только на loopback. Внутри контейнера процесс слушает 0.0.0.0 — это нормально, — но на хосте с белым IP результат идентичен ручному OLLAMA_HOST=0.0.0.0. Проверка та же команда:

ss -tlnp | grep 11434
LISTEN 0 4096 0.0.0.0:11434 0.0.0.0:* users:(("docker-proxy",pid=2217,fd=4))

Обратите внимание на процесс — это docker-proxy, а не ollama. Даже фаервол, настроенный «на процесс ollama», такую публикацию не поймает: формально слушает другой демон. Фикс для контейнера — вернуть биндинг на loopback: -p 127.0.0.1:11434:11434, а наружу отдавать доступ уже через отдельный контейнер с прокси.

Просто закрыть 0.0.0.0 — правильный первый шаг, но если внешний доступ команде действительно нужен, на этом дело не заканчивается: нужна замена авторизации, которой у Ollama нет. Разберём слои по порядку — от сети до процесса.

Слой 1 — сеть: где сервис слушает и кто до него достаёт

Проверка биндинга — первая команда после любой установки:

ss -tlnp | grep 11434
LISTEN 0 4096 127.0.0.1:11434 0.0.0.0:* users:(("ollama",pid=1043,fd=3))

127.0.0.1 в третьей колонке — дефолт для systemd-инсталляции: снаружи до порта в таком виде просто не долететь, фаервол тут ни при чём. Если задача — доступ только с вашей машины, порт можно вообще не открывать: ssh -L 11434:127.0.0.1:11434 user@203.0.113.50 — ноль правок на сервере, но не масштабируется на команду.

Если доступ нужен нескольким людям, рабочих вариантов три:

Фаервол по адресу — sudo ufw allow from 198.51.100.20 to any port 11434 proto tcp, следом sudo ufw deny 11434/tcp, чтобы allow не потерялся среди более широких правил. Работает, пока IP не меняется; для мобильного разработчика это скорее исключение, чем правило.

WireGuard закрывает вопрос надёжнее: сервис вообще не слушает публичный интерфейс, только адрес внутри туннеля. В override для systemd (sudo systemctl edit ollama):

[Service]
Environment="OLLAMA_HOST=10.8.0.1:11434"

После sudo systemctl daemon-reload && sudo systemctl restart ollama ss -tlnp с внешнего хоста, не подключённого к WireGuard, покажет на 11434 не «отказано», а вообще ничего — порта как будто не существует. Заодно снимается и вопрос из CVE выше: недостижимый порт не проэксплуатируешь удалённо.

Минус — конфигурацию клиента приходится ставить на каждое устройство команды, а разовому подрядчику выдавать WireGuard-профиль ради одного вечера избыточно. Для таких случаев — туннель или следующий слой, прокси с паролем.

Слой 2 — раз доступ снаружи нужен: авторизация на прокси

Когда доступ должен быть публичным — например, Open WebUI для распределённой команды без VPN, — перед Ollama ставят Nginx: он берёт на себя то, чего нет у API, — TLS, пароль, ограничение частоты запросов.

Пользователь и пароль:

sudo apt install apache2-utils
sudo htpasswd -c /etc/nginx/.htpasswd admin

Конфиг:

limit_req_zone $binary_remote_addr zone=ollama_api:10m rate=10r/m;

server {
    listen 443 ssl;
    server_name llm.example.com;

    location / {
        auth_basic "Restricted";
        auth_basic_user_file /etc/nginx/.htpasswd;
        limit_req zone=ollama_api burst=5 nodelay;
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host $host;
        proxy_read_timeout 600s;
        proxy_buffering off;
    }
}

proxy_read_timeout 600s не опция для красоты: генерация длинного ответа легко превышает дефолтный таймаут Nginx в 60 секунд, и клиент получит 504 Gateway Timeout посреди на первый взгляд рабочей настройки.

Честная оговорка про Basic Auth: она отлично работает для браузера — тот тут же покажет системное окно логина, и на этом всё. Но большинство OpenAI-совместимых клиентов и SDK шлют не логин с паролем, а заголовок Authorization: Bearer <token> — и программные клиенты об эту нестыковку схем спотыкаются. Если нужен именно API-доступ нескольким приложениям — с ключами sk-..., персональными бюджетами и отзывом по одному, — правильный инструмент перед Ollama не Nginx, а LiteLLM: он умеет то, ради чего эту связку обычно городят, из коробки.

Прокси с паролем сам становится целью перебора, поэтому рядом обязателен fail2ban, слушающий лог ошибок:

[nginx-ollama-auth]
enabled = true
filter = nginx-http-auth
port = 443
logpath = /var/log/nginx/error.log
maxretry = 5
bantime = 3600

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

Слой 3 — сам процесс: пользователь, права на файлы и обновления

Сеть и прокси закрывают вход снаружи, но защита в глубину подразумевает: если однажды в самой Ollama найдут новый баг вроде CVE-2024-37032, ущерб должен упираться в то, что процессу разрешено делать в системе.

Штатная установка уже создаёт отдельного системного пользователя — проверить: id ollama, ответ вида uid=998(ollama) gid=998(ollama) groups=998(ollama) (конкретный номер у вас будет свой) означает, что демон и так не root. Если у вас старая ручная установка и сервис поднят от root — это стоит исправить первым делом.

Права на каталог моделей часто остаются дефолтными и читаемыми остальными пользователями — на общем сервере это утечка весов и дыра для подмены файла:

ls -ld /usr/share/ollama/.ollama/models
chown -R ollama:ollama /usr/share/ollama/.ollama
chmod 700 /usr/share/ollama/.ollama/models

Дальше — песочница systemd. sudo systemctl edit ollama создаёт override без риска потерять правки при следующем обновлении пакета:

[Service]
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
ReadWritePaths=/usr/share/ollama/.ollama

ProtectSystem=strict монтирует всю файловую систему, кроме перечисленных путей, в read-only для этого процесса — то есть даже успешный path traversal упрётся в Read-only file system вместо записи произвольного файла. Ловушка в той же строке: если модели лежат не в /usr/share/ollama/.ollama, а на отдельном диске, ReadWritePaths обязан указывать на реальный путь — иначе сервис стартует нормально, а любая попытка ollama pull будет молча падать с той же ошибкой доступа.

Обновления — последний и самый скучный пункт этого слоя, поэтому его чаще всего пропускают. ollama -v раз в несколько недель занимает пять секунд; софт без авторизации по архитектуре, да ещё на сервере с белым IP, — не тот случай, где патчи можно откладывать на потом.

Как понять, что вас уже нашли, и что делать

Три слоя выше снижают вероятность, но не обнуляют её — стоит знать, как выглядят следы чужого визита.

ollama ps показывает модели, загруженные в память прямо сейчас: если там что-то, что вы не запускали, инференс идёт в эту секунду. du -sh /usr/share/ollama/.ollama/models раз в неделю и сравнение с прошлым значением ловит другой сценарий — рост на несколько гигабайт без вашего ollama pull означает, что модель тянул кто-то посторонний через открытый API.

Для прокси с паролем — счётчик неудачных попыток по адресам:

grep ' 401 ' /var/log/nginx/access.log | awk '{print 
Развернуть за пару минут
Готовый образ на VPS MAATRIX: NVMe, AMD EPYC, root-доступ. Локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.
Развернуть Ollama
Слой 1 — сеть: где сервис слушает и кто до него достаёт
Проверка биндинга — первая команда после любой установки:
ss -tlnp | grep 11434
LISTEN 0 4096 127.0.0.1:11434 0.0.0.0:* users:(("ollama",pid=1043,fd=3))
127.0.0.1 в третьей колонке — дефолт для systemd-инсталляции: снаружи до порта в таком виде просто не долететь, фаервол тут ни при чём. Если задача — доступ только с вашей машины, порт можно вообще не открывать: ssh -L 11434:127.0.0.1:11434 user@203.0.113.50 — ноль правок на сервере, но не масштабируется на команду.
Если доступ нужен нескольким людям, рабочих вариантов три:
Способ
Кому подходит
Что не закрывает
UFW по конкретному IP
Офис со статичным адресом
Смена IP рвёт доступ; внутри диапазона API всё ещё без пароля
WireGuard
Команда, ноутбуки, мобильные клиенты
Нужна настройка клиента на каждом устройстве
SSH-туннель
Разовый доступ одного человека
Не годится для нескольких пользователей
Фаервол по адресу — sudo ufw allow from 198.51.100.20 to any port 11434 proto tcp, следом sudo ufw deny 11434/tcp, чтобы allow не потерялся среди более широких правил. Работает, пока IP не меняется; для мобильного разработчика это скорее исключение, чем правило.
WireGuard закрывает вопрос надёжнее: сервис вообще не слушает публичный интерфейс, только адрес внутри туннеля. В override для systemd (sudo systemctl edit ollama):
[Service]
Environment="OLLAMA_HOST=10.8.0.1:11434"
После sudo systemctl daemon-reload && sudo systemctl restart ollama ss -tlnp с внешнего хоста, не подключённого к WireGuard, покажет на 11434 не «отказано», а вообще ничего — порта как будто не существует. Заодно снимается и вопрос из CVE выше: недостижимый порт не проэксплуатируешь удалённо.
Минус — конфигурацию клиента приходится ставить на каждое устройство команды, а разовому подрядчику выдавать WireGuard-профиль ради одного вечера избыточно. Для таких случаев — туннель или следующий слой, прокси с паролем.
Слой 2 — раз доступ снаружи нужен: авторизация на прокси
Когда доступ должен быть публичным — например, Open WebUI для распределённой команды без VPN, — перед Ollama ставят Nginx: он берёт на себя то, чего нет у API, — TLS, пароль, ограничение частоты запросов.
Пользователь и пароль:
sudo apt install apache2-utils
sudo htpasswd -c /etc/nginx/.htpasswd admin
Конфиг:
limit_req_zone $binary_remote_addr zone=ollama_api:10m rate=10r/m;

server {
    listen 443 ssl;
    server_name llm.example.com;

    location / {
        auth_basic "Restricted";
        auth_basic_user_file /etc/nginx/.htpasswd;
        limit_req zone=ollama_api burst=5 nodelay;
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host $host;
        proxy_read_timeout 600s;
        proxy_buffering off;
    }
}
proxy_read_timeout 600s не опция для красоты: генерация длинного ответа легко превышает дефолтный таймаут Nginx в 60 секунд, и клиент получит 504 Gateway Timeout посреди на первый взгляд рабочей настройки.
Честная оговорка про Basic Auth: она отлично работает для браузера — тот тут же покажет системное окно логина, и на этом всё. Но большинство OpenAI-совместимых клиентов и SDK шлют не логин с паролем, а заголовок Authorization: Bearer <token> — и программные клиенты об эту нестыковку схем спотыкаются. Если нужен именно API-доступ нескольким приложениям — с ключами sk-..., персональными бюджетами и отзывом по одному, — правильный инструмент перед Ollama не Nginx, а LiteLLM: он умеет то, ради чего эту связку обычно городят, из коробки.
Прокси с паролем сам становится целью перебора, поэтому рядом обязателен fail2ban, слушающий лог ошибок:
[nginx-ollama-auth]
enabled = true
filter = nginx-http-auth
port = 443
logpath = /var/log/nginx/error.log
maxretry = 5
bantime = 3600
Пять неудачных попыток — час бана. Не панацея против медленного распределённого перебора, но большинство автосканеров это отсеивает.
Слой 3 — сам процесс: пользователь, права на файлы и обновления
Сеть и прокси закрывают вход снаружи, но защита в глубину подразумевает: если однажды в самой Ollama найдут новый баг вроде CVE-2024-37032, ущерб должен упираться в то, что процессу разрешено делать в системе.
Штатная установка уже создаёт отдельного системного пользователя — проверить: id ollama, ответ вида uid=998(ollama) gid=998(ollama) groups=998(ollama) (конкретный номер у вас будет свой) означает, что демон и так не root. Если у вас старая ручная установка и сервис поднят от root — это стоит исправить первым делом.
Права на каталог моделей часто остаются дефолтными и читаемыми остальными пользователями — на общем сервере это утечка весов и дыра для подмены файла:
ls -ld /usr/share/ollama/.ollama/models
chown -R ollama:ollama /usr/share/ollama/.ollama
chmod 700 /usr/share/ollama/.ollama/models
Дальше — песочница systemd. sudo systemctl edit ollama создаёт override без риска потерять правки при следующем обновлении пакета:
[Service]
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
ReadWritePaths=/usr/share/ollama/.ollama
ProtectSystem=strict монтирует всю файловую систему, кроме перечисленных путей, в read-only для этого процесса — то есть даже успешный path traversal упрётся в Read-only file system вместо записи произвольного файла. Ловушка в той же строке: если модели лежат не в /usr/share/ollama/.ollama, а на отдельном диске, ReadWritePaths обязан указывать на реальный путь — иначе сервис стартует нормально, а любая попытка ollama pull будет молча падать с той же ошибкой доступа.
Обновления — последний и самый скучный пункт этого слоя, поэтому его чаще всего пропускают. ollama -v раз в несколько недель занимает пять секунд; софт без авторизации по архитектуре, да ещё на сервере с белым IP, — не тот случай, где патчи можно откладывать на потом.
Как понять, что вас уже нашли, и что делать
Три слоя выше снижают вероятность, но не обнуляют её — стоит знать, как выглядят следы чужого визита.
ollama ps показывает модели, загруженные в память прямо сейчас: если там что-то, что вы не запускали, инференс идёт в эту секунду. du -sh /usr/share/ollama/.ollama/models раз в неделю и сравнение с прошлым значением ловит другой сценарий — рост на несколько гигабайт без вашего ollama pull означает, что модель тянул кто-то посторонний через открытый API.
Для прокси с паролем — счётчик неудачных попыток по адресам:
grep ' 401 ' /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head
Единицы обращений со случайных IP — фоновый шум интернета, на него не стоит реагировать. Сотни попыток с одного адреса за час — повод для fail2ban-client status nginx-ollama-auth и, если бан не сработал, ручного fail2ban-client set nginx-ollama-auth banip <IP>.
Если признаки уже есть, порядок действий такой:
Сначала остановить утечку, потом разбираться. sudo ufw deny 11434/tcp или отключить внешний интерфейс WireGuard — раньше, чем открывать логи.
Сверить список моделей. ollama list против того, что вы сами когда-либо тянули; лишнее — ollama rm <model>.
Проверить версию и масштаб. Если версия старше 0.1.34 и порт был открыт, проверьте не только Ollama: ~/.ssh/authorized_keys на чужие ключи, crontab -l на незнакомые задания.
Сменить всё, что могло быть подсмотрено, и только потом открыть сеть заново. Пароль на прокси, ключи WireGuard (wg genkey), токены приложений — и лишь затем слои 1–3 с самого начала.
Честно про пределы видимости: Ollama по умолчанию не логирует тела запросов и промпты в виде, пригодном для разбора инцидента, — дословно восстановить, что спрашивал посторонний, скорее всего не получится. Ещё один довод не открывать порт «на всякий случай», а закрывать заранее.
Какой сервер и конфигурацию брать под защищённую локальную LLM
Ollama есть в каталоге apps.maatrix.io: при заказе она разворачивается автоматически на Ubuntu и Debian, доступы появляются в кабинете, команды установки вставлять не нужно. А всё описанное выше — сеть, прокси, песочница — уже ваша задача: сервер отдаётся с полным root-доступом, инструментов в чистом образе достаточно.
Экономия на памяти бьёт не только по скорости, но и по безопасности: если модели и так тесно, для Nginx, fail2ban, WireGuard и логов места не остаётся — а это и есть слой защиты из разделов выше. По нашему замеру на AMD EPYC 9554, модель qwen2.5:7b в квантовании Q4_K_M занимает в памяти около 5,1 ГБ весов, qwen2.5:3b — около 2,2 ГБ. На сервере с 8 ГБ RAM модель 7B съедает основную часть памяти сразу, и запас под фоновые процессы защиты минимален — рабочий вариант для соло-задачи через WireGuard, но без комфортного запаса. Конфигурация от 16 ГБ RAM и 4 vCPU оставляет место и под более крупную модель, и под полный стек — Nginx, fail2ban, WireGuard, а при необходимости и LiteLLM с Postgres для ключей команды, без риска OOM в разгар защитных процессов.
Локация — Великобритания. Если через модель проходят данные пользователей из Европы, лондонский хостинг держит их в периметре UK GDPR и Data Protection Act 2018 — тот же принцип «посторонним недоступно», только на уровне юрисдикции, а не порта. Плюс низкий пинг до команды в ЕС через WireGuard и репутация IP: чистый, недавно выделенный адрес не тащит чужую историю злоупотреблений, которая маскирует в логах целевую атаку под фоновый шум.
Оплата — картой российского банка, по СБП, криптовалютой или токеном MAAT; иностранная карта для сервера в Лондоне не нужна. После заказа: проверить ss -tlnp | grep 11434, убедиться, что порт не смотрит в 0.0.0.0 по недосмотру, и пройти слои 1–3 из этой статьи прежде, чем давать доступ кому-то ещё.
Развернуть за пару минут
Готовый образ на VPS MAATRIX: NVMe, AMD EPYC, root-доступ. Локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.
Развернуть Ollama
}' | sort | uniq -c | sort -rn | head

Единицы обращений со случайных IP — фоновый шум интернета, на него не стоит реагировать. Сотни попыток с одного адреса за час — повод для fail2ban-client status nginx-ollama-auth и, если бан не сработал, ручного fail2ban-client set nginx-ollama-auth banip <IP>.

Если признаки уже есть, порядок действий такой:

• Сначала остановить утечку, потом разбираться. sudo ufw deny 11434/tcp или отключить внешний интерфейс WireGuard — раньше, чем открывать логи.
• Сверить список моделей. ollama list против того, что вы сами когда-либо тянули; лишнее — ollama rm <model>.
• Проверить версию и масштаб. Если версия старше 0.1.34 и порт был открыт, проверьте не только Ollama: ~/.ssh/authorized_keys на чужие ключи, crontab -l на незнакомые задания.
• Сменить всё, что могло быть подсмотрено, и только потом открыть сеть заново. Пароль на прокси, ключи WireGuard (wg genkey), токены приложений — и лишь затем слои 1–3 с самого начала.

Честно про пределы видимости: Ollama по умолчанию не логирует тела запросов и промпты в виде, пригодном для разбора инцидента, — дословно восстановить, что спрашивал посторонний, скорее всего не получится. Ещё один довод не открывать порт «на всякий случай», а закрывать заранее.

Какой сервер и конфигурацию брать под защищённую локальную LLM

Ollama есть в каталоге apps.maatrix.io: при заказе она разворачивается автоматически на Ubuntu и Debian, доступы появляются в кабинете, команды установки вставлять не нужно. А всё описанное выше — сеть, прокси, песочница — уже ваша задача: сервер отдаётся с полным root-доступом, инструментов в чистом образе достаточно.

Экономия на памяти бьёт не только по скорости, но и по безопасности: если модели и так тесно, для Nginx, fail2ban, WireGuard и логов места не остаётся — а это и есть слой защиты из разделов выше. По нашему замеру на AMD EPYC 9554, модель qwen2.5:7b в квантовании Q4_K_M занимает в памяти около 5,1 ГБ весов, qwen2.5:3b — около 2,2 ГБ. На сервере с 8 ГБ RAM модель 7B съедает основную часть памяти сразу, и запас под фоновые процессы защиты минимален — рабочий вариант для соло-задачи через WireGuard, но без комфортного запаса. Конфигурация от 16 ГБ RAM и 4 vCPU оставляет место и под более крупную модель, и под полный стек — Nginx, fail2ban, WireGuard, а при необходимости и LiteLLM с Postgres для ключей команды, без риска OOM в разгар защитных процессов.

Локация — Великобритания. Если через модель проходят данные пользователей из Европы, лондонский хостинг держит их в периметре UK GDPR и Data Protection Act 2018 — тот же принцип «посторонним недоступно», только на уровне юрисдикции, а не порта. Плюс низкий пинг до команды в ЕС через WireGuard и репутация IP: чистый, недавно выделенный адрес не тащит чужую историю злоупотреблений, которая маскирует в логах целевую атаку под фоновый шум.

Оплата — картой российского банка, по СБП, криптовалютой или токеном MAAT; иностранная карта для сервера в Лондоне не нужна. После заказа: проверить ss -tlnp | grep 11434, убедиться, что порт не смотрит в 0.0.0.0 по недосмотру, и пройти слои 1–3 из этой статьи прежде, чем давать доступ кому-то ещё.

Частые вопросы