How to Secure a Network with Linux

Securing a network with Linux involves knowing techniques for how to:

• Secure network services.

• Prevent information leakage.
• Test for open ports and perform port scans
• Manage Xinetd security.
• Secure SSH
• Configure local Linux firewalls.

Securing Network Services

What are Network Services

• Network services are sometimes called daemons (a program that runs

continuously and exists for the purpose of handling periodic service
requests).
o Listen on network ports for incoming connections
o Often the focal point of system attacks.

• Constantly running in the background.

• Output recorded in log files.
o Not connected to a terminal
o Some use var system log files
o Some use their own log files
o Check the config files

• Designed to perform a single task.

How to Secure Network Services

• Use a dedicated user for each service.

o Take advantage of privilege separation. If an account gets
exploited, it can only impact a single service.
o Do not run services as root

• Ports below 1024 are privileged.

o Require superuser privileges to open.
o Use root to open them, then drop privileges.
o Configuration controlled by each service.
 • Stop and uninstall unused services.
o Each service is an attack vector.

• Avoid unsecure services.

o Use SSH instead of telnet, rlogin, rsh, and FTP
o Do not use unencrypted services.

• Stay up to date with patches.

o Install services provided by your distro.

• Only listen on the required interfaces and addresses.

o Many default to listening to every network interface and address
on the system.

Diagrammatic layout of network connections.

For example, say you are runninng a server that has a webserver running a
process, you want to be able to log into the server to configure SSHD. Say the
server has two connection, one on the public side (5.4.3.2) and one on the
private side (192.168.0.2). If you allow SSH tto bind to all the addresses on
your system, then SSH would be exposed to the outside world.

Preventing Information Leakage

•
o Avoid revealing information where possible.
Web Server Information Leakage

Curl request revealing server information.

As seen in the image above, you should avoid revealing information about
your servers’ operating systems in the headers (web server banners). Other
places that can leak server information are:

• Message of the day file – /etc/motd. This is displayed with a user logs
inl
• /etc/issue: displayed before login prompt on the Linux console.

How Do You Tell What Services Are Running on Linux

If you are running SystemD can displaying the services that are currently
running on your system with systemctl:
Screenshot of output from running systemctl on Linux.
Obviously not everything listed in the image above is a network services, but
you have some understanding of what is running on your system.

Stopping and Disabling SystemD Controlled Services

• systemctl stop
o Stopping a service stops it for now, but it will restart when the
system rebootts/restarts.
• systemctl disable SERVICE
o Prevents a system from restarting when the system
reboots/restarts.

List Listening Programs with netstat

Using the netstat will let you see which services are running.

In the image below, we run the netstat command, as sudo, with a number of
flags (nutlp).
Running the netstat command on Linux to view the listening programs.
In the image above, the following flags were used:

• n: Displays the output in numeric form

• u: tells netstat to include the UDP protocol
• t: tells netstat to include TCP protocol
• l:diplays listening sockets
• p: displays the PID/Process name
You can also see that the snmp process is running on the loop back IP at port
161. If a service is only being used locally, bind it to the local host address.

Port Scanning
Another way to see if something is listening on your system is to run a port
scan using something like nmap.

• nmap is called with a host name for an argument

o eg nmap 8.8.8.8
In the image below, Secur ran an nmap scan against a company by the name
of Canopy Growth, a cannabis producer and generated a report of the open
port on their system, 80 and 443.
Running an nmap port scan on Canopygrowth.com
Another option to look for open services is to use the lsof (list open files)
command, as in the image below. Remember that practically everything on
Linux is listed as a file.

Running the lsof command to show the established and listening network connections.

Testing a Specific Port

• If you want to see if a specific port is reachable, use the telnet

command with the host and address port.
o Historically used to log into systems, you can use telnet to
connect to a port and send data to the port.
• You can also use the netcat command to attempt to connect to an open
port like so:
nc -v
• The “-v” option indicates that netcat should run in verbose mode and
print out if a connection failed or succeeded.
Packet Paths
Schematic of the path packets take, assuming there are no rules that stop the packets.
Looking at the diagram above and assuming there are no rules that stop
packets along the way:

• Inbound packets: go through prerouting and input chains before

reaching the local system
• Inbound packet destine for another host: packets go through prerouting,
forward and post routing chain before leaving.
• Outbound packets: Go through output and postrouting chains before
leaving the network.
When you combine the chain traversal order with the tables in which they are
used, you get a complete picture of a path that a packet takes through a
computer system in the image below.
Diagrammatic representation of packet pathways through firewall tables and chains.
• Any incoming packet starts at the top of the diagram and follows this
route:
o Into the nat Table and the PREROUTING chain
 o From here is is either directed to the local system or it is going to
be forwarded.
▪ If destined for the local system, then the packet goes to the
INPUT chain of the filter Table.
• If the packet comes from the local system then it will transverse the nat
Table‘s OUTPUT chain followed by the filter Table‘s OUTPUT chain
• From there it goes to the POSTROUTING chain of the nat Table and
leaves the system.

Firewall Rule Specifications

• Now that we know the path that packets take through the system, you
can start creating rules and putting them in tables and chains
• Rules are comprised of a match and a target.
o Rules = Match + Target
● You can match a packet several different ways.
▪ Match on:
○ Protocol
○ Source/Dest IP or network
○ Source/Dest Port
○ Network interface that a packet comes in or out of the
system on.
○ You can make simple rules, or more complex one by using
a one criteria like this:
▪ protocol: TCP, source IP: 8.1.3.4, dest port: 80
▪ This rule matches TCP packets from the IP address
8.1.3.4 address and are destined for port 80. If a
packet doesn’t match all three rules, it is not
considered a match and the packet is examined by
the next rule in the chain.

Firewall Targets

• The target section of a rule determines what happens to a packet that is

matched. The target can be:
o The name of a chain
o Built in target, which include:
▪ ACCEPT: Used to accept a packet and stop processing
rules in the chain
▪ DROP: Silently ignores the packet and stops processing the
rules in the chain.
▪ REJECT: Like the drop target except that it notifies the
sender the packet was not accepted.
▪ LOG: Use the log target to log the packet using the system
logger and continue processing rules in the chain
▪ RETURN: Causes the current packet to stop travelling
through the current chain. If this happens in a subchain, the
packet returns to the calling chain. If the packet is in the
main chain, like the INPUT chain, the default policy of that
chain will be applied.