3.12 Configuring Access to Network Services

3.12.1 Configuring and Using Packet-filtering Firewalls
3.12.2 Configuring and Using TCP Wrappers

As networks are usually the primary point of entry point into IT systems, you can use network intrusion prevention and detection tools to help avert or uncover a security breach. You can then take steps such as disabling unused network services and configure a packet-filtering firewall and TCP wrappers.

There are several open-source tools for performing packet logging and analysis. For example, tcpdump and Snort capture TCP traffic and analyze it for suspicious usage patterns, such as those that typically occur with port scans or network DoS attacks. Sguil incorporates tcpdump, Snort, and the Wireshark protocol analyzer to provide a network intrusion and detection system that simplifies log analysis and reporting.

You can check what services are running on a system by using port scanning utilities. The following examples show the information that the netstat, lsof, and nmap commands return about open TCP ports and the associated services:

# netstat -tulp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address             Foreign Address   State    PID/Program name
tcp        0      0 localhost:ipp             *:*               LISTEN   1657/cupsd       
tcp        0      0 localhost:smtp            *:*               LISTEN   1987/master      
tcp        0      0 localhost:29754           *:*               LISTEN   2072/vpnagentd   
tcp        0      0 *:amqp                    *:*               LISTEN   2030/qpidd       
tcp        0      0 *:56652                   *:*               LISTEN   1605/rpc.statd   
tcp        0      0 *:sunrpc                  *:*               LISTEN   1542/rpcbind     
tcp        0      0 *:ssh                     *:*               LISTEN   1887/sshd        
tcp        0      0 localhost:ipp             *:*               LISTEN   1657/cupsd       
tcp        0      0 localhost:smtp            *:*               LISTEN   1987/master      
tcp        0      0 *:45534                   *:*               LISTEN   1605/rpc.statd   
tcp        0      0 *:amqp                    *:*               LISTEN   2030/qpidd       
tcp        0      0 *:sunrpc                  *:*               LISTEN   1542/rpcbind     
tcp        0      0 localhost:47314           *:*               LISTEN   2873/java        
tcp        0      0 *:ssh                     *:*               LISTEN   1887/sshd        
udp        0      0 *:bootpc                  *:*                        1584/dhclient    
udp        0      0 *:44127                   *:*                        1605/rpc.statd   
udp        0      0 *:sunrpc                  *:*                        1542/rpcbind     
udp        0      0 10.0.2.15:ntp             *:*                        1895/ntpd        
udp        0      0 localhost:ntp             *:*                        1895/ntpd        
udp        0      0 *:ntp                     *:*                        1895/ntpd        
udp        0      0 *:mdns                    *:*                        1580/avahi-daemon
udp        0      0 *:ipp                     *:*                        1657/cupsd       
udp        0      0 *:869                     *:*                        1542/rpcbind     
udp        0      0 *:33669                   *:*                        1580/avahi-daemon
udp        0      0 *:933                     *:*                        1605/rpc.statd   
udp        0      0 *:sunrpc                  *:*                        1542/rpcbind     
udp        0      0 localhost:ntp             *:*                        1895/ntpd        
udp        0      0 fe80::a00:27ff:fe16:c333:ntp *:*                     1895/ntpd        
udp        0      0 *:ntp                     *:*                        1895/ntpd        
udp        0      0 *:44822                   *:*                        1605/rpc.statd   
udp        0      0 *:869                     *:*                        1542/rpcbind     

