Mailinglist Archive: opensuse-security (757 mails)

< Previous Next >
Re: [suse-security] SuSEpersonal-firewall - Reason for not using a default policy for INPUT
On Tuesday 22 January 2002 02:22, Roman Drahtmueller wrote:
> > Just curious the reasons for not using default 'policy', but preferring
> > 'back stop' rules in SuSEpersonal-firewall. Can anyone explain the
> > reasons?
> >
> > Initial impression, would be that setting a policy of DENY on INPUT would
> > be more secure. The usage is commented on, but not explained which makes
> > me curious!
> >
> :-) That's very simple: The SuSEpersonal-firewall actually lets more
> packets pass than it drops/rejects. The main rule is the one where TCP SYN
> packets get rejected.

I suspect this is true of all packet filters, on systems that are actually
used, ie not a quiet one, which is just being hit by 'kiddies' or a DDoS.

> Everything else ist just featurism. By consequence,
> a changed default policy would require to list all options where a packet
> is allowed to pass. I judged the way to solve it by the number of rules
> I'd have to add to the filter.

Thinking about it, it means you don't have to worry about internal
interfaces, just deal with the single external one that has filtering.
For simple dial up use, it seems rule number same, as UDP packets are
dropped, so couldn't tcp ESTABLISHED,RELATED packets be accepted instead? I
know there was a kernel advisory on that combo, but it would seem a little
safer than relying on SYN flag.

I remember reading on critiques of 2.2 ipchains firewalling, that it was
possible to open connections without sending initial packets with SYN set.
How is this actually done? Is it just a variant of connection hijacking,
relying on predictable sequence number increments?

> Second reason: The personal-firewall does not touch any rule in the
> existing ruleset. All rules can be safely removed by the script because
> they use a "private" namespace, eg. other chains (rulchain, devchain,
> maschain) to match against the criteria. This way, masquerading can be
> turned on with just one variable without breaking anything.

Yep, very clever. I see this one. I've used SuSEpersonal-firewall, as a
quick and easy options after clean install.

The downside to this choice is, that it rquires explicit drop rules on INPUT,
and that makes it much harder to append rules for log of dropped UDP packets
for instance. Instead you need to insert them at the right point, which
changes depending on what's running when SuSEpersonal-firewall is started. I
modified SuSEpersonal-firewall in 7.1 release to support a local DNS server
using forwarders, but try to avoid that in 7.3.

I'll probably move to using my own script based firewall in a bit, now I've
added local DNS server to the mix of rules permitting, NTP, ICQ and some IRC
DCC's. Adding new chains into the devchain for my own permissive rules, is
becoming more complex than keeping the whole firewall in one place.

Rob

< Previous Next >
References