تحریر: Matt Connor 2026-08-15 · اپ ڈیٹ شدہ 2026-08-29

Ollama API پر پاس ورڈ نہیں؟ 3 محفوظ حل

Q: میں کیسے جانچوں کہ میرا 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 تک رسائی ممکن ہے۔ Server پر curl سے کبھی test نہ کریں، کیونکہ loopback bind address کی موجودہ configuration کے مطابق جواب دیتا ہے۔

Q: کسی نے میرے open Ollama تک رسائی حاصل کی۔ مجھے کیا جانچنا چاہیے؟

پہلے اسے 127.0.0.1 پر bind کریں اور service restart کریں، تاکہ investigation شروع کرنے سے پہلے exposure رک جائے۔ پھر journalctl -u ollama --since "-30 days" | grep GIN | grep -v 127.0.0.1 چلائیں تاکہ معلوم ہو سکے کہ کن بیرونی addresses نے کن endpoints کو کب call کیا۔ ollama list کا ان models کے ساتھ تقابل کریں جنہیں آپ نے رکھنا مقصود تھا، کیونکہ /api/pull میں authentication نہیں ہوتی، اور ایسا model جسے آپ نے pull نہیں کیا، disk usage بھی ہے اور evidence بھی۔ df -h سے free space دیکھیں۔ Ollama default log level پر prompt text record نہیں کرتا، اس لیے آپ کے پاس یہ record ہوتا ہے کہ کس نے کس model کے لیے request کی، نہ کہ کیا generate ہوا۔

Ollama API میں authentication نہیں ہوتی۔ port 11434 تک پہنچنے والا ہر شخص models چلا، download اور delete کر سکتا ہے۔ مسئلے کے 3 حل ترتیب سے جانیں۔

Ollama API پر پاس ورڈ نہیں ہوتا

Ollama API میں authentication نہیں ہے۔ آپ کے چلائے ہوئے server میں کہیں بھی user، password، key check یا allowlist موجود نہیں ہے۔ جو بھی port 11434 سے TCP connection قائم کر سکتا ہے، وہ آپ کے models کی فہرست دیکھ سکتا ہے، انہیں چلا سکتا ہے، نئے models download کر سکتا ہے اور موجودہ models delete کر سکتا ہے۔

سرکاری documentation میں یہ بات واضح طور پر بیان کی گئی ہے: "http://localhost:11434 کے ذریعے مقامی طور پر Ollama API تک رسائی کے لیے authentication درکار نہیں ہے۔" سکیورٹی ماڈل مکمل طور پر مقامی طور پر کی شرط پر مبنی ہے۔ 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 کھول دیتے ہیں۔ یہی تبدیلی تمام حفاظتی اقدامات ایک ساتھ ختم کر دیتی ہے۔

کھلے port 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 چلاتا ہے۔ ایسے plan میں جس میں fair-use CPU allowance ہو، مسلسل load کا مطلب ہے کہ کوئی اجنبی آپ کا allowance خرچ کر رہا ہے۔ جب requests بھیجنے والا صرف آپ نہ ہوں تو VPS پر AI workload کے اخراجات قابو میں رکھنا کہیں زیادہ مشکل ہو جاتا ہے۔
/api/pull آپ کی disk پر لکھتا ہے۔ ہر model کا حجم 2 سے 40 gigabytes تک ہوتا ہے۔ بار بار pull کرنے سے volume بھر جاتا ہے، اور full disk اس machine پر Ollama کے علاوہ ہر دوسری service کو بھی متاثر کرتی ہے۔
requests آپ کے process کے اندر پہنچتی ہیں اور log ہو جاتی ہیں۔ default log level پر Ollama صرف metadata record کرتا ہے، اس لیے آپ کو endpoint، status، latency اور client address ملتے ہیں، prompt text نہیں۔ پھر بھی یہ record موجود رہتا ہے کہ آپ کا server کس نے اور کس مقصد کے لیے استعمال کیا، اور یہ آپ کے journal میں محفوظ ہوتا ہے، حالانکہ آپ نے اسے collect کرنے کا انتخاب نہیں کیا۔
/api/delete models کو حذف کرتا ہے۔ انہیں واپس حاصل کرنے کے لیے انہیں اپنی bandwidth استعمال کرتے ہوئے دوبارہ download کرنا پڑتا ہے۔

