हर दिन मेरे 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 common 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 work कम है।
मैं 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 static होने पर भी exposed है। अगर
.git,.env, backup या कोई secret public directory में पहुँच जाए, configuration रोकती न हो तो Nginx उसे HTML की तरह serve कर सकता है। - Nginx, TLS, operating system और network attack surface का हिस्सा रहते हैं। इन्हें patch और सही तरह configure करना पड़ता है।
- Client-side code में vulnerabilities हो सकती हैं। 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” सुनने में actual load से ज्यादा गंभीर लग सकता है
Logs Internet background noise को बहुत intense दिखाते हैं क्योंकि हर failed probe अलग line है। लेकिन daily total अकेले operational impact नहीं बताता। 24 घंटे में फैली कुछ हजार requests और वही संख्या एक short burst में आना अलग परिस्थितियाँ हैं।
CPU भी सिर्फ एक signal है। मेरे मामले में वह stable रहा, जो उपयोगी evidence है कि observation के समय यह traffic noticeable compute pressure नहीं बना रहा था। लेकिन इससे यह साबित नहीं होता कि बाकी resources पर cost zero थी। सही 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 path में WordPress या PHP नहीं है तो उन probes के पास इस्तेमाल करने के लिए बहुत कम होता है।
लेकिन मैं अब “मेरे stack के लिए irrelevant” को “harmless traffic” नहीं मानता। मेरी current checklist:
- जानूँ कि public request path से कौन-से runtimes और services वास्तव में reachable हैं।
- Secrets, repository metadata, backups और build artifacts को web root से बाहर रखूँ या explicitly 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 देखते हुए रोज़ आने वाली हजारों scanner requests को observe किया। यह मेरे setup पर practical conclusion के लिए काफी है, universal rule “static हमेशा जीतता है” के लिए नहीं।
मैं ज्यादा confidence से यह specific बात कह सकता हूँ: Nginx-served Next.js static export पर मैंने जो scanner traffic देखा, उसका बड़ा हिस्सा PHP runtime या database-backed application तक पहुँचने के बजाय low-cost file misses और 404 में खत्म हुआ। Observation के दौरान CPU load नहीं बदला।
यही resilience advantage मेरे लिए मायने रखता है। कम moving parts system को invulnerable नहीं बनाते; वे random Internet noise के लिए real application work में बदलने की जगहें कम कर देते हैं।