IMPORTANT: Per accedir als fitxer de subversion: http://acacha.org/svn (sense password). Poc a poc s'aniran migrant els enllaços. Encara però funciona el subversion de la farga però no se sap fins quan... (usuari: prova i la paraula de pas 123456)

ICMP

De SergiTurWiki
Share/Save/Bookmark
(S'ha redirigit des de: Ping com traceroute)
Dreceres ràpides: navegació, cerca

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:

  • ICMPv4: ICMP per al protocol IP versió 4
  • ICMPv6: ICMP per al protocol IP versió 6

Contingut

Protocol ICMP

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.

Conceptes

Capçalera ICMP

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
  • Primer byte: indica el ICMP type
  • Segon byte: indica el ICMP code
  • Tercer i quart bytes: són el checksum tel missatge icmp sencer (ICMP message). El algorisme s'especifica al RFC 1071.
  • Resta de bytes: depenen dels tipus i el codi ICMP

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:

Tipus de missatges

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


Echo Reply i Echo Request

Vegeu ping

Destination unreacheable

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.

Destination unreachable message<ref name=rfc792/>Plantilla:Rp
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:

Type field (bits 0-7) must be set to 3
Code field (bits 8-15) is used to specify the type of error, and can be any of the following:
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).
Next-hop MTU field (bits 48-63) contains the MTU of the next-hop network if a code 4 error occurs.
IP header and additional data is included to allow the client to match the reply with the request that caused the destination unreachable reply.
icmp-net-unreachable

TODO

Es pot forçar l'enviament d'aquest tipus de paquets amb Policy_Routing:

Policy_Routing#unreachable
icmp-host-unreachable

Similar a l'anterior però aquest cas referent a una sola màquina i no pas a una xarxa.

icmp-port-unreachable
icmp-proto-unreachable
icmp-net-prohibited

TODO

Es pot forçar l'enviament d'aquest tipus de paquets amb Policy_Routing:

Policy_Routing#prohibited
icmp-host-prohibited

Similar a l'anterior però per a una màquina concreta en comptes de una xarxa completa.

icmp-admin-prohibited

Time exceeded

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:

Type must be set to 11
Code specifies the reason for the time exceeded message, include the following:
Code Description
0 Time-to-live exceeded in transit.
1 Fragment reassembly time exceeded.
IP header and first 64 bits of the original payload are used by the source host to match the time exceeded message to the discarded datagram. For higher level protocols such as UDP and TCP the 64 bit payload will include the source and destination ports of the discarded packet.


icmp-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.


Variables sysctl

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

icmp_echo_ignore_broadcasts

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

icmp-fragmentation-needed

Vegeu Ethernet#Path_MTU_Discovery

Altres

$ 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

Ping

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:

  • www.google.es és la mateixa màquina que www.l.google.com i la seva IP és 216.239.59.99.

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:

  • Ping of death (POD): El ping de la mort explota un error (bug) que feia que moltes màquines deixessin de funcionar a l'enviar un paquet IP de més de 65,536 bytes. Era un bug fàcil d'explotar però des del 1997-98 que es va començar a solucionar aquest error i actualment és un error que ha passat a la història.
  • Ping flooding: És un atac de denegació de servei (Deny of Service DOS) amb el qual s'inunda una màquina de tràfic ping de tal manera que el tràfic normal deixa de funcionar correctament.

Veieu la secció ús de la comanda ping per tal d'entendre millor el funcionament del protocol ARP.

Història

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]

ping com a traceroute

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:

Ping, MTU i fragmentació

Consulteu Maximum_Transfer_Unit#Path_MTU_Discovery

Mida del paquet ping

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
...

Pingmtu3200.png

Manual

$ 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

ping6

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

Paquet iputils-ping

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

Ping rate limit

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:

-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.

Paràmetres sysctl

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.

icmp_ratelimit

$ 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:

ICMP Redirect

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

Ping i multicast

Consulteu:

Multicast#Comanda_ping

Túnels ICMP

Consulteu Túnels ICMP.

tcpdump

Vegeu tcpdump#ICMP.

iptables

Vegeu Iptables#Bloquejar_pings_.28ICMP.29 i Iptables#REJECT

Resol·lució de problemes

Els pings s'envien lentament

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.

Vegeu també

Enllaços externs

OpenFPnet
IES Nicolau Copèrnic