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.
Of course. Packets with valid destination addresses, i.e. those with your gateway or internal machines as destinations pass the check, those with destinations not in your network fail. Note that I'm looking solely at anti-spoofing/sanity check type rules here, of course you typically need more than just these.
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,
Why will packets with destinations in RFC 1918 address space be dropped anyway? I've a feeling you're making assumptions that other rules are in place to take care of that. I'm not.
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.
Umm.. ah, yes, I think I see what you mean. And you are right, of course, that IP packets to invalid IP addresses should disappear at some point within your network, preferrably on the packet filter itself because it either uses reverse path filtering or doesn't have a valid route to the packet's destination. This applies in an entirely general fashion only if that network is properly configured, though. And the cost of performing routing sanity checks by filtering on destination IP addresses is a relatively cheap way to avoid any such dangers. The cost lies in having to modify the rules when local IP addresses change.
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.
It's an additional qualifier and allows you to reduce the amount of trust you need to place in other components, such as the routing code, the reverse path filter, probably some parts of the TCP/IP stack and, if applicable, your internal boxes. Perhaps it's similar to the question whether one should use a general iptables rule permitting anything with states RELATED and ESTABLISHED or employ specific ones that correspond to the individual --state NEW rules you have. The former is perfectly fine as long as you trust the iptables state engine completely. The latter still requires some trust in it, but a lot less, since you're basically just adding state to the stateless rules you'd had with ipchains. You're not replacing your ipchains logic with iptables, but rather adding iptables' state to ipchains. It's more expensive because it creates longer chains, but at least has the potential for higher security. The choice is up to oneself.
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?
No, that's not the only scenario. A router could well be confused or misconfigured enough to forward RFC 1918 addresses, for example, and in some cases this might not even be confusion or misconfiguration at all. It's foolish to assume that an ISP will perform any form of packet filtering or IP sanity checks for you unless you've got an SLA.
Then you don't trust your ISP.
The problem is, how can you detect if and when someone breaks into their equipment. In general that is impossible. So the default stance to take is not to place trust in 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.
If that's what they want to do, yes. If not, why should they? They're not forced to use the attack you deem most likely. They might even not attack you at all. Unless their aim is a short-term all-out attack on you, they'll try to be as inconspicuous as possible.
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).
This is very likely and therefore not an attack that intelligent attackers would employ. This is all entirely hypothetical anyhow, I don't think it makes sense to discuss hypothetical situations we don't know ebough about. I am stating that there is some potential benefit to being able to use many qualifiers in packet filtering, i.e. to be able to define very finegrained rules. I am *not* saying that there's an actual benefit in any given situation. This depends entirely on the exact situation and the definitions of benefit, risk and cost in that situation.
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.
Oh, the GRE tunnel doesn't extend to your equipment, just to your border router. However, it starts out on machines under the attacker's control. It enables him to transport packets to your border that wouldn't have made it there across the Internet. Packets with RFC 1918 destination addresses, for example.
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).
He can spoof as an inside machine, for one. He can also send the firewall packets directed at RFC 1918 hosts on your internal network. And those are just two examples. I don't wish to discuss them or any other specific attacks, I'm just pointing out that attacks are at least theoretically possible and you have options to defend against them. I prefer to be safe from theoretical attacks as well as those that are in widespread use. I am much more seriously worried about attackers with enough prowess to try promising but as yet theoretical attacks than script kiddies, though their sheer number makes them quite a problem, too.
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?!
Because that's not the topic here. We're talking about anti-spoofing/routing sanity check rules, not how to prevent access to 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.
That's an additional qualifier that it makes sense to use.
And based on such properties a filter decision should be made, and not by dynamic rewriting, which has disadvantages as short outages.
You don't necessarily have any outages, it depends how you implement the script that changes the rules. And if you don't want to filter based on destination IP addresses, be my guest and don't do it. I'm not trying to be a missionary here. I'm just saying that there can be some merit to using that information, I'm not saying it is that way in your case and I'm not saying it always makes sense. I am saying that there may well be situations where it does make sense.
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.
And maybe I don't either. But so what? Is security about defending against known risks only? No, it's not. Sound security attempts to protect against as yet unknown dangers by following principles of sometimes philosophical nature. And defense in depth is one of them.
Another important point is KISS: keep it simple, stupid.
Exactly, and it's almost always in contrast to the principle of defense in depth, since the latter involves the introduction of multiple defences, which pretty much always gives a more complicated system. It's in the balance of the principles that's applicable to a specific situation that the secret lies. There are no general answers or at least only very few.
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 :)
I don't assume anything. In fact, I am not addressing you at all. I am making the *general statement* that people who need high security (should) employ more layers of defense than those who are satisfied with less security. I am not saying where you fall, I am not even saying where the line between the two is. If you will, use the extremes and assume highest security to involve an infinite number of layers, effectively making communication impossible, and assume low security to mean no layer, i.e. involving no security at all. Everyone falls inbetween somewhere. Tobias