Net Ward

एक यूज़र-स्पेस डिसेप्शन लेयर जो DDoS और बॉट दुरुपयोग को व्यर्थ प्रयास में बदल देती है।

Net Ward आपकी HTTP सेवा के सामने एक रिवर्स प्रॉक्सी के रूप में बैठता है। वास्तविक ट्रैफ़िक बिना किसी बदलाव के गुज़रता है। ज्ञात प्रोब और फ़्लड को हानिरहित मिरर रिस्पॉन्स मिलते हैं जो बॉट का प्रयास जला देते हैं और कभी आपके ऐप तक नहीं पहुँचते — कोई कर्नेल हुक नहीं, कोई पेलोड नहीं, कोई जवाबी कार्रवाई नहीं, डिज़ाइन से फेल-ओपन।

Net Ward क्यों

विचलित करता है, पलटवार नहीं करता। बॉट विश्वसनीय-पर-हानिरहित मिरर पर समय बर्बाद करते हैं; आपका अपस्ट्रीम अनुरोध कभी नहीं देखता।
यूज़र-स्पेस और फेल-ओपन। कोई कर्नेल मॉड्यूल नहीं, कोई पैकेट छेड़छाड़ नहीं। यदि वर्गीकरण, स्टोरेज रीड, या रेंडरिंग कभी विफल हो, तो ट्रैफ़िक सीधे अपस्ट्रीम तक गुज़रता है (या यदि अपस्ट्रीम डाउन है तो डिफ़ॉल्ट मिरर तक)।
कहीं भी लगाएँ। किसी भी HTTP सेवा के सामने एक Python प्रोसेस। अपने लोड बैलेंसर को इस पर इंगित करें और चलें।
डिज़ाइन से ईमानदार। कोई टेलीमेट्री नहीं, कोई क्रेडेंशियल एकत्र नहीं, स्थानीय डेटा का हर बाइट ऑपरेटर के स्वामित्व में। Apache-2.0।

Dragon Lady द्वारा निर्मित और अनुरक्षित — github.com/Dragon-Lady · X: @answerislove2 स्वतंत्र सुरक्षा शोधकर्ता जो जंगली में लाइव सप्लाई-चेन और बॉट-दुरुपयोग अभियानों पर नज़र रखता है।

वेबसाइट: dragon-lady.github.io/netward-standalone

त्वरित शुरुआत

python -m pip install --upgrade "netward>=0.4.12"
python -m netward --config example_config.json

संस्करण 0.4.12 या उससे नया नई स्थापनाओं और अपग्रेड के लिए अनुशंसित आधार है। पुराने रिलीज़ पुनरुत्पादन के लिए उपलब्ध रहते हैं; नई परिनियोजनों को वर्तमान रिलीज़ का उपयोग करना चाहिए।

या स्रोत से:

git clone https://github.com/Dragon-Lady/netward-standalone
cd netward-standalone
pip install -e .

Net Ward listen_address पर सुनता है और साफ़ ट्रैफ़िक को upstream_target पर अग्रेषित करता है।

कॉन्फ़िगरेशन

उदाहरण कॉन्फ़िग कॉपी करें और upstream लक्ष्य को संपादित करें:

cp example_config.json config.json

Net Ward शुरू करने से पहले upstream_target को किसी वास्तविक HTTP सेवा पर इंगित करें। यदि upstream पहुँच से बाहर है, तो बिना मेल खाने वाले अनुरोध कच्ची प्रॉक्सी त्रुटि उजागर करने के बजाय एक डिफ़ॉल्ट मिरर प्रतिक्रिया लौटाते हैं।

आवश्यक फ़ील्ड:

फ़ील्ड	अर्थ
`node_id`	इस Net Ward इंस्टेंस के लिए स्थिर नाम
`upstream_target`	संरक्षित की जा रही HTTP सेवा
`listen_address`	होस्ट और पोर्ट जिस पर Net Ward बाइंड होता है

