Securing Net work Access

4.4.1. Securing Services Wit h T CP Wrappers and xinet d

TCP Wrappe rs are capable of much more than de nying acce s s to s e rvice s . This s e ction illus trate s how the y can be us e d to s e nd conne ction banne rs , warn of attacks from

particular hos ts , and e nhance logging functionality. Se e the hosts_options(5) man page for information about the TCP Wrappe r functionality and control language . Se e the

xinetd.conf(5) man page for the available flags , which act as options you can apply to a s e rvice .

4.4.1.1. T CP Wrappers and Connection Banners

Dis playing a s uitable banne r whe n us e rs conne ct to a s e rvice is a good way to le t pote ntial attacke rs know that the s ys te m adminis trator is be ing vigilant. You can als o control what information about the s ys te m is pre s e nte d to us e rs . To imple me nt a TCP Wrappe rs banne r for a s e rvice , us e the banner option.

This e xample imple me nts a banne r for vsftpd. To be gin, cre ate a banne r file . It can be anywhe re on the s ys te m, but it mus t have s ame name as the dae mon. For this e xample , the file is calle d /etc/banners/vsftpd and contains the following line s :

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 toke n s upplie s a varie ty of clie nt information, s uch as the us e rname and hos tname , or the us e rname and IP addre s s to make the conne ction e ve n more intimidating.

For this banne r to be dis playe d to incoming conne ctions , add the following line to the /etc/hosts.allow file :

vsftpd : ALL : banners /etc/banners/

4.4.1.2. T CP Wrappers and Attack Warnings

If a particular hos t or ne twork has be e n de te cte d attacking the s e rve r, TCP Wrappe rs can be us e d to warn the adminis trator of s ubs e que nt attacks from that hos t or ne twork us ing the spawn dire ctive .

In this e xample , as s ume that a cracke r from the 206.182.68.0/24 ne twork has be e n de te cte d atte mpting to attack the s e rve r. Place the following line in the /etc/hosts.deny file to de ny any conne ction atte mpts from that ne twork, and to log the atte mpts to a s pe cial file :

ALL : 206.182.68.0 : spawn /bin/echo `date` %c %d >>

/var/log/intruder_alert

The %d toke n s upplie s the name of the s e rvice that the attacke r was trying to acce s s . To allow the conne ction and log it, place the spawn dire ctive in the /etc/hosts.allow file .

Note

Be caus e the spawn dire ctive e xe cute s any s he ll command, it is a good ide a to cre ate a s pe cial s cript to notify the adminis trator or e xe cute a chain of commands in the e ve nt that a particular clie nt atte mpts to conne ct to the s e rve r.

4.4.1.3. T CP Wrappers and Enhanced Logging

If ce rtain type s of conne ctions are of more conce rn than othe rs , the log le ve l can be e le vate d for that s e rvice us ing the severity option.

For this e xample , as s ume that anyone atte mpting to conne ct to port 23 (the Te lne t port) on an FTP s e rve r is a cracke r. To de note this , place an emerg flag in the log file s ins te ad of the de fault flag, info, and de ny the conne ction.

To do this , place the following line in /etc/hosts.deny:

in.telnetd : ALL : severity emerg

This us e s the de fault authpriv logging facility, but e le vate s the priority from the de fault value of info to emerg, which pos ts log me s s age s dire ctly to the cons ole .

4.4.2. Verifying Which Port s Are List ening

Unne ce s s ary ope n ports s hould be avoide d be caus e it incre as e s the attack s urface of your s ys te m. If afte r the s ys te m has be e n in s e rvice you find une xpe cte d ope n ports in lis te ning s tate , that might be s igns of intrus ion and it s hould be inve s tigate d.

Is s ue the following command, as root, from the cons ole to de te rmine which ports are lis te ning for conne ctions from the ne twork:

~]# 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

tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 1608/rpcbind

tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 2581/unbound

tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 2048/sshd

tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 3202/cupsd

tcp 0 0 0.0.0.0:54136 0.0.0.0:* LISTEN 2279/rpc.statd

tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN

2708/master

udp6 0 0 :::33235 :::*

2279/rpc.statd

raw6 0 0 :::58 :::* 7 2612/NetworkManager

Note that at time of writing the -l option doe s not lis t SCTP s e rve rs .

Re vie w the output of the command with the s e rvice s ne e de d on the s ys te m, turn off what is not s pe cifically re quire d or authorize d, re pe at the che ck. Proce e d the n to make e xte rnal che cks us ing nmap from anothe r s ys te m conne cte d via the ne twork to the firs t s ys te m.

This can be us e d ve rify the rule s in ipt ables. Make a s can for e ve ry IP addre s s s hown in the ss output (e xce pt for localhos t 127.0.0.0 or ::1 range ) from an e xte rnal s ys te m. Us e the -6 option for s canning an IPv6 addre s s . Se e man nmap(1) for more information.

The following is an e xample of the command to be is s ue d from the cons ole of anothe r s ys te m to de te rmine which ports are lis te ning for TCP conne ctions from the ne twork:

~]# nmap -sT -O 192.168.122.1

Se e the man page s for ss, nmap, and services for more information.

4.4.3. Disabling Source Rout ing

Source routing is an Inte rne t Protocol me chanis m that allows an IP packe t to carry

information, a lis t of addre s s e s , that te lls a route r the path the packe t mus t take . The re is als o an option to re cord the hops as the route is trave rs e d. The lis t of hops take n, the

"route re cord", provide s the de s tination with a re turn path to the s ource . This allows the s ource (the s e nding hos t) to s pe cify the route , loos e ly or s trictly, ignoring the routing table s of s ome or all of the route rs . It can allow a us e r to re dire ct ne twork traffic for malicious purpos e s . The re fore , s ource -bas e d routing s hould be dis able d.

