Linux Network Basics

From WikiMLT

The con­tent of this ar­ti­cle is based or tak­en from the Cisco's Net­work­ing Acad­e­my NDG Lin­ux Es­sen­tials, Chap­ter 14, Net­work Con­fig­u­ra­tion. Al­so some ref­er­ences and quotes from Geeks for Geeks are used.

Ba­sic Net­work Ter­mi­nol­o­gy

Be­fore set­ting up a net­work or ac­cess­ing an ex­ist­ing net­work, it is ben­e­fi­cial to know some key terms that are re­lat­ed to net­work­ing. This sec­tion ex­plores the terms with which you should be fa­mil­iar. Some of the terms are ba­sic, and you may al­ready be fa­mil­iar with them. How­ev­er, oth­ers are more ad­vanced.

Term De­scrip­tion
Host A host is a com­put­er. Many peo­ple au­to­mat­i­cal­ly think of a desk­top com­put­er or lap­top when they hear the term com­put­er. In re­al­i­ty, many oth­er de­vices, such as cell phones, dig­i­tal mu­sic play­ers and many mod­ern tele­vi­sions, are al­so com­put­ers. In net­work­ing terms, a host is any de­vice that com­mu­ni­cates via a net­work with an­oth­er de­vice.
Net­work A net­work is a col­lec­tion of two or more hosts (com­put­ers) that are able to com­mu­ni­cate with each oth­er. This com­mu­ni­ca­tion can be via a wired con­nec­tion or wire­less.
In­ter­net The In­ter­net is an ex­am­ple of a net­work. It con­sists of a pub­licly ac­ces­si­ble net­work that con­nects mil­lions of hosts through­out the world. Many peo­ple use the In­ter­net to surf web pages and ex­change emails, but the In­ter­net has many ad­di­tion­al ca­pa­bil­i­ties be­sides these ac­tiv­i­ties.
Wi-Fi The term Wi-Fi refers to wire­less net­works.
Serv­er A host that pro­vides a ser­vice to an­oth­er host or client is called a serv­er. For ex­am­ple, a web serv­er stores, process­es and de­liv­ers web pages. An email serv­er re­ceives in­com­ing mail and de­liv­ers out­go­ing mail.
Ser­vice A fea­ture pro­vid­ed by a host is a ser­vice. An ex­am­ple of a ser­vice would be when a host pro­vides web pages to an­oth­er host.
Client A client is a host that is ac­cess­ing a serv­er. When you are work­ing on a com­put­er surf­ing the In­ter­net, you are con­sid­ered to be on a client host.
Router Al­so called a gate­way, a router is a ma­chine that con­nects hosts from one net­work to an­oth­er net­work. For ex­am­ple, if you work in an of­fice en­vi­ron­ment, the com­put­ers with­in the com­pa­ny can all com­mu­ni­cate via the lo­cal net­work cre­at­ed by the ad­min­is­tra­tors. To ac­cess the In­ter­net, the com­put­ers would have to com­mu­ni­cate with a router that would be used to for­ward net­work com­mu­ni­ca­tions to the In­ter­net. Typ­i­cal­ly when you com­mu­ni­cate on a large net­work (like the In­ter­net), sev­er­al routers are used be­fore your com­mu­ni­ca­tion reach­es its fi­nal des­ti­na­tion.

Net­work­ing Fea­tures Ter­mi­nol­o­gy

In ad­di­tion to the net­work­ing terms dis­cussed in the last sec­tion, there are some ad­di­tion­al terms with which you should be fa­mil­iar. These terms fo­cus more on the dif­fer­ent types of net­work­ing ser­vices that are com­mon­ly used, as well as some of the tech­niques that are used to com­mu­ni­cate be­tween ma­chines.

