So basically you're stating that, 1: By default, sending UDP packets from inside to outside is allowed, but not from outside to inside. 2: UDP packets sent outside add an allow rule to the firewall using the exact source and dest ip:port (but swapped to match return traffic) 3: The firewall doesn't translate addresses or ports. (4: If the rule generated in #2 hasn't been used for a certain period, remove the rule)
This essentially mean that any communication must be initiated from the inside network. And yes, for the lack of translation, you could punch holes and make connections with these rules. It requires cooperation between the peers and to know of each other what to connect to. If there's no cooperation, there will be no bidirectional communication.
Importantly, a host can't actively punch holes in the remote firewall, because it can't trigger rule #2 from the outside, and there's no other way to allow incoming traffic. Therefore this is not a security issue. In order to receive packets from a host a local machine must have established permission for incoming traffic by sending a packet to the specified port and ip. There are a number of options here: 1: The client is purposefully connecting. This can be either intended behaviour for peering, or it can be a form of coercion, indicating an exploit elsewhere, and thus not at issue here. 2: The attacker can guess a functional source/dest host/ip, and forge a packet accordingly. This is easy when you're able to intercept communications. Otherwise you have to a: Brute force the 16-bit source port b: Get the device's MAC address, or at least a valid IP (if the host is properly configured it will not initiate connections from the mac-based IP, but not everybody does that) c: Guess a service that's being used. If you do a bit of research DNS servers are for instance easy to guess. d: Hope there's no address forgery filtering on the route. (e: know that such a packet will actually have effect on the host, though this only matters post-firewall) This is considered difficult, but not impossible. The receiving network software (point e) is where the security should eventually be completed.
If the firewall doesn't do full host+host+port+port matching, like you see used in many NAT-to-NAT punching with an intermediate, you get increasingly less difficulties figuring a-d, and this certainly is an unnecessary increase of slack in security.
_________________ "Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie [ My OS ] [ VDisk/SFS ]
|