The accept_source_route option caus e s ne twork inte rface s to acce pt packe ts with the Strict Source Route (SSR) or Loose Source Routing (LSR) option s e t. The acce ptance of s ource route d packe ts is controlle d by s ys ctl s e ttings . Is s ue the following command as root to drop packe ts with the SSR or LSR option s e t:

~]# /sbin/sysctl -w net.ipv4.conf.all.accept_source_route=0

Dis abling the forwarding of packe ts s hould als o be done in conjunction with the above whe n pos s ible (dis abling forwarding may inte rfe re with virtualization). Is s ue the commands lis te d be low as root:

The s e commands dis able forwarding of IPv4 and IPv6 packe ts on all inte rface s .

~]# /sbin/sysctl -w net.ipv4.conf.all.forwarding=0

~]# /sbin/sysctl -w net.ipv6.conf.all.forwarding=0

The s e commands dis able forwarding of all multicas t packe ts on all inte rface s .

~]# /sbin/sysctl -w net.ipv4.conf.all.mc_forwarding=0

~]# /sbin/sysctl -w net.ipv6.conf.all.mc_forwarding=0

Acce pting ICMP re dire cts has fe w le gitimate us e s . Dis able the acce ptance and s e nding of ICMP re dire cte d packe ts unle s s s pe cifically re quire d.

The s e commands dis able acce ptance of all ICMP re dire cte d packe ts on all inte rface s .

~]# /sbin/sysctl -w net.ipv4.conf.all.accept_redirects=0

~]# /sbin/sysctl -w net.ipv6.conf.all.accept_redirects=0

This command dis able s acce ptance of s e cure ICMP re dire cte d packe ts on all inte rface s .

~]# /sbin/sysctl -w net.ipv4.conf.all.secure_redirects=0

This command dis able s acce ptance of all IPv4 ICMP re dire cte d packe ts on all inte rface s .

~]# /sbin/sysctl -w net.ipv4.conf.all.send_redirects=0

The re is only a dire ctive to dis able s e nding of IPv4 re dire cte d packe ts . Se e RFC4294 for an e xplanation of “IPv6 Node Re quire me nts ” which re s ulte d in this diffe re nce be twe e n IPv4 and IPv6.

In orde r to make the s e ttings pe rmane nt the y mus t be adde d to /etc/sysctl.conf.

Se e the s ys ctl man page , sysctl(8), for more information. Se e RFC791 for an e xplanation of the Inte rne t options re late d to s ource bas e d routing and its variants .

Warning

Ethe rne t ne tworks provide additional ways to re dire ct traffic, s uch as ARP or MAC addre s s s poofing, unauthorize d DHCP s e rve rs , and IPv6 route r or ne ighbor adve rtis e me nts . In addition, unicas t traffic is occas ionally broadcas t, caus ing information le aks . The s e we akne s s e s can only be addre s s e d by s pe cific counte rme as ure s imple me nte d by the ne twork ope rator. Hos t-bas e d counte rme as ure s are not fully e ffe ctive .

4.4.4. Reverse Pat h Forwarding

Re ve rs e Path Forwarding is us e d to pre ve nt packe ts that arrive d via one inte rface from le aving via a diffe re nt inte rface . Whe n outgoing route s and incoming route s are diffe re nt, it is s ome time s re fe rre d to as asymmetric routing. Route rs ofte n route packe ts this way, but mos t hos ts s hould not ne e d to do this . Exce ptions are s uch applications that involve s e nding traffic out ove r one link and re ce iving traffic ove r anothe r link from a diffe re nt s e rvice provide r. For e xample , us ing le as e d line s in combination with xDSL or s ate llite links with 3G mode ms . If s uch a s ce nario is applicable to you, the n turning off re ve rs e path forwarding on the incoming inte rface is ne ce s s ary. In s hort, unle s s you know that it is re quire d, it is be s t e nable d as it pre ve nts us e rs s poofing IP addre s s e s from local s ubne ts and re duce s the opportunity for DDoS attacks .

Note

Re d Hat Ente rpris e Linux 7 de faults to us ing Strict Reverse Path Forwarding following the Strict Re ve rs e Path re comme ndation from RFC 3704, Ingre s s Filte ring for

Multihome d Ne tworks . This curre ntly only applie s to IPv4.

Warning

If forwarding is e nable d, the n Re ve rs e Path Forwarding s hould only be dis able d if the re are othe r me ans for s ource -addre s s validation (s uch as ipt ables rule s for e xample ).

rp_filter

Re ve rs e Path Forwarding is e nable d by me ans of the rp_filter dire ctive . The rp_filter option is us e d to dire ct the ke rne l to s e le ct from one of thre e mode s . It take s the following form whe n s e tting the de fault be havior:

~]# /sbin/sysctl -w net.ipv4.conf.default.rp_filter=INTEGER whe re INTEGER is one of the following:

0 — No s ource validation.

1 — Strict mode as de fine d in RFC3704.

2 — Loos e mode as de fine d in RFC3704.

The s e tting can be ove rridde n pe r ne twork inte rface us ing

net.ipv4.interface.rp_filter. To make the s e s e ttings pe rs is te nt acros s re boot, modify the /etc/sysctl.conf file .

4.4.4.1. Additional Resources

The following are re s ource s which e xplain more about Re ve rs e Path Forwarding.

Usef ul Websit es

Se e RFC3704 for an e xplanation of Ingre s s Filte ring for Multihome d Ne tworks .

Se e https ://www.ke rne l.org/doc/Docume ntation/ne tworking/ip-s ys ctl.txt for a lis t of file s and options available in the /proc/sys/net/ipv4/ dire ctory.