Comment répertorier toutes les requêtes dans les sockets udp?

J'utilise quelques démons de servers qui utilisent udp pour communiquer avec un grand nombre de clients. Comment puis-je find et énumérer toutes les «connections» udp actives qui parlent aux servers afin d'estimer le nombre de clients actifs connectés aux démons du server? Je ne pouvais pas penser à un moyen simple de le faire en plus de renifler les packages avec tshark ou tcpdump et regarder l'ip source des packages udp allant aux démons du server et oui, je sais que UDP est un protocole sans connection et sans état.

5 Solutions collect form web for “Comment répertorier toutes les requêtes dans les sockets udp?”

UDP est un protocole apasortingde – donc, pas d'état.

Pour voir ce qui écoute UDP:

 netstat -lnpu 

Sur Linux, en supposant que l'iproute2 est installé, vous pouvez exécuter la command ss pour lancer les sockets udp de la manière suivante:

 ss -u 

Ou toutes les sockets udp, avec le process associé:

 [root@kerberos ks]# ss -u -pa State Recv-Q Send-Q Local Address:Port Peer Address:Port UNCONN 0 0 *:kerberos *:* users:(("krb5kdc",1935,7)) UNCONN 0 0 *:mdns *:* users:(("avahi-daemon",1613,13)) UNCONN 0 0 *:rquotad *:* users:(("rpc.rquotad",1872,3)) UNCONN 0 0 *:kerberos-iv *:* users:(("krb5kdc",1935,6)) UNCONN 0 0 *:sunrpc *:* users:(("rpcbind",1569,6)) UNCONN 0 0 *:ipp *:* users:(("cupsd",1687,9)) UNCONN 0 0 192.168.15.100:ntp *:* users:(("ntpd",1976,23)) UNCONN 0 0 172.16.15.1:ntp *:* users:(("ntpd",1976,22)) UNCONN 0 0 127.0.0.1:ntp *:* users:(("ntpd",1976,21)) UNCONN 0 0 *:ntp *:* users:(("ntpd",1976,16)) UNCONN 0 0 *:892 *:* users:(("rpc.mountd",1888,7)) UNCONN 0 0 *:896 *:* users:(("rpcbind",1569,7)) UNCONN 0 0 *:32769 *:* UNCONN 0 0 *:nfs *:* UNCONN 0 0 *:syslog *:* users:(("rsyslogd",1506,1)) UNCONN 0 0 *:42375 *:* users:(("avahi-daemon",1613,14)) UNCONN 0 0 *:pftp *:* users:(("rpc.statd",1643,8)) UNCONN 0 0 *:snmp *:* users:(("snmpd",1949,7)) UNCONN 0 0 *:37802 *:* users:(("squid",2124,9)) UNCONN 0 0 *:bootps *:* users:(("dhcpd",1987,7)) UNCONN 0 0 *:tftp *:* users:(("xinetd",1968,6)) UNCONN 0 0 *:971 *:* users:(("rpc.statd",1643,5)) UNCONN 0 0 *:kpasswd *:* users:(("kadmind",1926,6)) UNCONN 0 0 fe80::2e0:4cff:fe90:40eb:kerberos :::* users:(("krb5kdc",1935,11)) UNCONN 0 0 fe80::226:2dff:fe47:309f:kerberos :::* users:(("krb5kdc",1935,9)) UNCONN 0 0 fe80::2e0:4cff:fe90:40eb:kerberos-iv :::* users:(("krb5kdc",1935,10)) UNCONN 0 0 fe80::226:2dff:fe47:309f:kerberos-iv :::* users:(("krb5kdc",1935,8)) UNCONN 0 0 :::sunrpc :::* users:(("rpcbind",1569,9)) UNCONN 0 0 fe80::fc54:ff:feda:8094:ntp :::* users:(("ntpd",1976,26)) UNCONN 0 0 fe80::fc54:ff:fe52:8f66:ntp :::* users:(("ntpd",1976,30)) UNCONN 0 0 fe80::fc54:ff:feea:63a8:ntp :::* users:(("ntpd",1976,29)) UNCONN 0 0 fe80::fc54:ff:fe16:15c3:ntp :::* users:(("ntpd",1976,28)) UNCONN 0 0 fe80::fc54:ff:fe75:8012:ntp :::* users:(("ntpd",1976,27)) UNCONN 0 0 fe80::fc54:ff:feb3:4da8:ntp :::* users:(("ntpd",1976,25)) UNCONN 0 0 fe80::226:2dff:fe47:309f:ntp :::* users:(("ntpd",1976,20)) UNCONN 0 0 fe80::2e0:4cff:fe90:40eb:ntp :::* users:(("ntpd",1976,19)) UNCONN 0 0 ::1:ntp :::* users:(("ntpd",1976,18)) UNCONN 0 0 :::ntp :::* users:(("ntpd",1976,17)) UNCONN 0 0 :::892 :::* users:(("rpc.mountd",1888,9)) UNCONN 0 0 :::896 :::* users:(("rpcbind",1569,10)) UNCONN 0 0 :::32769 :::* UNCONN 0 0 :::nfs :::* UNCONN 0 0 :::syslog :::* users:(("rsyslogd",1506,2)) UNCONN 0 0 :::pftp :::* users:(("rpc.statd",1643,10)) UNCONN 0 0 fe80::2e0:4cff:fe90:40eb:kpasswd :::* users:(("kadmind",1926,8)) UNCONN 0 0 fe80::226:2dff:fe47:309f:kpasswd :::* users:(("kadmind",1926,7)) UNCONN 0 0 :::59603 :::* users:(("squid",2124,8)) [root@kerberos ks]# ss -upa State Recv-Q Send-Q Local Address:Port Peer Address:Port UNCONN 0 0 *:kerberos *:* users:(("krb5kdc",1935,7)) UNCONN 0 0 *:mdns *:* users:(("avahi-daemon",1613,13)) UNCONN 0 0 *:rquotad *:* users:(("rpc.rquotad",1872,3)) UNCONN 0 0 *:kerberos-iv *:* users:(("krb5kdc",1935,6)) UNCONN 0 0 *:sunrpc *:* users:(("rpcbind",1569,6)) UNCONN 0 0 *:ipp *:* users:(("cupsd",1687,9)) UNCONN 0 0 192.168.15.100:ntp *:* users:(("ntpd",1976,23)) UNCONN 0 0 172.16.15.1:ntp *:* users:(("ntpd",1976,22)) UNCONN 0 0 127.0.0.1:ntp *:* users:(("ntpd",1976,21)) UNCONN 0 0 *:ntp *:* users:(("ntpd",1976,16)) UNCONN 0 0 *:892 *:* users:(("rpc.mountd",1888,7)) UNCONN 0 0 *:896 *:* users:(("rpcbind",1569,7)) UNCONN 0 0 *:32769 *:* UNCONN 0 0 *:nfs *:* UNCONN 0 0 *:syslog *:* users:(("rsyslogd",1506,1)) UNCONN 0 0 *:42375 *:* users:(("avahi-daemon",1613,14)) UNCONN 0 0 *:pftp *:* users:(("rpc.statd",1643,8)) UNCONN 0 0 *:snmp *:* users:(("snmpd",1949,7)) UNCONN 0 0 *:37802 *:* users:(("squid",2124,9)) UNCONN 0 0 *:bootps *:* users:(("dhcpd",1987,7)) UNCONN 0 0 *:tftp *:* users:(("xinetd",1968,6)) UNCONN 0 0 *:971 *:* users:(("rpc.statd",1643,5)) UNCONN 0 0 *:kpasswd *:* users:(("kadmind",1926,6)) UNCONN 0 0 fe80::2e0:4cff:fe90:40eb:kerberos :::* users:(("krb5kdc",1935,11)) UNCONN 0 0 fe80::226:2dff:fe47:309f:kerberos :::* users:(("krb5kdc",1935,9)) UNCONN 0 0 fe80::2e0:4cff:fe90:40eb:kerberos-iv :::* users:(("krb5kdc",1935,10)) UNCONN 0 0 fe80::226:2dff:fe47:309f:kerberos-iv :::* users:(("krb5kdc",1935,8)) UNCONN 0 0 :::sunrpc :::* users:(("rpcbind",1569,9)) UNCONN 0 0 fe80::fc54:ff:feda:8094:ntp :::* users:(("ntpd",1976,26)) UNCONN 0 0 fe80::fc54:ff:fe52:8f66:ntp :::* users:(("ntpd",1976,30)) UNCONN 0 0 fe80::fc54:ff:feea:63a8:ntp :::* users:(("ntpd",1976,29)) UNCONN 0 0 fe80::fc54:ff:fe16:15c3:ntp :::* users:(("ntpd",1976,28)) UNCONN 0 0 fe80::fc54:ff:fe75:8012:ntp :::* users:(("ntpd",1976,27)) UNCONN 0 0 fe80::fc54:ff:feb3:4da8:ntp :::* users:(("ntpd",1976,25)) UNCONN 0 0 fe80::226:2dff:fe47:309f:ntp :::* users:(("ntpd",1976,20)) UNCONN 0 0 fe80::2e0:4cff:fe90:40eb:ntp :::* users:(("ntpd",1976,19)) UNCONN 0 0 ::1:ntp :::* users:(("ntpd",1976,18)) UNCONN 0 0 :::ntp :::* users:(("ntpd",1976,17)) UNCONN 0 0 :::892 :::* users:(("rpc.mountd",1888,9)) UNCONN 0 0 :::896 :::* users:(("rpcbind",1569,10)) UNCONN 0 0 :::32769 :::* UNCONN 0 0 :::nfs :::* UNCONN 0 0 :::syslog :::* users:(("rsyslogd",1506,2)) UNCONN 0 0 :::pftp :::* users:(("rpc.statd",1643,10)) UNCONN 0 0 fe80::2e0:4cff:fe90:40eb:kpasswd :::* users:(("kadmind",1926,8)) UNCONN 0 0 fe80::226:2dff:fe47:309f:kpasswd :::* users:(("kadmind",1926,7)) UNCONN 0 0 :::59603 :::* users:(("squid",2124,8)) 

