[UFO Chicago] NAT and port filtering

Jesse Becker jesse_becker@yahoo.com
Tue, 28 Jan 2003 09:05:46 -0800 (PST)


--- "Robert B. Moses" <robert.moses@helioslogic.com> wrote:
> I need 3 boxes connected to a Netgear router doing NAT
> and filtering.
> None of these boxes run any servers/services...they are
> simply client 
> machies that want to browse the WWW and POP off their
> email. Easy.

This is straight-forward masquerading.  Nothing fancy here.

> so..
> 1/2 my mind says "well since you don't need any inbound
> connections you 
> can drop ALL inbound traffic"
> the other 1/2 says "don't be stupid, you have to allow
> the client 
> initiated requests to come back via whatever port it
> started at..."

Both halves are half right.  ;-)  You don't need to allow
incoming connections, but you do need to allow return
traffic for connections that you have established.

When a TCP connection is created, the host initating the
connection ("client"), send a packet to another computer
("server").  This packet has the SYN flag (an no others)
set.  The server sends a packet back to the client with SYN
and ACK both set.  The client then sends a packet with only
the ACK bit set.  At this point, the connection is
established, and the client can start sending actual data
("HTTP 1.0\n\nGET index.html\n" or something. <grin>). 
This process is the infamous 3-way handshake that you may
hear about.

So, notice that the SYN packets are used *only* during the
creation of a session.  Thus, you should safely be able to
block any incoming packet with just the SYN flag set. 
Likewise, you could also block any outgoing packets with
SYN,ACK set as well--since that may indicate the presense
of something acting like the "server" side of the TCP
process.  Usually blocking incoming SYN packets is enough
though.

A few other notes:
 * This doesn't cover UDP at all.  Since UDP is stateless,
it's all or nothing (on a host-by-host and port-by-port
basis at least)
 * Some protocols are a pain in the @$$ to filter this way.
 Active FTP is the most common nusiance, and DCC
connections used in IRC are also similar.  The reason is
that after your client connects to the server, the "server"
connects *back* to your "client" in a seperate session.

> Would blocking/dropping inbound connections 0-1024 be
> sufficient?

Well, the default policy should be a default DROP, except
where you make holes for valid traffic.

(oh, someone check my work here...I'm pretty sure it's
correct, but I missed my coffee this morning)

--Jesse


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com