NetBIOS पैकेट प्रोबिंग (पोर्ट 137)। क्या यह राउटर से आता है?


0

काफी समय से मेरी मशीन के फ़ायरवॉल को अजीब तरह के पैकेटों का पता चल रहा है, जो मेरे राउटर से प्रतीत हो रहे हैं। मैं इस व्यवहार की व्याख्या नहीं कर सकता। मुझे संदेह है कि किसी तरह बाहर से हमलावर उन पैकेटों की तस्करी कर रहा है जो या तो स्रोत आईपी पते को खराब कर रहे हैं या मेरे राउटर को हैक कर रहे हैं, लेकिन मुझे इसकी पुष्टि करने की आवश्यकता है। या हो सकता है कि राउटर निर्माता द्वारा ऐसा करने के लिए पूर्वनिर्मित हो?

अगर किसी को इस बात का अंदाजा है कि इसका कारण क्या हो सकता है, तो मैं बहुत आभारी रहूंगा।

विन्यास: राउटर / RR.RRRRR - ऐरिस WTM652B (मुझे लगता है कि यह हुड के नीचे टचस्टोन है), फ़ायरवॉल सक्षम है।

मेरे मेजबान / MM.MM.MM.MM iptables के साथ

मुझे दो प्रकार के अप्रत्याशित पैकेट मिलते हैं:

  • रूटर के आईपी से आने वाले DST पोर्ट 137 (NetBIOS) पैकेट। क्या NetBIOS के साथ राउटर में कुछ अजीब "एक्स्ट्रा" है, या यह एक बाहरी व्यक्ति है?
  • अमान्य अनचाहे पैकेट के साथ !! ?? !! SRC पोर्ट = 443 , जो Google इंक को आवंटित विभिन्न आईपी पते से आता है, क्या यह हैकिंग का प्रयास हो सकता है? कोई (संभवतः Google?) अपने फ़ायरवॉल पर गतिशील नियमों के माध्यम से मेरे फ़ायरवॉल के माध्यम से प्राप्त करने की कोशिश कर रहा है (जब मैं Google को खोजता हूं तो वे नियम एक छेद को छेदते हैं और कोई इस छेद से घुसने की कोशिश करता है)?

यहाँ एक नमूना है:

Apr 27 10:55:38 notebook kernel: iptables REJECT input: IN=enp0s25 OUT= MAC=(my LAN MAC addr) SRC=RR.RR.RR.RR DST=MM.MM.MM.MM LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=4108 PROTO=UDP SPT=2092 DPT=137 LEN=58 
Apr 27 10:55:42 notebook kernel: iptables REJECT input: IN=enp0s25 OUT= MAC=(my LAN MAC addr) SRC=RR.RR.RR.RR DST=MM.MM.MM.MM LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=4109 PROTO=UDP SPT=2092 DPT=137 LEN=58 
Apr 27 10:55:49 notebook kernel: iptables DROP input/invalid: IN=enp0s25 OUT= MAC=(my LAN MAC addr) SRC=216.58.212.4 DST=MM.MM.MM.MM LEN=40 TOS=0x00 PREC=0x00 TTL=56 ID=58408 PROTO=TCP SPT=443 DPT=53474 WINDOW=0 RES=0x00 RST URGP=0 
Apr 27 10:55:50 notebook kernel: iptables DROP input/invalid: IN=enp0s25 OUT= MAC=(my LAN MAC addr) SRC=216.58.201.195 DST=MM.MM.MM.MM LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=32104 PROTO=TCP SPT=443 DPT=34440 WINDOW=0 RES=0x00 RST URGP=0 
Apr 27 10:58:27 notebook kernel: iptables DROP input/invalid: IN=enp0s25 OUT= MAC=(my LAN MAC addr) SRC=172.217.20.142 DST=MM.MM.MM.MM LEN=40 TOS=0x00 PREC=0x00 TTL=59 ID=16097 PROTO=TCP SPT=443 DPT=38786 WINDOW=0 RES=0x00 RST URGP=0 

किसी भी विचार यहाँ क्या हो रहा है?

बहुत अच्छा धन्यवाद, mbax


मुझे लगता है कि अगर आपने हमें अपने राउटर के कॉन्फिग्रेशन के बारे में अधिक बताया तो इससे मदद मिलेगी, क्योंकि WAN से NetBIOS की फॉरवर्डिंग आमतौर पर वहां नहीं होगी। के रूप में https, एक राउटर आमतौर पर एक निश्चित दूरस्थ स्रोत पोर्ट से शुरू किए गए ट्रैफ़िक के लिए अपने फ़ायरवॉल को नहीं खोलेगा , और ऐसा बहुत कुछ नहीं है जो कोई भी उसके खिलाफ कर सकता है। एक सवाल यह है कि क्या अन्य लैन क्लाइंट हैं, और दूसरा है, क्या आप एक उपकरण का उपयोग कर सकते हैं जैसे कि बेहतर आंकड़ा क्या हो रहा है। wireshark
CMD

