Linux میں سروسز غیر مرتبہ یوزر کے طور پر چلائیں

ہر چیز کو root کے طور پر کیوں نہ چلائیں

root مشین پر کچھ بھی کر سکتا ہے: ہر فائل پڑھ سکتا ہے، کوئی بھی ترتیب تبدیل کر سکتا ہے، پورا سسٹم ڈیلیٹ کر سکتا ہے۔ جب آپ کوئی سروس root کے طور پر چلاتے ہیں، تو آپ یہ ساری طاقت اس سروس کے حوالے کر دیتے ہیں۔ اگر سروس میں کوئی خامی ہے جسے حملہ آور استعمال کر سکتا ہے، تو انہیں صرف سروس نہیں ملتی، انہیں root مل جاتا ہے، اور root ہی پورا سرور ہوتا ہے۔ غیر مرتبہ یوزر کے طور پر چلانا نقصان کو محدود رکھتا ہے۔ کسی ایسی سروس میں خامی جو محدود اکاؤنٹ کے طور پر چلتی ہے، حملہ آور کو صرف وہی دے سکتی ہے جس تک وہ اکاؤنٹ رسائی حاصل کر سکتا ہے، جو تقریباً کچھ نہیں ہونا چاہیے۔

یہ کم سے کم مراعات کا اصول ہے: سسٹم کے ہر حصے کو بالکل وہی رسائی دیں جو اسے اپنا کام کرنے کے لیے درکار ہو، اور اس سے زیادہ کچھ نہیں۔ یہ کسی سمجھوتے کے دائرہ کار کو محدود کرنے کے لیے سب سے مؤثر عادت ہے، اور ایک جدید سرور پر اسے اپنانے کی قیمت تقریباً کچھ نہیں ہے۔

ہر سروس کے لیے ایک مخصوص اکاؤنٹ

کلاسیکی طریقہ ہر سروس کے لیے ایک الگ سسٹم یوزر بنانا ہے، جو صرف اس سروس کی فائلوں کا مالک ہو اور لاگ ان نہ ہو سکے۔ کسی ویب ایپ کے لیے سسٹم اکاؤنٹ کچھ اس طرح نظر آ سکتا ہے:

sudo useradd --system --no-create-home --shell /usr/sbin/nologin appsvc

ہر flag اہمیت رکھتا ہے۔ --system اسے سروس اکاؤنٹ بناتا ہے، انسانی لاگ ان نہیں۔ --no-create-home ایک ہوم ڈائریکٹری سے گزر جاتا ہے جس کی اسے ضرورت نہیں۔ --shell /usr/sbin/nologin کا مطلب ہے کہ اگر حملہ آور کسی طرح اکاؤنٹ پر قابض ہو بھی جائے، تو وہ اس کے ساتھ شیل نہیں کھول سکتے۔ اکاؤنٹ صرف ایک پروسے اور اس کی فائلوں کی ملکیت کے لیے موجود ہے۔

پھر اس یوزر کو صرف وہ فائلیں دیں جن کی اسے ضرورت ہے، اور اس سے زیادہ کچھ نہیں:

sudo chown -R appsvc:appsvc /opt/myapp

اب سروس اپنی ڈائریکٹری میں پڑھتی اور لکھتی ہے اور ڈسک پر کہیں اور اس کا کوئی کام نہیں ہے۔ اگر اسے کبھی استعمال کیا جائے، تو فائلیں جو حملہ آور تبدیل کر سکتا ہے وہ /opt/myapp تک محدود ہیں؛ اکاؤنٹ اب بھی world-readable کچھ بھی پڑھ سکتا ہے، لیکن یہ سسٹم کے باقی حصوں میں ترمیم نہیں کر سکتا۔

systemd کو اسے اس یوزر کے طور پر چلنے دیں

اکاؤنٹ موجود ہونے کے بعد، systemd کو بتائیں کہ سروس کو اس کے طور پر چلائے۔ یونٹ فائل میں، ایک لائن یہ کام کرتی ہے:

[Service]
ExecStart=/opt/myapp/bin/server
User=appsvc
Group=appsvc

User=appsvc کا مطلب ہے کہ پروسس root کی بجائے اس اکاؤنٹ کی محدود مراعات کے ساتھ شروع ہوتا ہے۔ یہ systemd کے تحت ایپلیکیشن چلانے کا عام، آزمودہ طریقہ ہے، اور ہر اس سروس کے لیے ایسا کرنا بہترین ہے جس کے لیے آپ یونٹ لکھتے ہیں۔

یا DynamicUser کے ساتھ اکاؤنٹ کو مکمل طور پر چھوڑ دیں

systemd ایک قدم آگے بڑھ کر آپ کے لیے ایک عارضی یوزر بنا سکتا ہے، جو صرف سروس چلنے کے دوران موجود ہوتا ہے۔ DynamicUser=yes سیٹ کریں اور آپ کوئی اکاؤنٹ منیج نہیں کرتے:

[Service]
ExecStart=/opt/myapp/bin/server
DynamicUser=yes
StateDirectory=myapp

شروع ہونے پر، systemd ایک غیر استعمال شدہ user ID مختص کرتا ہے؛ رکنے پر، یہ اسے چھوڑ دیتا ہے۔ سروس کو ایک نجی /tmp بھی ملتی ہے، فائل سسٹم کا زیادہ تر حصہ صرف پڑھنے کے لیے نظر آتا ہے، اور /var/lib/myapp کے تحت ایک قابلِ تحریر state ڈائریکٹری ملتی ہے جسے StateDirectory= سیٹ اپ کر کے اسے دیتا ہے۔ کسی ایسی سروس کے لیے جسے صرف اپنی state ڈائریکٹری درکار ہو، DynamicUser=yes مضبوط آئیولیشن حاصل کرنے کا کم سے کم محنت والا طریقہ ہے، کیونکہ حملہ آور کے نشانے بننے کے لیے کوئی طویل عرصے تک رہنے والا اکاؤنٹ موجود ہی نہیں ہوتا۔

