Protection against Fingerprinting

First of all sorry for my english.

Recently I have read many tutorials about passive methods of detection kinds of systems and theirs number behind NAT. It depends on sniffing headers of TCP/IP packets (ttl, window size, tcp stack in general)

As I know NAT only changes source/destination addresses and ports in TCP/IP packet. Rest of packet is the same as it was made by system.

Is there possible to configure freebsd or other system (which works as a router)to make out going packets look the same?
 
If I may suggest it, I think you're asking the wrong question, so you won't get the answer you're looking for. Making all the data packets look the same would ultimately make them look the same to the final receiver of the data, which is not useful is you want to transfer _real_ data.

I believe what you're asking is this: Is there a way to protect your data while it is transfered over a network?

The short answer is yes. Or at least make it uncomfortably difficult for them.

Encryption of your data is one of the best suggestions I can offer, but should not be the only method to data protection. Your approach to data security should be layered. You can direct your data to take more than one path which makes it harder to capture.
 
I think what OP is wanting to do is re-write the TCP headers for the packets leaving his router to eliminate the ability of a malicious user intercepting and analyzing traffic with a packet sniffer to determine how many and what OS the machines behind his NAT are running. It's an interesting idea and I'm very interested in what the guys with more advanced networking knowledge have to say about it. I know ways of preventing FreeBSD from being fingerprinted to some extent, but have not considered extending it like this.
 
Ruler2112 undestood me well. The only thing that I found what works as I described is server SOCKS (if i'm not wrong). Unfortunately its very uncomfortable to use because it needs special clients or program has to support socks connections.
 
In my network I have about 10 computers with diffrent systems. All of them are connected to router which is running on Linux Debian. I was wondering if there is possible to protect outgoing traffic against passive sniffing where is possible to guess number and kids of OSes behind NAT.

I want to filter each outgoing packet through the router and modify characteristic parameters of TCP/IP stack.

Now Im able to change value of TTL only. I think It's not sufficent. I would like to change for ex. size of window or timestamp (forwarded packets, not only local).

I know that 2 values of timestamp which are very diffrent are evidence that behind NAT have to be minimum 2 OSes
 
Fingerprinting TCP/IP stack of outgoing traffic is very difficult task to do. Chance that someone will catch packets from two different machines behind your NAT router is low (although that depends on network structure). Unless that someone has access to "choke point" router traffic, in that case having your packets fingerprinted is your least concern. Most common scenario is someone trying to fingerprint OSes that have their ports forwarded by the NAT router in that case tunneling is useful.
 
Ok. Let's assume that my ISP brohibits sharing internet connection for more than 2 computers. I want to hide this.

In general do ISPs look inside packets?
 
Truth be told OS fingerprinting is often misleading and inaccurate. Besides, it doesn't do any real harm (unless someone finds out you haven't been updating regularly).

In general, I don't think ISPs care how many computers you're using to connect to the Internet, since they limit your bandwidth and the number of IPs you have. Using NAT shouldn't cause any problems. At least it's like this in Taiwan.
 
Magnesik said:
In general do ISPs look inside packets?
Anything is possible.

If its ISP that you are dealing with, there are more ways to guess how many PCs are behind your router than fingerprinting TCP/IP stack when they have full access to all your bandwidth. Like some ISPs like to cache instant messaging traffic (you know just in case, for your and your children "security") when they notice there are 20 different accounts bells start ringing.
 
Magnesik said:
I always thought that instant messaging traffic is ecrypted :P

Depends on the protocol, what server daemon is being used, how the server is set up, what client is being used, how the client is set up, the specific version and revision of both server and client, and the current phase of the moon. ;)

I have installed a Jabber server at my workplace that's only accessible from inside our network. The reason is that people were using internet-based instant messengers that they thought were secure. When I was able to show my manager packet captures with snippets of conversations that people had that I'd captured with Ethereal (now WireShark), she told me to do something to eliminate going over the internet.



I don't know how aggressive ISPs are in detecting NAT. It used to be (here in the states) that they'd charge you extra for additional boxes using the line and rent you a router with only specific local ports enabled. They didn't like it when consumer-grade routers became more affordable and commonplace, because it made it very difficult for them to enforce such an edict. It's my understanding that most ISPs have basically given up trying to enforce such a restriction and only get upset if you share internet with your neighbors. However, if you call in for support with line trouble, you have to plug directly from their modem-type device to your machine with no router or firewall in between. (Which I don't like from a security standpoint, but can understand from their perspective; the vast majority of people with routers don't know what they are or how to configure them.)
 
I do not know if it'll accomplish your end (experimentation/observation would be the best way to tell - fire up your favorite packet sniffer), but I do have that option enabled on my mail server. (It was recommended by a guide to securing FreeBSD that I was using and I only briefly looked at what it did; there were far too many configs in that guide for me to learn all of them well.) There haven't been any problems using it that I'm aware of.
 
I might be wrong, but I remember that scrub only drops problematic packets, so packets that don't have problems shouldn't be affected.
 
I had a PDF version of it, but have been unable to find it. I did find the same information in a forum format though. Some of the information is dated, but overall it's a good guide IMO.
 
Back
Top