एक सिस्टम पर जहाँ आप परिणामों (*.tap फ़ाइलें) की समीक्षा कर रहे हैं, आप tappy स्थापित करना चाह सकते हैं। परिणाम प्रत्येक प्रोबर नोड पर स्थानीय git रिपॉजिटरी में रखे जाते हैं (डिफ़ॉल्ट रूप से, /var/run/prober/results/ में, कॉन्फ़िगरेशन विकल्पों के लिए नीचे देखें), प्रत्येक स्कैनिंग रन की समाप्ति तिथि के साथ टैग किए गए कमिट के साथ, ऐतिहासिक रिकॉर्ड और आसान तुलना के लिए।

संचालन

Ansible का उपयोग प्रोबर नोड्स पर परीक्षण उत्पन्न करने के लिए किया जाता है। एक प्रोबर नोड कोई भी FreeBSD या GNU/Linux होस्ट हो सकता है, जब तक उस पर Prober की निर्भरताएँ स्थापित करना संभव है। इसे परीक्षण के लिए समर्पित होने की आवश्यकता नहीं है, लेकिन अनुशंसा की जाती है — एक उचित आकार के नेटवर्क का स्कैन घंटों लग सकता है, बहुत अधिक CPU का उपयोग करता है, और काफी ट्रैफ़िक उत्पन्न करता है।

विभिन्न निगरानी बिंदुओं (उदाहरण के लिए: आंतरिक नेटवर्क, DMZ, इंटरनेट) से अपने नेटवर्क की जाँच करने के लिए विभिन्न मशीनों पर Prober तैनात करना समझ में आता है।

प्रोबर नोड्स पर परीक्षण निर्देशिका में परीक्षण चलाने की सुविधा के लिए एक run-tests.sh स्क्रिप्ट बनाई जाती है। परीक्षण इस तरह से चलाए जाते हैं कि हर समय <simultaneous_tests_count> परीक्षण एक साथ चल रहे हों — यह चर मुख्य तरीका है जिससे प्रोबिंग स्कैन कितने संसाधनों का उपयोग करता है और कितनी बैंडविड्थ की आवश्यकता है, इसे नियंत्रित किया जाता है।

परीक्षण के परिणाम तब स्थानीय git रिपॉजिटरी में सहेजे जाते हैं, जिसमें कमिट को किसी दिए गए रन की समाप्ति तिथि (जो कुछ लंबे प्रोबिंग रन के लिए प्रारंभ तिथि से भिन्न हो सकती है) से टैग किया जाता है।

यदि केवल कुछ होस्ट से बड़े बुनियादी ढांचे से निपट रहे हैं, तो Mitogen जैसे उपकरण का उपयोग परीक्षण उत्पादन को नाटकीय रूप से गति देने के लिए समझ में आ सकता है।

त्वरित आरंभ

1. Debian या FreeBSD सर्वर को प्रोबर नोड के रूप में उपयोग करने के लिए तैयार करें (इसे prober.example.com कहते हैं), सुनिश्चित करें कि आपके पास SSH पहुँच है और उस पर sudo कर सकते हैं।

2. उदाहरण इन्वेंट्री को inventories/test/ के रूप में कॉपी करें।

3. उस test इन्वेंट्री में:

   1. group_vars/all.yml संपादित करें और zone_nameserver, zone_domains, address_blocks को अपनी पसंद के अनुसार सेट करें; मान लें कि आप example.com को जांचे जाने वाले एकमात्र डोमेन के रूप में जोड़ते हैं
   2. hosts फ़ाइल संपादित करें, अपने prober.example.com प्रोबर नोड को [prober-nodes] अनुभाग में कॉन्फ़िगर करें; मान लें कि आप tested_zone को test पर सेट करते हैं।

4. उदाहरण ज़ोन कॉन्फ़िग को data/<tested_zone>.yml (हमारे मामले में: data/test.yml) के रूप में कॉपी करें और संपादित करें; न्यूनतम रूप से, tested_zone_settings.name कुंजी में tested_zone (यानी, test) होना चाहिए।

5. अपने DNS ज़ोन को निर्यात करें और इसे data/<dns_zone>.zone (हमारे मामले में: example.com) के रूप में सहेजें।

6. प्लेबुक चलाएँ:

   root@kitploit:~

   ansible-playbook prober.yml -i inventories/test/ -vvv
   

   इससे प्रोबर नोड पर परीक्षण उत्पन्न होंगे और उन्हें प्रति रात्रि 01:00 AM पर चलाने के लिए एक क्रॉनजॉब सेट होगा।

