Administering network security

Attack surface – all various points where an attacker may try to gain access to something on the system.

Port – number used by protocols (TCP or UDP) to identify which service or application is transmitting data. If a system is a building, ports are doors to each room inside that building. Based on ports, system knows which application uses which port to communicate with the client on the Internet. Port is an identification number assigned to a network service. Incoming network packets that have that network service’s port number trigger that service in action. While the network service is waiting for incoming packets that have its port number, they are waiting – that state is called listening.

Socket – A network socket is a combination of IP address and a port number. System associates two sockets – source socket came from the client, and destination socket came from itself. Based on those two, it knows where to send and retrieve data.

1. Scan open ports with nmap

The first step to disable unused services is to enumerate present services (enabled or disabled) on your machine. As we know, services are massive attack surface and if not properly maintained, an attacker can use them as his unauthorized entrance to our property resulting in damage of the company we work for. For that reason, it is crucial to keep services we do not use disabled, and the ones we use strictly managed to reduce attack surface to the minimum.

Tool that will help us enumerate present services on our machine is called Network Mapper (nmap). The nmap is tool often used in penetration testing area, where an attacker will scan our machine (remotely) and nmap will present him with all services present on our machine. Because of that, it is crucial to think as an attacker, and understand what information he can extract just from nmap. If he knows we have X services enabled, he knows that those doors are open for him to get in. Knowing that, we must ensure that those doors are firmly locked, or secured as much as we can.

The nmap utility, which by the way is massive tool that has entire book written on how it is used unleshing its power, is used by red team (offensive guys – attackers) and blue team (defensive guys – administrators) is used as a blueprint of the attacking or defending machine. The nmap will output all information he knows about the system among which are all open ports on the system, what services are installed, which versions of those services are present, the operating system underlaying those services, if there is a firewall, MAC address, hostname, and many other crucial information for both teams.

The nmap is developed as a network port scanning tool and it can scan multiple remote network servers, entire subnets, or entire company, showing all ports, protocols, and services that they support.

Normally, when a service is installed on a system, it opens a port (TCP or UDP) and listens for incoming connections or requests. Those incoming connections or requests need something from that service. Since we know services are extremely dumb, we need to ensure they are properly configured. For example, if an attacker requests something, let’s say to login to SSH, an administrator must configure SSH service to prevent any connections from remote hosts except the ones that we own. In that way, no attacker could login to a server with SSH because his IP is blacklisted. Since ports are open doors for good and bad guys, we must ensure good guys are allowed only and prevent bad guys from messing around the system.

The syntax of nmap is pretty straightforward. We call the command, and specify arguments, for example:

# nmap -sT
Nmap scan report for
Host is up (0.00057s latency).
Not shown: 995 closed ports
21/tcp filtered ftp
22/tcp filtered ssh
23/tcp filtered telnet
53/tcp open domain (generic dns response: NOTIMP)
| fingerprint-strings:
| DNSVersionBindReqTCP:
| version
|_ bind
80/tcp open ssl/http
[snip again]


  • -sU – Scan all UDP ports
  • -sT – Scan all TCP ports
  • -A – Scan both TCP and UDP, all ports, and services (takes most time)
  • -T5 – Fastest scan (may result in incorrect information)
  • -T1 – Slow and thorough scan

2. Scan open ports with netstat

Another tool to identify and audit network services is netstat utility. Netstat is deprecated tool meaning that in some point in the future won’t have installed by default or be present in distributions’ repositories.

In similar way as nmap, netstat will print all ports that are listening for incoming requests or connections. Here is an example to see which TCP ports are present on our system and are listening:

[root@arch ~]# netstat --tcp --listening
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 arch:6184     *               LISTEN     
tcp        0      0 localhost:6184*               LISTEN     
tcp        0      0   *               LISTEN     
tcp        0      0 localhost:versiera*               LISTEN     
tcp6       0      0 arch:6184               [::]:*                  LISTEN     
tcp6       0      0 localhost:6184          [::]:*                  LISTEN     
tcp6       0      0 [::]:xmsg               [::]:*                  LISTEN     
tcp6       0      0 [::]:ssh                [::]:*                  LISTEN
  • See all TCP listening ports: # netstat –tcp –listening
  • See all UDP listening ports: # netstat –udp –listening
  • Show all listening TCP ports: # netstat -alt
  • Show routing table: # netstat -r
  • Show multicast group membership information: # netstat -g
  • List all network interfaces with specific properties: # netstat -i
  • List summary of statistics for each protocol: # netstat -s

