Icmp port 3: Internet Control Message Protocol (ICMP) Parameters

Internet Control Message Protocol (ICMP) Parameters

Type 0 — Echo Reply

Registration Procedure(s)

IESG Approval or Standards Action

Reference

[RFC792][RFC2780]

Available Formats

CSV

Type 1 — Unassigned

Type 2 — Unassigned

Codes	Description	Reference
No registrations at this time.

Type 3 — Destination Unreachable

Registration Procedure(s)

IESG Approval or Standards Action

Reference

[RFC792][RFC2780]

Available Formats

CSV

Type 4 — Source Quench (Deprecated)

Reference

[RFC792][RFC6633]

Available Formats

CSV

Type 5 — Redirect

Registration Procedure(s)

IESG Approval or Standards Action

Reference

[RFC792][RFC2780]

Available Formats

CSV

Type 6 — Alternate Host Address (Deprecated)

Reference

[JBP][RFC6918]

Available Formats

CSV

Type 7 — Unassigned

Codes	Description	Reference
No registrations at this time.

Type 8 — Echo

Registration Procedure(s)

IESG Approval or Standards Action

Reference

[RFC792][RFC2780]

Available Formats

CSV

Type 9 — Router Advertisement

Registration Procedure(s)

IESG Approval or Standards Action

Reference

[RFC1256][RFC2780]

Available Formats

CSV

Type 10 — Router Selection

Registration Procedure(s)

IESG Approval or Standards Action

Reference

[RFC1256][RFC2780]

Available Formats

CSV

Type 11 — Time Exceeded

Registration Procedure(s)

IESG Approval or Standards Action

Reference

[RFC792][RFC2780]

Available Formats

CSV

Type 12 — Parameter Problem

Registration Procedure(s)

IESG Approval or Standards Action

Reference

[RFC792][RFC2780]

Available Formats

CSV

Type 13 — Timestamp

Registration Procedure(s)

IESG Approval or Standards Action

Reference

[RFC792][RFC2780]

Available Formats

CSV

Type 14 — Timestamp Reply

Registration Procedure(s)

IESG Approval or Standards Action

Reference

[RFC792][RFC2780]

Available Formats

CSV

Type 15 — Information Request (Deprecated)

Reference

[RFC792][RFC6918]

Available Formats

CSV

Type 16 — Information Reply (Deprecated)

Reference

[RFC792][RFC6918]

Available Formats

CSV

Type 17 — Address Mask Request (Deprecated)

Reference

[RFC950][RFC6918]

Available Formats

CSV

Type 18 — Address Mask Reply (Deprecated)

Reference

[RFC950][RFC6918]

Available Formats

CSV

Type 19 — Reserved (for Security)

Reference

[Solo]

Codes	Description	Reference
No registrations at this time.

Types 20-29 — Reserved (for Robustness Experiment)

Reference

[ZSu]

Type 30 — Traceroute (Deprecated)

Reference

[RFC1393][RFC6918]

Type 31 — Datagram Conversion Error (Deprecated)

Reference

[RFC1475][RFC6918]

Codes	Description	Reference
No registrations at this time.

Type 32 — Mobile Host Redirect (Deprecated)

Reference

[David_Johnson][RFC6918]

Type 33 — IPv6 Where-Are-You (Deprecated)

Reference

[Simpson][RFC6918]

Type 34 — IPv6 I-Am-Here (Deprecated)

Reference

[Simpson][RFC6918]

Codes	Description	Reference
No registrations at this time.

Type 35 — Mobile Registration Request (Deprecated)

Reference

[Simpson][RFC6918]

Type 36 — Mobile Registration Reply (Deprecated)

Reference

[Simpson][RFC6918]

Type 37 — Domain Name Request (Deprecated)

Reference

[RFC1788][RFC6918]

Codes	Description	Reference
No registrations at this time.

Type 38 — Domain Name Reply (Deprecated)

Reference

[RFC1788][RFC6918]

Type 39 — SKIP (Deprecated)

Reference

[Markson][RFC6918]

Type 40 — Photuris

Registration Procedure(s)

IESG Approval or Standards Action

Reference

[RFC2521][RFC2780]

Available Formats

CSV

Type 41 — ICMP messages utilized by experimental mobility protocols such as Seamoby

Registration Procedure(s)

Specification Required or IESG Approval

Expert(s)

Unassigned

Reference

[RFC4065]

Codes	Description	Reference
No registrations at this time.

