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 -tulpActive 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:LISTENCOMMAND 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.15Starting 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.
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.
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:
FilterThe default table, which is mainly used to drop or accept packets based on their content.
MangleThis table is used to alter certain fields in a packet.
NATThe 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:
ACCEPTContinue processing the packet.
DROPEnd the packet’s life without notice.
REJECTAs 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:
FORWARDPackets that are not addressed to the local system pass through this chain.
INPUTInbound packets to the local system pass through this chain.
OUTPUTLocally 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.
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 destinationIn 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 destinationUse 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-numbersChain 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
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/tcpwrappers.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 forbidden.com domain for
scp, sftp, and ssh access, logs
the event, and deny access (even if the rule appears in
/etc/hosts.allow).
sshd : .forbidden.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.