[TriLUG] counting NAT'ed hosts on the Internet

[Mike Johnson]

Greg [gregbrown at mindspring.com] wrote:
> Did anyone else see the article on slashdot yesterday about counting
> hosts on the Internet behind NAT'ed firewalls?
> 
> <"http://slashdot.org/articles/03/02/05/2129218.shtml?tid=95">

Yeah, I read it at lunch today (mostly because you asked this question -
I had planned to read it, but was putting it off).
 
> But he really didn't touch much on tunnels and IPsec (but I only skimmed
> the article, but I don't think he talked about it).  Anyway, take the
> scenario I set up a while for a local small office:

That's because tunnels and IPsec weren't the topic of the article. :)
 
> 1. Linux firewall - loaded with squid and ssh
> 2. machines on the LAN (macs, in this case) created a tunnel to the
> firewall using SSH.  The purpose of this was to encrypt web traffic
> which was floating around over 802.11b network.  Web browsers were
> configured to use a proxy (in this case 127.0.0.1 and port 8080).  Squid
> was listening on port 8080 and when the client requested a webpage, it
> went from the browser to port 8080 on local 127.0.0.1 where SSH picked
> it up, encrypted the packet, delivered it to the firewall (and squid)
> where squid then sent the packet along via port 80 on the firewall.
> 
> In the case outlined above I would think that the firewall would then
> re-write every packet since the proxy server was actually doing all the
> network queries.  It seems that this would be the case, but I don't have
> a protocol analyzer lying around to test this out.  
> 
> What do you think?  Yes?  

Well, it's not so much that the firewall is re-writing the packets as it
is that the firewall is making the requests itself.  Your clients ask
the proxy to fetch a web page on their behalf.  The proxy makes the
request, and returns it to the browser.  The actual packet stream from
the client terminates at the firewall - it is not translated and passed
along.

To test this, you don't need a piece of hardware.  Fire up two copies of
tcpdump on the firewall and log the results to a file, then peruse them
offline.  Basically, you'll see a request from the client to the proxy
with one set of (incementing, most likely) IPids, and then the proxy
will originate a request with a completely different (again, most likely
incrementing) set of IPids.  Another request will come along from a
different client (again, different, incrementing IPids) and the proxy
will make a new request.  It's entirely likely that the IPids the proxy
uses pick up where the previous request left off.  So, for instance, the
proxy uses IPids 1-10 for the request from client one, and then IPids
11-20 for client two.

In the end, it will look like one system with a very busy web browser.
 
> What about IPsec?  If the Mac clients were configured via ipfw to allow
> ONLY protocols 50 and 51 and port, uh, whatever the IPsec TCP port is,
> and the firewall supported IPsec and the Macs could connect via a IPsec
> client to the firewall then ALL the packets on the network, regardless
> if they were staying on the LAN or hitting the Internet/WAN, would have
> IP ID fields set only by the IPsec Firewall.  Correct?

I cannot say for sure, but my guess is that this would expose you to the
IPid method described in the paper.  The packets would arrive at the
gateway, be stripped of their IPsec headers, and passed along, most
likely with their original IPid's still in tact.

Mike
-- 
"If life hands you lemons, YOU BLOW THOSE LEMONS TO BITS WITH 
 YOUR LASER CANNONS!" -- Brak

GNUPG Key fingerprint = ACD2 2F2F C151 FB35 B3AF  C821 89C4 DF9A 5DDD 95D1
GNUPG Key = http://www.enoch.org/mike/mike.pubkey.asc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: <http://www.trilug.org/pipermail/trilug/attachments/20030206/7330c185/attachment.pgp>