Vraag hoe kan ik identificeren welk proces het maken van UDP-verkeer op Linux is?


mijn machine maakt onophoudelijk udp dns verkeersverzoek. wat ik moet weten is de PID van het proces dat dit verkeer genereert.

De normale manier in de TCP-verbinding is om netstat / lsof te gebruiken en het proces aan de pid te koppelen.

Is UDP de verbinding statels, dus als ik netastat / lsof bel, kan ik dit alleen zien als de UDP-socket wordt geopend en er verkeer wordt verzonden.

Ik heb met lsof -i UDP en met nestat -anpue geprobeerd maar ik kan niet kunnen vinden welk proces dat verzoek doet omdat ik lsof / netstat precies moet aanroepen wanneer het udp-verkeer wordt verzonden, als ik lsof / netstat vóór roep / nadat het udp-datagram is verzonden, is het onmogelijk om de geopende UDP-socket te bekijken.

aanroep netstat / lsof precies wanneer 3/4 udp-pakket wordt verzonden, is ONMOGELIJK.

hoe kan ik het beruchte proces identificeren? Ik heb het verkeer al geïnspecteerd om te proberen de verzonden PID te identificeren aan de hand van de inhoud van het pakket, maar het is niet mogelijk om het te identificeren aan de hand van het verkeer.

kan iemand me helpen?

Ik ben root op deze machine FEDORA 12 Linux noise.company.lan 2.6.32.16-141.fc12.x86_64 # 1 SMP Wed 7 juli 04:49:59 UTC 2010 x86_64 x86_64 x86_64 GNU / Linux


40
2017-10-20 10:41


oorsprong




antwoorden:


Linux-auditing kan helpen. Het zal op zijn minst gebruikers en processen lokaliseren die datagramnetwerkverbindingen maken. UDP-pakketten zijn datagrammen.

Installeer eerst de auditd kader op uw platform en zorg ervoor dat auditctl -l geeft iets terug, zelfs als er staat dat er geen regels zijn gedefinieerd.

Voeg vervolgens een regel toe om de systeemaanroep te bekijken socket() en label het om later gemakkelijk te vinden (-k). Ik moet ervan uitgaan dat je een 64-bits architectuur hebt, maar je kunt deze vervangen b32 in plaats van de b64 als je dat niet bent.

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

Je moet manpagina's en header-bestanden kiezen om dit te bouwen, maar wat het vastlegt is in wezen deze systeemaanroep: socket(PF_INET, SOCK_DGRAM|X, Y), waarbij de derde parameter niet gespecificeerd maar vaak nul is. PF_INET is 2 en SOCK_DGRAM is 2. TCP-verbindingen zouden gebruiken SOCK_STREAM welke zou instellen a1=1. (SOCK_DGRAM in de tweede parameter kan ORed met zijn SOCK_NONBLOCK of SOCK_CLOEXEC, vandaar de &= vergelijking.) De -k SOCKET is ons sleutelwoord dat we willen gebruiken bij het later doorzoeken van controletrajecten. Het kan van alles zijn, maar ik hou van het eenvoudig te houden.

Laat een paar momenten voorbijgaan en bekijk de audit trails. Optioneel zou je een paar pakketten kunnen forceren door een host op het internet te pingen, waardoor er een DNS-lookup optreedt, die gebruik maakt van UDP, wat onze audit alert zou moeten uitzetten.

ausearch -i -ts today -k SOCKET

En de uitvoer vergelijkbaar met de onderstaande sectie verschijnt. Ik kort het af om de belangrijke delen te benadrukken

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

In de bovenstaande uitvoer kunnen we zien dat de ping commando veroorzaakte dat de socket werd geopend. Ik zou dan kunnen rennen strace -p 14510 over het proces, als het nog liep. De ppid (parent process ID) wordt ook vermeld voor het geval het een script is dat het probleemkind veel spawnt.

Nu, als u veel UDP-verkeer heeft, zal dit niet goed genoeg zijn en u zult toevlucht moeten nemen tot oprofile of SystemTap, die beide momenteel mijn expertise te boven gaan.

Dit zou ertoe moeten bijdragen om de zaak in het algemeen te beperken.

Als u klaar bent, verwijdert u de auditregel door dezelfde regel te gebruiken die u hebt gebruikt om de auditregel te maken, alleen vervanging -a met -d.

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

44
2017-10-20 18:41



ik zal het proberen, maar ik denk dat het het juiste antwoord is. - boos
Dit is niet het oppikken van verkeer dat wordt afgebroken door iptables, althans voor mij. - 2rs2ts
+1 voor de eenvoud vergeleken met de systemtap-methode (die meer analytisch is, maar kernel devel-pakketten nodig heeft) - basos