# lsof -iTCP -sTCP:LISTEN
COMMAND    PID    USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
rpcbind   1542     rpc    8u  IPv4  11032      0t0  TCP *:sunrpc (LISTEN)
rpcbind   1542     rpc   11u  IPv6  11037      0t0  TCP *:sunrpc (LISTEN)
rpc.statd 1605 rpcuser    9u  IPv4  11201      0t0  TCP *:56652 (LISTEN)
rpc.statd 1605 rpcuser   11u  IPv6  11207      0t0  TCP *:45534 (LISTEN)
cupsd     1657    root    6u  IPv6  12375      0t0  TCP localhost:ipp (LISTEN)
cupsd     1657    root    7u  IPv4  12376      0t0  TCP localhost:ipp (LISTEN)
sshd      1887    root    3u  IPv4  13541      0t0  TCP *:ssh (LISTEN)
sshd      1887    root    4u  IPv6  13543      0t0  TCP *:ssh (LISTEN)
master    1987    root   12u  IPv4  13081      0t0  TCP localhost:smtp (LISTEN)
master    1987    root   13u  IPv6  13083      0t0  TCP localhost:smtp (LISTEN)
qpidd     2030   qpidd   10u  IPv4  13257      0t0  TCP *:amqp (LISTEN)
qpidd     2030   qpidd   11u  IPv6  13258      0t0  TCP *:amqp (LISTEN)
vpnagentd 2072    root   15u  IPv4  13823      0t0  TCP localhost:29754 (LISTEN)
java      2873   guest    7u  IPv6  20694      0t0  TCP localhost:47314 (LISTEN)

# nmap -sTU 10.0.2.15

