I've been lurking around for a while and followed this discussion with interest. I have the problem here that reloading the firewall rules after connecting to mu ISP takes so long (about 12-15 seconds), that for instance my DNS times out and gives up because the firewall is dropping the responses which it should get. Yes, I know that upgrading to a more powerfull computer might also fix this delay, but I hate to upgrade the 'ol Pentium 133 which handles internet traffic via ISDN, just because reloading the firewall rules takes too long, while it is running idle most of the time (even once the connection is established and the firewall rules are reloaded).

From a security point of view, though, you're safer the way it is than if

If you have many rules then iptables' and current way of modifying the chains will cause long delays when manipulating chains. The problem a colleague of mine found in the source code and that Rusty et al. are well aware of is that for each and every iptables [-A|-D|-I|-R] operation, the chain in question in memcopied as two halves, separated by the space where the manipulation is taking place. That is applied and then everything is memcopied into kernel memory (or maybe they merely change a pointer, I don't know). The point is that for each and every iptables line in a script, this procedure takes place. iptables-restore doesn't suffer from this drawback, BTW. You'll notice the COMMIT statement at the end of the output of a file created with iptables-save. However, I think you need to have a considerable number of rules for the effect to become as noticeable as you say, even on a P133.. But I haven't checked it out on that kind of a machine yet. the box would be open during those 15 seconds.

What puzzles me, is how filtering based on information received from my ISP (the local IP) might give additional protection against a spoofing via the same ISP. If someone manages to attack the servers at my ISP and manages to spoof an address, how can I trust ANYTHING which is coming from there. In this case, the local IP which is handed out via DHCP.

Oh, I wouldn't trust anything (purportedly) coming from the ISP. You don't have a choice but to accept their DHCP lease, though. There is no alternative other than to get a fixed IP address[1].

I bluntly changed the SuSEfirewall2 script to allow traffic with a local destination for any of the local IPs I might get (a query to whois gave me all local addresses I may get from my ISP) even before the connection is made. As long as the destination is within this range, this prevents me from having to reload the firewall rules when I connect to my ISP. I don't expect my ISP to change this range very frequently, so this should (and does so far) work most of the time. Am I missing something important here?

Define important. But you're probably not risking terribly much more. I believe you could filter based on the exact destination address and not experience dropouts simply by inserting the entire rulebase with the modified IP address in front of the old one, then deleting the 'old' rules. You'd have to be careful not to miss any, since you can't use the flush command. I guess this may not be possible with SuSEFirewall2, but I can't say -- I haven't used it myself yet, up to now I've always rolled my own. Cheers Tobias [1] This general statement if, of course, not entirely true. It is absolutely possible to create 'secure' mechanisms for functionality equivalent to DHCP. But you probably won't find any ISP who will cooperate.