SSD Nodes Learn 🎉 VPS $5.50/महिन्यापासून
मार्गदर्शक Matt Connorद्वारे Matt Connor

Ollama API ला password का नसतो? 3 सुरक्षा उपाय

Ollama server मध्ये authentication नसते. Port 11434 पर्यंत पोहोचणारा कोणीही models चालवू, download किंवा delete करू शकतो. सुरक्षिततेसाठी हे 3 उपाय क्रमाने करा.

Ollama API ला password नाही

Ollama API मध्ये authentication नाही. तुम्ही चालवत असलेल्या server मध्ये user, password, key check किंवा allowlist कुठेही नाही. Port 11434 वर TCP connection उघडू शकणारा कोणताही घटक तुमचे models list करू शकतो, ते चालवू शकतो, नवीन models download करू शकतो आणि तुमच्याकडील models delete करू शकतो.

अधिकृत documentation मध्ये हे स्पष्टपणे नमूद केले आहे: "http://localhost:11434 द्वारे Ollama API स्थानिक पातळीवर access करताना authentication आवश्यक नाही." स्थानिक पातळीवर हा शब्द संपूर्ण security model स्पष्ट करतो. Ollama default म्हणून 127.0.0.1 वर bind होते. त्यामुळे laptop वर loopback interface हेच access control असते. हा listener public address वर हलवल्यास access control नष्ट होते, कारण त्याची जागा घेणारी कोणतीही सुरक्षा व्यवस्था नसते.

म्हणूनच VPS (virtual private server) वर हे महत्त्वाचे ठरते. Default configuration सुरक्षित असते. दुसऱ्या machine ला model वापरता यावा म्हणून listener उघडणे हा बहुतेक लोकांचा पहिला बदल असतो. हाच बदल सर्व संरक्षण एकाच वेळी काढून टाकतो.

उघडा पोर्ट 11434 कोणती माहिती उघड करतो

प्रत्येक endpoint उपलब्ध असतो. Read-only mode किंवा स्वतंत्र admin port नसतो. या प्रत्यक्ष requests आहेत. त्या localhost ऐवजी server address कडे पाठवल्या जातात:

# 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 दुसऱ्या व्यक्तीसाठी inference चालवतो. Fair-use CPU allowance असलेल्या plan मध्ये सततचा load म्हणजे तुमचा allowance अनोळखी व्यक्ती वापरत आहे. तुम्ही एकमेव caller राहात नसल्यावर VPS वरील AI workload चे खर्च नियंत्रणात ठेवणे अधिक कठीण होते.
  • /api/pull तुमच्या disk वर लिहिते. प्रत्येक model ला दोन ते चाळीस gigabytes जागा लागते. Pulls ची loop volume भरते. Disk पूर्ण भरल्यास Ollama व्यतिरिक्त त्या server वरील इतर प्रत्येक service बंद पडू शकते.
  • Requests तुमच्या process मध्ये येतात आणि log होतात. Default log level वर Ollama केवळ metadata नोंदवते. त्यामुळे prompt text नव्हे, तर endpoint, status, latency आणि client address नोंदवले जातात. तरीही तुमचा box कोणी आणि कोणत्या कारणासाठी वापरला याची नोंद तुमच्या journal मध्ये राहते. ही नोंद गोळा करण्याचा निर्णय तुम्ही घेतलेला नसतो.
  • /api/delete models काढून टाकते. ते परत मिळवण्यासाठी तुमच्या स्वतःच्या bandwidth वरून ते पुन्हा download करावे लागतात.

यापैकी कशासाठीही exploit आवश्यक नाही. Document केलेले API जसे डिझाइन केले आहे तसेच कार्य करत आहे.

Ed25519 key हा access control नाही

“ Ollama API key” असे शोधल्यास दोन वेगवेगळ्या गोष्टी आढळतात. यापैकी कोणतीही गोष्ट तुमच्या server साठी password नाही. हे दोन्ही वेगळे समजल्यास बहुतेक गोंधळ दूर होतो.

पहिली गोष्ट म्हणजे identity key pair. Ollama पहिल्यांदा सुरू होताना Ed25519 key pair तयार करते. Linux वर install script ollama नावाचा system user तयार करते आणि त्याची home directory /usr/share/ollama येथे असते. त्यामुळे key pair येथे असते:

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