اس میں سے کسی کام کے لیے exploit درکار نہیں۔ یہ documented API ہے جو بالکل اسی طرح کام کر رہی ہے جیسے اسے design کیا گیا ہے۔

Ed25519 key رسائی کا کنٹرول نہیں ہے

"^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 بیرونی authentication کے لیے ہے۔ ollama signin public حصے کو آپ کے ollama.com account کے ساتھ register کرتا ہے۔ یہی key آپ کو registry میں model push کرنے یا private model pull کرنے کی اجازت دیتی ہے۔ یہ ollama.com کے سامنے آپ کی machine کی شناخت ثابت کرتی ہے۔ یہ آپ کی machine سے connect ہونے والے clients سے کچھ نہیں مانگتی۔ اسے delete کرنے، rotate کرنے یا کبھی نہ بنانے سے اس بات پر کوئی اثر نہیں پڑتا کہ آپ کی API کو کون call کر سکتا ہے۔

دوسری چیز OLLAMA_API_KEY ہے۔ اس variable میں وہ key ہوتی ہے جو آپ https://ollama.com/settings/keys پر بناتے ہیں۔ Hosted API کو https://ollama.com/api پر call کرتے وقت آپ کا client اسے Authorization: Bearer $OLLAMA_API_KEY کے طور پر بھیجتا ہے۔ یہ ان کی service کے لیے credential ہے، جسے آپ client کی حیثیت سے استعمال کرتے ہیں۔ آپ کا اپنا ollama serve اسے کبھی read نہیں کرتا۔ اپنے VPS پر OLLAMA_API_KEY set کرنے سے آپ کے VPS پر password فعال نہیں ہوتا۔

اس لیے کوئی ایسی setting موجود نہیں جسے فعال کیا جائے۔ ذیل کے تینوں دفاعی طریقے ایک ہی اصول پر کام کرتے ہیں: port کو ناقابلِ رسائی رکھیں، اور اس کے سامنے ایسی چیز رکھیں جو واقعی access check کرے۔

اس وقت دیکھیں کہ آپ کا server کن interfaces پر listening کر رہا ہے

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))

exposed نتیجے میں ہر interface درج ہوتا ہے:

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

0.0.0.0 کا مطلب server پر موجود تمام IPv4 addresses ہیں، جن میں public 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 مطلوبہ جواب ہے، اور curl: (7) Failed to connect ... Connection refused بھی۔ ایسا JSON object جس میں version field ہو، اس کا مطلب ہے کہ پوری API ہر درخواست کرنے والے کے لیے قابل رسائی ہے۔ خود server پر curl سے testing کچھ ثابت نہیں کرتی، کیونکہ loopback ہمیشہ جواب دیتا ہے۔

Exposure عموماً دو طریقوں میں سے ایک سے پیدا ہوتی ہے۔ پہلا طریقہ دانستہ edit ہے، کیونکہ کسی کو model تک دوسری machine سے رسائی درکار تھی:

sudo systemctl edit ollama.service

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

یہ ایک سطر ہی مکمل exposure ہے۔ دوسرا طریقہ Docker ہے، اور اس میں آپ کو کسی چیز کو edit کرنے کی ضرورت نہیں پڑتی۔ اس کے لیے ذیل میں الگ section موجود ہے۔

دفاع 1: اسے localhost پر رکھیں اور tunnel کے ذریعے رسائی حاصل کریں

سب سے پہلے یہی طریقہ اختیار کریں۔ اس کے لیے نئے software کی ضرورت نہیں ہوتی اور ایسا کوئی credential بھی نہیں بنتا جو leak ہو سکے۔ یہ 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 لکھا جائے گا۔ اسے apply کریں اور تصدیق کریں:

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 files کو ان کے paths سمیت فہرست میں دیکھنے کے لیے systemctl cat ollama.service چلائیں، پھر پرانا file حذف کریں۔

اپنے laptop سے model استعمال کرنے کے لیے port کو SSH کے ذریعے 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