Voici des exemples supplémentaires que vous pouvez utiliser avec les ss, y compris les connections par process.

http://www.cyberciti.biz/files/ss.html

Vous pouvez save chaque connection UDP à l'aide d'iptables:

 iptables -A INPUT -p udp -j LOG --log-prefix "udp connection: " 

Peut-être que vous voudrez peut-être le limiter à certains ports. Vérifiez la documentation ici ou, de preference, man iptables .

Comme d'autres l'ont mentionné, UDP est sans connection, alors l'état n'est pas suivi dans les locations standard que vous pourriez regarder.

Une méthode que vous pouvez utiliser consiste simplement à configurer certaines règles netfilter simples qui utilisent l'option --state . Cela obligera netfilter à suivre l'état lié à UDP. Une fois que vous avez configuré les règles, vous pouvez utiliser un outil comme conntrack pour regarder la table d'état netfilter. Voici, par exemple, ce que ressemble un de mes systèmes. Vous pouvez voir qu'il existe quelques systèmes fréquemment communiqués à udp / 1194 (OpenVPN).

 root@enterprise:# conntrack -L -p udp udp 17 173 src=192.168.32.1 dst=192.168.32.10 sport=41179 dport=1194 packets=2072 bytes=188058 src=192.168.32.10 dst=192.168.32.1 sport=1194 dport=41179 packets=2081 bytes=201185 [ASSURED] mark=0 secmark=0 use=1 udp 17 175 src=192.168.32.26 dst=192.168.32.10 sport=57440 dport=1194 packets=806767 bytes=154637738 src=192.168.32.10 dst=192.168.32.26 sport=1194 dport=57440 packets=1265893 bytes=1588040830 [ASSURED] mark=0 secmark=0 use=1 

