SSD Nodes Learn 🎉 VPS $5.50/ماہ سے
تعلیمی Matt Connorتحریر: Matt Connor

Ollama API میں password کیوں نہیں ہے؟

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

Ollama API میں password نہیں ہے

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

سرکاری documentation میں یہ بات واضح طور پر لکھی ہے: "Ollama API تک مقامی طور پر http://localhost:11434 کے ذریعے رسائی حاصل کرتے وقت authentication درکار نہیں ہوتی۔" مقامی طور پر کا لفظ پورے security model کی بنیاد ہے۔ Ollama default طور پر 127.0.0.1 پر bind ہوتا ہے، اس لیے laptop پر loopback interface ہی access control فراہم کرتا ہے۔ اس listener کو public address پر منتقل کرنے سے access control ختم ہو جاتا ہے، کیونکہ اس کی جگہ کوئی متبادل protection موجود نہیں ہوتی۔

اسی لیے VPS (virtual private server) پر یہ معاملہ اہم ہے۔ Default configuration محفوظ ہوتی ہے۔ زیادہ تر لوگ جو پہلی تبدیلی کرتے ہیں، یعنی دوسرے machine کو model استعمال کرنے دینے کے لیے listener کھولتے ہیں، وہی تبدیلی تمام protections بیک وقت ختم کر دیتی ہے۔

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

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

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 کرتا ہے۔ یہی 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 پر بناتے ہیں۔ آپ کا client hosted API کو https://ollama.com/api پر call کرتے وقت اسے Authorization: Bearer $OLLAMA_API_KEY کے طور پر بھیجتا ہے۔ یہ ان کی service کے لیے credential ہے، جسے آپ client کی حیثیت سے استعمال کرتے ہیں۔ آپ کا اپنا ollama serve اسے کبھی read نہیں کرتا۔ اپنے VPS پر OLLAMA_API_KEY set کرنے سے آپ کے VPS پر password عائد نہیں ہوتا۔

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

دیکھیں کہ آپ کا سرور اس وقت کن 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))

باہر سے accessible نتیجے میں ہر 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 شامل ہیں، public address بھی۔ *:11434 اور [::]:11434 کا مطلب بھی یہی ہے، لیکن ان میں IPv6 شامل ہوتا ہے۔

اب باہر سے تصدیق کریں۔ یہ command اپنے 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 ہر درخواست کرنے والے کے لیے accessible ہے۔ سرور پر خود curl سے testing کرنے سے کچھ ثابت نہیں ہوتا، کیونکہ loopback ہمیشہ جواب دیتا ہے۔

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

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 لکھا جاتا ہے۔ اسے 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 کھولتا ہے اور وہاں آنے والی ہر چیز کو 127.0.0.1:11434 تک بھیجتا ہے، جیسا کہ وہ server کی طرف سے نظر آتی ہے۔ -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 ہو جائے لیکن اس کے ذریعے empty reply ملے تو اس کا مطلب ہے کہ SSH کام کر رہا ہے اور server side پر 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 صرف ایسے interface پر موجود ہوگا جس میں شامل ہونے کے لیے key درکار ہے۔ یہ firewall کی غلطی کے باوجود بھی محفوظ رہتا ہے، کیونکہ کوئی rule اگر اتفاقاً پوری دنیا کو اجازت دے بھی دے تو public interface ایسے listener کو expose نہیں کر سکتا جو اس پر موجود ہی نہ ہو۔

دفاع 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 روکتی ہے جس کا آپ کو بصورت دیگر سامنا ہوتا۔

if کو nginx میں 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 دوسرا control ہے، جو اس browser client کے لیے مخصوص origin کی اجازت دیتا ہے جسے اس کی ضرورت ہو۔

proxy_buffering off; اہم ہے کیونکہ Ollama اپنا response token بہ token stream کرتا ہے۔ buffering فعال ہونے پر nginx اس stream کو روک کر آخر میں ایک ہی حصے میں بھیجتا ہے، اس لیے پوری generation کے دوران آپ کا client frozen دکھائی دیتا ہے۔

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 نے اسے ترک کر دیا۔

دونوں paths کو reload اور test کریں:

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 کرنا چاہیے۔ دوسری command کو آپ کی 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 چلائیں۔ naming کے ایک مسئلے پر توجہ دیں: Caddy v2.8 سے پہلے directive basicauth تھی، اور اب basic_auth ہے۔ اس لیے پرانی guide سے copy کی گئی config load نہیں ہوتی اور Caddy اس directive کا نام بتاتا ہے جسے وہ شناخت نہیں کر سکا۔

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

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

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

defence 1 کا اصول تبدیل نہیں ہوتا۔ Ollama 127.0.0.1 پر bind ہوتا ہے، gateway ہی اس سے بات کرنے والا واحد process ہوتا ہے، اور gateway ہی public listener رکھنے والی واحد service ہوتی ہے۔ اگر کسی machine پر port 11434 اب بھی پوری دنیا کے لیے کھلا ہو تو gateway محض دکھاوا ہے، کیونکہ callers آسانی سے اس کے راستے سے گزر کر براہ راست Ollama تک پہنچ سکتے ہیں۔

فائر وال کا مسئلہ: published container port، UFW کو bypass کرتا ہے

اسی وجہ سے ان سرورز پر 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 سے replace ہو چکا ہوتا ہے۔ اس لیے packet locally 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 ظاہر کرتا ہے۔ دونوں readings ایک ہی وقت میں درست ہیں۔ یہی وجہ ہے کہ لوگ غلط reading پر اعتماد کر لیتے ہیں۔ اس rule کو دیکھنے کے لیے یہ command چلائیں:

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

عمل کس account کے تحت چل رہا ہے

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 اسی account کے تحت چلتا ہے جس سے آپ نے login کیا ہے۔ اگر وہ account root ہے تو unauthenticated API، files کو root کے طور پر لکھ رہی ہے۔ یہ چیک کریں:

ps -o user= -C ollama

جواب ollama ہونا چاہیے۔ کوئی بھی دوسرا جواب اس بات کی نشاندہی کرتا ہے کہ ہاتھ سے شروع کیا گیا process unit کے ساتھ ساتھ یا اس کے بجائے چل رہا ہے۔ یہی اصول بعد میں شامل کیے جانے والے ہر daemon پر لاگو ہوتا ہے، اور services کو least-privilege 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 کا وقت ختم ہونا چاہیے یا انہیں 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 کے لیے ایک line لکھتا ہے اور client address شامل کرتا ہے:

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

Ollama کے loopback پر bind ہونے کے بعد ہر line میں 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" کہا جاتا ہے، وہ اس server کے بجائے دوسرے مقاصد کے لیے ہیں۔ /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 جو DNAT rule nat table میں شامل کرتا ہے اسے اس packet کے INPUT chain تک پہنچنے سے پہلے evaluate کیا جاتا ہے، جہاں 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 کے مطابق جواب دیتا ہے جو استعمال ہو رہا ہو۔

کیا میں port کو 11434 سے بدل کر کوئی random port رکھ سکتا ہوں؟

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

کسی نے میرے کھلے ہوئے 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 سے خالی جگہ check کریں۔ Ollama default log level پر prompt text record نہیں کرتا، اس لیے آپ کے پاس یہ record ہوتا ہے کہ کس نے کس model کے لیے request کی، لیکن یہ record نہیں ہوتا کہ کیا generate کیا گیا۔

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