Type 42 — Extended Echo Request

Registration Procedure(s)

First Come First Served

Reference

[RFC8335]

Available Formats

CSV

Type 43 — Extended Echo Reply

Registration Procedure(s)

First Come First Served

Reference

[RFC8335]

Available Formats

CSV

Types 44-252 — Unassigned

Codes	Description	Reference
No registrations at this time.

Type 253 — RFC3692-style Experiment 1 [1]

Registration Procedure(s)

Standards Action or IESG Approval

Reference

[RFC4727]

Type 254 — RFC3692-style Experiment 2 [1]

Registration Procedure(s)

Standards Action or IESG Approval

Reference

[RFC4727]

Sub-types — Class 1 — MPLS Label Stack Class

Registration Procedure(s)

First Come First Served

Reference

[RFC4950]

Available Formats

CSV

Sub-types — Class 2 — Interface Information Object

Reference

[RFC5837]

Available Formats

CSV

Sub-types — Class 2 — Interface Information Object — Interface Roles

Available Formats

CSV

Sub-types — Class 3 — Interface Identification Object

Registration Procedure(s)

First Come First Served

Reference

[RFC8335]

Available Formats

CSV

Sub-types — Class 4 — Extended Information

Registration Procedure(s)

Standards Action

Reference

[RFC8883]

Available Formats

CSV

ICMP — Destination Unreachable Message Analysis

The ‘ICMP Destination unreachable‘ message is quite interesting, because it doesn’t actually contain one message, but infact six! This means that the ICMP Destination unreachable futher breaks down into 6 different messages.

This article will analyse all six destination unreachable messages and explain which occasions each message is used. The table below shows an brief summary of the available messages and their code value contain in the ICMP header:

To make sure you don’t get confused, keep one thing in mind: The ICMP Destination unreachable is a generic ICMP message, the different code values or messages which are part of it are there to clarify the type of «Destination unreachable» message was received. It goes something like this: ICMP Destination unreachable.

The ICMP — Destination net unreachable message is one which a user would usually get from the gateway when it doesn’t know how to get to a particular network.

The ICMP — Destination host unreachable message is one which a user would usually get from the remote gateway when the destination host is unreachable.

If, in the destination host, the IP module cannot deliver the packet because the indicated protocol module or process port is not active, the destination host may send an ICMP destination protocol / port unreachable message to the source host.

In another case, when a packet received must be fragmented to be forwarded by a gateway but the «Don’t Fragment» flag (DF) is on, the gateway must discard the packet and send an ICMP destination fragmentation needed and DF set unreachable message to the source host.

These ICMP messages are most useful when trying to troubleshoot a network. You can check to see if all routers and gateways are configured properly and have their routing tables updated and synchronised.

Let’s look at the packet structure of an ICMP destination unreachable packet:

Please read on as the following example will help you understand all the above.

The Analysis

When you open a DOS command prompt and type «ping 200.200.200.200», assuming that your workstation is NOT part of that network, then it would forward the ICMP Echo request to the gateway that’s configured in your TCP/IP properties. At that point, the gateway should be able to figure out where to forward the ICMP Echo request.

The gateway usually has a «default route» entry, this entry is used when the gateway doesn’t know where the network is. Now, if the gateway has no «default route» you would get an «ICMP Destination net unreachable» message when you try to get to a network which the gateway doesn’t know about. When you’re connected to the Internet via a modem, then your default gateway is the modem.

In order for me to demonstrate this, I set up my network in a way that should make it easy for you to see how everything works. I have provided a lot of pictures hoping to make it as easy as possible to understand.

I will analyse why and how you get an «ICMP — Destination net unreachable» message.

In the example above, I’ve setup my workstation to use the Linux server as a default gateway, which has an IP of 192.168.0.5. The Linux server also has a default gateway entry and this is IP: 192.168.0.1 (the Windows 2000 Server).

When my workstation attempts to ping (send an ICMP Echo request) to IP 200.200.200.200, it realises it’s on a different network, so it sends it to the Linux server, which in turn forwards it to its default gateway (the Win2k server) so it can then be forwarded to the Internet and eventually I should get a ping reply (ICMP Echo reply) if the host exists and has no firewall blocking ICMP echo requests.

Here is the packet which I captured and its analysis on the right:

When looking at the decoded packet you can see in the ICMP header section that the ICMP Type is equal to 8, so this confirms that it’s an ICMP Echo (ping). As mentioned earlier, we would expect to receive an ICMP echo reply.

