Here’s info from the January meeting:

Attendees:

Scott
Adrian
Ed
Mike from ExitCertified.com

It was a pretty informal meeting, but we covered a few different
things:

• Ed brought some give-aways with him, including some Silly Putty, and
  some Sun software.

• Scott talked about revamping the ovsage.org website, which will
  hopefully include secure email, and @ovsage.org addresses for those
  interested.

• We also touched on using a Linux bootable CD to replace Windows
  administrator passwords via the on-disk registry, and saving
  RealAudio streams to disk – Scott recommends searching asian sites
  for “streambox”.

• Mike recommended visiting playground.sun.com for IPv6 links.

• Steve stood us up for the second time in as many months. :)

• Adrian gave a short talk about stateful packet filtering, which is
  below.

See you all next month!

What I’ve Learnt About Stateful Packet Filtering:

by: Adrian Chung <adrian @enfusion-group.com>
(much of this document includes specifics taken from IPtables/Netfilter
and Linux 2.4.x, but the concepts are widespread).

Introduction:

A stateful packet filter (SPF) is one that has the ability to maintain
state information about a connection in memory. This information
includes, but is not limited to, source and destination IP address and
port number pairs (socket pairs), protocol types, connection state and
timeouts.

SPFs have an advantage over stateless packet filters because they don’t
require every high numbered port (>1024) to be open on the firewall in
order to accept replies to outgoing packets. The classic example always
used to depict this is a DNS request to a DNS server on the Internet.

The firewall initiates a DNS request to a server out on the Internet.
The connection originates from a high numbered port on the server to UDP
port 53 on the Internet host. The Internet host will reply from UDP
port 53 back to the firewall on that same high numbered port.

On stateless firewalls, the only option is to accept packets on every
high numbered port, otherwise the DNS reply would be dropped.

On stateful firewalls, the firewall knows that the reply packet is in
response to a packet that originated on the firewall, by looking at its
connection tracking table and matching up source/destination IP/port and
protocol, so lets it through, without requiring all high ports to be
open.

This works well for simple TCP and UDP based services, but most stateful
firewalls will still need help on a case-by-case basis to handle
multiport, or complex protocols, such as FTP, RealAudio, and H.323.
This is touched on later.

With the exception of NAT, stateless packet filters have no record of
previous connections. The only criteria that can be used when
determining whether a TCP packet belongs to an existing connection or
not, is the SYN flag. If the SYN flag is set, and the ACK and FIN
flags are cleared, the packet is assumed to be a new connection
attempt. If the SYN flag is cleared and the ACK or FIN flags are set,
the packet is assumed to be part of an existing connection, though it
might not be.

It is important to note that this check is done on a packet-by-packet
basis, with no reference to sequence numbers, and/or information that a
stateful packet filter would store in its connection tracking table.

Connection Tracking in UDP:

Even though UDP is not a stateful protocol, we can still maintain state
about UDP conversations by recording packets from and to the destination
and source addresses in the packets.

Initially, when a UDP packet originates on the firewall, and is sent to
another host, a low timeout is attached to a UDP outbound packet, and
the connection is marked as ‘UNREPLIED’ in the connection tracking
table. The timeout is defined in the Linux kernel sources.

If, however, a response comes back before that timeout expires, the
timer is reset. If multiple packets are exchanged as part of the same
connection/conversation, the UDP conversation is assumed to be a
“stream”, and the timeout is set to 180 seconds [default per kernel
defaults], at which point, the connection tracking table marks this
connection as being in the ‘ASSURED’ state, which means that it won’t be
dropped during heavy load.

Conversely connections in the ‘UNREPLIED’ state, as they are after the
first/initial outbound packet is sent are dropped in preference to
‘ASSURED’ connections.

Connection Tracking in TCP:

“State” in stateful firewalls/packet filters is not equivalent to state
in TCP.

When a TCP packet is generated to another host, with the SYN flag set,
an entry is written into the connection tracking table, and the
connection’s state is marked as ‘UNREPLIED’.

If a response comes back with the SYN+ACK packets set, the ‘UNREPLIED’
state is removed, and the connection now becomes considered
ESTABLISHED, in connection tracking terms. However, in TCP terms, the
connection is not ESTABLISHED until an ACK packet comes back with a
valid sequence number, the end of the TCP three-way handshake.