آپ کو دو failures کا سامنا ہو سکتا ہے۔ 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 ہو جائے لیکن جواب خالی ہو تو اس کا مطلب ہے کہ SSH کام کر رہا ہے اور Ollama server کے جانب 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 صرف ایسے interface پر موجود ہوگا جس میں شامل ہونے کے لیے key درکار ہے۔ یہ firewall کی غلطی کے باوجود بھی محفوظ رہتا ہے، کیونکہ ایسا rule جو غلطی سے پوری دنیا کو اجازت دے دے، پھر بھی ایسے listener کو expose نہیں کر سکتا جو public interface پر موجود ہی نہیں ہے۔

دفاع 2: bearer token کی جانچ کرنے والا reverse proxy

جب public internet پر موجود کسی سسٹم کو model کو call کرنا ہو تو Ollama کو loopback پر رکھیں اور اس کے سامنے ایک proxy لگائیں۔ proxy TLS (transport layer security) کو terminate کرتا ہے اور درست header کے بغیر آنے والی requests مسترد کر دیتا ہے۔ Ollama اب بھی صرف 127.0.0.1 سے connections قبول کرتا ہے، اس لیے اندر جانے کا واحد راستہ proxy ہے۔

پہلے ایک حقیقی token بنائیں۔ اسے ہاتھ سے نہ گھڑیں:

openssl rand -base64 36

یہ nginx site token کی جانچ کرتی ہے:

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

اس میں پانچ lines اصل کام کرتی ہیں، اور ہر line ایسی failure کو روکتی ہے جس کا آپ کو بصورت دیگر سامنا ہوتا۔

nginx میں if کو location block کے اندر استعمال کرنا عموماً خراب خیال ہے، لیکن بالکل return body ان دو forms میں سے ایک ہے جو قابل پیش گوئی انداز میں کام کرتی ہیں، اس لیے یہ استعمال محفوظ ہے۔

location = /api/pull exact match ہے، اور nginx exact matches کو location / prefix سے زیادہ ترجیح دیتا ہے، اس لیے ان تین endpoints کو token پر غور کرنے سے پہلے ہی مسترد کر دیا جاتا ہے۔ درست token صرف inference کی اجازت دیتا ہے، آپ کی disk بھرنے کی نہیں۔

proxy_set_header Host 127.0.0.1:11434; اہم ہے کیونکہ Ollama آنے والے Host اور Origin headers کا معائنہ کرتا ہے۔ proxy کا public hostname براہ راست آگے بھیجنے سے ایسا 403 Forbidden بن سکتا ہے جو nginx کے بجائے Ollama سے آیا ہو، اور اس کی debugging مشکل ہو جاتی ہے۔ OLLAMA_ORIGINS دوسرا اختیار ہے، جب browser client کے لیے مخصوص origin کی اجازت درکار ہو۔

proxy_buffering off; اہم ہے کیونکہ Ollama اپنا response token بہ 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 کریں اور دونوں paths کی جانچ کریں:

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 print کرنا چاہیے۔ دوسری کو آپ کی model list print کرنی چاہیے۔ اگر پہلی command بھی model list واپس کرے تو map block غلط scope میں ہے۔ یہ http level پر ہونا چاہیے، اس لیے اسے /etc/nginx/conf.d/ کے اندر کسی file میں یا server block کے اوپر رکھیں، server کے اندر ہرگز نہیں۔

Caddy یہی کام basic authentication کے ذریعے چار lines میں کرتا ہے، جو 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 چلائیں۔ نام سے متعلق ایک اہم فرق ہے: Caddy v2.8 سے پہلے directive basicauth تھی، جبکہ اب basic_auth ہے۔ اس لیے پرانی guide سے copy کی گئی config load ہونے سے انکار کر دیتی ہے، اور Caddy اس directive کا نام بتاتا ہے جسے وہ پہچان نہیں سکا۔

آپ جو بھی proxy منتخب کریں، یہ سب clients کے لیے ایک ہی shared secret ہے۔ جس client کے پاس یہ موجود ہو اسے یکساں access حاصل ہوتی ہے، اور اسے revoke کرنے کے لیے config میں ترمیم کر کے تمام callers کو بیک وقت update کرنا پڑتا ہے۔

