Re: ipchains
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).
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.
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:
>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?
What about the new firewall in the linux kernel version 2.3.99?
__ _ Debian GNU User
/ /(_)_ __ _ ___ __ Simon Martin
/ / | | '_ \| | | \ \/ / Project Manager
/ /__| | | | | |_| |> < Isys
\____/_|_| |_|\__,_/_/\_\ mailto: smartin@isys.cl
There is a chasm of carbon and silicon the software cannot bridge
----- Original Message -----
From: "Lee Bradshaw" <lee@sectionIV.com>
To: <debian-firewall@lists.debian.org>
Sent: Tuesday, March 28, 2000 10:41 AM
Subject: Re: ipchains
> On Tue, Mar 28, 2000 at 11:25:39AM -0800, Simon Martin wrote:
> > I started off with the following
> >
> > echo 0 > /proc/sys/net/ipv4/ip_forward
> >
> > iphains -P input REJECT
> > ipchains -A input -j ACCEPT -s localhost
> > ipchains -A input -j ACCEPT -s localnet/24
> >
> > ipchains -P forward REJECT
> > ipchains -A forward -j MASQ -s localnet/24
> >
> > ipchains -P output ACCEPT
>
> I'd set the default policies to DENY instead of REJECT. DENY drops the
> packet with no other action. REJECT is more polite and tells the other
> end the connection isn't allowed. I'm not sure your firewall needs to
> be polite.
>
> Try something like this (untested, but hacked from a working config)
>
> # ipchains stuff before bringing up interfaces
> # flush rules and set default to DENY, must explicitly enable services
> ipchains -F input
> ipchains -P input DENY
> ipchains -F forward
> ipchains -P forward DENY
>
> # block private addresses from default route
> ipchains -A input -j DENY -i ppp0 -s 10.0.0.0/8
> ipchains -A input -j DENY -i ppp0 -s 172.16.0.0/12
> ipchains -A input -j DENY -i ppp0 -s 192.168.0.0/16
>
> # allow incoming dns connections
> ipchains -A input -j ACCEPT -i ppp0 -s $NAMESERVER1/32 53 -p tcp
> ipchains -A input -j ACCEPT -i ppp0 -s $NAMESERVER1/32 53 -p udp
>
> # allow ssh in both directions
> ipchains -A input -j ACCEPT --dport ssh -p tcp
> ipchains -A input -j ACCEPT --dport ssh -p udp
>
> # accept responses from internet
> ipchains -A input -j ACCEPT -i ppp0 -p tcp ! -y
>
> # masquerade internal net out to internet
> ipchains -A forward -j MASQ -s localnet/24
>
> # turn on ip forwarding
> echo "1" > /proc/sys/net/ipv4/ip_forward
>
> >
> > What I expected was "input will accept anything from my local net,
forward
> > will masquerade everything from my localnet, output will send anything".
> >
> > Unfortunately this did not work. The configuration I have now is:
> >
> > echo 1 > /proc/sys/net/ipv4/ip_forward
> >
> > iphains -P input REJECT
> > ipchains -A input -j ACCEPT -s localhost
> > ipchains -A input -j ACCEPT -s localnet/24
> > ipchains -A input -j ACCEPT -s 0.0.0.0/0 -d localnet/24 www -p tcp
> > ipchains -A input -j ACCEPT -s 0.0.0.0/0 -d localnet/24 ftp -p tcp
> > ipchains -A input -j ACCEPT -s 0.0.0.0/0 -d localnet/24 ftp-data -p tcp
> > ipchains -A input -j ACCEPT -s 0.0.0.0/0 -d localnet/24 domain -p udp
> > ipchains -A input -j ACCEPT -s 0.0.0.0/0 -d localnet/24 smtp -p tcp
> > ipchains -A input -j ACCEPT -s 0.0.0.0/0 -d localnet/24 pop-3 -p tcp
> >
> > ipchains -P forward REJECT
> > ipchains -A forward -j MASQ -s localnet/24
> > ipchains -A forward -j MASQ -d localnet/24
> >
> > ipchains -P output ACCEPT
> >
> > This now works, but I find it very permissive. Anyone connecting from
socket
> > 80 on a remote machine can connect to my telnet port!!!
> >
> > I have 2 main questions:
> >
> > 1) What am I doing wrong?
> > 2) I am about to update my kernel to linux-2.3.99-pre3 for other
reasons.
> > What will security be like on this?
> >
> > TIA
> >
> >
> > __ _ Debian GNU User
> > / /(_)_ __ _ ___ __ Simon Martin
> > / / | | '_ \| | | \ \/ / Project Manager
> > / /__| | | | | |_| |> < Isys
> > \____/_|_| |_|\__,_/_/\_\ mailto: smartin@isys.cl
> >
> > There is a chasm of carbon and silicon the software cannot bridge
> >
> >
> > --
> > To UNSUBSCRIBE, email to debian-firewall-request@lists.debian.org
> > with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
> >
>
> --
> Lee Bradshaw lee@sectionIV.com (preferred)
> Alantro Communications lee@alantro.com
>
>
> --
> To UNSUBSCRIBE, email to debian-firewall-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
>
Reply to: