4.4. Securing Network Access

download PDF

4.4.1. Securing Services With TCP Wrappers and xinetd

TCP Wrappers are capable of much more than denying access to services. This section illustrates how they can be used to send connection banners, warn of attacks from particular hosts, and enhance logging functionality. See the hosts_options(5) man page for information about the TCP Wrapper functionality and control language. See the xinetd.conf(5) man page for the available flags, which act as options you can apply to a service. TCP Wrappers and Connection Banners

Displaying a suitable banner when users connect to a service is a good way to let potential attackers know that the system administrator is being vigilant. You can also control what information about the system is presented to users. To implement a TCP Wrappers banner for a service, use the banner option.
This example implements a banner for vsftpd. To begin, create a banner file. It can be anywhere on the system, but it must have same name as the daemon. For this example, the file is called /etc/banners/vsftpd and contains the following lines:
220-Hello, %c
220-All activity on is logged.
220-Inappropriate use will result in your access privileges being removed.
The %c token supplies a variety of client information, such as the user name and host name, or the user name and IP address to make the connection even more intimidating.
For this banner to be displayed to incoming connections, add the following line to the /etc/hosts.allow file:
vsftpd : ALL : banners /etc/banners/ TCP Wrappers and Attack Warnings

If a particular host or network has been detected attacking the server, TCP Wrappers can be used to warn the administrator of subsequent attacks from that host or network using the spawn directive.
In this example, assume that a cracker from the network has been detected attempting to attack the server. Place the following line in the /etc/hosts.deny file to deny any connection attempts from that network, and to log the attempts to a special file:
ALL : : spawn /bin/echo `date` %c %d >> /var/log/intruder_alert
The %d token supplies the name of the service that the attacker was trying to access.
To allow the connection and log it, place the spawn directive in the /etc/hosts.allow file.


Because the spawn directive executes any shell command, it is a good idea to create a special script to notify the administrator or execute a chain of commands in the event that a particular client attempts to connect to the server. TCP Wrappers and Enhanced Logging

If certain types of connections are of more concern than others, the log level can be elevated for that service using the severity option.
For this example, assume that anyone attempting to connect to port 23 (the Telnet port) on an FTP server is a cracker. To denote this, place an emerg flag in the log files instead of the default flag, info, and deny the connection.
To do this, place the following line in /etc/hosts.deny:
in.telnetd : ALL : severity emerg
This uses the default authpriv logging facility, but elevates the priority from the default value of info to emerg, which posts log messages directly to the console.

4.4.2. Verifying Which Ports Are Listening

It is important to close unused ports to avoid possible attacks. For unexpected ports in listening state, you should investigate for possible signs of intrusion.

Using netstat for Open Ports Scan

Enter the following command as root to determine which ports are listening for connections from the network:
~]# netstat -pan -A inet,inet6 | grep -v ESTABLISHED
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address       Foreign Address    State     PID/Program name
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0   *               LISTEN      1/systemd
tcp        0      0*               LISTEN      1829/dnsmasq
tcp        0      0    *               LISTEN      1176/sshd
tcp        0      0 *               LISTEN      1177/cupsd
tcp6       0      0 :::111                  :::*                    LISTEN      1/systemd
tcp6       0      0 ::1:25                  :::*                    LISTEN      1664/master
sctp                                          LISTEN   20985/sctp_darn
udp        0      0*                           1829/dnsmasq
udp        0      0    *                           977/dhclient
Use the -l option of the netstat command to display only listening server sockets:
~]# netstat -tlnw
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0   *               LISTEN
tcp        0      0*               LISTEN
tcp        0      0    *               LISTEN
tcp        0      0 *               LISTEN
tcp        0      0  *               LISTEN
tcp6       0      0 :::111                  :::*                    LISTEN
tcp6       0      0 :::22                   :::*                    LISTEN
tcp6       0      0 ::1:631                 :::*                    LISTEN
tcp6       0      0 ::1:25                  :::*                    LISTEN
raw6       0      0 :::58                   :::*                    7

Using ss for Open Ports Scan