At this stage, the connection is marked as ‘ASSURED’, and will not be
dropped under heavy load.

Other protocols:

How about protocols that don’t only expect responses back to the same
ports that they originated on? A good example is FTP.

There are two modes FTP uses, active and passive:

i) In ‘active’ mode, a client connects to a server on TCP port 21. Port
21 is known as the FTP control channel. Once a data transfer is
initiated, the client sends a PORT command to the server, telling the
server which port on the client to transfer data to. The server then
connects from port 20 (ftp-data) to the port on the client.

ii) In ‘passive’ mode, a client connects to a server on TCP port 21.
Once a data transfer is initiated, the server tells the client what
port to connect to in order to transfer. The client then connects
from a (usually) high numbered port to the (usually) high numbered
port on the server.

This scenario is fine when both FTP servers have publicly routable IP
addresses. However, problems occur when one or both servers are behind
port-forwarding NAT firewalls. If both the server and client are behind
a firewall doing NAT, and both have unroutable IP addresses, no matter
which mode is used, the IP address provided for data transfer will not
be routable from one side or the other.

The IPtables Netfilter architecture solves this problem by having both
an ip_nat_ftp module and an ip_conntrack_ftp module. The first is
used to rewrite any non-routable IP’s in PORT commands to the IP of
the firewall. Then, the second is used to insert an appropriate
connection entry into the connection tracking table so that future
packets are allowed through the firewall. This makes it possible to
do FTP, and port-forward FTP without requiring all high numbered ports
to be open.

SonicWall also inspects FTP control packets for PORT commands and
inserts entries into a connection tracking table to allow replies to
penetrate the firewall.

SonicWall claims they do/must do the same thing for any protocol that
requires multiple ports for data exchange, ie, Real Audio, on a case by
case basis.

The BSD’s (at least OpenBSD) take a different approach, and use a proxy
server on the firewall to accept connections, inspect the packets, and
then recreate them inbound to the appropriate server behind the
firewall. This is much more CPU intensive.

Other improvements IPtables has over IPchains:

In particular, IPtables has a number of improvements over IPchains, not
all of which are a direct outfall from evolving into a “stateful packet
filter”.

SNAT/DNAT:

Enhanced source NAT/destination NAT which allows for port forwarding,
and many, many other things. In ipchains land, this required an extra
userspace utility called ‘ipmasqadm’.

An excellent example of a benefit of IPtables new SNAT/DNAT features is
one that is often raised. A company has a masquerading firewall that is
port-forwarding a port on its external interface through to a local
host. The organization does not have a split DNS setup, and so local
clients resolve the same external IP for the host. When external hosts
connect to that DNS name, port-forwarding works fine. However, when
local hosts attempt to connect to that DNS name, the connection never
gets established.

A local client connects to the external interface of the firewall, which
port-forwards the packet to a local server. The problem arises when the
local server and local client can route to each other directly. If the
local server can see the local client, it sends packets directly back to
the local client, which drops the packets because it’s expecting replies
from the external interface of the firewall.

SNAT/DNAT address this situation as follows: to port-forward packets on
the firewall to the local server, we simply apply a DNAT rule that
rewrites the destination address of specific packets to that of the
local server. After doing that, we also use SNAT to rewrite the source
address of the packets to that of the firewall. This forces all replies
to local client requests to go through the firewall, which then in turn
replies to the client, and establishes a connection.

Rate Limiting:

IPtables has the ability to apply a rate limit to rules in an attempt to
protect against things like SYN, and ping floods, and also repetitive
logging output.

Enhanced TCP inspection:

IPtables has the ability to inspect all six TCP flags, rather than just
the SYN flag, and has a target which matches UNCLEAN (invalid TCP
flags), or INVALID (not belonging to an existing connection) packets for
early dismissal.

–
Adrian Chung (adrian at enfusion-group dot com)
http://www.enfusion-group.com/~adrian
GPG Fingerprint: C620 C8EA 86BA 79CC 384C E7BE A10C 353B 919D 1A17
[rogue.enfusion-group.com] 1:25am up 5 days, 6:48, 5 users