SSD Nodes Learn 🎉 VPS $5.50/월부터
가이드 Matt Connor작성자 Matt Connor

Ollama API 보안 설정 및 인증 문제 해결 방법

Ollama는 기본적으로 11434 포트에 인증 기능이 없어 외부 노출 시 서버 자원이 무단 도용될 위험이 있습니다. 리버스 프록시 설정, 방화벽 구성, 환경 변수 제어를 통해 Ollama API를 안전하게 보호하는 3가지 실질적인 해결책을 확인하십시오.

Ollama API에는 비밀번호가 없습니다

Ollama API에는 인증 기능이 없습니다. 서버를 실행할 때 사용자, 비밀번호, 키 검증, 허용 목록(allowlist) 같은 보안 장치가 전혀 없습니다. TCP 연결을 통해 11434 포트에 접근할 수 있는 모든 대상은 모델 목록을 조회하고, 실행하고, 새로운 모델을 다운로드하거나 기존 모델을 삭제할 수 있습니다.

공식 문서에는 "Ollama API에 로컬로 접근할 때는 인증이 필요하지 않습니다(No authentication is required when accessing Ollama's API locally via http://localhost:11434)."라고 명시되어 있습니다. 여기서 로컬(locally)이라는 단어가 전체 보안 모델을 의미합니다. Ollama는 기본적으로 127.0.0.1에 바인딩되므로, 노트북 환경에서는 루프백 인터페이스가 접근 제어 역할을 합니다. 하지만 이 리스너를 공인 IP 주소로 옮기면 대체할 보안 수단이 없기 때문에 접근 제어 기능이 완전히 사라집니다.

이것이 VPS(가상 사설 서버)에서 이 문제가 중요한 이유입니다. 기본 설정은 안전합니다. 하지만 많은 사용자가 다른 기기에서 모델을 사용하기 위해 리스너를 개방하는 순간, 모든 보호 기능이 한꺼번에 제거됩니다.

포트 11434를 개방했을 때 노출되는 정보

모든 엔드포인트가 노출됩니다. 읽기 전용 모드나 별도의 관리자 포트가 존재하지 않습니다. 다음은 localhost 대신 서버 주소를 대상으로 직접 전송되는 실제 요청들입니다.

# List every model on the box
curl http://SERVER_IP:11434/api/tags

# See what is loaded into memory right now
curl http://SERVER_IP:11434/api/ps

# Run a prompt on your hardware
curl http://SERVER_IP:11434/api/generate -d '{"model":"llama3.2","prompt":"Why is the sky blue?"}'

# Write several gigabytes to your disk
curl http://SERVER_IP:11434/api/pull -d '{"model":"llama3.2"}'

# Remove a model
curl -X DELETE http://SERVER_IP:11434/api/delete -d '{"model":"llama3.2"}'

운영자 관점에서 다음과 같은 네 가지 문제가 발생합니다.

  • 타인이 귀하의 CPU나 GPU를 사용하여 추론을 수행합니다. 공정 사용(fair-use) CPU 할당량이 정해진 요금제를 사용 중이라면, 지속적인 부하로 인해 낯선 사람이 귀하의 할당량을 소진하게 되며, VPS에서 AI 작업 비용을 제어하는 방법을 적용하는 것이 귀하가 유일한 사용자일 때보다 훨씬 어려워집니다.
  • /api/pull가 귀하의 디스크에 데이터를 기록합니다. 모델은 각각 2GB에서 40GB에 달합니다. 모델을 반복적으로 pull하면 볼륨이 가득 차게 되며, 디스크가 꽉 차면 Ollama뿐만 아니라 해당 서버의 다른 모든 서비스가 중단됩니다.
  • 요청이 프로세스 내부로 유입되어 기록됩니다. 기본 로그 수준에서 Ollama는 메타데이터만 기록하므로, 프롬프트 텍스트가 아닌 엔드포인트, 상태, 지연 시간, 클라이언트 주소가 저장됩니다. 이는 귀하가 수집을 의도하지 않았더라도 누가 귀하의 서버를 어떤 목적으로 사용했는지에 대한 기록이 저널에 남게 됨을 의미합니다.
  • /api/delete이 모델을 삭제합니다. 삭제된 모델을 복구하려면 귀하의 대역폭을 사용하여 다시 다운로드해야 합니다.

