[Courses] [Security] Firewall theory -- general

coldfire rolick571 at duq.edu
Mon Mar 11 20:56:35 EST 2002


> 	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
>             <--------------|----|----------------

would now be a good time to mention connection tracking and the state
module?

in the above example, ports 1-1024 would be filtered ... anything above
would be left wide open.  this may not be desirable, as users could
configure services to run on those higher ports such as ftp and use your
server for a nice wares site or something ...

rather, you can use "Connection Tracking" which is required for IP
masquerading and NAT (kernel 2.4.x) in conjunction with "Connection state
match support."  this will give the kernel the ability to make decisions
based on previous packets ..

with the above example, you can set the default policy for incoming
packets to deny and then explicitly allow packets destined for ports
21, 22, 25, and 80.  then add one additional rule which accepts any
packets which are in the "new" or "related and established" state.  this
way, if someone inside the firewall initiates an SSH beyond the firewall,
the firewall will remember which port the internal machine created that
connection with and allow packets inbound which are classified as one of
the above.


coldie




More information about the Courses mailing list