Term De­scrip­tion
Pack­et A net­work pack­et is used to send net­work com­mu­ni­ca­tion be­tween hosts. By break­ing down com­mu­ni­ca­tion in­to small­er chunks (pack­ets), the da­ta de­liv­ery method is much more ef­fi­cient.
IP Ad­dress An In­ter­net Pro­to­col (IP) ad­dress is a unique num­ber as­signed to a host on a net­work. Hosts use these num­bers to ad­dress net­work com­mu­ni­ca­tion.
Mask Al­so called a net­mask, sub­net mask or mask, a net­work mask is a num­ber sys­tem that can be used to de­fine which IP ad­dress­es are con­sid­ered to be with­in a sin­gle net­work. Be­cause of how routers per­form their func­tions, net­works have to be clear­ly de­fined.
Host­name Each host on a net­work could have its own host­name be­cause names are more nat­ur­al for hu­mans to re­mem­ber than num­bers, mak­ing it eas­i­er for us to ad­dress net­work pack­ets to an­oth­er host. Host­names are trans­lat­ed in­to IP ad­dress­es be­fore the net­work pack­et is sent on the net­work.
URL A Uni­form Re­source Lo­ca­tor (URL), al­so com­mon­ly called a web ad­dress, is used to lo­cate a re­source, like a web page, on the in­ter­net. It’s what you type in­to your web brows­er to ac­cess a web page. For ex­am­ple, http://​www​.netdevgroup​.com. It in­cludes the pro­to­col http:// and the host­name www​.netdevgroup​.com.
DHCP Hosts can be as­signed host­names, IP ad­dress­es and oth­er net­work-re­lat­ed in­for­ma­tion by a DHCP (Dy­nam­ic Host Con­fig­u­ra­tion Pro­to­col) serv­er. In the world of com­put­ers, a pro­to­col is a well-de­fined set of rules. DHCP de­fines how net­work in­for­ma­tion is as­signed to client hosts, and the DHCP serv­er is the ma­chine that pro­vides this in­for­ma­tion.
DNS As men­tioned pre­vi­ous­ly, host­names are trans­lat­ed in­to IP ad­dress­es, pri­or to the net­work pack­et be­ing sent on the net­work. So your host needs to know the IP ad­dress of all of the oth­er hosts with which you are com­mu­ni­cat­ing. When work­ing on a large net­work (like the In­ter­net), this can pose a chal­lenge as there are so many hosts. A Do­main Name Sys­tem (DNS) pro­vides the ser­vice of trans­lat­ing do­main names in­to IP ad­dress­es.
Eth­er­net In a wired net­work en­vi­ron­ment, Eth­er­net is the most com­mon way to phys­i­cal­ly con­nect the hosts in­to a net­work. Eth­er­net ca­bles are con­nect­ed to net­work cards that sup­port Eth­er­net con­nec­tions. Eth­er­net ca­bles and de­vices (such as routers) are specif­i­cal­ly de­signed to sup­port dif­fer­ent com­mu­ni­ca­tion speeds, the low­est be­ing 10 Mbps (10 Megabits per sec­ond) and the high­est be­ing 100 Gbps (100 gi­ga­bits per sec­ond). The most com­mon speeds are 100 Mbps and 1 Gbps.
TCP/IP The Trans­mis­sion Con­trol Protocol/​​​Internet Pro­to­col (TCP/IP) is a fan­cy name for a col­lec­tion of pro­to­cols (re­mem­ber, pro­to­col = set of rules) that are used to de­fine how net­work com­mu­ni­ca­tion should take place be­tween hosts. While it isn't the on­ly col­lec­tion of pro­to­cols used to de­fine net­work com­mu­ni­ca­tion, it is the most of­ten uti­lized one. As an ex­am­ple, TCP/IP in­cludes the de­f­i­n­i­tion of how IP ad­dress­es and net­work masks work.

IP Ad­dress­es

There are, in fact, two dif­fer­ent types of IP ad­dress­es: IPv4 and IPv6.

In an IPv4 ad­dress, a to­tal of four 8‑bit num­bers are used to de­fine the ad­dress. This is con­sid­ered a 32-bit ad­dress (4 x 8 = 32). For ex­am­ple:

192.168.10.120. # 8-bit refers to numbers from 0 to 255.

In an IPv4 en­vi­ron­ment, there is a tech­ni­cal lim­it of about 4.3 bil­lion IP ad­dress­es. This is­sue en­cour­aged the de­vel­op­ment of IPv6. IPv6 was of­fi­cial­ly cre­at­ed in 1998. In an IPv6 net­work the ad­dress­es are much larg­er, 128-bit ad­dress­es that look like this:

2001:0db8:85a3:0042:1000:8a2e:0370:7334

It is im­por­tant to note that the dif­fer­ence be­tween IPv4 and IPv6 isn't just a larg­er ad­dress pool. IPv6 has many oth­er ad­vanced fea­tures that ad­dress some of the lim­i­ta­tions of IPv4, in­clud­ing bet­ter speed, more ad­vanced pack­age man­age­ment and more ef­fi­cient da­ta trans­porta­tion. How­ev­er, the ma­jor­i­ty of net­work-at­tached de­vices in the world still use IPv4 (some­thing like 98–99% of all de­vices).

So, why hasn't the world em­braced the su­pe­ri­or tech­nol­o­gy of IPv6?

There are pri­mar­i­ly two rea­sons:

  • NAT: In­vent­ed to over­come the pos­si­bil­i­ty of run­ning out of IP ad­dress­es in an IPv4 en­vi­ron­ment, Net Ad­dress Trans­la­tion (NAT) used a tech­nique to pro­vide more hosts ac­cess to the In­ter­net. In a nut­shell, a group of hosts is placed in­to a pri­vate net­work with no di­rect ac­cess to the In­ter­net; a spe­cial router pro­vides In­ter­net ac­cess, and on­ly this one router needs an IP ad­dress to com­mu­ni­cate on the In­ter­net. In oth­er words, a group of hosts shares a sin­gle IP ad­dress, mean­ing a lot more com­put­ers can at­tach to the In­ter­net. This fea­ture means the need to move to IPv6 is less crit­i­cal than be­fore the in­ven­tion of NAT.
  • Port­ing: Port­ing is switch­ing over from one tech­nol­o­gy to an­oth­er. IPv6 has a lot of great new fea­tures, but all of the hosts need to be able to uti­lize these fea­tures. Get­ting every­one on the In­ter­net (or even just some) to make these changes pos­es a chal­lenge. ‌⁠​​⁠​

Ports

A port is a unique num­ber that is as­so­ci­at­ed with a ser­vice pro­vid­ed by a host.

Well-known ports are the port num­bers in the range of 0–1023, typ­i­cal­ly used by sys­tem process­es to pro­vide net­work ser­vices. A list of ser­vice names and as­so­ci­at­ed port num­bers can be found in the /​​​etc/​​​services file.

nano /etc/services

Do­main Name Sys­tem (DNS)

When a com­put­er is asked to ac­cess a web­site, such as www​.example​.com, it does not nec­es­sar­i­ly know what IP ad­dress to use. For the com­put­er to as­so­ciate an IP ad­dress with the URL or host­name re­quest, the com­put­er re­lies up­on the DNS ser­vice of an­oth­er com­put­er. Of­ten, the IP ad­dress of the DNS serv­er is dis­cov­ered dur­ing the DHCP re­quest, while a com­put­er is re­ceiv­ing im­por­tant ad­dress­ing in­for­ma­tion to com­mu­ni­cate on the net­work.

The ad­dress of the DNS serv­er is stored in the /etc/resolv.conf file. A typ­i­cal /etc/resolv.conf file is au­to­mat­i­cal­ly gen­er­at­ed and looks like the fol­low­ing:

# Proxmox VE on Debian
root@pve:~# cat /etc/resolv.conf
search szs.space
nameserver 172.16.1.1
# Ubuntu Server 20.04
user@ubuntu:~# cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad

The host com­mand works with DNS to as­so­ciate a host­name with an IP ad­dress.

host szs.space
szs.space has address 185.218.64.95
szs.space mail is handled by 30 mx.szs.space.
host 185.218.64.95
95.64.218.185.in-addr.arpa domain name pointer home-unl-ip95-Ruse.networx-bg.com.

Net­work Con­fig­u­ra­tion Files

Name res­o­lu­tion on a Lin­ux host is ac­com­plished by 3 crit­i­cal files: the /​​​etc/​​​hosts, /etc/resolv.conf and /etc/nsswitch.conf files. To­geth­er, they de­scribe the lo­ca­tion of name ser­vice in­for­ma­tion, the or­der in which to check re­sources, and where to go for that in­for­ma­tion.