이러한 문제들은 익스플로잇이 필요하지 않습니다. 문서화된 API가 설계된 대로 정확하게 동작하는 결과일 뿐입니다.

Ed25519 키는 접근 제어 수단이 아닙니다

"Ollama API key"를 검색하면 서로 다른 두 가지 결과가 나옵니다. 둘 다 서버의 비밀번호가 아니며, 이 둘을 구분하면 대부분의 혼란이 해소됩니다.

첫 번째는 식별용 키 쌍입니다. Ollama는 처음 실행될 때 Ed25519 키 쌍을 생성합니다. Linux에서 설치 스크립트는 ollama이라는 시스템 사용자를 생성하고 홈 디렉터리를 /usr/share/ollama로 지정하므로, 키 쌍은 다음 위치에 저장됩니다.

/usr/share/ollama/.ollama/id_ed25519
/usr/share/ollama/.ollama/id_ed25519.pub

이 키는 외부를 향합니다. ollama signin은 공개 키를 ollama.com 계정에 등록하며, 이를 통해 모델을 레지스트리에 푸시하거나 비공개 모델을 풀(pull)할 수 있는 권한을 얻습니다. 즉, 이 키는 ollama.com에 귀하의 머신을 인증하는 용도입니다. 귀하의 머신에 연결하는 클라이언트에게는 아무것도 요구하지 않습니다. 이 키를 삭제하거나, 교체하거나, 아예 생성하지 않더라도 API 호출 권한에는 아무런 변화가 없습니다.

두 번째는 OLLAMA_API_KEY입니다. 이 변수는 https://ollama.com/settings/keys에서 생성한 키를 담고 있으며, 클라이언트는 https://ollama.com/api의 호스팅된 API를 호출할 때 이를 Authorization: Bearer $OLLAMA_API_KEY 헤더로 전송합니다. 이는 해당 서비스의 자격 증명이며, 귀하가 클라이언트로서 사용하는 것입니다. 귀하의 ollama serve은 이 키를 읽지 않습니다. VPS에 OLLAMA_API_KEY를 설정한다고 해서 VPS에 비밀번호가 걸리는 것은 아닙니다.

따라서 활성화할 별도의 설정은 없습니다. 아래에 제시된 세 가지 방어 수단은 모두 동일한 방식으로 작동합니다. 포트에 접근할 수 없도록 차단하고, 접근 제어를 수행하는 도구를 앞단에 배치하십시오.

현재 서버가 수신 대기 중인 항목 확인

sudo ss -tlnp | grep 11434

안전한 결과는 루프백 주소를 나타냅니다:

LISTEN 0  4096  127.0.0.1:11434  0.0.0.0:*  users:(("ollama",pid=812,fd=3))

노출된 결과는 모든 인터페이스를 나타냅니다:

LISTEN 0  4096  0.0.0.0:11434  0.0.0.0:*  users:(("ollama",pid=812,fd=3))

0.0.0.0은(는) 공인 IP를 포함하여 서버의 모든 IPv4 주소를 의미합니다. *:11434 및 [::]:11434는(은) IPv6를 포함하여 동일한 의미를 갖습니다.

이제 외부에서 확인합니다. 서버가 아닌 노트북에서 다음 명령을 실행하십시오:

curl -m 5 http://YOUR_SERVER_IP:11434/api/version

curl: (28) Connection timed out after 5001 milliseconds은(는) 원하는 응답이며, curl: (7) Failed to connect ... Connection refused도 마찬가지입니다. version 필드를 포함하는 JSON 객체는 전체 API가 요청하는 누구에게나 도달 가능함을 의미합니다. 서버 자체에서 curl로 테스트하는 것은 루프백이 항상 응답하므로 아무것도 증명하지 못합니다.

