If you can see this check that

Main Page

Active Recon - Network Scanning and Enumeration


Authors: Rich Macfarlane, Gordon Russell

This practical covers an introduction to some elementary linux networking commands for pentesting, along with an introduction to network discovery and active scanning for targets. Remember if you try these in your own machine make sure you have permission, as running these on or over system you have no permissions for is likely illegal.

Your virtual machine sits inside a virtual network, and this network connect you to other virtual machines. One of those machines is your network gateway. The gateway itself is a router, and this connects together all the virtual networks from yourself and other cloud users. Above this another router sits, connecting together cloud users running on different servers, and this in turn links to the main system gateway, connecting the virtual world to the real network via a NAT. This gives many networks to explore, but in reality layered firewalls within the virtual network prevent most explorations.

To reset all the check buttons from a previous attempt click here

Question 1: Network IP

What is the primary IP address of your virtual machine network connection? If you have multiple connections for some reason this is the ethernet device related to eth0. You should use the "ip" command for this (not ifconfig as this is very old and weak). You can use "ip help" to discover the options. The "addr" option is what we want here, and again you can discover more with "ip addr help". If you want to jump to the answer, try "ip addr show".

Machine ip :

Tests - not attempted
Network Address UNTESTED

Question 2: Mac address

This time use "ip link help" and "ip link show" and find out the mac address of eth0. Enter it in the format 00:00:00:00:00:00 using lowercase.

Machine mac:

Tests - not attempted
Layer 2 Address UNTESTED

Question 3: Network Gateway

This time use "ip route help" and "ip route show" and find out the IP address of your machine's gateway. The gateway is where your packets would be sent if it is destined for an IP address which is not in the local subnet.

Machine gateway:

Tests - not attempted

Question 4: Gateway Mac

Look into /proc/net/arp. What is the mac address of the gateway? Enter it in the format 00:00:00:00:00:00 using lowercase.

Gateway mac:

Tests - not attempted
Gateway mac UNTESTED

Question 5: Monitoring Scanning Traffic - Wireshark and tcpdump

Run Wireshark in Kali. It can be found in the graphical menu.
9. Sniffing & Spoofing -> Wireshark
Start a live capture, and in a kali terminal "ping" the machine at with 5 pings (you can use the "-c" option of ping for this, or press CTRL C to stop the ping). This ping should send a number of ping request packets, and if the network is operating correctly and the atarget is up, you should receive a corresponding number of ping response packets.

What does wireshark report:
is the length of a ping packet:
is the ICMP type number of a ping request packet:

Tests - not attempted
Length in bytes UNTESTED
Type number for request UNTESTED

Now, open another terminal window, and use tcpdump to check its options using -h. Which tcpdump flag:
is used to display the list of network interfaces: -
is used to display numerical port numbers and not perform DNS host resolution: -

Tests - not attempted
Display Interfaces flag UNTESTED
Display Numeric Output flag UNTESTED

Start a tcpdump capture on eth0, using numerical output for hosts and ports and displaying the contents of sniffed packets in Hex and ASCII. In your other kali terminal use ping again to send just a few packets to It may not be obvious where the ICMP type is in the tcp dump output. Try clicking on it in Wireshark, and comparing the data pane (pane 3 in Wireshark) with the tcpdump Hex and ASCII output!

What does the tcpdump output show:
What is the protocol of the ping packets:
What are the last 8 charcters in the content of each ICMP packet's data:

Tests - not attempted
tcpdump default protocol UNTESTED
tcpdump default protocol UNTESTED

Question 6: tcpdump and host sweeping with ping

In this set of questions you will learn how to run a command multiple times by looping over a numerical range. This is particularly useful when you are using a network command which normally only targets a single machine but you want to target a range of IP numbers.

Firstly, ping using "-c 1" (so only send a single packet exchange). What is the TTL of the response to this ping packet?

Tests - not attempted

It is possible to use bash variables in commands. One way is to set a variable using a for loop construct. Look at the following example:

for i in {1..10}; do mkdir /home/kali2/newdir$i; done;
The "for" part till the first ";" sets up a loop which sets a variable called "i" to the values 1,2,3,4,5,6,7,8,9,10, one after another. For each value the "do" command is executed; "done" indicates the end of the loop. The $i is replaced by the current value of i. In this example, "newdir$i" becomes "newdir1","newdir2", etc, up to "newdir10".

Consider another example:

for i in {1..10}; do echo 10.200.0.$i; done;
How many IP numbers are output? Count:

Tests - not attempted
Count Correct UNTESTED

In this question you will use a bash for loop and ping to investigate autoamtion of network scanning. Wireshark is excellent for packet analysis, but sometimes it can be resource hungry, so this time use tcpdump to capture a ping sweep. The tcpdump command allows us to capture all or some of the network traffic on a particular network device from the cmd line.

Make sure you have two terminal windows open. In one window, which will deal with the monitoring of the network, we will use tcpdump to sniff for ICMP traffic and redirect the output to a file:

tcpdump -vn -ieth0 icmp > /root/dump1
This will start the capture. Press CTRL C in this window when you want the capture to end. These flags indicate that it is a verbose capture (-v), and that IP numbers will be kept numeric and not generate DNS lookups (-n), and the capture is on interface eth0 (-i eth0). The captured information is saved to the dump1 file.

In the other terminal window, which in turn will generate the packets during the experiment, do the following REPLACING ?????? with suitable parameters to make the loop go from 1 to 30, and for the ping to send packets to up to, depending on i.

for i in {?????}; do ping -W1 -c1 ?????; done;
This will run a ping sweep of ips in the range to It is not fast... may take around a minute. The -W sets the timeout to 1 second each time, just to make the question go a bit faster. Note though in the real world a 1 second timeout might mean you miss things...

Once complete stop the tcpdump capture.

Tests - not attempted
Capture seems to start UNTESTED
Capture seems to end UNTESTED

Use cat or less to examine the packet capture, and locate the echo reply packets. The ICMP packet is contained within an IP packet, and the related IP packet information is on the line just before the ICMP information. From that information, discover the IP packet id for the last received echo reply.

IP Packet Id number:

Tests - not attempted
dump1 seems ok test1 UNTESTED
dump1 seems ok test2 UNTESTED
Last reply id UNTESTED

Use grep and wc. How many echo requests were sent?

Number of echo requests:

Tests - not attempted
dump1 seems ok test1 UNTESTED
dump1 seems ok test2 UNTESTED
Echo requests UNTESTED

Use grep, looking for packets with "echo reply", and use the '-B1' to also show the line immediately before the line which matches (which contains the packet header information of the reply). Sometimes the ttl is 64, but sometimes the ttl is something else.

What is the other ttl:

Tests - not attempted
dump1 seems ok test1 UNTESTED
dump1 seems ok test2 UNTESTED
Other ttl UNTESTED

Sometimes it's useful to be able to filter out traffic we aren't interested in. Use tcpdump again, but this time capture only traffic which is not LinuxZoo remote administation traffic. So, ignore ssh and telnet traffic using a filter.

tcpdump -ieth0 -vn not port ssh and not port telnet
Direct that file to save the capture to /root/dump2, and terminate the capture after capturing some host dicovery packets.

We can use the arping tool to check if a host ona local network is up. Try: "arping -ieth0 -c2", replacing the IP "" with the IP of your virtual machine gateway address.

Tests - not attempted
dump2 seems ok test1 UNTESTED
dump2 seems ok test2 UNTESTED

What is the protocol arping has used to sent the host discovery packets?
arping protocol:

What is the packet length of the reply to the arping from your gateway?
packet length:

Tests - not attempted
dump2 seems ok test1 UNTESTED
dump2 seems ok test2 UNTESTED
protocol UNTESTED
dump2 byte len of is-at UNTESTED

Question 7: Host sweeping with arping

Use the "ip route show" command and identify the start and end address (not including the network number and broadcast address) of your virtual machine's network. Use the network number and netmask to make this calculation from the "ip route show" command output.

Start IP:
End IP:

Tests - not attempted
start ip is right UNTESTED
end ip is right UNTESTED

for i in {0..150}; do
	arping -c 2 192.168.100.$i | grep 'bytes from' | awk '{print " possible target up at: " $4 " " $5}' | sort -u
Consider the above bash host discovery script. Use an editor and write this into a script /root/arpbash. After writing the script make sure the file is executable using "chmod +x /root/arpbash". This script should do an arping scan of the local network, if configured correctly!

In the "for" loop, which currently pings 0 to 150 IPs, change this to be the last octet of the start and end ip you identified in the previous question so we can find all the hosts on our network. Where the script has "192.168.100." change this to the first three octets of your network ip form the previous question.

Tests - not attempted
subnet ok UNTESTED

Run the command using ./arpbash, but save the output to dump3 in /root.

Look at the file and identify the first IP number it has found.

Tests - not attempted
File looks sensible UNTESTED
ip right UNTESTED

