El Internet Control Message Protocol (ICMP) és un dels protocols core d'Internet (aka Internet Protocol Suite). És utilitzat pels sistemes operatius dels nodes d'una xarxa per enviar missatges d'error de comunicació entre nodes com per exemple que un node no esta accessible o un servei no està disponible.
El sistema operatiu pot ser un SO d'estacions de treball com Windows o Linux, o altres sistemes més específics de nodes de xarxa com routers - routerOS, Cisco IOS, etc...)
TODO ICMP can also be used to relay query messages.[1]
El número de protocol és el 1
Cal tenir en compte que a diferència de TCP o UDP no s'utilitza per enviar dades entre sistemes.
Algunes aplicacions com ping o traceroute depenen en gran manera d'aquest protocol.
Cal tenir en compte que hi ha dos versions:
The Internet Control Message Protocol is part of the Internet Protocol Suite, as defined in RFC 792. ICMP messages are typically used for diagnostic or control purposes or generated in response to errors in IP operations (as specified in RFC 1122). ICMP errors are directed to the source IP address of the originating packet.[1]
For example, every device (such as an intermediate router) forwarding an IP datagram first decrements the time to live (TTL) field in the IP header by one. If the resulting TTL is 0, the packet is discarded and an ICMP Time To Live exceeded in transit message is sent to the datagram's source address.
Although ICMP messages are contained within standard IP datagrams, ICMP messages are usually processed as a special case, distinguished from normal IP processing, rather than processed as a normal sub-protocol of IP. In many cases, it is necessary to inspect the contents of the ICMP message and deliver the appropriate error message to the application that generated the original IP packet, the one that prompted the sending of the ICMP message.
Many commonly used network utilities are based on ICMP messages. The tracert (traceroute), Pathping commands are implemented by transmitting UDP datagrams with specially set IP TTL header fields, and looking for ICMP Time to live exceeded in transit (above) and "Destination unreachable" messages generated in response. The related ping utility is implemented using the ICMP "Echo request" and "Echo reply" messages.
ICMP és un protocol que corre sobre el protocol IP i no utilitza ni TCP ni UDP. Tots els paquets ICMP tenen una capçalera de mida de 8 bytes (64 bits) i una mida de les dades (payload) variable·
Els 4 primers Bytes de la capçalera (header) han de ser consistents:
| Bits | 0–7 | 8–15 | 16–23 | 24–31 |
|---|---|---|---|---|
| 0 | Type | Code | Checksum | |
| 32 | Rest of Header | |||
ICMP error messages contenen una secció de dades que inclou el header del protocol IP sencer més els els primers 8 bytes de dades del datagrama IP que va causar el missatge d'error.
Recursos:
Consulteu també Iptables#REJECT
| Type | Code | Description |
|---|---|---|
| 0 – Echo Reply<ref name=rfc792/>Plantilla:Rp | 0 | Echo reply (used to ping) |
| 1 and 2 | Reserved | |
| 3 – Destination Unreachable<ref name=rfc792/>Plantilla:Rp | 0 | Destination network unreachable |
| 1 | Destination host unreachable | |
| 2 | Destination protocol unreachable | |
| 3 | Destination port unreachable | |
| 4 | Fragmentation required, and DF flag set | |
| 5 | Source route failed | |
| 6 | Destination network unknown | |
| 7 | Destination host unknown | |
| 8 | Source host isolated | |
| 9 | Network administratively prohibited | |
| 10 | Host administratively prohibited | |
| 11 | Network unreachable for TOS | |
| 12 | Host unreachable for TOS | |
| 13 | Communication administratively prohibited | |
| 14 | Host Precedence Violation | |
| 15 | Precedence cutoff in effect | |
| 4 – Source Quench | 0 | Source quench (congestion control) |
| 5 – Redirect Message | 0 | Redirect Datagram for the Network |
| 1 | Redirect Datagram for the Host | |
| 2 | Redirect Datagram for the TOS & network | |
| 3 | Redirect Datagram for the TOS & host | |
| 6 | Alternate Host Address | |
| 7 | Reserved | |
| 8 – Echo Request | 0 | Echo request (used to ping) |
| 9 – Router Advertisement | 0 | Router Advertisement |
| 10 – Router Solicitation | 0 | Router discovery/selection/solicitation |
| 11 – Time Exceeded<ref name=rfc792/>Plantilla:Rp | 0 | TTL expired in transit |
| 1 | Fragment reassembly time exceeded | |
| 12 – Parameter Problem: Bad IP header | 0 | Pointer indicates the error |
| 1 | Missing a required option | |
| 2 | Bad length | |
| 13 – Timestamp | 0 | Timestamp |
| 14 – Timestamp Reply | 0 | Timestamp reply |
| 15 – Information Request | 0 | Information Request |
| 16 – Information Reply | 0 | Information Reply |
| 17 – Address Mask Request | 0 | Address Mask Request |
| 18 – Address Mask Reply | 0 | Address Mask Reply |
| 19 | Reserved for security | |
| 20 through 29 | Reserved for robustness experiment | |
| 30 – Traceroute | 0 | Information Request |
| 31 | Datagram Conversion Error | |
| 32 | Mobile Host Redirect | |
| 33 | Where-Are-You (originally meant for IPv6) | |
| 34 | Here-I-Am (originally meant for IPv6) | |
| 35 | Mobile Registration Request | |
| 36 | Mobile Registration Reply | |
| 37 | Domain Name Request | |
| 38 | Domain Name Reply | |
| 39 | SKIP Algorithm Discovery Protocol, Simple Key-Management for Internet Protocol | |
| 40 | Photuris, Security failures | |
| 41 | ICMP for experimental mobility protocols such as Seamoby [RFC4065] | |
| 42 through 255 | Reserved |
Vegeu ping
Destination unreachable són paquets generats per routers que contesten a un host que intenta fer una c
Vegeu també Iptables#REJECT
is generated by the host or its inbound gateway]<ref name=rfc792/> to inform the client that the destination is unreachable for some reason. A Destination Unreachable message may be generated as a result of a TCP, UDP or another ICMP transmission. Unreachable TCP ports notably respond with TCP RST rather than a Destination Unreachable type 3 as might be expected.
The error will not be generated if the original datagram has a multicast destination address. Reasons for this message may include: the physical connection to the host does not exist (distance is infinite); the indicated protocol or port is not active; the data must be fragmented but the 'don't fragment' flag is on.
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Type = 3 | Code | Header checksum | |||||||||||||||||||||||||||||
| unused | Next-hop MTU | ||||||||||||||||||||||||||||||
| IP header and first 8 bytes of original datagram's data | |||||||||||||||||||||||||||||||
Where:
| Code | Description |
|---|---|
| 0 | Network unreachable error. |
| 1 | Host unreachable error. |
| 2 | Protocol unreachable error (the designated transport protocol is not supported). |
| 3 | Port unreachable error (the designated protocol is unable to inform the host of the incoming message). |
| 4 | The datagram is too big. Packet fragmentation is required but the 'don't fragment' (DF) flag is on. |
| 5 | Source route failed error. |
| 6 | Destination network unknown error. |
| 7 | Destination host unknown error. |
| 8 | Source host isolated error. |
| 9 | The destination network is administratively prohibited. |
| 10 | The destination host is administratively prohibited. |
| 11 | The network is unreachable for Type Of Service. |
| 12 | The host is unreachable for Type Of Service. |
| 13 | Communication administratively prohibited (administrative filtering prevents packet from being forwarded). |
| 14 | Host precedence violation (indicates the requested precedence is not permitted for the combination of host or network and port). |
| 15 | Precedence cutoff in effect (precedence of datagram is below the level set by the network administrators). |
TODO
Es pot forçar l'enviament d'aquest tipus de paquets amb Policy_Routing:
Policy_Routing#unreachable
Similar a l'anterior però aquest cas referent a una sola màquina i no pas a una xarxa.
TODO
Es pot forçar l'enviament d'aquest tipus de paquets amb Policy_Routing:
Policy_Routing#prohibited
Similar a l'anterior però per a una màquina concreta en comptes de una xarxa completa.
Vegeu TTL i traceroute i exemple de com utilitzar ping com a traceroute i modificar el TTL a:
ICMP#ping_com_a_traceroute
Time Exceeded is generated by a gateway to inform the source of a discarded datagram due to the time to live field reaching zero. A time exceeded message may also be sent by a host if it fails to reassemble a fragmented datagram within its time limit.
Time exceeded messages are used by the traceroute utility to identify gateways on the path between two hosts.
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Type = 11 | Code | Header checksum | |||||||||||||||||||||||||||||
| unused | |||||||||||||||||||||||||||||||
| IP header and first 8 bytes of original datagram's data | |||||||||||||||||||||||||||||||
Where:
| Code | Description |
|---|---|
| 0 | Time-to-live exceeded in transit. |
| 1 | Fragment reassembly time exceeded. |
És el paquet ICMP que envia un encaminador quan rep un paquet amb el TTL a 0. Podeu veure exemples a ping com traceroute, traceroute i com funciona traceroute.
Consulteu també sysctl
La màquina (o les interfícies de xarxa) accepten ICMP Redirects?
/proc/sys/net/ipv4/conf/all/accept_redirects
O altres com:
/proc/sys/net/ipv4/conf/default/accept_redirects /proc/sys/net/ipv4/conf/lo/accept_redirects /proc/sys/net/ipv4/conf/eth0/accept_redirects /proc/sys/net/ipv4/conf/wmaster0/accept_redirects /proc/sys/net/ipv4/conf/wlan0/accept_redirects /proc/sys/net/ipv4/conf/vboxnet0/accept_redirects /proc/sys/net/ipv4/conf/pan0/accept_redirects /proc/sys/net/ipv6/conf/all/accept_redirects /proc/sys/net/ipv6/conf/default/accept_redirects /proc/sys/net/ipv6/conf/lo/accept_redirects /proc/sys/net/ipv6/conf/eth0/accept_redirects /proc/sys/net/ipv6/conf/wmaster0/accept_redirects /proc/sys/net/ipv6/conf/wlan0/accept_redirects /proc/sys/net/ipv6/conf/vboxnet0/accept_redirects /proc/sys/net/ipv6/conf/pan0/accept_redirects
Determina si la màquina contestarà o no a pings de broadcast. Per defecte normalment la configuració és que no contestarà (configuració de seguretat per evitar inundacions per IPs de broadcast). Per canviar-ho:
$ sudo -i # echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
Vegeu Ethernet#Path_MTU_Discovery
$ sudo find /proc -name icmp /proc/sys/net/ipv6/icmp
$ cat /proc/sys/net/ipv4/icmp_ (tabuleu dos cops...) icmp_echo_ignore_all icmp_ignore_bogus_error_responses icmp_echo_ignore_broadcasts icmp_ratelimit icmp_errors_use_inbound_ifaddr icmp_ratemask
La comanda Ping s'utilitza com a eina de diagnostic per tal de saber quan un host és accessible o no des de la nostra màquina. La comanda ping utilitza el protocol ICMP enviant un paquet Echo Request ICMP i esperant una resposta Echo Response ICMP. Al paquet Echo Request sovint se l'anomena "Ping" i al paquet Echo Response "Pong" en analogia amb el "Ping-Pong".
Un exemple d'ús de ping:
$ ping www.google.es PING www.l.google.com (216.239.59.99) 56(84) bytes of data. 64 bytes from 216.239.59.99: icmp_seq=1 ttl=245 time=109 ms 64 bytes from 216.239.59.99: icmp_seq=2 ttl=245 time=113 ms 64 bytes from 216.239.59.99: icmp_seq=3 ttl=245 time=109 ms 64 bytes from 216.239.59.99: icmp_seq=4 ttl=245 time=109 ms --- www.l.google.com ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3000ms rtt min/avg/max/mdev = 109.691/110.782/113.765/1.739 ms
Utilitzem el paràmetre -c per limitar el nombre de paquets ping que enviem. En Linux, la comanda ping no té límits al enviar paquets... Si executem:
$ ping -c 4 www.google.es PING www.l.google.com (216.239.59.99) 56(84) bytes of data. 64 bytes from 216.239.59.99: icmp_seq=1 ttl=245 time=109 ms 64 bytes from 216.239.59.99: icmp_seq=2 ttl=245 time=113 ms 64 bytes from 216.239.59.99: icmp_seq=3 ttl=245 time=109 ms 64 bytes from 216.239.59.99: icmp_seq=4 ttl=245 time=109 ms 64 bytes from 216.239.59.99: icmp_seq=4 ttl=245 time=109 ms 64 bytes from 216.239.59.99: icmp_seq=4 ttl=245 time=109 ms 64 bytes from 216.239.59.99: icmp_seq=4 ttl=245 time=109 ms .....................
Hem de pressionar les tecles Ctrl+C per aturar la comanda ping i poder veure les estadístiques:
--- www.l.google.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 109.946/110.854/111.669/0.804 ms
Tal i com podem veure en l'exemple la comanda ping també ens serveix per a conèixer l'adreça IP d'una màquina a partir del seu nom. De l'exemple veiem que:
Podem utilitzar la comanda ping directament amb IPs:
$ ping 216.239.59.99 PING 216.239.59.99 (216.239.59.99) 56(84) bytes of data. 64 bytes from 216.239.59.99: icmp_seq=1 ttl=245 time=112 ms .........................
Però en aquest cas no obtindrem el nom de màquina.
Es pot fer un ping a totes les màquines de la xarxa utilitzant l'adreça de broadcast:
$ ping -b 192.169.1.255
També es pot fer un ping a l'adreça de broadcast de multicast:
$ ping 224.0.0.1
Consulteu també:
Multicast#Comanda_ping
NOTA: La majoria de màquines con contesten. Per que ho facin cal desactivar icmp_echo_ignore_broadcasts:
$ sudo -i # echo 0 >/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
Hi han altres paràmetres de sistema relacionats amb el protocol ICMP:
# ls -la /proc/sys/net/ipv4/icmp* -rw-r--r-- 1 root root 0 2009-05-04 16:43 /proc/sys/net/ipv4/icmp_echo_ignore_all -rw-r--r-- 1 root root 0 2009-05-04 16:43 /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts -rw-r--r-- 1 root root 0 2009-05-04 16:43 /proc/sys/net/ipv4/icmp_errors_use_inbound_ifaddr -rw-r--r-- 1 root root 0 2009-05-04 16:43 /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses -rw-r--r-- 1 root root 0 2009-05-04 16:43 /proc/sys/net/ipv4/icmp_ratelimit -rw-r--r-- 1 root root 0 2009-05-04 16:43 /proc/sys/net/ipv4/icmp_ratemask
Per exemple es poden ignorar tots els paquets ICMP activant icmp_echo_ignore_all:
# echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
O establir un rati màxim de pings a rebre amb icmp_ratelimit
$ cat /proc/sys/net/ipv4/icmp_ratelimit 100
La comanda ping també s'ha utilitzat per a usos fraudulents. Hi ha dos usos molt coneguts:
Veieu la secció ús de la comanda ping per tal d'entendre millor el funcionament del protocol ARP.
La utilitat ping es va crear al desembre de 1983 per Mike Muuss com una eina per diagnosticar problemes en xarxes IP. Li va posar aquest en analogia al soroll que fa un radar/sonar i perque la metodologia és similar a un onar's echo location
TODO:
Host discovery or ping scanning or ping sweep is still a part of network scanning tools like nmap, as it may give basic evidence about the existence of a remote machine.
RFC 1122 prescribes that any host must accept an echo-request and issue an echo-reply in return.[3] This has been characterized as a security risk.[4]
Vegeu també traceroute i TTL.
Es pot fer amb l'opció -R:
$ ping -nR www.xtec.cat PING xtec.cat (213.176.161.13) 56(124) bytes of data. 64 bytes from 213.176.161.13: icmp_seq=1 ttl=251 time=54.3 ms NOP RR: 192.168.0.46 213.176.160.157 213.176.160.26 213.176.161.1 213.176.161.13 213.176.160.19 213.176.160.153 10.19.41.1 85.192.120.9 64 bytes from 213.176.161.13: icmp_seq=2 ttl=251 time=52.9 ms NOP (same route) 64 bytes from 213.176.161.13: icmp_seq=3 ttl=251 time=53.1 ms NOP (same route)
També es pot fer salt a salt canviant el TTL:
$ ping -t 1 www.xtec.cat
Us contestarà un paquet ICMP Time To Live Exceeded, tipus paquet 11 ICMP des del vostre gateway (primer servidor de la vostra ruta). En canvi:
$ ping -t 2 www.xtec.cat
Us contestarà el TTL des de la segona màquina de la vostra ruta. La següent ordre:
$ ping -t 3 www.xtec.cat
Us contestarà el TTL des de la segona màquina de la vostra ruta i així successivament.
Vegeu el paquet de resposta amb tcpdump:
$ sudo tcpdump -n -i eth0 icmp listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 19:47:06.502594 IP 192.168.204.100 > 8.8.8.8: ICMP echo request, id 2915, seq 168, length 64 19:47:06.521714 IP 149.6.130.113 > 192.168.204.100: ICMP time exceeded in-transit, length 36
IMPORTANT: Depenent de la configuració dels encaminadors intermediaris (p.ex un firewall), us podeu trobar que no us contestin
Consulteu:
Consulteu Maximum_Transfer_Unit#Path_MTU_Discovery
Es pot indicar amb el paràmetre -s (size). La mida màxima és 65515 (a la mida indicada se li sumen 8 bytes de la capçalera ICMP):
$ ping -s 65507 192.168.204.100 PING 192.168.204.100 (192.168.204.100) 65507(65535) bytes of data. 65515 bytes from 192.168.204.100: icmp_req=1 ttl=64 time=0.165 ms 65515 bytes from 192.168.204.100: icmp_req=2 ttl=64 time=0.154 ms 65515 bytes from 192.168.204.100: icmp_req=3 ttl=64 time=0.157 ms 65515 bytes from 192.168.204.100: icmp_req=4 ttl=64 time=0.150 ms
Si us passeu us donarà error:
$ ping -s 65508 192.168.204.100 Error: packet size 65508 is too large. Maximum is 65507
La mida màxima d'un paquet IP és 65535 - 20 de la capçalera Ip us dona el valor màxim (un paquet ICMP ha de cabre dins de un sol paquet IP).
Pot ser que les mides estiguin truncades per routers pels que passeu:
$ ping -s 80 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 80(108) bytes of data. 72 bytes from 8.8.8.8: icmp_req=1 ttl=46 (truncated) 72 bytes from 8.8.8.8: icmp_req=2 ttl=46 (truncated) ...
$ ping -s 3200 192.168.204.1 PING 192.168.204.1 (192.168.204.1) 3200(3228) bytes of data. 3208 bytes from 192.168.204.1: icmp_req=1 ttl=64 time=64.2 ms 3208 bytes from 192.168.204.1: icmp_req=2 ttl=64 time=5.48 ms ...
$ man ping PING(8) System Manager's Manual: iputils PING(8) NAME ping, ping6 - send ICMP ECHO_REQUEST to network hosts SYNOPSIS ping [-LRUbdfnqrvVaAB] [-c count] [-m mark] [-i interval] [-l preload] [-p pattern] [-s packetsize] [-t ttl] [-w deadline] [-F flowlabel] [-I interface] [-M hint] [-N nioption] [-Q tos] [-S sndbuf] [-T timestamp option] [-W timeout] [hop ...] destination DESCRIPTION ping uses the ICMP protocol's mandatory ECHO_REQUEST datagram to elicit an ICMP ECHO_RESPONSE from a host or gateway. ECHO_REQUEST data‐ grams (``pings) have an IP and ICMP header, followed by a struct timeval and then an arbitrary number of ``pad bytes used to fill out the packet. ping6 can also send Node Information Queries (RFC4620). OPTIONS -a Audible ping. -A Adaptive ping. Interpacket interval adapts to round-trip time, so that effectively not more than one (or more, if preload is set) unanswered probes present in the network. Minimal interval is 200msec for not super-user. On networks with low rtt this mode is essentially equivalent to flood mode. -b Allow pinging a broadcast address. -B Do not allow ping to change source address of probes. The address is bound to one selected when ping starts. -m mark use mark to tag the packets going out. This is useful for variety of reasons within the kernel such as using policy routing to select specific outbound processing. -c count Stop after sending count ECHO_REQUEST packets. With deadline option, ping waits for count ECHO_REPLY packets, until the timeout expires. -d Set the SO_DEBUG option on the socket being used. Essentially, this socket option is not used by Linux kernel. -F flow label Allocate and set 20 bit flow label on echo request packets. (Only ping6). If value is zero, kernel allocates random flow label. -f Flood ping. For every ECHO_REQUEST sent a period ``. is printed, while for ever ECHO_REPLY received a backspace is printed. This provides a rapid display of how many packets are being dropped. If interval is not given, it sets interval to zero and outputs pack‐ ets as fast as they come back or one hundred times per second, whichever is more. Only the super-user may use this option with zero interval. -i interval Wait interval seconds between sending each packet. The default is to wait for one second between each packet normally, or not to wait in flood mode. Only super-user may set interval to values less 0.2 seconds. -I interface address Set source address to specified interface address. Argument may be numeric IP address or name of device. When pinging IPv6 link-local address this option is required. -l preload If preload is specified, ping sends that many packets not waiting for reply. Only the super-user may select preload more than 3. -L Suppress loopback of multicast packets. This flag only applies if the ping destination is a multicast address. -N nioption Send ICMPv6 Node Information Queries (RFC4620), instead of Echo Request. name Queries for Node Names. ipv6 Queries for IPv6 Addresses. There are several IPv6 specific flags. ipv6-global Request IPv6 global-scope addresses. ipv6-sitelocal Request IPv6 site-local addresses. ipv6-linklocal Request IPv6 link-local addresses. ipv6-all
Ping a la nostra adreça local
$ ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:0f:fe:e2:8f:b7 inet addr:192.168.111.24 Bcast:192.168.111.255 Mask:255.255.255.0 inet6 addr: fe80::20f:feff:fee2:8fb7/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1638660 errors:0 dropped:0 overruns:0 frame:0 TX packets:1597862 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:926171814 (926.1 MB) TX bytes:179286277 (179.2 MB) Memory:f0180000-f01a0000
$ ping6 -I eth0 fe80::20f:feff:fee2:8fb7 PING fe80::20f:feff:fee2:8fb7(fe80::20f:feff:fee2:8fb7) from fe80::20f:feff:fee2:8fb7 eth0: 56 data bytes 64 bytes from fe80::20f:feff:fee2:8fb7: icmp_seq=1 ttl=64 time=0.033 ms 64 bytes from fe80::20f:feff:fee2:8fb7: icmp_seq=2 ttl=64 time=0.042 ms ...
Recursos:
Vegeu també IPv6
A la familia Debian és el nom del paquet que proporciona les comandes ping:
$ sudo dpkg -L iputils-ping /. /bin /bin/ping /bin/ping6 /usr /usr/share /usr/share/lintian /usr/share/lintian/overrides /usr/share/lintian/overrides/iputils-ping /usr/share/doc /usr/share/doc/iputils-ping /usr/share/doc/iputils-ping/copyright /usr/share/doc/iputils-ping/RELNOTES.gz /usr/share/doc/iputils-ping/changelog.Debian.gz /usr/share/man /usr/share/man/man8 /usr/share/man/man8/ping.8.gz /usr/share/man/man8/ping6.8.gz
Si feu un simple ping
$ sudo ping localhost
Veureu que contesta a raó d'un ping per segon aproximadament. Podeu anar més lent o menys amb l'opció:
-i
Per exemple cada 10 segons:
$ ping -i 10 192.168.201.1
O més ràpid (el doble de ràpid que el valor per defecte):
$ ping -i 0.5 192.168.201.1
L'usuari normal té un límit:
$ ping -i 0.19 192.168.201.1 PING 192.168.201.1 (192.168.201.1) 56(84) bytes of data. ping: cannot flood; minimal interval, allowed for user, is 200ms
Per evitar Flooding (vegeu Ping Flooding)
El superusuari pot però fer flooding:
$ sudo ping -i 0 192.168.201.1
La comanda iptraf us pot ser útil per veure els pps (paquets per segon) que genereu.
Rate-limiting settings are specified in jiffies, a unit of time dependence defined as one tick of the system timer interrupt: on x86 platforms (PCs), a jiffy is usually 0.01 seconds. The value given for the ratelimit is the number of jiffies the kernel must wait for, before sending another ICMP message of the same type. The default value is 100, that is, an interval of 100 jiffies, or 1 second between ICMP messages. A value of 10 would allow 10 ICMP messages per second. This is slightly counter-intuitive because common sense suggests that lower values would equate to better flood protection.
icmp_ratelimit is the maximum rate at which the kernel generates icmp messages of the types specified by icmp_ratemask (see icmp_ratemask). The value is the number of jiffies the kernel has to wait between sending two such messages. Therefore zero means no limit. Typically 1 jiffy = 1/100 sec, so a value of 1 means no more than 100/sec, a value of 100 means no more than 1/sec. Per default, this variable is set to 100, which means 1 ICMP packet may be sent in 100 jiffies. If we set it to 1, we allow 100 ICMP packets per second, and 0 means unlimited ICMP sendings.
Feu una prova, feu-vos un ping:
$ ping localhost
Ara executeu:
$ sudo -i # echo 200 > /proc/sys/net/ipv4/icmp_ratelimit
Ara torneu a consultar el ping. Va més ràpid?
Veureu que no. Això és que per defecte la comanda ping envia una petició per segon per defecte. Es pot modificar aquesta velocitat amb el paràmetre:
Acacha Wiki-i interval
Wait interval seconds between sending each packet. The default is to wait for one second between
each packet normally, or not to wait in flood mode. Only
super-user may set interval to values less 0.2 seconds.
Com podeu veure només el superusuari pot enviar paquets ping a velocitats més ràpides que 1 paquet cada 0,2 segons.
$ ping -i 0.3 localhost PING localhost (127.0.0.1) 56(84) bytes of data. 64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.078 ms 64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.084 ms 64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.078 ms 64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0.079 ms 64 bytes from localhost (127.0.0.1): icmp_seq=5 ttl=64 time=0.080 ms 64 bytes from localhost (127.0.0.1): icmp_seq=6 ttl=64 time=0.083 ms 64 bytes from localhost (127.0.0.1): icmp_seq=7 ttl=64 time=0.082 ms 64 bytes from localhost (127.0.0.1): icmp_seq=8 ttl=64 time=0.076 ms
Proveu de fer un ping flood (només permès al superusuari):
$ sudo ping -i 0 localhost
O també:
$ sudo ping -f localhost
Podeu comprovar els paquets amb:
$ sudo tcpdump -n icmp -i lo
icmp_ratemask
Valor per defecte:
$ cat /proc/sys/net/ipv4/icmp_ratemask 6168
The icmp_ratemask variable sets the mask of which ICMP types should be ratelimited with the icmp_ratelimit variable. The types are put together in the mask by setting specific bits in this variable. icmp_ratemask is the sum of 2^n for each icmp type you wish to ratelimit, and where n is each ICMP type as specified in the header files of the kernel. This ensures that each bit has a specific meaning. All of the different ICMP names and their corresponding values are available in the include file netinet/ip_icmp.h (generally /usr/include/netinet/ip_icmp.h on most systems). For more information about the different ICMP values and their meaning, see RFC 792 - Internet Control Message Protocol. This would be the complete mathematical formula for the expression: For all ICMP types n to be rate limited. For example, if you want to include the ICMP Destination unreachable type in the ratemask, we would notice that this has the value 3 in the header files. To do the conversion then, we would calculate 2^3, which turns out to be 8. Finally, you would or this to the bitmask that you already have. So, if your mask already is 6160, you would go 6160+8 which should do the trick. To or two values means to only add the new entry, in case it was not added previously, in a binary way.
Caution Make absolutely sure that the ratemask does not contain the bitmask that you want to add. If you fail to notice such a problem, your ratemask will become totally wrong. If you have 256 set already, and then try to set 256 again according to this description, you will wind up with ICMP Echo Request unset, and ICMP type 9 set. ICMP type 9 does not exist. The default value of this variable is 6168, which means that ICMP Destination Unreachable, ICMP Source Quench, ICMP Time Exceeded and ICMP Parameter Problem is in the mask. ICMP Destination Unreachable equals 3, ICMP Source Quench equals 4, ICMP Time Exceeded equals 11 and ICMP Parameter Problem equals 12. Hence, the default value is calculated like this: Note An attacker could cause a correctly operating host or router to flood a victim with ICMP replies by sending it packets that generate replies back to the (forged) source address of the victim. It is important in some cases to send such replies, but hardly ever important to generate them at a very high rate. Tip There is a small program to output the proper ICMP ratemask called ratemask, which is available at http://www.frozentux.net. It may be of some help when creating icmp_ratemasks, or if you want to find out what the current value means.
icmp_echo_ignore_all
Si s'activa s'ignoren completament els ICMP Echo requests. El valor per defecte és 0.
icmp_echo_ignore_broadcasts
Si s'activa s'ignoren completament els ICMP Echo requests enviats a tothom (broadcast) . El valor per defecte és 0 però distribucions com Ubuntu activen aquest paràmetre.
icmp_ignore_bogus_error_responses
There are some routers on the internet and in other places that ignore the standards drawn up in RFC 1122 and sends out bogus responses to broadcast frames. Normally, these violations are logged via the kernel logging facilities, but if we do not want to see these error messages in our logs we may turn this variable on, which will lead to all such error messages being ignored totally. If you live close to such a router, you will save much harddrive space in not logging these messages.
This variable takes a boolean value as you may understand, and is per default set to 0 or off. If you need or want this option and want to get rid of some annoying error messages in your logs, you may turn this on.
$ cat /proc/sys/net/ipv4/icmp_ratelimit 1000
Valor per defecte:
Rate-limiting settings are specified in jiffies, a unit of time dependence defined as one tick of the system timer interrupt: on x86 platforms (PCs), a jiffy is usually 0.01 seconds. The value given for the ratelimit is the number of jiffies the kernel must wait for, before sending another ICMP message of the same type. The default value is 100, that is, an interval of 100 jiffies, or 1 second between ICMP messages. A value of 10 would allow 10 ICMP messages per second. This is slightly counter-intuitive because common sense suggests that lower values would equate to better flood protection.
icmp_ratelimit is the maximum rate at which the kernel generates icmp messages of the types specified by icmp_ratemask (see icmp_ratemask). The value is the number of jiffies the kernel has to wait between sending two such messages. Therefore zero means no limit. Typically 1 jiffy = 1/100 sec, so a value of 1 means no more than 100/sec, a value of 100 means no more than 1/sec. Per default, this variable is set to 100, which means 1 ICMP packet may be sent in 100 jiffies. If we set it to 1, we allow 100 ICMP packets per second, and 0 means unlimited ICMP sendings.
Feu una prova, feu-vos un ping:
$ sudo ping localhost
Veureu que contesta a rao d'un ping per segon aproximadament.
Ara executeu:
$ sudo -i # echo 200 > /proc/sys/net/ipv4/icmp_ratelimit
Ara torneu a consultar el ping. Va més ràpid?
Veureu que no. Això és que per defecte la comanda ping envia una petició per segon per defecte. Es pot modificar aquesta velocitat amb el paràmetre:
-i interval
Wait interval seconds between sending each packet. The default is to wait for one second between
each packet normally, or not to wait in flood mode. Only
super-user may set interval to values less 0.2 seconds.
Com podeu veure només el superusuari pot enviar paquets ping a velocitats més ràpides que 1 paquet cada 0,2 segons.
$ $ ping -i 0.3 localhost PING localhost (127.0.0.1) 56(84) bytes of data. 64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.078 ms 64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.084 ms 64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.078 ms 64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0.079 ms 64 bytes from localhost (127.0.0.1): icmp_seq=5 ttl=64 time=0.080 ms 64 bytes from localhost (127.0.0.1): icmp_seq=6 ttl=64 time=0.083 ms 64 bytes from localhost (127.0.0.1): icmp_seq=7 ttl=64 time=0.082 ms 64 bytes from localhost (127.0.0.1): icmp_seq=8 ttl=64 time=0.076 ms
Proveu de fer un ping flood (només permès al superusuari):
$ sudo ping -f localhost
Podeu comprovar els paquets amb:
$ sudo tcpdump -n icmp -i lo
icmp_ratemask
Valor per defecte:
$ cat /proc/sys/net/ipv4/icmp_ratemask 6168
The icmp_ratemask variable sets the mask of which ICMP types should be ratelimited with the icmp_ratelimit variable. The types are put together in the mask by setting specific bits in this variable. icmp_ratemask is the sum of 2^n for each icmp type you wish to ratelimit, and where n is each ICMP type as specified in the header files of the kernel. This ensures that each bit has a specific meaning. All of the different ICMP names and their corresponding values are available in the include file netinet/ip_icmp.h (generally /usr/include/netinet/ip_icmp.h on most systems). For more information about the different ICMP values and their meaning, see RFC 792 - Internet Control Message Protocol. This would be the complete mathematical formula for the expression: For all ICMP types n to be rate limited. For example, if you want to include the ICMP Destination unreachable type in the ratemask, we would notice that this has the value 3 in the header files. To do the conversion then, we would calculate 2^3, which turns out to be 8. Finally, you would or this to the bitmask that you already have. So, if your mask already is 6160, you would go 6160+8 which should do the trick. To or two values means to only add the new entry, in case it was not added previously, in a binary way.
Caution Make absolutely sure that the ratemask does not contain the bitmask that you want to add. If you fail to notice such a problem, your ratemask will become totally wrong. If you have 256 set already, and then try to set 256 again according to this description, you will wind up with ICMP Echo Request unset, and ICMP type 9 set. ICMP type 9 does not exist. The default value of this variable is 6168, which means that ICMP Destination Unreachable, ICMP Source Quench, ICMP Time Exceeded and ICMP Parameter Problem is in the mask. ICMP Destination Unreachable equals 3, ICMP Source Quench equals 4, ICMP Time Exceeded equals 11 and ICMP Parameter Problem equals 12. Hence, the default value is calculated like this: Note An attacker could cause a correctly operating host or router to flood a victim with ICMP replies by sending it packets that generate replies back to the (forged) source address of the victim. It is important in some cases to send such replies, but hardly ever important to generate them at a very high rate. Tip There is a small program to output the proper ICMP ratemask called ratemask, which is available at http://www.frozentux.net. It may be of some help when creating icmp_ratemasks, or if you want to find out what the current value means.
Recursos:
Paràmetres sysctl:
secure_redirects
Només permet rebre redireccions ICMP dels default gateways. Els defaults gateways són els especificats amb l'ordre route?
# find /proc -name secure_redirects /proc/sys/net/ipv4/conf/all/secure_redirects /proc/sys/net/ipv4/conf/default/secure_redirects /proc/sys/net/ipv4/conf/lo/secure_redirects /proc/sys/net/ipv4/conf/eth0/secure_redirects /proc/sys/net/ipv4/conf/eth1/secure_redirects /proc/sys/net/ipv4/conf/eth2/secure_redirects /proc/sys/net/ipv4/conf/eth3/secure_redirects /proc/sys/net/ipv4/conf/eth4/secure_redirects /proc/sys/net/ipv4/conf/eth5/secure_redirects /proc/sys/net/ipv4/conf/eth6/secure_redirects /proc/sys/net/ipv4/conf/eth7/secure_redirects /proc/sys/net/ipv4/conf/eth8/secure_redirects /proc/sys/net/ipv4/conf/eth9/secure_redirects /proc/sys/net/ipv4/conf/eth10/secure_redirects /proc/sys/net/ipv4/conf/eth11/secure_redirects /proc/sys/net/ipv4/conf/eth12/secure_redirects /proc/sys/net/ipv4/conf/pan0/secure_redirects
send_redirects
accept_redirects'
http://ipsysctl-tutorial.frozentux.net/ipsysctl-tutorial.html#AEN585
Consulteu també:
Man_In_The_Middle_Atacks#ICMP_Redirect
Consulteu:
Multicast#Comanda_ping
Consulteu Túnels ICMP.
Vegeu tcpdump#ICMP.
Vegeu Iptables#Bloquejar_pings_.28ICMP.29 i Iptables#REJECT
Cal que tingueu en compte que a Linux per defecte no hi ha cap tipus de cache DNS i que cada vegada que feu un ping a un nom de màquina, prèviament s'ha de resoldre el nom per DNS. A més cal també tenir en compte la resol·lució inversa de DNS.
El que observareu és que els temps de viatge d'anada i tornada dels pings és un temps raonable (time=), però s'envien menys de 1 ping per segon (ritme per defecte dels pings). Això sol ser pel fet de que fins que no dona un timeout per a la resol·lució inversa de DNS no s'envia el ping.
Amb l'opció -n:
$ ping -n IP
Es desactiva la resol·lució DNS.