Differences

This shows you the differences between two versions of the page.

Link to this comparison view

ep:labs:04:contents:tasks:ex2 [2020/11/01 12:22]
gheorghe.petre2608 [02. [20p] Traffic monitoring - Tcpdump]
ep:labs:04:contents:tasks:ex2 [2023/10/29 20:47] (current)
radu.mantu
Line 1: Line 1:
-==== 02. [20pTraffic monitoring - Tcpdump ​====+==== 02. [30pNetwork Exploration ​====
  
-<​note>​In most of the situations presented in all the laboratories we have already gone throughwe have seen numerous ​tools whose output helps us to __understand the behavior__ of the system we are analyzingNext, we choose ​the most used Linux utility for **analyzing transferred packets** in a __conversation between two or more systems__+=== [10p] Task A - ARP vs ICMP === 
-</​note>​ + 
-<note important+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 requestsbut this can be fiddled with using tools such as **arptables**You can show the currently known neighbors using **iproute2**. 
-Tcpdump captures and prints out a **description** of the contents of **packets** on a **network interface**. + 
-Tcpdump utilises the //​**libpcap**//​ library for packet capturing. The packet details can either be __displayed on the screen__ or __saved to files__.</note>+<code bash
 +$ ip -c neigh show 
 +</code>
  
 <note tip> <note tip>
-Supported options by tcpdump command:+//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.
  
-| **Options** | **Description** ^^ +<code bash> 
-| --version | print the tcpdump and libpcap version strings and exit || +# alias for iproute2 color output 
-| -h, --help | print the tcpdump and libpcap version strings, print a usage message, and exit || +alias ip='​ip ​-c' 
-| -B buffer_size| set the operating system capture buffer size to //​buffer_size//,​ in units of KiB || +</code>
--c count| exit after receiving //count// packets || +
-| -D | print the list of the network interfaces on which tcpdump can capture packets || +
-| -i interface |report the results of compiling a filter expression on //​interface//​ || +
-| -n | don't convert addresses (host addresses, port numbers) to names || +
-| -s snaplen | truncate ​//snaplen// bytes of data from each packet rather than the default || +
-| -t | don't print a timestamp on each dump line || +
-| -v | produce more verbose output || +
-| -w file | write the raw packets to //file// rather than parsing and printing them out|| +
-| -r file | read packets from file || +
-| -A | print each packet in ASCII ||+
 </​note>​ </​note>​
  
-<note warning>​ +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.
-  ​Check if **tcpdump** is installed ​and which **version** is installed.+
  
-<​solution -hidden>​ +== The Task(s) ==
-<​code>​tcpdump -h</​code>​ +
-</​solution>​+
  
-  ​Check out the **network ​interfaces** available ​on your system+Use **arp-scan** to scan your //​local// ​network ​while monitoring ARP traffic with **wireshark** to get a sense of what's going on. 
-<​solution -hidden>​ +After that, use the following script to identify hosts discoverable via ARP but not ICMP.
-<​code>​tcpdump -D</​code>​ +
-</​solution>​+
  
-  * After starting a capture on all interfaces, you can always stop it using //**control + c**//.  +<​spoiler>​ 
-</​note>​+//Hint: click on the file name to download the snippet below.//
  
 +<file bash localnet-ping.sh>​
 +#!/bin/bash
  
-=== [10pTask A - Understanding traffic===+# localnet-ping.sh - performs differential ARP / ICMP scan 
 +#   $1 : [requiredinterface name  ​
  
-a) Start a capture that __stops by itself__ after getting __10 packets__ on __all interfaces__. +if [ "​$#"​ -ne 1 ]; then 
-<​solution ​-hidden>​ +    echo "​Usage: ​./localnet-ping.sh ​<interface>" 
-<code+    exit 1 
-sudo tcpdump -i any -c 10 +fi
-</​code>​ +
-</​solution>​+
  
-b) Have a look at the __output__. You can notice that **host names** are used instead ​of **IP addresses**, ​and commonly known port are replaced with application names. Use a command to display the **IP addresses** and port numbers instead of these names. +# generate list of IPs and hostnames in local network for given interface 
-<​solution ​-hidden> +localnet_hosts=$(sudo arp-scan                                      \ 
-<​code>​ +                    ​--interface=$1 ​          `# scanned network` ​   \ 
-sudo tcpdump ​-i any -c 10 -n +                    --localnet ​              `# only local network` \ 
-</​code>​ +                | head -n -3                 `# hide footer lines` ​ \ 
-</​solution>​ +                | tail -n +3                 `# hide header lines` ​ \ 
-<note tip>​Tcpdump __triggers itself DNS traffic__ as it captures, if it is ran without the //-n// option. The utility will trigger reverse or PTR DNS lookups to find __hostnames for IP addresses__ as it captures them. So, from now on, use //-n//.+                | awk '​{$2="";​ print $0}' ​   `# hide MAC address` ​  \ 
 +                )
  
-  * What is the capture size?  +# process generated list, one item at a time 
-<​solution ​-hidden> +while read -r it; do 
-<​code>​ +    # separate IP from hostname 
-It's shown in the output - mine is 262144 ​256KB +    ​current_ip=$(awk '​{print $1}' ​<<< $it) 
-</code> +    ​current_host=$(awk ​'{$1="";​ print $0}' <<<​ $it)
-</​solution>​ +
-What does this mean? It means that tcpdump will keep all those bytes for analysis. We don't need all this information for now, so change the __capture size to 96 bytes__. The __Ethernet, IP and TCP__ headers are the in the __first 64 bytes__ of the packets, so capturing 96 bytes per packet is more than enough to capture these headers.+
  
-</​note>​ +    printf '​\033[1;​33m%15s ​  %-35s \033[0;​33m== ​\033[0m'​ \ 
-c) Do the capture again with the output limitation. +        ​$current_ip "​$current_host"​
-<​solution ​-hidden+
-<​code>​ +
-sudo tcpdump -i any -c 10 -n -s96 +
-</​code>​ +
-</​solution>​+
  
