मैंने अपने एक्सेस लॉग्स में हुए हमलों की जाँच की
नियमित स्कैन और कम-कौशल वाले हमले इंटरनेट-फेसिंग किसी भी सर्वर पर लगातार वार करते हैं, जिससे `.env` files, WordPress paths, SSH passwords, और पुराने software bugs जैसी ज्ञात कमजोरियों के लिए probes लॉग्स में भर जाते हैं। टिप्पणीकारों का तर्क है कि असली बचाव बुनियादी बातों को अच्छी तरह लागू करना है—समय पर patching, key-based SSH, कम-से-कम exposed services (अक्सर VPN के ज़रिए), isolation/sandboxing, और layered controls—जबकि fail2ban, WAFs, और honeypots जैसे टूल मुख्यतः noise कम करते हैं या सावधानी से tune किए जाने पर सीमित सुरक्षा जोड़ते हैं। कई लोग नोट करते हैं कि हमलावर certificate transparency logs के माध्यम से नए targets तेजी से खोज रहे हैं, जिससे systems को live होने से पहले ही lock down करने की आवश्यकता और बढ़ जाती है.
नियमित इंटरनेट स्कैनिंग और हमले के पैटर्न
- लॉग्स में दिखने वाले अधिकांश “हमले” कम-कौशल, पूरी तरह स्वचालित स्कैन होते हैं जो हर routable IP को निशाना बनाते हैं, अक्सर पुराने CVEs के लिए तैयार payloads के साथ (.env leaks, Shellshock, Wordpress/PHP paths, आदि)।
- कई टूल बस सर्वरों पर लगातार अनुरोध भेजते रहते हैं, बिना responses जाँचे; कभी-कभी वही स्थिर IPs या ranges से बार-बार।
- कई लोग इस निष्कर्ष पर पहुँचते हैं कि यदि आप बुनियादी सुरक्षा प्रथाओं का पालन करते हैं, तो ये probes मायने नहीं रखते; और यदि आप नहीं करते, तो वे भी मायने नहीं रखते क्योंकि आप पहले से ही असुरक्षित हैं।
Fail2ban, SSH, और बुनियादी होस्ट हार्डनिंग
- Fail2ban का उपयोग मुख्यतः log noise कम करने और brute-force प्रयासों को घटाने के लिए किया जाता है; अन्य लोग कहते हैं कि यह पुराना है, resource-heavy है, और IP rotation के खिलाफ अप्रभावी है।
- सामान्य SSH सलाह: password auth बंद करें, केवल keys का उपयोग करें, वैकल्पिक रूप से port 22 से हटें, source IPs सीमित करें, या SSH को VPN/bastions/“dark” access के पीछे रखें।
- कुछ लोग fail2ban की बजाय iptables/nftables rate limiting या port knocking पर निर्भर करते हैं; IPv6-only SSH, जिसमें IPv4 firewall किया गया हो, एक और तरीका है।
WAFs, Cloudflare, और trade-offs
- कुछ लोग obvious attacks को फ़िल्टर करने और compliance पूरा करने के लिए AWS WAF, Azure WAF (OWASP rules), या Cloudflare का free WAF सुझाते हैं।
- कड़ी चेतावनियाँ: default rules अक्सर वैध traffic को तोड़ देती हैं (कुछ request bodies, missing User-Agent, metadata के साथ file uploads, लंबे URLs को block करना)। सर्वोत्तम अभ्यास है पहले “count mode”, फिर धीरे-धीरे blocking।
- आलोचक तर्क देते हैं कि WAFs सुरक्षा का झूठा एहसास देते हैं, bypass किए जा सकते हैं, latency जोड़ते हैं, और researchers या Tor users को block कर सकते हैं; समर्थक इन्हें एक उपयोगी band-aid मानते हैं, secure apps का विकल्प नहीं।
- Cloudflare जैसे बड़े providers के पीछे traffic केंद्रीकृत करने को लेकर चिंताएँ उठती हैं, लेकिन अन्य विकल्प और अपेक्षाकृत कम lock-in भी नोट किए जाते हैं।
Self-hosting रणनीतियाँ और नेटवर्क exposure
- मुख्य mitigations: सिस्टम को अपडेट रखें (अक्सर unattended security upgrades के माध्यम से), isolation के लिए containers/VMs/jails का उपयोग करें, और सेवाओं को अनावश्यक रूप से expose करने से बचें।
- कई self-hosters अब सब कुछ VPNs या zero-trust-style overlays (Wireguard, Tailscale, ZeroTier, Cloudflare Tunnels, समान टूल) के पीछे रखते हैं, कभी-कभी अतिरिक्त परत के रूप में mTLS या HTTP basic auth के साथ।
- सुझावों में dotfiles सर्व न करना, admin panels को obscure paths तक सीमित करना, और forensic analysis के लिए logs को host से बाहर भेजना शामिल है।
Credential stuffing और authentication hardening
- बड़े पैमाने के credential stuffing campaigns में 100k+ IPs शामिल हो सकते हैं, जिससे per-IP blocking अप्रभावी हो जाती है।
- रिपोर्ट किए गए mitigations:
- IP, username, और password के आधार पर rate-limit करें।
- पहले से leaked passwords को proactively पहचानें और reset करें, तथा आम leaked passwords को ban करें।
- auth checks को कम-लागत और scalable बनाएं; स्पष्ट attack traffic को जल्दी short-circuit करें लेकिन सामान्य timing की नकल करें।
- attack के दौरान dynamically extra auth requirements सक्षम करें।
Certificate Transparency और discovery
- कई रिपोर्टें बताती हैं कि Let’s Encrypt certificates प्राप्त करने के तुरंत बाद scanning spikes बढ़ जाते हैं, जिससे संकेत मिलता है कि attackers नए domains/subdomains के लिए CT logs देखते हैं।
- कुछ लोग इससे निपटने के लिए: exposure से पहले hardening, wildcard या internal/self-signed certs का उपयोग, या internal certs को public-facing proxies से अलग रखना अपनाते हैं।
- अपनी footprint की निगरानी के लिए crt.sh, certstream, और विभिन्न CT query tools जैसे टूल्स का उल्लेख किया गया है।
सुरक्षा दर्शन और “Security Through Obscurity”
- सहमति: पहले तेज़ी से patch करें और सर्वोत्तम प्रथाओं का पालन करें; logs हर probe पर obsess करने की बजाय post-incident analysis के लिए अधिक उपयोगी हैं।
- defense in depth के लिए मजबूत समर्थन: firewalls/VPNs, isolation, WAFs, monitoring, और अच्छी auth, साथ ही public और internal systems के बीच segmentation।
- “Security through obscurity” पर बहस होती है: केवल उसी पर निर्भर रहना निंदनीय है, लेकिन कई लोग obscurity (nonstandard ports/paths, hidden services) को drive-by noise कम करने के लिए एक मूल्यवान secondary layer मानते हैं।