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.
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.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.