ही key बाहेरील सेवांसाठी वापरली जाते. ollama signin public half तुमच्या ollama.com account सोबत register करते. Registry वर model push करण्यासाठी किंवा private model pull करण्यासाठी हीच key तुम्हाला authorize करते. ती तुमच्या machine ची ओळख ollama.com कडे सिद्ध करते. तुमच्या machine शी connect होणाऱ्या clients कडून ती काहीही मागत नाही. ती delete केली, rotate केली किंवा कधीही तयार केली नाही, तरी तुमच्या API ला कोण call करू शकतो यावर काहीही परिणाम होत नाही.

दुसरी गोष्ट म्हणजे OLLAMA_API_KEY. या variable मध्ये तुम्ही https://ollama.com/settings/keys येथे तयार केलेली key ठेवता. Hosted API ला https://ollama.com/api येथे call करताना तुमचा client ती Authorization: Bearer $OLLAMA_API_KEY म्हणून पाठवतो. हे त्यांच्या service साठीचे credential आहे आणि client म्हणून तुम्ही ते वापरता. तुमचा स्वतःचा ollama serve ते कधीही वाचत नाही. तुमच्या VPS वर OLLAMA_API_KEY सेट केल्याने VPS वर password लागू होत नाही.

म्हणून सुरू करण्यासाठी कोणतीही setting नाही. खालील तीनही संरक्षणपद्धती एकाच प्रकारे कार्य करतात: port पर्यंत पोहोचता येणार नाही याची खात्री करा आणि त्यासमोर तपासणी करणारी एखादी गोष्ट ठेवा.

तुमचा सर्व्हर सध्या कोणत्या पत्त्यांवर ऐकत आहे ते तपासा

sudo ss -tlnp | grep 11434

सुरक्षित निकालात loopback address दिसतो:

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

उघड्या प्रवेशाचा निकाल प्रत्येक interface चे नाव दाखवतो:

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

0.0.0.0 म्हणजे सर्व IPv4 addresses, त्यात सार्वजनिक address चाही समावेश होतो. *:11434 आणि [::]:11434 याचा IPv6 समाविष्ट असताना तोच अर्थ होतो.

आता बाहेरून पडताळणी करा. ही command server वर नव्हे, तर तुमच्या laptop वर चालवा:

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

curl: (28) Connection timed out after 5001 milliseconds हा अपेक्षित answer आहे. curl: (7) Failed to connect ... Connection refused हाही तसाच आहे. version field असलेला JSON object म्हणजे विनंती करणाऱ्या कोणत्याही व्यक्तीला संपूर्ण API उपलब्ध आहे. Server वरच curl वापरून केलेली चाचणी काहीही सिद्ध करत नाही, कारण loopback नेहमी उत्तर देतो.

Exposure साधारणपणे दोनपैकी एका मार्गाने येते. पहिला मार्ग म्हणजे जाणीवपूर्वक केलेला बदल. दुसऱ्या machine ला model पर्यंत पोहोचण्याची गरज असल्यामुळे कोणी configuration edit केलेला असतो:

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

ही एकच line संपूर्ण exposure घडवते. दुसरा मार्ग Docker आहे. त्यासाठी तुम्हाला काहीही edit करण्याची गरज नसते. त्यासाठी खाली स्वतंत्र section आहे.

प्रतिबंध 1: ते localhost वरच ठेवा आणि tunnel द्वारे प्रवेश करा

हा पर्याय प्रथम वापरा. यासाठी नवीन software आवश्यक नाही आणि गळती होऊ शकणारे कोणतेही credential तयार होत नाही. हा port public interface वर कधीही उपलब्ध नसतो, त्यामुळे scanning द्वारे तो शोधता येत नाही.

default वर अवलंबून न राहता bind address स्पष्टपणे सेट करा:

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 दिसत असल्यास, दुसरी drop-in file प्राधान्याने लागू होत आहे. unit आणि प्रत्येक drop-in चा path पाहण्यासाठी systemctl cat ollama.service चालवा. त्यानंतर जुनी file हटवा.

तुमच्या laptop वरून model वापरण्यासाठी, SSH द्वारे port forward करा:

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

-L 11434:127.0.0.1:11434 तुमच्या laptop वरील port 11434 उघडते आणि तेथे येणारे सर्व काही server च्या दृष्टीने 127.0.0.1:11434 कडे पाठवते. -N मुळे SSH कोणतीही remote command चालवत नाही. त्यामुळे process फक्त tunnel सुरू ठेवतो. तो चालू असताना, तुमच्या laptop वर हे कार्य करते:

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

