New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
@psycholyzern as long as any system hook to the internet ... there are bots always scan for unsecured system. a basic iptables, very strong ssh password or use SSH login without password will give you a basic protection.
Just see it as a learning experience, we all fuck up. Just make sure it doesn't happen in future!
A useful command is
netstat -tuplen
which I always use to check what is listening on a fresh VPS, after I installing new software and after any maintenance. Anything that is listening needs security evaluation.
yah.. Its a new experience for me.. thanks all..
thank you
Have you fix it? I'm a bit suspicious with the /etc/init.d/taskgrm- and /etc/init.d/modules_dep.sh. Also, check your /etc/passwd, just in case you had an illegal user account in the system.
But as other said, when we had the vps, run update & upgrade, change the ssh port, install firewall (denyhosts, fail2ban, csf, etc). Change the root password from the SolusVM, change the root password from ssh. ( Just for prevention if the provider SolusVM database had been leaked, so the attacker had the SolusVM password and vps root password, but the vps root password had been changed by us from ssh, so the attacker can't use our vps.)
You can also disable root login, but before you do that, always make sure you had your ssh-keys configured correctly, otherwise you will be locked.
Here is a good article about why putting SSH on another port is a bad idea.
tldr; It's security through obscurity, and also running SSH on a non-privileged port could allow non-privileged users to run a "fake sshd" on that port to capture credentials.
This guy is completely wrong.
Let's enumerate why:
He then goes on to recommend another form of "security through obscurity" btw.
he makes this argument about how only root can run on privileged ports. But doesn't recommend that you could run ssh on a different low port and achieve most of the same benefit, so I guess his real argument is that you must run on port 22.
his nonsense about "I could run a server on 2222 and steal passwords" is silly. Yes, you could, if I don't start ssh at boot time. If I start ssh at boot time...you can't bind to it. How do you propose to bind to this port? Why not bind to port 80/443 and put in your own credit-card-number-stealing web software?
And what if there are no other users, or the only users are admins? There are tons of servers where only admins (who have root) have access, so who are these legions of password-stealing users?
Apparently he's unfamiliar with server fingerprinting. The server's host key is not world-readable, so the only way you're going to fake being the server I want to talk to is to somehow steal this key.
Writing things IN CAPS does NOT MAKE THEM TRUE.
WTF? When I have legions of developers with badly written programs I'll worry about this. What are these applications, btw?
Since he's a developer, I guess I'm not surprised he thinks admins should bow to his code shortcomings :-)
But I thought "...this is nothing more than security through obscurity, and if you think that that is a good idea, you should not be allowed behind a computer.. ever…"
And then we get to his port-knocking idea:
This idea is not his - I've seen it before. But...wait...let me get this right...there are all these fragile applications in the world that can't possibly be reconfigured to talk on any port other than 22, but they can be reconfigured to first talk to port 3456 and then connect to port 22?
I have yet to be inside any corporate firewall that allows 22 out or in. Much less "often".
And how am I supposed to do my port 3456->port 22 tango?
He completely fails to mention any kind of active firewall (e.g., CSF/LFD/fail2ban/etc. which would watch for failed ssh connections and insert a firewall rule)...which is a better idea than his port knocking scheme.
This guy is trying to sound all security guru...
...when really he has no idea what he's talking about.
I notice comments are disabled...
@raindog308
I second this .....you took a while to write this post and great analysis btw
@psycholyzern
Is your website PHP based or just HTML/CSS
@raindog308 thanks for the detailed counter argument. Your VPS Advice site is also quite good.
Personally I don't see much/any harm in changing the port especially if it's under 1024. However the only real advantage I see is fewer connection attempts using resources and getting logged. The SSH server should not be letting strangers in no matter what port it's running on.
Disabling password authentication is much more important. Also it makes using SSH much more pleasant. Other options that can help are AllowGroups and AllowUsers, or only allowing connections from trusted IPs. And of course tools like fail2ban.
Have a look at my IPTables port scan detection tutorial, which was posted earlier on LET. Using this technique, you can easily thwart any port scan attempt by hackers to find your non-standard SSH port, by dropping traffic from an IP upon detection of X number of ports being hit within Y seconds (both configurable).
more information:
https://github.com/ValdikSS/billgates-botnet-tracker
reference:
https://isc.sans.edu/forums/diary/Unfriendly+crontab+additions/17282
It sounds like the guy who wrote that article thinks you can only choose 1 thing to secure SSH. So yea, if you only do 1 thing to secure SSH, changing the port would be the weakest option to choose.
I reinstalled my server.. I did all you said.. even disable root.. I create a user that have sudo access
I got a html for index.. and some php script that doesnt functioning at all, I mean, the script does not doing anything..
Are you sure? :-)
yah.. php script that manipulate yuotube api.. but didnt do what it should do
One thing I like to do for machines where I should be the only root user is to not only disable root logins but also limit su to members of the 'wheel' group. I've noticed some distributions do this by default (eg. Gentoo), but not all of them do (eg. CentOS). You can do it by adding or un-commenting a line in /etc/pam.d/su :
That way to break in and get root access you have to figure out which account is a member of wheel and its password (or better yet, private key) as well as the root password. This breaks down if you give yourself full powers with sudo since then you (probably) only need your own password to become root. It also breaks down if you need more than one person to be able to become root, because you end up needing to use sudo to let them do it (or you have to share root's password, which is even worse IMHO).
The best bet if you can do it is to use sudo very sparingly and only for very specific purposes rather than handing out the ability to actually become root.
@psycholyzern, do you still had the bruteforce attempt to the server now?
I forgot to mention, try to install logwatch and configure, so you can get the email whenever there's a change to the system, a login attempt, and anything about the server.
Check all the php files on your server....a hacker may have modified a php file to shell your website
I dont see any in my auth.log.. btw, will it logged? because I changed my ssh port.
ok.. I will try
I did..
You will get some log for ssh login attempt, included with the failed one
All of my vps having logwatch, so everyday they will send me an email about my vps activity. ( Installation, user logged in, disk space)
wow.. it would be many email in my inbox..
btw, i will take a look
Yes, you would had a lot of emails, but we can apply some Labels(Gmails) or automatically swipe/filter it in Outlook to automatically go to a folder. Having some informations is always better than hacked right?
You don't need SSH to get shell. For all we know, his xinetd could have a socket up for some webshell.
No offense OP, but you clearly have little to no experience securing systems.
My advice would be to reinstall the entire system (from scratch), after taking backups of your dbs / user data / whatever.
Who knows what other binary has been compromised / chattr +i'd?
@ErawanArifNugroho I got some tries from 108.166.98.9 but before I change my ssh port.. After i change my ssh port,no log are being record about those failed tries
yah.. I am learning from forums and blog.. i dont have enough knowledge and experinces in securing the server.. I just have fun with them and host some small website..
I did reinstall.. and use backup on my laptop and not from the infected server
the scripts like ddos script recently we got alot of orders using our VPS to ddos game servers using similar scripts .