WordPress .htaccess کے سیکیورٹی رولز جو واقعی کام آتے ہیں

“WordPress .htaccess سیکیورٹی” کے نام پر جو کچھ بیچا جاتا ہے، اس میں سے زیادہ تر محض بھرتی ہے۔ وہ رولز جو واقعی آپ کے اٹیک سرفیس کو بدلتے ہیں، مختصر ہیں: wp-content/uploads کے اندر PHP execution کو بلاک کرنا، wp-config.php تک براہِ راست رسائی کو روکنا، اور directory indexing کو بند کرنا۔ جو مقبول ہیں — “brute force روکنے کے لیے” xmlrpc.php بلاک کرنا، اپنا WordPress ورژن چھپانا، 200 لائنوں کی bad-bot user-agent لسٹ چسپاں کرنا — وہ معمولی سے لے کر خالص تماشے تک ہیں۔ نیچے بتایا گیا ہے کہ کون سا کیا ہے، اور کیوں۔

پہلے ایک بات طے کر لیں: .htaccess صرف Apache پر کچھ کرتا ہے (اور LiteSpeed پر، جو اسے پڑھتا بھی ہے)۔ nginx پر اسے مکمل طور پر نظرانداز کر دیا جاتا ہے — فائل بس وہیں پڑی رہتی ہے جبکہ آپ سمجھتے رہتے ہیں کہ آپ محفوظ ہیں۔ اگر آپ کا ہوسٹ nginx چلاتا ہے تو ان میں سے کچھ بھی لاگو نہیں ہوتا اور آپ کو اس کے بجائے server/location بلاکس درکار ہیں۔ curl -I https://yoursite.com سے چیک کریں اور کوئی فائل ایک گھنٹے تک ایڈٹ کرنے سے پہلے، جسے سرور کبھی پڑھتا ہی نہیں، Server: ہیڈر دیکھ لیں۔

وہ رول جو واقعی اہم ہے: /uploads میں کوئی PHP نہیں

یہی وہ ایک ہے جو کرنے کے قابل ہے۔ wp-content/uploads بنیادی ڈیزائن کے اعتبار سے world-writable ہے — ہر میڈیا اپلوڈ، ہر پلگ ان جو کوئی فائل سیو کرتا ہے، وہیں لکھتا ہے۔ اگر کوئی حملہ آور اس directory میں کوئی .php فائل ڈال دے (کسی کمزور upload handler کے ذریعے، کسی ایسے image field سے جو MIME type کی تصدیق نہیں کرتا، یا کسی compromised پلگ ان سے)، تو ایک معمولی جھنجھلاہٹ اور مکمل remote-code-execution کے compromise کے درمیان فرق صرف یہ ہے کہ آیا سرور درخواست پر اُس فائل کو execute کرے گا یا نہیں۔ execution روک دیں اور اپلوڈ شدہ payload بس ڈسک پر پڑی ایک بے اثر فائل رہ جاتی ہے۔

اسے wp-content/uploads/.htaccess میں ڈالیں (اگر فائل موجود نہیں تو بنا لیں):

<FilesMatch "\.php$">
    Require all denied
</FilesMatch>

یہ Apache 2.4 کا syntax ہے۔ پرانے 2.2 پر اس کے مساوی Order Deny,Allow / Deny from all ہے۔ ایک ہی فائل میں دونوں dialects ملانا “hardening” کے بعد اچانک 500 Internal Server Error کی سب سے عام وجہ ہے — اگر سیو کرتے ہی پوری سائٹ ڈھیر ہو جائے تو تقریباً ہمیشہ یہی وجہ ہوتی ہے۔ اپنا ورژن apachectl -v سے چیک کریں۔

wp-config.php کی حفاظت

wp-config.php آپ کے ڈیٹابیس credentials اور auth salts رکھتی ہے۔ جب تک PHP چل رہا ہے، اس پر براہِ راست درخواست ایک خالی صفحہ لوٹاتی ہے — PHP فائل کو پرنٹ کرنے کے بجائے execute کر دیتا ہے۔ خطرہ ناکامی کی صورت میں ہے: اگر کبھی PHP کریش ہو جائے، کسی migration کے دوران غلط کنفیگر ہو جائے، یا handler ڈس ایبل ہو جائے، تو Apache فائل کو plaintext کے طور پر سرو کرتا ہے اور آپ کا DB پاس ورڈ ہر مانگنے والے کے سامنے ڈال دیتا ہے۔ رسائی روک دینا اُن پانچ خراب منٹوں کے خلاف سستا بیمہ ہے:

<Files wp-config.php>
    Require all denied
</Files>

directory indexing بند کریں

اگر کوئی ایسے فولڈر پر جائے جس میں کوئی index.php نہ ہو اور Apache پر Options +Indexes آن ہو، تو یہ مواد کی فہرست دکھا دیتا ہے — ہر بیک اپ فائل، ہر بھولی بسری SQL dump جو آپ بھول گئے تھے۔ اسے پوری سائٹ کے لیے بند کریں:

Options -Indexes

کم شدت والا، مگر حقیقی، اور اس کی کوئی قیمت نہیں۔

یہی ایماندارانہ بنیادی لسٹ ہے۔ آپ ان کو — درست 2.4-بمقابلہ-2.2 syntax سمیت تاکہ آپ اپنی سائٹ 500 نہ کر دیں — WordPress .htaccess generator سے جوڑ سکتے ہیں، بجائے اس کے کہ کسی ایسی فورم پوسٹ سے copy-paste کریں جو غلط Apache ورژن کے لیے لکھی گئی تھی۔

کیا نہیں کرنا چاہیے

“brute-force تحفظ کے لیے” xmlrpc.php بلاک کرنا۔ یہ وہ بڑی بات ہے جو ہر کوئی دہراتا ہے اور جیسے بیان کی جاتی ہے ویسے غلط ہے۔ ہاں، XML-RPC کے system.multicall طریقے نے تاریخی طور پر کسی حملہ آور کو کئی login کے اندازے ایک ہی درخواست میں باندھنے کی اجازت دی — حقیقی amplification۔ لیکن بے تحاشا عام brute-force راستہ wp-login.php پر سادہ POST درخواستیں ہیں، اور xmlrpc.php بلاک کرنے سے اس کے لیے کچھ نہیں ہوتا۔ brute force کو rate limiting، مضبوط پاس ورڈز، اور 2FA سے شکست دی جاتی ہے — نہ کہ کسی ایک endpoint کو مار کر۔ XML-RPC کو ڈس ایبل کرنے کی ایک جائز وجہ ضرور ہے: اس کا pingback فیچر DDoS reflection کے لیے غلط استعمال ہو سکتا ہے، تو اگر آپ Jetpack، موبائل ایپ، یا pingbacks استعمال نہیں کرتے، تو اسے بند کرنا آپ کے اٹیک سرفیس کو سکیڑ دیتا ہے۔ بس اپنے آپ کو یہ نہ بتائیں کہ یہ آپ کا brute-force دفاع ہے، کیونکہ یہ نہیں ہے۔

اپنا WordPress ورژن چھپانا / generator tag ہٹانا۔ readme.html اور <meta name="generator"> tag اتار دینا hardening جیسا محسوس ہوتا ہے۔ ایک حملہ آور آپ کا ورژن enqueued asset query strings، block-editor markup، اور درجن بھر دیگر نشانیوں سے سیکنڈوں میں پہچان لیتا ہے۔ آپ کچھ نہیں چھپا رہے؛ آپ بس اپنے آپ کو مصروف محسوس کروا رہے ہیں۔

بڑی bad-bot user-agent اور referrer blocklists۔ User agents ایک ہی spoofed HTTP ہیڈر ہیں۔ یہ لسٹیں جس دن آپ چسپاں کرتے ہیں اسی دن باسی ہو جاتی ہیں، کسی قابل حملہ آور کو نہیں روکتیں، اور Apache ہر درخواست پر ہر regex کو جانچتا ہے — آپ صفر سیکیورٹی کے بدلے ایک حقیقی performance ٹیکس ادا کر رہے ہیں۔ انہیں چھوڑ دیں۔

wp-login.php کو IP سے لاک کرنا۔ بہترین رہتا ہے جب تک آپ کا ISP آپ کا پتہ نہ بدل دے اور آپ اپنے ہی admin سے باہر لاک ہو جائیں۔ صرف حقیقی static IP کے ساتھ قابلِ عمل ہے۔

Author-enumeration redirects (?author=1)۔ لوگ اس کے لیے جو .htaccess rewrite چسپاں کرتے ہیں وہ بذاتِ خود نامکمل ہے — REST endpoint /wp-json/wp/v2/users اب بھی usernames کی فہرست دکھاتا ہے۔ ایک راستہ بلاک کرنا جبکہ دوسرا کھلا رہے، محض تماشا ہے۔

پھر بھی پھنسے ہوئے ہیں؟

اگر کوئی رول سائٹ کو 500 کر دے تو یہ syntax ہے — آپ نے جو آخری بلاک شامل کیا تھا اسے نکالیں اور reload کریں؛ اس سے فوراً اسے الگ کر کے پہچانا جا سکتا ہے۔ اگر کوئی رول کچھ کرتا نظر نہ آئے تو تصدیق کریں کہ آپ واقعی Apache پر ہیں اور اس directory کے لیے AllowOverride فعال ہے (بہت سے managed hosts اسے محدود کرتے ہیں)۔ فائل کو کسی معلوم-درست template سے .htaccess generator کے ذریعے بنائیں، وہ تین رولز رکھیں جو اہم ہیں، اور باقی چھوڑ دیں۔