دفاع 3: ہر کلائنٹ کے لیے keys جاری کرنے والا gateway

جب ایک سے زیادہ افراد یا ایپلی کیشنز model کو call کرتی ہیں تو shared token کافی نہیں رہتا۔ آپ یہ معلوم نہیں کر سکتے کہ load کس client نے پیدا کیا، اور ایک client کو باقی سب کی رسائی بند کیے بغیر الگ سے روک نہیں سکتے۔ gateway اس جگہ کام کرتا ہے جہاں proxy موجود تھا، وہی OpenAI-compatible API استعمال کرتا ہے، ہر client کے لیے الگ key جاری کرتا ہے، اور ریکارڈ رکھتا ہے کہ ہر key نے کیا استعمال کیا۔ Self-hosted LiteLLM gateway عام حل ہے۔ یہ access control کے ساتھ ہر key کے لیے budgets اور request logs بھی فراہم کرتا ہے۔

دفاع 1 کا اصول تبدیل نہیں ہوتا۔ Ollama 127.0.0.1 پر bind ہوتا ہے، اس سے رابطہ کرنے والا واحد process gateway ہوتا ہے، اور public listener رکھنے والی واحد service بھی gateway ہوتی ہے۔ ایسے server پر gateway محض دکھاوا ہے جہاں port 11434 اب بھی پوری دنیا کے لیے کھلا ہو، کیونکہ callers آسانی سے gateway کو bypass کر سکتے ہیں۔

فائر وال کی الجھن: شائع کیا گیا container port UFW کو bypass کرتا ہے

اسی وجہ سے ان servers پر exposed instances موجود ہوتے ہیں جن کے مالکان نے firewall درست طور پر configure کیا ہوتا ہے۔

UFW (uncomplicated firewall) اپنے rules kernel کے filter table کی INPUT chain میں لکھتا ہے، اور INPUT ان packets کو handle کرتا ہے جن کا مقصد خود host ہو۔ Docker کا -p flag nat table کی PREROUTING chain میں destination NAT (network address translation) rule لکھتا ہے۔ Kernel یہ rule اس فیصلے سے پہلے evaluate کرتا ہے کہ packet کہاں جائے گا۔ Routing decision تک پہنچنے سے پہلے destination کو container کے address سے تبدیل کیا جا چکا ہوتا ہے۔ اس لیے packet مقامی طور پر deliver ہونے کے بجائے forward ہو جاتا ہے اور INPUT کے بجائے FORWARD سے گزرتا ہے۔ UFW کے INPUT rules کبھی consult نہیں ہوتے، اس لیے packet firewall کے ذریعے گزرنے کے بجائے اسے bypass کر جاتا ہے۔

اسی وجہ سے یہ sequence port 11434 کو internet کے لیے کھلا چھوڑ دیتی ہے:

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 کے ساتھ active report کرتا ہے۔ دونوں readings بیک وقت درست ہیں۔ یہی وجہ ہے کہ لوگ غلط reading پر اعتماد کرتے ہیں۔ آپ وہ 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 side loopback سے bind ہو جاتا ہے۔ اس طرح آپ کا SSH tunnel اور reverse proxy اب بھی اس تک پہنچ سکتے ہیں، لیکن internet نہیں پہنچ سکتا۔ یہاں container کو دوبارہ بنانا محفوظ ہے، کیونکہ models named ollama volume میں موجود ہیں، container کے اندر نہیں۔

تصدیق کریں کہ دونوں 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 کرے تو server اب بھی exposed ہے۔ اس mechanism کو ایک بار سمجھ لیں، پھر یہ ہر اس container پر لاگو ہوگا جسے آپ publish کریں گے: Docker کے published ports UFW کو bypass کیوں کرتے ہیں میں DOCKER-USER chain اور ان rules کی وضاحت ہے جو Docker restart کے بعد بھی برقرار رہتے ہیں۔ اگر آپ ابھی host policy خود بنا رہے ہیں تو نئے VPS کے لیے مطلوب UFW rules اس بنیادی policy کی وضاحت کرتا ہے جس پر یہ setup قائم ہے۔ Rocky یا AlmaLinux پر configure کرنے کے لیے UFW موجود نہیں ہوتا، اس لیے firewalld میں لکھی گئی یہی بنیادی policy سے آغاز کریں۔