-<​note>​The **TCP flags** are **SYN**, **ACK**, **RESET**, **FIN**, **URGENT** and **PUSH**. All flags are represented by the first letter, with the exception of ACK which is represented by a **dot**.</​note> ​ +    # ping current host 
-d) Start a new capture ​only on the __interface that connects you to the internet__, without printing the timestamp on each dump line. Open a separate terminal and try to __connect through ssh somewhere__. Spot the **3-way handshake** in the capture.+    ping -c 1           ​`# ​only one ping` \ 
 +         -W 1           `# 1s timeout` ​   \ 
 +         ​$current_ip ​   `# target host`   \ 
 +         ​1>/​dev/​null 2>&1
  
-<​solution ​-hidden> +    # evaluate ping success 
-<​code>​ +    if [ $? -eq 0 ]; then 
-sudo tcpdump -i enp0s3 --t +        ​printf '​\033[1;​32mok\n\033[0m'​ 
- +    ​else 
-ssh -T git@github.com +        printf '​\033[1;​31mfail\n\033[0m'​ 
--T = Disable pseudo-terminal allocation +    fi 
-</code+done <<<​ "​$localnet_hosts"​ 
-</solution>+</file>  
 +</spoiler>
  
-e) Repeat what you did for the previous task, but add //-S// to your tcpdump command. Figure out what has changed, and why. 
 <​solution -hidden> <​solution -hidden>
-<​code>​ +<​code ​bash
--S turns off the relative sequence numbers+$ sudo arp-scan --interface eth0 --localnet
 </​code>​ </​code>​
 </​solution>​ </​solution>​
  
-<​note>​ +=== [20p] Task B nmap vs traceroute ===
-Check out the **window size** in the previous capture. Since __window scaling is enabled__, that is __not the //actual// window size__. Notice the window scaling factor (//​**wscale**//​) in the 3-way handshake output. The scaling factor translates in __multiplying the receive window__ by __2 to the power of wscale__. So the //real// window size is the window value shown in the capture, multiplied by 2 to the power of wscale.+
  
