ioc2rpz™ आपकी थ्रेट इंटेलिजेंस को कार्रवाई योग्य बनाता है

विषय-सूची

संक्षिप्त सारांश
अवलोकन
ioc2rpz™ वह स्थान है जहाँ थ्रेट इंटेलिजेंस DNS से मिलती है
आर्किटेक्चर अवलोकन
ioc2rpz™ का उपयोग कैसे करें
ioc2rpz™ वेब इंटरफ़ेस
प्रोटोकॉल समर्थन
- पोर्ट सारांश
- UDP (पोर्ट 53)
- TCP (पोर्ट 53)
- DNS over TLS / DoT (पोर्ट 853)
- DNS over HTTPS / DoH (पोर्ट 443/8443)
- रेट लिमिटिंग
- DNS NOTIFY
ioc2rpz™ बनाम ISC BIND बनाम अन्य DNS
स्थापना
Docker कंटेनर
पर्यावरण चर
Docker Compose
AWS पर ioc2rpz™
प्रमाणपत्र सेटअप
स्रोत से निर्माण
ioc2rpz™ प्रबंधन
- DNS के माध्यम से
- REST के माध्यम से
निगरानी और स्वास्थ्य जाँच
समस्या निवारण
कॉन्फ़िगरेशन फ़ाइल
पूर्वनिर्धारित कॉन्फ़िगरेशन मान
AXFR और IXFR कैश कैसे अपडेट होते हैं
हॉट कैश
ioc2rpz™ को कैसे आज़माएँ
कुछ मुफ्त थ्रेट इंटेलिजेंस फ़ीड
आगे के दस्तावेज़
संदर्भ
समर्थन / समर्थक
संपर्क करें
लाइसेंस

संक्षिप्त सारांश

ioc2rpz™: DNS सुरक्षा समाधान - ioc2rpz™ एक शक्तिशाली DNS सर्वर है जो खतरे के संकेतकों को कार्रवाई योग्य रिस्पांस पॉलिसी ज़ोन (RPZ) फ़ीड में बदलता है। यह अपडेट प्रक्रिया को स्वचालित करता है, यह सुनिश्चित करता है कि आपका नेटवर्क नवीनतम खतरों से सुरक्षित है, जिसमें दुर्भावनापूर्ण डोमेन और IP पते शामिल हैं। IOC फ़ीड को RPZ में परिवर्तित करके, ioc2rpz™ थ्रेट इंटेलिजेंस और DNS सुरक्षा के बीच एक महत्वपूर्ण कड़ी के रूप में कार्य करता है, जो ISC Bind या PowerDNS जैसे RPZ-समर्थन करने वाले DNS सर्वरों के साथ संगत है।

अवलोकन

DNS इंटरनेट का कंट्रोल प्लेन है। आमतौर पर DNS का उपयोग अच्छे कार्यों के लिए होता है, लेकिन:

इसका उपयोग उपयोगकर्ताओं के स्थान और उनके व्यवहार को ट्रैक करने के लिए किया जा सकता है;
मैलवेयर DNS का उपयोग कमांड और कंट्रोल, डेटा एक्सफ़िल्ट्रेशन या ट्रैफ़िक को पुनर्निर्देशित करने के लिए करता है;
2016 सिस्को वार्षिक सुरक्षा रिपोर्ट के अनुसार, 91.3% मैलवेयर DNS का उपयोग करते हैं;
विज्ञापन कंपनियाँ आमतौर पर विज्ञापन दिखाने के लिए अलग और अस्पष्ट डोमेन का उपयोग करती हैं;
मुफ्त DNS सेवाएँ (जैसे 1.1.1.1, 8.8.8.8, 9.9.9.9 आदि) कुछ चिंताओं को दूर करने में आपकी मदद कर सकती हैं, लेकिन आप अपनी स्वयं की सुरक्षा सेटिंग्स या विज्ञापन फ़िल्टर परिभाषित नहीं कर सकते हैं।

ISC Bind नेमसर्वर का एक डी फैक्टो मानक है। ISC BIND 9.8 में रिस्पांस पॉलिसी ज़ोन (Response Policy Zones) की शुरुआत के साथ, DNS परत पर मैलवेयर की निगरानी करना और उसे नियंत्रित करना एक सरल कार्य बन गया। RPZ PowerDNS रिकर्सर 4.0.0 और बाद के रिलीज़ में समर्थित है। Knot DNS भी आंशिक रूप से RPZ का समर्थन करता है।

पारंपरिक नेटवर्क सुरक्षा समाधानों की तुलना में, एक DNS सर्वर बिना प्रदर्शन प्रभाव के लाखों संकेतकों को संभाल सकता है, लेकिन प्राथमिक DNS सर्वरों पर रिस्पांस पॉलिसी ज़ोन बनाए रखने का कोई स्वचालित और कुशल तरीका नहीं था।

सामान्यतः समझौता संकेतक (indicators of compromise) सादे पाठ में वितरित किए जाते हैं, लेकिन विभिन्न प्रारूपों में, और केवल कुछ IOC प्रदाता उन्हें RPZ के माध्यम से उपलब्ध कराते हैं।

ioc2rpz™ एक कस्टम DNS सर्वर है जो विभिन्न स्रोतों से संकेतकों (जैसे दुर्भावनापूर्ण FQDN, IP) को स्वचालित रूप से RPZ फ़ीड में परिवर्तित करता है और उन्हें स्वचालित रूप से बनाए/अपडेट करता है। फ़ीड को किसी भी ओपन सोर्स और/या व्यावसायिक DNS सर्वर पर वितरित किया जा सकता है जो RPZ का समर्थन करते हैं, जैसे ISC Bind, PowerDNS। आप राउटर, डेस्कटॉप, सर्वर और यहाँ तक कि Raspberry Pi पर भी RPZ फ़िल्टरिंग के साथ अपना स्वयं का DNS सर्वर चला सकते हैं। सिस्टम मेमोरी ही एकमात्र सीमा है।

ioc2rpz™ के साथ आप अपने स्वयं के फ़ीड, क्रियाएँ परिभाषित कर सकते हैं और अवांछित संचार को रोक सकते हैं।

ioc2rpz™ वह स्थान है जहाँ थ्रेट इंटेलिजेंस DNS से मिलती है

ioc2rpz™ IOC फ़ीड को रिस्पांस पॉलिसी ज़ोन (RPZ) में बदलता है। आप एकल RPZ या कई RPZ उत्पन्न करने के लिए फ़ीड मिला सकते हैं। भरोसेमंद डोमेन और IP को व्हाइटलिस्ट किया जा सकता है। ioc2rpz™ संकेतकों की समाप्ति का समर्थन करता है और तदनुसार ज़ोन का पुनर्निर्माण करता है।
Alt ioc2rpz™ वर्तमान रिलीज़ निम्न का समर्थन करती है: स्थानीय फ़ाइलें, http/https/ftp के माध्यम से फ़ाइलें/अनुरोध, और अन्य संसाधन प्रकारों तक पहुँचने के लिए शेल स्क्रिप्ट। आप किसी भी फ़ाइल प्रारूप का उपयोग कर सकते हैं यदि आप संकेतक निकालने के लिए एक REGEX लिख सकते हैं और संकेतक न्यूलाइन या/और कैरिज रिटर्न वर्णों (/n, /r, /r/n) द्वारा अलग किए गए हैं।

आर्किटेक्चर अवलोकन

ioc2rpz Erlang/OTP पर एक सुपरविज़न ट्री के साथ बनाया गया है जो फॉल्ट टॉलरेंस और स्वचालित पुनर्प्राप्ति सुनिश्चित करता है। पूर्ण विवरण के लिए docs/architecture.md देखें।``` ioc2rpz_app (application) └── ioc2rpz_sup (supervisor) ├── ioc2rpz_db_sup — ETS table heir process ├── ioc2rpz_tcp_sup — TCP listener pool (5 workers) ├── ioc2rpz_udp_sup — UDP listener ├── ioc2rpz_tls_sup — TLS/DoT listener pool (5 workers) [if cert configured] └── ioc2rpz_rest_sup — Cowboy HTTPS (REST API + DoH) [if cert configured]

मुख्य मॉड्यूल:

| मॉड्यूल | ज़िम्मेदारी |
|--------|---------------|
| `ioc2rpz.erl` | TCP/TLS DNS वर्कर — स्वीकारें, पार्स करें, मान्य करें, उत्तर दें |
| `ioc2rpz_udp.erl` | UDP DNS श्रोता — SOA क्वेरी |
| `ioc2rpz_conn.erl` | IOC स्रोत लाना (HTTP/HTTPS/फ़ाइल/शेल) |
| `ioc2rpz_db.erl` | ETS-आधारित ज़ोन और पैकेट कैश |
| `ioc2rpz_sup.erl` | मुख्य पर्यवेक्षक, कॉन्फ़िगरेशन लोडिंग, ज़ोन शेड्यूलिंग |
| `ioc2rpz_rest.erl` | REST प्रबंधन API (Cowboy) |
| `ioc2rpz_doh.erl` | DNS-over-HTTPS हैंडलर |

## ioc2rpz™ का उपयोग कैसे करें
आप ioc2rpz™ का उपयोग किसी भी DNS सर्वर के साथ कर सकते हैं जो रिस्पांस पॉलिसी ज़ोन (Response Policy Zones) का समर्थन करता है, जैसे कि ISC BIND के हालिया संस्करण, PowerDNS, और इन उत्पादों पर आधारित कोई भी व्यावसायिक DNS सर्वर (जैसे Infoblox, Blue Cat, Efficient IP)। एक नमूना bind कॉन्फ़िगरेशन फ़ाइल (named.conf) cfg फ़ोल्डर में दी गई है।
<p align="center"><a href="http://www.youtube.com/watch?feature=player_embedded&v=bvhyMFa_mBM" target="_blank"><img src="https://raw.githubusercontent.com/Homas/ioc2rpz/master/ioc2rpz_demo.png"></a></p>

## ioc2rpz™ वेब इंटरफ़ेस
[ioc2rpz.gui](https://github.com/Homas/ioc2rpz.gui) एक प्रबंधन वेब इंटरफ़ेस है जिसे एक अलग प्रोजेक्ट के रूप में विकसित किया गया है। ioc2rpz™ चलाने के लिए यह आवश्यक नहीं है।

## प्रोटोकॉल समर्थन

ioc2rpz™ कई ट्रांसपोर्ट प्रोटोकॉल पर सुनता है। सभी ट्रांसपोर्ट एक ही क्वेरी प्रोसेसिंग पाइपलाइन साझा करते हैं: रेट लिमिटिंग, TSIG सत्यापन, ज़ोन लुकअप, और प्रतिक्रिया निर्माण। पूर्ण प्रोटोकॉल दस्तावेज़ के लिए [docs/protocols.md](https://github.com/homas/ioc2rpz/blob/HEAD/docs/protocols.md) देखें।

### पोर्ट सारांश

| पोर्ट | प्रोटोकॉल | सेवा | शर्त |
|------|----------|---------|-----------|
| 53 | UDP | DNS क्वेरी (केवल SOA) | हमेशा |
| 53 | TCP | DNS क्वेरी, AXFR/IXFR ज़ोन ट्रांसफर, प्रबंधन | हमेशा |
| 853 | TCP+TLS | DoT — TCP के समान लेकिन एन्क्रिप्टेड | `cert` कॉन्फ़िगरेशन आवश्यक है |
| 443/8443 | TCP+TLS | DoH (`/dns-query`) और REST API | `cert` कॉन्फ़िगरेशन आवश्यक है |

### यूडीपी (पोर्ट 53)

यूडीपी का उपयोग हल्के DNS क्वेरी के लिए किया जाता है, मुख्य रूप से SOA लुकअप के लिए। 512 बाइट्स (या EDNS0 द्वारा विज्ञापित बफर आकार) से अधिक के प्रतिक्रियाएं RFC 1035 §4.2.1 के अनुसार TC (ट्रंकेशन) बिट सेट करती हैं, जिससे क्लाइंट TCP पर फिर से प्रयास करते हैं। प्रबंधन कमांड यूडीपी पर समर्थित नहीं हैं।```bash
dig @127.0.0.1 zone.ioc2rpz SOA -y hmac-sha256:keyname:base64key

TCP (Port 53)

TCP ज़ोन ट्रांसफर (AXFR/IXFR), SOA क्वेरी और प्रबंधन कमांड संभालता है। पहले से स्पॉन किए गए 5 एक्सेप्ट वर्कर्स का एक पूल आने वाले कनेक्शनों को संभालता है।```bash

AXFR zone transfer

dig @127.0.0.1 zone.ioc2rpz AXFR +tcp -y hmac-sha256:keyname:base64key

IXFR incremental transfer

dig @127.0.0.1 zone.ioc2rpz IXFR=12345 +tcp -y hmac-sha256:keyname:base64key

### DNS over TLS / DoT (पोर्ट 853)

ioc2rpz™ DoT के माध्यम से RPZ वितरण का समर्थन करता है। TLS लिसनर कॉन्फ़िगरेशन में `cert` रिकॉर्ड मौजूद होने पर पोर्ट 853 पर स्वचालित रूप से शुरू होता है। DoT वही ऑपरेशन सपोर्ट करता है जो TCP करता है (AXFR, IXFR, SOA, management)।

- समर्थित TLS संस्करण: 1.2 और 1.3 (`?TLSVersion = 'tlsv1.2-1.3'`)
- RFC 7858 §3.4 के अनुसार कनेक्शन पुन: उपयोग समर्थित (प्रति TLS सत्र कई क्वेरी, 30 सेकंड की idle timeout)
- TLS PIN समर्थित नहीं है
- DNS NOTIFY संदेश अनएन्क्रिप्टेड (सादे UDP) भेजे जाते हैं
- डिस्क पर फ़ाइलें बदलने पर सर्टिफ़िकेट स्वतः रीफ़्रेश होते हैं (Erlang SSL कैशिंग के कारण ~2 मिनट तक की देरी)

सर्टिफ़िकेट सेटअप के लिए, देखें [Certificate Setup](#certificate-setup)।```bash
# SOA query over DoT
kdig @127.0.0.1 -p 853 zone.ioc2rpz SOA +tls -y hmac-sha256:keyname:base64key

# AXFR over DoT
dig @127.0.0.1 -p 853 zone.ioc2rpz AXFR +tls +tcp -y hmac-sha256:keyname:base64key

DNS over HTTPS / DoH (Port 443/8443)

DoH /dns-query एंडपॉइंट के माध्यम से HTTPS पर DNS रिज़ॉल्यूशन प्रदान करता है। समर्थित विधियाँ:

GET ?dns= क्वेरी पैरामीटर में base64url-एन्कोडेड DNS संदेश के साथ
POST Content-Type: application/dns-message बॉडी के साथ (अधिकतम 4096 बाइट्स; बड़े पेलोड को HTTP 413 मिलता है)

प्रतिक्रियाएँ Content-Type: application/dns-message का उपयोग करती हैं। DoH पूर्ण DNS वायर-फॉर्मेट संदेश ले जाता है और Do53/DoT के समान पथ से संसाधित होता है, इसलिए इसे समान TSIG प्रमाणीकरण विरासत में मिलता है; ज़ोन ट्रांसफ़र (AXFR/IXFR) केवल TCP-आधारित रहते हैं और DoH पर प्रदान नहीं किए जाते हैं।```bash

DoH GET request

curl -H "Accept: application/dns-message"
"https://127.0.0.1:443/dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB" -k

DoH POST request

curl -X POST -H "Content-Type: application/dns-message"
--data-binary @dns_query.bin "https://127.0.0.1:443/dns-query" -k

### दर सीमा

DNS क्वेरी एक बुद्धिमान (हाइब्रिड) कुंजी का उपयोग करके दर-सीमित की जाती हैं, ताकि वैध मल्टी-ज़ोन क्लाइंट को दंडित न किया जाए जबकि क्वेरी-नाम-भिन्नता दुरुपयोग को अवरुद्ध किया जा सके:

- **प्रावधानित ज़ोन + समर्थित QTYPE** (`SOA`/`AXFR`/`IXFR`, क्लास `IN`) और **मान्यता प्राप्त प्रबंधन कमांड** (क्लास `CHAOS`/`TXT`) को प्रति `{client_IP, query_name, query_type}` ट्रैक किया जाता है — इसलिए एक द्वितीयक सर्वर जो कई ज़ोनों (जैसे `rpz1`, `rpz2`, `rpz3`) का पोलिंग/ट्रांसफर करता है और एक IP से प्रबंधन भी करता है, उसे प्रति ज़ोन+प्रकार के अनुसार स्वतंत्र रूप से गिना जाता है।
- **बाकी सब कुछ** (अज्ञात/अप्रावधानित ज़ोन, असमर्थित क्वेरी प्रकार, गलत क्लास, या अपरिचित प्रबंधन नाम) को प्रति `{client_IP}` एकत्रित किया जाता है, ताकि कोई हमलावर क्वेरी नाम बदलकर सीमा को बायपास न कर सके।

जब सीमा पार हो जाती है, सर्वर DNS `REFUSED` प्रतिक्रिया लौटाता है।

| पैरामीटर | डिफ़ॉल्ट | मैक्रो |
|-----------|---------|-------|
| विंडो | 10 सेकंड | `?RATE_LIMIT_WINDOW` (10000 ms) |
| प्रति विंडो अधिकतम अनुरोध (ग्रैन्युलर: ज्ञात ज़ोन+प्रकार / प्रबंधन) | 1 | `?MAX_REQUESTS_PER_WINDOW` |
| प्रति विंडो अधिकतम अनुरोध (एकत्रित: अज्ञात ज़ोन / असमर्थित प्रकार) | 1 | `?MAX_UNKNOWN_REQUESTS_PER_WINDOW` |

दर सीमा सभी DNS क्वेरी ट्रांसपोर्ट (UDP, TCP, TLS, DoH) पर लागू होती है। विंडो और थ्रेशोल्ड को `include/ioc2rpz.hrl` में मैक्रोज़ के माध्यम से कॉन्फ़िगर किया जा सकता है।

### DNS NOTIFY

ज़ोन अपडेट (AXFR या IXFR) के बाद, ioc2rpz™ RPZ `NotifyList` में कॉन्फ़िगर किए गए IP पतों पर UDP के माध्यम से DNS NOTIFY संदेश ([RFC 1996](https://tools.ietf.org/html/rfc1996)) भेजता है। यह द्वितीयक DNS सर्वरों को ज़ोन SOA सीरियल की जाँच करने और यदि सीरियल बदला है तो ट्रांसफर शुरू करने के लिए प्रेरित करता है।```erlang
%% NotifyList in RPZ config — last field before whitelists
{rpz, {"zone.ioc2rpz", ..., ["source1"], ["10.0.0.1", "10.0.0.2"], []}}.

ioc2rpz™ vs ISC BIND vs अन्य DNS:

ioc2rpz™ केवल RPZ वितरण को संभालने के लिए बनाया गया था;
ioc2rpz™ DoT (DNS over TLS) का समर्थन करता है ताकि कोई भी आपके RPZs/indicators पर आसानी से छिपकर न सुन सके;
ioc2rpz™ आधुनिक DNS क्लाइंट्स के लिए DoH (DNS over HTTPS) का समर्थन करता है;
ioc2rpz™ आपकी जितनी आवश्यकता हो उतने RPZs का समर्थन करता है;
ioc2rpz™ live/non cached zones का समर्थन करता है। यह किसी आने वाले अनुरोध द्वारा zones बनाता है;
indicators को विभिन्न स्रोतों और विभिन्न प्रोटोकॉल्स (जैसे REST API कॉल्स के माध्यम से) से प्राप्त किया जा सकता है;
RPZs स्वचालित रूप से अपडेट होते हैं;
IOC समाप्ति समय का उपयोग समय पर समाप्त हुए indicators को हटाने के लिए किया जाता है;
प्रदर्शन और zone transfer समय/आकार/पैकेट्स अनुकूलन।

स्थापना

सेवा को तैनात करने का सबसे आसान तरीका docker hub पर docker containers का उपयोग करना है। Deployment on Docker How-To आप ioc2rpz™ wiki में पा सकते हैं।

Docker कंटेनर

ioc2rpz™ Docker Hub पर उपलब्ध है। बस ioc2rpz™ खोजें। आवश्यक शर्तें:

ioc2rpz™ में कोई कॉन्फ़िगरेशन फ़ाइल नहीं होती, आपको /opt/ioc2rpz/cfg को host system पर किसी directory में mount करना होगा जिसमें कॉन्फ़िगरेशन फ़ाइल (ioc2rpz.conf) हो;
ioc2rpz™ 53/udp (केवल SOA अनुरोध), 53/tcp (AXFR, IXFR, SOA, MGMT), 853/tcp (AXFR, IXFR, SOA, MGMT) और 8443/tcp (REST API, DoH) पोर्ट्स का उपयोग करता है। पोर्ट्स को host system पर exposed किया जाना चाहिए;
ioc2rpz™ तेज़ boot के लिए ETS डेटाबेस को फ़ाइलों में सहेजता है। आप रीस्टार्ट के बाद DB को बनाए रखने के लिए /opt/ioc2rpz/db को host system पर किसी directory में mount कर सकते हैं; आप निम्न command से ioc2rpz™ प्रारंभ कर सकते हैं:``` sudo docker run -d --name ioc2rpz --log-driver=syslog --restart always --mount type=bind,source=/home/ioc2rpz/cfg,target=/opt/ioc2rpz/cfg --mount type=bind,source=/home/ioc2rpz/db,target=/opt/ioc2rpz/db -p53:53 -p53:53/udp -p853:853 -p8443:8443 pvmdel/ioc2rpz

जहाँ होस्ट सिस्टम पर /home/ioc2rpz/cfg, /home/ioc2rpz/db निर्देशिकाएँ हैं।  
आप ``-e`` पैरामीटर के माध्यम से कस्टम कॉन्फ़िगरेशन फ़ाइल का नाम पास कर सकते हैं। जैसे ``-e CONF=./cfg/ioc2rpz2.conf``

## पर्यावरण चर

निम्नलिखित पर्यावरण चर ioc2rpz™ द्वारा उपयोग किए जाते हैं, मुख्य रूप से Docker तैनातियों के लिए प्रासंगिक। इन्हें `config/sys.config.src` और `config/vm.args` में परिभाषित किया गया है।

| चर | डिफ़ॉल्ट | विवरण |
|----------|---------|-------------|
| `IPv4` | — | IPv4 बाइंड पता |
| `IPv6` | — | IPv6 बाइंड पता |
| `CONF` | — | कॉन्फ़िगरेशन फ़ाइल का पथ (उदा. `./cfg/ioc2rpz.conf`) |
| `DB` | `/opt/ioc2rpz/db` | ETS पर्सिस्टेंस के लिए डेटाबेस निर्देशिका |
| `CD` | `/opt/ioc2rpz` | कार्यशील निर्देशिका |
| `NODE_NAME` | `ioc2rpz` | Erlang नोड का छोटा नाम |
| `IO2Cookie` | `ioc2rpz` | Erlang वितरित कुकी |

पर्यावरण चर को `-e` के साथ Docker को पास करें:```bash
docker run -d --name ioc2rpz -e CONF=./cfg/custom.conf -e NODE_NAME=mynode ...

Docker Compose

आप ioc2rpz™ और ioc2rpz.gui को docker compose का उपयोग करके तैनात कर सकते हैं। मानक docker-compose.yml फ़ाइल ioc2rpz.dc रिपॉज़िटरी में पाई जा सकती है।

नीचे एक उदाहरण docker-compose.yml दिया गया है जो ioc2rpz को वेब UI और एक Let's Encrypt certbot sidecar के साथ दिखाता है:```yaml version: "3.8" services: ioc2rpz: image: pvmdel/ioc2rpz container_name: ioc2rpz restart: always logging: driver: syslog ports: - "53:53/tcp" - "53:53/udp" - "853:853/tcp" - "8443:8443/tcp" volumes: - ./cfg:/opt/ioc2rpz/cfg - ./db:/opt/ioc2rpz/db - letsencrypt-certs:/opt/ioc2rpz/ssl:ro

ioc2rpz-gui: image: pvmdel/ioc2rpz.gui container_name: ioc2rpz-gui restart: always ports: - "443:443" depends_on: - ioc2rpz

certbot: image: certbot/certbot container_name: certbot volumes: - letsencrypt-certs:/etc/letsencrypt - letsencrypt-www:/var/www/certbot entrypoint: "/bin/sh -c 'trap exit TERM; while :; do certbot renew --quiet; sleep 12h; done'"

volumes: letsencrypt-certs: letsencrypt-www:

अपने `ioc2rpz.conf` को माउंट किए गए प्रमाणपत्र पथ को संदर्भित करने के लिए अपडेट करें:```erlang
{cert, {"ssl/live/ns1.rpz-proxy.com/fullchain.pem", "ssl/live/ns1.rpz-proxy.com/privkey.pem", ""}}.

AWS पर ioc2rpz™

आप AWS पर ioc2rpz™ और ioc2rpz.gui चला सकते हैं। अपेक्षाकृत छोटे डिप्लॉयमेंट (कई सैकड़ों हजारों इंडिकेटर) के लिए भी फ्री टियर पर्याप्त है। नीचे दिया गया वीडियो दिखाता है कि ECS का उपयोग करके AWS पर ioc2rpz™ और ioc2rpz.gui कैसे सेटअप करें।

प्रमाणपत्र सेटअप

DoT (पोर्ट 853), REST API (पोर्ट 8443) और DoH के लिए TLS प्रमाणपत्र आवश्यक हैं। सभी TLS सेवाओं के लिए एक ही प्रमाणपत्र उपयोग किया जाता है। पूरे विवरण के लिए docs/deployment.md देखें।

सेल्फ-साइन्ड प्रमाणपत्र (डेवलपमेंट)```bash

openssl req -x509 -newkey rsa:2048 -keyout cfg/ioc2rpz_dot.key
-out cfg/ioc2rpz_dot.crt -days 365 -nodes -subj "/CN=ioc2rpz"

### Let's Encrypt (प्रोडक्शन)```bash
# Obtain certificate
sudo certbot certonly --standalone -d ns1.rpz-proxy.com

# Copy to ioc2rpz cfg directory
cp /etc/letsencrypt/live/ns1.rpz-proxy.com/fullchain.pem cfg/ioc2rpz_dot.crt
cp /etc/letsencrypt/live/ns1.rpz-proxy.com/privkey.pem cfg/ioc2rpz_dot.key

स्वचालित नवीनीकरण```bash

/etc/cron.d/ioc2rpz-cert-renew

0 3 * * * root certbot renew --quiet --deploy-hook "cp /etc/letsencrypt/live/ns1.rpz-proxy.com/fullchain.pem /opt/ioc2rpz/cfg/ioc2rpz_dot.crt && cp /etc/letsencrypt/live/ns1.rpz-proxy.com/privkey.pem /opt/ioc2rpz/cfg/ioc2rpz_dot.key"

प्रमाणपत्रों को कॉन्फ़िगरेशन रीलोड (`ioc2rpz-reload-cfg`) के दौरान भी स्पष्ट रूप से पुनः लोड किया जाता है: जब ioc2rpz यह पता लगाता है कि प्रमाणपत्र फ़ाइलें बदल गई हैं, तो यह लगभग ~2 मिनट के Erlang SSL कैश की प्रतीक्षा करने के बजाय, तुरंत नए प्रमाणपत्र के साथ TLS लिसनर को पुनः आरंभ करता है। बिना डाउनटाइम के नए प्रमाणपत्र लागू करने के लिए अपने नवीकरण हुक में एक `ioc2rpz-reload-cfg` चरण जोड़ें।

### डॉकर वॉल्यूम माउंटिंग

डॉकर में चलते समय, प्रमाणपत्र निर्देशिका को होस्ट से माउंट करें:```bash
docker run -d --name ioc2rpz \
  --mount type=bind,source=/etc/letsencrypt/live/ns1.rpz-proxy.com,target=/opt/ioc2rpz/ssl,readonly \
  ...

ioc2rpz.conf में संदर्भ:```erlang {cert, {"ssl/fullchain.pem", "ssl/privkey.pem", ""}}.

Erlang लगभग ~2 मिनट के भीतर बदले गए प्रमाणपत्र फ़ाइलों को स्वचालित रूप से ग्रहण कर लेता है। कॉन्फ़िग रीलोड (`ioc2rpz-reload-cfg`) के दौरान प्रमाणपत्र भी स्पष्ट रूप से रीलोड किए जाते हैं। प्रमाणपत्रों को समाप्त न होने दें — निर्बाध सेवा के लिए समाप्ति से पहले नवीनीकृत करें।

## स्रोत से निर्माण

> **नोट:** स्रोत से निर्माण **विकास और परीक्षण** के लिए है। प्रोडक्शन के लिए, **Docker तैनाती की अनुशंसित विधि है** — [Docker Compose](#docker-compose) और [ioc2rpz.dc](https://github.com/Homas/ioc2rpz.dc) रिपॉज़िटरी देखें।

### पूर्वापेक्षाएँ

- **Erlang/OTP 24 या नया** (जाँचने के लिए `erl -version`) और एक संगत [rebar3](https://www.rebar3.org)।
- एक C टूलचेन (डिपेंडेंसी बनाने के लिए) और `git`।

### बिल्ड और रन```bash
# 1. Clone the repository
git clone https://github.com/Homas/ioc2rpz.git
cd ioc2rpz

# 2. Build a release
rebar3 release

# 3. Edit the configuration (see the minimal example below)
$EDITOR cfg/ioc2rpz.conf

# 4. Start the server (foreground console, or 'start' for background)
_build/default/rel/ioc2rpz/bin/ioc2rpz console
# or: _build/default/rel/ioc2rpz/bin/ioc2rpz start

डिफ़ॉल्ट रूप से ioc2rpz™ अपना कॉन्फ़िगरेशन ./cfg/ioc2rpz.conf से पढ़ता है, सभी नेटवर्क इंटरफेस पर सुनता है, और अपना DB बैकअप ./db में लिखता है। कंपाइल-टाइम डिफ़ॉल्ट (पोर्ट, पथ, टाइमर) include/ioc2rpz.hrl में रहते हैं।

न्यूनतम कॉन्फ़िगरेशन

एक TSIG कुंजी, एक फ़ाइल स्रोत, और एक RPZ ज़ोन के साथ एक न्यूनतम cfg/ioc2rpz.conf:```erlang %% Server NS record, admin mailbox, management key(s), and management ACL {srv,{"ns1.example.com","hostmaster.example.com",["mgmtkey"],["127.0.0.1","::1"]}}.

%% A TSIG key (name, algorithm, base64 secret) used for management / zone transfers {key,{"mgmtkey","sha256","5Yvt70eJnf95+LJeI8H3TgKGeVparmMB7udA0pv/JRE="}}.

%% An IOC source: a local file parsed as a full (AXFR) feed of domains {source,{"sample","file:cfg/small_ioc.txt","[:AXFR:]","^([0-9A-Za-z.-]+\.[0-9A-Za-z.-]+)$","",0,0,0,"mixed",true}}.

%% An RPZ zone built from the source, served with the nxdomain action {rpz,{"rpz.example.com",86400,3600,2592000,7200,"true","true","nxdomain",["mgmtkey"],"mixed",604800,86400,["sample"],[],[]}}.

संपूर्ण फ़ील्ड-दर-फ़ील्ड संदर्भ के लिए [docs/configuration.md](https://github.com/homas/ioc2rpz/blob/HEAD/docs/configuration.md) देखें (source/RPZ tuple लेआउट, SOA टाइमर, कुंजी समूह, प्रमाणपत्र, आदि)। DoT (पोर्ट 853), DoH, और HTTPS REST API सक्षम करने के लिए, एक `{cert,{...}}` प्रविष्टि जोड़ें — [प्रमाणपत्र सेटअप](#certificate-setup) देखें।

### विकास शेल (केवल विकास/परीक्षण)

निम्नलिखित कमांड स्थानीय विकास और परीक्षण के लिए हैं — उत्पादन उपयोग के लिए नहीं:```bash
# Compile only (no release)
rebar3 compile

# Run the EUnit test suite
rebar3 eunit
# Run tests for a single module
rebar3 eunit --module=ioc2rpz_fun

# Start an interactive shell with the application and all deps loaded
rebar3 shell

rebar3 shell में आप चल रहे सिस्टम को सीधे परीक्षण कर सकते हैं, उदाहरण के लिए:```erlang %% Inspect the listener pools and ETS tables supervisor:which_children(ioc2rpz_sup). ets:info(cfg_table, size). ets:info(rpz_hotcache_table, size).

%% Trigger a configuration reload / forced zone update ioc2rpz_sup:reload_config3(reload). ioc2rpz_sup:update_all_zones(true).

## ioc2rpz™ प्रबंधन
### DNS के माध्यम से
ioc2rpz™ DNS/TCP या DoT पर प्रबंधन का समर्थन करता है। DNS/TCP के बजाय DoT या REST API का उपयोग करने की अनुशंसा की जाती है। ioc2rpz™ का वर्तमान संस्करण अलग प्रबंधन IP/इंटरफ़ेस का समर्थन नहीं करता है। किसी भी स्थिति में, केवल प्रबंधन के लिए उपयोग किए जाने वाले एक निर्दिष्ट TSIG कुंजी (या कुंजियाँ) बनाने की अत्यधिक अनुशंसा की जाती है। आप DNS पर प्रबंधन बंद कर सकते हैं।  
समर्थित क्रियाएँ:
- ioc2rpz™ वर्तमान स्थिति। अनुरोध ``ioc2rpz-status``, क्लास ``CHAOS``, रिकॉर्ड ``TXT``। उदा.:```
dig +tcp -y dnsmkey_1:ayVnL+h2QKMszRVohrngagcEuIpN3RkecXKdwSa5WsHD5N4Y5R3NUMGM W8sIGv36gPkAtWtgarqKzN9tmHqEnA== @127.0.0.1 ioc2rpz-status TXT -c CHAOS

