Results 1 to 6 of 6
Im getting a few random on my server logins and it looks like they have messed with a few things and to say the least im not very happy. Rather ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 05-12-2011 #1
Random logins from an unknown server?
- 05-13-2011 #2
- 05-13-2011 #3
Iv seen things like that before but that isn't enough info for what I want. Im more interested in seeing everything he types in over ssh not just what programs he is running or what account he is on
- 05-14-2011 #4
- Join Date
- Aug 2009
In short: while Linux may be free to use, using it is not free of responsibilities.
I hope you agree.
Logging done by users themselves inside their own domain, think shell history, is untrustworthy because (apart from any read-only variables set in global resource files) they control it. For the same reason I would strongly suggest avoiding any kludges like wrapping the shell in say 'script'. The Honeypot project supplies or supplied a logging BASH shell and there are two common logging shells available: 'sudosh' and 'rootsh'. While primarily used as wrapper around the users own shell at least rootsh can be run standalone and set logging destination and avoid command line args by compiling in defaults. A more trustworthy (but also more invasive if your distro doesn't cater for this) setup involves kernel-based logging using 'auditd' rules and SELinux for protecting the logging mechanism itself. With that kind of logging in place, with "immutable" rules ('auditctl -e 2') and combined with remote syslogging you can also be notified if root tried to change things. Finally logging features do complement each other so having out-of-the-box logging, a logging shell and auditd definitely is not overkill.
Last edited by unspawn; 05-14-2011 at 11:36 AM. Reason: //more *is* more
- 05-15-2011 #5
I definitely understand where your concern is coming from but as far as the rest of my network is concerned its very safe. This is just a small pet project of mine and I didn't spend the time securing it, im very interested in figuring out what they want and what they were interested in for the security of the rest of my system. I have a hunch that its being used as a bounce server and once I can confirm thats all they wanted I will shut the rest of the world out but its fairly important to me that I first find out what they wanted and how exactly they got in.
- 05-15-2011 #6
- Join Date
- Aug 2009
0) as log as you don't "freeze" the machine to contain the breach any movement (reading and writing files, logging in and out, performing updates, log rotation, cronjobs), be it by the intruder or the system itself or you, will overwrite and trample "evidence" so the longer you wait the less will remain and
1) Linux distributions (which one is your server using?) do log auth records and such but out of the box do not come with exhaustive auditing enabled. So what then remains for you in terms of "evidence" (unless doctored with) are:
- auth records ('last; lastb; lastlog') written on login / logout,
- any system or service log showing SSH logins (and deity forbid you allow root logins),
- any system or service log showing typical web stack manipulation like SQL injection or downloading,
- verifying integrity of files and finding any introduced (setuid/setgid) binaries or scripts. Easy if your Linux distribution comes with mature package management elif you ran some file integrity checker (OK, fat chance ;-p) else manually against "known good" copies of package (contents) or a remote(!) backup from way before the first time of entry,
- generating a MAC time line of files changed ('find /some/path -xdev -printf "%T@ %A@ %C@ %U %G %m \"%p\"\n"') if you have a clue users introduced binaries, scripts or archives or "dot-name" hidden files or directories,
- user shell history files,
- changed password and group entries and listing all users crontabs (/var/spool/cron),
- listing full process ('ps axfwwwe'), open files ('lsof -Pwln') and network connections ('netstat -anpe'),
... basically all of what the CERT/CC Intruder Detection Checklist provides. Also processing all system and service logs (preferably copied over to a separate and known safe machine) with Logwatch may be a good way to look for clues ('logwatch.pl --numeric --detail 5 --service all --range All --archives --print 2>&1').
Sure you can use any hunches to guide you (if you think an IRC boucer was set up it would be easy to find) but in essence finding out what was done (if possible) requires enumerating what was there in the first place (which net-facing services and web stack components and if they have any known vulnerabilities) and not making any assumptions: just focus on what the data tells you.