| > There is no realistic way to hijack DSL connections en-masse So, exactly what people always say exactly up to the point where someone demonstrates the exploit chain? > and an attacker skilled enough to compromise an entire ISP to the point they can start doing these sorts of things has far better options available to them than anything we're talking about here. So ... exactly what people always say exactly up to the point where someone launches some malware? > There's a huge difference between mass-deployed malware and complex targetted attacks, which is a point you seem to continually miss in this thread. Except there really isn't. Yes, obviously there is a difference, but you can't measure how well an attack can be scaled based on how well it has been scaled. Now, deploying rogue DSLAMs sure is really impractical to scale, so that's not a concern other than for targeted attacks. But abusing misconfigured ISP networks might very well be easy to scale under the right circumstances. Mind you that the attacker doesn't have to be an actual neighbour, it might very well be enough to compromise one machine in a neighbourhood and then start attacking the neighbourhood from there, and if this is a misconfiguration of a large ISP, you might be able to just leverage an existing bot net to compromise large parts of their customer base. > More verbosely this could have been expressed as "NAT prevents inbound connections unless you have a NAT device that for some reason accept incoming packets for which it has no session May I rephrase this slightly for clarity? "NAT prevents inbound connections unless it doesn't happen to be paired with a stateful firewall." Erm ... yeah, thanks for making my point for me? Except the actually non-confusing way to put this is "NAT does not prevent inbound connections, but stateful firewalls do", obviously. > and pick a device on the private network to route these packets to Could it be that you just don't even understand the attack? This sounds like you think that the owner of the router would have to explicitly configure a target that could be attacked or something? If that's how you understand it, you might want to brush up on how IP routing works. > This "unless" is not normally needed though, as this is widely regarded to be a sufficiently difficult thing to achieve it's not worth mentioning. Erm ... in other words: People are generally mistaken about this? Yeah, I agree. > On every consumer firewall/NAT box I've ever seen, it was possible to configure firewall rules. As in, if you want to make some internal service publicly reachable, you have to separately set up a "port forwarding rule" and a "firewall rule"? That sure is how professional equipment/software does it, but not something I have seen in home routers in a long time. > I also note that although you've presented a couple of ways you might be able to send arbitrary packets at the public IP of the NAT device No, I haven't. I have been talking about sending packets to the private IP addresses, the public IP address is completely not involved in any of this. > this isn't yet sufficient to manage to connect to arbitrary machines behind the NAT device - you must also find a way to force the NAT device to accept packets for which it has no existing session. Yeah, it seems like you don't understand IP routing or how the attack works. No, you don't. You just don't. That's not how NAT works or how IP works. Unless there is a stateful firewall on that device, in which case removing the NAT does not change anything about being able to establish inbound connections. To take the example of a common VLAN with your neighbours: What you need is the MAC address of the WAN interface of your neighbour that you want to attack. You might be able to just guess it, or you could find it via an ARP request, or maybe you just can see some random packets leaking from the switch. Then, you send an IP packet with your public IP address as the source IP address and your MAC address as your source MAC address to their MAC address as the destination MAC address and their internal IP address as the destination IP address. Their router, being an IP router with NAT but without a stateful firewall, will check their NAT state for the connection, not find it, check NAT rules, not find any either, therefore not rewrite anything, then do a routing table lookup which says that it should be delivered on the LAN interface, and then, potentially after an ARP lookup, deliver it to the LAN. That just is how IP works. Again: unless there is a stateful firewall on the device. |