[plug] Debian TCP/IP routing question

[Denis Brown]

Dear PLUG list members,

In Debian GNU/Linux (woody, as it happens) where is the default gateway 
info stored so that the eth0 network interface can route to the outside 
world?   And does the "harden-environment" package affect its location / 
permissions - maybe shadow it or disguise it in some way?

Situation:   Just brought up a new Linux machine, with an odd network card 
(Broadcom BCM5700) that is not listed in the usual network drivers.  Once 
the non-networked basic system was in place I patched a 2.4.20 kernel with 
the Broadcom source patches (version 5.0.16, the latest I can find), 
compiled the kernel and got networking happening by manually doing:

ifconfig eth0 my.ip.addy.here netmask 255.255.255.0   (I have a class C 
network)
route add default gw my.default gate.way
vi /etc/resolv.conf    (added nameserver info)

And all was sweet.   Using the now-functional network I added packages of 
my choice and updated from the Debian security site with apt-get.   Then I 
decided to apply some of the knowledge that has come my way regards 
security, thanks to members of this list.   All went well until I 
discovered and installed something from Debian called "harden-environment" 
that had not been mentioned here.   I thought that I'd be able to add 
something useful to the discussion based on my findings.   Again, all 
seemed to be sweet - the harden-environment package makes the root account 
more challenging to use, adds a separate root account (stand alone shell) 
and generally seemed to make working at root level a PITA.

At one point I rebooted the machine and merrily set up ifconfig and route 
again, while thinking "I must edit the /etc/network/interfaces file to grab 
this stuff automatically."   To my chagrin I find that no matter what I try 
to do, I cannot get the machine to see beyond my local subnet.   The eth0 
device seems to be correctly configured - I can see (ping) other machines 
on the same subnet, they can see the new box.   I can ssh into the box, 
too, from the local subnet.

Setting the route manually appears to work and running route with no 
arguments shows that the routing information is correct.   The significant 
difference between a fully-working Debian machine's response to the route 
command and this machine's response is that the okay machine returns 
instantly and lists the gateway's dns address, rather than just the ip 
number as does this ailing machine.   In addition, the ailing machine takes 
maybe 15 seconds to return that info - as though it is attempting to 
contact a nameserver and cannot :-)

Creating a "clone" of the /etc/network/interfaces file from a known working 
Debian installation, with ip addy changed of course, followed by a reboot 
shows that the information is being read from there correctly - ifconfig 
and route show the correct values (well, route does when it eventually 
completes!) but pinging anything beyond the local subnet by either name or 
IP fails - 100% packet loss.

Removing harden-environment and rebooting has not brought joy back to this 
installation.   Deleting the info in /etc/network/interfaces, other than 
the lo device put there by the fact of installation, makes no 
difference.   I can manually do the ifconfig and route as before, but route 
takes time to complete, fails to resolve the gateway name and again, only 
the local subnet is accessible.

I've checked permissions on each of the likely files and have grep'd a 
working machine's /etc directory looking for files containing ip address 
info. but cannot see anything there that I cannot also see on the ill 
machine.   I presume that during installation, a normal Debian setup will 
insert the interface data into the /etc/network/interfaces file.   Or is 
this assumption false?   if so, where to look for the real data?   The 
final observation I should mention is this:   the MAC address of the 
Broadcom card is not showing up in an ifconfig listing.   I cannot swear 
that it showed up previously (ie. before harden-environment) but I rather 
think that it did - it is something I am used to finding in all the 
ifconfig listings I've seen.

Slashing-and-burning is an easy option but I would like to use this as 
"learning fodder" in case I meet something similar further down the 
track.   All ideas appreciated - my quest for "security" has gone a bit too 
far, methinks :-)

Cheers,
Denis