how to log the info of users remotely connected to the server?

recently someone somehow made a terrible mistake (destroyed an important database application by re-initialised a disk).

the shell used was ksh with HISTFILE configured in .profile.

I can see in .sh_history.xxxx files what that person did.

But I just don't know from which machine (IP) the telnet connection was made.

Users don't have the console access to the server.  Thay can only access the server remotely (telnet, FTP etc)

Was wondering if there is an utility can be configured to record the info like IP or host name of a remote machine making connecttions like telnet to the server.

My Solaris is 8 and everybody uses ksh by default.

Any advise/help will be greatly appreciated.

Who is Participating?
beskyConnect With a Mentor Commented:
There is a possibility to log all TCP connections
to the syslog.

Edit /etc/init.d/inetsvc, at the end inetd will be started.
add a -t as option and the connection will show up in
/var/adm/messages as a deamon.notice message.
It should look like this :
/usr/sbin/inetd -s -t &

and you have to give the running inetd a kick with:

pkill -HUP inetd

btw, nice users you have there
The last command will show you who logged and from where.
I forgot, if rootpermissions are required to do these tasks, let noone log in as root.
If they connects as a user and use the su command you can check the sulog for usage of the su command.

Or you could install sudo, a good freewarepgm to handle rights to commands and admintasks

Cloud Class® Course: Certified Penetration Testing

This CPTE Certified Penetration Testing Engineer course covers everything you need to know about becoming a Certified Penetration Testing Engineer. Career Path: Professional roles include Ethical Hackers, Security Consultants, System Administrators, and Chief Security Officers.

Ryan RowleyCommented:
If a remote telnet or ftp user can cause this type of situation, I would be concerned about security.
Is there a reason for remote users to have this level
of access.
Are your users on fixed IP addresses or DHCP allocated addresses - if the latter then capturing the address is pointless.

I agree with the other posters however - your major problem is not really capturing the address of people connecting to your system but the lack of security that allows a user to format a disk!
It sounds like you have some "fiddlers" on your roof!

Here is what I would do..
Install TCP Wrappers - this will give you control and detailed connection history.
Follow the advice of besky by running inetd with the -s and -t flags.
alter the entries in the /etc/inetd.conf file for ftp to
add the -dl flags.
install tripwire - this will allow you to track changes to any file on the system.
if users are using DHCP - consider permanent leases for the users who have access to the system (this can be enforced by tcpwrappers mentioned above).
if the system is Solaris - get a hold of sunscreen lite (host based firewall).
consider the use of process accounting or BSM (be careful with BSM - it creates a LOT of information)
if you suspect that the connections may not have been made by "authorised" users - consider installing ssh and giving your users an ssh client like "putty".
by far the BEST suggestion i could give you is to build a box running an IDS like NFR, or SNORT with specific rules for connections to your system - this will not cost a lot (and in the case of snort it is free) but will provide an independent source of corroborative evidence (should it be required).

I hope this helps
frankfAuthor Commented:
thanks for all your advise/comments.

my department is a technical support department.

the nature of everybody's work decides that everyone needs root user access to all servers.

everybody uses static IP - thats why I want to know where the connection is made from

this time one of my servers was screwed

it takes fair bit of time to re-set the whole thing up including Oracle and Apache databases

Although I can't "shoot" that guy but at least I need to set something up which enables me to know who is the one keep making this silly mistakes in the future

Without wishing to be rude, why does everyone need root access to all the servers?

If this is so perhaps you could quarantine the databases onto a server (or servers) to which they don't have root access.

Alternatively, if they need root access to a server to test problem solutions could they not have access to a chrooted file system so they can only mess up their own pseudo-server rather than stuff up the underlying system.

Just some avenues of thought that might be worth exploring to prevent you having to rebuild servers in the future.

I understand the issues with needing multiple people to have root access to a group of servers. While that's not the ideal case, it is the real world in a lot of cases. My preferred solution in that environment is to have only one person set a root password on each of the servers. That root password(s) get recorded and locked up in a place that only senior managment/admins have access to in the event that those passwords are required, like for a single user boot. Ordinary  admins are only allowed root access via sudo, which records each time they exercise root privs.
I concur with jlevie, but understand that "support" staff
often require root privs. It is far better to have good auditing and controls, and even better to have very few with access to root - but sometimes it is more practical
(not that I would advocate it).

I have handled this before with sudo, C-based setuid wrappers for common functions etc. but in the end if there is root access on the local system being used - you may not be able to rely upon the log files (especially if the users are clever).

External controls are the most effective way of monitoring - it is for this reason that I normally setup sniffers in front of any honeypot i deploy - to capture everything.

The only thing to be aware of is that sniffers can generate a lot of logs (if the system is constantly being accessed) - it is often necessary to limit the tracking to one or two protocols.

This question really should be in the security forum.

Kind Regards,
frankfAuthor Commented:
I accepted besky's comments as the answer.  I implemented and it worked as I hoped.

in a short term, I still have to let everybody has root access to all servers as this is our department's "culture".  If I have this changed/removed obiousely I'll upset alot of people.

in a long term, I have to do some thing, as you guys suggested, to prevent this kind of thing from happening again.

Thanks again for all your input!

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.