U kunt netstat gebruiken, maar u hebt de juiste vlaggen nodig en het werkt alleen als het proces dat de gegevens verzendt nog steeds leeft. Het vindt geen sporen van iets dat kort tot leven is gekomen, stuurde UDP-verkeer en ging toen weg. Het vereist ook lokale rootprivileges. Dat gezegd hebbende:

Hier is het starten van een ncat op mijn lokale host, het verzenden van UDP-verkeer naar poort 2345 op een (niet-bestaande) machine 10.11.12.13:

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

Hier is wat tcpdump-uitvoer die bewijst dat het verkeer gaat:

[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

Dit is het handige stukje, gebruikmakend van netstat met de vlag -a (om details van de poort te zien) en de vlag -p om de details van het proces-ID te bekijken. Het is de vlag -p die rootprivileges vereist:

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

Zoals je kunt zien, is pid 9152 gevleugeld omdat deze een verbinding open heeft naar poort 2345 op de opgegeven externe host. Netstat helpt dat ook handig door ps en vertelt me ​​dat de procesnaam dat is ncat.

Hopelijk is dat nuttig.


22
2017-10-20 11:49



erg leuk gedaan! :duim omhoog: - ThorstenS
Er is echter een vangst. Als het probleem wordt veroorzaakt door een shell-script dat een subproces ontspant dat de DNS-lookup uitvoert en dat proces snel wordt afgesloten, zal de bronpoort (57550 hierboven) de hele tijd veranderen. In dit geval zal de techniek niet werken en zult u drastischer maatregelen moeten nemen. Bovendien zou uw netstat een a moeten hebben gedaan grep -w 57550 omdat meerdere processen DNS-lookups naar dezelfde server kunnen doen. Uw methode zou ze niet kunnen onderscheiden. - zerolagtime
Ik ben het eens met uw bezwaren, nerolagtime (maar bedankt voor uw vriendelijke woorden hoe dan ook, ThorstenS!). - MadHatter


Ik had precies hetzelfde probleem en helaas auditd heeft niet veel voor mij gedaan.

Ik had verkeer van een aantal van mijn servers naar google DNS-adressen, 8.8.8.8 en 8.8.4.4. Mijn netwerkbeheerder heeft nu milde OCD en hij wilde al het onnodige verkeer opschonen omdat we onze interne DNS-caches hebben. Hij wilde de uitgaande poort 53 uitschakelen voor iedereen behalve die cacheservers.

Dus na falen met auditctl, Graven ik in systemtap. Ik bedenk het volgende script:

# 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

Voer dan gewoon uit:

stap -v udp_detect_domain.stp

Dit is de uitvoer die ik heb gekregen:

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

Dat is het! Na het veranderen resolv.conf die PID's hebben de wijzigingen niet opgepikt.


Ik hoop dat dit helpt :)


13
2018-04-16 20:39





Ik zou een net-sniffer zoals tcpdump of wireshark gebruiken om de DNS-verzoeken te bekijken. De inhoud van de query kan een idee geven van het programma dat ze uitgeeft.


4
2017-10-20 10:46



geen informatie in het gesnapte verkeer die ik net al bekijk. - boos
Geen informatie? Lege pakketten? Wat ik bedoelde was, als iets probeert om updates.java.sun.com of rss.cnn.com op te lossen, kunt u hieruit waarschijnlijk iets afleiden. - RedGrittyBrick
dns query zoeken naar de interne proxy. op dit moment heb ik ontdekt welk proces dat is, maar de vraag blijft leven voor een algemene probleemoplossende techniek - boos
lsof -i | awk '/ UDP /' - c4f4t0r


Hier is een systemtap-optie, waarbij de netfilter-sondes worden gebruikt die beschikbaar zijn in stap verson 1.8 en hoger. Zie ook 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





Houd er rekening mee dat wanneer u autitctl gebruikt, nscd bijvoorbeeld een iets andere parameter gebruikt in de socketsysteemaanroep bij het uitvoeren van een DNS-query:

socket(AF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP)

Om er zeker van te zijn dat u deze vragen opvangt naast degene die hierboven zijn genoemd, kunt u een extra filter toevoegen met dezelfde naam als u wilt:

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

Hier is 2050 een bitsgewijze OR van SOCK_DGRAM (2) en SOCK_NONBLOCK (2048).

Dan zal de zoekopdracht beide filters met dezelfde sleutel vinden, SOCKET:

ausearch -i -ts today -k SOCKET

De hexadecimale waarden voor de socketconstanten die ik hier heb gevonden: https://golang.org/pkg/syscall/#pkg-constants

Omdat ik geen reputatie heb om opmerkingen te maken, heb ik dit toegevoegd.


3
2017-10-17 12:53