Logging facility for rlogin

[so_2]

Hi all,

I have a problem last week that the .profile file of an application user have been modified by someone. I checked the sulog (the server wont allow direct login to root) but no trace of an SU to root found. I suspect that some one might have rlogin to this server( rlogin is enabled) as root and commited the change.(The buisiness loss was huge...)
Now please let me know is there any other logs that I need to chcek who logged to the server as root during that time. And also let me know how to enable logging facility for rlogin service. I cant disable rlogin as it is a buisiness requirement.
Thanks in advance
s.o

[Peter Godron]

Hi,
what is your rlogind entry in inetd.conf ?
For rlogin to work unlogged, some serious breaches must have occured.
Anything in the history file for root ?

[Jaime Bolanos Rojas.]

so,

I do not think that information is logged by default, but you might want to go through this document and enable auditing for the future:

http://nixdoc.net/man-pages/HP-UX/man1/auth.adm.1m.html

Regards,

Jaime.

[Steve Steel]

Hi


1)
grep ": su" /var/adm/syslog/syslog.log

last -R

2)Did someone load sudo on the machine

3)Are you sure that the .profile was only root changeable

4)If it was deliberate someone could have ftpd the new copy in.


Indeed auditing is the best bet to be sure.

Steve Steel

[Bill Hassell]

You wrote:

(The buisiness loss was huge...)

and

I cant disable rlogin as it is a buisiness requirement.

These two statements are in direct opposition to each other. The 'r' commands (rlogin, remsh and rcp) are very well known security risks and are the first items on an auditor's remediation list (read: turn them off!!) All the features of rlogin can be accomplished with SSH. I am sure that the rlogin requirement is for some internal convenience, and that implementing SSH as a business process will cost time and money. In that case, I refer back to your business loss...

While your company may not be subject to independent auditing, it is an unsound idea to fix the blame rather than fix the problem. A log may show an rlogin with the IP address but it cannot identify the person. Only router logs can identify the MAC address which then could be traced to an actual computer. Indeed, most PCs are given a semi-random IP address via DHCP. It is also important to note that root access is *NOT* required to modify an application file such as .profile -- all that is needed is the ability to login as the application user, or more typically, a duplicate UID account (hackers commonly use this method). Run the command login -d to check for duplicates. Note that good security demands that no application be run as root and no duplicate login IDs are allowed.

Now rlogin requires very a specific setup to run on HP-UX. Good security demands that .rhosts not be allowed for root and that all .rhosts files in every $HOME directory be 600 permission. Also, there can be * (asterisk) in any .rhosts file. The * can be used to accept any external user or external machine or IP address, or worse: both. And there must never be a file called /etc/hosts.equiv (where the * settings affect every account).

Now none of the .rhosts and host.equiv rules are really adequate because the 'r' commands bypass security. The best security is to disallow root logins at all. That's correct! No password is ever given to anyone, or as an alternative, a cron job keeps changing the root password randomly. So the only possible way to attain root privileges is to configure sudo and use ssh. Don't take the easy road and allow users ALL=ALL privileges.

The modification of .profile was probably a well-meaning change made by someone trying to be helpful. But on a production machine, the ability to perform this kind of action must be prohibited and instead, run through your test system. If all is well, then move the change to production.

Now if all of this sounds complicated and costly in terms of time and procedural changes, I refer you to the first statement above.

[so_2]

Thanks all who replied

this is the entry for rlogin daemon in inetd.conf.

root : grep rlo /etc/inetd.conf
login stream tcp6 nowait root /usr/lbin/rlogind rlogind
# The standard remshd and rlogind do not include the Kerberized
klogin stream tcp nowait root /usr/lbin/rlogind rlogind -K




What arguments if I passed the logging can be enabled. I accept the choice of enabling auditing, but if we are able to logg from rlogin service, i think that would be a wiser option without sacrificing the server performance.

Thanks again.
s.o

[Bill Hassell]

The man page for rlogind lists all the options for the daemin. No mention of logging options and the executable doesn't seem to refer to any logfile. However, rlogin and remsh (rsh from non-HP-UX systems) will write entries to /var/adm/wtmp. So you can read this file with the last command:

last -R root

This will show all the logins.