Linux - Security This 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.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
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.
|
|
03-12-2007, 10:55 AM
|
#1
|
LQ Newbie
Registered: Feb 2007
Posts: 8
Rep:
|
How do I know I've been breached?
I searched through the invalid ssh login thread but I could not find anything about how to tell if these dictionary attacks have been working against my server. I have looked into the logs, but I am pretty new to this so I don't think I can tell what is "normal" server behavior and what is not. Is there a sure-fire way to tell if someone has broken into your server? This is a personal server I am using for development so the good news is I only have one user (me) and the root account, and I have changed both of those passwords and the user name. Here is a sample of the error I see in the log:
"***sshd[8552]: Invalid user maruyama from 193.15.55.4"
Also, I try to report what I can on these to their host, but it is a real pain to trace them back to the right person.
Any help would be greatly appreciated!
|
|
|
03-12-2007, 11:19 AM
|
#2
|
Senior Member
Registered: Sep 2005
Location: Out
Posts: 3,307
Rep:
|
Yes, comparing old checksums of files with current ones. That's 100% sure if you trust the hashing methods.
Several integrity systems are available in Linux.
Otherwise, theorically, noway to be sure.
|
|
|
03-12-2007, 11:36 AM
|
#3
|
LQ Guru
Registered: Aug 2003
Distribution: CentOS, OS X
Posts: 5,131
Rep:
|
I agree; if a person is able to break into your system, then that person usually knows it's not wise to leave traces behind, so probably most of the "traces" that you would hope to find are cleaned up by the time you start looking for them, if your system happened to be breached, so probably the only method that is half way sure are checksums; that means, though, that you can't store the checksums anywhere where they are accessible from the server (or any other place on the network), because if somebody got to know where they are, they could be re-created to try to fool you.
There is a lot of software made to ease your task of making sure nothing is altered; tripwire is one of them. The thumb rule is to never trust, but always think your system is not secure. If somebody was interested enough in breaking into the system that person could do it, because there is (and probably is never going to be) no way to make (for example) a server bullet-proof. All you can do is hope you notice what's going on before it's "too late", pull the server off the network and start fixing it. Take a look at tripwire for example and start searching around for software for your needs.
If there was a simple method to see, by reading logfiles, if somebody is really trying or has succeeded in breaching a system, then it would already be automated and wouldn't happen anymore.
|
|
|
03-14-2007, 01:02 AM
|
#4
|
Member
Registered: Mar 2007
Location: Bedford, Texas
Posts: 31
Rep:
|
The first thing that comes to mind is to take a look at two logs on the server.
/var/log/secure
/var/log/messages
You will be able to see attempts from user to log into the server and failing. Also run the last command it will tell you who logged in, from what IP and when. Compare the two if you see an unknown IP in last's output look in the users directory and look for the IP in the logs and see if you can see when they broke in and to who's account.
|
|
|
03-14-2007, 06:36 AM
|
#5
|
LQ Veteran
Registered: Feb 2003
Location: Maryland
Distribution: Slackware
Posts: 7,803
|
One of the things you should have done before putting this on the net is installed a file integrity checker like Aide, Samhain or Tripwire. If a file being monitored is changed, those programs will let you know about it.
|
|
|
03-28-2007, 12:44 PM
|
#6
|
Member
Registered: May 2005
Location: Northern VA
Distribution: Slackware, Ubuntu, FreeBSD, OpenBSD, OS X
Posts: 782
Rep:
|
I'd say check your system logs, but you shouldn't trust them totally, as rootkits usually wipe log traces of intrusions. Rootkits also replace certain tools with hacked versions that are designed to hide activity that would be logged, so that if you use a hacked version of, say, lsof, you won't see what you need to see to investigate a compromise. In this case, it is probably best to use investigative tools from a trusted source (the tools would best be run from a CD-R).
I've no real faith in HIDS, but my experience with them aren't the best. If your machine is hacked, NOTHING on that machine is trustworthy, event a HIDS. TCPDump goes a LONG way, as it is a NIDS...it will see anything going over the wire, such as backdoor traffic.
I've two NIDS placed on my network. One monitors internal traffic and the other monitors traffic before my LAN. One other monitors my public colo server, which dumps its logs to my home machine's IDS server. I can access traffic logs of all three servers from the IDS server. The thing with NIDS is that they are rule-based...if you don't do periodical updates, you're not going to be using the latest/greatest rules.
|
|
|
04-02-2007, 01:16 AM
|
#7
|
Moderator
Registered: May 2001
Posts: 29,415
|
Is there a sure-fire way to tell if someone has broken into your server?
Basically you follow the steps as outlined for any breach of security we've handled over the years in this forum. Maybe check out a few threads to get the idea. Run your audit tools (from Live CD if in doubt) and follow this guideline: Intruder Detection Checklist (CERT): http://www.cert.org/tech_tips/intrud...checklist.html.
Also, I try to report what I can on these to their host, but it is a real pain to trace them back to the right person.
A laudable approach but a Sysiphus task still. If you still choose to report, best report to the abuse@ address. Notice a lot of ISP's dump those reports due to whatever reasons valid or not. Automated reporting like Dshield and Mywatchmen are more favourable since they have a global scope which benefits everyone.
If you determined it's a true breach of security post your findings here, if not head over to the LQ FAQ: Security references and see if you should change or add to your boxen's security posture.
|
|
|
04-02-2007, 07:20 AM
|
#8
|
Member
Registered: Jul 2006
Posts: 134
Rep:
|
Some Thoughts
An old buddy of mine posted this on a now-gone website:
Assuming your system uses /etc/profile.d to store scripts to be run on login, do the following:
vi /etc/profile.d/loginreport.sh
#and add the command
mail -s "$USER Login: $HOST $SSH_CONNECTION" user@domain.com < /dev/null > /dev/null
#and change permissions on the newly created file
chmod 755 /etc/profile.d/loginreport.sh
This will send out an email to the specified adddress (user@domain.com - preferrably not an address on the local machine) anytime an ssh connection is successful.
To protect from the dictionary attacks, I recommend APF/BFD which will auto-block IP's afer a specified number of unsuccessful attempts. Use the following links to get started:
http://www.dedicated-resources.com/g...Firewall).html
http://www.dedicated-resources.com/g...etection).html
Deion "Mule" Christopher
|
|
|
04-03-2007, 12:37 AM
|
#9
|
Moderator
Registered: May 2001
Posts: 29,415
|
This will send out an email to the specified adddress (user@domain.com - preferrably not an address on the local machine) anytime an ssh connection is successful.
What this does is send out an email any time /etc/profile.d/loginreport.sh is run: the script doesn't check for type of login. Other than that if it's run it'll be too late since the intruder already logged in, so beefing up on Firewall, host and SSH security should be done before implementing any "logging" like this. Most SSH "blockers" where mentioned ages ago in http://www.linuxquestions.org/questi...d.php?t=340366.
|
|
|
04-03-2007, 09:06 AM
|
#10
|
Member
Registered: Jul 2006
Posts: 134
Rep:
|
"Other than that if it's run it'll be too late since the intruder already logged in, so beefing up on Firewall, host and SSH security should be done before implementing any "logging" like this. Most SSH "blockers" where mentioned ages ago in http://www.linuxquestions.org/questi...d.php?t=340366."
Your quite right. That is why I also posted the links for APF and BFD in my reply. I should have included a link for rkhunter as well though.
I'm not sure I'm following your comment unSpawn: The originator asked, "Is there a sure-fire way to tell if someone has broken into your server?" to which I suggested the mail command above.
Good point though - once you receive the e-mail about an ssh connection, it is too late. But you will at least have an IP to use as a lead...
Deion "Mule" Christopher
|
|
|
04-04-2007, 04:26 PM
|
#11
|
Moderator
Registered: May 2001
Posts: 29,415
|
I'm not sure I'm following your comment unSpawn
Sorry, which comment are you referring to I should clarify?
But you will at least have an IP to use as a lead.
For anyone using a box they own that's helpful. For those using one or more intermediaries, not really: the trail ends there.
|
|
|
04-04-2007, 06:41 PM
|
#12
|
Senior Member
Registered: Nov 2004
Location: Texas
Distribution: RHEL, Scientific Linux, Debian, Fedora
Posts: 3,935
Rep:
|
geoffmat, the suggestions in this thread are good, and in particular I concur with the HIDS (I like aide, personally) recommendation. Be sure to keep your HIDS db on an external device / server.
Also important: This may be a good time to reevaluate the sshd service you're providing. Who are you providing sshd access to? Can it be restricted to certain networks / users? Does it really need to be open to the world?
|
|
|
04-05-2007, 10:12 AM
|
#13
|
Member
Registered: Jan 2007
Distribution: Slackware
Posts: 341
Rep:
|
Quote:
Originally Posted by geoffmat
"***sshd[8552]: Invalid user maruyama from 193.15.55.4"
|
a. Do not allow root login for ssh. Modify your /etc/ssh/sshd_config file:
b. Close any unnecessary ports.
c. Watch who is logged on your computer (man who).
d. Watch any connection with state "ESTABLISHED" and user "0" (root).
e. Remember: Trust is a weakness.
|
|
|
04-06-2007, 07:19 AM
|
#14
|
Member
Registered: Jul 2006
Posts: 134
Rep:
|
Might I add to what Road map suggested?
If you want to move to the paranoia range of things, set up ssh to allow "a single, normal user in the wheel group" to ssh in ONLY from a specific machine inside your internal network. Then set up that chosen machine for remote access (XP use RDP/VNC | Linux use ssh/vnc). This will produce two security hurdles to overcome to access your box...
Deion "Mule" Christopher
|
|
|
All times are GMT -5. The time now is 03:27 PM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|