سرور کی بارہ جانچیں جو ہفتے میں ایک بار کرنے کے قابل ہیں

سرور ایک بار ترتیب دیا جاتا ہے اور اس کے بعد خود ہی چلتا رہتا ہے۔ ایک مہینے بعد کچھ پیکیج اپ گریڈ کے منتظر ہوتے ہیں، سرٹیفکیٹ میعاد ختم ہونے سے تین ہفتے کے فاصلے پر آ چکا ہوتا ہے، کسی غیر متعلق چیز کی تنصیب کے بعد SSH کی ترتیب میں ایک اضافی سطر آ چکی ہوتی ہے، اور وہ jail جسے لاگ اِن پر نظر رکھنی تھی رک چکا ہوتا ہے اور کسی کو خبر تک نہیں ہوتی۔ ان میں سے کوئی چیز چیختی نہیں۔ سب کچھ بس خاموشی سے درست ہونا چھوڑ دیتا ہے۔

ذیل میں بارہ چیزیں ہیں جنہیں باقاعدگی سے جانچنا مفید ہے، کمانڈوں کے ساتھ۔ یہ چکر پندرہ منٹ لیتا ہے۔ ترتیب اُس سے شروع ہوتی ہے جس سے اندر آیا جاتا ہے اور اُس پر ختم ہوتی ہے جو خود بخود خراب ہوتا ہے۔

SSH: پانچ سطریں

دیکھنے کی چیز فائل نہیں بلکہ مؤثر ترتیب ہے: یہ /etc/ssh/sshd_config، پوری ڈائرکٹری sshd_config.d اور کمپائل کی طے شدہ اقدار سے مل کر بنتی ہے۔

sudo sshd -T | grep -iE 'permitrootlogin|passwordauthentication|permitemptypasswords|maxauthtries|x11forwarding'

ہم جو دیکھنا چاہتے ہیں: permitrootlogin no، passwordauthentication no، permitemptypasswords no، maxauthtries 3 سے 4 کے درمیان اور x11forwarding no۔ پہلی تین دروازہ ہیں، آخری دو اس کے قبضے — فی کنکشن کوششوں کی حد، اور گرافکس کی ترسیل جس کی سرور کو کوئی ضرورت نہیں۔

دو تنبیہیں، دونوں خود کو باہر بند کر لینے کا آسان راستہ۔ پہلی: پاس ورڈ سے لاگ اِن اور root لاگ اِن اُس وقت تک بند نہ کریں جب تک یہ تصدیق نہ ہو جائے کہ آپ کی کلید کام کرتی ہے — ایک الگ سیشن میں، موجودہ سیشن بند کیے بغیر۔ اگر آپ یہ root کے طور پر پاس ورڈ سے جُڑے ہوئے پڑھ رہے ہیں تو وہی دو سطریں آپ ہی کو باہر بند کر دیں گی۔

دوسری: فائلوں کی ترتیب۔ OpenSSH کسی پیرامیٹر کی وہ قدر لیتا ہے جو اسے پہلے ملے، اور sshd_config.d کی فائلیں حروفِ تہجی کے اعتبار سے پڑھی جاتی ہیں۔ کلاؤڈ امیجز عموماً وہاں 50-cloud-init.conf چھوڑ جاتی ہیں، اور اگر آپ نے اپنی فائل کا نام 90-hardening.conf جیسا رکھا ہو تو وہی غالب آئے گی۔ اپنی ترتیبات چھوٹے نمبر کے تحت رکھیں — 00- یا 10-۔ اور نتیجہ فائل پڑھ کر نہیں، sshd -T سے جانچا جاتا ہے۔

فائر وال: ایک جانچ

sudo ufw status verbose

یہاں یاد رکھنا چاہیے کہ یہ نتیجہ ارادے دکھاتا ہے، نتائج نہیں۔ کوئی قاعدہ فہرست میں ہو سکتا ہے اور کچھ بھی بند نہ کر رہا ہو: خود UFW بند ہو، پورٹ کو Docker کی شائع کردہ کوئی چیز سنبھال رہی ہو (وہ اپنے قواعد UFW کے نیچے iptables میں لکھتا ہے)، یا ٹریفک سرور تک کسی اور راستے سے پہنچ رہی ہو۔ اسی لیے قواعد کی فہرست کو اُس چیز سے ملانا مفید ہے جو واقعی باہر کی طرف سن رہی ہے:

sudo ss -tulpn | grep -v '127.0.0.1\|::1'

fail2ban: دو جانچیں

صرف سروس کا چلنا کافی نہیں — SSH کے لیے ایک کارآمد jail بھی چاہیے۔

sudo fail2ban-client status
sudo fail2ban-client status sshd

یہاں سب سے عام مصیبت خاموش jail ہے۔ Debian 12 اور نئے Ubuntu پر /var/log/auth.log سرے سے موجود ہی نہ ہو: rsyslog نصب نہیں ہوتا اور اندراجات صرف journald میں رہتے ہیں۔ فیکٹری logpath والا jail اُس صورت میں چل پڑتا ہے، خود کو فعال بتاتا ہے اور کبھی کسی کو بلاک نہیں کرتا۔ علاج اسے systemd کے جرنل کی طرف موڑنا ہے:

printf '[sshd]\nenabled = true\nbackend = systemd\n' | sudo tee /etc/fail2ban/jail.d/sshd-systemd.local
sudo systemctl restart fail2ban

