netmap.js

त्वरित ब्राउज़र-आधारित नेटवर्क खोज मॉड्यूल

यह परियोजना अब अनुरक्षित नहीं है।

विवरण

netmap.js ब्राउज़र-आधारित होस्ट खोज और पोर्ट स्कैनिंग क्षमताएँ प्रदान करता है ताकि आप वेबसाइट आगंतुकों के नेटवर्क का मानचित्रण कर सकें।

यह काफी तेज़ है, और es6-promise-pool का उपयोग करके ब्राउज़र द्वारा अनुमत अधिकतम समवर्ती कनेक्शनों को कुशलतापूर्वक चलाता है।

प्रेरणा

मुझे अपने एक विचार के लिए ब्राउज़र-आधारित पोर्ट स्कैनर की आवश्यकता थी। मैंने सोचा कि यह मौजूदा मॉड्यूल आयात करने या BeEF जैसी किसी अन्य परियोजना से कॉपी-पेस्ट करने का एक सरल मामला होगा।

पता चला कि कोई अच्छा तैयार-उपयोग npm मॉड्यूल नहीं था और BeEF में port_scanner मॉड्यूल (लेखन के समय) अशुद्ध, धीमा है और क्रोमियम पर काम नहीं करता है।

netmap.js इसलिए एक कुछ हद तक अनुकूलित "पिंग" स्वीपर और टीसीपी स्कैनर है जो सभी आधुनिक ब्राउज़रों पर काम करता है।

त्वरित आरंभ

स्थापित करें

npm install --save netmap.js

लाइव होस्ट खोजें

आइए एक घरेलू वातावरण में संभावित उम्मीदवारों की सूची से शुरू करते हुए वेबसाइट आगंतुक के गेटवे का IP पता पता करें:

import NetMap from 'netmap.js'

const netmap = new NetMap()
const hosts = ['192.168.0.1', '192.168.0.254', '192.168.1.1', '192.168.1.254']

netmap.pingSweep(hosts).then(results => {
  console.log(results)
})

{
  "hosts": [
    { "host": "192.168.0.1", "delta": 1003, "live": false },
    { "host": "192.168.0.254", "delta": 1001, "live": false },
    { "host": "192.168.1.1", "delta": 18, "live": true },
    { "host": "192.168.1.254", "delta": 1002, "live": false }
  ],
  "meta": {}
}

होस्ट 192.168.1.1 लाइव प्रतीत होता है।

टीसीपी पोर्ट स्कैन करें

आइए कुछ होस्ट पर कुछ खुले टीसीपी पोर्ट खोजने का प्रयास करें:

import NetMap from 'netmap.js'

const netmap = new NetMap()
const hosts = ['192.168.1.1', '192.168.99.100', 'google.co.uk']
const ports = [80, 443, 8000, 8080, 27017]

netmap.tcpScan(hosts, ports).then(results => {
  console.log(results)
})

{
  "hosts": [
    {
      "host": "192.168.1.1",
      "control": "22",
      "ports": [
        { "port": 443, "delta": 15, "open": false },
        { "port": 8000, "delta": 19, "open": false },
        { "port": 8080, "delta": 21, "open": false },
        { "port": 27017, "delta": 26, "open": false },
        { "port": 80, "delta": 95, "open": true }
      ]
    },
    {
      "host": "192.168.99.100",
      "control": "1001",
      "ports": [
        { "port": 8080, "delta": 40, "open": true },
        { "port": 80, "delta": 1001, "open": false },
        { "port": 443, "delta": 1000, "open": false },
        { "port": 8000, "delta": 1004, "open": false },
        { "port": 27017, "delta": 1000, "open": false }
      ]
    },
    {
      "host": "google.co.uk",
      "control": "1001",
      "ports": [
        { "port": 443, "delta": 67, "open": true },
        { "port": 80, "delta": 159, "open": true },
        { "port": 8000, "delta": 1001, "open": false },
        { "port": 8080, "delta": 1002, "open": false },
        { "port": 27017, "delta": 1000, "open": false }
      ]
    }
  ],
  "meta": {}
}

पहली नज़र में परिणाम विरोधाभासी लग सकते हैं।

