2

The isolated networking lab is running Red Hat Linux 9 (Shrike). We still use this "ancient" release, because given the simplicity of the protocols examined, it is sufficient. In addition, because of the equipment and the textbook we are following, it requires a big amount of effort to change that. Eventually (sometime soon) we will have to do it, since issues are accumulating and support vanishes. However, the question and the issue encountered is a little more general (or at least that's what I want to believe). On one of the computers I could not get an output for the command

[guest@shakti guest]$ netstat -g
netstat: invalid option -- g
usage: netstat [-veenNcCF] [<Af>] -r         netstat {-V|--version|-h|--help}
   netstat [-vnNcaeo] [<Socket>]
   netstat { [-veenNac] -i | [-vnNc] -L | [-cnNe] -M }

    -r, --route              display routing table
    -L, --netlink            display netlink kernel messages
    -i, --interfaces         display interface table
    -M, --masquerade         display masqueraded connections

    -v, --verbose            be verbose
    -n, --numeric            dont resolve names
    -e, --extend             display other/more informations
    -c, --continuous         continuous listing

    -a, --all, --listening   display all
    -o, --timers             display timers

<Socket>={-t|--tcp} {-u|--udp} {-w|--raw} {-x|--unix} --ax25 --ipx --netrom
<Af>= -A {inet|ipx|netrom|ddp|ax25},... --inet --ipx --netrom --ddp --ax25

The net-tools version installed is 1.60-12. I thought that installing a newer version could solve the problem. For all of the following, I am acting as root. After downloading this I tried to install it

 rpm -Uvh net-tools-2.0-1.ram0.97.i686.rpm

and I get the following

Preparing...                ########################################### [100%]
1:net-tools              ########################################### [100%]
error: unpacking of archive failed on file /bin/dnsdomainname;529d4737: cpio: symlink failed - Permission denied

/bin/dnsdomainname points to hostname. I changed the permissions to 777 and with chattr I removed all the attributes (sorry for the bad practice, but had to be sure). 

[root@shakti bin]# ls -alstr dnsdomainname
0 lrwxrwxrwx   1 root     root            8 Dec  4  2003 dnsdomainname -> hostname
[root@shakti bin]# ls -alstr hostname
12 -rwxrwxrwx   1 root     root         9092 Feb 11  2003 hostname
[root@shakti bin]# lsattr dnsdomainname
------------- dnsdomainname
[root@shakti bin]# lsattr hostname
------------- hostname

Unfortunately, it did not fix the problem. I also tried to install earlier versions of the net-tools but I got the same error. Any ideas?

George
  • 133
  • 4
  • 1
    It's clear you've already reached the point where you should have upgraded... in fact that happened years ago. I'm not sure you'll be able to solve this any other way. – Michael Hampton Dec 03 '13 at 22:39
  • I'll give it one last shot for the next 8 days (until the semester usage of the lab is over). If no solution is found until then, I guess I will have busy Christmas. – George Dec 03 '13 at 22:42
  • Under this circumstances, this looks like a try-and-error thing. Next thing I would try would be to remove the symlink dnsdomain and to install again. – etagenklo Dec 03 '13 at 22:56
  • In the meantime you should look at the permissions and attributes of the `/bin` directory. – Michael Hampton Dec 03 '13 at 23:00
  • @etagenklo Unfortunately this did not work – George Dec 04 '13 at 00:30
  • @MichaelHampton Changing the attributes of /bin and /sbin as well as the attributes of some contents of /sbin did the trick. Thanks! – George Dec 04 '13 at 00:31

1 Answers1

1

Well, this is all sorts of messed-up... Redhat 9 is just unacceptably-old.

Either way, assuming this server hasn't been completely compromised, you can probably solve your problem by checking the attributes of the directory above the executable. In this case, lsattr -d /bin .

ewwhite
  • 197,159
  • 92
  • 443
  • 809
  • Yes, as you and @MichaelHampton said this indeed solved the issue. You are of course right about the unacceptably-old, but compromising is not an immediate danger. The lab is completely isolated with no internet connectivity. It is used to examine the basic networking protocols and their operation. Thanks again for the help, and indeed update is in the TODO during Christmas. – George Dec 04 '13 at 00:35
  • No problem. However, the attributes on /bin should not have any flags set. So perhaps the system was already hacked or compromised in the past? Glad this resolved your issue. – ewwhite Dec 04 '13 at 01:43
  • The output of the lsattr was 'suS-iadAc----'. This is the same for almost all the system files since the initial setup (or at least according to the "elders"). The idea was that it should be almost impossible for someone to mess something up. – George Dec 04 '13 at 03:57