Question 8: Network tracing with traceroute

In order for your virtual machine to reach the internet, it's packets travels through a number of virtual networks. The final network gateway node is

Using traceroute, investigate the route to reach Try traceroute using its default settings with traceroute -n, while in another terminal window monitoring the traffic using tcpdump, including the ASCII packet content.

What is the protocol traceroute has used to sent the network tracing packets?
traceroute protocol:

In the contents of the packets what are the first 4 characters after the @ symbol?
traceroute packet content:

Now check the help (--help)/man page for traceroute, and find the flag to use ICMP packets, rather than the default. Run the trace again using ICMP and review the output.

Num of hops:
Use dig to perform a reverse DNS lookup to find the Hostname of last hop:

In the contents of the packets what are the 4 characters before the [ symbol in the ICMP packet payload?
traceroute packet content:

Tests - not attempted
protocol UNTESTED
content UNTESTED
Count the hops UNTESTED
Last hop hostname UNTESTED

Question 9: Network Scanning with nmap - Host Discovery

Run the nmap network scanner tool, to perform only host discovery on a single host, with no DNS or protocol resoloution. In a 2nd terminal window run tcpdump to monitor the network traffic generated.

nmap -sn -n

How many different types of packets are sent by nmap for host discovery:

To compare to host discovery on a local network, run nmap, to perform only host discovery on a single host again, but this time against the host which was found by your arping scan, which should be in your dump3 output file. In your 2nd terminal window again have tcpdump running to monitor the network traffic generated.

What is the type of packets nmap has used for host discovery on the directly connected network - which protocol?
nmap packet type:

Now lets run nmap, to perform host discovery on a section of a remote network, and save the output as a grepable data file.

nmap -PE -oG /root/out1 -sn

This saves the search information as a file called /root/out1 in a "grepable" format. Look at the file contents once you have created it.

Tests - not attempted
Host discovery packets: UNTESTED
protocol UNTESTED
/root/out1 looks sensible check1 UNTESTED
/root/out1 looks sensible check2 UNTESTED

Process this output file out1, and generate a file "out2" with only the IP addresses of machines which are up.

grep Up /root/out1 | cut -d" " -f 2 > /root/out2

Tests - not attempted
/root/out1 looks sensible check1 UNTESTED
/root/out1 looks sensible check2 UNTESTED
/root/out2 seems right UNTESTED

Question 10: Target Port scanning - nmap and netcat

While port scanning, always have another terminal window open, and tcpdump running to monitor the scanning packets being created by the tools. Typically tcpdump with -vn is sufficient and add -X if you want to see the content of the packets.

Use nmap to analyse the ports open on As large scale scanning can take a long time to run, restrict your port scan to TCP ports between port numbers 50 to 100 inclusive. List the open port numbers you find with commas between them in the box below (e.g. if ports 50 and 60 are open, the answer would be "50,60"). The numbers in your list must be sorted (smallest number first), and the box is space sensitive so dont have extra spaces!

IMPORTANT. Linuxzoo security may shut you down if you produce too many packets too quickly! Use the following options for nmap to control the scanning traffic generated, or you may be shunned or exited from LinuxZoo. Even with these controlled scanning options, scans can take quite a few seconds to complete.

nmap -n -p50-80 --max-retries 3

Open ports:

Stop the tcpdump monitoring. Review the first 4 packets sent by nmap. Review the help, and identify the flag to stop these from being sent: -

Tests - not attempted
Identify of open ports on UNTESTED
Identify nmap Flag UNTESTED

Use a tcpdump filter to only capture traffic to or from port 80.

tcpdump -vni eth0 port 80

Capture the port 80 traffic generated, while using nmap to carry out a port scan of the target at using a fully connect scan, with -sT. Store this information in /root/nmapfull.

Now you have identified the nmap 'no host discovery' flag -Pn, always use this if the live host is known, to save extra packets being generated.

Tests - not attempted
nmapfull looks ok UNTESTED

nmap full connect port scanning

Using 'S' for SYN, '.' for ACK, and 'R' for RST (which is how tcpdump shows the "Flags" in the tcpdump), state the handshake involved in the 'full connect' scan captured in the previous question. Seperate each packet with a comma. For instance, if the handshake on port 80 was SYN, then ACK, then SYN+ACK, then the answer would be "S,.,S.".

Handshake in nmapfull:

Tests - not attempted
nmapfull looks ok UNTESTED
nmapfull analysis correct UNTESTED

Use tcpdump to only capture traffic involving port 80.

tcpdump -vni eth0 port 80

Capture the port 80 traffic generated, while using nmap to carry out a port scan of using a SYN/half open scan. Store this information in /root/nmapsyn. Remember to continue to use the nmap 'no host discovery' flag!

Tests - not attempted
nmapsyn looks ok UNTESTED

nmap half open port scanning

Using 'S' for SYN, '.' for ACK, and 'R' for RST (which is how tcpdump shows the "Flags" in the tcpdump), state the handshake involved in the full scan captured in the previous question. Seperate each packet with a comma. For instance, if the handshake on port 80 was SYN, then ACK, then SYN+ACK, then the answer would be "S,.,S.".

Handshake in nmapsyn:

Tests - not attempted
nmapsyn looks ok UNTESTED
nmapsyn analysis correct UNTESTED

Continue using tcpdump to capture all traffic using flags -nnv

Carry out a port scan of for the top 30 ports defined in nmap's services file, using a SYN/half open scan. Remember to continue to use the nmap 'no host discovery' flag, and the numeric/no DNS lookup flags!

Review nmap's services file. What is the frequency value of the services found to be running on the target, which is least often seen running on the Internet (to 3 dec places):

From the nmap services file, the protocol is more frequently run on a different transport protocol. Run an appropriate nmap scan on this port to check if it running on the target. Then run a port scan for the top 5 ports for that transport protocol. What is the service found running with the highest frequency in the nmap-services file:

Tests - not attempted
Identify nmap frquency UNTESTED
Identify nmap protcol UNTESTED

nmap Port Scanning with Version Fingerprinting

Use nmap, limiting yourself to port 80, and perform application version identification of (-sV). Enter the version NUMBER returned by nmap, ignoring all other information. So if it returns "Apache httpd 3.0.0 ((Redhat) OpenSSL))" the answer is "3.0.0".

Port 80 version:

Tests - not attempted
Version correct UNTESTED

Repeat the above scan, but introduce "--version-trace". What is the GetRequest line number shown in the trace for the Service Scan Match which produced the application version information from nmap?

Line of nmap-service-probe:

Tests - not attempted

Use "locate" to locate the nmap-service-probe definition file, and then do

head -LINE FILE | tail -1
where LINE is the line number from the previous question and FILE is the located filename. So if the file was /var/1 and the line number was 1000, you would do "head -1000 /var/1 | tail -1".

First 2 words of the line:

Tests - not attempted
Line words UNTESTED

Use nmap, limiting yourself to port 80, and perform OS fingerprinting of Save the output of running this command to /root/finger. Have a look at the file too, and see what nmap thinks is.

Tests - not attempted
OS Fingerprint test1 UNTESTED
OS Fingerprint test2 UNTESTED

Switch to using netcat, and perform a similar portscan. Review the help for the flags used inour scan below. Note "-z" which means no data is sent. We don't want to comminucate with the service yet, and only check the port is open. When we move onto Service Fingerprinting/Version Scanning we will want to send data.

nc -vv -n -z -w2 50-80
Note that there are many "version" of nc, and in some installs you may get an error message with the portscan. In this case switch to "nc.traditional" rather than "nc".

What message do you get for port 50?

Tests - not attempted
netcat output for port 50 UNTESTED

Use wireshark or tcpdump, and monitor the netcan scan of the previous question. What sort of scan does this command do by default?

What type of scan?

Tests - not attempted
netcat output for port 50 UNTESTED

Centos 7 intro: Paths | BasicShell | Search
Linux tutorials: intro1 intro2 wildcard permission pipe vi essential admin net SELinux1 SELinux2 fwall DNS diag Apache1 Apache2 log Mail
Caine 10.0: Essentials | Basic | Search | Acquisition | SysIntro | grep | MBR | GPT | FAT | NTFS | FRMeta | FRTools | Browser | Mock Exam |
CPD: Cygwin | Paths | Files and head/tail | Find and regex | Sort | Log Analysis
Kali: 1a | 1b | 1c | 2 | 3 | 4a | 4b | 5 | 6 | 7a | 8a | 8b | 9 | 10 |
Kali 2020-4: 1a | 1b | 1c | 2 | 3 | 4a | 4b | 5 | 6 | 7 | 8a |
Useful: Quiz | Forums | Privacy Policy | Terms and Conditions
Site Links:XMLZoo ActiveSQL ProgZoo SQLZoo

Linuxzoo created by Gordon Russell.
@ Copyright 2004-2021 Edinburgh Napier University