[Courses] [Security] Firewall theory -- general

[Raven, corporate courtesan]

Heya --

Quoth Hamster (Mon, Mar 11, 2002 at 10:24:43PM +0100):
> > 	If you were going to build me a firewall, what would you do?
> 
> I'll jump in and make myself look silly :)
> 
> Now, I cant remember the details of your box exactly, but based on the following assumptions:
> You're running:	ftp	
> 		www
> 		ssh	
> 		smtp
> so we let these in ;-)

	Right.  It doesn't make any sense to block services that you
want the world to access.  If these were services for my internal
network only then it would make sense to block them at the firewall, but
we'll assume that this is an Internet server (it is).  So I want folks
not on my internal network to be able to reach these ports.
 
> If I was being paranoid, I would set the default action to DROP on your external interface, except for the services youre running.

	Another good point.  We have to figure out what we want our
default policy to be.  If some packet doesn't match our firewall rules,
do we want to drop it or let it in?  Defaulting to accepting the packets
is easier on the admin, but defaulting to drop is more secure.  I
almost always default to the latter.

	Now, one thing that a lot of folks don't realize is the
difference between ports that servers commonly use and ports that
clients commonly use.  Any port below 1024 (barring weirdness) needs
root priviliges to open.  So most of the common servers run off ports
lower than 1024.  Clients that open connections to servers use high
numbered ports.  So, for example, an SSH connection might look like
this:

Client:     -------------------------------->  Server
10.1.1.47, port 35642                          10.1.1.2, port 22
           <--------------------------------

When the server sends its reply packets back to the client, they'll be
sent to port 35642.  So if you set up a firewall that blocks all ports
except for the services you run, you get this:

Client:     ---------------|----|---------------->  Server
10.1.1.47, port 35642      | fw |                   10.1.1.2, port 22
                           |   *|----------------

	Since you want your machine to be able to get the return packets
for any client connection, the usual solution is to default-deny
anything that's under port 1024.  That makes it easy to have successful
client connections, while still protecting priviliged ports.
 
Client:     ---------------|----|---------------->  Server
10.1.1.47, port 35642      | fw |                   10.1.1.2, port 22
            <--------------|----|----------------

> But if I am being less paranoid... I would block incoming on your external interface:
> finger
> telnet
> DHCP
> DNS
> POP3
> netbios
> imap
> snmp
> irc
> tftp (udp) maybe?

	Sensible enough -- picking the vulnerable services and
firewalling them is a common approach.  You'd have to look up the
appropriate ports and whether they were TCP or UDP for each of those,
but that's a good start.  I can't tell you how many scans for Windows
networks I get every month.  (Well, I probably could... it's a lot.) Ports
135, 137 and 139 are by far the most popular targets when someone
portscans me.  (That, on average, happens seven times a day on my 56k
dialup line at home.  It's things like this that make me believe that
most anyone on the Internet needs a firewall these days.  My Mom's cable
modem gets portscanned an average of five times an HOUR.) 

> So have fun picking this list to pieces. Sorry if I made a wrong assumption somewhere too.

	Actually, you're doing great.  Any other suggestions for things
we might want to look at in our firewall?

Cheers,
Raven
 
"Sed, sed, awk.  Like duck, duck, goose.  Sync, sync, halt.  It's the
 order of nature."
  -- me, after too long a day at work