RoadRunner’s DNS wildcard at 24.28.199.152 breaks Samba

12 March 2008 at 12:21 pm (Gentoo) (, , , , , , )

Today I tried to mount an smbfs share on my local network that has always worked before. I was greeted with the following error:

timeout connecting to 24.28.199.152:445
timeout connecting to 24.28.199.152:139
Error connecting to 24.28.199.152 (Operation already in progress)
5624: Connection to windowsbox failed
SMB connection failed

What? Why is Samba trying to connect to a machine outside of my LAN? And why that particular machine? My imagination conjures black hats and various compromise scenarios.

It turns out my ISP, Road Runner, has started using a DNS wildcard, which Road Runner is variously calling their “web address error redirect service”, or “non-existing domain landing service”, or “NXD”. This “service” is implemented automatically without the customer’s input, and it takes the input URL as a search term to return the same irrelevent, misleading, and downright useless search results you’ve come to know from domain parking. The searches are powered by Yahoo, and Road Runner takes a cut of the profits. You can opt out, apparently. The wildcard server is at 24.28.199.152, so that’s why that IP shows up.

But why was Samba doing DNS searches off my LAN, across the Internet? Well, I’ve now learned that’s default behavior for the whole Samba suite, including mount.smbfs and smbclient. Take a look at the “name resolve order” option in the smb.conf man page. The default setting prioritizes DNS requests over LAN broadcasts as a means of name resolution. I think that means that every time I’ve ever done an smbfs mount, I’ve sent a DNS request to Road Runner, saying “where is my windowsbox?” And in the past, Road Runner always said, “we don’t know”, so the smbfs mount command next tried broadcasting on the LAN, and then always found the target machine during that final step. I never noticed before, because Road Runner only recently started saying “hey, maybe your windowsbox is right over here at 24.28.199.152”, thus misdirecting Samba and breaking my network.

Well, let’s fix it. It’s easy. We’ll just add a line to /etc/samba/smb.conf and change the default behavior. We want to cut out DNS searches completely, and leave other behaviors untouched. Here’s the line:

name resolve order = wins lmhosts bcast

If you’re having similar problems, I’d recommend both fixing Samba, so the network stops leaking, and opting out of RoadRunner’s NXD junk.

Permalink 1 Comment

speeding up tor

4 November 2007 at 12:01 am (Firefox, Tor) (, , , , , )

The Noreply Wiki has a very useful guide on how to make Tor faster. I’m working with revision 37, currently the most recent revision of the guide.

I started with Procedure 1, and altered about:config like so:

