सवाल मैं कैसे पहचान सकता हूं कि कौन सी प्रक्रिया लिनक्स पर यूडीपी यातायात बना रही है?


मेरी मशीन लगातार udp डीएनएस यातायात अनुरोध कर रही है। मुझे यह जानने की ज़रूरत है कि इस ट्रैफिक को उत्पन्न करने वाली प्रक्रिया का पीआईडी ​​क्या है।

टीसीपी कनेक्शन में सामान्य तरीका netstat / lsof का उपयोग करना है और पिड से जुड़ी प्रक्रिया प्राप्त करना है।

क्या यूडीपी कनेक्शन stateles है, इसलिए, जब मैं netastat / lsof कॉल करता हूं तो मैं इसे केवल तभी देख सकता हूं जब यूडीपी सॉकेट खोला जाता है और यह यातायात भेज रहा है।

मैंने lsof -i UDP और nestat -anpue के साथ प्रयास किया है, लेकिन मैं यह नहीं कर पा रहा हूं कि कौन सी प्रक्रिया उस अनुरोध को कर रही है क्योंकि मुझे lsof / netstat को ठीक से कॉल करने की आवश्यकता है जब udp यातायात भेजा जाता है, अगर मैं lsof / netstat को पहले / udp डेटाग्राम भेज दिया गया है खोला यूडीपी सॉकेट देखने के लिए असंभव है।

नेटस्टैट / lsof को कॉल करें जब 3/4 udp पैकेट भेजा जाता है असंभव है।

मैं कुख्यात प्रक्रिया की पहचान कैसे कर सकता हूं? मैंने पहले से ही पैकेट की सामग्री से प्रेषित पीआईडी ​​की पहचान करने के लिए यातायात का निरीक्षण किया है, लेकिन ट्रैफिक के संदर्भ से इसकी पहचान करना संभव नहीं है।

कोई मुझे मदद कर सकता है ?

मैं इस मशीन पर रूट हूं FEDORA 12 Linux noise.company.lan 2.6.32.16-141.fc12.x86_64 # 1 एसएमपी बुध 7 जुलाई 04:49:59 यूटीसी 2010 x86_64 x86_64 x86_64 जीएनयू / लिनक्स


40
2017-10-20 10:41


मूल




जवाब:


लिनक्स ऑडिटिंग मदद कर सकता है। यह कम से कम उपयोगकर्ताओं और डेटाग्राम नेटवर्क कनेक्शन बनाने की प्रक्रियाओं का पता लगाएगा। यूडीपी पैकेट डेटाग्राम हैं।

सबसे पहले, स्थापित करें auditd अपने मंच पर ढांचे और सुनिश्चित करें कि auditctl -l कुछ देता है, भले ही यह कहता है कि कोई नियम परिभाषित नहीं किया गया है।

फिर, सिस्टम कॉल देखने के लिए एक नियम जोड़ें socket() और बाद में आसान खोज के लिए इसे टैग करें (-k)। मुझे यह मानने की ज़रूरत है कि आप 64-बिट आर्किटेक्चर पर हैं, लेकिन आप प्रतिस्थापित कर सकते हैं b32 के स्थान पर b64 यदि आप नहीं हैं।

auditctl -a exit,always -F arch=b64 -F a0=2 -F a1\&=2 -S socket -k SOCKET

इसे बनाने के लिए आपको मैन पेज और हेडर फाइलों को चुनना होगा, लेकिन यह कैप्चर करना अनिवार्य रूप से इस सिस्टम कॉल है: socket(PF_INET, SOCK_DGRAM|X, Y), जहां तीसरा पैरामीटर निर्दिष्ट नहीं है लेकिन अक्सर शून्य है। PF_INET 2 और है SOCK_DGRAM 2. टीसीपी कनेक्शन का उपयोग होगा SOCK_STREAM जो सेट करेगा a1=1। (SOCK_DGRAM दूसरे पैरामीटर में ऑर्ड किया जा सकता है SOCK_NONBLOCK या SOCK_CLOEXEC, इसलिए &= तुलना।) -k SOCKET हमारा कीवर्ड है जिसे हम बाद में ऑडिट ट्रेल्स खोजते समय उपयोग करना चाहते हैं। यह कुछ भी हो सकता है, लेकिन मुझे इसे सरल रखना पसंद है।

कुछ क्षणों को जाने और लेखा परीक्षा के निशान की समीक्षा करने दें। वैकल्पिक रूप से, आप नेट पर होस्ट को पिंग करके दो पैकेट को मजबूर कर सकते हैं, जो एक DNS लुकअप होने का कारण बनता है, जो यूडीपी का उपयोग करता है, जिसे हमारी ऑडिट अलर्ट यात्रा करनी चाहिए।

ausearch -i -ts today -k SOCKET

और नीचे दिए गए अनुभाग के समान आउटपुट दिखाई देगा। मैं महत्वपूर्ण भागों को हाइलाइट करने के लिए इसका संक्षेप में हूं

