Re: ipchains
On Wed, Mar 29, 2000 at 09:13:21AM -0800, Simon Martin wrote:
> Thanks for the reply Lee. It more or less confirms that I was on the right
> track, I may have been a little permissive, but not too bad for a first
> attempt.
>
> A couple of notes though. I thought that the firewall was a stateful packet
> filter, i.e. it tracks the state of the open transactions. In that case, I
> would think that you wouldn't have to write explicit rules for the RETURN
> transactions for a connection (as you specify with the ! -y rule at the
> end).
ipchains is only a packet filter. I haven't tried spf, but I believe
it stands for stateful packet filter.
> Secondly, my DNS server does not use my ISPs DNS servers, but resolves via
> the root hosts, so the NAMESERVER1 rules you specified wouldn't work that
> well, and it would be a real let down to enable each one of them.
The isp hosts our external DNS. Internally we forward to their
nameservers. I don't want anyone else talking to our nameservers, and no
one should need to, so those ports are blocked. If you use the root
nameservers, they redirect you to other servers to get info, so you
pretty much have to accept any DNS connections. If you have a
firewall which tracks state, you can open return connections when you
make outgoing connections so you'll block incoming connections except
from machines you query.
> One way of getting round this (I think) would be to place the rules into the
> output target. As I understand the functioning of firewall + masquerade, I
> see the following scenario:
I'm not clear on what you're trying to get around, so I don't
understand the rest of this. Search for "ASCII-art" in the
IPCHAINS-HOWTO to find a good description of how the different rules
are used.
>
> From the intranet:input accepts the connection, forward modifies the packet
> source address and marks a connection id, output sends it.
>
> From the extranet:unput accepts the connection, forward picks up the
> connection id and translates to the correct destination address, output
> sends it.
>
> If this is correct, on packets FROM the extranet, I will have correct
> source/destination addresses on the OUTPUT target (not so on the input
> target), and on packets TO the extranet I will have correct
> source/destination addresses on the INPUT target (not so on the output
> target). This means that I can do propper address filtering depending on the
> interface the packet is received on.
>
> Am I correct in my thinking?
You can filter on the interface.
> What about the new firewall in the linux kernel version 2.3.99?
It looks better. From looking at the docs, the way packets traverse
the rules has been cleaned up, nat is separate and not a strange
target, DROP is clearer than DENY, and the forward rule can specify
both input and output interfaces.
--
Lee Bradshaw lee@sectionIV.com (preferred)
Alantro Communications lee@alantro.com
Reply to: