Mailinglist Archive: opensuse-security (485 mails)

< Previous Next >
Re: [suse-security] firewall help..
  • From: Maarten J H van den Berg <maarten@xxxxxxx>
  • Date: Wed, 3 Mar 2004 01:43:41 +0100
  • Message-id: <200403030143.42000.maarten@xxxxxxx>
On Tuesday 02 March 2004 23:34, Gilmore, Eric wrote:

> Well I totally understand what you're saying about "ease of setup". But
> I believe the reasons I was given for using iptables instead of
> SuSEfirewall went something like, "it's quicker to re-establish
> connectivity if the firewall machine burns down..." and "we want to
> standardize across all our systems...yada, yada". Even though I had a
> working instance of SuSEfirewall2 in place doing exactly what I needed
> it to do. <sigh>

I do understand. I myself sometimes use SuSEfirewall, sometimes I use some
intelligent builder script, sometimes I just cut 'n paste something together.
However, I have a very clear idea about what to put in and where and why.
I'm not saying you don't, but I fear it when people first make a 'working
solution' and then start to fill the holes later on...

Oh yeah, another thing: If standardization is the goal, isn't there a working
template already ? Also I would stronly advise you to add extensive
comments inside the firewall scriptfile. Trust me, if you look at your own
filter a year from now you will not recognize it (much less admit to writing
it ;-) and documentation may make a very big difference.

> And yes I do understand the security implications of doing it this way
> (Open then close) this was to be more of a test instance where access
> from the internet would only be given to certain machines, not sub-nets,
> not lans, machines. There will be approx. 3-4 attaching to it from the
> internet via FTP, ssh, AFP & SAMBA.

Ok. Well, my time is too short to help you design a filter. However, upon
examination I found some errors (or at least inconsistencies).


iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

You really should change this. Why not make policy DENY, and (for now) put a
rule at the end of your script accepting anything that was not yet accepted ?
It gives you the same result but without having to start all over by the time
you change the default policy. And this way you can also have that logged.

iptables -A INPUT -i $EXTIF -m state --state ESTABLISHED,RELATED -j ACCEPT

This rule allows for return traffic TO the firewall (its irrelevant to the
LANs though) As I need to reference this rule later, lets call this rule(1)

iptables -A OUTPUT -o $EXTIF -m state --state NEW,ESTABLISHED,RELATED -j
ACCEPT

Lets the firewall connect to internet. Ok.

iptables -A INPUT -i $EXTIF -j ACCEPT

Well, this rule makes rule(1) totally worthless, i.e. it supersedes it
completely. In addition it allows for new connections which rule(1) did not.

echo "Adding Masquerade support for 192.0.0.0 subnet..."
iptables -A FORWARD -i $EXTIF -o $INTIF1 -m state --state ESTABLISHED,RELATED
-j ACCEPT

Hm, I see no masquerading being done here. This is just for return-traffic.
Maybe I'm out on a limb here but why don't you make just 1 (one) rule that
handles all state ESTABLISHED,RELATED traffic for the whole filter:
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A FORWARD -i $INTIF1 -o $EXTIF -j ACCEPT

Same here, where is the masquerading? I see no "-t nat" postrouting chain.

echo "Adding Masquerade support for 192.0.5.0 subnet..."
iptables -A FORWARD -i $EXTIF -o $INTIF2 -m state --state ESTABLISHED,RELATED
-j ACCEPT
iptables -A FORWARD -i $INTIF2 -o $EXTIF -j ACCEPT

The same goes for that second LAN

echo "Allowing traffic between internal networks..."
iptables -A FORWARD -i $INTIF1 -o $INTIF2 -m state --state
ESTABLISHED,RELATED -j ACCEPT

If you omit state NEW how could anyone ever connect ? In fact why don't you
get rid of this --state condition altogether ? (I call this one rule(2) btw)

iptables -A FORWARD -i $INTIF2 -o $INTIF1 -j ACCEPT
iptables -A FORWARD -i $INTIF2 -o $INTIF1 -m state --state
ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $INTIF1 -o $INTIF2 -j ACCEPT

Hum. Again, you do weird things. The last rule overrules rule(2) totally, and
the same goes for the two rules in between; one supersedes the other.
However, LAN to LAN connections should hereby fully work now.
(Provided your routing table entries are correct of course...!)

iptables -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE

Ah, here is the actual masquerading done (not above...)

echo "Associating internal address 192.0.0.2 with external address 128.0.0.2"
iptables -t nat -A PREROUTING -p tcp --dst 128.0.0.2 -j DNAT --to-destination
192.0.0.2
iptables -t nat -A PREROUTING -p udp --dst 128.0.0.2 -j DNAT --to-destination
192.0.0.2
iptables -t nat -A PREROUTING -p icmp --dst 128.0.0.2 -j DNAT
--to-destination 192.0.0.2

These look okay...

iptables -t nat -A POSTROUTING -p tcp --dst 128.0.0.2 -j SNAT --to-source
192.0.0.2
iptables -t nat -A POSTROUTING -p udp --dst 128.0.0.2 -j SNAT --to-source
192.0.0.2
iptables -t nat -A POSTROUTING -p icmp --dst 128.0.0.2 -j SNAT --to-source
192.0.0.2

If I'm not mistaken the main masquerading rule should've taken care of this,
so these last 3 rules are fully redundant(?). AFAIK...
Hum, then again, maybe not; you use three addresses at the external interface
so -at second glance- these may indeed be needed not to fsck up the routing.

<snip>

I missed the parts where all the kernel anti spoofing and IP forwarding are
being done. Where do you do that ?

In fact, a lot seems to be missing, like dropping 'surely evil' traffic, some
-possibly needed- conntrack modules, maybe a "--state state INVALID" rule,
and also you would want to prevent all kind of leaking of [samba] broadcast
traffic. However that might interfere with your ability to use samba from the
internet (which remains a VERY BAD idea, I really cannot overstate that !)

Still, from this script, with its inconsistencies, I cannot see why LAN to LAN
connections wouldn't work. (And neither for samba.)

Maarten


< Previous Next >
References