कॉन्फ़िगरेशन फ़ाइल पुनः लोड करें। RR Name ioc2rpz-reload-cfg, RR Class CHAOS, RR Type TXT
TSIG कुंजियाँ अपडेट करें। RR Name ioc2rpz-update-tkeys, RR Class CHAOS, RR Type TXT
सभी ज़ोन का पूर्ण रिफ़्रेश करें। RR Name ioc2rpz-update-all-rpz, RR Class CHAOS, RR Type TXT
किसी ज़ोन का पूर्ण रिफ़्रेश करें। RR Name zone_name, RR Class CHAOS, RR Type TXT। उदा. dga.ioc2rpz का पूर्ण रिफ़्रेश निम्न द्वारा लागू किया जा सकता है:``` dig +tcp -y dnsmkey_1:ayVnL+h2QKMszRVohrngagcEuIpN3RkecXKdwSa5WsHD5N4Y5R3NUMGM W8sIGv36gPkAtWtgarqKzN9tmHqEnA== @127.0.0.1 dga.ioc2rpz TXT -c CHAOS

- ioc2rpz™ रोकें। RR Name ``ioc2rpz-terminate``, RR Class ``CHAOS``, RR Type ``TXT``
- नमूना ज़ोन का अनुरोध करें। RR Name ``sample-zone.ioc2rpz``, RR Class ``IN``, RR Type ``AXFR``
### REST के माध्यम से
REST API (पोर्ट 8443/tcp) पसंदीदा प्रबंधन इंटरफ़ेस है। सुरक्षा कारणों से सभी प्रबंधन ट्रैफ़िक को एन्क्रिप्ट किया जाना चाहिए और यदि SSL प्रमाणपत्र नहीं है तो REST API प्रारंभ नहीं होती है। सभी एंडपॉइंट GET और POST दोनों विधियों को स्वीकार करते हैं।

अनुरोधों को प्रमाणित करने के लिए बेसिक HTTP प्रमाणीकरण का उपयोग किया जाता है। अनुरोध प्रमाणीकरण के लिए प्रबंधन TSIG कुंजियों का उपयोग किया जाता है। TSIG कुंजी नाम को HTTP उपयोगकर्ता नाम के रूप में और TSIG कुंजी को पासवर्ड के रूप में उपयोग किया जाता है। REST API तक पहुंच `srv` रिकॉर्ड में परिभाषित ACL द्वारा प्रतिबंधित है।

API संस्करण खंड `v1` और `v1.0` दोनों का समर्थन करता है (उदाहरण के लिए, `/api/v1/stats/serv` या `/api/v1.0/stats/serv`)।

REST API `Accept` हेडर के आधार पर JSON (डिफ़ॉल्ट) और सादा टेक्स्ट आउटपुट का समर्थन करती है:
- `application/json` — JSON आउटपुट (डिफ़ॉल्ट)
- `text/plain` — सादा टेक्स्ट आउटपुट```bash
# Example: plain text output
curl -u "keyname:base64key==" -k -H "Accept: text/plain" https://127.0.0.1:8443/api/v1/mgmt/update_tkeys

पाठ प्रतिक्रियाएँ प्रारूप का उपयोग करती हैं:``` status: ok msg: TSIG keys were updated

#### पथ पैरामीटर

| पैरामीटर | विवरण |
|-----------|-------------|
| `:rpz_name` | RPZ ज़ोन नाम (जैसे `dga.ioc2rpz`) |
| `:source_name` | IOC स्रोत नाम (जैसे `sample_fqdn`) |
| `:ioc` | देखने के लिए संकेतक (FQDN या IP, जैसे `baddomain.com`) |

#### सांख्यिकी एंडपॉइंट्स

`/api/v1/stats/serv` — सर्वर सांख्यिकी (नोड नाम, कुल नियम, मेमोरी उपयोग)```bash
curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/stats/serv

{
  "srv": {
    "node_name": "ioc2rpz@hostname",
    "srv_total_rules": 15000,
    "hot_cache_mem": "12.5 Mb",
    "axfr_table_mem": "45.2 Mb",
    "ixfr_table_mem": "8.1 Mb"
  },
  "rpz": [...],
  "sources": [...]
}

/api/v1/stats/rpz — RPZ ज़ोन आँकड़े```bash curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/stats/rpz

```json
{
  "rpz": [
    {
      "name": "malware.ioc2rpz",
      "status": "ready",
      "rule_count": 5000,
      "ioc_count": 4500,
      "serial": 1709000000,
      "serial_ixfr": 1708990000,
      "update_time": 1709000000,
      "ixfr_update_time": 1708995000,
      "ixfr_nz_update_time": 1708995000
    }
  ]
}

status फ़ील्ड (ready, updating, forceAXFR, notready) इंगित करता है कि रिपोर्ट की गई गणनाएँ/सीरियल वर्तमान हैं या नहीं; जब updating या forceAXFR होता है तो वे अंतिम पूर्ण किए गए अपडेट को दर्शाते हैं। कॉन्फ़िगरेशन रीलोड के दौरान गणनाएँ और सीरियल शून्य पर रीसेट होने के बजाय संरक्षित रहते हैं।

/api/v1/stats/source — स्रोत आँकड़े```bash curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/stats/source

```json
{
  "sources": [
    {"name": "sample_fqdn", "ioc_count": 150}
  ]
}

प्रबंधन एंडपॉइंट्स

/api/v1/mgmt/reload_cfg — कॉन्फ़िगरेशन फ़ाइल पुनः लोड करें```bash curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/mgmt/reload_cfg

सफलता: `{"status":"ok","msg":"Configuration reloaded"}`
त्रुटि (HTTP 520): `{"status":"error","msg":"Configuration reload error"}`

`/api/v1/mgmt/update_tkeys` — कॉन्फ़िगरेशन से TSIG कुंजियाँ पुनः लोड करें```bash
curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/mgmt/update_tkeys

सफलता: {"status":"ok","msg":"TSIG keys were updated"} त्रुटि (HTTP 520): {"status":"error","msg":"TSIG keys update error"}

/api/v1/mgmt/terminate — सर्वर का सुचारू रूप से बंद होना```bash curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/mgmt/terminate

सफलता: `{"status":"ok","msg":"Terminating"}`

#### ज़ोन अपडेट एंडपॉइंट्स

`/api/v1/update/all_rpz` — सभी RPZ ज़ोन का पूर्ण रिफ्रेश बलपूर्वक करें```bash
curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/update/all_rpz

सफलता: {"status":"ok","msg":"All RPZ zones will be updated"}

/api/v1/update/:rpz_name — किसी विशिष्ट ज़ोन का पूर्ण रिफ्रेश फोर्स करें```bash curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/update/dga.ioc2rpz

सफलता: `{"status":"ok","msg":"RPZ dga.ioc2rpz will be updated"}`
त्रुटि (HTTP 520): `{"status":"error","msg":"RPZ dga.ioc2rpz not found"}`

#### कैश प्रबंधन एंडपॉइंट

`/api/v1/cache/sources/clear/all` — हॉट कैश से सभी स्रोत हटाएँ```bash
curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/cache/sources/clear/all

सफलता: {"status":"ok","msg":"All sources were removed from the hotcache"}

/api/v1/cache/sources/clear/:source_name — किसी विशिष्ट स्रोत को हॉट कैश से हटाएं```bash curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/cache/sources/clear/sample_fqdn

सफलता: `{"status":"ok","msg":"sample_fqdn source was removed from the hot cache"}`

`/api/v1/cache/sources/load/all` — सभी स्रोतों को हॉट कैश में फिर से लोड करें```bash
curl -u "keyname:base64key==" -k https://127.0.0.1:8443/api/v1/cache/sources/load/all

सफलता: {"status":"ok","msg":"All sources will loaded to the hot cache"}

फ़ीड और IOC क्वेरी एंडपॉइंट्स

/api/v1/feed/:rpz_name — RPZ फ़ीड से इंडिकेटर प्राप्त करें

क्वेरी पैरामीटर: ?type=fqdn|ip|both (डिफ़ॉल्ट: both)```bash curl -u "keyname:base64key==" -k "https://127.0.0.1:8443/api/v1/feed/malware.ioc2rpz?type=fqdn"

सफलता:```json
{
  "status": "ok",
  "rpz": "malware.ioc2rpz",
  "iocs": ["baddomain.com", "evil.example.org"]
}

त्रुटि (HTTP 520): {"status":"error","msg":"RPZ malware.ioc2rpz not found"}

/api/v1/ioc/:ioc — जाँचें कि क्या कोई इंडिकेटर किसी RPZ फ़ीड द्वारा ब्लॉक किया गया है

क्वेरी पैरामीटर: ?tkey=keyname — खोज को उस कुंजी द्वारा सुलभ ज़ोन तक सीमित करें (वैकल्पिक)```bash curl -u "keyname:base64key==" -k "https://127.0.0.1:8443/api/v1/ioc/baddomain.com?tkey=dnsproxykey_1"

सफलता:```json
{
  "ioc": "baddomain.com",
  "tkey": "dnsproxykey_1",
  "data": [
    {
      "ioc": "baddomain.com",
      "feeds": [
        {
          "feed": "malware.ioc2rpz",
          "wildcard": "true",
          "type": "fqdn",
          "rpz_serial": 1709000000,
          "ioc_expiration": 0,
          "sources": ["abuse-ch", "internal-list"]
        }
      ]
    }
  ]
}

त्रुटि: {"status":"error", "ioc": "nonexistent.com"}

जब सोर्स ट्रैकिंग सक्षम होती है, तो additive sources फ़ील्ड प्रति फ़ीड योगदान देने वाले स्रोत नाम(नों) को सूचीबद्ध करती है; जब ट्रैकिंग अक्षम होती है या एट्रिब्यूशन अज्ञात होता है, तो यह null होती है। कॉन्फ़िगरेशन और अर्थ के लिए IOC Source Attribution देखें।

असमर्थित एंडपॉइंट्स

कोई भी अपरिचित पथ HTTP 200 के साथ लौटाता है:```json {"status":"error","msg":"Unsupported request"}

## निगरानी और स्वास्थ्य जाँच

### REST API आँकड़े```bash
# Server statistics
curl -u "keyname:key==" -k https://127.0.0.1:8443/api/v1/stats/serv

# RPZ zone statistics (indicator counts, serials, update times)
curl -u "keyname:key==" -k https://127.0.0.1:8443/api/v1/stats/rpz

# Source statistics
curl -u "keyname:key==" -k https://127.0.0.1:8443/api/v1/stats/source

