Differences
This shows you the differences between two versions of the page.
|
ep:labs:04:contents:tasks:ex2 [2021/10/03 21:35] radu.mantu [02. [??p] Network Exploration] |
ep:labs:04:contents:tasks:ex2 [2023/10/29 20:47] (current) radu.mantu |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ==== 02. [??p] Network Exploration ==== | + | ==== 02. [30p] Network Exploration ==== |
| - | === [??p] Task A - ARP vs ICMP === | + | === [10p] Task A - ARP vs ICMP === |
| - | The [[https://datatracker.ietf.org/doc/html/rfc826|Address Resolution Protocol (ARP)]] resolves layer 2 addresses (MAC) from layer 3 addresses (e.g.: IP). Normally, all hosts are compelled to reply to ARP requests, but this can be fiddled with using tools such as [[https://linux.die.net/man/8/arptables|arptables]]. For now, try using **arp-scan** to scan your //local// network. Use **wireshark** to monitor the ARP traffic and get a sense of what's going on. | + | The [[https://datatracker.ietf.org/doc/html/rfc826|Address Resolution Protocol (ARP)]] resolves layer 2 addresses (MAC) from layer 3 addresses (e.g.: IP). Normally, all hosts are compelled to reply to ARP requests, but this can be fiddled with using tools such as **arptables**. You can show the currently known neighbors using **iproute2**. |
| - | <solution -hidden> | ||
| <code bash> | <code bash> | ||
| - | $ sudo arp-scan --interface eth0 --localnet | + | $ ip -c neigh show |
| </code> | </code> | ||
| - | </solution> | ||
| - | The [[https://datatracker.ietf.org/doc/html/rfc792|Internet Control Message Protocol (ICMP)]] is an ancillary protocol meant mainly to report errors between hosts. Sometimes it can also be used to perform measurements (**ping**) or to inform network participants of better routes ([[https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/nx-os-software/213841-understanding-icmp-redirect-messages.html|Redirect Messages]]). There are many ICMP functionalities, most of which are now deprecated. Note that some network equipment may not be capable of understanding new and officially recognized protocols, while other may not even recognize experimental ICMP codepoints (i.e.: [[https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml|type=253,254]]) and simply drop the packet. Because ICMP can be used to stage attacks in a network, some operating systems (e.g.: Windows >7) went so far as to disable Echo Replies by default. Use the following script to scan your local network and identify hosts discoverable via ARP but no ICMP. | + | <note tip> |
| + | //Pro tip #2//: yes, **ip** can also generate color output. Most people don't know this and still use **ifconfig**, even though it's already deprecated at this point. Add this as an alias to your //.bashrc// or //.zshrc// and source it. | ||
| + | |||
| + | <code bash> | ||
| + | # alias for iproute2 color output | ||
| + | alias ip='ip -c' | ||
| + | </code> | ||
| + | </note> | ||
| + | |||
| + | The [[https://datatracker.ietf.org/doc/html/rfc792|Internet Control Message Protocol (ICMP)]] is an ancillary protocol meant mainly to report errors between hosts. Sometimes it can also be used to perform measurements (**ping**) or to inform network participants of better routes ([[https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/nx-os-software/213841-understanding-icmp-redirect-messages.html|Redirect Messages]]). There are many ICMP functionalities, most of which are now deprecated. Note that some network equipment may not be capable of understanding new and officially recognized protocols, while other may not even recognize experimental ICMP codepoints (i.e.: [[https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml|type=253,254]]) and simply drop the packet. Because ICMP can be used to stage attacks in a network, some operating systems (e.g.: Windows ≥7) went so far as to disable Echo Replies by default. | ||
| + | |||
| + | == The Task(s) == | ||
| + | |||
| + | Use **arp-scan** to scan your //local// network while monitoring ARP traffic with **wireshark** to get a sense of what's going on. | ||
| + | After that, use the following script to identify hosts discoverable via ARP but not ICMP. | ||
| <spoiler> | <spoiler> | ||
| - | Hint: click on the file name to download the snippet below. | + | //Hint: click on the file name to download the snippet below.// |
| <file bash localnet-ping.sh> | <file bash localnet-ping.sh> | ||
| Line 42: | Line 54: | ||
| current_host=$(awk '{$1=""; print $0}' <<< $it) | current_host=$(awk '{$1=""; print $0}' <<< $it) | ||
| - | printf '\033[1;33m%15s %-30s \033[0;33m==> \033[0m' $current_ip "$current_host" | + | printf '\033[1;33m%15s %-35s \033[0;33m==> \033[0m' \ |
| + | $current_ip "$current_host" | ||
| # ping current host | # ping current host | ||
| Line 60: | Line 73: | ||
| </spoiler> | </spoiler> | ||
| - | === [??p] Task B - nmap === | + | <solution -hidden> |
| + | <code bash> | ||
| + | $ sudo arp-scan --interface eth0 --localnet | ||
| + | </code> | ||
| + | </solution> | ||
| + | |||
| + | === [20p] Task B - nmap vs traceroute === | ||
| + | |||
| + | **nmap** is a network exploration tool and a port scanner. Today, we will look only at a specific functionality that it shares with the **traceroute** utility. | ||
| + | |||
| + | Route discovery is simple in principle: IPv4 packets have a **Time to Live (TTL)** field that is decremented by 1 with each hop, thus ensuring a limited packet lifespan (imagine routing loops without TTL). Even if the TTL is 0, the layer 3 network equipment //must// process the received packet (the destination host can accept a packet with TTL=0). Routers //may// check the TTL field only if they are to forward the packet. If the TTL is already 0, the packet is dropped and a //ICMP Time-To-Live Exceeded// message is issued to the source IP. By sending packets with incrementally larger TTL values, it is possible to obtain the IP of each router on the path (at least in theory). | ||
| + | |||
| + | == The Task(s) == | ||
| + | |||
| + | With 8.8.8.8 as a target, use **wireshark** to view the traffic generated by both **nmap** and **traceroute**. What differences can you find in their default mode of operation? | ||
| + | |||
| + | <code bash> | ||
| + | $ sudo nmap \ | ||
| + | -sn `# disable port scan` \ | ||
| + | -Pn `# disable host discovery` \ | ||
| + | -tr `# perform traceroute` \ | ||
| + | 8.8.8.8 | ||
| + | $ traceroute 8.8.8.8 | ||
| + | </code> | ||
| + | |||
| + | <solution -hidden> | ||
| + | **traceroute**: | ||
| + | * increments TTL starting from 1 | ||
| + | * uses UDP by default (can also use ICMP and TCP if specified) | ||
| + | **nmap**: | ||
| + | * starts off with a high TTL value and decrements it | ||
| + | * uses ICMP because we didn't perform a port scan first | ||
| + | </solution> | ||
| + | |||
| + | <note tip> | ||
| + | Troubleshooting: | ||
| + | * **permission denied** : make sure that **nmap** is not installed as a **snap**; you have two choices: | ||
| + | * reinstall **nmap** with apt : ''sudo snap remove nmap && sudo apt install nmap'' | ||
| + | * grant **nmap** permissions : ''snap connect nmap:network-control'' | ||
| + | </note> | ||
| + | |||
| + | If we do allow for a port scan by removing ''-sn'' (default is a TCP-based scan; use ''-sU'' for a UDP scan), this will take place //before// the actual traceroute. What changes does this bring? | ||
| + | |||
| + | <solution -hidden> | ||
| + | **nmap** has collected information about open ports, so it uses the same protocol (i.e.: TCP, UDP respectively) since it knows that the packets will reach the destination. If OS detection is enabled, it should be able to guess the distance (in number of hops) and start off with a proper TTL value. Otherwise, it starts from 10, decreasing to 1 and then increasing from 11 to 30 until the destination host is actually reached. This is done for the sake of its internal caching algorithm that presumably requires 5 less packets per experiment than **traceroute**. | ||
| + | </solution> | ||
| + | |||
| + | == Optional Task (... no, really) == | ||
| + | |||
| + | When doing the TCP scan with **nmap**, you may have noticed a weird field in the TCP header: **Options**. | ||
| + | Generate some TCP traffic with **curl** and look at the SYN packet in **wireshark**. What options do you see there? | ||
| - | TODO | + | [[https://www.firewall.cx/networking-topics/protocols/tcp/138-tcp-options.html|Here]] is a quick break down of the more common TCP options and how they are used to overcome protocol limitations and improve throughput. Take a quick look if you want, then move on. We'll dive deeper into protocol options in the next task. |