노출은 보통 두 가지 방식으로 발생합니다. 첫 번째는 다른 기기에서 모델에 접근해야 할 필요가 있어 의도적으로 편집하는 경우입니다:

sudo systemctl edit ollama.service
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

그 한 줄이 노출의 전부입니다. 두 번째 방식은 Docker이며, 이는 아무것도 편집할 필요가 없습니다. 이에 대해서는 아래 별도 섹션에서 다룹니다.

방어 1: localhost로 제한하고 터널링 사용

이 방법을 가장 먼저 고려하십시오. 추가 소프트웨어가 필요 없으며 유출될 수 있는 자격 증명을 생성하지 않습니다. 포트가 공용 인터페이스에 존재하지 않으므로 스캔으로 발견할 수 없습니다.

기본값에 의존하지 말고 바인드 주소를 명시적으로 설정하십시오.

sudo systemctl edit ollama.service
[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"

이 명령은 /etc/systemd/system/ollama.service.d/override.conf을 작성합니다. 적용 후 확인하십시오.

sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo ss -tlnp | grep 11434

ss은 이제 127.0.0.1:11434을 표시해야 합니다. 여전히 0.0.0.0가 표시된다면, 다른 드롭인 파일이 우선 적용되고 있는 것입니다. systemctl cat ollama.service을 실행하여 유닛과 모든 드롭인 파일의 경로를 나열한 뒤, 오래된 파일을 삭제하십시오.

노트북에서 모델을 사용하려면 SSH를 통해 포트를 포워딩하십시오.

ssh -N -L 11434:127.0.0.1:11434 you@your-server

-L 11434:127.0.0.1:11434은 노트북의 11434 포트를 열고, 해당 포트로 들어오는 모든 요청을 서버에서 바라보는 127.0.0.1:11434로 전달합니다. -N은 SSH가 원격 명령을 실행하지 않도록 하여 프로세스가 터널을 유지하게 합니다. 이 명령이 실행되는 동안 노트북에서 다음을 사용할 수 있습니다.

curl -s http://localhost:11434/api/tags

두 가지 실패 사례를 겪을 수 있습니다. bind [127.0.0.1]:11434: Address already in use는 노트북에서 이미 자체 Ollama를 해당 포트로 실행 중임을 의미하므로, -L 11500:127.0.0.1:11434를 사용하여 다른 로컬 포트를 선택하고 클라이언트가 11500을 가리키도록 하십시오. 터널은 정상적으로 연결되었으나 빈 응답이 돌아온다면 SSH는 작동 중이지만 서버 측에서 Ollama가 수신 대기 중이 아닌 상태입니다. SSH 명령을 수정하기 전에 서버에서 ss을 확인하십시오.

여러 클라이언트 머신을 사용하는 경우, 사용자당 하나의 터널을 만드는 것보다 사설 네트워크가 더 효율적입니다. 머신들을 WireGuard나 Tailscale에 연결한 뒤, Ollama를 0.0.0.0이 아닌 해당 네트워크의 주소에 바인딩하십시오.

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

그러면 포트는 키가 있어야만 접근할 수 있는 인터페이스에만 존재하게 됩니다. 이는 방화벽 설정 실수로부터도 안전합니다. 실수로 전체 공개를 허용하는 규칙이 적용되더라도, 공용 인터페이스가 아닌 곳에서 수신 대기 중인 서비스는 외부로 노출되지 않기 때문입니다.

방어 2: 베어러 토큰을 검증하는 리버스 프록시

공용 인터넷에서 모델을 호출해야 하는 경우, Ollama를 loopback 인터페이스에 유지하고 그 앞에 프록시를 배치합니다. 프록시는 TLS(transport layer security)를 종료하고 올바른 헤더가 없는 요청을 거부합니다. Ollama는 여전히 127.0.0.1에서만 연결을 허용하므로, 프록시가 유일한 진입 경로가 됩니다.

먼저 실제 토큰을 생성합니다. 직접 임의로 만들지 마십시오.

openssl rand -base64 36

이를 검증하는 nginx 사이트 설정입니다.

map $http_authorization $ollama_ok {
    default                                   0;
    "Bearer PASTE_YOUR_GENERATED_TOKEN_HERE"  1;
}

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

    ssl_certificate     /etc/letsencrypt/live/llm.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/llm.example.com/privkey.pem;

    location = /api/pull   { return 403; }
    location = /api/delete { return 403; }
    location = /api/push   { return 403; }

    location / {
        if ($ollama_ok = 0) { return 401; }

        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host 127.0.0.1:11434;
        proxy_buffering off;
        proxy_read_timeout 600s;
    }
}