तुम्हाला दोन प्रकारच्या त्रुटी दिसू शकतात. bind [127.0.0.1]:11434: Address already in use म्हणजे तुमच्या laptop वर त्याच port वर स्वतःचे Ollama चालू आहे. त्यामुळे -L 11500:127.0.0.1:11434 वापरून वेगळा local port निवडा आणि client ला 11500 कडे निर्देशित करा. tunnel यशस्वीरीत्या connect झाल्यानंतरही रिकामा reply मिळत असल्यास, SSH कार्यरत आहे; पण server बाजूला Ollama listening करत नाही. त्यामुळे SSH command बदलण्यापूर्वी तेथे ss तपासा.

अनेक client machines साठी प्रत्येक व्यक्तीसाठी स्वतंत्र tunnel ठेवण्यापेक्षा private network अधिक योग्य आहे. machines WireGuard किंवा Tailscale वर जोडा. त्यानंतर Ollama ला 0.0.0.0 ऐवजी त्या network वरील address वर bind करा:

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

त्यानंतर हा port join करण्यासाठी key आवश्यक असलेल्या interface वरच उपलब्ध राहतो. firewall configuration मध्ये चूक झाली तरी ही रचना टिकून राहते. कारण public interface वर listener उपलब्ध नसल्यास, चुकून world ला परवानगी देणारा rule देखील तो listener सार्वजनिक करू शकत नाही.

प्रतिबंध 2: bearer token तपासणारा reverse proxy

सार्वजनिक इंटरनेटवरील एखाद्या घटकाला model ला कॉल करणे आवश्यक असल्यास, Ollama ला loopback वर चालू ठेवा आणि त्यासमोर proxy ठेवा. हा proxy TLS (transport layer security) termination करतो आणि योग्य header नसलेल्या विनंत्या नाकारतो. Ollama अजूनही फक्त 127.0.0.1 कडून येणारी connections स्वीकारतो, त्यामुळे proxy हाच प्रवेशाचा एकमेव मार्ग राहतो.

प्रथम प्रत्यक्ष token तयार करा. तो स्वतःहून बनवू नका:

openssl rand -base64 36

तो तपासणारी nginx site:

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;
    }
}

या configuration मधील पाच ओळी प्रत्यक्ष काम करतात. त्या प्रत्येकामुळे अन्यथा उद्भवणारी एक अपयशाची शक्यता टळते.

location block मधील if हा nginx मध्ये सामान्यतः चुकीचा पर्याय आहे. परंतु अगदी return असलेला body हा predictably काम करणाऱ्या दोन प्रकारांपैकी एक आहे. त्यामुळे येथे त्याचा वापर सुरक्षित आहे.

location = /api/pull हा exact match आहे. nginx, location / prefix पेक्षा exact matches ना अधिक प्राधान्य देतो. त्यामुळे token तपासण्यापूर्वीच हे तीन endpoints नाकारले जातात. वैध token मुळे inference वापरता येते; disk भरून टाकण्याची क्षमता मिळत नाही.

proxy_set_header Host 127.0.0.1:11434; महत्त्वाचे आहे, कारण Ollama येणारे Host आणि Origin headers तपासते. Proxy चे सार्वजनिक hostname थेट पुढे पाठवल्यास Ollama कडून आलेला 403 Forbidden तयार होऊ शकतो, nginx कडून नाही. त्यामुळे debugging गोंधळात टाकणारे होते. Browser client ला विशिष्ट origin ला परवानगी आवश्यक असल्यास OLLAMA_ORIGINS हा दुसरा नियंत्रण पर्याय आहे.

proxy_buffering off; महत्त्वाचे आहे, कारण Ollama response token-by-token stream करते. Buffering सुरू असल्यास nginx पूर्ण stream धरून ठेवतो आणि generation संपल्यावर तो एकाच भागात पाठवतो. त्यामुळे संपूर्ण generation दरम्यान client अडकलेला दिसतो.

proxy_read_timeout 600s; महत्त्वाचे आहे, कारण nginx चे default मूल्य 60 seconds आहे. CPU वर चालणाऱ्या दीर्घ generation मध्ये हा कालावधी सहज ओलांडला जातो. Client ला 504 Gateway Time-out मिळते आणि /var/log/nginx/error.log मध्ये upstream timed out (110: Connection timed out) while reading response header from upstream नोंदवले जाते. Request अजूनही चालू असते. nginx ने मात्र ती सोडून दिलेली असते.

