Every 802.x network card (wireless, ethernet, token ring) has a unique 48 bit identifier known as a MAC address. This address is burned into the EEPROM on the card, and oftentimes is used by networking equipment to track users as they come and go, frequently associating MAC address to hotel or dorm room #, credit card number, login info, etc. This means hopping on a network that has authenticated your hardware before and expecting to be anonymous this time around is pure idiocy.
In fact, even most consumer wireless gear will record the MAC addresses of all computers that have ever issued DHCP requests to them, and these logs usually cannot be purged, even by the owner! When you combine this with the fact that most Cable/DSL service providers will also record your MAC address and bind it to your billing information, and the fact that some of them don't even seem to wait for a court order to turn your info over, it becomes apparent that your MAC address essentially is your name. This isn't even counting the possibility of databases maintained by the major laptop manufactures.
One particularly useful hack I have discovered is that if you change your MAC address, cable and DSL providers typically will give you a new IP address via DHCP. This can be useful if you are a heavy user of P2P networks, since changing your IP regularly can help keep you off the RIAA/MPAA's "big fish" watchlists, since without access to the ISPs internal databases they will be unable to correlate your identity across IP address changes. That is, unless you keep the same "nickname" in whatever P2P app you use...
Thus, changing your MAC address is highly desirable for a number of reasons. However, note that you really only have to concern yourself with your MAC address if you do not wish the local network administrator to be able to identify you. MAC addresses do not cross router boundaries, so anything outside of your LAN will never see it. If your adversary is not internal to the LAN or cannot trace your IP address back to the LAN, don't worry about your MAC.
Here are the commands to change your MAC for the three major platforms:
Linux
In Linux, you just need to issue two commands, and then re-run dhcp or reconfigure the interface. This works for both wired and wireless cards.
[root@machine ~/dir]# ifconfig eth0 down
[root@machine ~/dir]# ifconfig eth0 hw ether de:ad:be:ef:f0:0d
Windows
Under Windows, however, things are a bit more involved.. There are a few ways to do it. One involves wading through your registry, and will not be discussed here. If you're lucky, you might be able to do it right from control panel. If this is not an option, you can try this ntsecurity.nu utility or this utility.
Mac OS
In Mac OS, for some reason it is easy to change the MAC address of your wired interface. One of the following two commands should work:
[user@machine ~/dir]$ sudo ifconfig en0 ether aa:bb:cc:dd:ee:ff
[user@machine ~/dir]$ sudo ifconfig en0 lladdr 00:01:02:03:04:05
However, to change the MAC of a wireless interface, you will need to patch your kernel, and then recompile it.
Some OS X users have informed me that USB wireless adapters often allow you to change the MAC address via the command line just like a wired interface. The one most commonly mentioned is the Belkin F5D7050.
I should also note that many routers will allow you to clone or specify a MAC address from their web interface.
The 802.11 Nickname field is a little-known feature of the wireless spec that sends your hostname to the AP. This is obviously bad.
Linux
[root@machine ~/dir]# iwconfig ath0 nickname "Fucko The Clown"
Mac OS
Under Mac OS, your wireless nickname is your hostname. You can change it with sudo hostname -s "Fucko The Clown"
Windows
I think your only option is to choose an obscure machine name. If you wish to change your hostname, you can either edit these registry keys or run the NewSID utility
Upon obtaining an IP address, your DHCP client will sometimes send information about you in DHCP requests. In many cases, this includes your hostname and possibly your MAC address, but can include your operating system and DHCP version, which can potentially be very damaging to your anonymity set on your local network. Once again, much like MAC address, if you are unconcerned about your local network discovering your identity, then you probably needn't worry too much about this. However, in many cases it is necessary to obscure this information.
Also, as part of the DHCP standard, all operating systems will provide their most recent IP address to the DHCP server. Usually this is harmless, since it is typically just an internal IP address, but if you use your laptop to DHCP directly to your ISP, it is possible it may then hand this IP to an open access point you associate to. If you are changing your MAC address to minimize risk for P2P activity, you may want to wipe previous IP leases on your router machine every time you obtain a new lease. Typically router devices have a 'release DHCP' button somewhere on the web interface. If you need to change these settings on your computer itself, follow the appropriate instructions below:
Linux
Unfortunately under Linux, the details of DHCP client properties vary from
distribution to distribution. In the general case for dhclient, the values are
read from /etc/dhclient-interface.conf, but this is
typically created at runtime. In Fedora, for example, only the hostname is
transmitted, and this value is read from
/etc/sysconfig/networks/ifcfg-ethN where N is the
relevant interface number.
Gentoo (and likely any other distro that uses dhcpcd), however, will transmit
the entire OS and kernel version. One contributor suggested changing your
/etc/init.d/net.eth0 (or equivalent) file to include
VID=`fortune -o|head -c 30|tr "\"'\n" ' ' 2>/dev/null`
/sbin/dhcpcd -i ${VID} ${dhcpcd_IFACE} ${IFACE}
Previous IP/Lease information is typically found under
/var/lib/dhcp/. Blowing these files away between
interface restarts (/sbin/ifdown ethN ; [change mac addr] ; [change
hostname] ; rm /var/lib/dhcp/* ; /sbin/ifup ethN) should do the
trick.
Windows
Windows sends your MAC address and an OS and version string (though the version is something nonsensical, like "MSFT 5.0", which means it might not map to exact Windows versions, but some DHCP implementation version). Unfortunately, Windows also transmits hostname. I don't believe there is any way to stop this, but you should not have picked a hostname that easily identifies you anyways. Unfortunately, it can be used to correlate successive connections, which makes it easier to track you down eventually. It seems as though the utility NewSID can be used to change your hostname on the fly. Alternatively, you can edit a few registry keys.
To kill a previous lease, usually all you have to do is go to Control Panel->Network Connections and right click on the interface, and go to Disable, and then Enable. This will blow away any previous lease state and IP address information. If you prefer the command line, ipconfig /release followed by ipconfig /renew does the trick.
Mac OS
Mac OS sends just the MAC address and hostname, but you should be aware that it also has some option codes that can serve to identify the OS type as well. Again, to change the hostname, issue something like sudo hostname -s "Fucko The Clown", and don't forget to change your mac address.
As far as leasing/IP information, go to System Preferences->Network and select Network Port Configurations under Show:. Then, click the checkbox next to the relevant connection to disable the interface, and then click it again to enable it, and the lease will be blown away and renewed. From the command line, sudo ipconfig set en0 BOOTP followed by sudo ipconfig set en0 DHCP will essentially the same thing (of course, substitute the appropriate interface name for en0).
If you want to be absolutely sure you have set everything properly, you can download Ethereal to monitor your network traffic. Set the filter line to bootp while a capture is running. This will display only dhcp requests and responses, which you can then inspect for information to make sure everything is OK.
The most obvious way you can be tracked across the Internet at large is through your IP address. Yahoo Mail, for example appends an extra header on your email messages that contains the IP of the computer your web browser is on. So much for that anonymous email account, eh?
Luckily, there are at least three ways to change your IP address for Internet traffic. They are (in order of increasing preference):
While easy, Proxy hopping fucking sucks. The basic idea is to find a reliable list of open proxies and change your browser's proxy settings to tunnel your connections through the proxy, thus obfuscating your IP address. BE CAREFUL. Some proxies will REPORT YOUR IP ADDRESS in the form of a cookie/session variable to hosts you connect to. Always test out a new proxy with either of these two proxy checkers. I believe the shroomery list only includes proxies that don't provide identifying information, so it is readily usable by the Firefox extension Switch Proxy. Unfortunately, Switch Proxy has a rather annoying bug that slows new window creation down to a crawl.. They don't seem like they are maintaining it anymore either.
If you're on a Linux machine, there is a utility that will allow you to also use all your command line applications with various proxy types, and will also allow you to chain multiple proxies together, for better protection. This utility is called ProxyChains. It is basically a library that you LD_PRELOAD to intercept socket calls and forward them to a list of HTTP or SOCKS proxies. Sadly, most of these proxies will only allow you to connect to port 80 or 443. Also note that the proxy chain is not encrypted. THIS MEANS THAT A LOCAL OBSERVER AT ANY PROXY HOST CAN VIEW THE REMAINDER OF YOUR PROXY CHAIN, INCLUDING THE DESTINATION HOST!
SocksChains, a similar tool to Proxychains also is available for Windows. FIXME_WIN32: test
It is possible to accomplish the same thing as ProxyChaining by connecting numerous SSH connections together. If you have lots of UNIX shells, you may be able to use them to obfuscate your network connection by using ssh's -L and -D options. -L tells ssh to listen on a local port and forward those connections to another host and port through the ssh connection. -D tells ssh to open up a SOCKS 4 server where you specify. So an example session might look like this:
[you@home ~]$ssh -L 4242:127.0.0.1:4242 user1@machine1[user1@machine1 ~]$ssh -L 4242:127.0.0.1:4242 user2@machine2[user2@machine2 ~]$ssh -L 4242:127.0.0.1:4242 user3@machine3...[userN-1@machineN-1 ~]$ssh -D 4242 userN@machineN
So in this case, the first ssh command is run on your home machine. It opens up port 4242 locally, which you will then tell your web browser and other applications to use as a SOCKS4 proxy. Any connection made to this port will be forwarded to port 4242 on machine1. The ssh command on machine1 causes this to be redirected to port 4242 machine2, which has a SOCKS4 server listening, forwarding all connections out through machineN. Of course, if you only need one hop, you can just only use the -D command from localhost. Note that this technique should work on Linux and Mac OS natively, and also Windows, if you install Cygwin. If you set up ssh keys, you can pack this whole procedure onto one line for quick execution.
Apparently Putty can also be used as the first hop in the chain. Port forwarding can be done from the 'Tunnels' item under 'SSH'. You basically enter the local port and then 127.0.0.1:4242 as the destination (don't forget to click 'Add'). To make things quicker, you can save a profile named 'MyTunnel' with these settings (and perhaps also 'Don't start a shell' and 'Don't allocate a pseudo-terminal' if you just want to make the window real small and don't want to show up in the wtmp of the remote machine). Once a profile is saved, you can run putty from the command line or make a shortcut to run 'putty -load MyTunnel'. You can do this for a bunch of different tunnels so you can pick and choose which IP you want to have right from your desktop.
MetroPipe.net has packaged this whole setup behind a nice GUI interface, but before you sign up, you should be aware that the long-lived nature of these circuits, and the fact that a single path shares all your traffic makes this a far less desirable option than Tor, discussed shortly. They do however also provide VPN service.
OpenVPN is awesome. It provides an encrypted tunnel from your computer to the OpenVPN server. While it is not a perfect anonymity service, it is at least useful when you only need "one hop" of anonymous surfing, or when you need to dodge restrictive firewalls. For example, if your employer either blocks or watches your network traffic, you can create an OpenVPN tunnel going to port 53 (DNS, which should be open in just about any firewall) and route all your traffic through it.
In order to make use of OpenVPN, you will need an endpoint running the server. You can either set this up on your home machine as described below, or sign up for an account at a commercial VPN service provider. Vpn-service.us only seems to have a Russian language order page, but I have seen them advertised in English on certain boards. If you ICQ them, they may give you a price in $USD.
Here is a quickstart on setting up a Routed IP OpenVPN v2.0 tunnel for an endpoint you control. This quickstart generates two certificate authorities and 2048 bit keys, making it the most secure way to create an OpenVPN tunnel. It should be immune to MITM attacks, even if one of the hosts is compromised and its keys are taken.
Windows
Download this openssl config file and place it where you intend to keep your openvpn config files.
Generate the server and client keys. You can accept the defaults for all those bullshit info fields, but be careful to say 'y' to the question asking to sign the certificates. The default is No.
After that script is run, copy all the files that start with
client to the
client side, and all the files that start with server to the
server side. All config files and keys go in C:\Program
Files\OpenVPN\config. Be a dear, and use a secure channel, will ya?
Configure client to use 192.168.69.2, and to connect to the server. Replace VPN_SERVER_IP in client.ovpn with your server's IP.
Place this script to rewrite the client's routes upon connect in your openvpn conf directory. It will be called automatically. However, you need to edit it and replace LOCAL_GATEWAY_IP with your Internet gateway IP (use the top line from route print if unsure) and also replace VPN_SERVER_IP with your server's IP.
Go to Control Panel->Network Connections and right click on the TAP network device to manually set the IP address to 192.168.69.2 and the gateway 192.168.69.1. If you need a DNS server, use one of these.
If your server is a Windows machine, right click on its network interface and enable Internet Connection Sharing.
Go to Control Panel->Administrative Tools->Services and start the OpenVPN service on both client and server.
Mac OS
Download the latest OpenVPN source. Install it by opening a terminal, and issuing:
[user@machine ~/dir]$ tar -zxvf openvpn-2.0.5.tar.gz
[user@machine ~/dir]$ cd openvpn-2.0.5
[user@machine ~/dir]$ ./configure --disable-lzo && make
[user@machine ~/dir]$ sudo make install
Download the Tun/Tap driver by Mattias Nissler. Install it with:
[user@machine ~/dir]$ mkdir tuntap
[user@machine ~/dir]$ cd tuntap
[user@machine ~/dir]$ tar -zxvf ../tuntap.tar.gz
[user@machine ~/dir]$ open tuntap_installer.mpkg
Download this openssl config file and place it where you intend to keep your OpenVPN config files (ie /etc/openvpn).
Generate the server and client keys. You can accept the defaults for all those bullshit info fields, but be careful to say 'y' to the question asking to sign the certificates. The default is No.
After that script is run, copy all the files that start with client to the client side, and all the files that start with server to the server side. Be a dear, and use a secure channel, will ya?
sudo chown -R nobody:nobody /etc/openvpn to get all config files to be owned by nobody, then sudo chmod 755 client-osx-up
Configure client to use 192.168.69.2, and to connect to the server. Replace VPN_SERVER_IP in client.conf with your server's IP.
Place this script to rewrite the client's routes upon connect in your openvpn conf directory. It will be called automatically, but you might have to chmod 755 client-up. Replace VPN_SERVER_IP with your server's IP, and replace LOCAL_GATEWAY_IP with your local gateway to the Internet..
Add a publicly available nameserver to /etc/resolv.conf.
Linux
Download this openssl config file and place it where you intend to keep your OpenVPN config files (ie /etc/openvpn).
Generate the server and client keys. You can accept the defaults for all those bullshit info fields, but be careful to say 'y' to the question asking to sign the certificates. The default is No.
After that script is run, copy all the files that start with client to the client side, and all the files that start with server to the server side. Be a dear, and use a secure channel, will ya?
'adduser openvpn' to add an openvpn user and group to both server and client machines.
chown -R openvpn:openvpn /etc/openvpn to get all config files to be owned by nobody.
Run 'modprobe tun' or recompile kernels to support CONFIG_TUN (The Universal Tun/Tap Driver) as needed.
Configure client to use 192.168.69.2, and to connect to the server. Replace VPN_SERVER_IP in client.conf with your server's IP.
Place this script to rewrite the client's routes upon connect in your openvpn conf directory. It will be called automatically, but you might have to chmod 755 client-up. Replace VPN_SERVER_IP with your server's IP, and replace LOCAL_GATEWAY_IP with your local gateway to the Internet. Replace eth0 with your appropriate interface.
Add a publicly available nameserver to /etc/resolv.conf.
WARNING: An attentive and fascist network administrator will still be able to determine that you are tunneling packets over an openvpn tunnel by watching your traffic (rest assured, they won't be able to see what you are doing, just that you're doing something). If you work in an environment this oppressive, change the proto udp and port 53 lines in your server and client configuration file to proto tcp-server/proto tcp-client and port 443 (or port 22) to make your openvpn session look more like a secure web (or ssh) connection. Note that this comes at a performance price, which is why it is turned off by default. See also: Watching Your Back
For problems in general, the following checklist can help you narrow down the problem to the relevant component:
ping LOCAL_GATEWAY_IP
Pinging the local gateway should be your first check. Sometimes it will be configured not to reply to pings, however it should reply to ARP requests. You should be able to check for ARP entries on all 3 OS's with arp -a.
ping VPN_SERVER_IP
This should ensure you can connect to the VPN server through your specific route for that IP. Hopefully it responds to pings, otherwise check arp.
ping 192.168.69.1
This should check that the VPN tunnel is working. You can also check
my.log in your OpenVPN config directory, which should tell
if you if the remote VPN server passed the key exchange, etc.
ping DNS.SERVER.IP
The last item you should check is that your DNS server is reachable. If it is
reachable, but you still don't have net access, perhaps you forgot to update
/etc/resolv.conf or enter a DNS server in your IP
properties.
If you still are having no luck, consult the Gentoo OpenVPN FAQ.
Tor is magnificent. Plus, setting it up is surprisingly easy for what it accomplishes.
WARNING: DO NOT BE A JACKASS OVER TOR. Recently there have been a couple of reports of people using Tor to hack and deface websites. This is not cool, and usually ends up forcing whatever Tor node(s) the attack exited from to shut down. If you insist on using Tor as a cracking/penetration testing utility, PLEASE read the Combining Approaches section for some pointers on how to put a proxy or ssh host after your Tor exit.
Both Windows and Mac OS/Linux setup should be pretty similar. For the Windows folk, Tor comes prebuilt as an installer, and these instructions will hold your hand through the process. All you have to do is download the exe file, and run it, and Tor should be installed. Mac OS people can follow the these instructions for their package. Linux people will have to compile and install the Tor source code.
From this point, any user on the system can run tor. Once you do so, your machine is connected to the network as a client node. If you have at least 1Mb of upstream bandwidth, you are encouraged to run a tor server, which is more involved. Note that you do not have to run a tor server to run a tor service, which can come in handy if you have material you wish to publish anonymously.
The next step is getting applications to use Tor. Tor creates a local Version 4A/5 SOCKS server, listening on port 9050 by default. This means any application that supports SOCKS can be told to use localhost:9050 as your proxy server. However, this is not always desirable or possible. Most web browsers don't support forwarding host name lookups over SOCKS. This means that it is possible for a local observer to determine which hosts you connect to. So for full protection, you must install a go-between proxy that does forward host name lookups over SOCKS, such as privoxy. Windows and Mac OS users will have Privoxy already installed and configured as an HTTP Proxy listening on port 8118 as part of the Tor Bundle.
Linux users and DIY folk will want to download this config file for privoxy that starts the proxy server on port 8118 and forwards your requests to port 9050 for Tor. (The thing that has to be changed from the default is to add a forward-socks4a / localhost:9050 . line to it).
Newer web browsers such as Firefox 1.5 can be instructed to use SOCKS to do DNS lookups. Go to about:config and search for "dns". Set the option network.proxy.socks_remote_dns to true. If you do decide to abandon privoxy, you need to be sure to install several extensions to protect yourself from cookies, ads, javascript, etc.
Once you decide how to handle remote DNS, you can then tell your web browser to use HTTP localhost:8118 (if Privoxy) or SOCKS localhost:9050 (if remote DNS) as its proxy server, and you're good to go. Again, you may want to verify your setup with this handy checker or whatismyip.com.
If you intend to use Privoxy to access non-web ports (such as IRC, you may want to edit
default.action and replace the line containing
limit-connect with +limit-connect{1-} to
allow privoxy to connect to all ports.
If you are looking for an easy way to switch back and forth between Tor and a direct internet connection, the Firefox extension ProxyButton is pretty nice. Switch Proxy is also available, and is a lot more flexible in switching between multiple proxy settings and being able to use a list of proxies in rotation. Unfortunately it slows new window creation down to a crawl.. They don't seem like they are maintaining it anymore either.
If you run Linux or one of the other free Unixes, you can install tsocks, which is an application layer SOCKS proxy. There are several patches available for tsocks, including patches to support Mac OS X (does not work out of the box, sadly). This config file for tsocks tells it to use port 9050. Once tsocks is installed and configured, you can use it to enable any application (ssh, telnet, netcat, nmap, etc) to connect over the Tor network simply by prefixing the command with "tsocks". Note that while the default tsocks does not support SOCKS4A, the Total Information Security version does in fact route DNS requests over Tor.
Some command line applications such as wget, links, lynx and curl will honor the http_proxy environment variable. So you might want to export http_proxy=http://localhost:8118 if you use these commands often, so that they run through Privoxy.
Windows users may have some luck using TorCap2, which provides SOCKS4A support transparently to applications that lack SOCKS support. Presumably since it does SOCKS4A, DNS requests are not leaked, though I have not verified this personally.
Some web sites have taken to banning the Tor network. Most recently google has started routinely presenting catchpas to Tor users, which require cookies to persist and also javascript to be enabled. In the case of google, Scroogle is available to circumvent the catchpas, cookies, javascript and other nonsense google throws at you. For other sites, you may want to consider writing custom privoxy rules to combine Tor with an HTTP proxy.
Additional information on connecting specific applications to Tor is covered in the Torify HOWTO and also later on in the Anonymous Communication section. One thing you should pay particular attention to is that various browser plugins might not pass through Tor.
In some environments, you may only be able to connect to web or ssl through your firewall. If this is the case (or if you have a network administrator that you believe may watch for "suspicious" employee behavior), edit your torrc and add FascistFirewall 1 to it. This will cause Tor to only make outbound connections to port 80 or port 443. You can tune which ports it uses through FirewallPorts.
Just about everywhere on the Tor website, you are advised that Tor is not to be used if you require true anonymity. Further sections of this HOWTO address (almost) all of the application level issues involved in anonymity, so pretty much all that remains of that paranoia are attacks on the tor network itself, which, unless you are trying to hide from the NSA itself, you really don't have much to worry about.
You should, however, be aware of the possibility of malicious exit nodes. Exit nodes can both observe and modify traffic, which means they can do things like keep AIM/non-SSL web sessions open after you close them. You should also be aware of is that it is somewhat dangerous to mix traffic that can identify you with traffic you wish to be completely anonymous. Since Tor multiplexes multiple TCP sessions over a few circuits, it is possible for the exit nodes to determine that the two were sent from the same host.
I2P is a complementary network to Tor. While Tor is useful for establishing anonymous connections to the external Internet but doesn't have the bandwidth/architecture to support Peer to Peer and bulk traffic, I2P is designed specifically to provide an anonymous internal network upon which you can run any normal Internet server, including Peer to Peer applications.
While the install itself is typically straightforward, I2P's setup is a little more involved than Tor's, mostly because every client node is also a relay node, and as such you may need to have a hole punched in your firewall to forward port 8887 for UDP. I2P does have NAT and firewall traversal mechanisms, but they do not work in all cases (especially symmetric NATs). Once you have it installed, you can go to the config page and check to see if it is able to connect.
I2P opens a proxy server on localhost:4444, but most likely you will want to add a line to your privoxy config so you can use both I2P and tor. Placing forward .i2p localhost:4444 (no period) below your Tor line will allow all requests to .i2p domains to go through I2P. DO NOT configure privoxy to only filter .i2p domains without also using Tor for everything else. It is possible for eepsites to have images, cgi, or iframes from non-i2p servers that they control, and can thus discover visitor's IPs that way.
Note that I2P does have gateways to the external web, so you technically don't need a Tor line at all if you want to forward everything to localhost:4444, but there are only two I2P exit points, and they are not nearly as reliable as Tor's. Once Privoxy is set, you can go to Orion.i2p to browse the list of all .i2p sites on the net, or to search.i2p or eepsites.i2p to search the I2P web. Note that by default, you will not have the host entries for many sites listed in orion and the search engines. You can fix this by adding http://orion.i2p/hosts.txt to your addressbook subscriptions
If you would like to search/browse the I2P web without installing I2P itself, you can use tino's DNS-based I2P in-proxy by appending "tin0.de" to any i2p domain name to access it from the public internet.
The really beautiful thing about I2P is that it is effectively an anonymous networking layer that applications can be developed on top of, including Bittorrent and Gnutella. In addition, through a feature called I2PTunnel, you can create a tunnel to just about any TCP based service you wish, including anonymous .i2p site of your own. In particular, you can point your IRC client at localhost:6668 and you will then be on the I2P anonymous IRC network (note that your IRC client does not need a proxy server for this).
Once you're all set up with the basics, you can browse over to The Ugha Wiki and check out some HOWTOs for doing various tricks over I2PTunnel and I2P in general.
SLIRP is a magical tool that converts a normal non-root UNIX shell account into a PPP session. While obviously the conversion isn't 100% (for example pings don't work), it does allow you to set up a pseudo-VPN to a machine you don't have root on (and thus couldn't run OpenVPN). Unfortunately this technique is likely to only work on Linux/UNIX and Mac OS, since it requires that your PPP setup use an ssh session as the serial device. I doubt Windows PPP can do this, but I could be wrong.
For our limited purposes, we'll just discuss using SLIRP over ssh. To do this,
you need to do a couple things. First, you must download and compile SLIRP on your UNIX shell (not your home
machine). This is pretty straightforward and does not require root. You can
just run configure and then copy the slirp binary to someplace like
~/bin. If you need to be covert, you could try calling it
zsh or mutt or something.
[user@machine ~/dir]$ tar -zxvf slirp-1.0.16.tar.gz
[user@machine ~/dir]$ cd slirp-1.0.16/src
[user@machine ~/dir]$ ./configure && make
[user@machine ~/dir]$ cp slirp ~/bin/zsh
Next, you will have to make sure the host you connect to is in your
known_hosts file. Usually this means you have to connect
to it using root on your home machine (ie sudo ssh
user@shellhost). If you get an error to the effect of
"Host key verification failed" during connection, this is the reason for it.
You might also have to set up passwordless ssh to your UNIX shell. It makes things more convenient, and for some broken versions of ssh it is required (such as the one that ships with MacOS 10.3). If you don't get a password prompt or get some ssh error when running the following scripts, you probably need ssh keys.
Once this is accomplished, you can run a script to start pppd using ssh: Linux version, MacOS version. FIXME: The Mac OS version is causing problems with pppd either hanging up (10.3) or not connecting at all (10.4). Is this an issue common to FreeBSD as well? Could any BSD users give this a whirl and report back?
Run this script as root on your local computer. It runs PPPD, calling SLIRP through ssh on the other side. Note the variables you must set at the top. You can obtain your local router in Linux or Mac OS by issuing netstat -r and looking for the entry at the bottom for default. For PUBLIC_NAMESERVER you can cat /etc/resolv.conf on your UNIX Shell, or you can use one of the publicly available nameservers. I've already filled in two public nameservers for you. Also, the pppd should attempt to grab the remote shell's DNS server and write it to resolv.conf for you, but this doesn't always work. Hence I write to resolv.conf in the script before calling pppd, just in case pppd fails to write it.
Sometimes one approach is not sufficient by itself to both protect your identity and grant you access to all the services you would like. For example, Tor does not carry UDP traffic, nor is it really an all-encompassing VPN solution, which can lead to lots of problems with browser plugins ignoring your proxy settings, spyware, webbugs, etc.
In some cases, it is also not possible to use Tor to connect to services due to banning. In other cases, it may actually be desirable to conceal the fact that you are exiting from the Tor network to protect it from abuse complaints, which usually have the side effect of forcing Tor nodes to shut down.
This is probably the easiest way to conceal the fact that you came from the Tor network. If you are using Privoxy, you can chain a regular HTTP proxy from a list mentioned above (this one provides IRC capable proxies, while this one automatically builds a list of currently active "high-anonymous" proxies) after the Tor line in your config to bounce off the HTTP proxy before hitting the server you wish to access.
To connect to fascist.torhater.com through an HTTP proxy at somehost.net:8080, add forward-socks4a fascist.torhater.com localhost:9050 somehost.net:8080 to the end of your privoxy config file. Note that with Privoxy 3.0.3, somehost.net:8080 must be an HTTP proxy and cannot be SOCKS.
If you are having problems locating a proxy that is not already banned by your desired service, you can attempt to scan for a fresh one using either ScanSSH or YAPH. Once you find a proxy, you can either google for the IP to see if it's in any proxy lists, or if you're ambitious, use a perl script to check to see if it has been listed yet in the DNS RBLs by doing DNS queries for it. (For those writing their own script from scratch, note that the IP must be backwards. So query 5.13.42.23.dnsrbl.org to check 23.42.13.5).
Unfortunately, many IRC servers ban known proxy servers, and some will even scan your source IP for an open proxy before allowing you to connect. However, what you can do is combine the SSH hopping approach with Tor if you need Tor-caliber anonymity. Basically the procedure is to obtain a UNIX shell (using Tor and an anonymous email address), and then use tsocks to connect to it with tsocks ssh -D 4242 user@someshell.net.
Once this is done, you can add forward-socks4 fascist.torhater.com localhost:4242 . (the dot is not a typo) to your Privoxy config if the service is a website, or otherwise inform your IRC client to use localhost:4242 as a SOCKS4 proxy. In this way, you are connecting to your locally listening ssh client, which routes it through the Tor connection to someshell.net, at which point your traffic exits on to the Internet with the IP address of someshell.net.
Once again, note that SSH only supports SOCK4, and thus DNS queries will be made locally and thus can be observed. Also, if you are using one of the free UNIX shell accounts, please be courteous and don't make a nuisance of yourself. These people don't want to and shouldn't have to take time out of their day to answer abuse emails about your account. They do this for free.
Also, note that Putty can be used with Tor to perform this same technique by setting localhost:9050 as your SOCKS4 proxy. Then you can set up the SSH proxy by going to 'Tunnels', and filling in 4242 as the destination port, and clicking 'Dynamic', with no destination or hostname. When you click 'Add', D4242 should show up. As discussed before, you can save this profile and make a shortcut to 'putty.exe -load myprofile' to quickly establish your tunnel. Once you run putty, you can use localhost:4242 as your SOCKS proxy, or add the above line to your privoxy config.
A few people have mailed me asking about using OpenVPN over Tor. It turns out this is not as hard as I originally thought. There are several reasons you might want to do this. In my opinion, the main one would be to obtain protection against plugins/non-SOCKSified applications making connections that reveal your address. If you are running OpenVPN, all of these applications will go through the VPN.
Essentially the main problem is that you want your normal Internet traffic to go over the OpenVPN interface, but you need your Tor traffic to travel over your regular Internet interface. Essentially this involves setting up routes for every Tor server you intend to use as an entrance point. This can be very problematic, because there are many Tor servers. However, you can limit Tor's choice of entrance servers with the torrc config options EntryNodes nick1,nick2,nick3 and StrictEntryNodes 1. I would recommend picking a couple high bandwidth servers off of the Tor Network Status page. If you are running Tor 0.1.1.x or greater, you should also use LongLivedPorts and add your VPN server port to the list (or just run the VPN server port on one of the ports mentioned in the manpage, such as 5190, 5050 or 6667). Remember that Tor exit servers block most ports below 1024, and also common P2P ports. Be careful not to choose one of these as your OpenVPN server port, or you will be unable to connect.
Once you have selected a few nodes and edited your torrc accordingly, you basically can follow the OpenVPN instructions exactly, except for 3 differences:
You need to edit the server.conf (Linux, Mac OS, Windows) to have the line proto tcp-server instead of proto udp.
You need to edit the client.conf (Linux, Mac OS, Windows) to have the lines proto tcp-client, socks-proxy 127.0.0.1 9050, and socks-proxy-retry.
You need to modify the client-up script (Linux, Windows, Mac OS) and instead of just one route line with your VPN_SERVER_IP, you need a route line for the IP of each node you chose for EntryNodes.
After that, you're pretty much good to go. Doing this over HTTP proxy is essentially the same as Tor, except you only need one route, and the config options are http-proxy and http-proxy-retry instead of socks.
Using OpenVPN over Tor can be considerably weaker than simply using only Tor. On the one hand, you don't have to worry as much about applications/plugins not using Tor, but on the other hand, you do have to worry about OS-level leaks through the VPN interface, and also the fact that there is a fixed endpoint to correlate traffic through. If you use OpenVPN for more than just one-hop encryption, I would recommend only using it over a throwaway computing setup, to avoid risks of attacks, trojans, and other leaks through the interface.
Running SLiRP over Tor is desirable for similar reasons as running OpenVPN over Tor, but has the benefit that you only need a shell account on some UNIX machine. Unfortunately, it has the disadvantage that it is only possible under Linux and Mac OS. As far as I can tell, Windows cannot use an arbitrary terminal to run PPP over. However, it is still possible to set up a Linux box doing SLiRP over Tor, and have it NAT for your windows desktop, if you were so inclined.
But I digress. Again, like OpenVPN over Tor, you have to choose a few high-bandwidth, reliable and trustworthy entrance nodes from off of the Tor Network Status page. Then you have to add these servers to your torrc with EntryNodes nick1,nick2, and also set StrictEntryNodes 1.
Then, follow the instructions for SLIRP setup, but instead use a different client script: Linux version, MacOS version (FIXME: again, MacOS version has bugs.. See SLIRP for details). The script needs the variables at the top to be filled in, as well as the routes that are added for FIRST_TOR_IP, SECOND_TOR_IP and so on. These must be replaced with the numerical IP addresses for the Tor nodes you added in your EntryNodes list.
Remember that pings will not work, so test this with telnet or something, rather than ping.
An alternative approach is to ssh hop to one shell, and then use tsocks to ssh to the next shell where you either are using -L to forward to an OpenVPN server, or where you are running a SLIRP host. You then tell the OpenVPN/SLIRP client side that localhost:4242 (or whatever) is your server and adjust the routes accordingly.
Here is how to accomplish this for SLIRP, which I expect to be the more common use case. If anyone does this for OpenVPN, please send me your scripts and I will post them. I imagine it should be pretty similar. You start by constructing the typical SSH hop chain:
[you@home ~]$ssh -L 4242:127.0.0.1:4242 user1@machine1[user1@machine1 ~]$[tsocks] ssh -L 4242:127.0.0.1:4242 user2@machine2...[userN-1@machineN-1 ~]$ssh -L 4242:127.0.0.1:22 userN@machineN
You then can use this script (Mac OS) to launch SLIRP across the SSH hopped link. Notice that the parameters are a bit different than with the vanilla SLIRP setup. FIRST_IP is the IP of your first SSH hop (machine1). The rest of the hosts do not matter. The rest of the options are the same as above.
One thing that may improve your security is to make the first SSH hop to a box you control. From there, you can install tor and use tsocks for the SSH connection to the host that will be running SLIRP. This is a good way to get Tor-level security for UDP applications and apps that don't support SOCKS. Technically the first hop doesn't have to be your box, since you don't need root to install Tor as a client, but the first node might be able to reveal who you are if they decide to cooperate with the destination host of your tsocks connection for some reason (which they may do, if they believe you compromised them or something).