frankf
asked on
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.
Frankf
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.
Frankf
The last command will show you who logged and from where.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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
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
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.
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!
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
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
ASKER
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
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
frankf
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.
Cheers
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.
Cheers
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,
Clinton
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,
Clinton
ASKER
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!
Frankf
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!
Frankf