वैकल्पिक फ़ील्ड मिरर तीव्रता, स्थानीय संग्रहण, mesh प्लेसहोल्डर, अलर्ट चैनल, upstream टाइमआउट, और probe-log प्रतिधारण को नियंत्रित करते हैं। एक पैटर्न मैच या अनुरोध बाढ़ की शुरुआत SQLite में एक अलर्ट दर्ज करती है। अलर्ट को पाँच मिनट के लिए kind, source, और pattern द्वारा डीडुप्लिकेट किया जाता है। एक खाली alert_channels सूची stdout पर भेजती है; स्पष्ट डिलीवरी के लिए stdout, email, slack, और ntfy का कोई भी संयोजन चुनें। आउटबाउंड डिलीवरी पृष्ठभूमि में चलती है और विफल चैनलों को पुनः प्रयास करती है। हाल के अवितरित अलर्ट स्टार्टअप पर पुनः प्रयास किए जाते हैं।

Email के लिए alert_email, alert_smtp_host, और alert_smtp_from आवश्यक हैं। alert_smtp_port और alert_smtp_security (starttls, ssl, या none) सेट करें; none केवल loopback SMTP सर्वर के लिए अनुमत है। यदि प्रमाणीकरण आवश्यक है, तो alert_smtp_username और alert_smtp_password_env को उस environment variable के नाम पर सेट करें जिसमें पासवर्ड है। Slack के लिए alert_slack_webhook आवश्यक है। ntfy के लिए alert_ntfy_topic आवश्यक है (ntfy.sh पर एक टॉपिक या एक पूर्ण self-hosted टॉपिक URL); संरक्षित टॉपिक के लिए, alert_ntfy_token_env को उस environment variable के नाम पर सेट करें जिसमें उसका bearer token है। HTTP गंतव्यों को loopback के अलावा HTTPS का उपयोग करना चाहिए। alert_timeout_secs का डिफ़ॉल्ट पाँच सेकंड है। Net Ward स्टार्टअप पर अनुरोधित गंतव्यों की जाँच करता है और सफल डिलीवरी रसीदें alerts तालिका में संग्रहीत करता है। अलर्ट संदेशों में स्रोत IP, पैटर्न ID, और वर्गीकरण शामिल होते हैं; उनमें कच्चे अनुरोध बॉडी या हेडर शामिल नहीं होते हैं।

वैकल्पिक फ़ील्ड	डिफ़ॉल्ट	अर्थ
`upstream_timeout_total`	`10`	upstream कॉल के लिए पूरे अनुरोध का बजट, सेकंड में
`upstream_timeout_connect`	`3`	कनेक्ट (DNS + TCP + TLS) टाइमआउट, सेकंड में
`upstream_timeout_sock_read`	`5`	upstream सॉकेट रीड के बीच निष्क्रिय समय, सेकंड में
`upstream_max_concurrency`	`64`	इन-फ़्लाइट upstream अनुरोध
`upstream_max_body_bytes`	`8388608`	अधिकतम बफ़र्ड upstream प्रतिक्रिया बॉडी (8 MiB)। बड़ी बॉडी डिफ़ॉल्ट मिरर पर fail-open होती हैं
`probe_retention_secs`	`604800`	Probe-log TTL (7 दिन)
`probe_max_rows`	`10000`	purge-on-write के बाद अधिकतम probe-log पंक्तियाँ
`alert_timeout_secs`	`5`	आउटबाउंड अलर्ट डिलीवरी के लिए प्रति-चैनल टाइमआउट, सेकंड में

चलाएँ

python -m netward --config config.json

उदाहरण टोपोलॉजी:

घटक	पता
Net Ward	`127.0.0.1:8080`
अपस्ट्रीम ऐप	`http://127.0.0.1:9000`
स्टोरेज	`netward.db`

