4.4. Securing Network Access

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 ftp.example.com 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

Unnecessary open ports should be avoided because it increases the attack surface of your system. If you find unexpected open ports in listening state after the system has been in service, it might be a sign of intrusion, and it should be investigated.
Issue 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
tcp        0      0*          LISTEN    1/systemd
tcp        0      0*          LISTEN    1975/dnsmasq
tcp        0      0*          LISTEN    1362/sshd
tcp        0      0*          LISTEN    1355/cupsd
tcp        0      0*          LISTEN    1802/master
tcp6       0      0 ::1:111             :::*               LISTEN    1/systemd
tcp6       0      0 :::22               :::*               LISTEN    1362/sshd
tcp6       0      0 ::1:631             :::*               LISTEN    1355/cupsd
tcp6       0      0 ::1:25              :::*               LISTEN    1802/master
raw6       0      0 :::58               :::*               7         791/NetworkManager
You can 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 ::1:111             :::*                LISTEN
tcp6       0      0 :::22               :::*                LISTEN
tcp6       0      0 ::1:631             :::*                LISTEN
tcp6       0      0 ::1:25              :::*                LISTEN
raw6       0      0 :::58               :::*                7
Note that at time of writing, the -l option does not list SCTP servers.
You can also use the ss utility for listing open ports in the listening state. But at time of writing, this way also does not list SCTP servers.
~]# ss -tlw
Netid  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              ::1:sunrpc               :::*
tcp    LISTEN     0      128               :::ssh                  :::*
tcp    LISTEN     0      128              ::1:ipp                  :::*
tcp    LISTEN     0      100              ::1:smtp                 :::*
Review the output of the command with the services needed on the system, turn off what is not specifically required or authorized, repeat the check. Proceed then to make external checks using the nmap tool from another system connected through the network to the first system. This can be used verify the rules in firewalld.
The following is an example of the command to be issued from the console of another system to determine which ports are listening for TCP connections from the network:
~]# nmap -sT -O
See the 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 Route (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
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.
In order to make the settings permanent they must be added to /etc/sysctl.conf.
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.

4.4.4. 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 4.5.4, “Using the iptables Service”. 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 /proc/sys/net/ipv4/ 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.