re: original bypass question
Well, there are a few methods to bypass NAT that I'm aware of...here goes:
1. VPN
Meaning, in all VPN implementations that I'm aware (which is confined to the Cisco world....PIX-PIX, PIX-router, router-router, PIX/Router-Client) NAT must be bypassed in order for IPsec tunneling to work.
This is because you're basically building a private IP/LAN - LAN tunnel, which the endpoints indentifying one another on public IPs. Like this:
HOST A - - - PIX 1 - - - - WWW - - - - PIX 2 - - - - HOST B
So, when host A wants to talk with host B, PIX 1 erects a tunnel with PIX 2 using publically routable IPs assigned most likely from the ISP(s). But, HOST A and HOST B speak using their normal private IPs. NAT is bypassed by configuration b/c translating the private IPs to public IPs, as in the case of PAT or Global NAT, will prevent crypto-acls from identifying the private IP traffic, encrypting it, and sending it across the established tunnel.
This is again the intention of the setup, so I don't think it is what you're after...
1b. The reason i ranted on above is to explain how any type of tunneling will bypass NAT. HTTP/SSL tunneling, TCP/IP covert channels, ICMP tunneling are all additional methods I can think of...
2. Source-routing
This is when packets coming from "outisde" the NAT device contain crafted/forged source & destination header information, thus dictating how the packet(S) should be routed on the other side of the device.
To pull off source-routing you'd have to possess intimate knowledge of the target topology- both public-facing and private-facing. Sending forged packets for a network/host that doesn't exist within the private architecture isn't going to do well for you.
Also, stateful packet inspection will/should prevent this b/c packets are going to be compared to translation/connection tables in the device. It is highly likely that the crafted/forged packets your source-routing with won't match a valid connection entry in the table and will be dropped.
Does that help in anyway?
Cheers,
<0
Re: re: original bypass question
Quote:
Originally posted here by lessthanzero
Well, there are a few methods to bypass NAT that I'm aware of...here goes:
2. Source-routing
This is when packets coming from "outisde" the NAT device contain crafted/forged source & destination header information, thus dictating how the packet(S) should be routed on the other side of the device.
To pull off source-routing you'd have to possess intimate knowledge of the target topology- both public-facing and private-facing. Sending forged packets for a network/host that doesn't exist within the private architecture isn't going to do well for you.
Also, stateful packet inspection will/should prevent this b/c packets are going to be compared to translation/connection tables in the device. It is highly likely that the crafted/forged packets your source-routing with won't match a valid connection entry in the table and will be dropped.
<0
By the fact that several spam net send messages have made it through I doubt there useing much stateful firewall filtering if any. Perhaps these connections are being made through a sort of source-routing bruteforcing, i.e. sending packets to the perimeter with methodically random private addresses for the next hop. There's not that many private network ranges, and since the private addresses are only one hop from the perimeter router, it shouldn't be to difficult, at least in theory. I'm gonna try to devise a method to test whether it works.