Files Ex­pla­na­tion
/​​​etc/​​​hosts

This file con­tains a ta­ble of host­names to IP ad­dress­es. It can be used to sup­ple­ment a DNS serv­er.

$ cat /etc/hosts
127.0.1.1 szs
127.0.0.1 localhost szs

…and num­ber of oth­er IPv4 and IPv6 en­tries.

/etc/resolv.conf

This file con­tains the IP ad­dress­es of the name servers the sys­tem should con­sult in any at­tempt to re­solve names to IP ad­dress­es. These servers are of­ten DNS servers. It al­so can con­tain ad­di­tion­al key­words and val­ues that can af­fect the res­o­lu­tion process.

$ cat /etc/resolv.conf
nameserver 10.0.2.3
nameserver 10.0.2.4

It should con­tain at least two en­tries for name servers. The DNS res­o­lu­tion sys­tem will use the first name serv­er for an at­tempt­ed lookup of the name. If that is un­avail­able, or a time­out pe­ri­od is reached, the sec­ond serv­er will then be queried for the name res­o­lu­tion.

/etc/nsswitch.conf

This file can be used to mod­i­fy where host­name lookups oc­cur. It con­tains a par­tic­u­lar en­try that de­scribes in what or­der name res­o­lu­tion sources are con­sult­ed.

$ cat /etc/nsswitch.conf
...
hosts: files dns
...

The above en­try means: The /​​​etc/​​​hosts file is searched first, the DNS serv­er sec­ond. The DNS serv­er would be searched first, lo­cal files sec­ond – hosts: dns files al­so more val­ues could be added – hosts: files dns my­ma­chines

Two oth­er key­words may ap­pear in the system’s /etc/resolv.conf file. They are rou­tine­ly in­clud­ed in de­fault /etc/resolv.conf files and so we in­clude ex­pla­na­tions of these terms be­low:

do­main Fol­lowed by a qual­i­fied do­main, such as snowblower​.example​.com, al­lows the query for the host po­laris to be tried both just as the host po­laris, or fail­ing that, ap­pend­ing the rest of the do­main name to it and hope­ful­ly hav­ing it re­solved by the serv­er as that name (e.g. polaris​.snowblower​.example​.com.).
search Fol­lowed by a set of sep­a­rate do­mains which can be queried one af­ter the oth­er hope­ful­ly to re­solve the name.

Net­work Tools

There are sev­er­al com­mands that you can use to view net­work in­for­ma­tion. These tools can al­so be use­ful when you are trou­bleshoot­ing net­work is­sues.

The if­con­fig com­mand

The if­con­fig com­mand stands for in­ter­face con­fig­u­ra­tion and is used to dis­play net­work con­fig­u­ra­tion in­for­ma­tion. The com­mand can be used to mod­i­fy the net­work set­tings tem­porar­i­ly – to do the changes per­sis­tent you must change the con­fig­u­ra­tion files of the net­work man­ag­er in use.

The ip com­mand

The nowa­days ver­sions of De­bian and Ubun­tu comes wit the com­mand ip by de­fault, if­con­fig could be in­stalled but it is dep­re­cat­ed. To get an out­put sim­i­lar to if­con­fig (with­out any op­tions) we can use ip a or ip ad­dr show.

The ip com­mand has in­creased func­tion­al­i­ty and set of op­tions, it can al­most be a one-stop shop for con­fig­u­ra­tion and con­trol of a system’s net­work­ing. The for­mat for the ip com­mand is as fol­lows:

ip [OPTIONS] OBJECT COMMAND

The ip com­mand branch­es out to do some of the work of sev­er­al oth­er lega­cy com­mands such as route and arp.

See al­so: Tech­Mint: 10 Use­ful “IP” Com­mands to Con­fig­ure Net­work In­ter­faces.

The route com­mand

Re­call that a router (or gate­way) is a ma­chine that al­lows hosts from one net­work to com­mu­ni­cate with an­oth­er net­work. To view a ta­ble that de­scribes where net­work pack­ages are sent, use the route com­mand:

user@ubuntu:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    0      0        0 enp6s18
172.16.1.0      0.0.0.0         255.255.255.0   U     0      0        0 enp6s18
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0

Dis­play this in­for­ma­tion with nu­mer­ic da­ta on­ly, by us­ing the -n op­tion to the route com­mand.

user@ubuntu:~$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.16.1.1      0.0.0.0         UG    0      0        0 enp6s18
172.16.1.0      0.0.0.0         255.255.255.0   U     0      0        0 enp6s18
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0

The route com­mand is be­com­ing ob­so­lete in some Lin­ux dis­tri­b­u­tions (dep­re­cat­ed) and is be­ing re­placed with a form of the ip com­mand, specif­i­cal­ly ip route or ip route show. Note that the same in­for­ma­tion high­light­ed above can al­so be found us­ing this com­mand:

user@ubuntu:~$ ip route
default via 172.16.1.1 dev enp6s18 proto static
172.16.1.0/24 dev enp6s18 proto kernel scope link src 172.16.1.201
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1

The ping com­mand

The ping com­mand can be used to de­ter­mine if an­oth­er ma­chine is reach­able.

user@ubuntu:~$ ping 192.168.1.100

To lim­it how many pings to send, use the -c op­tion fol­lowed by a num­ber in­di­cat­ing how many it­er­a­tions you de­sire.

user@ubuntu:~$ ping -c 4192.168.1.100

It is im­por­tant to note that just be­cause the ping com­mand fails does not mean that the re­mote sys­tem is un­reach­able. Some ad­min­is­tra­tors con­fig­ure their ma­chines (and even en­tire net­works!) to not re­spond to ping re­quests be­cause a serv­er can be at­tacked by some­thing called a de­nial of ser­vice at­tack. In this sort of at­tack, a serv­er is over­whelmed by a mas­sive num­ber of net­work pack­ets. By ig­nor­ing ping re­quests, the serv­er is less vul­ner­a­ble.

Many ad­min­is­tra­tors use the ping com­mand with a host­name, and if that fails then use the IP ad­dress to see if the fault is in re­solv­ing the device’s host­name. Us­ing the host­name first saves time; if that ping com­mand is suc­cess­ful, there is prop­er name res­o­lu­tion, and the IP ad­dress is func­tion­ing cor­rect­ly as well.

The net­stat com­mand

The net­stat com­mand is a pow­er­ful tool that pro­vides a large amount of net­work in­for­ma­tion. It can be used to dis­play in­for­ma­tion about net­work con­nec­tions as well as dis­play the rout­ing ta­ble sim­i­lar to the route com­mand.

For ex­am­ple, to dis­play sta­tis­tics re­gard­ing net­work traf­fic, use the -i op­tion to the net­stat com­mand:

netstat -i
Kernel Interface table
Iface      MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0      1500    13539      0     20 0          2460      0      0      0 BMRU
lo       65536     1368      0      0 0          1368      0      0      0 LRU

The most im­por­tant sta­tis­tics from the out­put above are the TX-OK and TX-ERR. A high per­cent­age of TX-ERR may in­di­cate a prob­lem on the net­work, such as too much net­work traf­fic.

To use the net­stat com­mand to dis­play rout­ing in­for­ma­tion, use the -r op­tion:

netstat -r
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
default         host-185-143-18 0.0.0.0         UG        0 0          0 eth0
185.143.189.0   0.0.0.0         255.255.254.0   U         0 0          0 eth0

The net­stat com­mand is al­so com­mon­ly used to dis­play open ports. A port is a unique num­ber that is as­so­ci­at­ed with a ser­vice pro­vid­ed by a host. If the port is open, then the ser­vice is avail­able for oth­er hosts. To see a list of all cur­rent­ly open ports, use the fol­low­ing com­mand:

netstat -tln
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN
tcp6       0      0 :::22                   :::*                    LISTEN
tcp6       0      0 :::80                   :::*                    LISTEN
tcp6       0      0 :::443                  :::*                    LISTEN

