Hi, I have a Ubuntu Dapper Drake 6.06 Server running, but for some reason there are spurious entries in the routing table, which obviously I did not add manually. I inserted me@myserver instead of the real prompt and hostname, and ab.c. instead of the real IP address. So I wonder, what would insert this stuff (and what can I do to prevent it from reappearing), and is there a text file I can edit to remove it? I tried various ways of doing sudo route -n del -host 192.168.31.2, but always come up with errors that suggest my syntax is wrong. The one I'm most interested in removing, and therefore presumably re-enabling, is 192.168.31.2,
Did you set up that server yourself? Have you tried to reboot it? What's the output of Code: ls -la /etc/network/if-up.d ? What's in /etc/networking/interfaces?
First, thanks for answering and Happy New Year! Yes, I did set up the server myself, and have rebooted at least once since this started happening. If I recall it was worse before the reboot, then it seemed to not allow anyone online, now it blocks just one computer, or only a few. My first concern of course is fixing it, but there is a bigger long term question about security and reliability: Since both these seemingly false routes and entries in hosts.deny blocking some of the same addresses like 192.168.31.2 appeared at the same time, is it likely it was hacked? I took all sorts of precautions, like using ssh (never telnet), restricting webmin to only being administered by certain known IP addresses, etc. In fact I've checked the output of last, which shows nothing suspicious, and installed portsentry to guard against attempts at hacking, and I'm almost beginning to think it was one of my precautions that automatically blocked this stuff in an overzealous attempt to protect itself. Output of ls -la /etc/network/if-up.d I guess in your next question is about /etc/network/interfaces, because there is no networking in /etc.
You should check that: http://www.howtoforge.com/faq/1_38_en.html It's possible that these routes are created by Portsentry. Can you disable it and reboot the system (make sure Portsentry doesn't start automatically at boot time). What's in each of the files? Yes, right. What's in /etc/iptables.up.rules?
Again, thanks for the tips. The page you refer to has chkrootkit typed in as ckrootkit in several places! Chkrootkit has shown false positives for the ports portsentry is guarding, like 1524, which correctly drops telnet connections. I wonder if testing the defenses by trying to connect to that triggered adding the computers I tried it from to the blocking list. Quite possible. Being hacked is unlikely, I just wondered how things got blocked, and one scenario that came to mind, (unlikely as it is) is that someone who has gained access is trying to block me from administering the server. But here is the output anyway: chkrootkit: rkhunter (which is up to date, --update says so): It does note, however: and I'll reboot without portsentry at the next opportunity, but it can't be done immediately, maybe tomorrow or the day after. I found a temporary workaround, to use one system which can still access the server to reassign a new 192.x.y.z IP address to the one being blocked. I can post the contents of the files in question, but having glanced at them they do look harmless, like configurations for the various services like postfix set up automatically by webmin. But here's what they say: mountnfs: ntp-server: ntpdate: continued on next post, over 10000 characters
continued from previous post: postfix: iptables.up.rules: I have a feeling it is portsentry, or at least something in the system set too strictly with regards to security, and therefore blocking what it considers suspicious activity. This is listed under the portsentry portion of webmin: Block TCP Probes: Yes (was No by default) Block UDP Probes: same Hosts to ignore traffic from: 127.0.0.1/32 0.0.0.0 I did not to my knowledge enter these numbers, either they were the defaults or some part of webmin created them in response to my configuration.
The files look ok. I guess this is also caused by Portsentry. That's ok, it does the same on my servers.
Rebooted with portsentry off, routes (at least the one internal one that was failing before) are now ok! Somehow I either misconfigured portsentry, or it is malfunctioning. I prefer to have it on to guard against threats, but I have to have this working. Actually when I say "I misconfigured" it is more than likely Webmin itself (version 1.300) actually made the config. files, it's only a question of what I could have put in the GUI to make it do so.
