Whatsapp/ Telegram: +65 9776 5889 Live Chat Submit Ticket   Login
Windows Cloud Servers and Dedicated Servers are protected from RDP Bruteforce

Windows Cloud Servers and Dedicated Servers are protected from RDP Bruteforce

kaspersky endpoint comes default with every cloud servers and dedicated servers. You might not have been aware that Kaspersky Endpoint Security comes default for our Microsoft Windows Cloud Servers and Dedicated servers  which included Intrusion Detection System, and now it has an ability to detect RDP (Remote Desktop Protocol) bruteforce attack attempts.
Hacking an RDP-connection is very lucrative: once an attacker gets login-password pair for RDP, he or she effectively owns the system where the RDP server is installed. Attackers can then plant malicious software in the affected system, exfiltrate data, etc. He (or she) also can gain access to your company internal network, given that the “penetrated” workstation is connected to it, or attempt to check out all of the passwords in the browser installed on the affected system. Opportunities are multiple, and the consequences can be dire.

How to schedule a backup Job on Cloud Server

How to schedule a backup Job on Cloud Server

backup_panel backup_job backup_email_notification kaspersky_endpointEach Cloud Server comes with 2 free backup instances at no cost regardless of backup size. Additional backup instances can be ordered at only $10 /monthly. This is an useful feature to customers make changes to their files often and requires a roll back in case of any mishaps.

To perform a manual backup and schedule backups are very easy tasks with our control panel, just few clicks away and the hassle-free backup feature will send you an email notification if whether the backup is successful or unsuccessful that requires attention and rectification.

Control panel of the cloud server


Scheduling Backup Job for cloud serverdaily backup report for cloud server




Multiple PHP versions in Plesk 12

With Plesk 12.0.18 onwards, multiple PHP 5.x versions (PHP Select) can be installed and this is a new feature built by Plesk team. Via Plesk panel, without any additional third-party repositories or building PHP from sources by yourself anymore.

The new Plesk PHP packages do not conflict with or replace other PHP packages, so you can continue using your current PHP builds or third-party PHP packages.

Currently, PHP packages from the Plesk team are available on CentOS 6, CentOS 7, and Ubuntu 14. In Plesk 12.1, Plesk will extend this to Ubuntu 12, Debian 6, Debian 7, and RHEL 6, 7 operating systems

SSH With Two-Factor Authentication, Google Authenticator

To protect your SSH server with an two-factor authentication, you can use the Google Authenticator PAM module. Each time you are connecting to your server via SSH with Google Authenticator PAM installed  you have to enter the code from your smartphone with Google Authenticator installed.

On Red Hat, CentOS and Fedora systems install the ‘pam-devel‘ package.

# yum install pam-devel make gcc-c++

Install Wget if you have not installed one yet

TOTP (timebased one-time-password) security tokens are time sensitive. Hence, make sure that your system has ntpd running, and is configured to start the service at boot

# service ntpd start
# chkconfig  ntpd on

Download and extract Google authenticator module under Home directory (assume you are already logged in home directory of root).

# cd /tmp
 # wget http://google-authenticator.googlecode.com/files/libpam-google-authenticator-1.0-source.tar.bz2
 # bunzip2 libpam-google-authenticator-1.0-source.tar.bz2
 # tar xf libpam-google-authenticator-1.0-source.tar
 # cd libpam-google-authenticator-1.0
 # make
 # make install
 cp pam_google_authenticator.so /lib64/security
 cp google-authenticator /usr/local/bin

Before configuring SSH, first set up Google Authenticator. Run “google-authenticator” as the user you wish to log in with via SSH. You will be prompted with a few questions.

Do you want me to update your "~/.google_authenticator" file (y/n) y
https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/[email protected]%3Fsecret%3DABCD12E3FGHIJKLMN
Your new secret key is: ABCD12E3FGHIJKLMN
Your verification code is 98765432
Your emergency scratch codes are:
Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y
By default, tokens are good for 30 seconds and in order to compensate for
possible time-skew between the client and the server, we allow an extra
token before and after the current time. If you experience problems with poor
time synchronization, you can increase the window from its default
size of 1:30min to about 4min. Do you want to do so (y/n) y
If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y

This requires all users to use Google Authenticator for SSH authentication. To only require those users with Google Authenticator configured for their account (the ~/.google_authenticator file exists), then instead enter “auth required pam_google_authenticator.so nullok“.

The order in which you place items in this file matters. Given this configuration, you will first be prompted for your Google Authenticator verification code, then for your system account password when you SSH into the system.

Modify /etc/ssh/sshd_config. Verify these settings:

PasswordAuthentication yes
ChallengeResponseAuthentication yes
UsePAM yes
# service sshd restart

When you SSH into the system as a user configured for Google Authenticator, you will have to enter the verification code that is displayed in you Google Authenticator app, and then by your system password at the next prompt:

login as: root
Verification code: 01234567
Password: *******