All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
VPS being port scanned by anonymus
Recently I got my VPS port scanned by anonymous guy.
He came from : leased-line-87-252-246-142.telecom.by and was using "Test" as his login ID.
The process consuming more than 60% CPU
He was running some script (./pscan2)
How did he gained access to my VPS (root login has been disabled)?
I remembered I just updated my FluxBB (officially) to the latest and this all happened .
Anyone can share of how to prevent this happen again in the future?
test 18354 0.0 0.3 3000 1620 pts/2 Ss 05:05 0:00 /bin/bash
test 18358 0.0 0.2 3140 1212 pts/2 S+ 05:05 0:00 /bin/bash
test 30553 0.0 0.1 968 560 pts/2 S+ 16:38 0:01 ./ssh-scan 100
test 30574 0.0 0.1 968 560 pts/2 S+ 16:39 0:00 ./ssh-scan 100
test 30577 0.0 0.1 968 560 pts/2 S+ 16:40 0:00 ./ssh-scan 100
test 30578 0.0 0.1 968 560 pts/2 S+ 16:40 0:01 ./ssh-scan 100
test 30581 0.0 0.1 968 560 pts/2 S+ 16:40 0:00 ./ssh-scan 100
test 30582 0.0 0.1 968 560 pts/2 S+ 16:40 0:00 ./ssh-scan 100
test 30583 0.1 0.1 976 516 pts/2 S+ 16:40 0:01 ./ssh-scan 100
test 30593 0.0 0.1 968 560 pts/2 S+ 16:40 0:01 ./ssh-scan 100
test 30594 0.0 0.1 968 560 pts/2 S+ 16:40 0:00 ./ssh-scan 100
test 30598 0.0 0.1 968 560 pts/2 S+ 16:40 0:00 ./ssh-scan 100
test 30604 0.0 0.1 968 560 pts/2 S+ 16:40 0:00 ./ssh-scan 100
test 30605 0.0 0.1 968 560 pts/2 S+ 16:40 0:00 ./ssh-scan 100
test 30613 0.0 0.1 968 560 pts/2 S+ 16:40 0:00 ./ssh-scan 100
test 30617 0.1 0.1 976 516 pts/2 S+ 16:40 0:01 ./ssh-scan 100
test 30620 0.0 0.1 968 560 pts/2 S+ 16:40 0:00 ./ssh-scan 100
test 30636 0.0 0.1 968 560 pts/2 S+ 16:40 0:00 ./ssh-scan 100
test 30638 0.1 0.1 976 516 pts/2 S+ 16:40 0:01 ./ssh-scan 100
test 30642 0.0 0.1 1128 612 pts/2 S+ 16:40 0:00 ./ssh-scan 100
test 30643 0.0 0.1 968 560 pts/2 S+ 16:40 0:00 ./ssh-scan 100
test 30651 0.0 0.1 964 556 pts/2 S+ 16:41 0:00 ./ssh-scan 100
test 30657 0.0 0.1 968 560 pts/2 S+ 16:41 0:00 ./ssh-scan 100
test 30659 0.0 0.1 968 560 pts/2 S+ 16:41 0:00 ./ssh-scan 100
test 30664 0.0 0.1 968 560 pts/2 S+ 16:41 0:00 ./ssh-scan 100
test 30670 0.0 0.1 968 560 pts/2 S+ 16:41 0:00 ./ssh-scan 100
test 30746 0.0 0.2 2640 1108 pts/2 S+ 16:46 0:00 /bin/bash ./a 200.23
test 30838 0.0 0.0 948 188 pts/2 S+ 16:55 0:00 ./ssh-scan 100
Comments
what user is it (you actually have a user called test?)? And is it actually access or an attempt?
Did you change your ssh port, did you bother to tweak your sshd_config for stricter settings? Have you switched to paired-key authentication?
Also if the script ssh-scan is actually running on the box, then I hate to say it... but your box is compromised and should probably just be wiped.
Most of the time w hen someone's ssh is compromised is because they used a weak-ass password, and didn't bother to set 'root' login to 'no' or 'without-password' on sshd_config. Or similar to a user with wheel access.
Also where is ssh-scan on the drive, is it running out of a /tmp folder that didn't have noexec on?
The user "test" was created by the intruder I believe.
I never have "Test" user.
Sadly, the port scanning activity came from the box itself. (Never change the ssh port either).
What should I do now to prevent him comprimising my box in the future?
I don't know where was it running from.
sql injection maybe ?
do you have webserver installed on vps?
After a hack/compromize, the best thing is to start afresh and delete all files (after backup) because the first thing the intruder will do is copy backdoors into your files
Secondly, do a full audit and path the VPS including the access logs and error logs
Thirdly, patch the old scripts and update your server on a regular basis (I keep nagios to keep track of updates)
Fourthly, install logwatch (https://gist.github.com/4006677) or some other program to keep track of whose doing what!!! In my experience the compromise is done at least a few hours before the actual attack happens, sometimes even a day before the actual attack.
What OS are you running, and what kind of software was running on it? What services were launched and listening?
Weak passwords, low VPS security. You need to move at least SSH on non-standard port and restrict access to it.
If you're on a KVM/XEN (or even openvz) based VPS that has VNC access, you could even go as far as switching to paired-key authentication, and disable password authentication completely so that only way to shell into the VPS is with your private/public key. And then course use a different port to avoid the whole bots scanning for SSH servers still running on 22.
If you do choose to just use a password, something over 10 digits, using both lower and upper case letters and at least one number and symbol would improve protection against brute-forcing greatly. (installing Fail2Ban would also help against brute forcing).
Well, that is possible. Those things came up after I tried to update my FluxBB. Maybe there was some exploit in the scripts.
Yes, that is highly possible. I have changed SSH port and root password, etc but the intruder still can login and run the exploit repeatedly.
I'm running Debian 6 latest and using Nginx as my webserver, mysql, squid (DotDeb Repo)
Thanks for the recommendation, I'll use 10 digits+ from now on.
Right now I put the box in "halt" state because the intruder is still able to login.
Any ideas to stop this besides reinstall the OS? -_-
What software are you running on that server? Including non-web software.
Changing the SSH port will not protect you.
All of this.
No. The only proper solution is not using password authentication at all. To generate an SSH keypair,
ssh-keygen -t rsa. Place the resulting ~/.ssh/id_rsa.pub (or other path if you changed it), in ~/.ssh/authorized_keys on the server for whatever user you want to enable login with that key. Finally, edit /etc/ssh/sshd_config (or your distro's equivalent) and make sure that it saysPasswordAuthentication Nosomewhere (often there's a line you can uncomment). Restart your SSHd. Done.EDIT: And again, changing SSH to a nonstandard port will not protect you. It is a form of security through obscurity, and the only real purpose it serves is to hide from lazy scripts. It doesn't cover the other 99,99% of scenarios where you could be compromised, and if you do decide to move your SSH to a nonstandard port, it will cause issues with a lot of software that requires SSH access, as not all of them allow you to define a different port.
If you want to prevent bruteforcing, install fail2ban.
@Fritz on debian I only use DotDeb for PHP, and only PHP. MySQL is installed from the main debian repo, and nginx is installed from the official nginx repo. Not that it would make a huge difference by I find the least hassle that way.
Follow joepie91's recommendations. His methods are effective, he knows his stuff.
I'm using minstall script.
@joepie91
Thanks for your recommendation.
Any complete guide that "fool"-proof for securing our box for newbie.
Thanks before.
I ended up reinstall everything. Ahh..fresh air.. lol.
My conclusion is, someone put an exploit into FluxBB script which is uploaded to my box.
Did you not update FluxBB from the official sources?
@nunim => munin => http://munin-monitoring.org/ => Version 2.0.8 => 2+8 = 10 => 10-3 = 7
FluxBB => http://fluxbb.org/ => Version 1.5.1 => 1+5+1 = 7
Coincidence?!
I THINK NOT!
Lol @halfeatenpie
Thanks again @joepie91
It doesn't protect you from targeted attack, but it does protect you from the unsophisticated majority of attackers. By removing that noise it might make it easier for you to spot an attack if/when one comes.
That is what fail2ban is for.
After you getting everything resolved, sign up for cloudflare and enable it. That should help protect you from a sql injection if that is what you think happened. You may also have your server acting as a DDOS tool.
So it can notify you every time a skiddie is banned on :22 ? I used fail2ban for an ssh service on :22 and there were a TON of notifications coming in all the time.
No, so it can block them out.
Only Cloudflare Pro supposedly protects against SQLi. Not the Free plan.
Dude, do you work for Cloudflare?
My logs stay clean.
Ipchains and fail2ban.
Google it.
Still need a good IPchains config I think?
Why not stop using the CPU time and such for fail2ban on the scriptkiddies when you can change the port.
Because that breaks other stuff?
And honestly, if fail2ban causes issues with CPU time, it's probably time to upgrade your Pentium 2.
Well VPS are in a shared environment... I bet if everyone used fail2ban - fail2ban would cause a lot of cpu time. I say - just setup key auth >.>
I doubt it.
As far as I know, even if you have password authentication disabled, there is still a certain amount of cryptography involved in every login attempt via SSH. That means that you are probably actually causing more CPU usage by doing nothing except disabling password auth, than you would if you set up fail2ban. Cryptography is expensive (in terms of CPU).
I don't know of any software that uses SSH and doesn't allow you to specify the SSH port, though some of them actually require you to RTFM to figure out how to do so (which seems to be a foreign concept to most people nowadays). And if there is something out there like that... well, it's a piece of shit and you probably shouldn't use it anyways.
I've had the issue at least once with a standard GNU tool (I forgot which) that didn't allow you to use a custom SSH port and some other kind of option together, because the syntax of the command changed. I can't recall the specifics.