दोन्ही मार्ग reload करून तपासा:

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

पहिल्या command ने 401 दाखवले पाहिजे. दुसऱ्या command ने तुमची model list दाखवली पाहिजे. पहिल्या command नेही model list दाखवली, तर map block चुकीच्या scope मध्ये आहे. तो http स्तरावर असणे आवश्यक आहे. त्यामुळे तो /etc/nginx/conf.d/ अंतर्गत असलेल्या file मध्ये किंवा server block च्या वर ठेवा; server च्या आत कधीही ठेवू नका.

Caddy हेच काम basic authentication वापरून चार ओळींमध्ये करते. त्यामुळे browser client साठी bearer token पेक्षा हा पर्याय अधिक योग्य ठरतो:

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

अपेक्षित bcrypt hash तयार करण्यासाठी caddy hash-password चालवा. Naming मधील एक अडचण लक्षात ठेवा: Caddy v2.8 पूर्वी directive basicauth होती आणि आता ती basic_auth आहे. त्यामुळे जुन्या guide मधून copy केलेली config load होत नाही आणि Caddy ला ओळखता न आलेल्या directive चे नाव दाखवते.

तुम्ही कोणताही proxy निवडला तरी हा सर्वांसाठी एकच shared secret असतो. तो असलेल्या प्रत्येक client ला समान access मिळतो. तो revoke करण्यासाठी config संपादित करून प्रत्येक caller एकाच वेळी update करावा लागतो.

संरक्षण 3: प्रत्येक client साठी keys जारी करणारा gateway

मॉडेलला एकापेक्षा अधिक व्यक्ती किंवा अॅप्लिकेशनकडून requests येऊ लागल्यावर shared token अपुरा पडतो. कोणत्या client मुळे load निर्माण झाला हे समजत नाही. तसेच सर्व clients बंद न करता त्यांपैकी एखाद्याचा access बंद करता येत नाही. Proxy ज्या ठिकाणी होता, त्या ठिकाणी gateway ठेवला जातो. तो त्याच OpenAI-compatible API द्वारे requests स्वीकारतो, प्रत्येक client साठी स्वतंत्र key जारी करतो आणि प्रत्येक key ने कोणता वापर केला याची नोंद ठेवतो. Self-hosted LiteLLM gateway हा यासाठी नेहमीचा पर्याय आहे. Access control व्यतिरिक्त तो प्रत्येक key साठी budgets आणि request logs उपलब्ध करून देतो.

Defence 1 मधील नियम बदलत नाही. Ollama 127.0.0.1 वर bind होते. त्याच्याशी संवाद साधणारी एकमेव process gateway असते. Public listener असलेली एकमेव service देखील gateway असते. ज्या मशीनवर port 11434 अजूनही संपूर्ण इंटरनेटसाठी खुला आहे, तिथे gateway ठेवणे निरुपयोगी आहे. Callers gateway वगळून थेट Ollama शी संवाद साधू शकतात.

फायरवॉलचा सापळा: प्रकाशित container port UFW ला वगळतो

फायरवॉल योग्यरीत्या कॉन्फिगर केलेल्या सर्व्हरवरही exposed instances का दिसतात, याचे हे कारण आहे.

UFW (uncomplicated firewall) आपले rules kernel च्या filter table मधील INPUT chain मध्ये लिहिते आणि INPUT स्वतः host कडे निर्देशित केलेली packets हाताळते. Docker चा -p flag nat table मधील PREROUTING chain मध्ये destination NAT (network address translation) rule लिहितो. Packet कुठे पाठवायचे हे kernel ठरवण्यापूर्वीच हा rule तपासला जातो. Routing decision होईपर्यंत destination container च्या address मध्ये बदललेले असते. त्यामुळे packet स्थानिकरीत्या deliver होण्याऐवजी forward होते आणि INPUT ऐवजी FORWARD मधून जाते. UFW चे INPUT rules कधीही तपासले जात नाहीत. त्यामुळे packet फायरवॉलमधून जाण्याऐवजी त्याला वळसा घालते.