위 설정 중 5개 행이 실제 작업을 수행하며, 각 행은 발생할 수 있는 장애를 방지합니다.

location 블록 내부의 if는 nginx에서 일반적으로 권장되지 않지만, return 크기의 본문은 예측 가능한 방식으로 동작하는 두 가지 형태 중 하나이므로 이 사용법은 안전합니다.

location = /api/pull는 정확히 일치하는 경로이며, nginx는 location / 접두사보다 정확히 일치하는 경로를 우선순위에 두므로 해당 세 개의 엔드포인트는 토큰 검증 이전에 거부됩니다. 유효한 토큰은 추론 권한을 부여할 뿐, 디스크를 채울 수 있는 권한을 부여하지는 않습니다.

Ollama는 들어오는 Host 및 Origin 헤더를 검사하므로 proxy_set_header Host 127.0.0.1:11434; 설정이 중요합니다. 프록시의 공용 호스트 이름을 그대로 전달하면 nginx가 아닌 Ollama에서 생성된 403 Forbidden이 발생할 수 있으며, 이는 디버깅을 어렵게 만듭니다. OLLAMA_ORIGINS은 특정 origin을 허용해야 하는 브라우저 클라이언트를 위한 또 다른 설정입니다.

Ollama는 응답을 토큰 단위로 스트리밍하므로 proxy_buffering off; 설정이 중요합니다. 버퍼링이 켜져 있으면 nginx가 스트림을 붙잡고 있다가 마지막에 한꺼번에 전달하므로, 생성되는 동안 클라이언트는 멈춘 것처럼 보입니다.

nginx의 기본값은 60초이므로 proxy_read_timeout 600s; 설정이 중요합니다. CPU에서 긴 생성이 이루어지면 이 시간을 쉽게 초과하여 클라이언트는 504 Gateway Time-out을 받게 되고, /var/log/nginx/error.log는 upstream timed out (110: Connection timed out) while reading response header from upstream을 기록합니다. 요청은 여전히 처리 중이었으나 nginx가 포기한 것입니다.

설정을 다시 불러오고 두 경로를 모두 테스트합니다.

sudo nginx -t && sudo systemctl reload nginx
curl -s -o /dev/null -w '%{http_code}\n' https://llm.example.com/api/tags
curl -s -H "Authorization: Bearer YOUR_TOKEN" https://llm.example.com/api/tags

첫 번째 명령은 401를 출력해야 합니다. 두 번째 명령은 모델 목록을 출력해야 합니다. 만약 첫 번째 명령에서도 모델 목록이 반환된다면 map 블록의 범위가 잘못된 것입니다. 이 블록은 http 수준에 위치해야 하므로, /etc/nginx/conf.d/ 아래의 파일에 작성하거나 server 블록 위에 배치하십시오. 절대 server 내부에는 두지 마십시오.

Caddy는 4줄의 설정으로 기본 인증을 통해 동일한 작업을 수행하며, 이는 베어러 토큰보다 브라우저 클라이언트에 더 적합합니다.

llm.example.com {
	basic_auth {
		apiuser PASTE_BCRYPT_HASH_HERE
	}
	reverse_proxy 127.0.0.1:11434
}

caddy hash-password을 실행하여 필요한 bcrypt 해시를 생성합니다. 주의할 점은 Caddy v2.8 이전에는 지시어가 basicauth이었으나 현재는 basic_auth라는 점입니다. 따라서 이전 가이드에서 복사한 설정은 로드되지 않으며, Caddy는 인식하지 못한 지시어 이름을 알려줍니다.