192.168.1.1 स्थानीय नेटवर्क खंड पर एक एम्बेडेड लिनक्स मशीन (राउटर) है, और केवल पोर्ट 80 खुला है। हम देख सकते हैं कि ब्राउज़र को 80 पर त्रुटि आने में अन्य बंद पोर्टों की तुलना में लगभग 5 गुना अधिक समय लगा।

192.168.99.100 एक होस्ट-ओनली VM है जिसमें पोर्ट 8080 खुला है और google.co.uk एक बाहरी होस्ट है जिसमें 443 और 80 दोनों खुले हैं। इन मामलों में, ब्राउज़र ने खुले पोर्टों पर अपेक्षाकृत तेज़ी से त्रुटि दी जबकि बंद पोर्ट बस टाइमआउट हो गए। आगे सिद्धांत अनुभाग बताता है कि यह कब होता है।

यह निर्धारित करने के लिए कि पोर्टों को खुले या बंद के रूप में चिह्नित किया जाना चाहिए, netmap.js एक "नियंत्रण" पोर्ट (डिफ़ॉल्ट रूप से 45000) स्कैन करेगा जिसे बंद माना जाता है। फिर नियंत्रण समय का उपयोग अन्य पोर्टों की स्थिति निर्धारित करने के लिए किया जाता है। यदि अनुपात delta/control एक निर्धारित मान (डिफ़ॉल्ट 0.8) से अधिक है, तो पोर्ट को बंद माना जाता है (tl;dr: नियंत्रण समय से 20% से अधिक का अंतर पोर्ट के खुले होने का अर्थ है)।

सीमाएँ

पोर्ट ब्लैकलिस्ट

ब्राउज़र उन पोर्टों की एक ब्लैकलिस्ट बनाए रखते हैं जिनसे वे कनेक्ट करने से मना कर देंगे (जैसे FTP, SSH या SMTP)। यदि आप डिफ़ॉल्ट प्रोटोकॉल (http) का उपयोग करके netmap.js से उन पोर्टों को स्कैन करने का प्रयास करते हैं, तो आपको बहुत कम टाइमआउट मिलेगा। एक छोटा टाइमआउट आमतौर पर इस बात का संकेत है कि पोर्ट बंद है, लेकिन ब्लैकलिस्टेड पोर्ट के मामले में इसका कोई मतलब नहीं है।

आप इन स्रोतों से ब्लैकलिस्ट देख सकते हैं:

• क्रोमियम स्रोत
• मोज़िला दस्तावेज़
• Edge/IE (यदि आपको कोई स्रोत मिले तो मुझे एक लिंक भेजें)

Firefox 61 (और शायद अन्य ब्राउज़रों) से पहले, कनेक्शन स्थापित करने के लिए http के बजाय ftp प्रोटोकॉल का उपयोग करके इस सीमा को दरकिनार करना संभव था। आप NetMap को इंस्टैंशिएट करते समय विकल्पों में protocol निर्दिष्ट कर सकते हैं। ftp का उपयोग करते समय, आप उम्मीद कर सकते हैं कि खुले पोर्ट टाइमआउट होंगे और बंद पोर्ट अपेक्षाकृत तेज़ी से त्रुटि देंगे। ftp स्कैनिंग इस दस्तावेज़ में चर्चित TCP RST पैकेट के आसपास की सीमाओं के अधीन भी है।

ftp जैसे "लेगसी" प्रोटोकॉल से उप-संसाधन अनुरोध क्रोमियम में कुछ समय से अवरुद्ध हैं।

"पिंग" स्वीप

netmap.js द्वारा प्रदान की गई "पिंग" स्वीप कार्यक्षमता स्थानीय नेटवर्क खंड पर लाइव *निक्स-आधारित होस्ट (अन्य कंप्यूटर, फोन, राउटर, प्रिंटर आदि) को तेज़ी से खोजने में काफी अच्छा काम करती है।

हालाँकि, कार्यान्वयन के कारण यह तब काम नहीं करेगा जब TCP RST पैकेट वापस नहीं आते। आमतौर पर:

• विंडोज मशीनें
• कुछ बाहरी होस्ट
• ब्रिज्ड/होस्ट-ओनली VM जैसी कुछ नेटवर्क सेटअप

इसके पीछे का कारण नीचे सिद्धांत अनुभाग में समझाया गया है।

