Remotely Counting Machines Behind A NAT Box 618
Overtone writes "Steve Bellovin of AT&T Labs Research has published a paper showing how to remotely count the number of machines hiding behind a NAT box (in IMW 2002, the
Second Internet Measurement Workshop). Your friendly DSL or cable broadband provider could implement this technique to enforce their single-machine license clause. Bellovin explains how to change the NAT software to defeat the measurement scheme, but the fix is complicated and unlikely to appear in commercial home gateways anytime soon."
Just another way.... (Score:1, Informative)
Not a bad thing (Score:5, Informative)
Still be screwed by proxies, though...
Re:Silver Lining? (Score:1, Informative)
Google cache link to the site (Score:2, Informative)
It's already here (Score:5, Informative)
It's already here: SpeakEasy [speakeasy.net].
Their TOS [speakeasy.net] explicitly states:
"Speakeasy believes in the right of the individual to publish information they feel is important to the world via the Internet. Unlike many ISP's, Speakeasy allows customers to run servers (web, mail, etc.) over their Internet connections, use hubs, and share networks in multiple locations."
Mirror of Article (Score:2, Informative)
http://www.public.asu.edu/~jmellen/fnat.pdf. [asu.edu] Have at it!!
Re:It's already here (Score:4, Informative)
Re:Not a bad thing (Score:1, Informative)
Re:Not where I'm from (Score:2, Informative)
Re:Not where I'm from (Score:2, Informative)
Re:this sucks (Score:5, Informative)
1. Use proxies instead of NAT and proxy transparently if needed. Yeah, I know, none of the P2P download sucker shit as it does not have proxies but such is life.
2. Use OSes with better randomisation of IP IDs. This is a tuneable parameter on most OSes and after you have turned it on the graphs are no longer so pretty.
Re:How this works (Score:4, Informative)
One of the grsecurity patches for the kernel already gives Linux the random IPid field.
Re:what if they are chained? (Score:5, Informative)
In reading the paper, it is apparent that this is not a particularly cheap thing to attempt. I can't see how it could be easily automated and deployed on a large scale, even assuming someone could be sufficiently bothered to do so.
If you want protection from this, you're going to need to do some serious work on iptables to add tracking of fragments to the connection tracking code and to rewrite the field on outbound packets to some psuedo-random value. Interestingly this is the "correct" thing to do anyway - otherwise it is theoretically possible to generate two packets with the same id, both fragmented from different internal hosts to the same destination, and screw up the fragmentation reassembly at the receiver.
Tim
Re:Is this really a big deal? (Score:5, Informative)
With franchise agreements to the cable companies, not necessarily true.
I don't see anything but a poor rationalization in your arguement suggesting that it's not *YOUR* fault that you NEED to break your contract
What about the chance that the contract may be illegal? There's the nice little FCC regulation that the cable company/phone company can't say squat about what happens inside your house provided you don't get services you don't pay for (You're paying for one IP, not one computer in reality) and you don't degrade the service of others.
Patch Linux! (Score:2, Informative)
Re:what if they are chained? (Score:5, Informative)
Another user already posted that there's already a patch (or kernel option) for linux to do random ipid's just like BSD does.
This is more an admin utility than a policing tool. Just kick back, get yourself a beer and watch the knee-jerk reactions and paranoid theories from all the nerds who think the man is out the get 'em.
Re:Protection for Linux (Score:5, Informative)
While you MIGHT be able to use the "mangling" abilities of iptables to rewite headers on the way out -- I suspect the key is monitoring fragment IDs on the way IN. This would be by an upstream connection, before the packets got to your machine. Thus, there isn't a damn thing you can do about it.
Match an outgoing request (via IP destination) to incoming fragments (via IP source and IPid). Not only could the monitor build a map of the destinations, they could reasonably determine via statistical analysis of the access times and frequencies, how many machines are behind the NAT making the requests.
That's probably the long, hard way. I need to finish reading the article, first.
Today and tommorow (was Re:Silver Lining?) (Score:5, Informative)
CATV (cable) used to be the same way.. you day to pay extra for each TV. And then they stopped doing that and you paid for *service* of the signal.
Now here is where it gets tricky, unlike POTS and analog CATV the line is hot or its not (so to speak), broadband you actually have discrete data you are passing around. This should be the *service*. However it could end up being a pay as you go service (bad for the users, good for the money grubbers) or a limited throughput 'unlimited' service (which is mostly how it is now). Currently I don?t see a metered usage model flying right now and this is why:
Everyone that adopted broadband early wanted it (and could get it) go it. Dialup services are cheap and unlimited. If you start charging for broadband based on usage you aren?t not very attractive to those people you want to take away from dialup who are complacent and will cope with what they have. A metered service is not (in consumers minds) a *NOT* better value than an unmetered service.
As we know there is a mega glut of fiber, broadband should be getting cheaper rather than more expensive.. but that?s another article. Its going to be hard to justify metering people when there is so much capacity unused. (hopefully supply and demand will work out here).
Now this is what is going to happen, when a critical mass of people stop using dialup, and then modems stop coming standard in computers, and then the broadband guys think they have a captive audience they will get everyone in the cartel on board and raise rates and meter usage. What?s worse is that they will claim there is a lack of long haul bandwidth, which probably wont be true, because as the broadband market picks up they will still be doing expansion of the network because of the expectation of even larger amounts of growth.
Conclusion, this are probably good for the short term, *VERY* bad for the long term.
PS the document was spell checked for those with delicate constitutions.
related links on google (Score:2, Informative)
_DON'T_ USE THIS PATCH (Score:1, Informative)
just download the grsecurity.net patches and everything should be fine
Re:Is this really a big deal? (Score:5, Informative)
I'm not sure what world you're living in. It IS MOST ASSUREDLY my local ISP's fault that there are not multiple provider's in my area.
Verizon ran every dirty trick in the book to stop me from getting access through DSLi (out of Florida, who had an EXCELLENT TOS) instead of buying Verizon's restricted, overpriced DSL in North Carolina. I fought with them for over 14 months. I called the friggin' Utilities Commission on them. Unfortunately, by the time that bore fruit, every intelligently run provider had read the writing on the wall -- there's no way to make a profit when every single customer has to fight through the SUC for over a year, for God's sake.
The reason I am stuck with crappy TOS is because of Verizon, straight and simple. Verizon covers something like 20% of the country. Most of the Baby Bells aren't any better.
I'm not saying everyone who has a NAT fought with a Baby Bell for a year. But most of them have been cheated out of a decent, affordable TOS by one.
Since virtually none exist because of illegal behavior, you shouldn't be so surprised or indignant that many folks choose to get around them.
Re:How this works (Score:5, Informative)
The field they are using is the IP id field, which exists in all IP packets (including UDP, ICMP, whatever), and which is used for low-level packet reassembly. On many OS'es, this is a globally increasing counter, i.e. two distinct connections on the same machine share the same counter, but two connections on different machines do not.
Workarounds:
Re:this sucks (Score:4, Informative)
Re:_DON'T_ USE THIS PATCH (Score:2, Informative)
Besides the patches at grsecurity.net do the same thing, but use their own random number generator (ip_randomid) rather than the kernel-provided one (net_random).
Their patches are better, of course, since they integrate with the kernel proper and provide a kernel option. The point of my post was to emphasise how trivial the change effectively was
Also, anyone patching their kernels with things they got off slashdot has far greater problems than being NAT sniffed
Re:what if they are chained? (Score:2, Informative)
But in your case (and mine), TW Austin reps have said they don't care how many boxes you NAT as long as you're not breaking their 'naughty user' upload threshold. Join the mailing list. [yahoo.com]
Re:what if they are chained? (Score:3, Informative)
What do these clauses typically look like? (Score:5, Informative)
here's one. [sssnet.com]
Seems a little arbitrary, but they're small fry. let's go bigger:
here's another. [yahoo.com]
I think this bit applies to the question at hand (emphasis is mine):
How does this imply that you can't share a DSL connection? OTOH, it explicitly says that sharing a connection is OK.
however, if we look to AT&T DSL [att.net] TOS, they are somewhat more restrictive:
A little tougher, but it doesn't actually rule out connection-sharing entirely- just requires that AT&T grant you permission, right? So they must have a process for granting the approval, and a list of approved equipment.
Since I'm bored today, I called them up. I pointed the nice lady at their TOS, section 8(a), and asked if she could provide me with a list of AT&T approved equipment, and/or the approval process for home networking. She put me on hold for a bit. When she came back, she told me that AT&T DSL is not the same as AT&T WORLDnet DSL, and i had the wrong phone number- but WORLDnet doesn't allow any kind of connection sharing- and she'd happily transfer me to the REAL AT&T. The second phone monkey had no idea what I was talking about- ditto the 3rd. Neither of them could understand why I would want to ask questions about their TOS if they couldn't even deliver service to my residence. The fourth phone monkey told me that they don't support any kind of multiple connection, and that the "grant you permission" line is in the contract for things like automated security systems that call the police department when someone breaks into your house.
So. Score: SBC +1 (but -1 for their stupid 'frames' patent), AT&T 0. Interesting article, but since I'm on SBC, i won't be changing my NAT settings...
Re:How this works (Score:4, Informative)
Re:This is a mute point for most operating systems (Score:3, Informative)
pf was designed into Open for 3.0, which would be about 18 months ago, I think. This makes it one of the newest and most recently designed firewalls. (Its a whole other topic of whether its the best, ipfilter has some loyal devotees).
FreeBSD's stack does do a pseudo-random ipid, but of the two firewalls available for FreeBSD (ipfw and ipf) neither rewrites the IPID, as is the case with Linux as far as I know.
So if you have a NAT'd LAN of FreeBSD boxes, don't worry about. If you have an OpenBSD 3.0 or greater firewall, don't worry about it. Otherwise, the technique outlined in the paper will work and the boogeyman is being dispatched to your CO as we speak!
This is already being done by AT&T. (Score:2, Informative)
About nine months ago I got into a bit of a sticky situation at work. One of our clients was running three PCs behind a NAT we installed. The DSL provider shut them off repeatedly for having "more than one machine per connection"
Mind you, this was AT&T business-class SDSL. Static IP, 768k/768k. They were certainly paying enough for it.
I talked to the ISP. The very rude and condescending rep told me they have software that can detect multiple machines behind a NAT, and that the customer had been warned and disconnected multiple times for it.
(No, we didn't take responsibility, because the customer didn't inform us the contract precluded NAT usage)
I asked the rep how they could detect this. The rep didn't know but said it was something called Option 82. I'm assuming this is DHCP Option 82, Routed Bridge Encapsulation. I don't see where RBE has anything to do with this, unless they were using it to sniff the connection between the NAT and the DSL router.
Re:Maybe not home gateways... (Score:2, Informative)
From what I understand, there is no problem if you're using a 2.4 series kernel. The article itself states that the ID field is set to 0 by the Linux network stack. There is no data to analyze/extract host info from, and your hosts are safe.
Re:What do these clauses typically look like? (Score:3, Informative)
Remember, outside of the support issues, supporting this technology makes their life EASIER. They limit your up and down rates, and your number of connections to the news server (4 simultaneous) so why limit the number of machines? The whole point of these devices is that one machine looks like multiple machines, so they have no reason to care.
If you want multiple IPs, then you have to pay more.
Re:this sucks (Score:2, Informative)
grsecurity [grsecurity.net] can do this for linux.
I do believe you missed the point (Score:1, Informative)
Since the vast majority of packets are not DF, this really doesn't qualify as scoring another one for linux.
IPPersonality.... (Score:4, Informative)
Re:It's already here (Score:4, Informative)
No Real Data (Score:2, Informative)
Re:Protection for Linux (Score:4, Informative)
No, the paper argued that when the IPid field is zeroed, like Linux does, NAT information can still be leaked. Consider what is says on p. 5:
In such situations, the NAT box can rewrite the IPid field freely, since there will never be any reassembly. Setting it to 0, as Linux does, is one possibility; as discussed below, in a NAT situation this can leak information, and hence is probably undesirable.
And then:
Some hosts never use Path MTU Discovery; some use it only for TCP. A NAT that treated DF packets differently than non-DF packets for the same protocol would thus leak the fact that at least two different policies exist behind it.Therefore, to preserve privacy the NAT should do the same thing send a unique IPid field on all packets.
So they're claiming that it is possible to detect whether a Linux host is using NAT, because packets with the Don't Fragment bit set are treated differently (IPid=0) than the ones with cleared DF bit (IPid=random).