Show Table of Contents
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.
126.96.36.199. 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
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/vsftpdand 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.
%ctoken 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
vsftpd : ALL : banners /etc/banners/
188.8.131.52. 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
In this example, assume that a cracker from the 184.108.40.206/24 network has been detected attempting to attack the server. Place the following line in the
/etc/hosts.denyfile to deny any connection attempts from that network, and to log the attempts to a special file:
ALL : 220.127.116.11 : spawn /bin/echo `date` %c %d >> /var/log/intruder_alert
%dtoken supplies the name of the service that the attacker was trying to access.
To allow the connection and log it, place the
spawndirective in the
spawndirective 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.
18.104.22.168. 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
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
emergflag in the log files instead of the default flag,
info, and deny the connection.
To do this, place the following line in
in.telnetd : ALL : severity emerg
This uses the default
authprivlogging facility, but elevates the priority from the default value of
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
rootto determine which ports are listening for connections from the network:
netstat -pan -A inet,inet6 | grep -v ESTABLISHEDActive 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 ...
-loption of the
netstatcommand to display only listening server sockets:
netstat -tlnwActive 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
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 -tlwetid 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,sctpNetid 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))
UNCONNstate 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
-6option 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 192.168.122.65Starting 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
The TCP connect scan
(-sT)is the default TCP scan type when the TCP SYN scan
(-sS)is not an option. The
-Ooption 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
netstat -plnSActive 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 2500sctp 0.0.0.0:2500 LISTEN
The ss utility is also able to show SCTP open ports:
ss -an | grep 2500sctp 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.
accept_source_routeoption 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
0value 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.conffile. For example, to disable acceptance of all IPv4 ICMP redirected packets on all interfaces, open the
/etc/sysctl.conffile with an editor running as the
rootuser 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.
22.214.171.124. 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
IPaddresses 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
sysctlutility can be used to make changes to the running system, and permanent changes can be made by adding lines to the
rp_filteroption is used to direct the kernel to select from one of three modes.To make a temporary global change, enter the following commands as
sysctl -w net.ipv4.conf.default.rp_filter=integer sysctl -w net.ipv4.conf.all.rp_filter=integerwhere integer is one of the following:
The setting can be overridden per network interface using the
0— No source validation.
1— Strict mode as defined in RFC 3704.
2— Loose mode as defined in RFC 3704.
net.ipv4.conf.interface.rp_filtercommand as follows:
sysctl -w net.ipv4.conf.interface.rp_filter=integer
NoteTo make these settings persistent across reboots, modify the
/etc/sysctl.conffile. For example, to change the mode for all interfaces, open the
/etc/sysctl.conffile with an editor running as the
rootuser and add a line as follows:
- In case of the
IPv6protocol the firewalld daemon applies to Reverse Path Forwarding by default. The setting can be checked in the
/etc/firewalld/firewalld.conffile. You can change the firewalld behavior by setting the
IPv6_rpfilteroption.If you need a custom configuration of Reverse Path Forwarding, you can perform it without the firewalld daemon by using the
ip6tablescommand as follows:
ip6tables -t raw -I PREROUTING -m rpfilter --invert -j DROPThis 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
ip6tablesservices, see Section 5.13, “Setting and Controlling IP sets using
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
rootand change the line which reads
net.ipv4.ip_forward = 0in the
/etc/sysctl.conffile to the following:
net.ipv4.ip_forward = 1
To load the changes from the
/etc/sysctl.conffile, enter the following command:
To check if IP forwarding is turned on, issue the following command as
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
126.96.36.199. 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
yum install kernel-doc
- Online DocumentationSee RFC 3704 for an explanation of Ingress Filtering for Multihomed Networks.