अब आप प्रोबर नोड में ssh कर सकते हैं और /opt/prober/ में उत्पन्न परीक्षणों का निरीक्षण कर सकते हैं। एक बार संतुष्ट होने पर, आप उन्हें /opt/prober/run_tests.sh निष्पादित करके चला सकते हैं। परिणाम /var/run/prober/results में सहेजे जाएंगे।

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

कॉन्फ़िगरेशन चर (probers.yml में परिभाषित):

• tests_directory (डिफ़ॉल्ट: /opt/prober):
  प्रोबर नोड्स पर वह निर्देशिका जहाँ परीक्षण फ़ाइलें (*.bats फ़ाइलें) उत्पन्न की जाती हैं।

• results_repo_directory (डिफ़ॉल्ट: /var/run/prober/results):
  परीक्षण परिणामों (*.tap फ़ाइलें) के लिए रिपॉजिटरी की निर्देशिका; वहाँ एक git रिपॉजिटरी आरंभ की जाती है और वास्तविक परिणामों के लिए एक tap/ उपनिर्देशिका बनाई जाती है; परिणाम git रिपॉजिटरी में प्रतिबद्ध किए जाते हैं, कमिट को yyyy-mm-dd प्रारूप में एक तारीख से टैग किया जाता है (उदाहरण के लिए, 19 मार्च, 2020 को समाप्त हुए परीक्षण के परिणामों वाला कमिट 2020-03-19 के रूप में टैग किया जाता है)।

• simultaneous_tests_count (डिफ़ॉल्ट: 20):
  एक साथ कितने परीक्षण चलाए जाते हैं।

• prober_dev (डिफ़ॉल्ट: अपरिभाषित):
  कुछ कार्यों को छोड़ें जो डेव मशीन पर समझ में नहीं आते (जैसे cron या zabbix सेट करना)।

ज़ोन

ज़ोन ./data/<zone_name>.yml फ़ाइलों में परिभाषित होते हैं जिनमें शीर्ष कुंजी स्ट्रिंग "tested_zone_settings" होती है, जिसमें तब कुंजियाँ होती हैं:

• name: ज़ोन का नाम, फ़ाइल नाम (बिना एक्सटेंशन) से मेल खाता है; उदाहरण के लिए: "internal", "external", "dmz"
• default (वैकल्पिक): इस ज़ोन के सभी होस्ट के लिए डिफ़ॉल्ट सेटिंग्स
• regex कुंजियाँ (अनिवार्य रूप से "^" वर्ण से शुरू होती हैं) जो कई FQDN से मेल खाती हैं
• प्रत्येक FQDN के लिए कुंजी जिसे स्पष्ट कॉन्फ़िगरेशन की आवश्यकता है

default कुंजी, प्रत्येक regex कुंजी और प्रत्येक डोमेन कुंजी में ये कुंजियाँ हो सकती हैं:

• resolve: क्या होस्ट प्रासंगिक IP पते पर हल होना चाहिए (बूल true/false, या स्ट्रिंग "skip")
• ping: क्या होस्ट को ping का जवाब देना चाहिए (बूल true/false, या स्ट्रिंग "skip")
• ports: TCP और UDP पोर्टों की सूची जिन्हें खुलने की अनुमति है (उप-कुंजियाँ "tcp" और "udp", प्रत्येक में पूर्णांकों की एक सरणी जो खुले रहने की अनुमति वाले पोर्टों को परिभाषित करती है, या स्ट्रिंग "skip"), और TLS-सक्षम पोर्ट जिनकी गहन जाँच की जानी है (tls उप-कुंजी, जिसमें पोर्ट नंबरों को कुंजी के रूप में और TLS सेवा के प्रकार या शब्द "skip" को मान के रूप में युक्त dict होता है)
  ports: "skip" निम्नलिखित का संक्षिप्त रूप है:
  root@kitploit:~

  ports:
    tcp: "skip"
    udp: "skip"
    tls: "skip"
  

  TLS सेवा प्रकार वही हैं जो testssl.sh -t/--starttls विकल्प के लिए समर्थन करता है, HTTPS परीक्षण (हेडर सहित) के लिए "https", या सामान्य TLS परीक्षण के लिए "tls"।
  सूचना: TLS परीक्षण तब तक नहीं चलाए जाते जब तक कि पोर्ट को "tcp" कुंजी में भी खुले के रूप में चिह्नित न किया गया हो।