The -t op­tion to the net­stat com­mand lim­its the list­ing to TCP ports; the -l op­tion lim­its the out­put to ports with lis­ten­ing ser­vices; the -n shows the net­work ad­dress­es nu­mer­i­cal­ly.

While no fur­ther de­vel­op­ment is be­ing done on the net­stat com­mand, it is still an ex­cel­lent tool for dis­play­ing net­work in­for­ma­tion. The goal is to even­tu­al­ly re­place the net­stat com­mand with com­mands such as the ss and ip com­mands. How­ev­er, it is im­por­tant to re­al­ize that this may take some time.

Com­mon­ly used op­tions.

netstat -tln
netstat -tuln
netstat -tnupa
netstat -penaut
netstat -pnat

The if­s­tat com­mand

if­s­tat – re­port In­ter­Face STA­Tis­tics – it is a lit­tle tool to re­port in­ter­face ac­tiv­i­ty, just like io­stat/vm­stat do for oth­er sys­tem sta­tis­tics.

sudo apt install ifstat
ifstat [-a] [-l] [-z] [-n] [-v] [-h] [-t] [-i if0,if1,...] [-d drv[:opt]] [-s
       [comm@][#]host[/nn]] [-T] [-A] [-w] [-W] [-S] [-b] [-q] [delay[/delay] [count]]
sudo ifstat -t
  Time         enp6s18             docker0         br-7924d7f73888       vethf21c018         veth124914d         vetha6d5f6c    
HH:MM:SS   KB/s in  KB/s out   KB/s in  KB/s out   KB/s in  KB/s out   KB/s in  KB/s out   KB/s in  KB/s out   KB/s in  KB/s out
21:38:04      2.32      7.15      20.37    17.56      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
21:38:05      0.12      0.22      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
21:38:06      1.97      5.43      0.00      0.00      0.16      0.95      0.00      0.08      0.00      0.08      0.22      0.95
21:38:07     28.06   1037.76      0.00      0.00   1013.09     18.08      0.54      1.63      0.00      0.08   1016.72     18.57
21:38:08     10.55    825.46      0.00      0.00    820.37      7.55      3.93      2.76      0.00      0.00    824.55     11.48

The lsof com­mand

Test which ser­vice at which port lis­tens to (sim­i­lar to net­stat ‑tuln):

sudo lsof -i -n -P
sudo lsof -i -n -P +c 0
sudo lsof -i -n -P +c 0 | grep ':80\|:443'
sudo lsof -i -n -P | grep www-data

See al­so the fol­low­ing an­swers for prac­ti­cal us­age of lsof:

The nmap com­mand

The com­mand nmap is Lin­ux com­mand-line tool for net­work ex­plo­ration and se­cu­ri­ty au­dit­ing. This tool is gen­er­al­ly used by hack­ers and cy­ber­se­cu­ri­ty en­thu­si­asts and even by net­work and sys­tem ad­min­is­tra­tors. It is used for the fol­low­ing pur­pos­es:

  • Re­al time in­for­ma­tion of a net­work
  • De­tailed in­for­ma­tion of all the IPs ac­ti­vat­ed on your net­work
  • Num­ber of ports open in a net­work
  • Pro­vide the list of live hosts
  • Port, OS and Host scan­ning
nmap -h                              # get help and examples
nmap www.geeksforgeeks.org           # basic usage
nmap -p22 www.geeksforgeeks.org      # basic usage with certain port
nmap -p80-82 www.geeksforgeeks.org   # basic usage with port range
nmap -p U:53,111,137,T:21-25,80,139,8080,S:9 www.geeksforgeeks.org
nmap -sT 77.77.77.70
nmap --script vuln 77.77.77.70

Find all IPv4 ad­dress­es in the LAN:

nmap -sn 192.168.100.0/24

Scan for open ports at cer­tain IPv4 ad­dress:

sudo nmap -p 1-20000 192.168.100.110

See al­so:

The ss com­mand

The ss com­mand is de­signed to show sock­et sta­tis­tics and sup­ports all the ma­jor pack­et and sock­et types. Meant to be a re­place­ment for and to be sim­i­lar in func­tion to the net­stat com­mand, it al­so shows a lot more in­for­ma­tion and has more fea­tures.

The main rea­son a user would use the ss com­mand is to view what con­nec­tions are cur­rent­ly es­tab­lished be­tween their lo­cal ma­chine and re­mote ma­chines, sta­tis­tics about those con­nec­tions, etc.

Sim­i­lar to the net­stat com­mand, you can get a great deal of use­ful in­for­ma­tion from the ss com­mand just by it­self as shown in the ex­am­ple be­low.

ss
Netid  State      Recv-Q Send-Q   	Local Address:Port       	   Peer Address:Port
u_str  ESTAB      0      0                    * 104741                     * 104740 
u_str  ESTAB      0      0      /var/run/dbus/system_bus_socket 14623      * 14606  
u_str  ESTAB      0      0      /var/run/dbus/system_bus_socket 13582      * 13581  
...

The out­put is very sim­i­lar to the out­put of the net­stat com­mand with no op­tions. The columns above are:

Netid The sock­et type and trans­port pro­to­col
State Con­nect­ed or Un­con­nect­ed, de­pend­ing on pro­to­col
Recv‑Q Amount of da­ta queued up for be­ing processed hav­ing been re­ceived
Send‑Q Amount of da­ta queued up for be­ing sent to an­oth­er host
Lo­cal Ad­dress The ad­dress and port of the lo­cal host’s por­tion of the con­nec­tion
Peer Ad­dress The ad­dress and port of the re­mote host’s por­tion of the con­nec­tion

The for­mat of the out­put of the ss com­mand can change dra­mat­i­cal­ly, giv­en the op­tions spec­i­fied, such as the use of the -s op­tion, which dis­plays most­ly the types of sock­ets, sta­tis­tics about their ex­is­tence and num­bers of ac­tu­al pack­ets sent and re­ceived via each sock­et type, as shown be­low:

ss -s
Total: 1000 (kernel 0)
TCP:   7 (estab 0, closed 0, orphaned 0, synrecv 0, timewait 0/0), ports 0
 
Transport Total     IP        IPv6
*	  	  0         -         -        
RAW	  	  0         0         0        
UDP	  	  9         6         3        
TCP	  	  7         3         4        
INET	  16        9         7        
FRAG	  0         0         0
sudo ss -ltpn
State     Recv-Q    Send-Q            Local Address:Port        Peer Address:Port   Process
LISTEN    0         1                     127.0.0.1:52400            0.0.0.0:*       users:(("autossh",pid=1141240,fd=3))
LISTEN    0         1                     127.0.0.1:52944            0.0.0.0:*       users:(("autossh",pid=1141206,fd=3))
LISTEN    0         1024                  127.0.0.1:6800             0.0.0.0:*       users:(("aria2c",pid=21787,fd=5))
LISTEN    0         1                     127.0.0.1:56337            0.0.0.0:*       users:(("autossh",pid=1141044,fd=3))
LISTEN    0         65535                   0.0.0.0:8081             0.0.0.0:*       users:(("docker-proxy",pid=8859,fd=4))
LISTEN    0         65535                   0.0.0.0:8082             0.0.0.0:*       users:(("docker-proxy",pid=9062,fd=4))
...

The dig com­mand

The dig com­mand stands for Do­main In­for­ma­tion Grop­er. It is used for re­triev­ing in­for­ma­tion about DNS name servers. It is ba­si­cal­ly used by net­work ad­min­is­tra­tors. It is used for ver­i­fy­ing and trou­bleshoot­ing DNS prob­lems and to per­form DNS lookups. Dig com­mand re­places old­er tools such as nslookup and the host.

dig [@global-server] [domain] [q-type] [q-class] {q-opt}
dig -h

There may be times when you need to test the func­tion­al­i­ty of the DNS serv­er that your host is us­ing. One way of do­ing this is to use the dig com­mand, which per­forms queries on the DNS serv­er to de­ter­mine if the in­for­ma­tion need­ed is avail­able on the serv­er.

dig geeksforgeeks.org                       # get verbose information
dig geeksforgeeks.org +short                # get essential information only IP in this case
dig geeksforgeeks.org TXT +short            # get only the TXT records 
dig _acme-challenge.example.com TXT +short  # get certain TXT record

If the DNS serv­er doesn't have the re­quest­ed in­for­ma­tion, it is con­fig­ured to ask oth­er DNS servers. If none of them have the re­quest­ed in­for­ma­tion, an er­ror mes­sage dis­plays. Here is how to test the da­ta cached for a tar­get host by a cer­tain DNS:

dig @ns1.domain.com metalevel.tech +short

See al­so: Dig­i­talO­cean Docs: Re­trieve DNS In­for­ma­tion Us­ing Dig

The host com­mand

In its sim­plest form, the host com­mand works with DNS to as­so­ciate a host­name with an IP ad­dress. As used in a pre­vi­ous ex­am­ple, example​.com is as­so­ci­at­ed with the IP ad­dress of 192.168.1.2:

host example.com
example.com has address 192.168.1.2

The host com­mand can al­so be used in re­verse if an IP ad­dress is known, but the do­main name is not.

host 192.168.1.2
2.1.168.192.in-addr.arpa domain name pointer example.com.                     
2.1.168.192.in-addr.arpa domain name pointer cserver.example.com.

Oth­er op­tions ex­ist to query the var­i­ous as­pects of a DNS such as a CNAME canon­i­cal name ‑alias:

host -t CNAME example.com
example.com has no CNAME record

Since many DNS servers store a copy of example​.com, SOA Start of Au­thor­i­ty records in­di­cate the pri­ma­ry serv­er for the do­main:

host -t SOA example.com
example.com has SOA record example.com. cserver.example.com. 2 604800 86400 2419200 604800

A com­pre­hen­sive list of DNS in­for­ma­tion re­gard­ing example​.com can be found us­ing the -a all op­tion:

host -a example.com
Trying "example.com"                                                          
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3549                      
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:                                                          
;example.com.                   IN      ANY
;; ANSWER SECTION:                                                            
example.com.            86400   IN      SOA     example.com. cserver.example.com. 2 604800 86400 2419200 604800
example.com.            86400   IN      NS      example.com.
example.com.            86400   IN      A       192.168.1.2

;; ADDITIONAL SECTION:
example.com.            86400   IN      A       192.168.1.2

Received 119 bytes from 127.0.0.1#53 in 0 ms

The ssh com­mand

The ssh com­mand al­lows you to con­nect to an­oth­er ma­chine across the net­work, log in and then per­form tasks on the re­mote ma­chine.

If you on­ly pro­vide a ma­chine name or IP ad­dress to log in­to, the ssh com­mand as­sumes you want to log in us­ing the same user­name that you are cur­rent­ly logged in as. To use a dif­fer­ent user­name, use the syn­tax:

ssh username@hostname   # type `exit` to close the connection

When us­ing the ssh com­mand, the first prompt asks you to ver­i­fy the iden­ti­ty of the ma­chine you are log­ging in­to. In most cas­es, you are go­ing to want to an­swer yes. While you can check with the ad­min­is­tra­tor of the re­mote ma­chine to make sure that the RSA key fin­ger­print is cor­rect, this isn't the pur­pose of this query. It is de­signed for fu­ture lo­gin at­tempts.

Af­ter you an­swer yes, the RSA key fin­ger­print of the re­mote ma­chine is stored on your lo­cal sys­tem. When you at­tempt to ssh to this same ma­chine in the fu­ture, the RSA key fin­ger­print pro­vid­ed by the re­mote ma­chine is com­pared to the copy stored on the lo­cal ma­chine. If they match, then the user­name prompt ap­pears. If they don't match, an er­ror is sis­played.

This er­ror could in­di­cate that a rogue host has re­placed the cor­rect host. Check with the ad­min­is­tra­tor of the re­mote sys­tem. If the sys­tem were re­cent­ly re­in­stalled, it would have a new RSA key, and that would be caus­ing this er­ror.

In the event that this er­ror mes­sage is due to a re­mote ma­chine re­in­stall, you can re­move the ~/.ssh/known_hosts file from your lo­cal sys­tem (or just re­move the en­try for that one ma­chine) and try to con­nect again.