How Hacker Can Access VPS CentOS 6 content? [closed]

Just want to understand. Please, correct mistakes and write advices

Hacker can access to VPS:

1. Through (using) console terminal, for example, using PuTTY.

To access, hacker need to know port number, username and password.

Port number hacker can know scanning open ports and try to login. The only way to login as I understand need to know username and password.

To block (make more difficult) port scanning, need to use iptables configure /etc/sysconfig/iptables. I followed this https://www.digitalocean.com/community/articles/how-to-setup-a-basic-ip-tables-configuration-on-centos-6 tutorial and got

*nat
:PREROUTING ACCEPT [87:4524]
:POSTROUTING ACCEPT [77:4713]
:OUTPUT ACCEPT [77:4713]
COMMIT

*mangle
:PREROUTING ACCEPT [2358:200388]
:INPUT ACCEPT [2358:200388]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2638:477779]
:POSTROUTING ACCEPT [2638:477779]
COMMIT

*filter
:INPUT DROP [1:40]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [339:56132]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP 
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP 
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP 
-A INPUT -i lo -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 110 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT 
-A INPUT -s 11.111.11.111/32 -p tcp -m tcp --dport 22 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -s 11.111.11.111/32 -p tcp -m tcp --dport 21 -j ACCEPT
COMMIT

Regarding ports that need to be opened.

If does not use ssl, then seems must leave open port 80 for website.

Then for ssh (default 22) and for ftp (default 21). And set ip address, from which can connect. So if hacker uses other ip address, he can not access even knowing username and password?

Regarding emails not sure.

If I send email, using Gmail (Send mail as: (Use Gmail to send from your other email addresses)), then port 25 not necessary.

For incoming emails at dynadot.com I use Email Forwarding. Does it mean that emails “does not arrive to VPS” (before arriving to VPS, emails are forwarded, for example to Gmail)? If emails does not arrive to VPS, then seems port 110 also not necessary.

If use only ssl, must open port 443 and close port 80.

Do not understand regarding port 3306

In PuTTY with /bin/netstat -lnp see

Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name
tcp        0      0 0.0.0.0:3306                0.0.0.0:*                   LISTEN      992/mysqld

As understand it is for mysql. But does not remember that I have opened such port (may be when installed mysql, the port is opened automatically?). Mysql is installed on the same server, where all other content. Need to understand regarding port 3306

2. Also hacker may be able access console terminal through VPS hosting provider Control Panel (serial console emergency access).

As understand only using console terminal (PuTTY, etc.) can make “global” changes (changes that can not modify with ftp).

3. Hacker can access to my VPS exploiting some hole in my php code and uploading, for example, Trojan.

Unfortunately, faced situation that VPS was hacked. As understand it was because I used ZPanel. On VPS ( \etc\zpanel\panel\bin) ) found one php file, that was identified as Trojan by some virus scanners (at virustotal.com).

Experimented with the file on local computer (wamp).

And appears that hacker can see all content of VPS, rename, delete, upload etc. From my opinion, if in PuTTY use command like chattr +i /etc/php.ini then hacker could not be able to modify php.ini.

Is there any other way to get into VPS?

Solution 1:

What you've described is a vulnerability of ZPanel if the file has been placed inside it's directory and is accessible trough web server - I've seen this happen a million times on Joomla/Wordpress installations.

As for the provided screenshot - this looks like a PHP shell which will be able to list the file system because Apache can access the file system. Which files/directories the script can access/read is up to the permissions set to those files.

Now to answer your questions:

1. I would suggest using CSF to secure your server which provides protection from port knocking and scans your SSH log to see if there are any brute force attacks going and block the attacker IP address. As for leaving open ports - ask yourself what will the server do and then open the needed ports:
   • 21 for FTP
   • 22 for SSH
   • 25 for SMTP server
   • 80 for HTTP
   • 443 for HTTPS if you're using this
   • 110/995 for POP3/POP3 via SSL - if you want to use a mail server on your VPS
   • 143/993 for IMAP4/IMAP4 via SSL - same as for POP3 connection

You can close the 3306 - MySQL port , if you need to access the MySQL server from a remote location you can always add a iptables rules that allows only the remote IP address to access port 3306.

