Say Goodbye to 2-Year Certificates and Hello to Multi-Year SSL Plans

Say Goodbye to 2-Year Certificates and Hello to Multi-Year SSL Plans

As of September 1st, 2-year certificates have been replaced by multi-year SSL plans offering similar benefits

September 1, 2020 marked the dawn of a new era for SSL certificates. Multi-year SSL certificates are now history. The only certificates that will be trusted by major browsers will be those with a validity period of 397 days or less. Why 397 days, you ask? That’s one year plus a one-month grace period for renewal.

Don’t panic yet, though. In reality, multi-year SSL certificates aren’t TRULY going away. It’s more a situation of “they are, but they aren’t.” You see, this change was a long time in the making, so Certificate Authorities (CAs) have had ample time to prepare. In response, they’ve introduced new multi-year plans that will provide similar benefits as the old multi-year SSL certificates did but work a bit differently in practice.

So why were multi-year SSL certificates eliminated in the first place? How do the new multi-year plans actually work? And how do you go about implementing them in your organization?

Let’s hash it out.
Shorter Validity = Higher Security

At its core, the goal of the change is to improve security for users of the world wide web (and not to make your life more complicated, even though it may seem that way at first glance). Those that supported the change argued that the shorter the validity period of a certificate, the more secure it is.

There are several key advantages to shorter-term certificates, including:

  • A shorter lifespan for keys, which means a shorter lifespan for compromised keys, as well. With shorter certificates, you have a smaller window of exposure if a key is stolen.
  • Certificate security updates are rolled out into the wild at a much quicker pace.
  • Organizational information is updated on a yearly basis, including company names, addresses, and domains, which translates to increased user trust.
  • Automation is encouraged. With a good certificate management system in place, there is no difference in convenience between shorter and longer lifetimes. They are automatically re-issued when needed, regardless of the validity period.

Users will have to do a little bit extra on their end as the switchover is being made, but the trade-off is a higher level of security over the long-term.

What Does It Mean for Your Website?

First off, only public TLS certificates are affected. Private-root and other certificate types (such as code signing certificates, S/MIME certificates, document signing certificates, etc.) are not impacted.

What about certificates issued before the September 1 deadline? Good news: they will remain valid for their original validity period. The only time you’ll notice anything different is if they need to be re-issued. In that case, you won’t lose any of the validity time, but you’ll need to plan to re-issue again if your initial validity period is still greater than 397 days.

The ultimate answer to “what does it mean for your website?” is that you have more frequent certificate expiration dates to consider. Subsequently, it means that proper certificate management is more important than ever. Automated platforms, such as DigiCert’s CertCentral or Sectigo Certificate Manager, can be a huge help with reducing the risk that expiring certificates pose to your organization, but more on that shortly. Now let’s take a closer look at the specifics of the new multi-year SSL plans.

New Plans, Same Benefits
Save Time & Lower Costs with Multi-Year SSL Plans

So does this mean goodbye to multi-year discounts? Nope! You’ll still enjoy cost savings with these new-age multi-year plans. One of the main benefits of the old multi-year SSL certificates was the price-break you received. The more years you bought, the bigger the discount was on a per-year basis. CAs have mirrored this system in the new plans, so fortunately nothing is changing in that regard. You will still be rewarded for buying multi-year certificates. You’re simply pre-paying for certificate usage upfront, so there’s a discount for that.

You’ll still be saving time with the new multi-year plans, too. You only need to purchase the multi-year SSL subscription once, which is an especially useful feature if your organization has any kind of lengthy purchase-approval process in place. So, at the end of the 397-day validity period all you have to do is re-issue the certificate. That’s it. There’s no need to go through all the legwork of making a brand-new purchase.

Here’s an example of what the new multi-year plans look like with DigiCert’s Secure Site SSL product:

DC-SS-SSL-Multi-Year-Plans

 
If You Can’t Beat It, Automate It

These plans were also created to further support automation (if it hasn’t been drilled into your head enough yet, automation is a wonderful thing for certificate management). With a certificate management system in place, you don’t even have to worry about the re-issuing task that we were just talking about. All you need to do is setup your system to auto re-issue your certificate every 13 months (or more frequently if you want).

