TCP wrappers and IP filtering (UKERNA workshop draft)

George Ross

gdmr@dcs.ed.ac.uk

Version 1.7 of 2000/10/24 15:36:38 Talk is about protecting UNIX machines from network attacks. It’s based on our experiences with wrappers and filters.

We are a typical (?!) biggish University department, with no particular obvious attractions. We’re scanned a dozen or so times/week.

Talk isn’t a comprehensive tutorial on wrappers or filters (see the “howto” documentation), or prescriptive.

\overline{Why? 2}

Why use wrappers and filters?

• Nothing else between you and the outside world.

• Security in depth — in case firewall is breached, or to stop traffic which it lets through.

• Alien networks (e.g. laptops at conferences or other institutions), where network strength can’t be relied on.

• ISP dialups and cable modems!!

What are TCP wrappers?

Originally (early 1990s) a small program “wrapped around” service daemons started out of inetd. Wrapper library can also be linked in to standalone daemons.

See http://www.porcupine.org/

Control access based primarily on caller’s source Configure through a simple file Logging through syslog For daemons started by inetd adding a wrapper is a simple addition to the configuration:

ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
smtp stream tcp nowait root /usr/sbin/tcpd sendmail -bs

The corresponding wrapper configuration

(“hosts.allow”) file:
in.ftpd : ALL
in.telnetd : ALL EXCEPT .dcs.ed.ac.uk \
                    EXCEPT @external_connect
sshd : ALL EXCEPT .dcs.ed.ac.uk EXCEPT @external_connect
sshdfwd-X11 : localhost remote.dcs.ed.ac.uk
sendmail : localhost

Config options: ALL, netgroups, EXCEPT, hostnames, domain parts, addresses and subnets, ...

Twist, spawn, banners, niceness, umask, rfc931. Paranoid.

Pro wrappers:

• lightweight

• easy to set up

• no code change for basic functionality

• can be linked into non-inetd code

• run in userspace.

Con wrappers:

• can’t protect every kind of service

• “internal” services aren’t covered

• non-inetd services usually not covered — they have to have library linked in

• generally only on first connection.

\overline{IP filter 7}

IP filter — see

http://coombs.anu.edu.au/~avalon/ip-filter.html

It’s a kernel module for Solaris, SunOS 4, *BSD, HPUX, and IRIX.

It allows for all IP traffic to be filtered on one or more of:

• source address or block

• specific source port or source port range

• destination address or block

• specific destination port or port range

• IP protocol

• network interface

• TCP flags

• IP options

• ICMP type

Configuration is done through a filter description language.

Logging: a userspace daemon forwards to syslog.

In general packets pass through all the rules, with the pass/block state being altered by matching rules and preserved otherwise. The “quick” keyword shortcircuits this.

“Groups” are like “if… then” blocks — they can be used to cut down on rule processing for efficiency.

Keeping of state allows outgoing packets to open a temporary hole for appropriate responses.

There are built-in proxies for “difficult” protocols (e.g. ftp).

NAT (not covered here).

Asymmetric routing is coming — it needs the state sharing hooks from the latest test versions.

A small IPfilter example 9

...
# Group head first -- all service-wire traffic comes through here
block in proto tcp/udp from any to 129.215.216.0/24 head 216
# remote access telnet
pass in quick proto tcp from any to 129.215.216.239 port = 23 group 216
# SMTP to the mail hub
pass in quick proto tcp from any to 129.215.216.15 port = 25 group 216
# User-ftp and anonymous ftp
pass in quick proto tcp from any to 129.215.216.15 port = 21 group 216
pass in quick proto tcp from any to 129.215.216.238 port = 21 group 216
# Print servers, from EdLAN only
pass in quick proto tcp from 129.215.0.0/16 to 129.215.216.13 port = 515 group 216
pass in quick proto tcp from 129.215.0.0/16 to 129.215.216.14 port = 515 group 216
...

Or, if you’re running Linux, you have ipchains (see

http://netfilter.samba.org/ipchains/) which comes

with 2.2.x kernels (2.3+ have netfilter instead). This does basically the same job as IPfilter, though the details are different.

Packets start on a built-in chain. A match can result in a jump to one of ACCEPT, REJECT, DENY or RETURN, or to a user-defined chain.

Saving of state userspace addon, not built-in. Likewise ftp handling.

MASQ is similar to NAT (also not covered here).

Can manipulate TOS flags (for routing or network drivers).

Logging: through klogd to kernel syslog.

Built-in chains (“input,” “output” and “forward”) can have a default policy for packets which don’t match any rules.

ipchains example 11

# Pre-flush built-in chains
ipchains -P input ACCEPT
ipchains -F input
ipchains -P output ACCEPT
ipchains -F output
ipchains -P forward ACCEPT
ipchains -F forward
# Chain: budp
ipchains -F budp
ipchains -A budp -p udp --dport 520 -j ACCEPT
ipchains -A budp -j DENY
# Chain: bcast
ipchains -F bcast
# Generated by /usr/libexec/ipchains/generated.broadcast:
    # Broadcasts directed to running interfaces:
    # eth0...
    ipchains -A bcast -i eth0 -p udp \
        -s 129.215.58.4/255.255.255.0 -d 129.215.58.255 40: -j budp
    ipchains -A bcast -d 129.215.58.255 -j DENY
ipchains -A bcast -p udp -d 255.255.255.255 40: -j budp
ipchains -A bcast -d 255.255.255.255 -j DENY
ipchains -A bcast -d 224.0.0.0/8 -j ACCEPT
...
# Chain: input
ipchains -P input DENY
ipchains -F input
ipchains -A input -p udp --dport 123 -j ACCEPT
ipchains -A input -i lo -j ACCEPT
ipchains -A input -s 127.0.0.0/8 -j DENY -l
ipchains -A input -d 127.0.0.0/8 -j DENY -l
ipchains -A input -j dcs
ipchains -A input -j bcast
ipchains -A input -p tcp -j tcp
ipchains -A input -p udp -j udp
ipchains -A input -p icmp \! -f -j icmp
ipchains -A input -j DENY -l

IPfilter vs. ipchains:

• Different OSs!

• IPfilter: kernel add-on with some OSs, built in with *BSD, more flexible filtering options, state built-in, cumulative packet disposition or “quick”, groups like “if ... then”.

• ipchains: comes with Linux 2.2.x, cumulative effect through chaining, chains akin to procedure calls.

Wrappers: much simpler to set up, don’t see everything, inetd-started or linked in, only affect inbound connections.

Filters: more complex to set up, see everthing, control all packets, overhead on all traffic, good supporting docs, use on routers as basic firewall.

TCP wrappers:

http://www.porcupine.org/

IPfilter:

http://coombs.anu.edu.au/~avalon/ip-filter.html
http://www.obfuscation.org/ipf/

ipchains:

http://netfilter.samba.org/ipchains/
http://www.linuxdoc.org/