-The **length field** stands for packet length, ​and represents the __number of bytes in the layer 4 headers__and it matches ​with the sequence numbers ​**(packet_length = larger_seq_no - smaller_seq_no)**.</​note>​+**nmap** is a network exploration tool and a port scanner. Todaywe 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).
  
-=== [10p] Task B - DNS capture==+== The Task(s) ==
-If we are the victims of a possible cyber attack (DNS hijacking), the DNS request packages are investigated.+
  
-We will simulate ​the monitoring of all DNS packages.+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?
  
-a) Capture an output for a DNS request. +<​code ​bash
-<​solution -hidden>​ +sudo nmap                            \ 
-<​code>​ +    ​-sn     `# disable ​port scan`      \ 
-sudo tcpdump ​-i enp0s3 ​port 53 -n +    ​-Pn     `# disable host discovery` \ 
- +    ​-tr ​    `# perform traceroute` ​    \ 
-different terminal: wget www.google.com +    8.8.8.8 
- +$ traceroute 8.8.8.8
-It's quite a bit to explain here, but at least they can notice the redirection to google.ro. +
- +
-  * A - ipv4 +
-  * AAAA -ip v6 +
- +
-  * for google.com: +
-      * ipv4 -  I get 6 IP addresses +
-      * ipv6 - 1 IP address +
-  * pt google.ro:​ +
-      * ipv4 - 1 IP +
-      * ipv6 - 1 IP+
 </​code>​ </​code>​
-</​solution>​ 
  
-b) Save a capture to a file. Use the appropriate options so that: 
-      * it displays the number of packets captured 
-      * the capture stops after 30 packets 
 <​solution -hidden> <​solution -hidden>
-<​code>​ +**traceroute**:​ 
-sudo tcpdump -i any -w capture.pcap -v -c20 +  * increments TTL starting from 1 
-</​code>​+  * 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>​ </​solution>​
  
-cRead the contents of the capture file.+<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 tracerouteWhat changes does this bring? 
 <​solution -hidden> <​solution -hidden>
-<​code>​ +**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**.
-sudo tcpdump -n -r capture.pcap | less +
-</​code>​+
 </​solution>​ </​solution>​
  
-:!: :!: NON-DEMO TASK+== Optional Task (... no, really) ==
  
-Using filters helps you view just the types of traffic that you are interested ​in and ignore ​the rest. Create short captures of up to 5 packets for the following cases: +When doing the TCP scan with **nmap**, ​you may have noticed a weird field in the TCP header: **Options**
-      ​Capture traffic just from the IP 8.8.8.8 +Generate some TCP traffic with **curl** and look at the SYN packet ​in **wireshark**What options do you see there?
-      ​Capture traffic having the source IP 8.8.8.8 +
-      Capture traffic to or from your PC on port 80 +
-      ​Capture traffic to or from your PC on port 80 or port 443 +
- +
-Include ​the commands or a screenshot of the terminal ​in the submission. +
- +
- +
-<​solution -hidden>​ +
-<​code>​ +
-1. sudo tcpdump -i enp0s3 -n host 8.8.8.8 -c5 +
-2. sudo tcpdump -i enp0s3 -n src host 8.8.8.8 -c5 +
-3. sudo tcpdump -i enp0s3 -n host <​IP_PC>​ and port 80 -c5 +
-   wget google.ro +
-4. sudo tcpdump -i enp0s3 -n src "host 8.8.8.8 and (port 80 or port 443)"​ +
-   wget google.ro +
-   wget https://​www.google.ro +
-       +
-</​code>​ +
-</​solution>​+
  
 +[[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.
ep/labs/04/contents/tasks/ex2.1604226147.txt.gz · Last modified: 2020/11/01 12:22 by gheorghe.petre2608
CC Attribution-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0