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,
This doesn't seem to be mentioned at all in CompTIA's description of their exam, so I will briefly explain.
IP Address Assignment
The old way on Linux
$ 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
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
the wired Ethernet inferface
and the wireless interface
It's "lo" for loopback, "e" for Ethernet, "wl" for wireless.
In particular, you should recognize:
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
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"
An assignment here means that there is no DHCP
server on this network.
The wireless Ethernet or
192.168.*.* means "inside only"
or private IP address space.
192.168.11.0/24 means a chunk within that.
Simplified, this means:
"localhost", communication only within this
"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:
172.16.*.* - 172.31.*.*
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.
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:
localhost in IPv6
fe80::/64 = link-local-only IPv6,
on the local LAN but not routable to the outside world.
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 (22.214.171.124) 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
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.
www.purduefed.com is an alias,
the canonical name is simply
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
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 (126.96.36.199), 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 (188.8.131.52) 11.886 ms 18.253 ms 9.495 ms 3 tn02gi6.fkoknt01.ap.so-net.ne.jp (184.108.40.206) 6.779 ms 7.018 ms 8.796 ms 4 note-13Vl638.net.so-net.ne.jp (220.127.116.11) 27.055 ms 54.929 ms 46.687 ms 5 18.104.22.168 23.846 ms 32.668 ms 27.771 ms 6 22.214.171.124 26.746 ms 31.092 ms 25.822 ms 7 ae-4.a01.tokyjp05.jp.bb.gin.ntt.net (126.96.36.199) 24.472 ms 29.946 ms 91.634 ms 8 ae-24.r03.tokyjp05.jp.bb.gin.ntt.net (188.8.131.52) 27.009 ms 32.079 ms 26.424 ms 9 * * * 10 ae-12-12.car1.Louisville1.Level3.net (184.108.40.206) 191.316 ms 430.565 ms 395.326 ms 11 WINTEK-CORP.car1.Louisville1.Level3.net (220.127.116.11) 392.432 ms 220.610 ms 203.536 ms 12 18.104.22.168 214.017 ms 374.270 ms 343.802 ms 13 www.purdueefcu.com (22.214.171.124) [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
network in Japan.
Hops #5 and 6 are routers in the 126.96.36.199/24 network.
That network also belongs to
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
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
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 188.8.131.52/192 range (that is, 184.108.40.206 through 220.127.116.11) 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 command can display many things,
depending on the command-line option.
Routing table with
Ethernet interface statistics with
and so on.
-a option asks for the state of all
-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 18.104.22.168.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 22.214.171.124.42117 TIME_WAIT tcp4 0 0 10.138.0.3.443 126.96.36.199.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 188.8.131.52.50820 TIME_WAIT tcp4 0 0 10.138.0.3.443 184.108.40.206.11111 FIN_WAIT_2 tcp4 0 185 10.138.0.3.443 220.127.116.11.11394 LAST_ACK tcp4 0 31 10.138.0.3.443 18.104.22.168.46154 LAST_ACK tcp4 0 0 10.138.0.3.443 22.214.171.124.5028 ESTABLISHED tcp4 0 0 10.138.0.3.443 126.96.36.199.48366 TIME_WAIT tcp4 0 0 10.138.0.3.443 188.8.131.52.58818 TIME_WAIT tcp4 0 0 10.138.0.3.443 184.108.40.206.55000 ESTABLISHED tcp4 0 4582 10.138.0.3.443 220.127.116.11.54999 ESTABLISHED tcp4 0 0 10.138.0.3.80 18.104.22.168.46944 TIME_WAIT tcp4 0 0 10.138.0.3.80 22.214.171.124.15234 TIME_WAIT tcp4 0 0 10.138.0.3.443 126.96.36.199.27269 TIME_WAIT tcp4 0 0 10.138.0.3.443 188.8.131.52.4989 TIME_WAIT tcp4 0 0 10.138.0.3.443 184.108.40.206.16889 TIME_WAIT tcp4 0 0 10.138.0.3.443 220.127.116.11.55336 ESTABLISHED tcp4 0 0 10.138.0.3.443 18.104.22.168.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
That's me connected in from 22.214.171.124, running
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.