어떤 프록시를 선택하든, 이는 모든 사용자가 공유하는 하나의 비밀값입니다. 이 값을 가진 모든 클라이언트는 동일한 접근 권한을 가지며, 이를 취소하려면 설정을 수정하고 모든 호출자를 동시에 업데이트해야 합니다.

방어 3: 클라이언트별 키를 발급하는 게이트웨이

둘 이상의 사용자나 애플리케이션이 모델을 호출하면 공유 토큰은 한계에 도달합니다. 어떤 클라이언트가 부하를 유발했는지 파악할 수 없으며, 특정 클라이언트만 차단할 방법도 없습니다. 프록시가 있던 위치에 게이트웨이를 배치하면 동일한 OpenAI 호환 API를 사용하면서 클라이언트별로 별도의 키를 발급하고 각 키의 사용량을 기록할 수 있습니다. 자체 호스팅 LiteLLM 게이트웨이가 일반적인 해결책이며, 이는 접근 제어 외에도 키별 예산 설정과 요청 로그 기능을 추가합니다.

방어 1의 규칙은 변하지 않습니다. Ollama는 127.0.0.1에 바인딩되어야 하며, 게이트웨이만이 Ollama와 통신하고, 게이트웨이만이 외부 공개 리스너를 갖는 유일한 서비스여야 합니다. 포트 11434가 여전히 외부로 열려 있는 서버에 게이트웨이를 두는 것은 무의미합니다. 호출자가 게이트웨이를 우회하여 직접 접근할 수 있기 때문입니다.

방화벽의 함정: 게시된 컨테이너 포트는 UFW를 우회합니다

방화벽을 올바르게 설정했다고 생각하는 서버에서 외부로 노출된 인스턴스가 발견되는 이유가 바로 이것입니다.

UFW(uncomplicated firewall)는 규칙을 커널의 filter 테이블에 있는 INPUT 체인에 작성하며, INPUT은 호스트 자체로 향하는 패킷을 처리합니다. Docker의 -p 플래그는 목적지 NAT(network address translation) 규칙을 nat 테이블의 PREROUTING 체인에 작성하는데, 커널은 패킷의 목적지를 결정하기 전에 이 규칙을 먼저 평가합니다. 라우팅 결정이 내려질 시점에는 이미 목적지가 컨테이너 주소로 재작성된 상태이므로, 패킷은 로컬로 전달되지 않고 포워딩되며 INPUT 대신 FORWARD을 통과하게 됩니다. UFW의 INPUT 규칙은 전혀 참조되지 않으므로, 패킷은 방화벽을 통과하는 대신 우회하게 됩니다.

이러한 이유로 다음 순서를 실행하면 포트 11434가 인터넷에 그대로 노출됩니다:

sudo ufw default deny incoming
sudo ufw enable
docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

그리고 sudo ufw status은 여전히 방화벽이 활성화되어 있고 기본 정책이 거부(deny)라고 보고합니다. 두 정보 모두 사실이지만, 바로 이 때문에 사용자가 잘못된 정보를 신뢰하게 됩니다. 이 문제를 일으킨 규칙은 다음 명령어로 확인할 수 있습니다:

sudo iptables -t nat -L DOCKER -n

해결 방법은 게시 플래그에 주소를 하나 추가하는 것입니다:

docker rm -f ollama
docker run -d -v ollama:/root/.ollama -p 127.0.0.1:11434:11434 --name ollama ollama/ollama

-p 11434:11434는 -p 0.0.0.0:11434:11434의 약어입니다. 127.0.0.1을 지정하면 매핑의 호스트 측이 루프백 인터페이스에 바인딩되므로, SSH 터널이나 리버스 프록시는 여전히 서비스에 접근할 수 있지만 인터넷에서는 접근할 수 없게 됩니다. 모델은 컨테이너 내부가 아닌 명명된 ollama 볼륨에 저장되므로, 컨테이너를 다시 생성해도 안전합니다.

두 관점의 설정이 일치하는지 확인하십시오:

docker port ollama
sudo ss -tlnp | grep 11434

