Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
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.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hi all,
Iam currently having a security issue due to a uninvited intrusion happen few days back. I've been checking the server for any possible backdoor but i could not find any. anyway i've finally found a weird SSH login logger which will log any successful SSH connection"id & password" (scary). The file was located under /dev/ and named "httpd". Im totally blank now. Dont know where to start troubleshooting. Please help me on this issue. Thank You in advance.
OS: CENTOS 5 i386
Kernel: 2.6.18-8.el5PAE
Last edited by biotones; 09-06-2010 at 11:38 PM.
Click here to see the post LQ members have rated as the most helpful post in this thread.
next, you use a live cd to analyse the server and to search for any other applications. (you may have found an application that logs successful ssh connection id and password but you havent figured out the HOW it arrived there!). fedora has a security spin for forensics. there are others you can find on distrowatch.
this of course doesnt sound practical, especially if this is a mission critical server, so you will need to replace the server while you do your forensics. failing that, in case this is a webhost, you are going to make your own tough decisions.
next, you use a live cd to analyse the server and to search for any other applications. (you may have found an application that logs successful ssh connection id and password but you havent figured out the HOW it arrived there!). fedora has a security spin for forensics. there are others you can find on distrowatch.
this of course doesnt sound practical, especially if this is a mission critical server, so you will need to replace the server while you do your forensics. failing that, in case this is a webhost, you are going to make your own tough decisions.
Dude thx 4 the reply, how ever this is indeed a critical web hosting server. The server still running due the other servers required files access on it. How do detect any script or software that doing the logging?
well: the better thing will be to recover an old backup you know to be clean.
Otherwise: server reinstallation, and data transfer being careful to what you transfer.
Obviously, this will be effective only after you found the original problem which let the intruder in!
well: the better thing will be to recover an old backup you know to be clean.
Otherwise: server reinstallation, and data transfer being careful to what you transfer.
Obviously, this will be effective only after you found the original problem which let the intruder in!
bye
giammy
Thx for the reply Giaamy,
Im doing a forensic task now. The sever was 1st invade by mySQL injection. It was running joomla and now i've remove the joomla main folder. Is there any forensic step is recon for this?
Thx for the reply Giaamy,
Im doing a forensic task now. The sever was 1st invade by mySQL injection. It was running joomla and now i've remove the joomla main folder. Is there any forensic step is recon for this?
sorry, i'm not a forensic specialist.
Anyway, they probably used joomla to access the system: I think that removing joomla just removed the door they used: they probably installed some software in the system.
The best thing for you to do is stop the activity with the server. If at all possible, isolate it from the network, but if it isn't too late do not reboot it as this may cause a loss of information. Next, start reading from this thread: http://www.linuxquestions.org/questi...erences-45261/ One of the things you should do is familiarize yourself with the CERT intruder detection checklist, perhaps run some of these tests on another known clean system to get an idea of what the results look like.
The activity, especially a strange file that logs ids and passwords, looks suspicious and you will need / want to take appropriate action. There are others on this forum that are very knowledgeable in this regard and will have questions for you and ask you to perform checks. Until then please don't disturb things any more than is possible.
well: the better thing will be to recover an old backup you know to be clean.
Otherwise: server reinstallation, and data transfer being careful to what you transfer.
giammy
Please be aware that this forum works on a fact-based basis and offering this specific advice is frowned upon. As you noted, unless you've done an investigation, simply re-installing may be putting the original weakness back in place. Noway2 has the approach we're after.
Quote:
Originally Posted by biotones
Im doing a forensic task now. The sever was 1st invade by mySQL injection. It was running joomla and now i've remove the joomla main folder. Is there any forensic step is recon for this?
Can I ask what the basis for these decisions was? If you've got some evidence, we would love to see it so we can help.
Other things to look at:
The outputs of lsof -Pwn, netstat -pane and ps -axfwwwe.
Any suspicious log entries
A good resource for investigating is the CERT Checklist.
It would also help to have a better description of the server. What we're after is things like the state of patching, what services are being run, is it a VM guest and the intended use of the machine. Knowing about installed software like Joomla and its patch state would be good. Knowing a bit about its network environment may also help.
Also, since you suspect an SSH breach, if you can't pull the network cable, you should put a firewall in place that only allows SSH access from trusted IP addresses.
Please be aware that this forum works on a fact-based basis and offering this specific advice is frowned upon. As you noted, unless you've done an investigation, simply re-installing may be putting the original weakness back in place.
I agree, however, a wipe & reload (even with the original vulnerability) is better than leaving the box online. Wipe & Reload might also bring in newer software, leading to a net security improvement.
(Forensic analysis & lockdown are best of course, but not everyone has the resources.)
I agree, however, a wipe & reload (even with the original vulnerability) is better than leaving the box online. Wipe & Reload might also bring in newer software, leading to a net security improvement.
Certainly it is better than leaving an infected box online if there is absolutely no other option, but all too frequently wipe and reload is offered as the first thing to do, which is never right in my opinion. As for the forensic analysis, the kinds of stuff we ask for here tend to be fairly simple. If someone can't work their way through the CERT checklist or post the output of a few commands, they probably shouldn't be running a server.
I guess my concern is that the owner of infected boxes actually learn a little something about how to stop cracks in the first place, or detect them if they can't. I don't think a wipe and reload teaches them anything near enough about the security aspects of being responsible for a server.
Please be aware that this forum works on a fact-based basis and offering this specific advice is frowned upon. As you noted, unless you've done an investigation, simply re-installing may be putting the original weakness back in place. Noway2 has the approach we're after.
Can I ask what the basis for these decisions was? If you've got some evidence, we would love to see it so we can help.
Other things to look at:
The outputs of lsof -Pwn, netstat -pane and ps -axfwwwe.
Any suspicious log entries
A good resource for investigating is the CERT Checklist.
It would also help to have a better description of the server. What we're after is things like the state of patching, what services are being run, is it a VM guest and the intended use of the machine. Knowing about installed software like Joomla and its patch state would be good. Knowing a bit about its network environment may also help.
Also, since you suspect an SSH breach, if you can't pull the network cable, you should put a firewall in place that only allows SSH access from trusted IP addresses.
Thx alot guys, I'll upload the requested file asap. Im actually away from office due some urgent matter. Sorry for the late reply.
Hi Hangdog,
There's no VM running. I Believe the server is far from latest patches. I dont believe its a SSH breach because I've limit the ssh connection only from few IPs. BTW i've run the command and theres nothing on logging the ssh connection. pif...
I agree, however, a wipe & reload (even with the original vulnerability) is better than leaving the box online.
While he's pretty much capable of putting the idea forward I'll still wedge in a reply to say I agree with Hangdog42 completely.
This is not about "net security improvement" or allocating resources but about the right approach to handling incidents. A "wipe and reinstall" may be a verdict, a conclusion, but never the starting point. LQ members who by reflex post "wipe and reinstall" (and often never return to the thread) should not post that but go read incident handling threads here and the standard docs. Also this is not up for discussion. This is how we want incident handling to be done at LQ. Any member who still thinks "wipe and reinstall" is the way to go will find enough fora on the 'net where they won't care for more than that. Not here.
Hi Hangdog,
There's no VM running. I Believe the server is far from latest patches.
I dont believe its a SSH breach because I've limit the ssh connection only from few IPs. BTW i've run the command and theres nothing on logging the ssh connection. pif...
Could you explain this last bit in a bit more depth? Are you saying that the logging command you found isn't actually logging? That might be a good thing, but it still doesn't explain how it got there and unless you do a bit more investigating, you don't know if other compromises have happened.
Kind of a semi-on-topic response being I really didn't quite understand your last post either; but I was kind of expecting you to post the output from those commands for the rest of us to look at?
Also, if you didn't delete /dev/httpd which is the suspected ssh logger, you can use it's timestamps to perhaps help narrow down in the logs where to start looking?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
