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