network.http.keep-alive.timeout:600 (300ms default is OK usually, but 600 is better.)
network.http.max-persistent-connections-per-proxy:16 (Default is 4)
network.http.pipelining:true (Default- false. Some old HTTP/1.0 servers can't handle it.)
network.http.pipelining.maxrequests:8 (No default)
network.http.proxy.keep-alive:true (Default- true, but double check)
network.http.proxy.pipelining:true (Default- false)

I’m going to skip all the suggestions about Fasterfox, because I don’t trust it to behave properly and not leak around the proxy, and I need to work with a lot of dynamic content anyway, which Fasterfox obviously can’t prefetch. I’m on Linux so I’m going to skip everything else in Procedure 2.

Procedure 3 is where this gets interesting, and where we actually start to make Tor faster, as opposed to making torified applications faster. The suggestions here really make a lot of difference in speed. I haven’t done any technical measurements, but I can see the difference very clearly when I’m browsing. However, though I haven’t tested, I suspect that I may potentially be sacrificing some anonymity for the increased speed. The authors of the guide note this is a possibility.

So I’m going to make two torrc configuration files, and I’ll use one when I need the best security I can get, and the other when I want speed and can afford to potentially be vulnerable to profiling attacks. For example, when I’m only concerned about the destination website knowing my IP, I can opt for speed. When I’m concerned about Big Brother, I can opt for security. This is simple to accomplish. I’m going to use Vidalia to switch between the two when I need to.

Vidalia’s torrc is at $HOME/.vidalia/torrc and I made a copy of it, in the same directory, called torrc-speed. The old torrc is going to remain unaltered; its defaults are secure. In the new torrc-speed, I added these lines:

# Try for at most NUM seconds when building circuits. If the circuit isn't
# open in that time, give up on it. (Default: 1 minute.)
CircuitBuildTimeout 5
# Send a padding cell every N seconds to keep firewalls from closing our
# connections while Tor is not in use.
KeepalivePeriod 60
# Force Tor to consider whether to build a new circuit every NUM seconds.
NewCircuitPeriod 15
# How many entry guards should we keep at a time?
NumEntryGuards 8

CircuitBuildTimeout, KeepalivePeriod, and NewCircuitPeriod are part of Procedure 3. I also added NumEntryGuards and increased it to 8 (the default is 3) because I want to give my speedy Tor the chance to pick faster entry guards if the low CircuitBuildTimeout means that some entry guards cannot be used. I don’t know whether this is actually necessary, nor whether it potentially decreases anonymity, but I don’t much care in this configuration. Save the file.

Then I went to Vidalia’s “Settings” screen and unchecked “Start Tor when Vidalia starts”. Then I went to the Advanced tab and pointed Vidalia at the new torrc-speed file. Then started Tor and tested it out. Yes, noticeably faster.

So now when Vidalia starts, it doesn’t start Tor yet, giving me the chance to go to the Settings > Advanced tab and change configuration files, to either the security or the speed configuration, before actually starting Tor.

Permalink 26 Comments

vidalia on linux

1 November 2007 at 7:05 am (Fedora, Tor) ()

Fedora 7:

Previously I had Tor running as a service, without Vidalia. That setup worked fine, but I also wanted a Tor controller, in order to easily change exit nodes. Since my Fedora 7 has GNOME already and not KDE, there’s no obvious solution. I could find a way to use TorK, or find a way to use Vidalia. I’m already accustomed to Vidalia, so that’s my choice.

Vidalia isn’t in the Fedora repositories, though, and it isn’t in freshrpms, an alternative Fedora repository. I didn’t want to dig anywhere else. I downloaded the Vidalia rpm directly from the Vidalia project page, and used their instructions. It says Vidalia requires nas, qt4, and qt4-x11. Why it needs nas I cannot guess, but that was already installed on my system. I used yumex to install qt4 and qt4-x11. Then I tried “rpm -Uvh vidalia-0.0.8-3.i386.rpm” but it didn’t work. I’m still a Fedora noob. I guess I have to install as root. That worked.

I wanted Vidalia to control the already-running Tor process that starts as a server, but I could not get that to work. When I thought I had it set up correctly with HashedControlPassword, Vidalia would just start up and kill the Tor process, and then complain “Vidalia was unable to register for Tor events. Control socket is not connected.” I don’t know. I gave up with this route and decided to just let Vidalia start its own Tor process. This meant I had to run “chkconfig tor off” to disable the service from starting.

Now I just start Vidalia when I want to run Tor. Privoxy is still a service.

Remember that Vidalia makes its own torrc file for the Tor instances it starts, so if you had settings you wanted to save, you have to copy them over. Look in $HOME/.vidalia for the file.

Permalink 2 Comments

separate Firefox profiles, running simultaneously, for Tor and non-Tor traffic.

5 October 2007 at 9:37 pm (Fedora, Firefox, Tor) (, , , , , )

Last post dealt with installing tor and privoxy. Time now to get Firefox ready to use anonymously. Much of this post will be Firefox-specific, so can be extended to any operating system. The small part that is Fedora-specific will probably extend to any Linuxes. For other operating systems, see the Note at the bottom.

I want to make Firefox run as two separate processes, with two separate profiles, at the same time; one will be anonymous and one normal. The anonymous Firefox will route through Tor, and run no Javascript, no Java, no extensions (such as StumbleUpon), and no plug-ins (such as Flash or Gnash), because these can leak identifying data around the Tor proxy.

To begin, Firefox has a command line option, “-no-remote”, that allows operation of two or more separate Firefox processes at once. The normal process won’t need this option, but the anonymous process will. It wasn’t obvious to me why this is called “-no-remote” but it seems to relate to turning off this Mozilla “remote” option and whatever relates to it.

Anyway, if you go to the command line and type “firefox -no-remote -profilemanager” you’ll get a separate firefox process that starts with the Profile Manager. Create a new profile. We’re going to assume you called it “torprofile”. Now close this new Firefox process, and at the command line type “firefox -no-remote -P torprofile” which will start up the profile you just created, bypassing the Profile Manager.

This profile is fairly clean. It has no extensions installed. It will have Javascript and Java enabled by default; you’ll have to turn these off under Edit > Preferences > Content. Also in Preferences > Security, I disabled “tell me if the site I’m visiting is a suspected forgery”, and “remember passwords for sites”. Also under Preferences > Advanced > Update I chose “ask me what to do”, because I don’t want updates to occur over Tor; I’d rather see that there is an update, disable the anonymous proxy, and then update over my normal connection. Disabling Javascript and Java are pretty much essential; the other choices mentioned here may be optional for you.

Don’t forget to change Firefox’s network proxy to 127.0.0.1 port 8118, to go through Privoxy and Tor.

A problem remains, though. Plugins on your computer, like Flash, are still enabled, and these can leak. Go to about:plugins and you’ll see what’s installed. Firefox looks for plugins and loads them automatically. We want these plugins to be available to the normal Firefox process and invisible to the anonymous Firefox process.

In Fedora, the easiest way I’ve found to do this is to make a copy of /usr/bin/firefox and alter it slightly. This is not a binary file, it’s actually a wrapper script to “setup all the environment voodoo needed to make mozilla work”, and at the end of the script it actually initializes the binary, which in this case, is /usr/lib/firefox-2.0.0.5/firefox-bin

So, first, make a copy of the wrapper script, by typing “cp /usr/bin/firefox /usr/bin/firefox-no-plugins” and then open /usr/bin/firefox-no-plugins with a text editor. Somewhere in there is a section that sets the variable $MOZ_PLUGIN_PATH and on mine it looks like this:

##
## Make sure that we set the plugin path
##
if [ "$MOZ_PLUGIN_PATH" ]
then
MOZ_PLUGIN_PATH=$MOZ_PLUGIN_PATH:$MOZ_LIB_DIR/mozilla/plugins:$MOZ_DIST_BIN/plugins
else
MOZ_PLUGIN_PATH=$MOZ_LIB_DIR/mozilla/plugins:$MOZ_DIST_BIN/plugins
fi
export MOZ_PLUGIN_PATH

I want this variable to be empty, so I’m going to change the section like this:

##
## Make sure that we set the plugin path
##
MOZ_PLUGIN_PATH=""
export MOZ_PLUGIN_PATH

Excellent. Now if you go to the command line and execute “firefox-no-plugins -no-remote -P torprofile” you’ll get the new clean profile, and without any plugins. Check about:plugins in Firefox’s URL bar and it should say “No plug-ins are installed”. By the way, I’m pretty sure if you want specific plugins to be used in the anonymous Firefox, you can hardcode them into MOZ_PLUGIN_PATH instead of leaving it empty, though I haven’t tried this yet.

Now you need to make separate desktop links for the two Firefox profiles. Make a desktop link that executes “firefox-no-plugins -no-remote -P torprofile” for the Torified Firefox. You also need to change the desktop links for the normal Firefox, to “firefox -P default”. This will cause those links to start up your normal profile with your normal plugins. If you don’t do this, unaltered Firefox links will start up the last profile that was used: sometimes the anonymous profile, sometimes the normal one. Protect yourself first against this undefined behavior. Change your links.

Keep in mind also that every time you update Firefox, you will need to make a new copy of the wrapper script and empty the plugin path. This is because every new Firefox version has a different wrapper script (verified on Fedora and expected on other Linuxes); sometimes they are different only in referencing the new version number, but they are different, and your Torified desktop link will break and simply stop working after you update Firefox, until you make a new wrapper script.

This is a good baseline for anonymous browsing and we could stop here if we wanted to. I’m going to do one last thing, though. The 1.1.x development branch of Torbutton has some nice features that I’d like to take advantage of, especially “Set user agent during Tor usage”, “Block History Reads during Tor”, and “Restore saved session via Tor after Firefox crash”. Check out the Torbutton development branch page to see what these do.

Currently the development branch doesn’t have SSL access, but you can download the XPI file, retrieve the MD5 hash over Tor and over non-Tor, compare the two, md5sum the file, and this should be reliable enough. Drag the XPI file into the open Torified Firefox window and it will install. I’m pretty sure this method means that Tools > Add-ons > Find Updates will look for updates on local computer’s download directory, so you’ll have to check for and install updates manually.

Extension preferences are at Tools > Add-ons > Torbutton > Preferences. I recommend disabling “Display Tor proxy setting in the status bar” so that you can’t accidentally turn off Tor with a stray click. This is the only extension I’m going to install in the anonymous profile, since Torbutton is made especially for leak-proof usage with Tor and Firefox.

Everything should be working smoothly now…

(Note: for non-Linux operating systems, the methods for “concealing” the plugins from Firefox may be very different from the above. I recommend just installing the 1.1.x branch of Torbutton and using that, because it has an option to disable all plugins in Firefox as long as it’s on. This should be reliable and simpler than messing around with wrapper scripts. As long as the Torified profile is always running through the proxy, Torbutton will keep the plugins turned off. This makes it even more important to disable “Display Tor proxy setting in the status bar” so as to prevent any accidental leaks. You’ll still need separate profiles and a separate link with -no-remote.)

Permalink 7 Comments

tor and privoxy

5 October 2007 at 6:54 pm (Fedora, Tor) (, )

Get Tor and Privoxy running in Fedora 7:

I downloaded the most recent tor and privoxy, using pirut. Configured /etc/privoxy/config and made the following changes:

#logfile logfile #commented out this line
#jarfile jarfile #commented out this line
#debug 1 # show each GET/POST/CONNECT request #commented out this line
forward-socks4a / 127.0.0.1:9050 . #added this line
forward 192.168.*.*/ . #added this line
forward 10.*.*.*/ . #added this line
forward 127.*.*.*/ . #added this line
enable-remote-toggle 0 #changed this to 0 as suggested here
enable-remote-http-toggle 0 #changed this to 0
enable-edit-actions 0 #changed this to 0

Tor and privoxy are now installed, tor can be considered configured by default, and privoxy is now configured. But they aren’t going to run at startup. To make that happen, you have to run:

chkconfig --add tor
chkconfig tor on
chkconfig --add privoxy
chkconfig privoxy on

Actually I’m not sure that the “--add” commands are necessary. I’m kind of clumsy with this stuff. But I do know it all works after this; tor and privoxy will start on boot. I did make one change to /etc/tor/torrc to uncomment the line “Log notice file /var/log/tor/notices.log” which gives me the basic operational messages I’m used to seeing. After making that change it is necessary to execute “service tor restart”.

Later I may try to get Vidalia installed, but it’s not in the Fedora depos, so I’m not going to mess with it right now.

Permalink 4 Comments

Incognito: a Tor LiveCD

3 October 2007 at 8:47 am (Gentoo, Tor) (, , , )

I want to quickly give a plug for Incognito, a very handy anonymity tool. It’s a Live CD, which means you burn it to disc with a standard CD burning tool, then boot your computer with the CD in the drive, and this separate operating system starts up; take out the disc and reboot, and your normal operating system (such as Windows or Ubuntu) is running again.

The most notable feature of Incognito is that by default, all your network traffic is routed through Tor. This basically means that to prying eyes, snoopers, and eavesdroppers, your IP address is concealed.

For those users already familiar with Tor, the appeal of Incognito is to have a bootable anonymity toolkit available to you wherever you go, at any computer. It works very well, and as of right now, it is being actively maintained by the friendly Pat Double. Go check it out.

Permalink 1 Comment

configuring laptop touchpad

29 September 2007 at 7:08 pm (Fedora, Ubuntu, VGN-T250P) (, , )

I have a VGN-T250P laptop with some GNU/Linux distributions that I’m multibooting for a while until I decide which one to keep. First thing after install is to get the touchpad functioning properly so that I can work.

In Ubuntu 7.04 (Feisty Fawn), I used gnome-app-install (Add/Remove Applications) to install gsynaptics (Touchpad). It shows up in System > Preferences. It won’t work yet though; it throws an error: “GSynaptics couldn’t initialize.
You have to set ‘SHMConfig’ ‘true’ in xorg.conf or XF86Config to use GSynaptics”. This is remedied by editing /etc/X11/xorg.conf and adding the line:

Option “SHMConfig” “true”

under the section labeled “Synaptics”. You have to restart the X server then, which can usually be done easily by hitting Ctrl-Alt-Backspace twice. It’s a bit of an annoying irony that you have to manually edit the xorg.conf file to start a program that lets you avoid manually editing the xorg.conf file.

After GNOME’s touchpad configurator was running, the first thing I did was turn off tapping. Horizonal scrolling was off so I turned it on. This is the baseline of usability for me. Next is to deal with Firefox.

Firefox has a bothersome default behavior that many touchpad users complain about. Horizonal scrolling, which can be easily initiated with a casual finger swipe, causes the browser to jump forward and backward through the current page’s history, as though you were clicking on the arrow buttons. From reading the forums I found while troubleshooting, it seems many people misinterpret this and go looking for mouse gestures to turn off.

The solution is to go into about:config and change mousewheel.horizscroll.withnokey.action to either 1 or 0. Gentoo-wiki.com says that 1 enables normal horizontal scrolling, and I’m assuming that 0 disables any functionality. 1 works for me. Most every page I see in google says you also need to toggle mousewheel.horizscroll.withnokey.sysnumlines to true, but I cannot figure out why and it does not seem to make a difference on my system. Mozdev.org implies it’s irrelevant, saying “Scroll by a number of lines equal to system default?”

All the most annoying touchpad behavior is fixed now, but the cursor is still too slow. It does not move far enough across the screen for a quick finger swipe. Unfortunately, this is not as easily remedied as it should be. System > Preferences > Mouse does not seem to have any effect on the cursor speed in Ubuntu, although this method works fine in Fedora 7. The problem seems to be described by bug #118593.

It can be solved using synclient. Check the man page for syntax. I got the results I wanted with these settings: MinSpeed=0.3, MaxSpeed=1, AccelFactor=0.02 (different people’s hardware will need different settings). MaxSpeed must exceed MinSpeed or you get no acceleration. I found the most important setting was AccelFactor. Mine was originally set to approximately 0.006, and though adjusting MaxSpeed didn’t do much, AccelFactor made a big difference.

The changes from synclient are temporary and last only through the current Xorg session. You have to go into /etc/X11/xorg.conf and add the settings that worked for you, to make them permanent.

For Fedora 7, the above instructions can be followed (it’s only superficially different, if at all), except it’s not necessary to bother with synclient. GNOME’s regular mouse config app will work.

Permalink 10 Comments