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. 4.4.1.1. 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/ 4.4.1.2. 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 206.182.68.0/24 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 : 206.182.68.0 : 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. Note 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. 4.4.1.3. 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: Use the -l option of the netstat command to display only listening server sockets: 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 . 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 127.0.0.0 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: 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 : The ss utility is also able to show SCTP open ports: 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: 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: These commands disable forwarding of all multicast packets on all interfaces: 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: This command disables acceptance of secure ICMP redirected packets on all interfaces: This command disables acceptance of all IPv4 ICMP redirected packets on all interfaces: Important 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: 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. Note 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: net.ipv4.conf.all.send_redirects=0 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. Warning 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.3.1. 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. Note 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 .. Warning 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). rp_filter 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 : 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 Note 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: net.ipv4.conf.all.rp_filter=2 IPv6_rpfilter 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: To load the changes from the /etc/sysctl.conf file, enter the following command: To check if IP forwarding is turned on, issue the following command as root : 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: 4.4.3.2. 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 : Online Documentation See RFC 3704 for an explanation of Ingress Filtering for Multihomed Networks.

Commands:
220-Hello, %c 220-All activity on ftp.example.com is logged. 220-Inappropriate use will result in your access privileges being removed.
vsftpd : ALL : banners /etc/banners/
ALL : 206.182.68.0 : spawn /bin/echo `date` %c %d >> /var/log/intruder_alert
in.telnetd : ALL : severity emerg
~]# 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 0.0.0.0:111 0.0.0.0:* LISTEN 1/systemd tcp 0 0 192.168.124.1:53 0.0.0.0:* LISTEN 1829/dnsmasq tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1176/sshd tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 1177/cupsd tcp6 0 0 :::111 :::* LISTEN 1/systemd tcp6 0 0 ::1:25 :::* LISTEN 1664/master sctp 0.0.0.0:2500 LISTEN 20985/sctp_darn udp 0 0 192.168.124.1:53 0.0.0.0:* 1829/dnsmasq udp 0 0 0.0.0.0:67 0.0.0.0:* 977/dhclient
~]# netstat -tlnw Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN tcp 0 0 192.168.124.1:53 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:25 0.0.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
~]# 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 192.168.124.1:domain *:* tcp LISTEN 0 128 *:ssh *:* tcp LISTEN 0 128 127.0.0.1:ipp *:* tcp LISTEN 0 100 127.0.0.1:smtp *:* 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 192.168.124.1:53 *:* 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 192.168.124.1:53 *:* users:(("dnsmasq",pid=1829,fd=6)) tcp LISTEN 0 128 *:22 *:* users:(("sshd",pid=1176,fd=3)) tcp LISTEN 0 128 127.0.0.1:631 *:* users:(("cupsd",pid=1177,fd=12)) tcp LISTEN 0 100 127.0.0.1:25 *:* users:(("master",pid=1664,fd=13)) sctp LISTEN 0 5 *:2500 *:* users:(("sctp_darn",pid=20985,fd=3))
~]# nmap -sT -O 192.168.122.65 Starting Nmap 6.40 ( http://nmap.org ) at 2017-03-27 09:30 CEST Nmap scan report for 192.168.122.65 Host is up (0.00032s latency). Not shown: 998 closed ports PORT STATE SERVICE 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 http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 1.79 seconds
~]# netstat -plnS Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name sctp 127.0.0.1:250 LISTEN 4125/sctp_darn sctp 0 0 127.0.0.1:260 127.0.0.1:250 CLOSE 4250/sctp_darn sctp 0 0 127.0.0.1:250 127.0.0.1:260 LISTEN 4125/sctp_darn
~]# netstat -nl -A inet,inet6 | grep 2500 sctp 0.0.0.0:2500 LISTEN
~]# ss -an | grep 2500 sctp LISTEN 0 5 *:2500 *:*
~]# /sbin/sysctl -w net.ipv4.conf.all.accept_source_route=0
~]# /sbin/sysctl -w net.ipv4.conf.all.forwarding=0
~]# /sbin/sysctl -w net.ipv6.conf.all.forwarding=0
~]# /sbin/sysctl -w net.ipv4.conf.all.mc_forwarding=0
~]# /sbin/sysctl -w net.ipv6.conf.all.mc_forwarding=0
~]# /sbin/sysctl -w net.ipv4.conf.all.accept_redirects=0
~]# /sbin/sysctl -w net.ipv6.conf.all.accept_redirects=0
~]# /sbin/sysctl -w net.ipv4.conf.all.secure_redirects=0
~]# /sbin/sysctl -w net.ipv4.conf.all.send_redirects=0
~]# /sbin/sysctl -w net.ipv4.conf.default.send_redirects=0
sysctl -w net.ipv4.conf.default.rp_filter= integer sysctl -w net.ipv4.conf.all.rp_filter= integer
net.ipv4.ip_forward = 1
/sbin/sysctl -p
/sbin/sysctl net.ipv4.ip_forward
/sbin/sysctl -w net.ipv4.ip_forward=1
~]# yum install kernel-doc