क्लास स्टेकर को जवाब देने के लिए धन्यवाद। दुर्भाग्यवश, UI में राउटर कॉन्फ़िगरेशन सरल है। इसमें एक सरल रेडियो बटन है, "फ़ायरवॉल ऑन" और "फ़ायरवॉल ऑफ"। मेरा "पर" है। मेरे पास कोई खुली सेवा या बंदरगाह अग्रेषण नहीं है। मैंने बाहरी रूप से भी जाँच की और कोई भी टीसीपी पोर्ट नहीं खुला। दूसरे मुद्दे के बारे में: नहीं, मेरी मशीन LAN में अकेली है। मैंने tcpdump का उपयोग करने की कोशिश की, लेकिन इसने मुझे फ़ायरवॉल लॉग से अधिक नहीं बताया। मैं वायरशर्क के साथ कोशिश करूंगा।
mbax

पहला पैकेट प्रकार ( pastebin.com/UeH12zMq ) - यह एक NetBIOS नाम क्वेरी है। "राउटर" (या कोई और) यह देखने के लिए सूँघ रहा है कि नेटवर्क पर कौन है। क्या यह सामान्य है? ऐसा लगता है कि Google ( pastebin.com/GQW9YeiX ) द्वारा दूसरे प्रकार का एक टीसीपी कनेक्शन रीसेट भेजा गया है । क्या ऐसा हो सकता है कि यह ब्राउज़र में मेरे HTTPS सत्र के कारण हो? आरएसटी क्यों, उन कनेक्शनों को एक सामान्य फिन, ईमो के साथ समाप्त होना चाहिए।
mbax

: मैं वेबसाइट (उनके मामले में फेसबुक) द्वारा AJAX responces के लिए इस तरह के पैकेट संबंधित एक समान धागा पाया security.stackexchange.com/questions/73344/... वे हालांकि बहुत यकीन है कि नहीं है।
mbax

जवाबों:


0

मुझे अपने राउटर से आने वाले NetBIOS नाम क्वेरी के बारे में चिंता नहीं होगी।

मैंने कई राउटर देखे हैं कि जब आप उनके मैक फ़िल्टरिंग विकल्प (या मैक पते का उपयोग करने वाले किसी भी विकल्प) में जाते हैं, तो उस पीसी पर सेट किए गए नेटबीआईओएस नाम को भी दिखाएगा। इससे यह पता लगाना आसान हो जाता है कि नेटवर्क पर कौन सी मशीनें आपकी हैं और उन्हें आवश्यक रूप से प्रतिबंधित करें।

यदि आप अभी भी अनिश्चित हैं तो मैं क्या करूँगा grc.com पर जा रहा हूँ और उनके शील्ड्स का उपयोग करूँगा ! उपकरण आपके पोर्ट को स्कैन करने और यह सुनिश्चित करने के लिए कि पोर्ट 137 आपके राउटर के इंटरनेट साइड में बंद है। इस तरह से आप यह सुनिश्चित कर सकते हैं कि नाम जांच पैकेट आपके राउटर से ही आ रहे हैं न कि इंटरनेट पर।


हाँ, मैंने ऐसा नहीं सोचा है। वास्तव में राउटर प्रतीकात्मक नाम लेने में सक्षम है (कम से कम जब फ़ायरवॉल सामान को रोक नहीं रहा है - जैसे कि पैड, फोन या विंडोज उपकरणों के लिए।) इससे समझ में आता है।
mbax

0

मुझे एक बहुत ही समझदार उत्तर के साथ एक समान धागा मिला :

एक साइड नोट के रूप में, मैं अपने कुछ सर्वरों पर कुछ आईपी रेंज के साथ भी ऐसा व्यवहार देख रहा हूं। वे सभी आरएसटी पैकेट हैं जो भेजे जाते हैं क्योंकि कुछ सामान्य रूप से उपयोग किए जाने वाले वेबसेवाओं के डीएनएस रोटेशन में आईपी पते होते हैं जो वास्तव में सेवा नहीं चलाते हैं।

Google के समूहों और बदलते IP पतों के कारण, AJAX के माध्यम से कई जावास्क्रिप्ट अनुरोधों के कारण, पुनरावृत्ति करने के लिए, संभवतः क्या होता है। उन Google सर्वरों में से कुछ शायद नीचे हैं और एक आरएसटी (आईपी स्विच करने के बाद) भेजते हैं?

अन्य संभावना फ़ायरवॉल नियमों या फ़ायरवॉल बग में एक गलत धारणा है। मैंने आधिकारिक iptables कॉन्फ़िगरेशन गाइड का उपयोग किया और नियमों का उपयोग लगभग 1: 1 किया, इसलिए यह मामला नहीं होना चाहिए, लेकिन कौन जानता है?

और तीसरा - यह एक अनचाहा पैकेट हो सकता है, जो सीधे एसआरसी आईपी = राउटर आईपी और डीएसटी आईपी = माय आईपी के साथ मेरे राउटर को भेजा जाता है। राउटर उन अवैध पैकेटों को न गिराने के लिए इतना गूंगा हो सकता है। अगर ऐसा होता, तो मुझे आश्चर्य होता।

यदि किसी के पास बेहतर स्पष्टीकरण है, तो कृपया मदद करें।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.