Erlang शेल जाँच

यदि आप इंटरैक्टिव शेल में चल रहे हैं या किसी चालू नोड से जुड़े हैं:```erlang %% Check supervisor children supervisor:which_children(ioc2rpz_sup). supervisor:count_children(ioc2rpz_tls_sup_v6). supervisor:count_children(ioc2rpz_tcp_sup_v6).

%% Check ETS table sizes (memory usage) ets:info(cfg_table, size). ets:info(rpz_hotcache_table, size). ets:info(rate_limits, size).

### DNS स्वास्थ्य जाँच```bash
# SOA query over UDP
dig @localhost -p 53 your-zone.rpz SOA +short

# Zone transfer over TCP
dig @localhost -p 53 your-zone.rpz AXFR +tcp -y hmac-sha256:keyname:base64key

# DoT query
dig @localhost -p 853 +tls your-zone.rpz SOA

# Sample zone (built-in test zone)
dig @localhost sample-zone.ioc2rpz AXFR +tcp

देखें docs/deployment.md पूर्ण निगरानी और लॉग संदर्भ के लिए।

समस्या निवारण

विस्तृत समस्या निवारण के लिए देखें docs/deployment.md।

कॉन्फ़िगरेशन फ़ाइल

कॉन्फ़िगरेशन एक Erlang फ़ाइल है। हर कॉन्फ़िगरेशन विकल्प एक Erlang टर्म है, इसलिए कॉन्फ़िगरेशन को Erlang सिंटैक्स का पालन करना चाहिए। सर्वर लोड/रीलोड पर कॉन्फ़िगरेशन प्रविष्टियों को मान्य करता है: TSIG कुंजी एन्कोडिंग, प्रमाणपत्र फ़ाइल अस्तित्व, regex संकलन, और URL सिंटैक्स। अमान्य प्रविष्टियाँ लॉग की जाती हैं और छोड़ दी जाती हैं। पूर्ण कॉन्फ़िगरेशन संदर्भ के लिए देखें docs/configuration.md।

ioc2rpz™ निम्नलिखित कॉन्फ़िगरेशन पैरामीटर समर्थन करता है:

एक एकल srv रिकॉर्ड (आवश्यक);
एक एकल cert रिकॉर्ड (वैकल्पिक);
शून्य या अधिक key रिकॉर्ड (वैकल्पिक);
शून्य या अधिक whitelist रिकॉर्ड (वैकल्पिक);
एक या अधिक source रिकॉर्ड (न्यूनतम एक स्रोत आवश्यक है);
एक या अधिक rpz रिकॉर्ड (न्यूनतम एक rpz आवश्यक है)।

srv रिकॉर्ड

srv रिकॉर्ड का उपयोग सर्वर डिफ़ॉल्ट मानों को परिभाषित करने के लिए किया जाता है। इसमें शामिल है:

SOA रिकॉर्ड में उपयोग किया जाने वाला NS सर्वर नाम;
SOA रिकॉर्ड के लिए एक ईमेल पता (SOA प्रारूप में);
प्रबंधन TSIG कुंजियों की सूची (केवल नाम)। विवरण के लिए कृपया प्रबंधन अनुभाग देखें।
REST API पहुँच नियंत्रण के लिए ACL IP पतों की सूची।
(वैकल्पिक) TrackSources — स्रोत आरोपण के लिए सर्वर-स्तरीय वैश्विक डिफ़ॉल्ट: off | auto | on (डिफ़ॉल्ट off)। किसी भी फ़ीड पर लागू होता है जिसका अपना track_sources सेट नहीं है। देखें IOC स्रोत आरोपण।

नमूना srv रिकॉर्ड:``` {srv,{"ns1.example.com","support.email.example.com",["dnsmkey_1","dnsmkey_2","dnsmkey_3"],["acl_ip1","acl_ip2"]}}.

%% With the optional global source-tracking default (5-field form): {srv,{"ns1.example.com","support.email.example.com",["dnsmkey_1"],["acl_ip1"],auto}}.

The 4-field form remains valid and defaults `TrackSources` to `off`.
### **cert** रिकॉर्ड
**cert** रिकॉर्ड का उपयोग DNS over TLS, REST API, और DoH संचार के लिए एक प्रमाणपत्र और एक निजी कुंजी परिभाषित करने के लिए किया जाता है। प्रमाणपत्र निर्माण और प्रबंधन के लिए, [Certificate Setup](#certificate-setup) देखें।

इसमें शामिल हैं:
- प्रमाणपत्र वाली फ़ाइल का पथ;
- निजी PEM-एन्कोडेड कुंजी वाली फ़ाइल का पथ;
- PEM-एन्कोडेड CA प्रमाणपत्रों वाली फ़ाइल का पथ।  

नमूना **cert** रिकॉर्ड:```
{cert,{"cfg/cert.pem", "cfg/key.pem",	"cfg/cacerts.pem"}}.

include रिकॉर्ड

include रिकॉर्ड ioc2rpz™ कॉन्फ़िगरेशन को कई फ़ाइलों में विभाजित करने की अनुमति देता है।

नमूना include रिकॉर्ड:``` {include,"cfg/tkeys.include.cfg"}.

### **key** रिकॉर्ड
TSIG कुंजियों का उपयोग प्रमाणीकरण और प्राधिकरण के लिए किया जाता है। अनुशंसा की जाती है कि ioc2rpz™ प्रबंधन और ज़ोन ट्रांसफ़र के लिए अलग-अलग TSIG कुंजियों का उपयोग करें।  
**key** रिकॉर्ड में निम्न शामिल हैं:
- TSIG कुंजी का नाम;
- एल्गोरिदम। ``md5``, ``sha256`` और ``sha512`` समर्थित हैं;
- कुंजी;
- (वैकल्पिक) उन कुंजी समूहों की सूची जिनसे यह संबंधित है।

नमूना **key** रिकॉर्ड:```
{key,{"key_name_1","md5","ayVnL+h2QKMszRVohrngagcEuIpN3RkecXKdwSa5WsHD5N4Y5R3NUMGM W8sIGv36gPkAtWtgarqKzN9tmHqEnA=="}}.
{key,{"key_name_2","sha256","5Yvt70eJnf95+LJeI8H3TgKGeVparmMB7udA0pv/JRE="}}.
{key,{"key_name_3","sha512","03uuaGl9kqfenjRgIeCv6e29lVvMwviB1+cDX1I0jcVOcTU4jWFwRkfo3ULRMD+NGDfwzYvXkJ94FNEaAW4vzw==",["customers","public"]}}.

dnssec-keygen उपयोगिता का उपयोग TSIG कुंजियाँ उत्पन्न करने के लिए किया जा सकता है:```bash

MD5 (512-bit)

dnssec-keygen -a HMAC-MD5 -b 512 -n USER tsig-key

SHA-256 (256-bit)

dnssec-keygen -a HMAC-SHA256 -b 256 -n USER tsig-key

SHA-512 (512-bit)

dnssec-keygen -a HMAC-SHA512 -b 512 -n USER tsig-key

विवरण के लिए कृपया "dnssec-keygen" प्रलेख देखें। RPZ ज़ोन अभिगम नियंत्रण में समूह-आधारित प्राधिकरण के लिए कुंजियों को समूहों को सौंपा जा सकता है।

### **key_group** रिकॉर्ड
कुंजी समूह ज़ोन स्थानांतरण और प्रबंधन के लिए समूह-आधारित प्राधिकरण प्रदान करते हैं। `rpz` या `srv` रिकॉर्ड्स में व्यक्तिगत कुंजियों को सूचीबद्ध करने के बजाय, आप कुंजियों को नामित समूहों को सौंप सकते हैं और समूह का संदर्भ ले सकते हैं।

कुंजियों को समूहों को सौंपने के दो तरीके हैं:
1. इनलाइन `key` रिकॉर्ड के वैकल्पिक चौथे फ़ील्ड के माध्यम से: `{key, {Name, Alg, Secret, [Groups]}}`
2. स्पष्ट रूप से `key_group` रिकॉर्ड के माध्यम से (नीचे दिखाया गया है)```erlang
{key_group, {GroupName, [KeyName1, KeyName2, ...]}}.

Field	Type	Description
GroupName	string	समूह का नाम (जैसे `"customers"`)
Keys	list of strings	इस समूह से संबंधित TSIG कुंजी नामों की सूची

नमूना key_group रिकॉर्ड:```erlang {key_group, {"customers", ["dnsproxykey_1", "dnsproxykey_2"]}}. {key_group, {"public", ["dnsproxykey_3"]}}.

समूहों को `rpz` और `srv` रिकॉर्ड्स में keys सूची में `{groups, ["group1", "group2"]}` टपल का उपयोग करके संदर्भित किया जाता है:```erlang
{rpz, {"zone.ioc2rpz", 7202, 3600, 2592000, 7200, "true", "true", "nxdomain",
       ["dnsproxykey_1", {groups, ["customers", "public"]}],
       "fqdn", 86400, 3600, ["source1"], [], []}}.

whitelist रिकॉर्ड

व्हाइटलिस्ट का उपयोग संभावित त्रुटियों को रोकने और विश्वसनीय डोमेन तथा IP पतों को ब्लॉक होने से बचाने के लिए किया जाता है। व्हाइटलिस्ट किए गए IOCs को response policy zones से हटा दिया जाता है। ioc2rpz™ केवल सटीक मिलान की जाँच करता है, इसलिए यदि किसी ब्लॉक किए गए सबनेट में कोई व्हाइटलिस्ट किया गया IP पता शामिल है, तो यह किसी नेटवर्क को विभाजित या अस्वीकार नहीं करेगा, और इसके विपरीत भी। व्हाइटलिस्ट एक टेक्स्ट फ़ाइल या टेक्स्ट डेटा का फ़ीड है। संकेतकों को न्यूलाइन वर्णों (/n,/r या दोनों /n/r) द्वारा अलग किया जाना चाहिए। व्हाइटलिस्ट में मान्य FQDNs और/या IP पते होने चाहिए। ioc2rpz™ असीमित संख्या में संकेतकों का समर्थन करता है।
whitelists रिकॉर्ड में निम्न शामिल होते हैं:

व्हाइटलिस्ट का नाम;
व्हाइटलिस्ट पथ। URLs(http/https/ftp) और स्थानीय फ़ाइलें समर्थित हैं। स्थानीय फ़ाइलों के लिए उपसर्ग "file:" का उपयोग किया जाता है;
REGEX जिसका उपयोग संकेतकों को निकालने के लिए किया जाता है। एक regular expression को दोहरे उद्धरण चिह्नों में शामिल किया जाना चाहिए। यदि आप एक खाली REGEX ("") निर्दिष्ट करते हैं, तो एक डिफ़ॉल्ट REGEX का उपयोग किया जाएगा ("^([A-Za-z0-9][A-Za-z0-9\-\._]+)[^A-Za-z0-9\-\._]*.*$")। यदि कोई REGEX आवश्यक नहीं है, तो none का उपयोग किया जाता है (स्रोत पहले से ही आवश्यक प्रारूप में डेटा प्रदान करता है)।