यह सीमा TCP स्कैनिंग क्षमताओं को प्रभावित नहीं करती है और उन पर एक खुला पोर्ट खोजने का प्रयास करके उपरोक्त होस्ट के लाइव होने का निर्धारण करना अभी भी संभव है।

सामान्य सटीकता का अभाव

कुल मिलाकर, मैंने इस मॉड्यूल को वेब पर बिखरे अन्य कोड टुकड़ों की तुलना में अधिक सटीक और तेज़ पाया है। ऐसा कहने के बाद, ब्राउज़र से नेटवर्क मैप करने का पूरा विचार स्वाभाविक रूप से चिड़चिड़ा होने वाला है। आपका अनुभव भिन्न हो सकता है।

उपयोग

NetMap कंस्ट्रक्टर

NetMap कंस्ट्रक्टर एक विकल्प ऑब्जेक्ट लेता है जो आपको निम्नलिखित कॉन्फ़िगर करने की अनुमति देता है:

• स्कैनिंग के लिए उपयोग किया जाने वाला protocol (डिफ़ॉल्ट http, इसे ftp पर सेट करने के कारण के लिए पोर्ट ब्लैकलिस्ट देखें)
• पोर्ट कनेक्शन timeout (डिफ़ॉल्ट 1000 मिलीसेकंड)

import NetMap from 'netmap.js'

const netmap = new NetMap({
  protocol: 'http',
  timeout: 3000
})

pingSweep()

pingSweep() विधि यह निर्धारित करती है कि होस्टों की दी गई सरणी लाइव है या नहीं। यह यह जाँच करके करता है कि क्या किसी पोर्ट से कनेक्शन टाइमआउट होता है, जिस स्थिति में होस्ट को ऑफ़लाइन माना जाता है (सीमाओं के लिए "पिंग" स्वीप और सिद्धांत के लिए मानक मामला देखें)।

विधि निम्नलिखित पैरामीटर लेती है:

• होस्ट्स की hosts सरणी (IP पते या होस्ट नाम)
• विकल्पों वाला options ऑब्जेक्ट:
  • maxConnections - अधिकतम समवर्ती कनेक्शनों की संख्या (डिफ़ॉल्ट रूप से क्रोम पर 10 और अन्य ब्राउज़रों पर 17 - ब्राउज़रों द्वारा समर्थित अधिकतम समवर्ती कनेक्शन)
  • स्कैन करने के लिए port (डिफ़ॉल्ट 45000)

यह एक प्रॉमिस लौटाता है।

netmap.pingSweep(['192.168.1.1'], {
  maxConnections: 5,
  port: 80
}).then(results => {
  console.log(results)
})

tcpScan()

tcpScan() विधि लक्ष्यों की एक श्रेणी के विरुद्ध पोर्ट स्कैन करेगी। यह कैसे करता है यह समझने के लिए मानक मामला पढ़ें।

विधि निम्नलिखित पैरामीटर लेती है:

• होस्ट्स की hosts सरणी (IP पते या होस्ट नाम)
• स्कैन करने के लिए ports की सूची (1-65535 के बीच पूर्णांक, ब्लैकलिस्ट में पोर्ट से बचें)
• विकल्पों वाला options ऑब्जेक्ट:
  • maxConnections - अधिकतम समवर्ती कनेक्शनों की संख्या (डिफ़ॉल्ट 6 - ब्राउज़र प्रति डोमेन अधिकतम कनेक्शन की अनुमति देते हैं)
  • portCallback - एक कॉलबैक जो व्यक्तिगत host:port संयोजन के स्कैनिंग समाप्त होने पर निष्पादित होता है
  • controlPort - आधार रेखा बंद-पोर्ट डेल्टा निर्धारित करने के लिए स्कैन करने हेतु पोर्ट (डिफ़ॉल्ट 45000)
  • controlRatio - नियंत्रण डेल्टा से प्रतिशत में समानता जिसके लिए एक पोर्ट को बंद माना जाता है (डिफ़ॉल्ट 0.8, उदाहरण देखें)

यह एक प्रॉमिस लौटाता है।

netmap.tcpScan(['192.168.1.1'], [80, 27017], {
  maxConnections: 5,
  portCallback: result => {
    console.log(result)
  },
  controlPort: 45000,
  controlRatio: 0.8
}).then(results => {
  console.log(results)
})

