ஆல் Ollama API பாதுகாப்பு: கடவுச்சொல் இல்லாமல் இயங்குவது
Ollama server-ல் இயல்பாகவே authentication கிடையாது. 11434 port வழியாக எவரும் உங்கள் models-ஐ இயக்க முடியும். இந்த பாதுகாப்பு சிக்கலை சரிசெய்ய மூன்று எளிய வழிகளைப் பாருங்கள்.
Ollama API-க்கு கடவுச்சொல் இல்லை
Ollama API-ல் எந்தவிதமான அங்கீகாரமும் (authentication) இல்லை. நீங்கள் இயக்கும் server-ல் பயனர், கடவுச்சொல், key சரிபார்ப்பு அல்லது allowlist என எதுவும் கிடையாது. 11434 port-க்கு TCP connection ஏற்படுத்தக்கூடிய எவரும் உங்கள் models-ஐ பட்டியலிடலாம், இயக்கலாம், புதியவற்றைத் தரவிறக்கம் செய்யலாம் மற்றும் ஏற்கனவே உள்ளவற்றை நீக்கலாம்.
இதன் அதிகாரப்பூர்வ ஆவணங்கள் இதைத் தெளிவாகக் குறிப்பிடுகின்றன: "Ollama-வின் API-ஐ http://localhost:11434 வழியாக உள்ளூர் அளவில் அணுகும்போது எந்த அங்கீகாரமும் தேவையில்லை." உள்ளூர் அளவில் (locally) என்ற வார்த்தையே அதன் முழு பாதுகாப்பு மாதிரியையும் குறிக்கிறது. Ollama இயல்பாகவே 127.0.0.1-ல் பிணைக்கப்படுவதால் (bind), ஒரு laptop-ல் loopback interface மட்டுமே அணுகல் கட்டுப்பாடாகச் செயல்படுகிறது. அந்த listener-ஐ ஒரு public address-க்கு மாற்றினால், அணுகல் கட்டுப்பாடு நீங்கிவிடும்; ஏனெனில் அதற்குப் பதிலாக வேறு எந்தப் பாதுகாப்பும் அங்கு இல்லை.
இதனால்தான் VPS (virtual private server)-ல் இது முக்கியத்துவம் பெறுகிறது. இயல்புநிலை அமைப்பு பாதுகாப்பானது. பெரும்பாலான பயனர்கள் செய்யும் முதல் மாற்றமான, மற்றொரு machine-ஐ model-ஐப் பயன்படுத்த அனுமதிப்பதற்காக listener-ஐத் திறப்பதுதான், அனைத்துப் பாதுகாப்புகளையும் ஒரே நேரத்தில் நீக்கும் செயலாகிறது.
திறந்திருக்கும் 11434 port எதை வெளிப்படுத்துகிறது
ஒவ்வொரு endpoint-ம் வெளிப்படும். இதில் read-only mode கிடையாது, தனிப்பட்ட admin port-ம் இல்லை. இவை localhost-க்கு பதிலாக server முகவரியை இலக்காகக் கொண்ட உண்மையான கோரிக்கைகள் (requests):
# 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 வரம்பு கொண்ட திட்டத்தில், தொடர்ச்சியான சுமை என்பது ஒரு அந்நியர் உங்கள் ஒதுக்கீட்டைப் பயன்படுத்துவதாகும். நீங்கள் மட்டுமே பயன்படுத்துபவராக இல்லாதபோது, VPS-ல் AI பணிச்சுமை செலவுகளைக் கட்டுப்படுத்துவது மிகவும் கடினமாகிறது.
/api/pullஉங்கள் disk-ல் எழுதும். ஒவ்வொரு மாடலும் இரண்டு முதல் நாற்பது gigabytes வரை இருக்கும். மீண்டும் மீண்டும் pull செய்யும் சுழற்சி உங்கள் volume-ஐ நிரப்பிவிடும். disk முழுமையாக நிரம்பினால், Ollama மட்டுமல்லாமல் அந்த server-ல் உள்ள மற்ற அனைத்து சேவைகளும் பாதிக்கப்படும்.- கோரிக்கைகள் உங்கள் process-க்குள் வந்து பதிவாகின்றன. இயல்புநிலை log level-ல் Ollama metadata-வை மட்டுமே பதிவு செய்யும். எனவே, prompt உரை கிடைக்காது, ஆனால் endpoint, status, latency மற்றும் client முகவரி ஆகியவை கிடைக்கும். உங்கள் server-ஐ யார் பயன்படுத்தினார்கள், எதற்காகப் பயன்படுத்தினார்கள் என்பதற்கான பதிவு உங்கள் journal-ல் இருக்கும். இதைச் சேகரிக்க நீங்கள் முடிவெடுக்கவில்லை.
/api/deleteமாடல்களை நீக்கும். அவற்றை மீண்டும் பெற, உங்கள் சொந்த bandwidth-ஐப் பயன்படுத்தி மீண்டும் பதிவிறக்கம் செய்ய வேண்டியிருக்கும்.
இதற்கு எந்த exploit-ம் தேவையில்லை. இது ஆவணப்படுத்தப்பட்ட 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 key-ஐ ollama.com கணக்கில் பதிவு செய்கிறது. ஒரு model-ஐ registry-க்கு அனுப்ப (push) அல்லது private model-ஐப் பெற (pull) இதுவே அங்கீகாரம் அளிக்கிறது. இது உங்கள் machine-ஐ ollama.com-க்கு உறுதிப்படுத்துகிறது. உங்கள் machine-உடன் இணையும் clients-க்கு இது எந்தக் கட்டுப்பாட்டையும் விதிக்காது. இதை நீக்கினாலும், மாற்றினாலும் அல்லது உருவாக்காமல் இருந்தாலும், உங்கள் API-ஐ யார் அழைக்கலாம் என்பதில் எந்த மாற்றமும் இருக்காது.
இரண்டாவது OLLAMA_API_KEY ஆகும். இந்த variable, நீங்கள் https://ollama.com/settings/keys-ல் உருவாக்கும் ஒரு key-ஐ வைத்திருக்கும். நீங்கள் https://ollama.com/api-ல் உள்ள hosted API-ஐ அழைக்கும்போது, உங்கள் client அதை Authorization: Bearer $OLLAMA_API_KEY-ஆக அனுப்பும். இது அவர்களின் சேவைக்கான ஒரு credential ஆகும்; இதை நீங்கள் client-ஆகப் பயன்படுத்துகிறீர்கள். உங்கள் சொந்த ollama serve இதை ஒருபோதும் வாசிப்பதில்லை. உங்கள் VPS-ல் OLLAMA_API_KEY-ஐ அமைப்பது உங்கள் VPS-க்கு கடவுச்சொல் பாதுகாப்பைத் தராது.
எனவே, இதைச் செயல்படுத்த எந்த அமைப்பும் (setting) இல்லை. கீழே உள்ள மூன்று பாதுகாப்பு முறைகளும் ஒரே விதமாகவே செயல்படுகின்றன: port-ஐ அணுக முடியாதபடி வைத்திருங்கள், மேலும் அதைச் சரிபார்க்கும் ஒரு கருவியை அதற்கு முன்னால் நிறுவுங்கள்.
உங்கள் server தற்போது எதைக் கவனிக்கிறது (listening) என்பதைச் சரிபார்க்கவும்
sudo ss -tlnp | grep 11434பாதுகாப்பான முடிவானது loopback முகவரியைக் காட்டும்:
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 என்பது அந்த machine-ல் உள்ள அனைத்து IPv4 முகவரிகளையும் குறிக்கும், இதில் public முகவரியும் அடங்கும். *:11434 மற்றும் [::]:11434 ஆகியவை IPv6-உடன் சேர்த்து அதே பொருளைத் தரும்.
இப்போது வெளியிலிருந்து உறுதிப்படுத்தவும். இதை server-ல் இயக்காமல், உங்கள் laptop-ல் இயக்கவும்:
curl -m 5 http://YOUR_SERVER_IP:11434/api/versioncurl: (28) Connection timed out after 5001 milliseconds என்பது நீங்கள் எதிர்பார்க்கும் பதில், curl: (7) Failed to connect ... Connection refused என்பதும் அதேதான். version புலத்தைக் கொண்ட ஒரு JSON object, அந்த API-ஐ யார் வேண்டுமானாலும் அணுக முடியும் என்பதைக் குறிக்கிறது. Server-லேயே curl மூலம் சோதிப்பது எதையும் நிரூபிக்காது, ஏனெனில் loopback எப்போதும் பதிலளிக்கும்.
பொதுவாக இரண்டு வழிகளில் வெளிப்பாடு (exposure) நிகழ்கிறது. முதலாவது, வேண்டுமென்றே செய்யப்படும் திருத்தம், ஏனெனில் மற்றொரு machine-லிருந்து அந்த model-ஐ அணுக வேண்டிய தேவை ஏற்பட்டிருக்கலாம்:
sudo systemctl edit ollama.service[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"அந்த ஒரு வரிதான் முழு வெளிப்பாட்டிற்கும் காரணமாகிறது. இரண்டாவது வழி Docker, இது எதையும் திருத்தச் சொல்லாது. அதற்கென கீழே தனிப் பகுதி உள்ளது.
பாதுகாப்பு முறை 1: localhost-ல் வைத்துக்கொண்டு tunnel செய்யவும்
இதை முதலில் முயற்சி செய்யுங்கள். இதற்குப் புதிய மென்பொருள் தேவையில்லை, கசியக்கூடிய எந்தவொரு நற்சான்றிதழும் (credential) உருவாக்கப்படுவதில்லை. இந்த port பொதுவான interface-ல் இருக்காது என்பதால், scanning மூலம் இதைக் கண்டறிய முடியாது.
இயல்பான அமைப்பைச் சார்ந்திருக்காமல், bind முகவரியை நேரடியாகக் குறிப்பிடவும்:
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 11434ss இப்போது 127.0.0.1:11434-ஐக் காட்ட வேண்டும். ஒருவேளை அது இன்னும் 0.0.0.0-ஐக் காட்டினால், வேறொரு drop-in கோப்பு முன்னுரிமை பெறுகிறது என்று அர்த்தம். systemctl cat ollama.service-ஐ இயக்கி, அந்த unit மற்றும் அதன் அனைத்து drop-in கோப்புகளையும் பாதையுடன் பட்டியலிட்டு, தேவையற்ற கோப்பை நீக்கவும்.
உங்கள் மடிக்கணினியிலிருந்து இந்த மாதிரியைப் பயன்படுத்த, SSH மூலம் port-ஐ forward செய்யவும்:
ssh -N -L 11434:127.0.0.1:11434 you@your-server-L 11434:127.0.0.1:11434 உங்கள் மடிக்கணினியில் 11434 port-ஐத் திறந்து, அங்கு வரும் அனைத்தையும் server-ன் பார்வையில் 127.0.0.1:11434-க்கு அனுப்பும். -N என்பது SSH-ஐ ஒரு remote command-ஐ இயக்க வேண்டாம் என்று கூறுகிறது, எனவே அந்த process tunnel-ஐத் திறந்து வைத்திருக்கும். அது இயங்கும்போது, உங்கள் மடிக்கணினியில் இது வேலை செய்யும்:
curl -s http://localhost:11434/api/tagsநீங்கள் இரண்டு தோல்விகளைச் சந்திக்க நேரிடலாம். bind [127.0.0.1]:11434: Address already in use என்பது உங்கள் மடிக்கணினியில் ஏற்கனவே அந்த port-ல் Ollama இயங்குகிறது என்று பொருள், எனவே -L 11500:127.0.0.1:11434 மூலம் வேறு ஒரு local port-ஐத் தேர்ந்தெடுத்து, உங்கள் client-ஐ 11500-க்கு மாற்றவும். சரியாக இணைக்கப்பட்ட tunnel வழியாக வெற்றுப் பதில் (empty reply) கிடைத்தால், SSH வேலை செய்கிறது ஆனால் server பக்கத்தில் Ollama இயங்கவில்லை என்று பொருள், எனவே SSH கட்டளையைத் தொடுவதற்கு முன் அங்கு ss-ஐச் சரிபார்க்கவும்.
பல client கணினிகளுக்கு, ஒவ்வொரு நபருக்கும் ஒரு tunnel அமைப்பதை விட, ஒரு private network சிறந்தது. கணினிகளை WireGuard அல்லது Tailscale-ல் இணைத்து, Ollama-வை 0.0.0.0-க்கு பதிலாக அந்த network-ன் முகவரியுடன் bind செய்யவும்:
[Service]
Environment="OLLAMA_HOST=10.8.0.1:11434"இந்த port நீங்கள் key மூலம் இணையும் interface-ல் மட்டுமே இருக்கும். இது firewall-ல் தவறு நடந்தாலும் பாதுகாப்பாக இருக்கும், ஏனெனில் தவறுதலாக பொதுமக்களுக்கு அனுமதி அளித்தாலும், public interface-ல் இல்லாத listener-ஐ வெளிப்படுத்த முடியாது.
பாதுகாப்பு 2: bearer token-ஐ சரிபார்க்கும் reverse proxy
பொது இணையத்திலிருந்து ஏதேனும் ஒன்று model-ஐ அழைக்க வேண்டியிருக்கும் போது, Ollama-வை loopback-ல் வைத்துக்கொண்டு, அதற்கு முன்னால் ஒரு proxy-ஐ அமைக்கவும். இந்த proxy TLS (transport layer security)-ஐ முடித்து, சரியான header இல்லாத கோரிக்கைகளை நிராகரிக்கிறது. Ollama தொடர்ந்து 127.0.0.1-லிருந்து வரும் இணைப்புகளை மட்டுமே ஏற்பதால், இந்த proxy மட்டுமே உள்ளே செல்வதற்கான ஒரே வழியாகும்.
முதலில் ஒரு உண்மையான token-ஐ உருவாக்கவும். நீங்களாகவே எதையும் உருவாக்க வேண்டாம்:
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;
}
}அதில் உள்ள ஐந்து வரிகள் உண்மையான வேலையைச் செய்கின்றன, ஒவ்வொன்றும் நீங்கள் எதிர்கொள்ளக்கூடிய ஒரு தோல்வியைத் தடுக்கின்றன.
nginx-ல் ஒரு location தொகுதிக்குள் if-ஐப் பயன்படுத்துவது பொதுவாக நல்லதல்ல, ஆனால் சரியாக return அளவுள்ள body, கணிக்கக்கூடிய வகையில் செயல்படும் இரண்டு வடிவங்களில் ஒன்றாகும், எனவே இந்த பயன்பாடு பாதுகாப்பானது.
location = /api/pull என்பது ஒரு துல்லியமான பொருத்தம் (exact match), மேலும் nginx துல்லியமான பொருத்தங்களை location / முன்னொட்டை விட உயர்வாகக் கருதுகிறது, எனவே அந்த மூன்று endpoints-களும் token பரிசீலிக்கப்படுவதற்கு முன்பே நிராகரிக்கப்படுகின்றன. ஒரு செல்லுபடியாகும் token உங்களுக்கு inference-ஐ மட்டுமே வழங்கும், உங்கள் disk-ஐ நிரப்பும் திறனை வழங்காது.
proxy_set_header Host 127.0.0.1:11434; முக்கியமானது, ஏனெனில் Ollama உள்வரும் Host மற்றும் Origin தலைப்புகளை (headers) ஆய்வு செய்கிறது. proxy-ன் பொதுவான hostname-ஐ அப்படியே கடத்துவது, nginx-லிருந்து வராமல் Ollama-விலிருந்து வரும் ஒரு 403 Forbidden-ஐ உருவாக்கலாம், இது பிழைத்திருத்தம் செய்ய குழப்பமாக இருக்கும். OLLAMA_ORIGINS என்பது மற்றொரு கருவி, இது ஒரு குறிப்பிட்ட origin அனுமதிக்கப்பட வேண்டிய browser client-க்காகப் பயன்படுகிறது.
proxy_buffering off; முக்கியமானது, ஏனெனில் Ollama அதன் பதிலை token-ஆக stream செய்கிறது. buffering செயல்பாட்டில் இருந்தால், nginx stream-ஐத் தடுத்து வைத்து, இறுதியில் முழுமையாக வழங்குகிறது, இதனால் generation முடியும் வரை உங்கள் client உறைந்து போனது போலத் தோன்றும்.
proxy_read_timeout 600s; முக்கியமானது, ஏனெனில் nginx இயல்பாக 60 வினாடிகளை காலாவதி நேரமாக (timeout) கொண்டுள்ளது. 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-ஐப் பதிவு செய்யும். கோரிக்கை இன்னும் செயல்பட்டுக்கொண்டிருக்கும், ஆனால் 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முதலாவது 401-ஐ அச்சிட வேண்டும். இரண்டாவது உங்கள் model பட்டியலை அச்சிட வேண்டும். முதலாவது கூட model பட்டியலைத் திருப்பியளித்தால், map தொகுதி தவறான scope-ல் உள்ளது. இது http மட்டத்தில் இருக்க வேண்டும், எனவே அதை /etc/nginx/conf.d/-க்குக் கீழே உள்ள ஒரு கோப்பிலோ அல்லது server தொகுதிக்கு மேலோ வைக்கவும், ஒருபோதும் server-க்குள் வைக்க வேண்டாம்.
Caddy இதே வேலையை நான்கு வரிகளில் basic authentication மூலம் செய்கிறது, இது bearer token-ஐ விட browser client-க்கு மிகவும் பொருத்தமானது:
llm.example.com {
basic_auth {
apiuser PASTE_BCRYPT_HASH_HERE
}
reverse_proxy 127.0.0.1:11434
}அது எதிர்பார்க்கும் bcrypt hash-ஐ உருவாக்க caddy hash-password-ஐ இயக்கவும். ஒரு பெயரிடல் சிக்கல்: Caddy v2.8-க்கு முன்பு இந்த directive basicauth என்று இருந்தது, இப்போது basic_auth என்று உள்ளது, எனவே பழைய வழிகாட்டியிலிருந்து நகலெடுக்கப்பட்ட config ஏற்றப்படாது, மேலும் Caddy தான் அடையாளம் காணாத directive-ன் பெயரைத் தெரிவிக்கும்.
நீங்கள் எந்த proxy-ஐத் தேர்ந்தெடுத்தாலும், இது அனைவருக்கும் பகிரப்பட்ட ஒரு ரகசியமாகும். அதை வைத்திருக்கும் ஒவ்வொரு client-க்கும் ஒரே மாதிரியான அணுகல் இருக்கும், அதை நீக்குவது என்பது config-ஐத் திருத்தி, அனைத்து caller-களையும் ஒரே நேரத்தில் புதுப்பிப்பதைக் குறிக்கும்.
பாதுகாப்பு 3: ஒவ்வொரு client-க்கும் தனித்தனி keys வழங்கும் gateway
ஒன்றுக்கும் மேற்பட்ட நபர்கள் அல்லது applications இந்த model-ஐ அழைக்கும்போது, பகிரப்பட்ட (shared) token-ன் பயன்பாட்டு வரம்பு விரைவில் முடிந்துவிடும். எந்த client சுமையை (load) உருவாக்கியது என்பதை உங்களால் கண்டறிய முடியாது; மேலும், அனைவரின் இணைப்பையும் துண்டிக்காமல் ஒரு குறிப்பிட்ட client-ஐ மட்டும் உங்களால் தடுக்க முடியாது. proxy இருந்த இடத்தில் ஒரு gateway-ஐ அமைக்க வேண்டும். இது OpenAI-compatible API-ஐப் பின்பற்றி, ஒவ்வொரு client-க்கும் தனித்தனி key-களை வழங்கி, அந்தந்த key-ன் பயன்பாட்டைப் பதிவு செய்யும். சுயமாக இயங்கும் (self-hosted) LiteLLM gateway இதற்குச் சிறந்த தீர்வாகும். இது access control-உடன் சேர்த்து, ஒவ்வொரு key-க்கும் தனித்தனி வரவு-செலவுத் திட்டத்தையும் (budgets) மற்றும் request logs-ஐயும் வழங்குகிறது.
பாதுகாப்பு 1-ல் உள்ள விதி மாறாது. Ollama-வை 127.0.0.1-ல் bind செய்ய வேண்டும். gateway மட்டுமே அதனுடன் தொடர்பு கொள்ளும் ஒரே process ஆக இருக்க வேண்டும், மேலும் public listener-ஐக் கொண்ட ஒரே service-ஆகவும் gateway மட்டுமே இருக்க வேண்டும். port 11434 உலகளாவிய பயன்பாட்டிற்குத் திறந்திருக்கும் ஒரு server-ல் gateway-ஐ அமைப்பது பயனற்றது; ஏனெனில், அழைப்பாளர்கள் (callers) gateway-ஐத் தவிர்த்துவிட்டு நேரடியாக Ollama-வை அணுக முடியும்.
Firewall சிக்கல்: வெளியிடப்பட்ட container port UFW-ஐத் தவிர்க்கிறது
சரியான firewall அமைப்புகளைக் கொண்டிருந்தும், servers-ல் exposed instances ஏன் இருக்கின்றன என்பதற்கு இதுவே காரணம்.
UFW (uncomplicated firewall) தனது விதிகளை kernel-ன் INPUT chain-ல், filter table-ல் எழுதுகிறது. INPUT, host-க்கு வரும் பாக்கெட்டுகளைக் கையாளுகிறது. Docker-ன் -p flag, destination NAT (network address translation) விதியை nat table-ன் PREROUTING chain-ல் எழுதுகிறது. பாக்கெட் எங்கு செல்ல வேண்டும் என்று தீர்மானிக்கும் முன்பே, kernel இதைச் சரிபார்க்கிறது. Routing முடிவு எடுக்கும்போது, destination ஏற்கனவே container-ன் முகவரிக்கு மாற்றப்பட்டிருக்கும். எனவே, பாக்கெட் உள்ளூர் பயன்பாட்டிற்கு வராமல், நேரடியாக forward செய்யப்படுகிறது. இது INPUT-க்கு பதிலாக FORWARD வழியாகச் செல்கிறது. UFW-ன் INPUT விதிகள் கவனிக்கப்படுவதில்லை; இதனால் பாக்கெட் firewall-ஐத் தவிர்த்து வெளியேறுகிறது.
இதன் காரணமாகவே, பின்வரும் வரிசைமுறை 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 firewall செயல்பாட்டில் இருப்பதையும், default deny விதியையும் காட்டுகிறது. இரண்டு தகவல்களும் ஒரே நேரத்தில் சரியானவை, இதுவே பயனர்கள் தவறான தகவலை நம்புவதற்குக் காரணமாகிறது. இதற்கு காரணமான விதியை நீங்கள் இங்கே பார்க்கலாம்:
sudo iptables -t nat -L DOCKER -nஇதற்கான தீர்வு, publish flag-ல் ஒரு முகவரியைச் சேர்ப்பதுதான்:
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-க்குள் இல்லை, அவை ollama என்ற பெயரிடப்பட்ட volume-ல் உள்ளன.
இரண்டு பார்வைகளும் ஒத்துப்போவதை உறுதிப்படுத்தவும்:
docker port ollama
sudo ss -tlnp | grep 11434docker port ollama என்பது 11434/tcp -> 127.0.0.1:11434 என்று காட்ட வேண்டும். அது 0.0.0.0:11434 என்று காட்டினால், உங்கள் server இன்னும் exposed நிலையில் உள்ளது. இந்த நுட்பத்தை ஒருமுறை கற்றுக்கொண்டால், நீங்கள் வெளியிடும் அனைத்து container-களுக்கும் இது பொருந்தும்: Docker published ports ஏன் UFW-ஐத் தவிர்க்கின்றன என்ற கட்டுரை DOCKER-USER chain மற்றும் Docker restart-க்குப் பிறகும் நீடிக்கும் விதிகளை விளக்குகிறது. நீங்கள் இன்னும் host policy-ஐ உருவாக்குகிறீர்கள் என்றால், புதிய VPS-க்குத் தேவையான UFW விதிகள் என்ற கட்டுரை அடிப்படை அமைப்புகளை விளக்குகிறது. Rocky அல்லது AlmaLinux-ல் UFW கிடையாது, எனவே firewalld-ல் அதே அடிப்படை policy என்ற கட்டுரையைத் தொடங்குங்கள்.
இந்த process எந்த பயனர் கணக்கில் இயங்குகிறது
Linux install script ஒரு பிரத்யேக கணக்கை உருவாக்கி, அதன் கீழ் service-ஐ இயக்குகிறது:
useradd -r -s /bin/false -U -m -d /usr/share/ollama ollama/etc/systemd/system/ollama.service-ல் உள்ள unit, User=ollama மற்றும் Group=ollama ஆகியவற்றை அமைக்கிறது. அதை மாற்ற வேண்டாம். ஒரு terminal-ல் கையால் தொடங்கப்படும் ollama serve, நீங்கள் login செய்துள்ள பயனர் கணக்கிலேயே இயங்கும். அது root ஆக இருந்தால், authentication இல்லாத API, root உரிமையுடன் கோப்புகளை எழுதும். எது இயங்குகிறது என்பதைச் சரிபார்க்கவும்:
ps -o user= -C ollamaஇதற்கான விடை ollama என்று இருக்க வேண்டும். வேறு ஏதேனும் விடை வந்தால், unit-க்கு பதிலாகவோ அல்லது அதனுடன் இணைந்தோ கையால் தொடங்கப்பட்ட process ஒன்று இயங்குகிறது என்று அர்த்தம். நீங்கள் பின்னர் சேர்க்கும் ஒவ்வொரு daemon-க்கும் இதே தர்க்கம் பொருந்தும், மேலும் குறைந்தபட்ச உரிமைகள் கொண்ட பயனர்களாக சேவைகளை இயக்குதல் என்ற பகுதி இதை விரிவாக விளக்குகிறது.
Ollama API endpoint பாதுகாப்பாக உள்ளதா என்பதைச் சரிபார்ப்பது எப்படி
நீங்கள் எதை தேர்வு செய்தாலும், ஒரு சோதனை மட்டுமே அதை உறுதிப்படுத்தும். அந்தச் சோதனையை மற்றொரு கணினியிலிருந்து இயக்க வேண்டும்:
curl -m 5 http://YOUR_SERVER_IP:11434/api/version
curl -m 5 http://YOUR_SERVER_IP:11434/api/tagsஇவை இரண்டுமே time out ஆக வேண்டும் அல்லது நிராகரிக்கப்பட வேண்டும். நீங்கள் ஒரு proxy-ஐ உருவாக்கியிருந்தால், proxy hostname-ல் உள்ள அதே இரண்டு பாதைகளும், credentials இல்லாமல் 401-ஐயும், credentials உடன் உண்மையான JSON-ஐயும் வழங்க வேண்டும்.
பிறகு, access log-ஐ ஒருமுறை வாசிக்கவும். ஏனெனில், port திறந்திருந்தபோது யாராவது அதைக் கண்டறிந்தார்களா என்பதை அது தெரிவிக்கும்:
journalctl -u ollama --since "-30 days" | grep GIN | grep -v 127.0.0.1Ollama ஒவ்வொரு கோரிக்கைக்கும் ஒரு வரியை எழுதுவதுடன், client முகவரியையும் உள்ளடக்கும்:
[GIN] 2026/08/12 - 14:01:10 | 200 | 103.965898ms | 127.0.0.1 | POST "/api/generate"Ollama loopback-ல் இணைக்கப்பட்டவுடன், ஒவ்வொரு வரியிலும் 127.0.0.1 காட்டப்பட வேண்டும். ஏனெனில், அந்த முகவரியிலிருந்து மட்டுமே இணைப்பு வர முடியும். அந்த நெடுவரிசையில் ஒரு public முகவரி இருந்தால், அது வெளியிலிருந்து வந்த கோரிக்கை என்று அர்த்தம்; timestamp மூலம் அது எப்போது நடந்தது என்பதை அறியலாம். அந்த command-லிருந்து எந்த வெளியீடும் வராததே நீங்கள் எதிர்பார்க்கும் முடிவு. இது தொடர்பான model பகுதி உங்களுக்குப் புதியது என்றால், VPS-ல் Ollama-வை இயக்குவது என்ற பகுதி, நிறுவல், model அளவு மற்றும் எவை உண்மையில் load ஆகும் என்பதைத் தீர்மானிக்கும் memory வரம்புகள் குறித்து விளக்குகிறது.
FAQ
Ollama-வில் API key அல்லது password உள்ளதா?
இல்லை. நீங்கள் இயக்கும் server-ல் எந்தவிதமான authentication-ம் இல்லை. API-ஐ அணுக எந்த authentication-ம் தேவையில்லை என்று அதிகாரப்பூர்வ ஆவணங்கள் தெரிவிக்கின்றன. "Ollama API key" என்று அழைக்கப்படுபவை இரண்டும் வேறு நோக்கங்களுக்காகப் பயன்படுபவை. /usr/share/ollama/.ollama/-ல் உள்ள Ed25519 ஜோடி, உங்கள் கணினியை ollama.com-உடன் இணைத்து, models-ஐப் பதிவேற்றவும் (push) மற்றும் தனிப்பட்ட models-ஐப் பதிவிறக்கவும் (pull) உதவுகிறது. OLLAMA_API_KEY என்பது https://ollama.com/api-ல் உள்ள hosted API-க்கு உங்கள் client அனுப்பும் ஒரு credential ஆகும். உங்கள் சொந்த ollama serve இவை இரண்டையும் வாசிப்பதில்லை, எனவே network மூலமாகவோ அல்லது முன்னால் உள்ள ஒரு proxy மூலமாகவோதான் access control-ஐ நீங்கள் நிர்வகிக்க வேண்டும்.
என்னிடம் firewall இருந்தால் OLLAMA_HOST=0.0.0.0 பாதுகாப்பானதா?
அந்த server-ல் வேறு எந்த மென்பொருளும் firewall விதிகளை மாற்றாத வரை மட்டுமே இது பாதுகாப்பானது. 0.0.0.0 என்பது, listener பொதுவான interface-ல் இயங்குகிறது என்பதைக் குறிக்கிறது. அதை அணுக முடியாதபடி firewall மட்டுமே தடுக்கும் என்று நீங்கள் நம்புகிறீர்கள். Docker ஒரு port-ஐ வெளியிடும்போது (publish) அந்த நம்பிக்கை உடைகிறது. ஏனெனில், Docker சேர்க்கும் DNAT விதி nat அட்டவணையில், UFW இருக்கும் INPUT chain-க்கு முன்பே செயல்படுத்தப்படுகிறது. இதனால் packet நேரடியாக அனுப்பப்பட்டு, UFW-வால் அதைக் கவனிக்க முடியாது. 127.0.0.1 அல்லது ஒரு private tunnel முகவரியில் bind செய்வதன் மூலம், listener-ஐ பொதுவான interface-லிருந்து நீக்கலாம். இதனால் firewall-ல் தவறு நடந்தாலும், வெளிப்படையாக எதுவும் இருக்காது.
எனது Ollama port இணையத்திற்குத் திறந்திருக்கிறதா என்பதை எப்படிச் சரிபார்ப்பது?
Server-ல் sudo ss -tlnp | grep 11434 கட்டளையையும், வேறொரு கணினியிலிருந்து 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-யும் அணுகக்கூடிய நிலையில் உள்ளது என்று அர்த்தம். Server-லேயே curl மூலம் சோதிக்க வேண்டாம், ஏனெனில் loopback முகவரி bind செய்யப்பட்ட முகவரியைப் பொருட்படுத்தாமல் பதிலளிக்கும்.
Port-ஐ 11434-லிருந்து வேறு ஏதேனும் random port-க்கு மாற்றலாமா?
கூடாது, இதற்கான காரணத்தைப் புரிந்துகொள்வது அவசியம். ஒரு port-ஐ மாற்றுவது, அந்த ஒரு குறிப்பிட்ட port-ஐ ஸ்கேன் செய்வதை மட்டுமே தாமதப்படுத்தும். ஸ்கேனர்கள் முழு range-ஐயும் சோதிக்கும்; /api/tags-க்கு வரும் ஒரு request, எந்த port-ல் வந்தாலும் அது என்ன service என்பதை அடையாளம் காட்டிவிடும். Port-ஐ மாற்றுவது அனைத்து client-களின் default அமைப்புகளையும் பாதிக்கும், மேலும் உங்கள் setup-ஐப் புரிந்துகொள்வதையும் கடினமாக்கும். அதற்குப் பதிலாக loopback-ல் bind செய்யவும்; இது listener-ஐ இடமாற்றம் செய்வதற்குப் பதிலாக, பொதுவான அணுகலிலிருந்து நீக்கிவிடும்.
யாரோ எனது திறந்திருந்த Ollama-வை அணுகிவிட்டனர். நான் எதைச் சரிபார்க்க வேண்டும்?
முதலில் அதை 127.0.0.1-ல் bind செய்து service-ஐ restart செய்யவும், இதனால் விசாரணை தொடங்கும் முன்பே அணுகல் நிறுத்தப்படும். பிறகு, எந்தெந்த வெளி முகவரிகள், எந்த endpoint-களை, எப்போது அழைத்தன என்பதைப் பார்க்க journalctl -u ollama --since "-30 days" | grep GIN | grep -v 127.0.0.1-ஐ இயக்கவும். ollama list-ஐ நீங்கள் வைத்திருந்த models-உடன் ஒப்பிட்டுப் பார்க்கவும். /api/pull-ல் authentication இல்லாததால், நீங்கள் பதிவிறக்காத ஒரு model உங்கள் disk-ல் இருந்தால், அதுவே ஆதாரமாகும். df -h மூலம் disk-ல் எவ்வளவு இடம் உள்ளது என்பதைச் சரிபார்க்கவும். Ollama அதன் default log level-ல் prompt உரையைச் சேமிப்பதில்லை, எனவே யார் எதைக் கேட்டார்கள் என்ற பதிவு மட்டுமே இருக்கும், என்ன பதில் உருவாக்கப்பட்டது என்ற பதிவு இருக்காது.