Ce contenu n'est pas disponible dans la langue sélectionnée.
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:
~]# 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
...
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 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 :::* 7Using 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 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))
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:
~]# 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
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 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
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
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:
~]# /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.
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_filterdirective. Thesysctlutility can be used to make changes to the running system, and permanent changes can be made by adding lines to the/etc/sysctl.conffile. Therp_filteroption is used to direct the kernel to select from one of three modes.To make a temporary global change, enter the following commands asroot: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 thenet.ipv4.conf.interface.rp_filtercommand as follows:sysctl -w net.ipv4.conf.interface.rp_filter=integer
Note
To 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 therootuser and add a line as follows:net.ipv4.conf.all.rp_filter=2
-
IPv6_rpfilter - 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 theIPv6_rpfilteroption.If you need a custom configuration of Reverse Path Forwarding, you can perform it without the firewalld daemon by using theip6tablescommand 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 theiptablesandip6tablesservices, see Section 5.13, “Setting and Controlling IP sets usingiptables”.
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=14.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 asroot:~]#
yum install kernel-doc - Online DocumentationSee RFC 3704 for an explanation of Ingress Filtering for Multihomed Networks.