پروسیس کس اکاؤنٹ کے تحت چل رہا ہے

Linux install script ایک dedicated account بناتی ہے اور service اسی کے تحت چلاتی ہے:

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

/etc/systemd/system/ollama.service میں موجود unit پھر User=ollama اور Group=ollama متعین کرتی ہے۔ اسے تبدیل نہ کریں۔ ٹرمینل میں ہاتھ سے شروع کیا گیا فوری ollama serve اسی user کے تحت چلتا ہے جس سے آپ نے login کیا ہو۔ اگر وہ root ہے تو unauthenticated API، root کے طور پر files لکھ رہی ہے۔ معلوم کریں کہ یہ کس account کے تحت چل رہا ہے:

ps -o user= -C ollama

جواب ollama ہونا چاہیے۔ اس کے علاوہ کوئی بھی نتیجہ ظاہر کرتا ہے کہ ہاتھ سے شروع کیا گیا process unit کے ساتھ ساتھ یا اس کے بجائے چل رہا ہے۔ یہی اصول بعد میں شامل کیے جانے والے ہر daemon پر لاگو ہوتا ہے، اور services کو کم سے کم مراعات رکھنے والے users کے تحت چلانا اس مسئلے کو درست طور پر حل کرتا ہے۔

Ollama API endpoint کا محفوظ ہونے کی جانچ کیسے کریں

آپ نے جو بھی طریقہ اختیار کیا ہو، ایک ٹیسٹ فیصلہ کن ہوتا ہے، اور اسے کسی دوسرے machine سے چلانا ضروری ہے:

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

دونوں requests کا time out ہونا یا refuse ہونا چاہیے۔ اگر آپ نے proxy بنایا ہے تو proxy hostname پر یہی دو paths credentials کے بغیر 401 واپس کریں، اور credentials کے ساتھ حقیقی JSON واپس کریں۔

پھر access log ایک بار پڑھیں، کیونکہ اس سے معلوم ہوتا ہے کہ port کھلا ہونے کے دوران کسی نے اسے تلاش کیا یا نہیں:

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 نہ آنا ہی مطلوبہ نتیجہ ہے۔ اگر model سے متعلق یہ طریقہ آپ کے لیے نیا ہے تو VPS پر Ollama چلانا installation، model sizing اور ان memory limits کی وضاحت کرتا ہے جو طے کرتی ہیں کہ حقیقت میں کیا load ہو سکے گا۔

FAQ

کیا Ollama کے پاس API key یا password ہوتا ہے؟

نہیں۔ آپ جو server چلاتے ہیں اس میں کسی بھی قسم کی authentication نہیں ہوتی، اور official documentation کے مطابق API تک رسائی کے لیے authentication درکار نہیں۔ "Ollama API key" کہی جانے والی دونوں چیزیں دراصل اس کے برعکس سمت میں کام کرتی ہیں۔ /usr/share/ollama/.ollama/ میں موجود Ed25519 جوڑا آپ کی machine کی شناخت ollama.com کے سامنے ثابت کرتا ہے، تاکہ آپ models push اور private models pull کر سکیں۔ OLLAMA_API_KEY وہ credential ہے جو آپ کا client https://ollama.com/api پر موجود hosted API کو بھیجتا ہے۔ آپ کا اپنا ollama serve ان دونوں میں سے کوئی چیز نہیں پڑھتا، اس لیے access control network یا سامنے موجود proxy سے فراہم کرنا ہوگا۔

اگر میرے پاس firewall ہو تو کیا `OLLAMA_HOST=0.0.0.0` محفوظ ہے؟

