Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I see these entries in here and am not sure what they are. Does anyone know what this is?
Oct 14 14:57:01 server xinetd: START: sgi_fam pid=19886 from=<no address>
Oct 14 15:39:34 server usermod: change user `gdm' shell from `/sbin/nologin' to `/sbin/nologin'
Oct 14 15:39:47 server usermod: change user `mailman' GID from `41' to `41'
Oct 14 15:39:47 server usermod: change user `mailman' shell from `/bin/false' to `/sbin/nologin'
Oct 14 15:41:19 server sshd: Received signal 15; terminating.
Oct 14 15:41:22 server sshd: Server listening on 0.0.0.0 port 22.
You sure you the only one that's got the root password? Either someone else is also doing things that normally require root privilleges or you have the worst memory to date in history!I'm not familiar with RH, but ain't sgi_fam the file alteration monitor? I'd say sometime fishy is up. If you have an md5sum of sshd, now may be the time to check it, just for hell. md5sum the top trojan'ed files. I know there's a sshd trojan going around right now. That plus the file alter. w/no address + sshd being shutdown & restarted looks like the start of trouble to me. I keep a hidden file with md5sums of the most popular trojaned apps + the ones I would hate for someone to trojan. That way I can tell if something is changed, by either virus/worm, trojan, bad users, whatever- without having to run a full service like tripwire, which would surely be deactivated by a competent cracker anyway upon breach of system.
I'd gather some more info, keep an eye out, and maybe set a few intrustion detection traps. Then watch for action if it appears that nothing has really occured, based on the log evidence you have already.