म्हणून खालील sequence port 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 default deny सह firewall active असल्याचे दाखवते. दोन्ही निष्कर्ष एकाच वेळी बरोबर असतात. त्यामुळे लोक चुकीच्या निष्कर्षावर विश्वास ठेवतात. हे घडवणारा rule तुम्ही पाहू शकता:

sudo iptables -t nat -L DOCKER -n

यासाठी publish flag मध्ये एक address द्या:

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 नमूद केल्याने mapping ची host बाजू loopback शी बांधली जाते. त्यामुळे तुमचा SSH tunnel आणि reverse proxy त्यापर्यंत पोहोचू शकतात, पण इंटरनेट पोहोचू शकत नाही. येथे container पुन्हा तयार करणे सुरक्षित आहे, कारण models container मध्ये नसून named ollama volume मध्ये साठवलेले आहेत.

दोन्ही views एकमेकांशी जुळतात का ते तपासा:

docker port ollama
sudo ss -tlnp | grep 11434

docker port ollama ने 11434/tcp -> 127.0.0.1:11434 print केले पाहिजे. 0.0.0.0:11434 print झाल्यास तुम्ही अजूनही exposed आहात. ही यंत्रणा एकदा समजून घेतल्यावर तुम्ही भविष्यात publish केलेल्या प्रत्येक container वर ती लागू करता येईल: Docker चे published ports UFW ला का वगळतात येथे DOCKER-USER chain आणि Docker restart नंतर टिकून राहणारे rules समजावले आहेत. Host policy स्वतः तयार करत असाल, तर नवीन VPS साठी आवश्यक UFW rules या आधारभूत configuration चे स्पष्टीकरण देते.

प्रक्रिया कोणत्या वापरकर्त्याच्या खात्याखाली चालते

Linux install script एक स्वतंत्र account तयार करते आणि सेवा त्याच्या खात्याखाली चालवते:

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

/etc/systemd/system/ollama.service मधील unit त्यानंतर User=ollama आणि Group=ollama सेट करते. त्यात बदल करू नका. टर्मिनलमध्ये manually सुरू केलेली तात्पुरती ollama serve प्रक्रिया तुम्ही ज्या account ने login केले आहे त्याच account खाली चालते. तो account root असल्यास, authentication नसलेले API root म्हणून files लिहिते. ते कोणते आहे ते तपासा:

ps -o user= -C ollama

उत्तर ollama असावे. यापेक्षा वेगळे काही दिसल्यास unit सोबत किंवा त्याऐवजी manually सुरू केलेली प्रक्रिया चालू आहे. नंतर जोडलेल्या प्रत्येक daemon साठीही हाच विचार लागू होतो. किमान विशेषाधिकार असलेल्या वापरकर्त्यांखाली सेवा चालवणे ही बाब योग्य प्रकारे हाताळते.

Ollama API endpoint सुरक्षित आहे का हे कसे तपासावे

तुम्ही कोणताही पर्याय निवडला असला तरी एक चाचणी निर्णायक ठरते. ती दुसऱ्या मशीनवरून चालवावी लागते:

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

दोन्ही विनंत्या timeout व्हाव्यात किंवा नाकारल्या जाव्यात. तुम्ही proxy तयार केला असल्यास, proxy hostname वरील हेच दोन paths credentials शिवाय 401 परत करावेत आणि credentials दिल्यावर खरा JSON परत करावा.

त्यानंतर access log एकदा वाचा. पोर्ट उघडा असताना तो कोणाला सापडला का, हे त्यातून कळते:

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

Ollama प्रत्येक request साठी एक ओळ लिहिते आणि client address समाविष्ट करते:

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

Ollama loopback वर bind केल्यानंतर प्रत्येक ओळीत 127.0.0.1 एकदा दिसले पाहिजे, कारण connection फक्त याच address वरून येऊ शकते. त्या column मध्ये public address दिसत असल्यास request बाहेरून आलेली आहे. timestamp वरून ती कधी आली हे कळते. त्या command मधून कोणतेही output न मिळणे हाच अपेक्षित परिणाम आहे. Ollama विषयीचा हा भाग तुमच्यासाठी नवीन असल्यास, VPS वर Ollama चालवणे या मार्गदर्शकात install, model sizing आणि प्रत्यक्षात कोणते model load होतील हे ठरवणाऱ्या memory limits चे वर्णन आहे.

FAQ

Ollama कडे API key किंवा password आहे का?

