[KLUG Members] IPChains problem

[Rusty Yonkers]

> >The Problem:
> >1. Restrict access from outside to the services we support.
> 
> INPUT CHAIN
> 
> >2. Prevent any packets that are produced on the server other than 
> >   those involved in the above services from leaving, and log
> them.
> 
> OUTPUT CHAIN

Only if we were doing iptables and not ipchains.  That is a major
design difference between the two.

> Where does "-y" come from?  My iptables says that in an unknown
> arg.  (Reminds
> me of the pirate on the Simpsons).

I have been approaching this from ipchains, which is what I think Bob
is using at this time.
> 

> 
> >So a connection on port 80 is an attack?

A connection on port 80 coming from something below port 1024 is
likely an attack.  

This is where it is vitally important to understand how TCP/IP works
in the conversation at layer 4 of the OSI model.  I will try to
clearly explain.  

We will use a conversation to a dns server first.  This will be for a
dns lookup and not a zone transfer.  DNS lookups are udp traffic,
which is connectionless.  This means, in general, that there is no
acknologment for the conversation.  It is kinda like an I talk and
you listen type of thing.  

Well, anyway, the client computer sends a packet with a source ip
address of itself and a udp port number randomly chosen from an upper
port number of 1024 or above (usually way above).  The destination
address will be the address of the dns server with a port number of
53.  When the packet gets to the dns server, it will respond using
itself as the source address and port 53 and the destination address
will be the client that started the conversation with the port number
that the destination computer used to start the conversation.  Thus
the dns server needs to be able to listen on and respond from 53 but
the client computer needs to send a request in and listen on a port
above 1023.

TCP conversations are somewhat similar to UDP but with a little more
overhead.  Web is an example of a TCP conversation.  The client
starts out by sending a request using its ip address as the source
and a source port of 1024 or above.  The destination of the packet
will be the ip address of the web server and the destination port of
80.  Same as UDP.  The differences come in play as it establishes a
connection-oriented connection.  The first packet the client sends
out is the SYN packet to start the syncronization.  The web server
will then send a SYN ACK.  The client then sends an ACK back.  After
this point for every packet that is sent an ACK is sent back saying
that the packet was received.  

This is why the rules look a little funny at first.  You do not
really want persons to use just any port willy nilly. This is a way
that hackers will try to get into a box (through holes in the system
because of this) or try to shut down a box with denial of server
attack.  

I know that this is a little theoretical but it is needed to be able
to understand the construct of the rules.

It takes a while to really get it.  It took me some time and I can do
cisco access lists in my sleep.  Once I got over the hump though I
found it really easy.



=====
Truth is truth ... no matter what I think...
-----------------------------------------
Department of Redundancy Department
-----------------------------------------
Devoted RedHat fan...

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com