While I see what you're saying. It's still not "Spoofed".
The device in question receives the request. And then generates a response
with the src address of the egress interface of the device dst to the IP
and port that requested it... In this case. The GRE tunnel. Unless I'm
missing something here about replying to a request only on the interface
which it ingressed the device. And the fact that it's UDP. not TCP. So it's
fire-and-forget.
Thus, Nothing was ever spoofed. It just simply was returned from a
different interface of the same device. From our point of view. We saw the
packet of DNS-SRC>OurCustomer. And the other ISP, Which transported the
reply. only saw Customer-SRC>DNS-DST.
Obviously, This only works because it's UDP. And TCP would be broken.
Nick Olsen
Network Operations
(855) FLSPEED x106
Nope, what happens is I send from my IP address (lets say 10.0.0.1). I send a packet to 192.168.0.1. It has 172.16.0.1 as it's DNS server.
192.168.0.1 has a rule that says send UDP/53 packets I process to 172.16.0.1. Since i'm "outside" it's "NAT", the rule ends up taking the source IP, which isn't part of it's "NAT" set, and ends up copying my "source" IP into the packet, then forwards it to the DNS server.
172.16.0.1 is responding to 10.0.0.1 DIRECTLY.
It took me awhile in looking at this to figure out what was happening. Was interesting when you find out the 192.168.0.1 CPE was doing.
You may not call it "spoofing" as it's doing what it was supposed to do/configured to do, but it shouldn't be sending the packet with *my* IP address.
- Jared
Jarad is correct. There is lack of BCP38 filtering in the CPE ASN.
Either the packet has gone
"probe" -> CPE ->(*) recursive server -> "probe"
or
"probe" -> CPE -> recursive server -> CPE ->(*) "probe"
(*) indicates the packet that should have been blocked depending apon
how the NAT worked.
In either case the CPE ASN had failed to check the source address of
a packet. In the first case the source address of the query to the
recursive server. In the second case the source address of the reply
back to the probe after it had been through the NAT process.
Mark
While I see what you're saying. It's still not "Spoofed".
The device in question receives the request. And then generates a response
with the src address of the egress interface of the device dst to the IP
and port that requested it... In this case. The GRE tunnel. Unless I'm
missing something here about replying to a request only on the interface
which it ingressed the device. And the fact that it's UDP. not TCP. So it's
fire-and-forget.
No in this case the system is being hit with a MITM type attack
This is really broken. Do you have any idea as to why such rule is
implemented? I also heard that some CPE implement exactly the same logic
if one spoof src IP inside their NAT. I think that the Spoofer project
discards tests from the inside NAT, but maybe they track such cases?
Andrei