नमूना whitelist रिकॉर्ड:``` {whitelist,{"whitelist_1","file:cfg/whitelist1.txt",none}}.

### **source** रिकॉर्ड
एक स्रोत दुर्भावनापूर्ण संकेतकों (indicators) का एक फीड है। FQDNs, IPv4 और IPv6-पते समर्थित हैं। एक स्रोत एक टेक्स्ट फ़ाइल या टेक्स्ट डेटा का फीड है। संकेतकों को न्यूलाइन/कैरिज रिटर्न वर्णों (/n,/r या दोनों /r/n) द्वारा अलग किया जाना चाहिए। ioc2rpz™ संकेतकों की असीमित संख्या का समर्थन करता है।  
**source** रिकॉर्ड में निम्न शामिल हैं:
- स्रोत नाम;
- पूर्ण स्रोत स्थानांतरण (AXFR) के लिए स्रोत पथ। URLs(http/https/ftp), स्थानीय फ़ाइलें और स्क्रिप्ट समर्थित हैं। स्थानीय फ़ाइलों के लिए उपसर्ग **file:** उपयोग किया जाता है। होस्ट/कंटेनर पर स्थानीय स्क्रिप्ट/कमांड निष्पादित करने के लिए उपसर्ग **shell:** उपयोग किया जाता है, जिसे STDOUT पर संकेतक और वैकल्पिक समाप्ति तिथि लौटानी चाहिए;
- वृद्धिशील स्रोत स्थानांतरण (IXFR) के लिए स्रोत पथ। AXFR,IXFR पथ URL को छोटा करने और ज़ोन अद्यतन टाइमस्टैम्प प्रदान करने के लिए कीवर्ड का समर्थन करते हैं:
  - **[:AXFR:]** - पूर्ण AXFR पथ। केवल IXFR पथों में उपयोग किया जा सकता है;
  - **[:FTimestamp:]** - टाइमस्टैम्प जब स्रोत को अंतिम बार अद्यतन किया गया था (उदा. 1507946281)
  - **[:ToTimestamp:]** - वर्तमान टाइमस्टैम्प;
- REGEX जिसका उपयोग संकेतकों और उनके समाप्ति समय को निकालने के लिए किया जाता है। पहला मैच संकेतक होता है, दूसरा मैच समाप्ति समय होता है। समाप्ति समय एक वैकल्पिक पैरामीटर है। एक रेगुलर एक्सप्रेशन को दोहरे उद्धरणों में शामिल किया जाना चाहिए। यदि आप खाली REGEX (`""`) निर्दिष्ट करते हैं, तो एक डिफ़ॉल्ट REGEX उपयोग होगा (`"^([A-Za-z0-9][A-Za-z0-9\-\._]+)[^A-Za-z0-9\-\._]*.*$"`). यदि कोई REGEX आवश्यक नहीं है तो `none` उपयोग किया जाता है (स्रोत पहले से ही आवश्यक प्रारूप में डेटा प्रदान करता है)।
वैकल्पिक पैरामीटर (सभी या कोई भी उपयोग नहीं किया जाना चाहिए):
- UserID (आंतरिक रूप से उपयोग किया जाता है)।
- IoCs की अधिकतम संख्या।
- पूर्ण स्रोत अद्यतन, हॉट कैश समय (सेकंड में)।
- वृद्धिशील स्रोत अद्यतन, हॉट कैश समय (सेकंड में)।

HTTPS स्रोत डाउनलोड रिमोट सर्वर के TLS प्रमाणपत्र को सत्यापित करते हैं। अमान्य या स्व-हस्ताक्षरित प्रमाणपत्रों वाले स्रोत डाउनलोड करने में विफल होंगे। स्व-हस्ताक्षरित प्रमाणपत्रों के लिए, `curl --insecure` के साथ `shell:` स्रोत का उपयोग करें।

**स्थानीय फ़ाइल प्रतिबंध:** `file:` पथ जिनमें `..` (पैरेंट-डायरेक्टरी ट्रैवर्सल) होता है, सुरक्षा के लिए अस्वीकार कर दिए जाते हैं; `..` के बिना पथ उपयोग करें (कार्य/डेटा निर्देशिका के भीतर)।

**शेल कमांड प्रतिबंध:** प्रत्येक पाइपलाइन खंड का निष्पादन योग्य एक निरपेक्ष पथ (जैसे `/usr/bin/curl`) या एक सादा-नाम सुरक्षित पाठ उपयोगिता (`sort`, `uniq`, `grep`, `sed`, `awk`, `gawk`, आदि) होना चाहिए; विनाशकारी कमांड और शेल (`rm`, `bash`, `sh`, आदि) अवरुद्ध हैं, और कमांड प्रतिस्थापन (`$(...)`, बैकटिक्स) और आउटपुट पुनर्निर्देशन (`>`, `>>`) अस्वीकार कर दिए जाते हैं। अस्वीकृत कमांड निष्पादित नहीं होते हैं और CEF इवेंट 151 के माध्यम से लॉग किए जाते हैं (निष्पादित कमांड 150 के माध्यम से)। पूर्ण नियम सेट के लिए [docs/configuration.md](https://github.com/homas/ioc2rpz/blob/HEAD/docs/configuration.md#shell-command-restrictions) देखें।

यदि कोई स्रोत अपनी पिछली संकेतक संख्या के 50% से कम लौटाता है, तो अद्यतन अस्वीकार कर दिया जाता है और पिछला डेटा बनाए रखा जाता है। यह घटिया फीड को RPZ कवरेज कम करने से रोकता है। `?SOURCE_MIN_IOC_RATIO` मैक्रो के माध्यम से कॉन्फ़िगर करने योग्य।

नमूना **source** रिकॉर्ड:```
%% Local file source — indicators without expiration
{source,{"sample_fqdn","file:cfg/sample_ioc_fqdn.txt","[:AXFR:]",none}}.

%% Local file source — indicators with expiration timestamps (tab-separated)
{source,{"sample_expire","file:cfg/sample_ioc_expire.txt","[:AXFR:]","^([A-Za-z0-9][A-Za-z0-9\-\._]+)\t([0-9TZ:\-]+)$"}}.

%% Shell source — fetch RPZ via AXFR and extract CNAMEs
{source,{"base.rpz1","shell:/usr/bin/dig -y KEYNAME:TSIGKEY @127.0.0.1 base.rpz.ioc2rpz.local axfr | /bin/grep -e CNAME | /bin/grep -v '*.' | /usr/bin/awk -F '.base.rpz' '{print $1}'","",none}}.

स्रोत shell: का उपयोग ioc2rpz™ कनेक्टिविटी विकल्पों को बढ़ाने के लिए किया जाता है, जो मूल रूप से कुछ सीमित हैं। ioc2rpz™ कंटेनर में dig, grep, awk और python शामिल हैं। उदा. आप विभिन्न RPZ फ़ीड मिश्रित कर सकते हैं या डेटाबेस से डेटा प्राप्त कर सकते हैं।

शेल कमांड प्रतिबंध: सभी निष्पादनयोग्य फ़ाइलों को पूर्ण पथ का उपयोग करना चाहिए (जैसे /usr/bin/curl न कि curl)। विनाशकारी कमांड (rm, bash, sh, आदि) अवरुद्ध हैं। कमांड प्रतिस्थापन ($(...), बैकटिक्स) और आउटपुट पुनर्निर्देशन (>, >>) अस्वीकार कर दिए जाते हैं। पूर्ण विवरण के लिए docs/configuration.md देखें।

स्थानीय फ़ाइल सुरक्षा: .. (पैरेंट डायरेक्टरी ट्रैवर्सल) वाले फ़ाइल पथ सुरक्षा के लिए अस्वीकार कर दिए जाते हैं।

rpz रिकॉर्ड

RPZ शब्द एक रिस्पॉन्स पॉलिसी ज़ोन को परिभाषित करता है।
rpz रिकॉर्ड में निम्न शामिल हैं:

rpz नाम;
सेकंड में SOA रिफ्रेश समय;
सेकंड में SOA अपडेट रिट्री समय;
सेकंड में SOA समाप्ति समय;
सेकंड में SOA NXDomain TTL;
कैश। संभावित मान: true या false। true परिभाषित करता है कि RPZ को कैश किया जाना चाहिए, false - गैर-कैश, लाइव ज़ोन स्रोत डाउनलोड किए जाते हैं और AXFR अनुरोध द्वारा RPZ जनरेट होता है। "लाइव" ज़ोन इंक्रीमेंटल ज़ोन ट्रांसफर का समर्थन नहीं करते। यदि RPZ फ़ीड कैश नहीं है, तो भी इसे अस्थायी रूप से हॉट कैश में संग्रहीत किया जाता है। यदि क्लाइंट से अनुरोध टाइमआउट हो जाता है, तो हम अगली बार उत्तर देने में सक्षम होंगे। कैश जीवन निर्धारित करने के लिए AXFR समय का उपयोग किया जाएगा;
वाइल्डकार्ड। संभावित मान: true या false। परिभाषित करता है कि वाइल्डकार्ड नियम उत्पन्न किए जाने चाहिए या नहीं;
कार्रवाई। नीचे दी गई RPZ क्रियाएँ तालिका देखें;
TSIG कुंजियों और कुंजी समूहों की सूची;
RPZ में उपयोग किए गए IOC के प्रकार: mixed, fqdn, ip। यह अनुकूलन के लिए उपयोग किया जाता है।
सेकंड में पूर्ण ज़ोन अपडेट समय (AXFR Time)। यदि IOC के लिए MD5 भिन्न हो तो पूर्ण ज़ोन अपडेट और पुनर्निर्माण;
इंक्रीमेंटल ज़ोन अपडेट समय (IXFR Time)। स्रोतों को इंक्रीमेंटल अपडेट का समर्थन करना चाहिए। "0" का अर्थ है कोई इंक्रीमेंटल ज़ोन अपडेट नहीं;
स्रोतों की सूची;
DNS सर्वरों (IP पते) की सूची जिन्हें RPZ अपडेट पर सूचित किया जाना चाहिए (देखें );

RPZ क्रियाएँ

एकाधिक स्थानीय क्रियाओं को एक सूची में संयोजित किया जा सकता है: [{"local_a","127.0.0.1"},{"local_aaaa","fe80::1"},{"local_txt","Blocked"}]