You can implement true automation using DigiCert CertCentral and protocols like ACME. It allows for communication with the CA directly from your server and makes the installation process completely hands-off, requiring no help from the administrator. ACME works for OV and EV certificates and allows for both 1-year and shorter, custom validity periods. It is anticipated within the industry that certificate lifespans will continue to shorten, and by investing the time to setup automation now you can ensure you’ll be ready.

The screenshot below shows the process for adding an ACME directory URL in CertCentral, as well as the ability to input your own custom validity period:Acme-Directory-Config-ARVITA

Using automation protocols like ACME is faster and easier than the manual method, and it eliminates the threat of unanticipated certificate expirations. Your costs will be lowered as well, since your staff won’t have to spend their time performing the tedious, time-consuming certificate management tasks. You’ll expose yourself to less human error and will be able to recover from any security incidents more quickly and easily. If you’ve been putting off implementing an automated certificate management platform, now is a great time to do so.

A Real-World Example

Now let’s take a closer look as to how multi-year SSL plans work in practice. Say you’ve just purchased a new 3-year DV certificate plan. How exactly does it work? What all do you need to do on your end to stay secure?

When you first issue the certificate, it will be issued with a validity period of 397 days. Whether you have an automated system in place or not, you’ll be getting an email notification from your CA/certificate provider in advance of the certificate expiration. If you’re manually managing your certificates, then you’ll especially want to pay special attention to these reminders.

So, let’s say you just got a 30-day expiration reminder. At that point, you’ll have 30 days to re-issue (free of charge, of course) the certificate and complete domain validation.

Once you’ve done that, you’ll instantly get a new certificate that’s valid for another 397 days. Basically, you’ll keep repeating the process until the overall validity time is used up.

As far as the logistics of the purchase itself, you have a few different options. As before, you can buy multi-year SSL certificates via our website, API or through integrations like WHMCS.

A Step in the Right Direction

The move away from multi-year certificates is something that has been in the works for years. It’s a change that will require a bit of extra action from users at the front-end, but one that will ultimately translate to a higher overall level of security for websites and users alike.

With shorter validity times across the board, effective certificate management is also more important than ever. The increased adoption of automated systems is expected, which will hopefully lead to a drop in costly expired certificate incidents over the long-term.

And luckily for you, the website admin, CAs and the rest of the SSL industry were well-prepared for the September 1 deadline. With the new multi-year subscription plans in place, customers can still receive the same benefits and cost savings that they got with the old multi-year SSL certificates.

Overall, it’s a change that might seem intimidating at first glance, but one that is proving to be a win-win for all involved.

20% off on any Dedicated Server and VPS server

20% off on any Dedicated Server and VPS server

We’ve added five new references to our catalogue of Dedicated servers with 128 IPs. These new products can be ordered as of now in our Canadian and French data centers. We would also like to take this opportunity to announce the launch of the server series for our new data centres in London, Frankfurt, Warsaw, Sydney and Singapore.

Enjoy the discovery with 20% discount on any dedicated server and VPS server on this Cyber-day.

Promo Code:MARCH2020

Please Note:

  • These offer started on 11:00PM IST, 03rd March 2020.
  • Offers are valid on any Dedicated & VPS  Servers only.
  • These discounts are valid until 12:00AM IST, 31th March 2020.
  • The cost prices that you see on your control panel have been updated to include this special discount.
  • Any discount that may have been applicable previously on these hosting products will expire unless explicitly mentioned on our website.
  • Additional taxes will be applicable.

Dedicated Server

https://www.arvitaglobal.com/server/dedicated-server-usa-europe/

https://www.arvitaglobal.com/servers/enterprise-dedicated-servers/

https://www.arvitaglobal.com/manage/cart.php?gid=15 (32 IPs)

https://www.arvitaglobal.com/manage/cart.php?gid=35 ( 256 IP)

https://www.arvitaglobal.com/manage/cart.php?gid=38(128 IP)

 


Our VPS service start with 17$ per month

https://www.arvitaglobal.com/server/linux-virtual-private-server-usa-europe/

Windows VPS

Buy SSL

Chrome 68 is here – Help you to Get Secured: Buy Now & Secure Your Website

Chrome 68 is here – Help you to Get Secured: Buy Now & Secure Your Website

Arvita Global SSL