• skip: क्या होस्ट को पूरी तरह से छोड़ दिया जाना चाहिए (बूलियन)

आप यहाँ एक उदाहरण कॉन्फ़िग देख सकते हैं।

ग्लोबल डिफ़ॉल्ट probers.yml में परिभाषित हैं। प्रत्येक जांचे गए होस्ट के लिए इन्हें तब प्रासंगिक ज़ोन डिफ़ॉल्ट के साथ combine किया जाता है, फिर regex कुंजियों के साथ जो किसी दिए गए होस्टनाम से मेल खाती हैं, और अंत में विशिष्ट होस्ट सेटिंग्स के साथ।

इसका मतलब है कि किसी दिए गए ज़ोन में विशिष्ट होस्ट सेटिंग्स regex मिलान की गई कुंजियों की सेटिंग्स पर प्राथमिकता लेती हैं, जो बदले में ज़ोन डिफ़ॉल्ट पर प्राथमिकता लेती हैं, जो बदले में ग्लोबल डिफ़ॉल्ट पर प्राथमिकता लेती हैं।

ports कुंजी को थोड़ा विशेष रूप से माना जाता है: यदि कॉन्फ़िगरेशन वंशावली श्रृंखला में कहीं कुछ पोर्ट सूचीबद्ध हैं, तो उन्हें श्रृंखला में नीचे हटाना असंभव है, केवल अतिरिक्त पोर्ट नंबर जोड़ना या किसी दिए गए प्रोटोकॉल के सभी पोर्टों के लिए परीक्षणों को "skip" करना संभव है।

ज़ोन फ़ाइलें प्रत्येक प्रोबर नोड के लिए सेट किए गए tested_zone चर के आधार पर चुनी जाती हैं।

प्रति-IP परीक्षण बनाम प्रति-होस्टनाम परीक्षण

कुछ परीक्षण अलग-अलग IP पतों के संदर्भ में समझ में आते हैं, भले ही कितने डोमेन/होस्टनाम उन पर हल हों; उदाहरण के लिए, यह जाँचना कि क्या कुछ पोर्ट खुले हैं। उदाहरण के लिए, मान लें कि a.example.com और b.example.com एक ही IP पते पर इशारा करते हैं। ऊपर दिए गए उदाहरण कॉन्फ़िगरेशन के साथ, इसका मतलब है कि पोर्ट 8080/tcp और 8443/tcp दोनों खुले होने चाहिए, और 8443/tcp पर HTTPS की अपेक्षा की जाती है।

कुछ परीक्षण विशेष डोमेन/होस्टनाम और IP पते के संयोजन के संदर्भ में समझ में आते हैं; उदाहरण के लिए, यदि किसी विशिष्ट IP पते पर किसी विशिष्ट डोमेन नाम के लिए प्रस्तुत TLS प्रमाणपत्र मान्य है।

इन दो प्रकार के परीक्षणों को लक्ष्यों की दो अलग-अलग सूचियाँ उत्पन्न करके लागू किया जाता है:

• प्रति-IP सूची, जहाँ प्रत्येक तत्व इस रूप में है:
  <ip-address> <hostname1> (<hostname2> <hostname3> ... <hostnameN>)
  इस सूची में IP पते दोहराए नहीं जाने चाहिए;
• प्रति-होस्टनाम सूची, जहाँ प्रत्येक तत्व इस रूप में है:
  <ip-address> <hostname>
  इस सूची में IP पते दोहराए जा सकते हैं।

फिर कुछ परीक्षण फ़ाइलें केवल पहली सूची के लक्ष्यों के लिए उत्पन्न की जाती हैं (उदाहरण के लिए, खुले पोर्ट परीक्षण), और कुछ केवल दूसरी सूची के लक्ष्यों के लिए (उदाहरण के लिए, TLS-संबंधित)।

पोर्ट और परीक्षण

कुछ परीक्षण तब तक समझ में नहीं आते जब तक कि कुछ पोर्ट खुले न हों। TLS-संबंधित परीक्षण किसी दिए गए होस्ट के लिए केवल तभी उत्पन्न होते हैं यदि किसी भी प्रासंगिक TCP पोर्ट को दिए गए ज़ोन में open के रूप में कॉन्फ़िगर किया गया हो।