صرف اس وقت تک جب اس box پر کوئی دوسری چیز firewall rules نہ لکھ رہی ہو۔ 0.0.0.0 کا مطلب ہے کہ listener واقعی public interface پر موجود ہے، اور آپ اسے ناقابل رسائی رکھنے کے لیے صرف firewall پر اعتماد کر رہے ہیں۔ Docker کے ذریعے port publish ہوتے ہی یہ اعتماد ختم ہو جاتا ہے، کیونکہ Docker کی جانب سے nat table میں شامل کیا گیا DNAT rule اس وقت evaluate ہوتا ہے جب packet INPUT chain تک پہنچے، جہاں UFW کام کرتا ہے۔ یوں packet forward ہو جاتا ہے اور UFW اسے دیکھ ہی نہیں پاتا۔ 127.0.0.1 یا private tunnel address پر bind کرنے سے listener public interface سے ہٹ جاتا ہے، اس لیے firewall کی غلطی سے expose ہونے کے لیے کچھ باقی نہیں رہتا۔

میں کیسے جانچوں کہ میرا 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 تک رسائی ممکن ہے۔ Server پر curl سے کبھی test نہ کریں، کیونکہ loopback bind address کی موجودہ configuration کے مطابق جواب دیتا ہے۔

کیا میں port کو 11434 سے کسی random port پر منتقل کر سکتا ہوں؟

نہیں، اور اس کی وجہ واضح کرنا ضروری ہے۔ مختلف port صرف ایک single port کے scan کو سست کرتا ہے۔ Scanners پوری range کو scan کرتے ہیں، اور /api/tags کو بھیجی گئی ایک request service کی شناخت کر دیتی ہے، چاہے وہ کسی بھی port پر موصول ہوئی ہو۔ Port منتقل کرنے سے ہر client کی default configuration بھی متاثر ہوتی ہے اور بعد میں اپنی setup کو سمجھنا زیادہ مشکل ہو جاتا ہے۔ اس کے بجائے loopback پر bind کریں، جس سے listener منتقل نہیں بلکہ ختم ہو جاتا ہے۔

کسی نے میرے open Ollama تک رسائی حاصل کی۔ مجھے کیا جانچنا چاہیے؟

پہلے اسے 127.0.0.1 پر bind کریں اور service restart کریں، تاکہ investigation شروع کرنے سے پہلے exposure رک جائے۔ پھر journalctl -u ollama --since "-30 days" | grep GIN | grep -v 127.0.0.1 چلائیں تاکہ معلوم ہو سکے کہ کن بیرونی addresses نے کن endpoints کو کب call کیا۔ ollama list کا ان models کے ساتھ تقابل کریں جنہیں آپ نے رکھنا مقصود تھا، کیونکہ /api/pull میں authentication نہیں ہوتی، اور ایسا model جسے آپ نے pull نہیں کیا، disk usage بھی ہے اور evidence بھی۔ df -h سے free space دیکھیں۔ Ollama default log level پر prompt text record نہیں کرتا، اس لیے آپ کے پاس یہ record ہوتا ہے کہ کس نے کس model کے لیے request کی، نہ کہ کیا generate ہوا۔

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

Ollama API پر پاس ورڈ نہیں ہوتا

کھلے port 11434 سے کیا ظاہر ہوتا ہے

Ed25519 key رسائی کا کنٹرول نہیں ہے

اس وقت دیکھیں کہ آپ کا server کن interfaces پر listening کر رہا ہے

دفاع 1: اسے localhost پر رکھیں اور tunnel کے ذریعے رسائی حاصل کریں

دفاع 2: bearer token کی جانچ کرنے والا reverse proxy

دفاع 3: ہر کلائنٹ کے لیے keys جاری کرنے والا gateway

فائر وال کی الجھن: شائع کیا گیا container port UFW کو bypass کرتا ہے

پروسیس کس اکاؤنٹ کے تحت چل رہا ہے

Ollama API endpoint کا محفوظ ہونے کی جانچ کیسے کریں

FAQ

کیا Ollama کے پاس API key یا password ہوتا ہے؟

اگر میرے پاس firewall ہو تو کیا OLLAMA_HOST=0.0.0.0 محفوظ ہے؟

میں کیسے جانچوں کہ میرا Ollama port internet کے لیے کھلا ہے؟

کیا میں port کو 11434 سے کسی random port پر منتقل کر سکتا ہوں؟

کسی نے میرے open Ollama تک رسائی حاصل کی۔ مجھے کیا جانچنا چاہیے؟

اگر میرے پاس firewall ہو تو کیا `OLLAMA_HOST=0.0.0.0` محفوظ ہے؟