On July 24th, Google officially launched Chrome 68. With new features and security enhancements, Chrome continues to leverage its market dominance to push for a safer and more secure internet.From the beginning, security has been one of Chrome’s core principles and one of the biggest changes in Chrome 68 is displaying ‘Not Secure’ warnings for websites not encrypted with HTTPS.

Nearly two years ago, Google announced that Chrome would eventually start marking all sites that are not encrypted with HTTPS as ‘Not Secure’ as an attempt to motivate site owners to improve the security of their websites. With the release of Chrome 68, that has now become a reality.

As of Chrome 68’s rollout date, Google reports that HTTPS usage has made incredible progress over the past two years. They report that today:

76% of Chrome traffic on Android is now protected, up from 42%
85% of Chrome traffic on ChromeOS is now protected, up from 67%
83 of the top 100 sites on the web use HTTPS by default, up from 37

Google isn’t finished yet though. Starting in October 2018, Google plans to start showing a red ‘Not Secure’ warning when users enter data on pages that are not served using HTTPS.

If any of you or your customer’s websites are still without SSL Certificates, now is the time to help get more secure and avoid these Chrome security indicators by offering SSL Certificates from Emporis Software Solutions.

Emporis Software Solutions automates the entire SSL lifecycle, from the initial purchase and provisioning process, to CSR generation, provisioning, deployment and renewal.

If you haven’t activated purchased yet, start using SSL today and make secure your website.

Buy SSL Now

SSL is required and Only 4 months left

SSL is required and Only 4 months left

Google’s new age of Secure Internet is set to take another giant leap forward this coming July 2018 with the launch of Chrome 68.

For the past several years, Google has been increasingly advocating the use of HTTPS by gradually introducing not secure warnings to more and more HTTP pages. But soon, with the release of Chrome 68 due out on July 1st, 2018, Chrome will begin marking all HTTP sites that don’t have an SSL Certificate as “Not Secure”.

This presents a big opportunity for you and your business. Many website owners don’t know this change is coming and not only can you help your customers be prepared for this change before July 2018 , but we provide the solution that prevents you for losing visitor confidence and business when Chrome 68 is released.

Plus there’s never been a better time to start offering SSL certificates – with the fully automated issuance and deployment available with us and the instant activation, it’s never been quicker or easier to begin using SSL.

Why is this happening?

Google and Mozilla, the two most popular web browsers that together account for over 65% of web traffic, have been working to increase SSL usage for a while now.

Last year they began to make changes that encouraged the use of SSL by marking sites with forms and input fields on pages served via HTTP as Not Secure.

Now, with the release of Chrome 68 in July 2018, Google is stepping things up even more by labeling any website served via HTTP as “Not Secure”.

google-chrome-68-not-secure-warningIn addition to increased visitor confidence, HTTPS has many other advantages for website owners. HTTPS is faster, more performant, and more secure than it’s HTTP counterpart, it’s also been proven to help with SEO rankings, and provides the ability to use HTTP/2 for even greater speed improvements.

If you’re not yet using SSL to on your website yet, you should start doing so today! Buy SSL Now

With Emporis Software Solutions you can start selling SSL in under 60 seconds. And with our ready made landing pages, you have the perfect place to point your business towards to learn more about the benefits and advantages of SSL, as well as browse your range of SSL offerings.

Don’t leave it too late. With SSL becoming a requirement, you need to make sure you’re offering your customers a solution to this growing problem. With over 75% of internet traffic using Google Chrome, doing nothing simply isn’t an option

source:whmcs.com
[/vc_column][/vc_row]

Basic Security on a Linux Server

Basic Security on a Linux Server

Here in this guide we will show how to make some basic security configurations on the Server, so it is a bit more secure against hackers.

In this example we will use a fresh installed “Ubuntu 16.04 – Plesk Onyx” vServer M8 to showcase and test it.

1. Make sure that the Server is up to date
(this is something you should do regularly on the Server so the latest security patches etc. are installed)

Code:
apt-get update && apt-get dist-upgrade

2. Configure login over SSH Key and disable Password login

3. Create a new non-root-user (you can add this user to the sudo list “usermod -aG sudo <username>” as a root user, or just “su root” when needed)

