Fountain and plaques at a Buddhist temple.

CompTIA Security+ Networking Commands

Network+ Knowledge

I have heard from two sources that the U.S. Department of Defense and CompTIA have had some rather intense discussions.

The first story that I heard described how, around late 2017, US DoD told CompTIA to quit the nonsense with questions about mid-1990s concerns, like Thicknet and Teardrop and Smurf Amplifiers. And also, cut out all the fiction, all the questions where you have to pick a specific wrong answer to get the point.

The second story described CompTIA's exasperation at the number of test-takers who didn't know much at all about networking. OK, DoD people, realize that:

CompTIA expects that most people taking Security+ have already passed Network+, or they could pass it if they took it.

Know Basic Network Command Output

I think that CompTIA is trying to include some of the CEH (or Certified Ethical Hacker) requirement to recognize basic command output. Not much compared to CEH, just a little. But they want you to do some very introductory level CEH work of interpreting tool output.

Far more than you need to know about network commands

You need to interpret the output of commands showing IP address assignment, ping, traceroute, and netstat.

This doesn't seem to be mentioned at all in CompTIA's description of their exam, so I will briefly explain.

IP Address Assignment

Linux

The old way on Linux involves the ifconfig command:

$ ifconfig
enp3s0    Link encap:Ethernet  HWaddr 42:01:0a:8a:00:03
          inet addr:169.254.10.216  Bcast:169.254.255.255  Mask:255.255.0.0
          inet6 addr: fe80::4001:aff:fe8a:3/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:148 errors:0 dropped:0 overruns:0 frame:0
          TX packets:213 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:44485 (44.4 KB)  TX bytes:32929 (32.9 KB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:1840 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1840 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:554583 (554.5 KB)  TX bytes:554583 (554.5 KB)

wlo1      Link encap:Ethernet  HWaddr 68:a3:c4:70:f1:73  
          inet addr:192.168.11.50  Bcast:192.168.11.255  Mask:255.255.255.0
          inet6 addr: fe80::c87a:16ce:3a61:8f0c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:58124 errors:0 dropped:0 overruns:0 frame:0
          TX packets:38160 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:74797563 (74.7 MB)  TX bytes:3995897 (3.9 MB)

We can no longer trust ifconfig, the ip command is the new way:

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 42:01:0a:8a:00:03 brd ff:ff:ff:ff:ff:ff
    inet 169.254.10.216/16 brd 169.254.255.255 scope link enp3s0:avahi
       valid_lft forever preferred_lft forever
    inet6 fe80::4001:aff:fe8a:3/64 scope link 
       valid_lft forever preferred_lft forever
3: wlo1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 68:a3:c4:70:f1:73 brd ff:ff:ff:ff:ff:ff
    inet 192.168.11.50/24 brd 192.168.11.255 scope global dynamic wlo1
       valid_lft 172742sec preferred_lft 172742sec
    inet6 fe80::c87a:16ce:3a61:8f0c/64 scope link 
       valid_lft forever preferred_lft forever

What do you need to know about the above for the Security+ exam?

IPv4 addresses are 32-bit strings. They are represented as four base-10 numbers in the range 0-255, separated by dots. In the above, the software loopback or "localhost" interface lo gets, 127.0.0.1, the wired Ethernet inferface enp3s0 gets 169.254.10.216, and the wireless interface wlo1 gets 192.168.11.50. It's "lo" for loopback, "e" for Ethernet, "wl" for wireless.

My page on IP addresses and subnets has far more than you need to know for Security+

In particular, you should recognize:

Loopback or lo is assigned 127.0.0.1/8, meaning that the first 8 bits or 127.*.*.* define the network. That means communication within this host only.

The wired Ethernet or enp3s0 was assigned 169.254.10.216/16, meaning that 169.254.*.* is the network itself, and 169.254.10.216 is this device in particular. Know that 169.254.*.* is the "AutoConf" address block. An assignment here means that there is no DHCP server on this network.

The wireless Ethernet or wlo1 was assigned 192.168.11.50/24. 192.168.*.* means "inside only" or private IP address space. 192.168.11.0/24 means a chunk within that.

Simplified, this means:

127.*.*.* = "localhost", communication only within this one computer

169.254.*.* = "AutoConf", automatic configuration, called Bonjour or Rendezvous among other names by Apple. Communication within the LAN, there is no functioning DHCP server.

As for "link-only" or "inside-only" addresses, these are private IP address spaces written in three equivalent ways:

10/8
10.0.0.0/8
10.*.*.*

172.16/12
172.16.0.0/12
172.16.*.* - 172.31.*.*

192.168/16
192.168.0.0/16
192.168.*.*

You need a NAT router, or a proxy gateway doing NAT, to communicate with external servers. And CompTIA is fussy about the terms, it's actually NAT/PAT for what you usually use.

IPv6

These addresses are 128 bits long, represented in base 16 or hexadecimal, 0-9 plus a-f, with colons between 16-bit or 4-character chunks that may be compressed together. You don't need to know much beyond:

::1 or ::1/128 = localhost in IPv6
fe80::/64 = link-local-only IPv6, on the local LAN but not routable to the outside world.

ping

Recognize errors. In the following, we are directly connected, plugged into the same switch. However, that other host isn't up. Our host, 192.168.11.12, is reporting that the target, 192.168.11.88, is unreachable. It recognizes that the target is on the same LAN, so it should be able to use ARP to find the target hardware address, but it can't.

$ ping 192.168.11.88
PING 192.168.11.88 (192.168.11.88) 56(84) bytes of data.
From 192.168.11.12 icmp_seq=1 Destination Host Unreachable
From 192.168.11.12 icmp_seq=2 Destination Host Unreachable
From 192.168.11.12 icmp_seq=3 Destination Host Unreachable
From 192.168.11.12 icmp_seq=4 Destination Host Unreachable
^C 

In the following, the host is a few router hops away and it isn't responding. Nothing came back. You might see some router between here and there reporting that it's unreachable. Here, it's silent failure.

$ ping whatever.example.com
PING whatever.example.com (128.46.144.53) 56(84) bytes of data.

--- whatever.example.com ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4079ms 

In the following, we asked for a name that doesn't exist. Either we misspelled it, or the relevant DNS server is lacking a record.

$ ping foo.example.com
ping: unknown host foo.example.com 

In this last one, we see another form the above error may take.

$ ping foo.example.com
ping: foo.example.com: Name or service not known

traceroute

It's spelled tracert on Windows. Recognize DNS errors as above.

The output will resemble something like the following, with one line per router along the way, and three probes to each router. Line 1 is hop #1, line 2 is the router 2 hops away, and so on.

If you don't get a response within the timeout period, you see "*" instead of a time. A line with three stars means the router at that distance did not respond at all. If you see its names or IP addresses and then a mix of times and stars, it responded some and timed out some.

An unending series of probes that entirely timed out means either that it reached the target and the target didn't respond (very common for web servers), or that the network is broken beyond the last router that responded.

Finally, slightly inconsistent DNS configurations may makes things a little more confusing.

Here is an example. I was staying at a hostel in Fukuoka, Japan, when I updated this page. I asked for a trace to the Purdue Federal Credit Union in West Lafayette, Indiana, U.S.A. I explicitly asked for the IP addresses to be converted back to fully-qualified domain names. Depending on your version of the tool, it may provide nothing but IP addresses by default.

This example shows some of the potential DNS oddities. The name www.purduefed.com is an alias, the canonical name is simply purduefed.com. Then, the hosting company has not changed the PTR record mapping back from IP address to name. It used to do business as Purdue Employees Federal Credit Union, using the domain purdueefcu.com, which appears as the last hop. There was an outdated PTR record for that IP address when I did this.

$ traceroute --resolve-hostnames www.purduefed.com
traceroute to purduefed.com (72.12.218.18), 64 hops max
 1  192.168.11.1  8.789 ms  5.242 ms  2.219 ms
 2  r081.fkoknt01.ap.so-net.ne.jp (218.221.253.61)  11.886 ms  18.253 ms  9.495 ms
 3  tn02gi6.fkoknt01.ap.so-net.ne.jp (210.132.216.89)  6.779 ms  7.018 ms  8.796 ms
 4  note-13Vl638.net.so-net.ne.jp (202.223.119.213)  27.055 ms  54.929 ms  46.687 ms
 5  202.213.194.61  23.846 ms  32.668 ms  27.771 ms
 6  202.213.194.33  26.746 ms  31.092 ms  25.822 ms
 7  ae-4.a01.tokyjp05.jp.bb.gin.ntt.net (120.88.53.9)  24.472 ms  29.946 ms  91.634 ms
 8  ae-24.r03.tokyjp05.jp.bb.gin.ntt.net (129.250.6.83)  27.009 ms  32.079 ms  26.424 ms
 9  * * *
10  ae-12-12.car1.Louisville1.Level3.net (4.69.140.213)  191.316 ms  430.565 ms  395.326 ms
11  WINTEK-CORP.car1.Louisville1.Level3.net (4.59.184.106)  392.432 ms  220.610 ms  203.536 ms
12  72.12.218.10  214.017 ms  374.270 ms  343.802 ms
13  www.purdueefcu.com (72.12.218.18) [open]  462.688 ms  263.595 ms  399.409 ms

Hop #1 is the wireless access point in the hostel. 192.168.0.0/16 is a private block of IP addresses commonly used by small routers.

Hops #2-4 are across the so-net.ne.jp network in Japan.

Hops #5 and 6 are routers in the 202.213.194.0/24 network. That network also belongs to so-net.ne.jp, but they have not set up DNS pointer records and so we only see IP addresses, not names (I used the whois command to figure out who owned those addresses). You could say that this represents an error in the form of missing DNS data. It's really only a problem for easily interpreting traceroute output, so I would only select that as an error if I couldn't find anything else.

Hops #7 and 8 are across ntt.net, a major network provider in Japan.

Hop #9 timed out all three times. That router dropped the timed-out packets, but it did not return ICMP error reports for that. Later steps returned results, so this router was not responding as expected although it could successfully forward packets for the later steps. Again, I don't see this as an error, but if I had to pick something, this seems to me to be a better choice than the lack of DNS pointer records for hops 5-6.

Hops #10 and 11 are across level3.net routers, a major world-wide provider. The round-trip times generally increase, but look how much larger they are for hop #10. The router at hop #8 was in Japan, then hop #10 was in the U.S.

Hop #12 is another router whose name doesn't resolve back to a name. The 72.12.192.0/192 range (that is, 72.12.192.0 through 72.12.223.255) belongs to Wintek, a network provider in Lafayette, Indiana.

Hop #13 is the destination.

Other than the three sent to hop #9, all the individual packets returned ICMP reports. Sometimes just 1 or 2 packets will time out, and you see "*" instead of a time.

Sometimes you will notice that every packet is routed individually. The 3 packets sent with a given TTL may take different routes, leading to 2 or 3 hostnames or IP addresses reported on the corresponding line.

netstat

The netstat command can display many things, depending on the command-line option. Routing table with -r, Ethernet interface statistics with -i, and so on.

The -a option asks for the state of all services, and -n means leave it numeric, don't try to use DNS to map back to host names. Here's a real example, from my server:

$ netstat -an
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address          Foreign Address        (state)
tcp4       0      0 10.138.0.3.22          184.16.205.240.50966   ESTABLISHED
tcp4       0      0 127.0.0.1.9000         127.0.0.1.37632        TIME_WAIT
tcp4       0      0 127.0.0.1.11628        127.0.0.1.9000         TIME_WAIT
tcp4       0      0 10.138.0.3.443         62.231.124.172.42117   TIME_WAIT
tcp4       0      0 10.138.0.3.443         62.231.124.172.42115   TIME_WAIT
tcp4       0      0 127.0.0.1.12042        127.0.0.1.9000         TIME_WAIT
tcp4       0      0 10.138.0.3.443         5.148.56.100.50820     TIME_WAIT
tcp4       0      0 10.138.0.3.443         176.212.20.116.11111   FIN_WAIT_2
tcp4       0    185 10.138.0.3.443         176.212.20.116.11394   LAST_ACK
tcp4       0     31 10.138.0.3.443         77.88.11.254.46154     LAST_ACK
tcp4       0      0 10.138.0.3.443         61.146.63.211.5028     ESTABLISHED
tcp4       0      0 10.138.0.3.443         46.229.168.84.48366    TIME_WAIT
tcp4       0      0 10.138.0.3.443         46.229.168.75.58818    TIME_WAIT
tcp4       0      0 10.138.0.3.443         92.84.229.82.55000     ESTABLISHED
tcp4       0   4582 10.138.0.3.443         92.84.229.82.54999     ESTABLISHED
tcp4       0      0 10.138.0.3.80          130.15.4.209.46944     TIME_WAIT
tcp4       0      0 10.138.0.3.80          46.229.168.70.15234    TIME_WAIT
tcp4       0      0 10.138.0.3.443         78.109.23.1.27269      TIME_WAIT
tcp4       0      0 10.138.0.3.443         61.146.63.211.4989     TIME_WAIT
tcp4       0      0 10.138.0.3.443         78.109.23.1.16889      TIME_WAIT
tcp4       0      0 10.138.0.3.443         80.42.127.171.55336    ESTABLISHED
tcp4       0      0 10.138.0.3.443         109.178.61.69.39398    FIN_WAIT_2
tcp4       0      0 *.443                  *.*                    LISTEN
tcp4       0      0 *.80                   *.*                    LISTEN
tcp4       0      0 127.0.0.1.9000         *.*                    LISTEN
tcp4       0      0 *.22                   *.*                    LISTEN
tcp4       0      0 127.0.0.1.25           *.*                    LISTEN
udp4       0      0 127.0.0.1.123          *.*                    
udp4       0      0 10.138.0.3.123         *.*                    
udp4       0      0 *.123                  *.*                    
udp4       0      0 *.514                  *.*                    

"LISTEN" indicates that a service process is listening for connections. "ESTABLISHED" means that a client is currently connected and transferring data. Others TCP states including "LAST_ACK", "TIME_WAIT", "FIN_WAIT", "FIN_WAIT_2", and others, indicate that we caught a connection in the process of being established or shut down.

Notice in the above that SSH is listening for new connections on TCP/22, and an SSH connection is currently established. That's me connected in from 184.16.205.240, running the netstat command.

My server accepts connections over HTTP (TCP/80), and immediately redirects the client to the same URL over HTTPS (TCP/443). That's called HTTPS redirect, it's best practice for security, you need to know that on the test.

To the Cybersecurity Page