Check out though what happens when the default gateway entry is removed from the Linux server:

Now what I did was to remove the default gateway entry from the Linux server. So when it gets a packet from my workstation, it wouldn’t know what to do with it. This is how you get the gateway to generate an «ICMP Destination net unreachable» message and send it back to the source host (my workstation).

Here is a screen shot from the command prompt:

As you can see, the Linux server has returned an «ICMP Destination net unreachable». This is one of the six possible ‘ICMP Destination Unreachable’ messages as listed at the beginning of this page. The Linux server doesn’t know what to do with the packet since it has no way of getting to that 200.200.200.0 network, so it sends the «ICMP Destination net unreachable» message to my workstation, notifiying it that it doesnt know how to get to that network.

Let’s now take a look what the packet sniffer caught :

The decoded packet on the right shows that the Linux server (192.168.0.5) sent back to my workstation (192. 168.0.100) an ICMP Destination unreachable message (look at the ICMP type field, right under the ICMP header) but if you also check out the ICMP Code (highlighted field), it’s equal to 0, which means «net unreachable». Scrolling right at the top of this page, the first table clearly shows that when the code field has a value of 0, this is indeed a «net unreachable» message.

It is also worth noticing the «Returned IP header» which exists within the ICMP header. This is the IP header of the packet my workstation sent to the Linux server when it attempted to ping 200.200.200.200, and following that is 64 bits (8 bytes) of the original data.

This completed our discussion on the ICMP ‘Destination Unreachable’ generated packets.

Next — ICMP — Source Quench Message

ICMP port opener for the server / Sudo Null IT News

. After a little thought (the idea is not new), I decided to write a simple, so to speak, ICMP knocker, that is, opening ports by ping. But ping is not simple, but with a certain message/packet size. Linux example:

ping -s 999 -c1 mysrv.com

Where -s is the size of the message to be sent, -s is the number. If the message size matches, then the specified ports are opened for the sender’s IP address for a while and a message is sent about opening ports in Telegram. So to implement this craft you will need: ufw, curl, tcpdump:

apt install ufw curl tcpdump

and the script itself:

nano /opt/port-knocker.sh

 #!/bin/bash
PING_SIZE=999
PORTS='tcp/22 tcp/443'
TIMEOUT=3600
TOKEN="121212XXXX:XXXXZZZZAAAAEEEERRRRQQQQGGGGTTTTHHHH"
CHATID="55555XXXX"
PACKAGE_SIZE=$(( $PING_SIZE + 28 ))
function allow_access {
    RESULT=`ufw allow proto $PROTO from $SRC to $DST port $PORT`
    echo "`date` _ PORT-knocker _ $SRC -> $DST:$PORT : $RESULT"
    MESS="`uname -n` %0A`date` %0Aufw allow proto tcp from $SRC to $DST PORT $PORT %0A$RESULT"
    curl -s "https://api. .*IP ||' | tr ':' ' ' | awk '{print $1" "$3 }'`
            SRC=`echo $IP | awk {'print $1'}`
            DST=`echo $IP | awk {'print $2'}`
            if [ -n "$SRC" ] && [ -n "$DST" ]
            then
                for PPORT in ${PORTS}
                do
                    PROTO=`echo $PPORT | sed 's|/| |g' | awk '{print $1}'`
                    PORT=`echo $PPORT | sed 's|/| |g' | awk '{print $2}'`
                    if ufw show added | grep "$DST" | grep "$SRC" | grep "$PORT"
                    then
                        deny_access
                    else
                        allow_access
                        deny_access
                    fi
                done
            fi
        else
            echo "`date` - Timeout, reload sniffer"
        fi
done 

Where,

PING_SIZE — message size
PORTS=’tcp/22 tcp/443′ — protocol and port
TIMEOUT=3600 — port opening timeout in seconds

TOKEN — BotFather will tell the telegram on request «/mybots» -> «API Token»
CHATID — IDBot’s telegram will prompt «/getid»

Make the script executable:

chmod +x /opt/port-knocker. sh

To make the script work as a service:

nano / nano / etc/systemd/system/pk.service

 [Unit]
Description=Start port-knocker
[Service]
StandardOutput=syslog
StandardError=syslog
WorkingDirectory=/opt/
Type=simple
ExecStart=/bin/bash /opt/port-knocker.sh
KillMode=process
Restart=on-failure
RestartSec=5s
[Install]
WANTEDBY = MULTI-USER.TARGET