docker port ollama은 11434/tcp -> 127.0.0.1:11434를 출력해야 합니다. 만약 0.0.0.0:11434이 출력된다면 여전히 노출된 상태입니다. 이 메커니즘을 한 번 익혀두면 게시하는 모든 컨테이너에 동일하게 적용할 수 있습니다. Docker가 게시한 포트가 UFW를 우회하는 이유에서는 DOCKER-USER 체인과 Docker 재시작 후에도 유지되는 규칙을 다룹니다. 호스트 정책 자체를 구축하는 중이라면 새 VPS에 필요한 UFW 규칙에서 이 작업의 기반이 되는 내용을 확인할 수 있습니다.

프로세스가 어떤 계정으로 실행 중인가

Linux 설치 스크립트는 전용 계정을 생성하고 해당 계정으로 서비스를 실행합니다.

useradd -r -s /bin/false -U -m -d /usr/share/ollama ollama

/etc/systemd/system/ollama.service에 위치한 유닛 파일은 User=ollama 및 Group=ollama를 설정합니다. 이 설정은 그대로 두어야 합니다. 터미널에서 수동으로 시작한 ollama serve는 현재 로그인한 사용자의 권한으로 실행되며, 만약 root 계정으로 로그인했다면 인증되지 않은 API가 root 권한으로 파일을 작성하게 됩니다. 다음 명령어로 실행 계정을 확인하십시오.

ps -o user= -C ollama

결과는 ollama이어야 합니다. 다른 결과가 나온다면 수동으로 시작한 프로세스가 유닛 서비스와 함께 실행 중이거나 유닛 서비스를 대신하여 실행 중임을 의미합니다. 이후 추가하는 모든 데몬에도 동일한 원칙이 적용되며, 최소 권한 사용자로 서비스 실행하기에서 이를 올바르게 처리하는 방법을 다룹니다.

Ollama API 엔드포인트의 보안 상태 확인 방법

어떤 방식을 선택했든, 다른 머신에서 실행해야 하는 다음 테스트 한 번이면 보안 상태를 확실히 알 수 있습니다.

curl -m 5 http://YOUR_SERVER_IP:11434/api/version
curl -m 5 http://YOUR_SERVER_IP:11434/api/tags

두 명령 모두 타임아웃이 발생하거나 연결이 거부되어야 합니다. 프록시를 구축했다면, 프록시 호스트 이름의 동일한 두 경로에 대해 자격 증명 없이 요청 시 401이 반환되고, 자격 증명을 포함하면 실제 JSON이 반환되어야 합니다.

그다음 접근 로그를 한 번 확인하십시오. 포트가 열려 있던 동안 누군가 접근을 시도했는지 알 수 있습니다.

journalctl -u ollama --since "-30 days" | grep GIN | grep -v 127.0.0.1

Ollama는 요청당 한 줄씩 로그를 기록하며 클라이언트 주소를 포함합니다.

[GIN] 2026/08/12 - 14:01:10 | 200 | 103.965898ms | 127.0.0.1 | POST "/api/generate"

Ollama가 루프백(loopback) 주소에 바인딩된 상태라면 모든 줄에 127.0.0.1이 표시되어야 합니다. 연결이 들어올 수 있는 유일한 주소이기 때문입니다. 해당 열에 공인 IP 주소가 있다면 외부에서 요청이 들어온 것이며, 타임스탬프를 통해 시점을 확인할 수 있습니다. 해당 명령을 실행했을 때 아무런 출력도 나오지 않는 것이 가장 이상적인 결과입니다. 모델 관련 설정이 생소하다면 VPS에서 Ollama 실행하기 문서를 참조하십시오. 설치, 모델 크기 산정, 실제 로드 여부를 결정하는 메모리 제한에 대해 다룹니다.

FAQ

Ollama에 API 키나 비밀번호가 있습니까?