Also, you can use SSH keys for root login and disable password login for the root user ( PermitRootLogin without-password ), so only users with the SSH key added in ~/.ssh/authorized_keys can access the root account. Another way is to completely disable root access and use another account so you can traverse into root account (su - root).

But your security is as strong as your weakest link - you can have everything locked down, but if the web app is vulnerable - they will find a way to get into it.

If you are the only one using the server, you can see with ZPanel on adding a HTTP Auth before accessing the panel, or if you are behind a VPN set HTTP server serving Zpanel to allow only access to your VPN IP address.

Edit: Adding chattr +i /etc/php.ini would disable any modifications to the php.ini file, as it has set an immutable attribute, not you (root) or any other would be able to modify the file.

As for php.ini protection you can consider modifying following options, if this is a production server:

• display_errors - Off
• expose_php - Off

Also you can disable number of unneeded PHP functions that would render PHP shell scripts unusable:

disable_functions = php_uname, getmyuid, getmypid, passthru, leak, listen, diskfreespace, tmpfile, link, ignore_user_abord, shell_exec, dl, set_time_limit, exec, system, highlight_file, source, show_source, fpaththru, virtual, posix_ctermid, posix_getcwd, posix_getegid, posix_geteuid, posix_getgid, posix_getgrgid, posix_getgrnam, posix_getgroups, posix_getlogin, posix_getpgid, posix_getpgrp, posix_getpid, posix, _getppid, posix_getpwnam, posix_getpwuid, posix_getrlimit, posix_getsid, posix_getuid, posix_isatty, posix_kill, posix_mkfifo, posix_setegid, posix_seteuid, posix_setgid, posix_setpgid, posix_setsid, posix_setuid, posix_times, posix_ttyname, posix_uname, proc_open, proc_close, proc_get_status, proc_nice, proc_terminate, phpinfo If your script is not working properly after these functions are disabled, check which function it would need enabled, remove from the list and restart your HTTP server.

Solution 2:

Well of course! It all depends on the attack surface.

Anything from the bottom of the stack upward is a potential target. Without knowing more about a particular VPS, we know that they must have at a minimum:

• Physical layer vulnerabilities (tapping a wire, stealing a physical server)
• Layer 2 vulnerabilities (sniffing traffic from another VLAN, ARP exploits)
• Networking vulnerabilities (denial of service)
• Session/Transport/etc (wrapping layer) vulnerabilities (manipulating client into thinking certificates are valid, other SSL problems, hijacking, etc)
• Presentation/Application layer vulnerabilities (your journey begins here)

In a virtualized environment, the stack kind of starts all over so that the application layer in the physical server hosts the physical layer in the virtual environment. For instance, say you are hosting a VPS on a single physical server with some hypervisor. Any storage, networking, or server issues can affect the virtual machines living on that server.

On the other hand, even if all is well in the physical world, the virtual environment hosts virtualized hardware so that you have to start all over again.

However, the two environments need not be considered totally separately. Though the virtual environment sits on top of the physical environment, it can still potentially reach physical networks. This is where overlap between the virtual and physical threats begins.

For instance, your ISP may have a physical edge router that inspects and filters traffic. It may check the querystrings of non-encrypted URLs to see if something is amiss. If the fitler were good enough, you might assume that you do not have to worry about traffic outside (thanks to bridging and NAT). Still, you may perform your own check on querystrings to be doubly-sure. In this case, the traffic has gone:

1. From client to ISP edge filter (physical)
2. Either: From ISP edge filter to client via physical-to-virtual bridging OR from ISP edge filter to client gateway to client
3. From client filter to client application

I understand that is a really roundabout way to answer your question but I am trying to say is that you should think about your attack surface - especially the lowest-hanging fruit - rather than think of a checklist. If you allow file uploads you have to have a reliable way to filter out bad files. If you allow basic HTTP authentication you will need to prevent eavesdropping and brute-force attacks. If you allow SSH you might want to carefully audit login attempts.

So rather than thinking of security categorically, instead think of it in terms of the attack surface that is created for your specific services to function.