RE: [suse-security] SuSE personal Firewall 1.1-4 / ppp*
The antispoofing rules, at least, need to be rewritten when the IP address changes.
AFAIK "antispoofing" means to drop packets with source addresses which come from the wrong interface.
Not quite. Spoofed IP packets have false addresses, i.e. source or destination addresses or both. When talking about anti-spoofing, people usually use the terms 'egress filtering' and 'ingress filtering' to mean filtering of outbound and inbound packets respectively. When considered alone, it makes sense to check both source and destination addresses. The source addresses are of higher importance, though.
At least in a common configuration (internal LANs with static addressing and a dialup/DSL/cable uplink) I don't see why the antispoofing rules should change when the local IP address changes.
If you wish to use the IP address of local machines (including and sometimes restricted to the gateway) as qualifiers in your packet filtering rules, you need to update those along with the IP address.
And let me repeat, if you don't trust your ISP, you don't know if you get the correct IP assigned, but if you do, you know that the ISP router will route the correct packets (destination based).
Have you never seen a confused or misconfigured router? What happens when someone breaks into the ISP and changes the configuration of their equipment? Break into an ISP router and configure it to establish GRE tunnels and you've got some very hefty potential problems. It's not about trusting or not trusting the ISP. The problem is that you have practically no influence on their security. OTOH, you have full control over your own systems and you can apply security measures to suit your degree of paranoia. With the ISP's equipment, your options are considerably fewer, very often none.
Well, and since the source addresses are unaffected by your local IP, nothing changes. Usually you may get just *any* IP assigned, and by that you can filter with any as local IP.
That's possible and swinging the balance between security and ease of use towards the latter by some measure I don't wish to discuss. If you can't or are unwilling to do without the IP address information, you need to update the packet filter configuration whenever that changes.
Since at the last time we had such a thread and nobody had a situation requiring rule rewriting (not counting very exotic setups), I still think there is no need for such rewrites in a clean configuration.
As long as everything is properly configured, yes. But security has a concept called 'defense in depth'. If you follow that concept, you will have redundant, overlapping mechanisms. All but one are unnecessary as long as that one left doesn't fail. But what if it does? This, of course, leads to compromise. Those with the need for high security use many layers of defence, those with assets of lower value (or those that don't care or know better) employ fewer layers. In the end it's always a question of cost. Cheers Tobias
* Reckhard, Tobias wrote on Tue, Apr 23, 2002 at 13:56 +0200:
AFAIK "antispoofing" means to drop packets with source addresses which come from the wrong interface.
filtering of outbound and inbound packets respectively. When considered alone, it makes sense to check both source and destination addresses. The source addresses are of higher importance, though.
This makes a difference only, if the received packets may be handled different depending on the destination. I don't think that common home setups (who work with dynamic IP) have such differences. Destination RC1918 will be dropped from *ppp* in any case, and if a port is closed or open does not depends on the actual source. Either you may connect i.e tcp:80, or not, no matter what the local IP currently is.
If you wish to use the IP address of local machines (including and sometimes restricted to the gateway) as qualifiers in your packet filtering rules, you need to update those along with the IP address.
Yes, of course, but this is exactly the point, where I don't see advantages.
And let me repeat, if you don't trust your ISP, you don't know if you get the correct IP assigned, but if you do, you know that the ISP router will route the correct packets (destination based).
Have you never seen a confused or misconfigured router?
Yes, but malformed requests are not working anyway, except if they are "pretty malformed" when:
What happens when someone breaks into the ISP and changes the configuration of their equipment?
Then you don't trust your ISP. But in this case, the intruder may assign any IP it want's to your dyn IP interface. She may make the ppp assign an RFC1918 address or whatever. I think, this would confuse really a lot of things and may even lead to some failures, since a dynamic IP filter may drop packets (if the rules are not dedicated for the external interface, for instance).
Break into an ISP router and configure it to establish GRE tunnels and you've got some very hefty potential problems.
Well, but you should filter unneeded IP protocols (as well as TCP ports) at all, no matter if their IP is correct. And this attacker may spoof the correct address always; in many cases using the correct IP would be much more easy than the wrong one. So the intruder does not get advantages (no one I'm aware of I mean).
It's not about trusting or not trusting the ISP. The problem is that you have practically no influence on their security.
Well, and so an intruder can assign your PPP stack the needed IP anyway. So why not block any destination IP with non-public services?!
That's possible and swinging the balance between security and ease of use towards the latter by some measure I don't wish to discuss. If you can't or are unwilling to do without the IP address information, you need to update the packet filter configuration whenever that changes.
I think, in this case, you shouldn't think about addressing, but on packets coming from interface *ppp* or similar. And based on such properties a filter decision should be made, and not by dynamic rewriting, which has disadvantages as short outages.
As long as everything is properly configured, yes. But security has a concept called 'defense in depth'. If you follow that concept, you will have redundant, overlapping mechanisms. All but one are unnecessary as long as that one left doesn't fail. But what if it does?
No, don't take me wrong. Of course you're right. But in this particular case, I don't see an attack szenario which would become impossible by such a setup. Another important point is KISS: keep it simple, stupid. If you have a firwall rule that blocks anythink on *ppp* except a short list of allowed things, it's much more easy to overview/supervise, check and verify the setup. It's much more straightforward. It's based on the natural feeling of the problem (filtering packets on an external interface), which is more intuitive than filtering packets with uncommon, compliciated IP addresses never seen in any setup script.
This, of course, leads to compromise. Those with the need for high security use many layers of defence, those with assets of lower value (or those that don't care or know better) employ fewer layers. In the end it's always a question of cost.
You assume that "my" setup is more insecure but more cheap. I think this way is not more insecure, but more easy to administrate - and by this more secure - AND more cheap :) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
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). 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. 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? Regards, Arjen
participants (3)
-
Arjen de Korte -
Reckhard, Tobias -
Steffen Dettmer