type=SYSCALL ... arch=x86_64 syscall=socket success=yes exit=1 a0=2 a1=2 ... pid=14510 ... auid=zlagtime uid=zlagtime ... euid=zlagtime ... comm=ping exe=/usr/bin/ping key=SOCKET

उपरोक्त आउटपुट में, हम इसे देख सकते हैं ping कमांड ने सॉकेट खोलने का कारण बना दिया। मैं फिर चला सकता था strace -p 14510 प्रक्रिया पर, अगर यह अभी भी चल रहा था। ppid (पैरेंट प्रोसेस आईडी) भी सूचीबद्ध है यदि यह एक ऐसी स्क्रिप्ट है जो समस्या को बच्चे को बहुत परेशान करती है।

अब, यदि आपके पास बहुत सारे यूडीपी यातायात हैं, तो यह पर्याप्त नहीं होगा और आपको इसका सहारा लेना होगा OProfile या SystemTap, जो दोनों वर्तमान में मेरी विशेषज्ञता से परे हैं।

इससे सामान्य मामले में संकीर्ण चीजों को कम करने में मदद मिलनी चाहिए।

जब आप पूरा कर लेंगे, उसी लाइन का उपयोग करके ऑडिट नियम को हटा दें जिसका उपयोग आप इसे बनाने के लिए करते थे, केवल विकल्प -a साथ में -d

auditctl -d exit,always -F arch=b64 -F a0=2 -F a1\&=2 -S socket -k SOCKET

44
2017-10-20 18:41



मैं कोशिश करूँगा, लेकिन मुझे लगता है कि सही जवाब है। - boos
यह कम से कम मेरे लिए iptables द्वारा यातायात को गिराया नहीं जा रहा है। - 2rs2ts
Systemtap विधि की तुलना में सादगी के लिए +1 (जो अधिक विश्लेषणात्मक है, लेकिन कर्नेल डेवेल पैकेज की आवश्यकता है) - basos


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

यहां मैं अपने स्थानीय होस्ट पर एक एनटीसी शुरू कर रहा हूं, एक (अस्तित्वहीन) मशीन पर पोर्ट 2345 पर यूडीपी यातायात भेज रहा हूं 10.11.12.13:

[madhatta@risby]$ ncat -u 10.11.12.13 2345 < /dev/urandom

यहां कुछ टीसीपीडम्प आउटपुट साबित कर रहे हैं कि यातायात जा रहा है:

[root@risby ~]# tcpdump -n -n port 2345
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:41:32.391750 IP 192.168.3.11.57550 > 10.11.12.13.2345: UDP, length 8192
12:41:32.399723 IP 192.168.3.11.57550 > 10.11.12.13.2345: UDP, length 8192
12:41:32.401817 IP 192.168.3.11.57550 > 10.11.12.13.2345: UDP, length 8192
12:41:32.407051 IP 192.168.3.11.57550 > 10.11.12.13.2345: UDP, length 8192
12:41:32.413492 IP 192.168.3.11.57550 > 10.11.12.13.2345: UDP, length 8192
12:41:32.417417 IP 192.168.3.11.57550 > 10.11.12.13.2345: UDP, length 8192

यहां उपयोगी बिट है, प्रक्रिया आईडी विवरण देखने के लिए -ए फ्लैग (पोर्ट विवरण देखने के लिए) और -पी ध्वज के साथ नेटस्टैट का उपयोग करना। यह -पी ध्वज है जिसके लिए रूट विशेषाधिकारों की आवश्यकता है:

[root@risby ~]# netstat -apn|grep -w 2345
udp        0      0 192.168.3.11:57550          10.11.12.13:2345            ESTABLISHED 9152/ncat     

जैसा कि आप देख सकते हैं, 9152 को निर्दिष्ट रिमोट होस्ट पर पोर्ट 2345 के लिए कनेक्शन खोलने के रूप में उंगली मिली है। नेटस्टैट मददगार रूप से पीएस के माध्यम से भी चलता है और मुझे बताता है कि प्रक्रिया का नाम है ncat

उम्मीद है कि कुछ उपयोग है।


22
2017-10-20 11:49



वास्तव में अच्छा किया! :अंगूठा ऊपर: - ThorstenS
यद्यपि एक पकड़ है। यदि समस्या एक शेल स्क्रिप्ट के कारण होती है जो एक उपप्रोसेस उत्पन्न करती है जो DNS लुकअप करता है और वह प्रक्रिया जल्दी से बाहर निकलती है, तो स्रोत पोर्ट (57550 ऊपर) हर समय बदल जाएगा। इस मामले में, तकनीक काम नहीं करेगी और आपको अधिक कठोर उपाय करना होगा। इसके अतिरिक्त, आपके नेटस्टैट को एक होना चाहिए था grep -w 57550 क्योंकि एकाधिक प्रक्रियाएं उसी सर्वर पर DNS लुकअप कर रही हैं। आपकी विधि उन्हें अलग नहीं करेगा। - zerolagtime
मैं आपके दोनों आपत्तियों से सहमत हूं, ज़ीरोलागटाइम (लेकिन आपके तरह के शब्दों के लिए धन्यवाद, थॉर्स्टन!)। - MadHatter