ہاتھ سے یونٹس لکھنا مشکل ہوتا ہے، اور ہارڈننگ ہدایات کو درست کرنا اس کی اہمیت کا زیادہ تر حصہ ہے۔ the systemd service and timer guide میں موجود جنریٹر آپ کے لیے یہ آپشنز بھر سکتا ہے تاکہ یونٹ پہلی بار ہی درست ہو۔

یہ باقی چیزوں کے ساتھ کیسے فٹ بیٹھتا ہے

کم سے کم مراعات ایک تہہ ہے، اور یہ دوسروں کے ساتھ مل کر کام کرتی ہے، ان کی جگہ نہیں لیتے۔ ایک default-deny firewall کنٹرول کرتا ہے کہ سروس تک کیا پہنچ سکتا ہے؛ اسے غیر مرتبہ یوزر کے طور پر چلانا کنٹرول کرتا ہے کہ سروس خلاف ورزی کی صورت میں کیا کر سکتی ہے؛ اور hardened SSH حملہ آوروں کو مشین سے ہی دور رکھتی ہے۔ ان میں سے کوئی ایک اکیلا کافی نہیں ہے، اور مل کر ان کا مطلب ہے کہ ایک سروس میں خامی پورے سرور کا سمجھوتہ نہیں بنتی۔

آگے بڑھنے سے پہلے، پوری مشین کے لیے ہارڈننگ چیک لسٹ چلائیں اور کام شروع کرنے کے لیے ایک ذاتی کاپی بنائیں:

FAQ

میں سروس کو root کے طور پر کیوں نہ چلاؤں؟

چونکہ root مشین پر کچھ بھی کر سکتا ہے، اس لیے root کے طور پر چلنے والی سروس جس پر قبضہ کیا جائے، وہ حملہ آور کو پورا سرور دے دیتی ہے، نہ کہ صرف سروس۔ سروس کو محدود، غیر مرتبہ اکاؤنٹ کے طور پر چلانا نقصان کو اس تک محدود رکھتا ہے جس تک وہ اکاؤنٹ رسائی حاصل کر سکتا ہے۔ انتظامیہ کے لیے root محفوظ رکھیں، اور ہر طویل عرصے تک چلنے والی سروس کو محدود یوزر کے طور پر چلائیں۔

میں ایسا یوزر کیسے بناؤں جو لاگ ان نہ ہو سکے؟

sudo useradd --system --no-create-home --shell /usr/sbin/nologin NAME چلائیں۔ nologin شیل کا مطلب ہے کہ اکاؤنٹ انٹرایکٹو سیشن نہیں کھول سکتا حتیٰ کہ اگر اس کی اسناد چوری بھی ہو جائیں، --system اسے سروس اکاؤنٹ کے طور پر نشان زد کرتا ہے، اور --no-create-home ایک ہوم ڈائریکٹری سے گزر جاتا ہے جس کی اسے ضرورت نہیں۔ اسے chown کے ساتھ صرف اپنی فائلوں کی ملکیت دیں۔

systemd DynamicUser کیا ہے؟

DynamicUser=yes systemd کو بتاتا ہے کہ سروس کے لیے ایک عارضی یوزر بنائے جو صرف اس کے چلنے کے دوران موجود رہتا ہے، لہٰذا آپ کبھی طویل عرصے تک رہنے والا اکاؤنٹ منیج نہیں کرتے۔ یہ سروس کو ایک نجی /tmp، زیادہ تر صرف پڑھنے کے قابل فائل سسٹم ویو، اور ایک منیج شدہ state ڈائریکٹری بھی دیتا ہے۔ یہ خود کفیل سروس کو ایک عارضی، کم مراعات والی شناخت کے تحت چلانے کا کم سے کم محنت والا طریقہ ہے۔

غیر root یوزر کے طور پر چلانا فائر وال کی جگہ لیتا ہے؟

نہیں۔ وہ مختلف چیزوں کی حفاظت کرتے ہیں۔ غیر مرتبہ یوزر کے طور پر چلانا اس بات کو محدود کرتا ہے کہ سروس خلاف ورزی کی صورت میں کیا کر سکتی ہے، جبکہ فائر وال اس بات کو محدود کرتا ہے کہ سروس تک کیا پہنچ سکتا ہے۔ دونوں کا استعمال کریں، ہارڈنڈ SSH کے ساتھ، تاکہ ہر تہہ اس چیز کا احاطہ کرے جو دوسری نہیں کر سکتیں۔

سروس یوزر کی کون سی فائلوں کی ملکیت ہونی چاہیے؟

صرف وہ فائلیں جن کی سروس کو واقعی ضرورت ہے، اور اس سے زیادہ کچھ نہیں۔ اکاؤنٹ کو اپنی ورکنگ ڈائریکٹری اور اپنے ڈیٹا کی ملکیت دیں، اور باقی سب کچھ root کی ملکیت میں رہنے دیں۔ ایک اچھا پیٹرن ایپلیکیشن ڈائریکٹری کے لیے sudo chown -R svc-app:svc-app /opt/svc-app ہے، جبکہ /etc کے تحت کنفیگریشن root کی ملکیت میں رہتی ہے اور سروس صرف اسے پڑھ سکتی ہے۔ مقصد یہ ہے کہ اگر پروسے پر کبھی قبضہ ہو جائے، تو فائلیں جو یہ تبدیل کر سکتا ہے اس کے اپنے ڈیٹا تک محدود ہوں، سسٹم کے باقی حصوں کی نہیں۔