नमूना rpz रिकॉर्ड:``` {rpz,{"zone_name",soa_refresh, soa_update_retry,soa_expire,soa_nxdomain_ttl,"cache","wildcards","action",["key1","key2"],"Zone_type",AXFT_Time, IXFR_Time,["source1","source2"],["notify_ip1","notify_ip2"],["whitelist_1","whitelist_2"]}}.

{rpz,{"zone_name",soa_refresh, soa_update_retry,soa_expire,soa_nxdomain_ttl,"cache","wildcards","action",["key1","key2",{groups,["group1","group2"]}],"Zone_type",AXFT_Time, IXFR_Time,["source1","source2"],["notify_ip1","notify_ip2"],["whitelist_1","whitelist_2"]}}.

{rpz,{"mixed.ioc2rpz",7202,3600,2592000,7200,"true","true","passthru",["dnsproxykey_1","dnsproxykey_2"],"mixed",86400,3600,["sample_fqdn","sample_expire","sample_ip"],[],["whitelist_1","whitelist_2"]}}.

{rpz,{"mixed.ioc2rpz",7202,3600,2592000,7200,"true","true","passthru",["dnsproxykey_1","dnsproxykey_2",{groups,["public","ip2"]}],"mixed",86400,3600,["sample_fqdn","sample_expire","sample_ip"],[],["whitelist_1","whitelist_2"]}}.

%% With explicit per-feed source tracking (16-field form; trailing auto): {rpz,{"mixed.ioc2rpz",7202,3600,2592000,7200,"true","true","passthru",["dnsproxykey_1"],"mixed",86400,3600,["sample_fqdn","sample_expire","sample_ip"],[],["whitelist_1"],auto}}.

### IOC स्रोत एट्रिब्यूशन
एक RPZ फीड कई स्रोतों से संकेतकों को मर्ज करके बनाई जाती है। स्रोत एट्रिब्यूशन IOC-लुकअप API को रिपोर्ट करने देता है कि **किसी फीड के भीतर कौन से स्रोत** ने एक संकेतक में योगदान दिया — जो किसी रिपोर्ट किए गए गलत-सकारात्मक की जाँच में उपयोगी है। ट्रैकिंग **डिफ़ॉल्ट रूप से बंद** होती है और प्रति फीड एक वैकल्पिक सर्वर-स्तरीय वैश्विक डिफ़ॉल्ट के साथ नियंत्रित होती है।

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

- प्रति-फीड: `{rpz,{...}}` टपल का वैकल्पिक अंतिम (16वाँ) `TrackSources` तत्व — `auto | true | false`.
- सर्वर वैश्विक डिफ़ॉल्ट: `{srv,{...}}` टपल का वैकल्पिक अंतिम (5वाँ) `TrackSources` तत्व — `off | auto | on` (डिफ़ॉल्ट `off`)।

दोनों वैकल्पिक और पिछड़े-संगत हैं: मौजूदा कॉन्फ़िग फ़ाइलें (15-फ़ील्ड `rpz`, 4-फ़ील्ड `srv`) बिना परिवर्तन के लोड होती हैं और बंद की तरह व्यवहार करती हैं।

**समाधान वरीयता** — किसी फीड के लिए प्रभावी स्थिति इस प्रकार हल होती है:
1. फीड का स्पष्ट `track_sources` मान, यदि सेट है;
2. अन्यथा सर्वर वैश्विक डिफ़ॉल्ट;
3. अन्यथा अंतर्निहित डिफ़ॉल्ट `off`।

`auto` का अर्थ है: केवल **बहु-स्रोत** फीड को ट्रैक करना। एकल-स्रोत फीड कभी छिपाई नहीं जातीं — उनका एकमात्र स्रोत नाम सीधे लौटाया जाता है (कोई ट्रैकिंग लागत नहीं)।

**API — योजक `sources` फ़ील्ड**

`/api/v1/ioc/:ioc` प्रतिक्रिया में प्रत्येक फीड ऑब्जेक्ट पर एक नया `sources` फ़ील्ड जुड़ता है। यह **योजक और पिछड़ा-संगत** है: सभी मौजूदा फ़ील्ड अपरिवर्तित रहते हैं, इसलिए पुराने क्लाइंट जो इसे अनदेखा करते हैं, काम करते रहते हैं।

- ट्रैक की गई बहु-स्रोत फीड: योगदान देने वाले स्रोत नामों की एक JSON सरणी।
- एकल-स्रोत फीड: उस एक स्रोत नाम के साथ एक-तत्व वाली सरणी।
- ट्रैकिंग अक्षम, या एट्रिब्यूशन अज्ञात (जैसे कि उसके वन-टाइम AXFR पुनर्निर्माण से पहले की पूर्व-अपग्रेड कैश की गई पंक्ति): `null` (JSON) / `(disabled)` या `(unavailable)` (TXT)।```json
{
  "feed": "mixed.ioc2rpz",
  "wildcard": "true",
  "type": "fqdn",
  "rpz_serial": 1709000000,
  "ioc_expiration": 0,
  "sources": ["abuse-ch", "internal-list"]
}

एकल-स्रोत फ़ीड: "sources": ["sample_fqdn"]। ट्रैकिंग अक्षम/अज्ञात: "sources": null।

रोलआउट (डिफ़ॉल्ट रूप से बंद)

बाइनरी को अपग्रेड करने से कुछ भी नहीं बदलता — न ट्रैकिंग, न ज़ोन रीबिल्ड, न अपरिवर्तित API — जब तक track_sources मान सेट न किया जाए। फ़ीड GUI-प्रबंधित हैं; GUI/कम्युनिटी साइट इन वैकल्पिक कॉन्फ़िग मानों को लिखेगी और बाद के अपडेट में sources को प्रदर्शित करेगी। कैश्ड फ़ीड के लिए ट्रैकिंग सक्षम करने से सोर्स मास्क को भरने के लिए एक बार का AXFR रीबिल्ड ट्रिगर होता है।

सीमाएँ

एट्रिब्यूशन केवल कैश्ड फ़ीड्स (cache = "true") के लिए उपलब्ध है, क्योंकि API लुकअप IXFR कैश तालिका पढ़ता है।
मास्क पूर्ण AXFR रीबिल्ड के बाद आधिकारिक होते हैं। IXFR अपडेट पर, नए जोड़े गए इंडिकेटर्स के लिए मास्क सही ढंग से सेट होते हैं, लेकिन पहले से मौजूद इंडिकेटर के लिए मास्क परिवर्तन (दूसरा स्रोत किसी मौजूदा IOC को सूचीबद्ध करना शुरू करता है) अगले AXFR पर ही समायोजित हो सकता है।
सोर्स मास्क प्रति-ज़ोन स्थितीय होते हैं (बिट i = i-वां स्रोत)। किसी ज़ोन की सोर्स सूची को पुनः क्रमबद्ध करना या संपादित करना एक बार का AXFR रीबिल्ड बाध्य करता है (सोर्स-सिग्नेचर जाँच के माध्यम से पता लगाया जाता है) ताकि मास्क पुनः व्युत्पन्न हों।
63 से अधिक स्रोतों वाले फ़ीड व्यापक बाइनरी बिटमैप मास्क (डिफ़ॉल्ट) का उपयोग करते हैं ताकि एट्रिब्यूशन सही बना रहे।

नमूना कॉन्फ़िगरेशन फ़ाइल (विस्तार करने के लिए क्लिक करें)

