All,
I've noticed that if someone performs a traceroute to a 44net address routed via an IPIP tunnel on OpenWRT versions 14 or 15 (tested) results in the router giving the Public, Commercial IP address of the device instead of a 44net IP on tunl0, or any assigned forwarded interface.
Without intricate detail, this is by design of the Operating System, as the kernel re-packets an ICMP TTL Exceeded, and seems not to connect that new pack as RELATED to the Received Packet in which the TTL had Exceeded. This is fine when all local IPs are Private IPs, or should be forwarded via the Kernel's Gateway; but as they are not, and the only gateway the kernel knows is the physical WAN. The ICMP TTL Exceeded Packet is given the Kernel's source address (with Gateway), and sent hence - a leaked TTL Exceeded packet.
Reason: the least computationally difficult method to protect our gateways from rogue packets is to not publicize/announce our Public WAN-facing IP address.
In order to prevent this, a RAW Packet Filter rule for all packets received via tunl0 < 2 can be created, preventing processing of TTL exceeded packets for non-44net IPs:
iptables -t raw -I PREROUTING -i tunl0 -m ttl --ttl-lt 2 -j DROP iptables -t raw -I PREROUTING -s 44.0.0.0/8 -d 44.xxx.xxx.xxx/xx -i tunl0 -m ttl --ttl-lt 2 -j ACCEPT
Those using OpenWRT, please test and confirm issue and its fix.
73,
-Lynwood KB3VWG
Rob and Marius,
When considering:
- I did realize other spoofed packets may enter and route. I've been researching that as well, and have thus far only filtered against someone spoofing an IP in my subnet ONLY
- I considered that other 44 operators know our Public IP (Rob noted this), I did not consider them as a part of the assessment, as we MUST know one another's Public IPs to properly route traffic
- We do not publicize our IPs; but considering it's possible, Marius' solution is the only reasonable answer for all cases (i.e. to only accept IPENCAP on the real WAN). Although, afterwhich an operator can only use 44 addresses routed to the PHY with that Public IP address
- While only accepting 44net traffic on the tunnel could prevent spoofing to Public addresses, it only prevents spoofing to one another by trust, and others through the same Security by Obscurity of not publicizing the Public IP addresses
- Lynwood KB3VWG
I spent some time with this 44 spoofing issues and reached some conclusions...
First of all, spoofing a 44 address while being outside the 44 tunnel system and using one of its addresses is actually not possible. Beacuse even if the 44 destination in a subnet can be reached via whatever means, the replies will either go directly to the proper tunnel, which hosts will ignore them since it did not originate that traffic, or will go through the local gateway and through amprgw, which drops 44 to 44 traffic (which is good). So a no go here.
Second, let's say the attacker implements a direct IPIP tunnel spoofing. Since its routes are not in encap/rip, there will be no return route other than the default route or the original proper tunnel. While the default route will usually NAT to the public IP, the original src address is lost and the communication will be probably compromised and the now orphan replies sent to the non-spoofed originator by amprgw. Again no go here.
Going up one level, let't assume that the attacker could hijack a 44 subnet by injecting some fake BGP route into the global table. In this case, it will affect only the bgp-announce subnets or undefined network ranges, since the others are protected by the internal routings of the full mesh.
So I don't think that spoofing is an efficient attack path in our case, allthough, by tracking the gateway traffic, it seems that there are either a lot of tentatives outside, or that some persons use our 44 address space as private space, and there is some traffic leak in their configuration.
Marius, YO2LOJ
Rob,
This worked, I will add it to the Wiki.
You can change the behavior in this case: echo 1 > /proc/sys/net/ipv4/icmp_errors_use_inbound_ifaddr
- Lynwood KB3VWG
On 02.02.2016 04:11, lleachii--- via 44Net wrote:
I've noticed that if someone performs a traceroute to a 44net address routed via an IPIP tunnel on OpenWRT versions 14 or 15 (tested) results in the router giving the Public, Commercial IP address of the device instead of a 44net IP on tunl0, or any assigned forwarded interface.
You can change the behavior in this case: echo 1 > /proc/sys/net/ipv4/icmp_errors_use_inbound_ifaddr
73, Jann DG8NGN
-
Jann Traschewski -
lleachii＠aol.com -
marius＠yo2loj.ro