Slashdot Mirror
Remotely Counting Machines Behind A NAT Box
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."
For 'the man' to stick it you, and your wallet...
You mean Speakeasy?
http://216.239.57.100/search?q=cache:QZA0opGpxtwC: www.research.att.com/~smb/papers/fnat.pdf+&hl=en&i e=UTF-8
It's already here: SpeakEasy.
Their TOS 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."
In case this gets /.-ed (like it won't =| )...
http://www.public.asu.edu/~jmellen/fnat.pdf. Have at it!!
Producer: NEXT!!
Ralph Wiggum: Chicken necks
Yeah, my first question was, "Is this a problem?" I'm with Mindspring, and they don't seem to have any problems with multiple computers...mine are all wireless hooked to the DSL wireless router/switch....no 'caps' either that I know of....
Light travels faster than sound. This is why some people appear bright until you hear them speak.........
Verizon DSL in NJ told me a NAT was no problem, and they are willing to support certain brands... and sell them to you. Of course, that was probably a last ditch effort to give up trying to restrict users and instead make money off multiple computer some other way. With something like this, they could quickly change their minds again.
There are already several simpler ways:
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.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
One of the grsecurity patches for the kernel already gives Linux the random IPid field.
Wouldn't make a jot of difference. The current firewalls aren't rewriting the IPid field anyway, so adding an extra hop would not affect the analysis at all.
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
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.
"you're going to need to do some serious work on iptables "
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.
I don't need no instructions to know how to rock!!!!
History does not bode well for the broadband providers on this. If one recalls back in the day, the Telco (MA-Bell/AT&T) user to tack on an additional charge for every actual receiver (that you were forced to rent from them) on the phone line. For those who know POTS (plain old telephone system) an extension can be added but just tapping a wire onto the existing wire in the house. However when MA-bell got broken up in the 70s(?) I believe they did away with this foofah, and you paid for the telephone *service*
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.
more google... beyond the PDF
don't use this patch - it will break your system. rtfm if you want to know why (small tip: random != unique).
:)
just download the grsecurity.net patches and everything should be fine
"I dont agree. It's not your local ISPs fault that there aren't multiple providers in your area (assuming we are talking about you) or multiple service options. If there was enough money to be made in an area, there would most likely be more providers."
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.
Who is RTFM and when will he help me with Unix?
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:
Say no to software patents.
Just for your information: Many of those p2p applications support SOCKS 4 + 5 proxies. (Morpheus/Kazaa, WinMX, AG did..)
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.
If your firewall is a FreeBSD or OpenBSD machine, it already does this. Linux just uses a 0.
Lack of eloquence does not denote lack of intelligence, though they often coincide.
here's one.
Seems a little arbitrary, but they're small fry. let's go bigger:
here's another.
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 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...
Humpty Dumpty was pushed.
Fragments having the same ipid field are assembled. Indedd, Ipid only changes from one packet to the next, but not from one fragment to the next.
Say no to software patents.
As far as I know, OpenBSD's pf is the only free packet filter that gives you the option to change the IP ID field. It is the "modulate state" command.
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!
Troll Like a Champion Today
I suspect the techniques discussed in that paper have been used for quite a while by AT&T, but they have been rather secretive about it.
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.
but I bet a fix will apear for the Linux kernel pretty quick.
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.
2. Use OSes with better randomisation of IP IDs.
grsecurity can do this for linux.
The article is using Path MTU discovery as an example of DF packets (which were ignored by their analysis anyway). It's not clear to me why they even mention Linux setting the IPid field to 0 in a DF packet, since it's not applicable to their analysis (and, by definition, the IPid field is meaningless in a DF packet anyway).
Since the vast majority of packets are not DF, this really doesn't qualify as scoring another one for linux.
Hmmmm this little module lets onw configure how you want the IP header id generatored, among a bunch of other options to hide identify. Why not just work this into iptables, PF, IPF and no worries about NAT ID'ing.
We recently discussed this paper here at UNC-CH because one of our graduate students went to IMW. Something that came up was that they didn't actually get any real data for this experiment. So although the paper's content is sound, it should still be verified before it is taken as a feasible approach.