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 192.168.100.1
[snip]
Nmap scan report for 192.168.100.1
Host is up (0.00057s latency).
Not shown: 995 closed ports
PORT STATE SERVICE VERSION
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]Syntax:
- -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 0.0.0.0:* LISTEN
tcp 0 0 localhost:6184 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:ssh 0.0.0.0:* LISTEN
tcp 0 0 localhost:versiera 0.0.0.0:* 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.
Columns:
- 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)
Syntax:
| h | display help menu |
| V | version information |
| H | remove heading line of output (great for scripting) |
| n | don’t resolve service names (don’t look at /etc/services) |
| r | resolve domain names (IP to domain-name) |
| a | display all sockets on the system (listening, nonlistening, socket types) |
| l | display only listening sockets |
| o | display detailed socket information |
| m | display how much memory sockets are using |
| s | display socket usage statistics |
| e | display detailed socket information |
| E | display sockets as they are being destroyed |
| 4 | display only IPv4 sockets |
| 6 | display only IPv6 sockets |
| u | display only UDP sockets |
| t | display only TCP sockets |
| K | close 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 -
[SNIP]
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
[Unit]
Description=Telnet Server Activation Socket
Documentation=man:telnetd(8)
[Socket]
ListenStream=23
Accept=true
[Install]
WantedBy=sockets.targetOfcourse, 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.
Syntax:
- 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
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
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
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
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:
| cps | Maximum rate of incoming connections to the network service |
| instances | Maximum number of service processes that can be active at the same time |
| logtype | Set where log messages are sent. SYSLOG sents to syslog protocol, FILE sents to file |
| log_on_failure | Set what is logged when server process cannot start |
| log_on_success | Set what is logged when server process start |
| max_load | Set load average. Once reached, network service stops accepting connections until load level drops |
| no_access | Set which remote hosts are banned from using this network service |
| only_from | Set which remote hosts are allowed from using this network service |
| per_source | Set 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.