Alternatively, use the ss utility to list open ports in the listening state. It can display more TCP and state information than netstat.
~]# ss -tlw
etid State      Recv-Q Send-Q     Local Address:Port                      Peer Address:Port
udp   UNCONN     0      0                     :::ipv6-icmp                           :::*
tcp   LISTEN     0      128                    *:sunrpc                               *:*
tcp   LISTEN     0      5                               *:*
tcp   LISTEN     0      128                    *:ssh                                  *:*
tcp   LISTEN     0      128                                    *:*
tcp   LISTEN     0      100                                   *:*
tcp   LISTEN     0      128                   :::sunrpc                              :::*
tcp   LISTEN     0      128                   :::ssh                                 :::*
tcp   LISTEN     0      128                  ::1:ipp                                 :::*
tcp   LISTEN     0      100                  ::1:smtp                                :::*
~]# ss -plno -A tcp,udp,sctp
Netid State      Recv-Q Send-Q       Local Address:Port                      Peer Address:Port
udp   UNCONN     0      0                                     *:*                   users:(("dnsmasq",pid=1829,fd=5))
udp   UNCONN     0      0                 *%virbr0:67                                   *:*                   users:(("dnsmasq",pid=1829,fd=3))
udp   UNCONN     0      0                        *:68                                   *:*                   users:(("dhclient",pid=977,fd=6))
tcp   LISTEN     0      5                                     *:*                   users:(("dnsmasq",pid=1829,fd=6))
tcp   LISTEN     0      128                      *:22                                   *:*                   users:(("sshd",pid=1176,fd=3))
tcp   LISTEN     0      128                                      *:*                   users:(("cupsd",pid=1177,fd=12))
tcp   LISTEN     0      100                                       *:*                   users:(("master",pid=1664,fd=13))
sctp  LISTEN     0      5                        *:2500                                 *:*                   users:(("sctp_darn",pid=20985,fd=3))
The UNCONN state shows the ports in UDP listening mode.
Make a scan for every IP address shown in the ss output (except for localhost or ::1 range) from an external system. Use the -6 option for scanning an IPv6 address.
Proceed then to make external checks using the nmap tool from another remote machine connected through the network to the first system. This can be used to verify rules in firewalld. The following is an example to determine which ports are listening for TCP connections:
~]# nmap -sT -O
    Starting Nmap 6.40 ( ) at 2017-03-27 09:30 CEST
    Nmap scan report for
    Host is up (0.00032s latency).
    Not shown: 998 closed ports
    22/tcp  open  ssh
    111/tcp open  rpcbind
    Device type: general purpose
    Running: Linux 3.X
    OS CPE: cpe:/o:linux:linux_kernel:3
    OS details: Linux 3.7 - 3.9
    Network Distance: 0 hops

    OS detection performed. Please report any incorrect results at .
    Nmap done: 1 IP address (1 host up) scanned in 1.79 seconds
The TCP connect scan (-sT) is the default TCP scan type when the TCP SYN scan (-sS) is not an option. The -O option detects the operating system of the host.

Using netstat and ss to Scan for Open SCTP Ports

The netstat utility prints information about the Linux networking subsystem. To display protocol statistics for open Stream Control Transmission Protocol (SCTP) ports, enter the following command as root:
~]# netstat -plnS
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address   Foreign Address  State    PID/Program name
sctp                          LISTEN   4125/sctp_darn
sctp       0      0    CLOSE    4250/sctp_darn
sctp       0      0    LISTEN   4125/sctp_darn
~]# netstat -nl -A inet,inet6 | grep 2500
sctp                                          LISTEN
The ss utility is also able to show SCTP open ports:
~]# ss -an | grep 2500
sctp   LISTEN     0      5         *:2500                  *:*
See the ss(8), netstat(8), nmap(1), and services(5) manual pages for more information.

4.4.3. Disabling Source Routing

Source routing is an Internet Protocol mechanism that allows an IP packet to carry information, a list of addresses, that tells a router the path the packet must take. There is also an option to record the hops as the route is traversed. The list of hops taken, the "route record", provides the destination with a return path to the source. This allows the source (the sending host) to specify the route, loosely or strictly, ignoring the routing tables of some or all of the routers. It can allow a user to redirect network traffic for malicious purposes. Therefore, source-based routing should be disabled.
The accept_source_route option causes network interfaces to accept packets with the Strict Source Routing (SSR) or Loose Source Routing (LSR) option set. The acceptance of source routed packets is controlled by sysctl settings. Issue the following command as root to drop packets with the SSR or LSR option set:
~]# /sbin/sysctl -w net.ipv4.conf.all.accept_source_route=0
Disabling the forwarding of packets should also be done in conjunction with the above when possible (disabling forwarding may interfere with virtualization). Issue the commands listed below as root:
These commands disable forwarding of IPv4 and IPv6 packets on all interfaces:
~]# /sbin/sysctl -w net.ipv4.conf.all.forwarding=0
~]# /sbin/sysctl -w net.ipv6.conf.all.forwarding=0
These commands disable forwarding of all multicast packets on all interfaces:
~]# /sbin/sysctl -w net.ipv4.conf.all.mc_forwarding=0
~]# /sbin/sysctl -w net.ipv6.conf.all.mc_forwarding=0
Accepting ICMP redirects has few legitimate uses. Disable the acceptance and sending of ICMP redirected packets unless specifically required.
These commands disable acceptance of all ICMP redirected packets on all interfaces:
~]# /sbin/sysctl -w net.ipv4.conf.all.accept_redirects=0
~]# /sbin/sysctl -w net.ipv6.conf.all.accept_redirects=0
This command disables acceptance of secure ICMP redirected packets on all interfaces:
~]# /sbin/sysctl -w net.ipv4.conf.all.secure_redirects=0
This command disables acceptance of all IPv4 ICMP redirected packets on all interfaces:
~]# /sbin/sysctl -w net.ipv4.conf.all.send_redirects=0