Vos règles netfilter pourraient être aussi simples que cela.

 /sbin/iptables -t filter -A INPUT -m state --state NEW\,ESTABLISHED -j ACCEPT /sbin/iptables -t filter -A FORWARD -m state --state NEW\,ESTABLISHED -j ACCEPT /sbin/iptables -t filter -A OUTPUT -m state --state NEW\,ESTABLISHED -j ACCEPT 

inspiré de cette réponse , j'ai constaté que la syntaxe ss suivante fonctionne pour moi:

 ss -u state CLOSE 

… parce que les sockets UDP «écoutantes» sont comme des sockets TCP «fermés».

  • Solution pour tracer / proxy SNMP Traps (ou Netflow, UDP générique, etc.) pour la surveillance du réseau?
  • Impossible de se connecter au server Python sur LAN
  • Est-ce que OpenVPN UDP est vulnérable au coeur?
  • Poinçonnage symésortingque NAT et UDP
  • Où la documentation qui indique TCP et UDP source port devrait-elle être supérieure à 1024 et random?
  • lié le problème udp
  • Comment les datagrammes UDP ne me possèdent pas en tant que destinataire atteignant mon server?
  • Php-fpm php_network_getaddresses appelle démarrer de manière aléatoire avec mauvais udp cksum
  • Clients de blocs basés sur RTT
  • Problème UDP / TFTP étrange
  • Le livre blanc du fournisseur dit: 5Mpps no prob. Je frappe déjà un mur à 120kpps. Où est le goulot d'étranglement?
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.