메인 콘텐츠로 건너뛰기
In January 2026, SentinelLABS and Censys published research mapping roughly 175,000 internet-exposed Ollama hosts across about 130 countries — SentinelOne’s writeup is the primary source; the numbers here have also circulated via The Hacker News and SecurityWeek. Researchers reported that roughly half of the exposed hosts advertised tool-calling support — meaning code execution, not just chat. 이는 Ollama 자체의 취약점이 아닙니다. 많은 사용자들이 기본 설정을 그대로 사용하기 때문에 발생하는 현상일 뿐입니다.

​
문제가 발생하는 원인

Ollama는 기본적으로 127.0.0.1:11434 포트에서 대기합니다. 이때는 루프백 주소만 사용되므로 외부에서는 접근할 수 없습니다. 네트워크 내 다른 기기나 휴대폰, 별도의 컴퓨터, 혹은 다른 위치에서 실행되는 코딩 에이전트에서 접근하려면 다음과 같은 조치가 필요합니다.
단 하나의 환경 변수만 설정하면 바인딩 주소가 루프백에서 모든 인터페이스로 변경됩니다. 이를 라우터의 포트 포워딩 기능이나 클라우드 VM의 공용 IP, 혹은 일시적으로 열어둔 방화벽 규칙과 결합하면 11434 포트가 LAN 내부뿐만 아니라 인터넷 전체에서 접근 가능해집니다. 기본적으로 인증 절차가 없으므로 포트를 발견한 누구나 직접 API를 호출할 수 있습니다. 모델 목록을 조회하거나 추론을 실행할 수 있으며, 툴 호출 기능이 활성화된 호스트라면 코드 실행까지 가능합니다. 바로 이러한 패턴이 Shodan이나 Censys와 같은 대량 스캔 도구들이 찾아내도록 설계된 것입니다. 특별한 공격이 필요하지 않으며 단순한 포트 스캔만으로도 충분합니다.
이는 Ollama의 결함이 아니라 설정상의 문제입니다. 루프백 주소 대신 모든 인터페이스에 바인딩되고 포트가 외부에 개방된 상태이며 인증 절차가 없다는 점은 Ollama뿐만 아니라 모든 로컬 모델 서버에도 해당하는 문제입니다.

​
왜 단순히 인증 기능만 추가하는 것으로는 충분하지 않은가

Putting a reverse proxy with basic auth in front of 0.0.0.0:11434 helps, but it doesn’t remove the underlying condition: the port is still listening, and something in your network path still has to be reachable from the outside for that proxy to work. Every inbound-facing component — the proxy, the firewall rule, the port forward, the TLS cert — is one more thing that has to stay correctly configured forever. Misconfigure any of them once, or roll one back during debugging, and you’re back to an open port.

​
또 다른 방법: 인바운드 포트를 아예 두지 않는 것입니다

Tokios는 다른 접근 방식을 취합니다. 사용자가 모델 옆에서 실행하는 tokios-connector은 인바운드 트래픽을 전혀 수신하지 않습니다. 대신 브라우저가 웹페이지를 불러올 때 사용하는 방향과 동일하게 wss:// 연결을 한 번만 아웃바운드로 https://api.tokios.com에 개방한 뒤, Tokios가 해당 연결을 통해 요청을 다시 라우팅합니다. 포트를 포워딩할 필요도, 방화벽 규칙을 설정할 필요도 없으며 0.0.0.0에도 아무것도 바인딩되지 않습니다. 모델에 도달하는 모든 요청에는 반드시 범위가 지정된 sk-tok-… API 키가 포함되어야 하며, Tokios는 이 키를 확인한 뒤에야 터널을 통해 커넥터로 요청을 전달합니다. 이 키들은 특정 모델 이름 패턴에 따라 배포 단위로 지정될 수 있고, 교체되거나 비활성화, 삭제될 수도 있습니다. 한번 무효화된 키는 즉시 인증 기능이 중단됩니다. 이 방식이 의미하는 바와 그렇지 않은 점을 명확히 하자면, 아웃바운드 전용 커넥터에는 애초에 노출될 인바운드 인터페이스가 존재하지 않습니다. 이는 보안 보장이라기보다는 연결 모델 자체의 구조적 차이입니다. Tokios는 이를 통해 사용자가 노출한 모델의 모든 오용 가능성을 막는다고 주장하지 않습니다. 유출된 API 키 역시 다른 곳에서 유출된 비밀번호와 마찬가지로 실제 위협 요소입니다. 핵심은 보다 기계적이고 좁은 의미입니다. 즉 스캐너가 찾을 수 있는 리스닝 포트가 애초에 존재하지 않는다는 점입니다.
현재 원격 접속을 위해 Ollama와 OLLAMA_HOST=0.0.0.0을 함께 사용 중이라면, 175,000 호스트 번호가 바로 이 방식을 반영한 것입니다. 모델을 다시 127.0.0.1에 배치한 뒤 아웃바운드 전용 커넥터를 통해 접속해 보세요. 전환 방법은 Ollama 원격 접속 문서를 참고하시기 바랍니다.

​
실제로 어떻게 작동하는지 살펴보겠습니다

1

기본 설정대로 루프백 상에서 Ollama를 실행합니다

No OLLAMA_HOST override, no bind-to-all-interfaces flag.
2

커넥터를 페어링합니다

tokios-connector이 https://api.tokios.com에 아웃바운드 연결을 시도한 뒤 콘솔에서 승인을 기다립니다. 이 단계에서는 사용자 기기나 라우터에 포트가 열리는 일은 전혀 없습니다
3

어디서든 모델을 호출할 수 있습니다

요청 시에는 반드시 유효하고 범위가 지정된 sk-tok-… 키가 포함되어야만 커넥터까지 도달할 수 있습니다
캐리어급 NAT(CGNAT) 환경에 있는 사용자들도 마찬가지 상황에 처해집니다. 이 경우 포트 포워딩은 권장되지 않을 뿐만 아니라 구조적으로 불가능한데, 라우터에 포워딩할 공용 IP가 없기 때문입니다. 왜 그런지 그리고 아웃바운드 전용 연결 방식이 어떻게 이 문제를 우회하는지 알아보려면 CGNAT 뒤에서 로컬 LLM 제공하기를 참고하시기 바랍니다.

​
요약하자면

The 175,000-host figure is a scan result, not a prediction about any specific server. But the pattern behind it is simple and worth remembering regardless of the exact count: inbound reachability plus no auth is the whole problem. Removing the inbound part removes an entire category of “how did they even find this” incidents, because there’s nothing listening to find.

빠른 시작

커넥터를 연결하고 모델을 등록한 뒤 첫 번째 요청을 보내보세요.

Ollama 원격 접근 방법

이미 외부에 공개된 Ollama 설치를 루프백 모드로 되돌린 뒤 Tokios를 통해 접속하는 방법입니다.

Tokios가 요청을 라우팅하는 방식

아웃바운드 전용 아키텍처가 어떻게 작동하는지 전체적으로 살펴보세요.