नाही. तुम्ही चालवत असलेल्या server वर कोणत्याही प्रकारचे authentication नाही. API पर्यंत पोहोचण्यासाठी authentication आवश्यक नाही, असे अधिकृत documentation मध्ये नमूद केले आहे. “Ollama API key” म्हणून ओळखल्या जाणाऱ्या दोन्ही गोष्टींचा उपयोग वेगळा आहे. /usr/share/ollama/.ollama/ मधील Ed25519 pair तुमच्या machine ची ollama.com कडे ओळख पटवते, त्यामुळे तुम्ही models push करू शकता आणि private models pull करू शकता. OLLAMA_API_KEY हे तुमचा client https://ollama.com/api वरील hosted API कडे पाठवणारे credential आहे. तुमचा स्वतःचा ollama serve यापैकी कोणतेही credential वाचत नाही. त्यामुळे access control network किंवा समोरील proxy कडून लागू करावे लागते.

Firewall असल्यास OLLAMA_HOST=0.0.0.0 सुरक्षित आहे का?

त्या box वर इतर कोणतीही गोष्ट firewall rules लिहित नसेल, तेव्हाच. 0.0.0.0 याचा अर्थ listener public interface वर प्रत्यक्ष उपलब्ध आहे आणि तो unreachable ठेवण्यासाठी तुम्ही फक्त firewall वर अवलंबून आहात. Docker ने port publish केल्याच्या क्षणी हा विश्वास अपयशी ठरतो. Docker ने nat table मध्ये जोडलेला DNAT rule packet INPUT chain पर्यंत पोहोचण्यापूर्वी लागू होतो. UFW याच chain मध्ये कार्यरत असते. त्यामुळे packet forward होतो आणि UFW ला तो दिसतच नाही. 127.0.0.1 किंवा private tunnel address वर bind केल्यास listener public interface वरून काढला जातो. त्यामुळे firewall मधील चुकीमुळे उघड करण्यासाठी काहीही शिल्लक राहत नाही.

माझा Ollama port internet साठी खुला आहे का, हे कसे तपासू?

Server वर sudo ss -tlnp | grep 11434 चालवा आणि वेगळ्या machine वरून curl -m 5 http://YOUR_SERVER_IP:11434/api/version चालवा. ss ने 127.0.0.1:11434 दाखवणे आणि remote curl timeout होणे, ही अपेक्षित उत्तरांची जोडी आहे. ss ने 0.0.0.0:11434 किंवा *:11434 दाखवले आणि remote curl ने JSON परत केले, तर संपूर्ण API reachable आहे. Server वरच curl वापरून कधीही तपासू नका, कारण bind address काहीही असला तरी loopback उत्तर देते.

Port 11434 ऐवजी एखाद्या random port वर हलवू शकतो का?

नाही. याचे कारण स्पष्टपणे समजून घेणे महत्त्वाचे आहे. वेगळा port वापरल्याने केवळ एका port च्या scan ला विलंब होतो. Scanners संपूर्ण range तपासतात. /api/tags कडे केलेली एक request कोणत्याही port वर service उपलब्ध असली तरी ती ओळखते. Port हलवल्याने प्रत्येक client चा default देखील मोडतो आणि पुढे तुमची स्वतःची setup समजून घेणे अधिक कठीण होते. Listener दुसरीकडे हलवण्याऐवजी loopback वर bind करा. त्यामुळे listener सार्वजनिक interface वरूनच काढला जातो.

कोणीतरी माझ्या उघड्या Ollama पर्यंत पोहोचले. मी काय तपासावे?

प्रथम ते 127.0.0.1 वर bind करा आणि service restart करा. त्यामुळे तपास सुरू करण्यापूर्वी exposure थांबेल. त्यानंतर कोणत्या बाहेरील addresses ने कोणत्या endpoints ला आणि कधी call केले, हे पाहण्यासाठी journalctl -u ollama --since "-30 days" | grep GIN | grep -v 127.0.0.1 चालवा. ollama list मधील नोंदी तुमच्याकडे असलेल्या models शी तुलना करा. /api/pull मध्ये authentication नसल्यामुळे तुम्ही pull न केलेला model हा disk usage तसेच घटनेचा पुरावा असू शकतो. df -h वापरून मोकळी जागा तपासा. Default log level वर Ollama prompt text नोंदवत नाही. त्यामुळे कोणी आणि कोणत्या model साठी request केली याची नोंद मिळते; मात्र काय generate झाले याची नोंद मिळत नाही.

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