आउटपुट की व्याख्या करने के लिए उदाहरण देखें।

सिद्धांत

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

यह मॉड्यूल क्रॉस-ओरिजिन संसाधनों (परीक्षण के तहत http://{host}:{port} URL की श्रृंखला) का अनुरोध करने के लिए Image ऑब्जेक्ट का उपयोग करता है। ब्राउज़र को त्रुटि उत्पन्न करने में लगने वाला समय (delta), या एक निश्चित टाइमआउट मान के बाद त्रुटि का अभाव, समीक्षा के तहत होस्ट और पोर्ट की स्थिति में अंतर्दृष्टि प्रदान करता है।

मानक मामला

एक लाइव होस्ट आमतौर पर बंद पोर्ट से कनेक्ट करने का प्रयास करते समय TCP RST पैकेट के साथ अपेक्षाकृत तेज़ी से प्रतिक्रिया करेगा।

यदि पोर्ट खुला है, और भले ही वह HTTP सर्वर नहीं चला रहा हो, ब्राउज़र को पूर्ण TCP कनेक्शन स्थापित करने और फिर यह महसूस करने के ओवरहेड के कारण त्रुटि उत्पन्न करने में थोड़ा अधिक समय लगेगा कि वह प्रदान किए गए URL से एक छवि प्राप्त नहीं कर सकता।

एक ऑफ़लाइन होस्ट स्वाभाविक रूप से न तो RST के साथ प्रतिक्रिया करेगा और न ही पूर्ण TCP कनेक्शन स्थापित करने की अनुमति देगा। ब्राउज़र टाइमआउट (~90 सेकंड) से पहले थोड़ी देर तक कनेक्शन स्थापित करने का प्रयास करेंगे। netmap.js डिफ़ॉल्ट रूप से 1000 मिलीसेकंड प्रतीक्षा करने के बाद टाइमआउट हो जाएगा।

संक्षेप में:

• लाइव होस्ट पर बंद पोर्ट का delta बहुत छोटा होगा
• लाइव होस्ट पर खुले पोर्ट का delta थोड़ा लंबा होगा
• ऑफ़लाइन होस्ट या अप्रयुक्त IP पते टाइमआउट होंगे

मानक मामला TCP पोर्ट स्कैन उदाहरण में होस्ट 192.168.1.1 द्वारा दर्शाया गया है।

कोई TCP RST मामला नहीं

कुछ होस्ट (जैसे google.co.uk या विंडोज होस्ट) और कुछ नेटवर्क सेटअप (जैसे VirtualBox होस्ट-ओनली नेटवर्क) बंद पोर्ट से टकराने पर TCP RST पैकेट वापस नहीं करेंगे।

इन मामलों में, बंद पोर्ट आमतौर पर टाइमआउट होंगे जबकि खुले पोर्ट जल्दी से त्रुटि उत्पन्न करेंगे।

pingSweep() विधि का कार्यान्वयन इसलिए तब अविश्वसनीय है जब RST पैकेट वापस नहीं आते।

संक्षेप में, जब किसी भी कारण से TCP RST पैकेट वापस नहीं आते:

• लाइव होस्ट पर बंद पोर्ट टाइमआउट होंगे
• लाइव होस्ट पर खुले पोर्ट का delta छोटा होगा
• pingSweep() बंद पोर्ट टाइमआउट और "मृत" होस्ट टाइमआउट के बीच अंतर नहीं कर सकता

विशेष मामला TCP पोर्ट स्कैन उदाहरण में होस्ट 192.168.99.100 और google.co.uk द्वारा दर्शाया गया है।

वेबसॉकेट और AJAX की उपेक्षा

यह अच्छी तरह से प्रलेखित है कि आपको वेबसॉकेट और AJAX के साथ भी नेटवर्क मैप करने में सक्षम होना चाहिए।

मैंने इसे आज़माया (और BeEF को भी ट्वीक किया ताकि वह केवल वेबसॉकेट और AJAX के साथ अपने port_scanner मॉड्यूल का प्रयास करे); मैंने पाया कि दोनों विधियाँ पूरी तरह से अविश्वसनीय परिणाम उत्पन्न करती हैं।

कृपया मुझे बताएं कि क्या मैं इस संबंध में कुछ भूल रहा हूं।