[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.
I don't know if that's the reason Bruce wants to jump the IPCop ship and go to 
floppyfw; after talking to him tonight I think there are other reasons. Perhaps
he will comment on this....

>>>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.
OK, for the moment, forget the special cases. I'm looking for some underlying 
principles here.

>>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.
It helps pass the time and keeps me awake, and seems to have other benefits.
Running with a faster crowd is fun, too.

>>>>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 look for SYN packets.
>Thats ok, it happens alot.  Just amusing myself amid the blight of corporate
>america.  "-y" is ipchains. 
I see. It's only Tuesday, with 50 minutes to go.

>>>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.
OK, pleased to see you back on the same page :)

>>>>>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.
OK, I understood that. I think this is a level of detail reached perhaps a 
message too soon. Best we agree on something, then refine it. 

>>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.
Right, I see that coming, but I wanted agreemnt (or argument) on the general 
rule, perhaps before getting this specific.

>>>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
Yup
>2. HTTP and FTP services running ON the edge device
Correct
>3. Forwarding (with masq) traffic from internal net
No. There is no "internal net"

>4. Services should be accessable from both external and internal clients
Ditto

>5. Forwarding of DNS queries is restricted to those from a certain internal
    host.
We only want dns queries to go to/come from a deginated host[s].

>Yes?
See each item above.

Oh, and anything else coming OUT of the box (that does not meet the above
criteria) is LOGGED and denied.

We don't want anything coming out of this server we don't really, REALLY 
understand.


>>#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?
myip is actually the only IP address I've got. This is NOT a gateway or 
router! It ia a stand-alone server with packet filtering....

							Regards,
							---> RGB <---