Sending of ICMP redirects remains active if at least one of the net.ipv4.conf.all.send_redirects or net.ipv4.conf.interface.send_redirects options is set to enabled. Ensure that you set the net.ipv4.conf.interface.send_redirects option to the 0 value for every interface. To automatically disable sending of ICMP requests whenever you add a new interface, enter the following command:
~]# /sbin/sysctl -w net.ipv4.conf.default.send_redirects=0
There is only a directive to disable sending of IPv4 redirected packets. See RFC4294 for an explanation of IPv6 Node Requirements which resulted in this difference between IPv4 and IPv6.


To make these settings persistent across reboots, modify the /etc/sysctl.conf file. For example, to disable acceptance of all IPv4 ICMP redirected packets on all interfaces, open the /etc/sysctl.conf file with an editor running as the root user and add a line as follows:
See the sysctl man page, sysctl(8), for more information. See RFC791 for an explanation of the Internet options related to source based routing and its variants.


Ethernet networks provide additional ways to redirect traffic, such as ARP or MAC address spoofing, unauthorized DHCP servers, and IPv6 router or neighbor advertisements. In addition, unicast traffic is occasionally broadcast, causing information leaks. These weaknesses can only be addressed by specific countermeasures implemented by the network operator. Host-based countermeasures are not fully effective. Reverse Path Forwarding

Reverse Path Forwarding is used to prevent packets that arrived through one interface from leaving through a different interface. When outgoing routes and incoming routes are different, it is sometimes referred to as asymmetric routing. Routers often route packets this way, but most hosts should not need to do this. Exceptions are such applications that involve sending traffic out over one link and receiving traffic over another link from a different service provider. For example, using leased lines in combination with xDSL or satellite links with 3G modems. If such a scenario is applicable to you, then turning off reverse path forwarding on the incoming interface is necessary. In short, unless you know that it is required, it is best enabled as it prevents users spoofing IP addresses from local subnets and reduces the opportunity for DDoS attacks.


Red Hat Enterprise Linux 7 defaults to using Strict Reverse Path Forwarding following the Strict Reverse Path recommendation from RFC 3704, Ingress Filtering for Multihomed Networks..


If forwarding is enabled, then Reverse Path Forwarding should only be disabled if there are other means for source-address validation (such as iptables rules for example).
Reverse Path Forwarding is enabled by means of the rp_filter directive. The sysctl utility can be used to make changes to the running system, and permanent changes can be made by adding lines to the /etc/sysctl.conf file. The rp_filter option is used to direct the kernel to select from one of three modes.
To make a temporary global change, enter the following commands as root:
sysctl -w  net.ipv4.conf.default.rp_filter=integer
sysctl -w net.ipv4.conf.all.rp_filter=integer
where integer is one of the following:
  • 0 — No source validation.
  • 1 — Strict mode as defined in RFC 3704.
  • 2 — Loose mode as defined in RFC 3704.
The setting can be overridden per network interface using the net.ipv4.conf.interface.rp_filter command as follows:
sysctl -w net.ipv4.conf.interface.rp_filter=integer


To make these settings persistent across reboots, modify the /etc/sysctl.conf file. For example, to change the mode for all interfaces, open the /etc/sysctl.conf file with an editor running as the root user and add a line as follows:
In case of the IPv6 protocol the firewalld daemon applies to Reverse Path Forwarding by default. The setting can be checked in the /etc/firewalld/firewalld.conf file. You can change the firewalld behavior by setting the IPv6_rpfilter option.
If you need a custom configuration of Reverse Path Forwarding, you can perform it without the firewalld daemon by using the ip6tables command as follows:
ip6tables -t raw -I PREROUTING -m rpfilter --invert -j DROP
This rule should be inserted near the beginning of the raw/PREROUTING chain, so that it applies to all traffic, in particular before the stateful matching rules. For more information about the iptables and ip6tables services, see Section 5.13, “Setting and Controlling IP sets using iptables.
Enabling Packet Forwarding
To enable packets arriving from outside of a system to be forwarded to another external host, IP forwarding must be enabled in the kernel. Log in as root and change the line which reads net.ipv4.ip_forward = 0 in the /etc/sysctl.conf file to the following:
net.ipv4.ip_forward = 1
To load the changes from the /etc/sysctl.conf file, enter the following command:
/sbin/sysctl -p
To check if IP forwarding is turned on, issue the following command as root:
/sbin/sysctl net.ipv4.ip_forward
If the above command returns a 1, then IP forwarding is enabled. If it returns a 0, then you can turn it on manually using the following command:
/sbin/sysctl -w net.ipv4.ip_forward=1 Additional Resources

The following are resources which explain more about Reverse Path Forwarding.
  • Installed Documentation
    /usr/share/doc/kernel-doc-version/Documentation/networking/ip-sysctl.txt - This file contains a complete list of files and options available in the directory. Before accessing the kernel documentation for the first time, enter the following command as root:
    ~]# yum install kernel-doc
  • Online Documentation
    See RFC 3704 for an explanation of Ingress Filtering for Multihomed Networks.
Red Hat logoGithubRedditYoutubeTwitter


Try, buy, & sell


About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.