[KLUG Members] IPChains problem

[members@kalamazoolinux.org]

Bob:
>> >The Problem:
>> >1. Restrict access from outside to the services we support.
Adam:
>> INPUT CHAIN

Bob:
>> >2. Prevent any packets that are produced on the server other than 
>> >   those involved in the above services from leaving, and log
>> them.

Adam:
>> OUTPUT CHAIN
I'd think so, too. Perhaps this is iptables thinking.

Rusty:
>Only if we were doing iptables and not ipchains.  That is a major
>design difference between the two.
OK, this is an interesting point, one not emphasised enough:
ipchains: Every packet traverses (potentially?) all three chains.
iptables: Every Packet traverses (at most?) one chain.

I elected to use (and learn) ipchains since that was what was used on the
server I am talking about; it's clear that learning both is important. I
feel that ipchains and iptables are very different from what preceeded them
(things like ipfwadm, ipportfw, ipmasqadm, etc.), but are in many ways (the
above being a notable exception) very similar.

I know there are wrapper scripts and "compatibility" tools so that you don't
have to update your ruleset or your thinking right away, but they'll be gone 
soon, and it's important to upgrade the computer bettwen the ears for the
newer tools in any case....

Adam:
>> Where does "-y" come from?  My iptables says that in an unknown
>> arg.  (Reminds me of the pirate on the Simpsons).
I have NO IDEA what you're talking about (re: Simpsons), but the -y is
a flag to llok for SYN packets.

>I have been approaching this from ipchains, which is what I think Bob
>is using at this time.
That's right  
 
>>>So a connection on port 80 is an attack?
>A connection on port 80 coming from something below port 1024 is
>likely an attack.  
Ah, that's the key, "coming from something"...

>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.  
[explanation assimilated and elided]
OK, you're not connecting this back to what we're doing. Someone out there
sends using their local socket 34567 (f'rinstance) and wants to bind to my 
local port 53. That seems pretty normal. I don't see why I care -- I'm either
going to allow a packet bound for port 53, or I'm not. Therefore, I'm either 
going to restrict port 53, UDP (actually, some DNS requests are TCP as well)
either by policy or by explici rule, or I'm not.

>This is why the rules look a little funny at first.  You do not
>really want persons to use just any port willy nilly. 
I didn't think we were, nor are we now (see below).

>This is a way that hackers will try to get into a box...
Crackers, and yes, that's obvious.

>I know that this is a little theoretical but it is needed to be able
>to understand the construct of the rules.
That's OK, Rusty, we do theoretical every day! :)

>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.
I think my problem is elsewhere. Let's take a look at my refined ruleset:

#flush any prior rules
-F input

#set the default policy
-P input DENY

#allow anything on the loopback interface
-A input -s 0/0 -d 0/0 -i lo -j ACCEPT

#allow any icmp packets for good control
-A input -s 0/0 -d 0/0 -p icmp -j ACCEPT

#accept HTTP and FTP from anywhere, in and outbound 
# (http and ftp servers on the local host)
-A input -s $myip -d 0/0 80 -p tcp -b -j ACCEPT
-A input -s $myip -d 0/0 20 -p tcp -b -j ACCEPT
-A input -s $myip -d 0/0 21 -p tcp -b -j ACCEPT

# accept DNS from my DNS server (TCP or UDP)
-A input -s $dns 53 -j ACCEPT
-A input -l -j DENY

myip is my IP address.
dns  is the dns server address.

							Regards,
							---> RGB <---