डिफ़ॉल्ट रूप से, यदि कोई भी ज्ञात TLS-सक्षम पोर्ट ports.tcp कुंजी में खुले के रूप में कॉन्फ़िगर किया गया है, तो उनके लिए TLS परीक्षण उत्पन्न होंगे। ज्ञात TLS-सक्षम पोर्टों की सूची default_host_settings चर में परिभाषित है।

FAQ

सामान्य तौर पर, Prober और कई अन्य समान उपकरणों या सेवाओं के बीच अंतर आमतौर पर किसी संयोजन तक सीमित होता है:

• स्व-होस्टेड होना, जिसमें Prober नोड्स को आपके बुनियादी ढांचे के अंदर या बाहर किसी भी स्थान पर तैनात किया जा सकता है;
• नियमित, पुनरुत्पादन योग्य स्कैन पर ध्यान केंद्रित करना जो अच्छी तरह से परिभाषित, कॉन्फ़िगर करने योग्य धारणाओं को सत्यापित करते हैं;
• आपको परीक्षण रनों के शेड्यूल पर नियंत्रण देना, और कच्चे स्कैन परिणामों तक पहुँच प्रदान करना।

यह Shodan से कैसे अलग है?

Shodan इंटरनेट को क्रॉल करके उजागर सिस्टम खोजता है। Prober आपके अपने बुनियादी ढांचे को क्रॉल करके उसके बारे में आपकी धारणाओं को सत्यापित करता है, जितने चाहें उतने निगरानी बिंदुओं से। यह अच्छी तरह से परिभाषित परीक्षणों और नियमित, निर्धारित रनों के माध्यम से परिणामों की पुनरुत्पादन क्षमता पर ध्यान केंद्रित करता है, और प्रत्येक परीक्षण की गई धारणा के लिए एक बूलियन "पास/फेल" परिणाम प्रदान करने का प्रयास करता है (निरीक्षण के लिए पूर्ण स्कैन परिणाम डेटा उपलब्ध होने के साथ)।

यह BitSight से कैसे अलग है?

BitSight आपके बुनियादी ढांचे के बारे में उनके विचार से उचित धारणाओं को सत्यापित करता है, आपको यह नियंत्रण या जानकारी दिए बिना कि स्कैन कब होगा, और न ही कच्चा स्कैन डेटा प्रदान करता है। Prober आपके बुनियादी ढांचे के बारे में आपकी धारणाओं को सत्यापित करता है, इसे आपके शेड्यूल पर करता है, और निरीक्षण के लिए पूर्ण कच्चा स्कैन डेटा प्रदान करता है।

यह Natlas से कैसे अलग है?

Natlas Shodan के करीब प्रतीत होता है (उजागर होस्ट खोजने के लिए क्रॉलिंग, प्रश्नों के जवाब में परिणाम दिखाना), लेकिन स्व-होस्टिंग की क्षमता के साथ (और इस प्रकार Natlas Agent को आपके बुनियादी ढांचे के अंदर और बाहर विभिन्न स्थानों में चलाना, Prober नोड्स की तरह)। Prober आपके बुनियादी ढांचे के नियमित स्कैन चलाता है ताकि आपके बारे में आपकी अपनी धारणाओं को सत्यापित किया जा सके, जैसा कि कॉन्फ़िग में व्यक्त किया गया है।

बड़े प्रश्न

• अधिक शक्तिशाली परीक्षण प्रणाली पर स्विच करें?
  • BATS में कष्टप्रद सीमाएँ हैं, उदाहरण के लिए: सशर्त परीक्षण करने का कोई तरीका नहीं है ("यदि टेस्ट A विफल हो तो टेस्ट B छोड़ें", आदि)
  • परीक्षण प्रणाली को पूरी तरह से छोड़ दें?
    • https://docs.ansible.com/ansible/latest/reference_appendices/test_strategies.html
    • https://github.com/benwebber/ansible-tap
• IPv6 पूर्ण-ब्लॉक स्कैन एक सहस्राब्दी के भीतर पूरा करना असंभव है
  • IP स्कैन करने के लिए चयन की ह्यूरिस्टिक (यादृच्छिक, नीचे से शुरू करके एक कॉन्फ़िगर किए गए "step" के साथ, आदि) को कॉन्फ़िगर करने का एक तरीका प्रदान करें?

आभार

लोगो Magnifying Glass by verry obito, ID; CC-By और Network by Creative Stall, PK; CC-By, द नाउन प्रोजेक्ट के माध्यम से पर आधारित है।