ہر روز میرے server logs میں ہزاروں automated vulnerability scans درج ہوتے ہیں۔ Requests دیکھنے میں کافی خطرناک لگتے ہیں:
/wp-admin/wp.php/111.php/code.php/.git/config/i.php/admin/api/.env/kal.php
مجھے تعداد سے زیادہ server کا ردعمل حیران کن لگا۔ جب میں یہ traffic دیکھ رہا تھا تو CPU load میں کوئی نمایاں تبدیلی نہیں ہوئی۔
یہ observation درست ہے، مگر میری ابتدائی explanation بہت absolute تھی۔ Static delivery کوئی جادوئی shield نہیں اور 404 بھی free نہیں۔ میری architecture کا حقیقی فائدہ زیادہ specific ہے: بہت سی opportunistic probes سستی پڑتی ہیں کیونکہ public request path میں پہنچنے کے لیے تقریباً کوئی server-side application logic موجود نہیں۔
یہ probes ہیں، compromise کا ثبوت نہیں
/wp-admin/wp.php یا /111.php دیکھ کر ہر request کو “exploit” کہنا آسان ہے، مگر technically یہ precise نہیں۔ میں زیادہ تر automated probing دیکھتا ہوں: bots عام filenames اور endpoints try کرتے ہیں اور دیکھتے ہیں کیا جواب آتا ہے۔
کچھ paths واضح طور پر WordPress یا PHP کو target کرتے ہیں۔ /.git/config اور /api/.env جیسی requests غلطی سے exposed configuration یا secrets تلاش کرتی ہیں۔ /admin اس سے بھی زیادہ generic ہے اور کسی site پر legitimate route ہو سکتا ہے۔ Suspicious request یہ بتاتی ہے کہ scanner کیا ڈھونڈ رہا ہے؛ یہ vulnerability کے موجود ہونے کا ثبوت نہیں۔
میرے معاملے میں architecture فیصلہ کن ہے: public site Next.js سے pre-render کیا گیا static HTML ہے جسے Nginx براہ راست serve کرتا ہے۔
میرے stack پر یہ traffic کم لاگت کیوں ہے
جن pages کی بات ہو رہی ہے، ہر request کے پیچھے PHP runtime یا database نہیں۔ Nginx پہلے سے موجود files serve کرتا ہے۔ اگر scanner /111.php مانگے اور file موجود نہ ہو تو کوئی PHP application boot نہیں ہوتی، WordPress code execute نہیں ہوتا اور database query نہیں چلتی۔ Request صرف miss ہو کر 404 پر ختم ہوتی ہے۔
اس سے cost model بدل جاتا ہے۔ Dynamic application میں request routing، framework، authentication، rendering، database یا دوسرے services سے گزر سکتی ہے۔ میرے static path میں moving parts بہت کم ہیں۔ Nginx کو پھر بھی connection accept کرنا، HTTP process کرنا، resource lookup کرنا، log لکھنا اور response بھیجنا ہوتا ہے، مگر application-level کام کم ہے۔
میں site پر aggressive caching بھی استعمال کرتا ہوں، جو normal static delivery میں مدد دیتی ہے۔ پھر بھی ہر random 404 کا credit cache کو نہیں دوں گا۔ کوئی نیا bogus URI، 404 سے پہلے normal Nginx processing اور filesystem lookup سے گزر سکتا ہے۔
اہم correction: static کا مطلب “by definition secure” نہیں
آج میں اس حصے کو زیادہ احتیاط سے لکھوں گا۔ Static architecture public request path سے کئی server-side components ہٹا دیتی ہے، مگر security work ختم نہیں کرتی۔
- Exposed file اب بھی exposed ہے۔ اگر
.git،.env، backup یا secret public directory میں آ جائے اور configuration اسے نہ روکے تو Nginx اسے HTML کی طرح serve کر سکتا ہے۔ - Nginx، TLS، operating system اور network attack surface کا حصہ رہتے ہیں۔ انہیں patch اور درست configure کرنا ضروری ہے۔
- Client-side code میں vulnerability ہو سکتی ہے۔ Static HTML، JavaScript، browser-side auth logic یا third-party scripts کو خودکار طور پر safe نہیں بناتا۔
- Resource exhaustion اب بھی ممکن ہے۔ Connections، bandwidth، TLS handshakes، worker capacity، log I/O اور disk space محدود ہیں۔ کافی traffic static site کو بھی متاثر کر سکتا ہے۔
اس لیے صحیح conclusion “ان requests سے کوئی فرق نہیں پڑتا” نہیں، بلکہ یہ ہے: اس architecture میں بہت سی application-specific probes کو execute کرنے کے لیے کچھ نہیں ملتا۔
“روزانہ ہزاروں scans” اصل load سے زیادہ خوفناک لگ سکتے ہیں
Logs Internet background noise کو بہت intense دکھاتے ہیں کیونکہ ہر failed probe الگ line بنتی ہے۔ لیکن daily total اکیلا operational impact نہیں بتاتا۔ 24 گھنٹوں میں پھیلی چند ہزار requests اور ایک short burst میں یہی تعداد بالکل مختلف حالات ہیں۔
CPU بھی صرف ایک signal ہے۔ میرے معاملے میں یہ stable رہا، جو useful evidence ہے کہ observation کے وقت یہ traffic نمایاں compute pressure نہیں بنا رہا تھا۔ مگر اس سے دوسرے resources کا cost صفر ثابت نہیں ہوتا۔ بہتر evaluation کے لیے request rate، bandwidth، active connections، Nginx worker utilization، response latency، log volume اور disk usage بھی دیکھنا چاہیے۔
اس noise کو دیکھ کر میں نے کیا سیکھا
میرے لیے سب سے بڑا lesson یہ ہے کہ architecture خود automated attacks کی پوری categories کو irrelevant بنا سکتی ہے، ہر scanner signature کے لیے الگ rule لکھے بغیر۔ Bot سارا دن WordPress اور PHP backdoors ڈھونڈ سکتا ہے؛ اگر public request path میں WordPress یا PHP ہی نہیں تو ان probes کے پاس exploit کرنے کو بہت کم ہے۔
لیکن اب میں “میرے stack کے لیے irrelevant” کو “harmless traffic” نہیں سمجھتا۔ میری current checklist:
- جاننا کہ public request path سے کون سے runtimes اور services واقعی reachable ہیں۔
- Secrets، repository metadata، backups اور build artifacts کو web root سے باہر رکھنا یا explicit block کرنا۔
- جب تک targeting یا impact کا دوسرا evidence نہ ہو repeated 404 probes کو normal Internet background noise سمجھنا۔
- صرف CPU دیکھ کر abusive traffic کو free نہ سمجھنا۔
- Application static ہو تب بھی Nginx، OS، TLS libraries اور dependencies patch رکھنا۔
یہ experience کیا ثابت نہیں کرتا
میں نے controlled benchmark نہیں کیا اور DDoS simulate نہیں کیا۔ میں نے production logs اور server load اس وقت observe کیے جب روزانہ ہزاروں scanner requests آ رہی تھیں۔ یہ میرے setup کے بارے میں practical conclusion کے لیے کافی ہے، مگر universal rule “static ہمیشہ جیتتا ہے” ثابت نہیں کرتا۔
جو بات میں زیادہ confidence سے کہہ سکتا ہوں وہ specific ہے: Nginx-served Next.js static export میں جو scanner traffic میں نے دیکھا، اس کا زیادہ حصہ PHP runtime یا database-backed application تک پہنچنے کے بجائے low-cost file miss اور 404 بن کر ختم ہوا۔ Observation کے دوران CPU load نہیں بدلا۔
یہی resilience advantage میرے لیے اہم ہے۔ کم moving parts system کو invulnerable نہیں بناتے؛ وہ random Internet noise کے لیے real application work میں بدلنے کی جگہیں کم کر دیتے ہیں۔