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

Question

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

टीसीपी कनेक्शन का सामान्य तरीका नेटस्टैट / एलएसओएफ का उपयोग करना और प्रक्रिया को पीआईडी ​​से संबद्ध करना है।

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

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

नेटस्टैट / lsof को ठीक उसी समय कॉल करें जब 3/4 udp पैकेट भेजा जाता है, जो कि IMPOSSIBLE है।

मैं कुख्यात प्रक्रिया की पहचान कैसे कर सकता हूं? मैंने पहले ही पैकेट की सामग्री से भेजे गए PID की पहचान करने के लिए ट्रैफ़िक का निरीक्षण कर लिया है, लेकिन ट्रैफ़िक के दृष्टिकोण से इसकी पहचान करना संभव नहीं है।

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

मैं इस मशीन पर रूट कर रहा हूँ FEDORA 12 लिनक्स नॉइज.कॉम। इसके साथ ही 2.6.32.16-141.fc12.x86_64 # 1 एसएमपी बुध जुलाई 7 04:49:59 UTC 2010 x86_64 x86_64 x86_64 x64- लिनक्स

Answer 1

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

सबसे पहले, 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_INET2 है और SOCK_DGRAM2. टीसीपी कनेक्शन का उपयोग 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(मूल प्रक्रिया ID) भी इस मामले में सूचीबद्ध किया गया है यह एक स्क्रिप्ट है कि spawns समस्या बच्चा एक बहुत।

अब, यदि आपके पास बहुत अधिक UDP ट्रैफ़िक है, तो यह बहुत अच्छा नहीं है और आपको OProfile या SystemTap का सहारा लेना होगा , जो दोनों वर्तमान में मेरी विशेषज्ञता से परे हैं।

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

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

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

Comments

मैं यह कोशिश करूँगा, लेकिन मुझे लगता है कि सही जवाब है।

— boos

यह कम से कम मेरे लिए iptables द्वारा गिराए जा रहे ट्रैफ़िक को नहीं उठा रहा है।

— 2rs2ts

सिस्टमटैप विधि की तुलना में सादगी के लिए +1 (जो अधिक विश्लेषणात्मक है, लेकिन कर्नेल

— डेवेल

Answer 2

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

यहाँ मैं अपने स्थानीय होस्ट पर एक ncat शुरू कर रहा हूँ, यूडीपी ट्रैफ़िक को 10.11.12.13 को एक (गैर-मौजूद) मशीन पर 2345 पोर्ट पर भेज रहा हूँ:

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

यहाँ कुछ tcpdump आउटपुट साबित कर रहा है कि यातायात चल रहा है:

[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

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

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

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

उम्मीद है कि इसका कुछ फायदा हो।

Comments

वास्तव में अच्छा किया! : thumbup:

— ThorstenS

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

— zerolagtime

मैं आपकी दोनों आपत्तियों से सहमत हूँ, zerolagtime (लेकिन वैसे भी अपनी तरह के शब्दों के लिए धन्यवाद, Thorstenag!)।

— MadHatter

Answer 3

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

मेरे पास मेरे कुछ सर्वरों से ट्रैफ़िक था जो Google DNS पते 8.8.8.8और , की ओर जा रहा था 8.8.4.4। अब, मेरे नेटवर्क व्यवस्थापक के पास हल्के OCD हैं और वह हमारे अनावश्यक 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उन PID को बदलने के बाद परिवर्तन नहीं उठा।

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

Answer 4

यहाँ एक सिस्टमटैप विकल्प दिया गया है, जो स्टैप्ट वर्सन 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

Answer 5

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

Comments

ट्रैफिक में कोई जानकारी मुझे पहले से ही नहीं सूँघनी पड़ी।

— bo '

कोई सूचना नहीं? खाली पैकेट? मेरा क्या मतलब था, अगर कुछ अपडेट को हल करने का प्रयास कर रहा है। java.sun.com या rss.cnn.com। आप उपयोगी रूप से इससे कुछ अनुमान लगा सकते हैं।

— RedGrittyBrick

आंतरिक प्रॉक्सी की खोज के लिए dns क्वेरी। अभी मैंने पाया विच प्रक्रिया है, लेकिन एक सामान्य समस्या को सुलझाने के लिए जिंदा सवाल है टेकनीक

— boos

lsof- आई | awk '/ UDP /'

— c4f4t0r

Answer 6

ज्ञात हो कि ऑटिटैक्टल का उपयोग करते समय, उदाहरण के लिए 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

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