Code:
# adduser community
Adding user `community' ...
Adding new group `community' (1010) ...
Adding new user `community' (1000) with group `community' ...
Creating home directory `/home/community' ...
Copying files from `/etc/skel' ...
Enter new password:
Retype new password:
passwd: password updated successfully
Changing the user information for community
Enter the new value, or press ENTER for the default
        Full Name []:
        Room Number []:
        Work Phone []:
        Home Phone []:
        Other []:
Is the information correct? [Y/n] Y

Also add an SSH Key there for the login

Code:
su <username>
mkdir /home/<username>/.ssh/
chmod 700 /home/<username>/.ssh/
nano /home/<username>/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Test if you can login into the new user

4. Configure the sshd_config (Change SSH Port/Disable root login)
Change the SSH Port there (If you already have a firewall configured DO NOT forget to allow the connection on the new port) and disable root login

Code:
nano /etc/ssh/sshd_config

Change “Port 22″there to the port number that you want, in this example I will use 1923

My SSHD_CONFIG now looks like this:

Code:
# cat /etc/ssh/sshd_config
# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 1923
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile     %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

5a. Basic configuration of the firewall via UFW(uncomplicated firewall)

Keep in mind that on the vServers there is a limit on the rules that you can set. You can check how many you are using and how many you can set with:
cat /proc/user_beancounters | grep numiptent

Example:

# cat /proc/user_beancounters | grep -iE “numiptent|uid”
uid resource held maxheld barrier limit failcnt
numiptent 173 177 256 256 0

As you can see I am using 173 and I am allowed a max of 256

Install UFW

Code:
apt install ufw

As we do not have IPv6 we can disable it

Code:
nano /etc/default/ufw

and change the “IPV6=yes” to “IPV6=no”

Add the rules:

Code:
ufw allow 1923

Change this one to the port number that you using for SSH

ufw allow 22 -> for the fake SSH
Add all ports that you use

If you are sure that the SSH port is allowed runs then
(with “ufw show added” you can check all the rules that will be added”

Example:
# ufw show added
Added user rules (see ‘ufw status’ for running firewall):
ufw allow 1923
ufw allow 22
ufw allow 21
ufw allow 8443
ufw allow 80
ufw allow 443
ufw allow Postfix)

to start the Firewall and update the rules use:

Code:
ufw enable

5b. Basic configuration of the firewall via IPTables

Please do not forget that the firewall configuration depends on your needs and your configuration so the rules and ports need to be changed according to your server! Running this blindly may cause losing the connection to the server. We take no responsibility for that.

You can also setup the configuration over IPTables.
Here in this example we will block all incoming traffic and only allow the one we want.
Do not forget to set your SSH port to allow incoming first before setting the drop policy!

To check all your rules you can use the command “iptables -L”

Here you can see that at the moment there are no rules and the policy is to accept all:

Code:
# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Also as external check I did a port scan before the setup:

Code:
$ nmap <Your IP or Hostname> -PN -p1-10000