아니요. 실행 중인 서버에는 어떠한 인증 기능도 없으며, 공식 문서에서도 API 접근을 위해 인증이 필요하지 않다고 명시하고 있습니다. "Ollama API 키"라고 불리는 두 가지 개념은 모두 다른 용도입니다. /usr/share/ollama/.ollama/의 Ed25519 키 쌍은 사용자의 기기가 ollama.com에 인증되도록 하여 모델을 업로드하거나 비공개 모델을 내려받을 수 있게 합니다. OLLAMA_API_KEY은 클라이언트가 https://ollama.com/api의 호스팅된 API로 보내는 자격 증명입니다. 사용자의 로컬 ollama serve는 이 두 가지를 모두 읽지 않으므로, 접근 제어는 네트워크 수준이나 앞단에 배치된 프록시를 통해 수행해야 합니다.

방화벽이 있다면 OLLAMA_HOST=0.0.0.0은 안전합니까?

해당 서버에서 다른 어떤 것도 방화벽 규칙을 작성하지 않을 때만 안전합니다. 0.0.0.0는 리스너가 실제로 공용 인터페이스에 존재함을 의미하며, 방화벽 하나만 믿고 접근이 불가능할 것이라 가정하는 상황입니다. Docker가 포트를 공개하는 순간 이 신뢰는 깨집니다. Docker가 nat 테이블에 추가하는 DNAT 규칙은 패킷이 UFW가 위치한 INPUT 체인에 도달하기 전에 평가되기 때문에, 패킷은 그대로 전달되고 UFW는 이를 보지 못합니다. 127.0.0.1이나 사설 터널 주소에 바인딩하면 리스너가 공용 인터페이스에서 제거되므로, 방화벽 설정 실수로 인해 노출될 위험이 사라집니다.

Ollama 포트가 인터넷에 열려 있는지 어떻게 확인합니까?

서버에서 sudo ss -tlnp | grep 11434을 실행하고, 다른 기기에서 curl -m 5 http://YOUR_SERVER_IP:11434/api/version를 실행하십시오. ss의 결과가 127.0.0.1:11434로 표시되고 원격 curl 요청이 시간 초과(timeout)되는 것이 원하는 결과입니다. ss의 결과가 0.0.0.0:11434이나 *:11434로 표시되는데 원격 curl 요청이 JSON을 반환한다면, 전체 API에 접근이 가능한 상태입니다. 서버 자체에서 curl로 테스트하지 마십시오. 루프백 주소는 바인딩 주소와 상관없이 항상 응답하기 때문입니다.

포트를 11434에서 임의의 번호로 옮기면 안 됩니까?

안 됩니다. 그 이유는 명확합니다. 포트를 바꾼다고 해서 단일 포트 스캔 외에 속도가 느려지는 것은 없습니다. 스캐너는 전체 범위를 훑으며, /api/tags에 요청을 한 번만 보내도 어떤 포트로 들어왔든 해당 서비스가 무엇인지 식별할 수 있습니다. 포트를 옮기면 모든 클라이언트의 기본 설정이 깨지고, 나중에 자신의 설정을 파악하기도 더 어려워집니다. 대신 루프백 주소에 바인딩하십시오. 이는 리스너를 옮기는 것이 아니라 제거하는 방법입니다.

누군가 내 Ollama 서버에 접근했습니다. 무엇을 확인해야 합니까?

먼저 127.0.0.1에 바인딩하고 서비스를 재시작하여 노출을 즉시 차단하십시오. 그 후 journalctl -u ollama --since "-30 days" | grep GIN | grep -v 127.0.0.1을 실행하여 어떤 외부 주소가 어떤 엔드포인트를 언제 호출했는지 확인하십시오. /api/pull는 인증이 없으므로, 본인이 내려받지 않은 모델이 있다면 이는 디스크 공간을 점유하고 있다는 증거입니다. ollama list과 본인이 의도한 모델 목록을 비교하십시오. df -h으로 여유 공간을 확인하십시오. Ollama는 기본 로그 수준에서 프롬프트 텍스트를 기록하지 않으므로, 누가 어떤 모델을 요청했는지는 알 수 있지만 무엇이 생성되었는지는 기록되지 않습니다.

#ollama#security#api#firewall#reverse-proxy