In the example above, you see that my PC is listening on different services or port numbers, among which is SSH service. In “Local Address” column, notice there are address:service fields. The service name is pulled from /etc/services file, and if port number isn’t defined in /etc/services file, it appears as a number.

3. Scan network sockets with ss utility

The ss (socket statistics) command is used as replacement for obsolete netstat utility. If ss is not installed on your system, it is placed inside iproute2 package, so installing that will install ss among other networking tools.


  • STATE: shows the state of a connection. States can be listening, established, non-listening.
  • RECV-Q and SEND-Q: amount of data queued for receive and send operations
  • Local Address:Port: IP address on which process listens to, and port number used.
  • Peer Address:Port: Shows IP address and port of machine that is connected (a client)


hdisplay help menu
Vversion information
Hremove heading line of output (great for scripting)
ndon’t resolve service names (don’t look at /etc/services)
rresolve domain names (IP to domain-name)
adisplay all sockets on the system (listening, nonlistening, socket types)
ldisplay only listening sockets
odisplay detailed socket information
mdisplay how much memory sockets are using
sdisplay socket usage statistics
e display detailed socket information
Edisplay sockets as they are being destroyed
4display only IPv4 sockets
6display only IPv6 sockets
udisplay only UDP sockets
tdisplay only TCP sockets
Kclose sockets on force

4. Auditing open sockets with systemd.socket

Systems that are based on systemd can create network sockets with systemd.socket. Since systemd uses unit files to describe almost everything on the system, it also contains .socket files describing, well – sockets.

[root@arch ~]# systemctl list-sockets
LISTEN                       UNIT                            ACTIVATES               
/dev/rfkill                  systemd-rfkill.socket           systemd-rfkill.service  
/run/dbus/system_bus_socket  dbus.socket                     dbus.service            
/run/dmeventd-client         dm-event.socket                 dm-event.service        
/run/dmeventd-server         dm-event.socket                 dm-event.service        
/run/lvm/lvmetad.socket      lvm2-lvmetad.socket             lvm2-lvmetad.service    
/run/lvm/lvmpolld.socket     lvm2-lvmpolld.socket            lvm2-lvmpolld.service   
/run/snapd-snap.socket       snapd.socket                    snapd.service           
/run/snapd.socket            snapd.socket                    snapd.service           
/run/systemd/coredump        systemd-coredump.socket         -                       
/run/systemd/journal/dev-log systemd-journald-dev-log.socket systemd-journald.service
/run/systemd/journal/socket  systemd-journald.socket         systemd-journald.service
/run/systemd/journal/stdout  systemd-journald.socket         systemd-journald.service
/run/udev/control            systemd-udevd-control.socket    systemd-udevd.service   
audit 1                      systemd-journald-audit.socket   systemd-journald.service
kobject-uevent 1             systemd-udevd-kernel.socket     systemd-udevd.service   

15 sockets listed.
Pass --all to see loaded but inactive sockets, too.

The following command will show if network socket is enabled or disabled for systemd. A disabled value means systemd does not manage that socket. On contrary, this does not mean service is disabled.

[root@arch ~]# systemctl list-unit-files --type=socket --no-pager
UNIT FILE                        STATE    VENDOR PRESET
avahi-daemon.socket              disabled disabled     
dbus.socket                      static   -            
dm-event.socket                  static   -            
git-daemon.socket                disabled disabled     
krb5-kpropd.socket               disabled disabled     
lvm2-lvmetad.socket              static   -            
lvm2-lvmpolld.socket             static   -            
systemd-userdbd.socket           disabled enabled      
talk.socket                      disabled disabled     
telnet.socket                    disabled disabled     
uuidd.socket                     disabled disabled     

28 unit files listed.

Now, for each enabled socket listed here (STATE : enabled), you need to open a unit file for that socket, and examine the port on which it listens. The image below shows what I mean by this.

[root@arch ~]# systemctl cat telnet.socket
# /usr/lib/systemd/system/telnet.socket
Description=Telnet Server Activation Socket



Ofcourse, auditing network sockets this way seems a bit odd, and I agree, but what do you want from me huh? Keep reading.

5. Auditing open files with lsof and fuser utilities

The lsof utility is 0.11MB program that lists all open files on the system. Hence, it can be used to audit network sockets, as they are files too.


  • Show UDP files: # lsof -iUDP
  • Show TCP files: # lsof -iTCP
  • Show TCP file with port number: # lsof -i tcp:80
  • Show listening TCP ports: # lsof -iTCP -sTCP:LISTEN

Here is an example with UDP connections:

[root@arch ~]# lsof -iUDP
NetworkMa 360  root   23u  IPv6  21565      0t0  UDP arch:dhcpv6-client 
NetworkMa 360  root   34u  IPv4  24880      0t0  UDP arch:bootpc->_gateway:bootps 
kdeconnec 606 aldin   11u  IPv6  24018      0t0  UDP *:xmsg 
qbittorre 693 aldin   23u  IPv4  21264      0t0  UDP localhost:6184 
qbittorre 693 aldin   25u  IPv6  21267      0t0  UDP localhost:6184 
qbittorre 693 aldin   27u  IPv6  21270      0t0  UDP arch:6184 
qbittorre 693 aldin   28u  IPv4  21272      0t0  UDP *:plysrv-https 
qbittorre 693 aldin   29u  IPv6  21273      0t0  UDP *:plysrv-https 
qbittorre 693 aldin   30u  IPv6  21274      0t0  UDP *:plysrv-https 
qbittorre 693 aldin   43u  IPv4  24176      0t0  UDP arch:6184 
qbittorre 693 aldin   44u  IPv4  24178      0t0  UDP *:plysrv-https 

Here is another example to filter out even more with -s for state, TCP for TCP only, and LISTEN for LISTEN connections only:

[root@arch ~]# lsof -iTCP -sTCP:LISTEN
tor       372  root    6u  IPv4  18016      0t0  TCP localhost:versiera (LISTEN)
sshd      374  root    3u  IPv4  14085      0t0  TCP *:ssh (LISTEN)
sshd      374  root    4u  IPv6  14087      0t0  TCP *:ssh (LISTEN)
kdeconnec 606 aldin   12u  IPv6  24019      0t0  TCP *:xmsg (LISTEN)
qbittorre 693 aldin   22u  IPv4  21263      0t0  TCP localhost:6184 (LISTEN)
qbittorre 693 aldin   24u  IPv6  21266      0t0  TCP localhost:6184 (LISTEN)
qbittorre 693 aldin   26u  IPv6  21269      0t0  TCP arch:6184 (LISTEN)
qbittorre 693 aldin   42u  IPv4  24175      0t0  TCP arch:6184 (LISTEN)

Disabling the Services

After we have enumerated enough from our system, we can disable unneeded services. For systemd systems, we need to stop the service if it is running, then check if it stopped:

  • # systemctl stop sshd
  • # systemctl status sshd

When service is stopped, disable it so that is disabled even after reboot. In other words, it stays disabled until we enable it manually. After that, check if it is disabled with is-enabled argument:

  • # systemctl disable sshd
  • # systemctl is-enabled sshd

For SysV systems, same situation, check if the service is running, then stop the service, then check again if stopped. When stopped, disable it:

  • # service sshd stop
  • # service sshd status

On Red-Hat systems, disabling the service is done with chkconfig, and check if it is disabled with –list argument:

  • # chkconfig sshd off
  • # chkconfig –list sshd

To disable network service on Debian systems, use update-rc.d command:

  • # update-rc.d -f sshd remove

Using super server restrictions

When a network service (daemon) starts (such is chronyd), it opens a port. We know that service is listening for a packet (incoming connection) that has its own port number, and that port will trigger that service into action.

However, instead of listening directly on a port to come, some network services have “super server” that acts as a guardian for those services. Instead service listening for incoming port number to trigger its own action, a super server listens for packets containing that port number. When incoming packet comes into the system, the super server starts the network service and gives that packet to the service to do what it needs to to.

With this method, systems boot faster because network services are not started until incoming connection with designated port number comes in. Also, super server can be used to fine-tune the services, set limit on network service use (max connections), etc.

The super server used is called xinetd (extended super daemon). Primary configuration file is /etc/xinetd.conf and it contains global default options. The file uses following keywords to restric and fine-tune super server:

cpsMaximum rate of incoming connections
to the network service
instancesMaximum number of service processes
that can be active at the same time
logtypeSet where log messages are sent. SYSLOG sents to syslog protocol, FILE sents to file
log_on_failureSet what is logged when server process cannot start
log_on_successSet what is logged when server process start
max_loadSet load average. Once reached, network service stops
accepting connections until load level drops
no_accessSet which remote hosts are banned from using this network service
only_fromSet which remote hosts are allowed from using this network service
per_sourceSet maximum number of network server processes that can be started per IP address

Those options are used within /etc/xinetd.conf configuration file. However, all files that are inside /etc/xinetd.d/ directory will overwrite the global configuration file /etc/xinetd.conf.

Here we are, if you read to the end, congratulations, and thank you. The next post will describe how to administer local system.

Leave a Reply