Starting Nmap 7.01 ( https://nmap.org ) at 2018-03-23 08:05 CET
Nmap scan report for euve183269.serverprofi24.de (62.75.138.43)
Host is up (0.0073s latency).
Not shown: 9984 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
22/tcp   open  ssh
25/tcp   open  smtp
53/tcp   open  domain
80/tcp   open  http
106/tcp  open  pop3pw
110/tcp  open  pop3
143/tcp  open  imap
443/tcp  open  https
465/tcp  open  smtps
993/tcp  open  imaps
995/tcp  open  pop3s
1923/tcp open  unknown
4190/tcp open  sieve
8443/tcp open  https-alt
8880/tcp open  cddbp-alt

Nmap done: 1 IP address (1 host up) scanned in 0.74 seconds

So as advised above first I will set my SSH port to accept connections:

Code:
iptables -A INPUT -p tcp --dport 1923 -j ACCEPT

change the 1923 to the port where your SSH is active

Code:
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

This will allow connections to port 22 where I will setup the fake SSH in step 6

Code:
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 8443 -j ACCEPT

Here I did now allow access to the Webserver and Plesk

Code:
iptables -A INPUT -i lo -j ACCEPT

Here we do allow the loopback connections so that we do not get issues with some services etc.

Now that we do have our SSH allowed we can change the policy to drop with:

Code:
sudo iptables -P INPUT DROP

This will now cause all incoming connections where there is no allow rule specified to be rejected.

Now we check again with iptables -L

Code:
# iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:1923
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:https
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:8443
ACCEPT     all  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

As you can see “Chain INPUT (policy DROP)” so the default is set to reject all input/incoming
And then we have the other rules to accept the connection. We can check that with a new port scan:

Code:
$ nmap 62.75.138.43 -PN -p1-10000

Starting Nmap 7.01 ( https://nmap.org ) at 2018-03-23 08:16 CET
Nmap scan report for euve183269.serverprofi24.de (62.75.138.43)
Host is up (0.0075s latency).
Not shown: 9995 filtered ports
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
443/tcp  open  https
1923/tcp open  unknown
8443/tcp open  https-alt

Nmap done: 1 IP address (1 host up) scanned in 24.99 seconds

And a 2nd scan checking all ports that where open in the first scan:

Code:
$ nmap 62.75.138.43 -PN -p21,22,25,53,80,106,110,143,443,465,993,995,1923,4190,8443,8880

Starting Nmap 7.01 ( https://nmap.org ) at 2018-03-23 08:18 CET
Nmap scan report for euve183269.serverprofi24.de (62.75.138.43)
Host is up (0.0075s latency).
PORT     STATE    SERVICE
21/tcp   filtered ftp
22/tcp   open     ssh
25/tcp   filtered smtp
53/tcp   filtered domain
80/tcp   open     http
106/tcp  filtered pop3pw
110/tcp  filtered pop3
143/tcp  filtered imap
443/tcp  open     https
465/tcp  filtered smtps
993/tcp  filtered imaps
995/tcp  filtered pop3s
1923/tcp open     unknown
4190/tcp filtered sieve
8443/tcp open     https-alt
8880/tcp filtered cddbp-alt

Nmap done: 1 IP address (1 host up) scanned in 1.26 seconds

As you can see all ports we did not specify in the IPTables are filtered (not accepting the connection)
Please be careful when setting this rules as it is way to easy to get locked out of the server if wrongly done or in wrong order!

We recommend you to use a bash script to runs this changes.
Here a small example:

For this we will suppose that we do have a Server with a Plesk setup so we need Webserver, Mailserver, Plesk, SSH reachable.

Code:
nano /opt/rules.sh

here we will input all the rules we want to set:

Code:
#!/bin/sh

# Flush all rules
sudo iptables -t filter -F
sudo iptables -t filter -X

# Block everything by Policy
sudo iptables -t filter -P INPUT DROP
sudo iptables -t filter -P FORWARD DROP
sudo iptables -t filter -P OUTPUT DROP

# Allow already established connections
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
sudo iptables -t filter -A INPUT -i lo -j ACCEPT
sudo iptables -t filter -A OUTPUT -o lo -j ACCEPT

# Allow SSH connections (CHANGE IN THIS BLOCK THE PORT TO YOUR SSH CONNECTION)
sudo iptables -t filter -A INPUT -p tcp --dport 1923 -j ACCEPT
sudo iptables -t filter -A OUTPUT -p tcp --dport 1923 -j ACCEPT

# Allow Fake SSH connections
sudo iptables -t filter -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -t filter -A OUTPUT -p tcp --dport 22 -j ACCEPT

# Allow DNS requests
sudo iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT
sudo iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT
sudo iptables -t filter -A INPUT -p tcp --dport 53 -j ACCEPT
sudo iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT

# Allow HTTP&HTTPS connections
sudo iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -t filter -A OUTPUT -p tcp --dport 443 -j ACCEPT
sudo iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT

# Allow FTP connections
sudo iptables -t filter -A OUTPUT -p tcp --dport 20:21 -j ACCEPT
sudo iptables -t filter -A INPUT -p tcp --dport 20:21 -j ACCEPT

# Allow Mail SMTP connections
iptables -t filter -A INPUT -p tcp --dport 25 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 25 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 465 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 465 -j ACCEPT

# Allow Mail POP3 connections
iptables -t filter -A INPUT -p tcp --dport 110 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 110 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 995 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 995 -j ACCEPT

# Allow Mail IMAP connections
iptables -t filter -A INPUT -p tcp --dport 143 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 143 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 993 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 993 -j ACCEPT

# Allow Plesk HTTPS and HTTP connections
iptables -t filter -A INPUT -p tcp --dport 8443 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 8880 -j ACCEPT

# Allow NTP (server time)
sudo iptables -t filter -A OUTPUT -p udp --dport 123 -j ACCEPT

# Allow Ping Requests
sudo iptables -t filter -A INPUT -p icmp -j ACCEPT
sudo iptables -t filter -A OUTPUT -p icmp -j ACCEPT

Now then lets use the file:

Code:
cd /opt/
chmod +x rules.sh
./rules.sh

This will make the rules look like:

Code:
# iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:1923
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:https
ACCEPT     tcp  --  anywhere             anywhere             tcp dpts:ftp-data:ftp
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:smtp
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:urd
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:pop3
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:pop3s
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:imap2
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:imaps
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:8443
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:8880
ACCEPT     icmp --  anywhere             anywhere

Chain FORWARD (policy DROP)
target     prot opt source               destination

Chain OUTPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:1923
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:https
ACCEPT     tcp  --  anywhere             anywhere             tcp dpts:ftp-data:ftp
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:smtp
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:urd
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:pop3
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:pop3s
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:imap2
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:imaps
ACCEPT     udp  --  anywhere             anywhere             udp dpt:ntp
ACCEPT     icmp --  anywhere             anywhere

6. Install a fake SSH (optional, this may help against bots and less skilled hackers who may not even try to find the real ssh port).

Check: https://github.com/tylermenezes/FakeSSH there are other options

Code:
apt-get install git
cd /opt/
wget https://bootstrap.pypa.io/get-pip.py
python get-pip.py
pip install paramiko

git clone https://github.com/tylermenezes/FakeSSH.git
ssh-keygen

Save it to /opt/FakeSSH/data/rsa

Code:
cp /opt/FakeSSH/data/config.sample.json /opt/FakeSSH/data/config.json

You can edit /opt/FakeSSH/data/config.json as required

Code:
chmod +x /opt/FakeSSH/server.py
chmod +x /opt/FakeSSH/stats.py
Code:
nano /etc/init/fakessh.conf

Add there:

Code:
# fakessh
description "A fake SSH server"
author "Tyler Menezes <tylermenezes@gmail.com>"
start on runlevel [2345]
stop on runlevel [016]
respawn
exec python /opt/fakessh/server.py

now run the server.py
example:

Code:
cd /opt/FakeSSH/
screen -S "fakeSSH" -d -m ./server.py

Now to check it:

Code:
$ nmap <Your IP or Hostname> -p-

Starting Nmap 7.01 ( https://nmap.org ) at 2018-03-21 10:21 CET
Nmap scan report for <Your IP or Hostname>.serverprofi24.de (<Your IP or Hostname>)
Host is up (0.0074s latency).
Not shown: 65519 closed ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh <--- Fake port
25/tcp open smtp
53/tcp open domain
80/tcp open http
106/tcp open pop3pw
110/tcp open pop3
143/tcp open imap
443/tcp open https
465/tcp open smtps
993/tcp open imaps
995/tcp open pop3s
1923/tcp open unknown <--- Real port
4190/tcp open sieve
8443/tcp open https-alt
8880/tcp open cddbp-alt

Nmap done: 1 IP address (1 host up) scanned in 2.77 seconds

 

Code:
ssh root@<Your IP or Hostname> -p22
hello, welcome to my internet home!
please don't guess my password!
root@<Your IP or Hostname>'s password:
Access denied

As you can see the server does reply and always says that it is a wrong password. So a bot, etc. will think that it’s a real port.

With these steps all done, your Server should be mostly secure.

If you using Plesk it is probably also recommended to check:
https://support.plesk.com/hc/en-us/a…best-practices
Also make sure that your CMS systems etc. are always up to date!

(THIS IS NO GUARANTEE THAT YOUR SERVER WILL BE HACK PROOF BUT IT SHOULD HELP IN MOST CASES)

Ransomware will strike again. Are your customers ready?

Ransomware will strike again. Are your customers ready?

2018 forecast: ransomware will strike again
In 2017, cyber criminals further perfected their ransomware delivery techniques, resulting in Petya, WannaCry and, most recently, BadRabbit wreaking havoc worldwide. And the end is nowhere in sight: security vendors expect that ransomware will hit businesses even harder in 2018. As long as this type of malware remains highly profitable, it will continue to evolve. So, if the threat of ransomware wasn’t on your customers’ radar before, it definitely is (or should be) now.

Ransomware protection is no longer an option, it is a necessity. Become your customers’ hero in times of need by introducing them to Acronis Active Protection™! This smart anti-ransomware feature for Mac and Windows computers enables you to help your customers fight this dangerous threat effectively.

Acronis Active Protection™ proactively exterminates ransomware and restores any damaged data with features including pattern detection, whitelisting and blacklisting, and self-defence of backup files.

Get Your Backup server today.

50% off on any Dedicated Server and VPS server

50% off on any Dedicated Server and VPS server

50% off on any Dedicated Server and VPS server

We’ve added five new references to our catalogue of Dedicated servers with 128 IPs. These new products can be ordered as of now in our Canadian and French data centers. We would also like to take this opportunity to announce the launch of the server series for our new data centres in London, Frankfurt, Warsaw, Sydney and Singapore.

Enjoy the discovery with 50% discount on any dedicated server and VPS server on this Cyber-day.

Promo Code:50-50

Please Note:

  • These offer started on 08:00 IST, 23rd November.
  • Offers are valid on any Dedicated & VPS  Servers only.
  • These discounts are valid until 12:00 IST, 27th November 2017.
  • The cost prices that you see on your control panel have been updated to include this special discount.
  • Any discount that may have been applicable previously on these hosting products will expire unless explicitly mentioned on our website.
  • Additional taxes will be applicable.

Dedicated Server

https://www.arvitaglobal.com/server/dedicated-server-usa-europe/

https://www.arvitaglobal.com/servers/enterprise-dedicated-servers/

https://www.arvitaglobal.com/manage/cart.php?gid=15 (32 IPs)

https://www.arvitaglobal.com/manage/cart.php?gid=35 ( 256 IP)

https://www.arvitaglobal.com/manage/cart.php?gid=38(128 IP)

 


Our VPS service start with 17$ per month

https://www.arvitaglobal.com/server/linux-virtual-private-server-usa-europe/

Windows VPS

Buy SSL

Google Now Penalizing Even More HTTP Websites

Google Now Penalizing Even More HTTP Websites

Dear website Owners,

Are you aware that Google Now Penalizing Even More HTTP Websites?

Starting with the release of Chrome 62, Google will mark any website with an insecure form “Not Secure.”

If you haven’t added SSL to your website, you may want to—an important deadline is coming up, please visit www.mporis.com and order your SSL today. Starting in October with the release of Chrome 62, Google will be marking any website with an insecure form “Not Secure.” This isn’t just a warning for pages with an insecure login/password field, now it’s any field—anywhere a user can input information.

insecurepasswordwarningInsecure Password Warning, Firefox 52

This is keeping with Google’s push for universal encryption. The company has continued to ramp up pressure for websites to add SSL. And Google doesn’t plan to stop at just warning Chrome users about insecure forms, either. Google plans to roll out a warning for all HTTP websites sometime in 2018.

http-websiteHTTP website

So heed this warning, if your website is anything more than a blog or a personal website, you need to encrypt. Whether you’re just collecting an email address as part of a capture strategy or you’ve got a signup form somewhere, you’ll be sorry if you don’t secure it before Chrome 62 drops in October.

“Not Secure” warnings kill conversions

Nothing is going to kill your conversion rate faster than Google placing a “Not Secure” warning in your address bar or drop an interstitial warning when a customer attempts to type in one of your website’s fields.

And it’s not just Google, the other browsers are also adopting similar policies with regard to encryption and insecure websites.

Think about it, people tend to trust their browsers. When one of them tells a user that he or she is not safe on a website, the vast majority of people are going to leave. Nobody is sitting at their computer saying, “this seems like a worthwhile risk to take.”

So remember, if your website has any forms on it—install SSL. Waiting until Google flags your website is playing with fire. It’s time to add SSL on your portal,.

We have various SSL products and starting price from $15(1000/-INR) per year.

Visit: www.arvitaglobal.com
Contact : sales@arvitaglobal.com