وہ نشانی جس سے یہ ترتیبات کھنگالے بغیر پکڑا جاتا ہے: fail2ban-client status sshd میں «Currently failed» اور «Total failed» صفر پر کھڑے رہتے ہیں جبکہ جرنل میں ناکام لاگ اِن صاف موجود ہوتے ہیں۔

اپ ڈیٹس: تین جانچیں

الگ الگ: کل کتنے پیکیج منتظر ہیں، ان میں سے کتنے سیکیورٹی کے ہیں، اور کیا نظام کرنل اپ ڈیٹ کے بعد ری اسٹارٹ مانگ رہا ہے۔

sudo apt update
apt list --upgradable 2>/dev/null | grep -c -- '-security'
ls /var/run/reboot-required 2>/dev/null && echo 'ری اسٹارٹ درکار ہے'

تیسری جانچ یہ ہے کہ خودکار سیکیورٹی اپ ڈیٹس آن ہیں یا نہیں، تاکہ پہلی دو ماہانہ رسم نہ بن جائیں:

systemctl status unattended-upgrades --no-pager
cat /etc/apt/apt.conf.d/20auto-upgrades

اس فائل کی دونوں سطروں میں 1 ہونا چاہیے۔ اگر پیکیج موجود نہ ہو: sudo apt install unattended-upgrades && sudo dpkg-reconfigure -plow unattended-upgrades۔

سرٹیفکیٹ: ایک جانچ

Let's Encrypt کا سرٹیفکیٹ نوے دن جیتا ہے، اور تجدید عام طور پر خود ہی چلتی ہے — ٹھیک اُس دن تک جب وہ رک جاتی ہے۔ دیکھنے کی چیز رجسٹرار کا پینل نہیں بلکہ وہ ہے جو سرور واقعی دے رہا ہے:

echo | openssl s_client -connect localhost:443 -servername example.com 2>/dev/null | openssl x509 -noout -enddate
sudo certbot renew --dry-run

پہلی کمانڈ اُس سرٹیفکیٹ کی اختتامی تاریخ دیتی ہے جو اُس نام کے لیے پیش کیا جاتا ہے؛ دوسری اصل میعاد کا انتظار کیے بغیر تصدیق کرتی ہے کہ تجدید کامیاب ہوگی۔ سرور جن تمام ناموں کو سنبھالتا ہے اُن سب پر نظر ڈالنا مفید ہے، صرف مرکزی ڈومین پر نہیں: عموماً وہی ذیلی ڈومین بھول جاتا ہے جو بعد میں شامل کیا گیا ہو۔

ڈسک: ایک جانچ

df -h
df -i

دو کمانڈیں، کیونکہ جگہ اور فائلوں کے اندراج ایک دوسرے سے آزادانہ ختم ہوتے ہیں۔ زیادہ تر سرورز پر دوسری پہلے چھت سے ٹکراتی ہے — PHP سیشنز یا ایپلیکیشن کیش میں لاکھوں چھوٹی فائلیں IUse% کو 100 تک پہنچا دیتی ہیں جبکہ گیگا بائٹس خالی پڑے ہوتے ہیں۔ دونوں صورتوں پر ہمارا الگ مضمون موجود ہے۔

اس فہرست میں خرابی کیا ہے

فہرست درست ہے، مگر اس کی ایک خاصیت ہے: یہ تقاضا کرتی ہے کہ کوئی اسے یاد رکھے۔ ہفتے میں پندرہ منٹ زیادہ نہیں، جب تک سرور ایک ہے اور جب تک کوئی سبب موجود ہے۔ دو پُرسکون مہینوں کے بعد چکر رہ جاتا ہے، اور jail کے رک جانے کی خبر کسی اور کے لاگ سے ملتی ہے۔

اسی لیے ہم نے بالکل یہی بارہ جانچیں ایک الگ مفت پینل میں جمع کر دیں — Arcivéo FREE۔ یہ ایک ہی کمانڈ سے نصب ہوتا ہے، آپ کے اپنے سرور پر چلتا ہے، ہمیں کچھ نہیں بھیجتا اور رجسٹریشن نہیں مانگتا۔ ایک جمع کنندہ cron سے ہر پانچ منٹ بعد چلتا ہے اور وہی سب کچھ مقامی ڈیٹابیس میں لکھتا ہے: SSH لاگ اِن اور مسترد کنکشن، UFW اور fail2ban کی حالت، زیرِ التوا سیکیورٹی اپ ڈیٹس، سرٹیفکیٹ کی میعادیں، ڈسک کی جگہ۔ تاریخ سات دن کی ہے، انٹرفیس 34 زبانوں میں۔ قیمت صفر ہے، کاروباری سرور پر بھی: لائسنس پینل کو اپنی مشینوں پر، بشمول کمپنی کی مشینوں کے، نصب کرنے کی اجازت دیتا ہے، اور اسے آگے بیچنے یا دوسروں کے سرورز کے لیے بطور سروس چلانے کی اجازت نہیں دیتا۔

مفت ایڈیشن کا ڈھیر معمولی ہے: یہ UFW اور fail2ban کو نصب اور فعال کرتا ہے، اور اس کے بعد حالت دکھاتا ہے۔ ModSecurity، Suricata، AIDE اور باقی ماڈیول اس میں نہیں ہیں، وہ ادائیگی والے سے تعلق رکھتے ہیں۔ مگر ہفتہ وار چکر کو ذہن میں رکھنا چھوڑنے کے لیے یہی کافی ہے۔ وہی ڈیٹا مکمل پینل پر کیسا لگتا ہے — نیچے دیے گئے ڈیمو صفحات پر۔