```erlang {srv,{"ns1.rpz-proxy.com","support.rpz-proxy.com",["dnsmkey_3"],["127.0.0.1","10.42.0.10"]}}. {cert,{"cfg/ioc2rpz_dot.crt", "cfg/ioc2rpz_dot.key", ""}}.

{key,{"dnsproxykey_1","md5","apXqLsDs90H213eV6LS9ryYp5tY8YTpkttOkRCve7dp1Zeob3SGAbaVU9BShpsW25MmR8mTiX5OY0Qetv977Yw=="}}. {key,{"dnsproxykey_2","sha512","03uuaGl9kqfenjRgIeCv6e29lVvMwviB1+cDX1I0jcVOcTU4jWFwRkfo3ULRMD+NGDfwzYvXkJ94FNEaAW4vzw=="}}. {key,{"dnsmkey_3","sha512","03uuaGl9kqfenjRgIeCv6e29lVvMwviB1+cDX1I0jcVOcTU4jWFwRkfo3ULRMD+NGDfwzYvXkJ94FNEaAW4vzw=="}}.

{whitelist,{"whitelist_1","file:cfg/sample_whitelist.txt",none}}. {whitelist,{"whitelist_2","file:cfg/whitelist2.txt",""}}.

{source,{"sample_fqdn","file:cfg/sample_ioc_fqdn.txt","[:AXFR:]",none}}. {source,{"sample_expire","file:cfg/sample_ioc_expire.txt","[:AXFR:]","^([A-Za-z0-9][A-Za-z0-9\-\._]+)\t([0-9TZ:\-]+)$"}}. {source,{"sample_ip","file:cfg/sample_ioc_ip.txt","[:AXFR:]",none}}.

{rpz,{"localdata.ioc2rpz",7202,3600,2592000,7200,"false","true",[{"local_aaaa","fe80::1"},{"local_a","127.0.0.1"},{"local_a","127.0.0.2"},{"local_a","127.0.0.3"},{"local_a","127.0.0.4"},{"local_cname","www.example.com"},{"local_txt","Text Record www.example.com"},{"local_txt","Text Record 2"}],["dnsproxykey_1", "dnsproxykey_2"],"mixed",30,30,["sample_fqdn"],[],["whitelist_1","whitelist_2"]}}. {rpz,{"dga.ioc2rpz",7202,3600,2592000,7200,"true","true","nodata",["dnsproxykey_1","dnsproxykey_2"],"fqdn",172800,3600,["sample_expire"],[],[]}}. {rpz,{"mixed.ioc2rpz",7202,3600,2592000,7200,"true","true","passthru",["dnsproxykey_1", "dnsproxykey_2"],"mixed",86400,3600,["sample_fqdn","sample_expire"],[],["whitelist_1","whitelist_2"]}}. {rpz,{"ip-block.ioc2rpz",7202,3600,2592000,7200,"false","true","nxdomain",["dnsproxykey_1","dnsproxykey_2"],"ip",172800,0,["sample_ip"],[],[]}}.

</details>

## पूर्वनिर्धारित कॉन्फ़िगरेशन मान - include/ioc2rpz.hrl
include/ioc2rpz.hrl में पूर्व-संकलित पैरामीटर होते हैं।

मानक पैरामीटर:
- ``MGMToDNS`` (true/false) - DNS/TCP पर प्रबंधन सक्षम करता है;
- ``DBStorage`` (ets) - AXFR और IXFR कैश के लिए DB संग्रहण परिभाषित करता है। वर्तमान संस्करण केवल ETS का समर्थन करता है;
- ``SaveETS`` (true/false) - परिभाषित करता है कि ETS AXFR/IXFR तालिकाओं को डिस्क पर सहेजा जाना चाहिए या नहीं;
- ``Port`` (संख्यात्मक मान, 1 - 65535) - उस DNS पोर्ट को परिभाषित करता है जिस पर सेवा चल रही है;
- ``PortTLS`` (संख्यात्मक मान, 1 - 65535) - उस DoT पोर्ट को परिभाषित करता है जिस पर सेवा चल रही है;
- ``PortREST`` (संख्यात्मक मान, 1 - 65535) - उस HTTPs पोर्ट को परिभाषित करता है जिस पर सेवा चल रही है;
- ``TTL`` (संख्यात्मक मान, सेकंड में) - DNS रिकॉर्ड/RPZ नियमों के लिए डिफ़ॉल्ट TTL।
- ``DefConf`` (string) - डिफ़ॉल्ट कॉन्फ़िगरेशन फ़ाइल;
- ``DefDB`` (string) - डिफ़ॉल्ट डेटाबेस पथ;
- ``logTS`` - यदि परिभाषित किया जाता है तो लॉग संदेशों में टाइमस्टैम्प जोड़ा जाता है;
- ``debug`` - यदि परिभाषित किया जाता है तो डीबग लॉग संदेश मुद्रित किए जाते हैं;
- ``TLSVersion`` ('tlsv1.2-1.3') - DoT और REST API के लिए समर्थित TLS संस्करण;

अनुकूलन पैरामीटर:
- ``DNSPktMax`` (संख्यात्मक मान, 100 - 65535) - अधिकतम पैकेट आकार। अनुशंसित मान:
  - 16384 - न्यूनतम ज़ोन ट्रांसफर आकार;
  - 65535 - DNS पैकेटों की न्यूनतम संख्या;
- ``Compression`` (संख्यात्मक मान, 0 - 9) - संपीड़न स्तर (0 - कोई संपीड़न नहीं, 9 - उच्चतम संपीड़न)। AXFR कैश और डिस्क पर तालिकाएँ संपीड़ित डेटा संग्रहीत करती हैं;
- ``ZoneRefTime`` (संख्यात्मक मान, मिलीसेकंड में) - ज़ोन रिफ्रेश जाँच अंतराल परिभाषित करता है;
- ``TCPTimeout`` (संख्यात्मक मान, मिलीसेकंड में) - TCP सत्र टाइमआउट परिभाषित करता है;
- ``HotCacheTime`` (संख्यात्मक मान, सेकंड में) - IOCs, नियम, पैकेट के लिए हॉट कैश समय। लाइव ज़ोन हॉट कैश में संग्रहीत किए जाते हैं;
- ``HotCacheTimeIXFR`` (संख्यात्मक मान, सेकंड में) - हॉट कैश में IXFR IOCs के लिए हॉट कैश समय। डिफ़ॉल्ट रूप से IXFR संकेतक एक मिनट के लिए कैश किए जाते हैं (भले ही इसे 0 पर सेट किया गया हो) क्योंकि वर्तमान सीरियल हमेशा पिछले मिनट तक पूर्णांकित होता है;
- ``RATE_LIMIT_WINDOW`` (संख्यात्मक मान, मिलीसेकंड में, डिफ़ॉल्ट 10000) - प्रति IP दर सीमा विंडो अवधि;
- ``MAX_REQUESTS_PER_WINDOW`` (संख्यात्मक मान, डिफ़ॉल्ट 1) - प्रति दर सीमा विंडो में प्रति IP अधिकतम DNS अनुरोध;
- ``ShellMaxRespSize`` (संख्यात्मक मान, डिफ़ॉल्ट 2 GiB) - शेल कमांड स्रोतों के लिए अधिकतम प्रतिक्रिया आकार;
- ``SourcePullTimeout`` (संख्यात्मक मान, मिलीसेकंड में, डिफ़ॉल्ट 300000) - स्रोत डाउनलोड के लिए टाइमआउट (5 मिनट);

## AXFR (पूर्ण) और IXFR (वृद्धिशील) कैश कैसे अपडेट किए जाते हैं
- AXFR कैश में हमेशा SOA/NS/TSIG रिकॉर्ड के बिना पूर्व-निर्मित ज़ोन होते हैं। पूर्व-निर्मित का अर्थ है कि सभी रिकॉर्ड पैकेट द्वारा विभाजित किए जाते हैं और लेबल छोटे/ज़िप किए गए थे।
- यदि किसी सर्वर को AXFR अनुरोध मिलता है, तो वह AXFR कैश से पैकेट प्राप्त करता है, आवश्यक होने पर SOA/NS रिकॉर्ड और TSIG जोड़ता है।
- AXFR ज़ोन अपडेट को एक सफाई प्रक्रिया माना जाना चाहिए, जो समय-समय पर होती रहनी चाहिए। बस यह सुनिश्चित करने के लिए कि स्रोतों और कैश के बीच कोई डिसिंक्रनाइज़ेशन न हो।
- बड़े ज़ोन के लिए, AXFR अपडेट को सर्वर के प्रदर्शन और सभी क्लाइंट्स को हस्तांतरित डेटा की मात्रा पर प्रभाव को कम करने के लिए कभी-कभार शेड्यूल किया जाना चाहिए।
- यदि संभव हो तो सभी परिवर्तन वृद्धिशील ज़ोन अपडेट के माध्यम से किए जाने चाहिए। उस स्थिति में AXFR कैश केवल तभी पुनर्निर्मित किया जाएगा जब कोई ज़ोन अपडेट किया गया हो।
- [TODO] अनुकूलन के कारण, नए IOCs के लिए केवल अंतिम पैकेट और समाप्त IOCs के लिए प्रासंगिक एवं अनुरूप पैकेट पुनर्निर्मित किए जाएंगे।
- IXFR कैश में केवल IOCs और समाप्ति तिथियां होती हैं। [TODO] और पैकेट ID (ज़ोन को तेज़ी से पुनर्निर्मित करना संभव बनाने के लिए)।
- RPZ रिकॉर्ड में वर्तमान ज़ोन Serial और Serial_IXFR होते हैं। Serial_IXFR न्यूनतम वृद्धिशील ज़ोन सीरियल के रूप में कार्य करता है जो वृद्धिशील ज़ोन ट्रांसफर के लिए उपलब्ध है।
- पूर्ण ज़ोन अपडेट (AXFR) के बाद IXFR कैश खाली कर दिया जाता है। Serial_IXFR = Serial। क्लाइंट्स को किसी भी स्थिति में पूर्ण ज़ोन अपडेट प्राप्त होगा, यही कारण है कि AXFR ज़ोन ट्रांसफर कम बार होना महत्वपूर्ण है।
- जब IXFR कैश अपडेट होता है, AXFR कैश का पुनर्निर्माण किया जाना चाहिए।
- यदि कोई ज़ोन IXFR अपडेट का समर्थन नहीं करता है -> तो यह IXFR तालिका में सहेजा नहीं जाता है।
- लाइव ज़ोन AXFR, IXFR कैश में कैश नहीं किए जाते हैं, लेकिन स्रोत (IOCs) हॉट कैश में कैश किए जा सकते हैं।

## हॉट कैश
सभी IOCs, नियम, पैकेट (लाइव RPZs सहित) हॉट कैश में संग्रहीत किए जाते हैं। पूर्व-संकलित पैरामीटर ``HotCacheTime``, ``HotCacheTimeIXFR`` भंडारण समय परिभाषित करते हैं।

## ioc2rpz™ कैसे आज़माएं (या ioc2rpz™ द्वारा होस्ट किए गए नमूने और मुफ्त RPZ फ़ीड)
### अस्वीकरण
लेखक इन RPZ फ़ीड की सामग्री में किसी भी त्रुटि या चूक के लिए कोई ज़िम्मेदारी या दायित्व नहीं लेता है। फ़ीड केवल ioc2rpz™ तकनीक प्रदर्शित करने के लिए "जैसा है" आधार पर प्रदान की जाती हैं, जिनमें पूर्णता, सटीकता, उपयोगिता या समयबद्धता की कोई गारंटी नहीं होती। RPZ फ़ीड सेवा का वितरण बिना किसी पूर्व सूचना के बाधित या बंद हो सकता है। इस सेवा का उपयोग करने से हुई किसी भी प्रत्यक्ष या अप्रत्यक्ष क्षति के लिए लेखक उत्तरदायी नहीं है।

### RPZ फ़ीड
यदि आप [ioc2rpz™ समुदाय](https://ioc2rpz.net) पर निम्नलिखित फ़ीड के साथ पंजीकरण करते हैं, तो आप ioc2rpz™ तकनीक का परीक्षण कर सकते हैं:
- [notracking](https://github.com/notracking/hosts-blocklists);
- [Phishtank](https://www.phishtank.com/);

### नमूना bind कॉन्फ़िगरेशन```
options {
  #This is just options for RPZs. Add other options as required
  recursion yes;
  response-policy {
    ####FQDN only zones
    ####Mixed zones
    zone "phishtank.ioc2rpz" policy nxdomain;
    ####IP only zones
  } qname-wait-recurse no break-dnssec yes;
};

key "ioc2rpz-YOUR-UNIQUE-KEY-NAME"{
  algorithm hmac-sha256; secret "ioc2rpz-YOUR-UNIQUE-KEY";
};

zone "phishtank.ioc2rpz" {
  type slave;
  file "/var/cache/bind/phishtank.ioc2rpz";
  masters {94.130.30.123  key "ioc2rpz-YOUR-UNIQUE-KEY-NAME";};
};

पोर्ट पहले से उपयोग में है	`lsof -i :53` / `lsof -i :853` से जाँचें। त्वरित पुनर्प्रारंभ के लिए लिसन सॉकेट्स पर `{reuseaddr, true}` सेट होता है।
DoT कनेक्शन स्वीकार नहीं कर रहा	सत्यापित करें कि `{cert, ...}` कॉन्फ़िगर किया गया है। TLS वर्कर्स जाँचें: `supervisor:count_children(ioc2rpz_tls_sup_v6).` जाँचें कि पोर्ट 853 फ़ायरवॉल नहीं किया गया है।
ज़ोन ट्रांसफ़र विफल (TSIG mismatch)	सत्यापित करें कि कुंजी का नाम और गुप्त मान क्लाइंट और सर्वर के बीच मेल खाते हैं। लॉग्स में CEF 104/105 इवेंट देखें।
स्रोत डाउनलोड विफलताएँ	नेटवर्क कनेक्टिविटी जाँचें। लॉग्स में `Error downloading feed` देखें। सर्वर 3s की देरी के साथ 3 बार पुनः प्रयास करता है। HTTPS स्रोतों के लिए, मान्य TLS प्रमाणपत्र सुनिश्चित करें।
उच्च मेमोरी उपयोग	Erlang शेल में ETS तालिका आकार जाँचें। `rate_limits` और `rpz_hotcache_table` समय-समय पर साफ़ होते हैं। `?HotCacheTime` कम करने पर विचार करें।

NXDOMAIN	`"nxdomain"`	NXDOMAIN लौटाएँ (डोमेन मौजूद नहीं है)
NODATA	`"nodata"`	खाली उत्तर लौटाएँ (डोमेन मौजूद है, कोई रिकॉर्ड नहीं)
Passthru	`"passthru"`	क्वेरी की अनुमति दें (छूट नियम)
Drop	`"drop"`	क्वेरी को चुपचाप छोड़ दें
TCP-Only	`"tcp-only"`	क्लाइंट को TCP पर पुनः प्रयास करने के लिए बाध्य करें
Block NS	`"blockns"`	अधिकृत नेमसर्वर को अवरुद्ध करें
Redirect (domain)	`{"redirect_domain","example.com"}`	निर्दिष्ट डोमेन पर पुनर्निर्देशित करें (`local_cname` के लिए उपनाम)
Redirect (IP)	`{"redirect_ip","127.0.0.1"}`	निर्दिष्ट IP पर पुनर्निर्देशित करें (`local_a`/`local_aaaa` के लिए उपनाम)
Local A	`{"local_a","127.0.0.1"}`	एक कस्टम IPv4 पता लौटाएँ
Local AAAA	`{"local_aaaa","fe80::1"}`	एक कस्टम IPv6 पता लौटाएँ
Local CNAME	`{"local_cname","www.example.com"}`	एक CNAME पुनर्निर्देशन लौटाएँ
Local TXT	`{"local_txt","Text Record"}`	एक TXT रिकॉर्ड लौटाएँ

ioc2rpz

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

नमूना PowerDNS कॉन्फ़िगरेशन```

नमूना DIG (SOA पाने के लिए)```