मुझे बिल्कुल वही समस्या थी और दुर्भाग्य से auditd मेरे लिए बहुत कुछ नहीं किया।

मेरे कुछ सर्वरों से ट्रैफिक था जो Google DNS पते की तरफ जा रहा था, 8.8.8.8 तथा 8.8.4.4। अब, मेरे नेटवर्क व्यवस्थापक में हल्का ओसीडी है और वह हमारे अनावश्यक यातायात को साफ करना चाहता था क्योंकि हमारे पास हमारे इंटर्न DNS कैश हैं। वह उन कैश सर्वर को छोड़कर सभी के लिए आउटगोइंग पोर्ट 53 अक्षम करना चाहता था।

तो, विफल होने के बाद auditctl, मैं खोदना systemtap। मैं निम्नलिखित लिपि के साथ आया हूं:

# cat >> udp_detect_domain.stp <<EOF
probe udp.sendmsg {
  if ( dport == 53 && daddr == "8.8.8.8" ) {
    printf ("PID %5d (%s) sent UDP to %15s 53\n", pid(), execname(), daddr)
  }
}
EOF

फिर बस चलाएं:

stap -v udp_detect_domain.stp

यह वह आउटपुट है जो मुझे मिला:

PID  3501 (python) sent UDP to  8.8.8.8 53
PID  3501 (python) sent UDP to  8.8.8.8 53
PID  3506 (python) sent UDP to  8.8.8.8 53

बस! बदलने के बाद resolv.conf उन पीआईडी ​​ने बदलाव नहीं उठाए।


उम्मीद है की यह मदद करेगा :)


13
2018-04-16 20:39





मैं DNS अनुरोधों को देखने के लिए tcpdump या wireshark जैसे नेट-स्निफर का उपयोग करूंगा। क्वेरी की सामग्री यह बता सकती है कि कौन सा प्रोग्राम उन्हें जारी कर रहा है।


4
2017-10-20 10:46



यातायात में कोई जानकारी नहीं मिली मैं बस पहले ही देखता हूं। - boos
कोई सूचना नहीं? खाली पैकेट? मेरा मतलब था, अगर कुछ update.java.sun.com या rss.cnn.com को हल करने का प्रयास कर रहा है, तो आप उपयोगी रूप से इससे कुछ अनुमान लगा सकते हैं। - RedGrittyBrick
आंतरिक प्रॉक्सी के लिए खोज क्वेरी डीएनएस। अभी मुझे पता चला कि प्रक्रिया क्या है, लेकिन सवाल तकनीकी समस्याओं को हल करने के लिए एक सामान्य समस्या के लिए जिंदा है - boos
lsof -i | अजीब '/ यूडीपी /' - c4f4t0r


1.8 और बाद में स्टैप में उपलब्ध नेटफिल्टर जांच का उपयोग करके, एक सिस्टमटैप विकल्प यहां दिया गया है। यह भी देखें man probe::netfilter.ip.local_out

# stap -e 'probe netfilter.ip.local_out {
  if (dport == 53) # or parametrize
      printf("%s[%d] %s:%d\n", execname(), pid(), daddr, dport)
}'
ping[24738] 192.168.1.10:53
ping[24738] 192.168.1.10:53
^C

3
2018-04-24 20:03





ध्यान रखें कि autitctl का उपयोग करते समय, उदाहरण के लिए nscd सॉकेट सिस्टम कॉल में थोड़ा अलग पैरामीटर का उपयोग करता है, DNS क्वेरी करते समय:

socket(AF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP)

इसलिए यह सुनिश्चित करने के लिए कि आप ऊपर वर्णित किए गए लोगों के अतिरिक्त उन प्रश्नों को पकड़ लें, यदि आप चाहें तो उसी नाम के साथ आप एक अतिरिक्त फ़िल्टर जोड़ सकते हैं:

auditctl -a exit,always -F arch=b64 -F a0=2  -F a1=2050 -S socket -k SOCKET

यहां 2050 थोड़ा सा या है SOCK_DGRAM (2) और SOCK_NONBLOCK (2048)।

फिर खोज उन दोनों फ़िल्टरों को एक ही कुंजी के साथ मिल जाएगी, SOCKET:

ausearch -i -ts today -k SOCKET

सॉकेट स्थिरांक के लिए हेक्स मान मैंने यहां पाया: https://golang.org/pkg/syscall/#pkg-constants

जैसा कि मेरे पास टिप्पणी करने के लिए कोई प्रतिष्ठा नहीं है, मैंने इसे जोड़ा।


3
2017-10-17 12:53