route default changed (who did it?)

[steven Burgess_2]

Hi all

We had an issue yesterday where on of our servers in OZ stopped communicating. We found the default route to be incorrect. But only by one character ??

There is nothing in roots history or the sam log apart from the engineers actions


Ideas anyone?

Thanks in advance

Steve

[Christopher McCray_1]

Hello,

If you have auditing enabled, it is possible that that information could be in the audit files. Use the audisp command to view their contents.

I hope you find what you're looking for

Chris

[melvyn burnard]

Hmmm, time for magic wands and crystal balls, methinks.

Anything in syslog.log?
Are you aware of anything being done on/to the system that was not "normal", e.g. scheduled work, etc?
have you checked the sulog?
have you run last or lastb to see if anyone was logging in around that sort of time?



One minor point, are you running gated? if so is it patched?

[steven Burgess_2]

Melvin

There is nothing in the syslog.

I am not aware of gated

Most support staff log on as root , so su log only shows root switching to other users as opposed to others to root. Which I know can be an issue

[John Carr_2]

Hi

I had this problem and pulled most of my remaining hair out before I realised someone in our networking dept had changed the IP address on the actual router.

when you discovered the route was incorrect was this through the /etc/rc.config.d/netconf file or the o/s ?

check the time on the netconf file to see if this is prior to yesterday then you can tell if the file was changed or the change was made on the fly ie add route default .....

hopefully someone changed the file which need root permission normally but check the file permissions. Now back track using last lastb and look at all log files for errors relating to failed comms.

good luck
John.

[steven Burgess_2]

The netconf has r-- r-- r-- permissions

looking through last to see who was on at the time the problem was noted

Cheers

[pap]

Hi,
Just check when the
/etc/rc.config.d/netconf file updated?

IF it is not updated within 2 days then this seems to be a different kind of problem may be IP changing on router or so...

-pap.

[John Payne_2]

This is one of the classic type of problem you run into when you have more than 1 sysadmin and they all log in directly as root. (Or even if there is only 1 and they log in directly.) You always want to be able to retrace your steps. Some people go to the extreme of not letting anyone have root without having to grovel and beg for it, some use some sort of security software layer on top of the OS, some use sudo, some just make it a policy that people log in as themselves and su to root.

IMHO, you should at least have them log in as themselves and su to root. You don't have to enforce neccessarily, the honor system may be ok. Also, you should be taking advantage of the logging function of inetd. In /etc/rc.config.d/netdaemons, if you add a '-l ' (That is -L) to the end of the 'export INETD_ARGS=' line, you should start to see logging in your syslog. (Will show things like who logged in from where, etc) This will at least leave a trail of crumbs if something like this happened.

So anyway, look and see the date for /etc/rc.config.d/netconf. If it has not changed, then there were no changes to your systems. If this problem is happening across several (or more) boxes, you really need to be talking to your networking guys...

Hope it helps

John

[pap]

Hi Steven,

It always a problem when mutiple SA works on same site and handling same machines. For that you should have to deny access directly to root on all terminals. The SA has to login with their ordinary login id and when they need super user access they can go using "su" command. This is the good method to track logins for all super users. The "sulog" file will keep the record of all logins who tried to use "su".

You can do this by creating file /etc/securetty and put a single entry in it for console.

This is just a suggestion.

Thanks,
-pap

[Sandip Ghosh]

The entry inside the /etc/securetty file should be root instead of console.

Sandip

[pap]

Hi,

The entry in /etc/securetty must be console and not the root.

securetty itself tty to be secureed. here you can put any tty name from ehre you want to block direct root login.

Securetty is meant only for superuser and hence no need to specify root.

-pap

[Ron Kinner]

Ask your network guy if he's running HSRP. (That maybe a Cisco term. Don't know. Stands for Hot Standby Router Protocol.) With HSRP you have two routers and both can do the default but only one is active at a time. To make this switch transparent to the PCs they define a virtual ip address and the active router responds to any attempts to send packets to the virtual address.

Assume you have Router A with address 192.168.1.252 and Router B with 192.168.1.253
The Virtual address might be 192.168.1.254.

Say Router B is the active router and someone made a mistake and pointed the PC at Router B's real address of 192.168.1.253 instead of at the virtual address of 192.168.1.254. Everything works fine and everyone is happy. Now Router B dies hard and Router A takes over. Everybody is still happy since they point to the virtual address and Router A is handling that now. Everyone except the one PC which points at B's real IP. His default route is now one number away from the correct default address and you are looking for the man who wasn't there!

Ron

[rick jones]

besides gated, there is also the rdpd or router discovery protocol daemon which will listen to advertisements on the net and use them to select the "best" default route for the system.

neither are enabled by default, but if running they would appear in the output of ps.

[steven Burgess_2]

Hi chaps

Thanks for all your input. I spoke with one of
our senior staff last night about the problem.

We do actually log all of our logins from our access server here in the uk, we also have a job in cron that picks up all the root logs and advises where they log in from on the remote server. We use sna on this box to pass mainframe traffic, i have instances of when the sna stopped talking, so will spend a little time matching the logs to see who was logged on and when. The problem I have is the fact that the engineer added the correct route and ran net from /sbin/init.d and didn't advise when the netconf file was last edited.

I'll advise of the culprit when I have a solid answer.

Thanks again

Steve