अपने लोड बैलेंसर या वेब सर्वर को Net Ward की ओर इंगित करें। जब संभव हो, अपस्ट्रीम ऐप को केवल होस्ट या विश्वसनीय नेटवर्क से ही पहुँच योग्य रखें। listen_address को 0.0.0.0:<port> पर केवल तब सेट करें जब आप जानबूझकर Net Ward को localhost से परे पहुँच योग्य बनाना चाहते हों। Linux/macOS पर, storage_path को विश्व-लेखन योग्य (world-writable) न रखें। उदाहरण: chmod 600 netward.db, या chmod 644 netward.db केवल तब जब आप जानबूझकर मॉनिटरिंग के लिए पढ़ने की पहुँच चाहते हों।

संसाधन मॉनिटरिंग

Net Ward अपनी प्रलेखित प्रति-बॉक्स क्षमता को लगातार बनाए रखता है, लेकिन लगातार भारी लोड के बाद Python रनटाइम मेमोरी पूल कार्यशील-सेट स्थिति बनाए रख सकते हैं। लगातार भारी ट्रैफ़िक के तहत Net Ward चलाने वाले ऑपरेटरों को प्रक्रिया संसाधन उपयोग की निगरानी करनी चाहिए और डेमॉन को समय-समय पर पुनः आरंभ करना चाहिए, उदाहरण के लिए साप्ताहिक रूप से या जब RSS बेसलाइन से 2x अधिक हो जाए। v0.5 ऑपरेटर प्रतिक्रिया और स्थानीय परीक्षण अवलोकनों के आधार पर इस मार्गदर्शन को परिष्कृत करेगा, स्वचालित टेलीमेट्री के आधार पर नहीं।

सत्यापित करें

स्वच्छ अनुरोध अपस्ट्रीम तक पहुँचना चाहिए:

curl -i http://127.0.0.1:8080/

ज्ञात प्रोब को मिरर किया जाना चाहिए:

curl -i http://127.0.0.1:8080/wp-admin/

The WordPress probe एक नकली लॉगिन पेज लौटाता है। अपस्ट्रीम सेवा को अनुरोध प्राप्त नहीं होता है।

हैप्पी-पाथ उदाहरण

ऊपर दिए गए उदाहरण टोपोलॉजी के साथ, एक स्वस्थ पहला रन इस तरह दिखना चाहिए:

127.0.0.1:9000 पर एक छोटी अपस्ट्रीम सेवा शुरू करें।
127.0.0.1:8080 पर Net Ward शुरू करें।
Net Ward के माध्यम से / का अनुरोध करें और पुष्टि करें कि अपस्ट्रीम प्रतिक्रिया वापस आती है।
Net Ward के माध्यम से /wp-admin/ का अनुरोध करें और पुष्टि करें कि इसके बजाय एक मिरर प्रतिक्रिया वापस आती है।

अपेक्षित परिणाम: सामान्य ट्रैफ़िक अपस्ट्रीम ऐप तक पहुँचता है, जबकि ज्ञात प्रोब को Net Ward की मिरर लेयर द्वारा संभाला जाता है। यह सबसे सरल संकेत है कि प्रॉक्सी पाथ, पैटर्न मैच और मिरर प्रतिक्रिया सभी काम कर रहे हैं।

ऑपरेटर कमांड

बंडल किए गए वेंडर पैटर्न सेट को इंस्टॉल या रीफ़्रेश करें:

python -m netward.cli --db netward.db install-patterns
python -m netward.cli --db netward.db install-patterns --force

सक्रिय पैटर्न की सूची बनाएं:

python -m netward.cli --db netward.db list-patterns

जांच रिपोर्ट को डेटाबेस में लिखे बिना पढ़ें। रिपोर्ट में समग्र गणनाएँ होती हैं: कौन-से प्रोब परिवार सक्रिय हुए, उन परिवारों ने किन अनुरोध-पथ योगों को हिट किया, और कितने स्रोत शामिल थे। यह कच्चे IP पते या भू-स्थान नहीं दिखाती। --send वही सारांश भेजता है — पथ गणनाओं सहित, कभी भी कच्चे IP नहीं। आउटपुट फ़ाइलें केवल स्वामी के लिए होती हैं (0600)।

netward-standalone

सबसे लोकप्रिय