Stopping leakage from the LAN

Or, how to avoid unwanted DNS lookups

I have a local network at home with two Linux machines and one Windows (Win95) box. One of the Linux boxes is the gateway to the Internet, with masquerading / firewall / mail server / http junk filtering functions. The gateway (mizar) is an old Pentium which I run “headless”, i.e., without keyboard or monitor; to do anything on it, I telnet into it, usually from the other Linux box (spica). Of course, the telnet daemon on mizar only listens to the local network, not to the outside world (a description of how to do this is here).

I do not run a name server on my system. The local addresses (in the 192.168.1.x range) are looked up from /etc/hosts and C:\windows\hosts files. External addresses are looked up using the name servers of my ISP.

By running (as root) tcpdump on spica I can see the traffic on the red (local) network [1]. It is amazing (and instructive) to see how much traffic occurs on such a small network even if “nothing is happening”. ARP caches are updated; both altair (MS Outlook) and spica (Mozilla) regularly query the IMAP server on mizar to check if new mail has arrived; and various Windows things are going on between altair and spica, which runs Samba.

These are examples of local “maintenance” traffic, and it should not go beyond the local LAN. However, sometimes I see packets to and from the ISP’s name servers. This should not happen unless somebody is actually trying to reach an outside destination. Two cases where unwanted DNS lookups occur are Win95 ‘browsing’ and IPv6 capable programs. Such unnecessary DNS lookups are especially annoying if you have a modem connection with dial-on-demand. They can also lead to long delays in starting up programs.

Stopping Win95 DNS calls

Win95, at regular intervals, tries to find other machines belonging to its “workgroup”. Somehow this ‘browsing’ activity is not limited to the LAN.

Some searching on the Web produced a solution: run regedit in Windows, and change the value

HKLM\System\CurrentControlSet\Services\VxD\MSTCP
EnableDNS

from 1 to 0.

I do not know if this problem occurs in other versions of Windows, and if so, if the solution is the same.

Problems with IPv6

Internet Protocol, version 6, will sometime in the future replace the current protocol (IP version 4). It is already in use in some networks, especially in universities. More and more newer Linux packages are ‘IPv6 capable’; support for IPv6 can also be compiled into the kernel.

This is all very fine for hackers and researchers, but at the moment there doesn’t seem to be any practical reason why you should have this. Furthermore, some newer ‘IPv6 capable’ packages have side effects on a non-IPv6 system. When they look up a host address, they first try look for an IPv6 address, and only if this is not found, will the ‘normal’ IPv4 method of address resolution be used. So if your local /etc/hosts file does not also contain IPv6-type addresses for the machines on your local network, the ISP’s name servers will get involved each time some process tries to reach a local machine!

This happened on my system after I upgraded telnet (and telnetd) to version 0.17-18, which (at least in Debian Linux) is IPv6-capable. Suddenly telnets from spica to mizar involved the ISP’s name servers (which of course always responded that they had no IPv6 address available for mizar)[2].

One solution is, of course, to downgrade packages when you notice this problem. The real solution is to add IPv6 addresses to /etc/hosts. Local IPv6 addresses are derived from IPv4 addresses with a prefix. So if you have in /etc/hosts

127.0.0.1	localhost
192.168.1.2     mizar.my.home   mizar
192.168.1.1     altair.my.home  altair
192.168.1.3     spica.my.home   spica

You have to add the following lines:

::FFFF:127.0.0.1	localhost
::FFFF:192.168.1.2      mizar.my.home   mizar
::FFFF:192.168.1.1      altair.my.home  altair
::FFFF:192.168.1.3      spica.my.home   spica

You may also need the following lines (anyway, I have them, the Debian upgrade process added them to /etc/hosts):

::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

If you really are going to experiment with IPv6 you probably need to do a whole lot of other things. This is only for fixing a ‘traditional’ IPv4 Linux installation. In my case it cured ‘unwanted DNS lookup’ problems with telnet/telnetd and with exim.

News server lookup in Netscape 4.5/4.7

Back in the days when I was still using Netscape, there was an annoying problem. The modem dial-on-demand connection (which I had then) would become active when Netscape was started, even if the start-up ‘home page’ was a local one.

Netscape apparently tried to look up the address of my ISP’s news server on start-up using the ISP’s name servers. The solution was to find out the numerical IP addres of the news server by pinging it:

jws:~$ping news.isp.com
PING news.isp.com (aaa.bbb.ccc.ddd): 56 data bytes
64 bytes from aaa.bbb.ccc.ddd: icmp_seq=0 ttl=249 time=25.2 ms

And then adding it to the /etc/hosts file:

aaa.bbb.ccc.ddd    news.isp.com

Mozilla does not have this problem.

Other superfluous DNS activity

Studying tcpdump output together with syslog records may reveal other cases of unnecessary “external activity” of the system (for such “detective work”, it helps to keep very accurate time on your network). If you have a ppp connection, enabling debug in the options file may also help.

Comments
Simplue WordPress theme, Copyright © 2013 DicasLivres.org Simplue WordPress theme is licensed under the GPL.