Starting Nmap 5.51 ( http://nmap.org ) at 2012-12-10 09:37 GMT
Nmap scan report for 10.0.2.15
Host is up (0.0017s latency).
Not shown: 1993 closed ports
PORT     STATE         SERVICE
22/tcp   open          ssh
111/tcp  open          rpcbind
68/udp   open|filtered dhcpc
111/udp  open          rpcbind
123/udp  open          ntp
631/udp  open|filtered ipp
5353/udp open|filtered zeroconf

Nmap done: 1 IP address (1 host up) scanned in 12.66 seconds

For more information, see the lsof(8), netstat(8), and nmap(1) manual pages.

Caution

Before installing or using the nmap command, check the local legislation relating to port scanning software. In some jurisdictions, the possession or use of port scanning software is considered as unlawful criminal activity. Some ISPs might also have acceptable use policies that forbid using such software outside of your private networks.

3.12.1 Configuring and Using Packet-filtering Firewalls

A packet filtering firewall filters incoming and outgoing network packets based on the packet header information. You can create packet filter rules that determine whether packets are accepted or rejected. For example, if you create a rule to block a port, any request is made to that port that is blocked by the firewall, and the request is ignored. Any service that is listening on a blocked port is effectively disabled.

The Oracle Linux kernel uses the Netfilter feature to provide packet filtering functionality for IPv4 and IPv6 packets respectively.

Netfilter consist of two components:

  • A netfilter kernel component consisting of a set of tables in memory for the rules that the kernel uses to control network packet filtering.

  • The iptables and ip6tables utilities to create, maintain, and display the rules that netfilter stores.

To implement a simple, general-purpose firewall, you can use the Firewall Configuration GUI (system-config-firewall) to create basic Netfilter rules. To create a more complex firewall configuration, use the iptables and ip6tables utilities to configure the packet filtering rules.

Netfilter records the packet filtering rules in the /etc/sysconfig/iptables and /etc/sysconfig/ip6tables files, which netfilter reads when it is initialized.

The netfilter tables include:

Filter

The default table, which is mainly used to drop or accept packets based on their content.

Mangle

This table is used to alter certain fields in a packet.

NAT

The Network Address Translation table is used to route packets that create new connections.

The kernel uses the rules stored in these tables to make decisions about network packet filtering. Each rule consists of one or more criteria and a single action. If a criterion in a rule matches the information in a network packet header, the kernel applies the action to the packet. Examples of actions include:

ACCEPT

Continue processing the packet.

DROP

End the packet’s life without notice.

REJECT

As DROP, and additionally notify the sending system that the packet was blocked.

Rules are stored in chains, where each chain is composed of a default policy plus zero or more rules. The kernel applies each rule in a chain to a packet until a match is found. If there is no matching rule, the kernel applies the chain’s default action (policy) to the packet.

Each netfilter table has several predefined chains. The filter table contains the following chains:

FORWARD

Packets that are not addressed to the local system pass through this chain.

INPUT

Inbound packets to the local system pass through this chain.

OUTPUT

Locally created packets pass through this chain.

The chains are permanent and you cannot delete them. However, you can create additional chains in the filter table.

For more information, see the iptables(8) and ip6tables(8) manual pages.

3.12.1.1 Listing Firewall Rules

Use the iptables -L command to list firewall rules for the chains of the filter table. The following example shows the default rules for a newly installed system:

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source       destination         
ACCEPT     all  --  anywhere     anywhere        state RELATED,ESTABLISHED 
ACCEPT     icmp --  anywhere     anywhere            
ACCEPT     all  --  anywhere     anywhere            
ACCEPT     tcp  --  anywhere     anywhere        state NEW tcp dpt:ssh 
ACCEPT     udp  --  anywhere     anywhere        state NEW udp dpt:ipp 
ACCEPT     udp  --  anywhere     224.0.0.251     state NEW udp dpt:mdns 
ACCEPT     tcp  --  anywhere     anywhere        state NEW tcp dpt:ipp 
ACCEPT     udp  --  anywhere     anywhere        state NEW udp dpt:ipp 
REJECT     all  --  anywhere     anywhere        reject-with icmp-host-prohibited 

Chain FORWARD (policy ACCEPT)
target     prot opt source       destination         
REJECT     all  --  anywhere     anywhere        reject-with icmp-host-prohibited 

Chain OUTPUT (policy ACCEPT)
target     prot opt source       destination

In this example, the default policy for each chain is ACCEPT. A more secure system could have a default policy of DROP, and the additional rules would only allow specific packets on a case-by-case basis.

If you want to modify the chains, specify the --line-numbers option to see how the rules are numbered.

# iptables -L --line-numbers
Chain INPUT (policy ACCEPT)
num  target     prot opt source           destination         
1    ACCEPT     all  --  anywhere         anywhere        state RELATED,ESTABLISHED 
2    ACCEPT     icmp --  anywhere         anywhere            
3    ACCEPT     all  --  anywhere         anywhere            
4    ACCEPT     tcp  --  anywhere         anywhere        state NEW tcp dpt:ssh 
5    ACCEPT     udp  --  anywhere         anywhere        state NEW udp dpt:ipp 
6    ACCEPT     udp  --  anywhere         224.0.0.251     state NEW udp dpt:mdns 
7    ACCEPT     tcp  --  anywhere         anywhere        state NEW tcp dpt:ipp 
8    ACCEPT     udp  --  anywhere         anywhere        state NEW udp dpt:ipp 
9    REJECT     all  --  anywhere         anywhere        reject-with icmp-host-prohibited 

Chain FORWARD (policy ACCEPT)
num  target     prot opt source           destination         
1    REJECT     all  --  anywhere         anywhere        reject-with icmp-host-prohibited 

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source           destination

3.12.1.2 Inserting Rules in a Chain

Use the iptables -I command to insert a rule in a chain. For example, the following command inserts a rule in the INPUT chain to allow access by TCP on port 80:

# iptables -I INPUT 4 -p tcp -m tcp --dport 80 -j ACCEPT
# iptables -L --line-numbers
Chain INPUT (policy ACCEPT)
num  target     prot opt source           destination         
1    ACCEPT     all  --  anywhere         anywhere        state RELATED,ESTABLISHED 
2    ACCEPT     icmp --  anywhere         anywhere            
3    ACCEPT     all  --  anywhere         anywhere            
4    ACCEPT     tcp  --  anywhere         anywhere        tcp dpt:http 
5    ACCEPT     tcp  --  anywhere         anywhere        state NEW tcp dpt:ssh 
6    ACCEPT     udp  --  anywhere         anywhere        state NEW udp dpt:ipp 
7    ACCEPT     udp  --  anywhere         224.0.0.251     state NEW udp dpt:mdns 
8    ACCEPT     tcp  --  anywhere         anywhere        state NEW tcp dpt:ipp 
9    ACCEPT     udp  --  anywhere         anywhere        state NEW udp dpt:ipp 
10   REJECT     all  --  anywhere         anywhere        reject-with icmp-host-prohibited 

Chain FORWARD (policy ACCEPT)
num  target     prot opt source           destination         
1    REJECT     all  --  anywhere         anywhere        reject-with icmp-host-prohibited 

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source           destination

The output from iptables -L shows that the new entry has been inserted as rule 4, and the old rules 4 through 9 are pushed down to positions 5 through 10. The TCP destination port of 80 is represented as http, which corresponds to the following definition in the /etc/services file (the HTTP daemon listens for client requests on port 80):

http            80/tcp          www www-http    # WorldWideWeb HTTP

3.12.1.3 Deleting Rules in a Chain

Use the iptables -D command to delete a rule in a chain. For example, the following command deletes rule 4 from the INPUT chain:

# iptables -D INPUT 4

3.12.2 Configuring and Using TCP Wrappers

TCP wrappers provide basic filtering of incoming network traffic. You can allow or deny access from other systems to certain wrapped network services running on a Linux server. A wrapped network service is one that has been compiled against the libwrap.a library. You can use the ldd command to determine if a network service has been wrapped as shown in the following example for the sshd daemon:

# ldd /usr/sbin/sshd | grep libwrap
	libwrap.so.0 => /lib64/libwrap.so.0 (0x00007f877de07000)

When a remote client attempts to connect to a network service on the system, the wrapper consults the rules in the configuration files /etc/hosts.allow and /etc/hosts.deny files to determine if access is permitted.

The wrapper for a service first reads /etc/hosts.allow from top to bottom. If the daemon and client combination matches an entry in the file, access is allowed. If the wrapper does not find a match in /etc/hosts.allow, it reads /etc/hosts.deny from top to bottom. If the daemon and client combination matches and entry in the file, access is denied. If no rules for the daemon and client combination are found in either file, or if neither file exists, access to the service is allowed.

The wrapper first applies the rules specified in /etc/hosts.allow, so these rules take precedence over the rules specified in /etc/hosts.deny. If a rule defined in /etc/hosts.allow permits access to a service, any rule in /etc/hosts.deny that forbids access to the same service is ignored.

The rules take the following form:

daemon_list : client_list [: command] [: deny]

where daemon_list and client_list are comma-separated lists of daemons and clients, and the optional command is run when a client tries to access a daemon. You can use the keyword ALL to represent all daemons or all clients. Subnets can be represented by using the * wildcard, for example 192.168.2.*. Domains can be represented by prefixing the domain name with a period (.), for example .mydomain.com. The optional deny keyword causes a connection to be denied even for rules specified in the /etc/hosts.allow file.

The following are some sample rules.

Match all clients for scp, sftp, and ssh access (sshd).

sshd : ALL

Match all clients on the 192.168.2 subnet for FTP access (vsftpd).

vsftpd : 192.168.2.*

Match all clients in the mydomain.com domain for access to all wrapped services.

ALL : .mydomain.com

Match all clients for FTP access, and displays the contents of the banner file /etc/banners/vsftpd (the banner file must have the same name as the daemon).

vsftpd : ALL : banners /etc/banners/

Match all clients on the 200.182.68 subnet for all wrapped services, and logs all such events. The %c and %d tokens are expanded to the names of the client and the daemon.

ALL : 200.182.68.* : spawn /bin/echo `date` “Attempt by %c to connect to %d" >> /var/log/tcpwr.log

Match all clients for scp, sftp, and ssh access, and logs the event as an emerg message, which is displayed on the console.

sshd : ALL : severity emerg

Match all clients in the forbid.com domain for scp, sftp, and ssh access, logs the event, and deny access (even if the rule appears in /etc/hosts.allow).

sshd : .forbid.com : spawn /bin/echo `date` "sshd access denied for %c" >>/var/log/sshd.log : deny

For more information, see the hosts_access(5) manual page.