[KLUG Members] IPChains problem

[members@kalamazoolinux.org]

>>>>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.
>Adam:
>>> OUTPUT CHAIN
>I'd think so, too. Perhaps this is iptables thinking.

Yes it is.  I've become terribly confused.  I thought you were trying to use
iptables.  But now I realize ipCop uses ipchains and that is why Bruce is
switching to floppyfw).  Ok,  the fog is clearing.

 
>>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.
iptables: Every packet traverses (at least) one chain.

Your close though,  special cases muddy it up in both cases.  And iptables has
PRE and POST routing chains.

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

Yes.

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

"L.e.a.r.n.i.n.g".  Yes.  I wish I could teach my users how to spell that.

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

Thats ok, it happens alot.  Just amusing myself amid the blight of corporate
america.  "-y" is ipchains. 

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

I get that now.

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

Yep.

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

You don't.  If they connect from port 712, you do.  Source ports of less than
1024 are considered "suspicious" 1-1024 are ports services LISTEN on,  a
connection shouldn't come from there.

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

More or less, yes.  You can policy thay port 53 accepts connections from source
ports >1024 but refuses for ports <1024.

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

So  -
1. Using ipchains
2. HTTP and FTP services running ON the edge device
3. Forwarding (with masq) traffic from internal net
4. Services should be accessable from both external and internal clients
5. Forwarding of DNS queries is restricted to those from a certain internal host.

Yes?

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

Is myip the "outside" IP?