Workshops and Networking for Plesk Team at CodeFest 11

CodeFest Plesk blog header

This spring, kicking off a new season of live, Covid-compliant events, one of the most well-known Russian IT conferences took place in the Siberian city of Novosibirsk. CodeFest, held annually in the city, welcomed thousands of participants online and offline, including a Plesk team of 26 people!

Over the duration of the IT focused event, the Plesk team gave one presentation, ran three workshops, and even organized a Digital Detox for all the conference attendees. Let’s take a look at how it went!

Plesk Presents…

Pavel Vasilevich, Team Lead in the Russian office of Plesk, gave a presentation at CodeFest 11 on how to collect security information using various DevSecOps tools. As the topic of security is extensive, in the report Pavel highlighted those areas where the use of tools is especially relevant. This included vulnerabilities and sensitive data in the code, infrastructure and network, and cloud security.

Combining this data, Pavel sought to answer the question: how do you combine data from different sources, work with them centrally?

CodeFest speaker Pavel Vasilevich Plesk

“The topic of security is not covered very often at CodeFest, so it was an experiment for me. I tried to make the report as interesting as possible for developers, testers, DevOps, tried to show that it is possible to deal with security issues at all stages of the development cycle and why it matters.”


Pavel Vasilevich, Team Lead at Plesk

Inspiring Workshops

Also during the two days of the CodeFest event, Plesk organized a series of workshops to inspire the attending IT professionals.

Plesk team member Denis Gorbatykh led an interactive workshop based on the question, ‘How do you plan for big tasks without losing control?’ The discussion involved 40 active participants, and ended up accumulating the experiences of many specialists to find the answers!

In a separate workshop, Plesk speakers Alexey Vokhmyanin, Olga Perevozkina and Oleg Neumyvakin presented on the topic of hyper-responsibility.

In the discussion with attendees, they shared twenty scenarios and discussed distribution of responsibilities, diagnosing and understanding when workloads are overwhelming, and the harmful effects of hyper-responsiveness. It was a great chance for attendees to rethink and share valuable experiences, and was a great success!

Digital Detox

Specially for the event, the Plesk team provided a lounge zone based on the theme “Digital Detox”. The space had no screens, no computers, no internet connection; instead, Plesk freed attendees from devices by providing the opportunity to chat, play board games, and play musical instruments. There was even a huge lego board that attendees were welcomed to add their creations to!

Such an atmosphere was perfect for networking and relaxation. The main topics of discussions in this detox zone were personal and friendly, or discussing corporate culture.

Here is some feedback from participants in the Digital Detox:

  • “[Plesk] always have so many people and everything is very emotional”.
  • “Plesk keeps its brand. No one communicates at conferences as they do”.
  • “It is clear that everything is not just a pretense for the sake of the conference. You truly live like this.”

The ‘playground’ turned out to be a very warm and quirky place, and the friendly atmosphere charged everyone with positive emotions for a long time.

Here at Plesk, we are looking forward to the next opportunity to be a part of such a big IT event! Did you make it to CodeFest? What would you like to see at your next IT conference? Let us know below!

New WordPress Hosting Team Reps with Plesk’s Lucas Radke

WordPress hosting reps Plesk blog

WordPress is a tool used by millions daily, but most of us don’t know what happens behind the scenes. In order to provide the very best solutions in record time, one of WordPress’ innovative methods is through supporting an open source software project, managed entirely by the WordPress community.

So what does this open source project do?

Using the highly diverse global community of WordPress experts, the project enlists teams for broader projects such as Hosting, Plugins, Community and Mobile. These experts work on code, support the WordPress community, produce documentation, review new plugins and themes, and much more. These teams then vote on Team Reps to represent the team, speak on behalf of the other team members and help new volunteers to get started.

These Team Reps become active contributors of their area of expertise, delegating leadership roles and coordinating with other teams and projects. They are also responsible for providing reporting on the progress of their projects and keeping the team up to date.

Managing this type of network is complex and requires a great deal of skill, WordPress knowledge and expertise. Which is why we are proud to announce that the 2021 list of Team Reps includes one of Plesk’s own!

Lucas Radke WordPress hosting rep Plesk blog

2021 Hosting Team Reps

Among the elected Team Reps for this year is Lucas Radke, Product Manager at Plesk for the past three and a half years. With his extensive understanding and expertise with WordPress and its tools, as well as the experience he has gained from using his skills building Plesk’s hosting management platform, Lucas will be representing the Hosting team members of the open source project.

This shows huge trust and confidence from the hosting team who voted him in, and is a huge achievement for Lucas who has worked for many years as a contributor to the team. We offer huge congratulations to Lucas, as we speak to him in this short interview:


A word with the new Hosting Team Rep


Congratulations on your new position Lucas! How are you taking the news?

It’s a pleasure for me to represent the whole members of the WordPress Hosting team and I’m super thankful for everyone giving me the trust.

Have you worked with the WordPress community project before?

A few years ago during a contributor day I had my first experience with contributing towards the hosting team and starting then, I attended the weekly hosting meeting regularly. After a few months I also started to lead the meeting.

Have you already got started with your Team Rep duties?

I have, but nothing much has changed as I was already deeply involved in the team and its work. Anyone interested is invited to check out and join our weekly meetings!


What else is coming up for the WordPress community project? Take a look here, and please join us in congratulating him in the comments!

Migration to Plesk from Other Hosting Platforms

How to migrate your services to a server managed by Plesk Panel - Plesk

Nowadays, a server operating system might host some of the following services:

  • Web service and associated applications used by websites
  • Mail service
  • Database services
  • DNS service

Often there’s also an installed control panel software that helps to facilitate the deployment and management of these services. So migration of the data and services from one server to another one is, in this case, the process of transfer of the hosting control panel data and content (such as websites, mail, databases, DNS zones) to the new server.

Disadvantages of Manual Backup/Restore

Disadvantages of manual backup / restore - server migration to Plesk

Generally, the migration procedure backs up some data on the old server. Then, transfers the backup file to the new server and restores it there. For such a complex environment, the transfer of data to another server isn’t the easiest option. You can, of course, move all the data piece by piece using the native backup/restore tools for each server component and file copy. However, it often takes an unreasonable amount of work-time and manual operations.

The other disadvantage is that it’s not possible to make a seamless transition if the services on the old server are active. Some data will be lost in transfer staying on the old server or some services will be down during the transfer.

Migration to a Server with Plesk

Let’s now suppose you have Plesk Obsidian on the new server. In this case, it will be easier to transfer all the data (web/mail/databases/DNS/Control Panel data). Because Plesk provides a special tool, the Plesk Migrator Extension, which automates the process.

This is the migration tool that Plesk provides for migration to the latest, recommended Plesk Obsidian versions. You install it via Plesk Panel like any other Plesk Extension and it has a handy user interface too.

There can be different reasons for migrating services and/or data from one server to another. Let’s go through the typical server migration scenarios and see how Plesk makes the whole process simple.

Moving your services to the Cloud with Plesk and our hyperscaler partners

Migration from another control panel/hosting environment to Plesk

Migration to the new Plesk and Operating System versions

Moving Your Services to the Cloud with Plesk

Moving your services to the Cloud - Server migration to Plesk

It’s become popular to move onto cloud services and scale your business. You can easily install Plesk on the most-loved cloud platforms, like:

And once you install Plesk, you can migrate to the cloud instance with Plesk from anywhere, in a standard way.

There will practically be no difference as it doesnt depend on where Plesk is installed (cloud instance, virtual container/ machine or a physical server). You always migrate to Plesk using the Plesk Migrator Extension (this is the number one tool for Plesk migration).

Migration From Another Hosting Panel/Hosting Environment to Plesk

Migration from another control panel/hosting environment to Plesk - server migration

If you have any control panel you would like to leave for Plesk – check out our list of supported hosting panels.

  • Specific versions of Plesk for Windows and Linux: 8.6, 9.5, 10.4, 11.0, 11.5, 12.0, 12.5, 17.0, 17.5, 17.8.
  • cPanel 11.5
  • Helm 3.2
  • Confixx 3.3
  • Parallels Pro Control Panel for Linux 10.3.6
  • Plesk Expand 2.3.2
  • DirectAdmin 1.51 (just custom migration is supported when you switch from DirectAdmin installed on Ubuntu 10.x)

These objects, settings, and data will be transferred during migration:

Plesk Migrator moves the following: service plans, websites featuring content (e.g. mail, files), and subscriptions with related domains for your convenience. In the case of customer and reseller accounts without domains, these won’t be migrated.

Additionally, Plesk service settings will not be transferred. These include Fail2Ban settings, firewall configurations, and installed PHP handlers.

How to Install Plesk Migrator

You can complete Plesk Migrator’s installation via Plesk’s interface. Here’s how:

  • Log in to Plesk as the administrator, on the destination server
  • Navigate to Tools & Settings, go to Updates & Upgrades, then Add/Remove Components
  • Hit Install beside the Plesk Migrator component

Prefer to process the Plesk Migrator’s installation with a command line instead?

  • In Linux, you can sign in to the destination server through SSH as the root user, or in Windows through RDP as the administrator user

Follow these steps:

  • On Linux, run this command: plesk installer
  • On Windows, go to the command prompt and run "%plesk_bin%\ai.exe" --console.
  • Continue with the installation wizard, and follow the directions provided until you’re invited to choose components
  • Pick the “Plesk Migrator” component to be installed and run through the rest of the procedure, following the instructions as they appear on-screen

What if none of the supported hosting platforms are installed on the source server? You can migrate from a server running an unsupported hosting platform (or none at all) with custom migration.

With custom migration, you’ll create a hosting description file written in JSON or YAML and detail the objects to be migrated (such as mailboxes, domains, etc.). You can perform custom migration even if you lack administrative access to the source server.

How to Migrate from a Linux Server with Custom Hosting

This topic covers migration to a Linux server running a control panel that isn’t one of the supported source platforms, or one with hosting but without a control panel. These scenarios are supported:

  • Migrating from a server with custom hosting (with administrative access): This situation requires you to create a hosting description file including a list of subscriptions, clients, mailboxes, etc. and defines where mail and web content data can be found on the source server. The file’s format is readable by humans and covers the majority of popular hosting services. It could be in JSON or YAML.
  • Migrating from a server with custom hosting (without administrative access): In this scenario, it’s presumed that you’ll manually transfer database dumps and web content data from the destination server to the source one. You’ll need to make a hosting description file, but it will specify where database dumps and web content data will be located on the destination server.

Please be aware that you can only use the command line to migrate from servers with custom hosting, rather than the Plesk interface.

Follow these directions if you have administrative access to the server:

  • Log in to the destination Plesk server through SSH.
  • Ensure that Plesk Migrator has been installed. If it hasn’t, follow these instructions to install it.
  • Set up the hosting description file, and name it hosting-description.[yaml/json] (depending on the selected format). Place it in the /usr/local/psa/admin/sbin/modules/panel-migrator The file should include the list of clients, mailboxes, subscriptions, etc. set to be migrated from the source server. Sample hosting description files are available here.
  • Make a directory titled conf in the /usr/local/psa/var/modules/panel-migrator/ Set up the migrator tool configuration file, name it config.ini, and put it in the /usr/local/psa/var/modules/panel-migrator/conf/ directory. The file needs to include the source server’s configuration and access information. Check the sample configuration file here to learn more.
  • Run this command to create the migration list: /usr/local/psa/admin/sbin/modules/panel-migrator/plesk-migrator generate-migration-list

The name of the resulting file will be migration-list. It will be located in the /usr/local/psa/var/modules/panel-migrator/sessions// directory. The migration list comprises numerous objects that will be migrated, including service plans, customer/reseller accounts, etc.

  • Make changes to the migration list: you can take out domains you don’t want to be included in the migration, assign domains you intend to migrate to service plans, or re-assign them to different customer accounts.
  • This step is optional: running the command below to validate the hosting description file: /usr/local/psa/admin/sbin/modules/panel-migrator/plesk-migrator validate

You can learn more about validating a hosting description file in this guide.

  • To start the migration, run this command: /usr/local/psa/admin/sbin/modules/panel-migrator/plesk-migrator transfer-accounts
  • This step is optional: run the following command to undertake another content sync: /usr/local/psa/admin/sbin/modules/panel-migrator/plesk-migrator copy-content

This ensures that changes to hosting content that could have taken place on the source server during the migration will be replicated on the destination server. You can use the following commands to re-sync certain content types only: plesk-migrator copy-web-content, plesk-migrator copy-mail-content, or plesk-migrator copy-db-content.

  • It’s recommended that you run this command when the migration is complete, to check the operability of objects migrated to the destination server: /usr/local/psa/admin/sbin/modules/panel-migrator/plesk-migrator test-all

A report will be generated by the post-migration check. It will be saved to a file called test-all-report. in the /usr/local/psa/var/modules/panel-migrator/sessions// directory.

Customer accounts, services, and subscriptions are presented in the report in a tree structure. Each unsuccessful post-migration test will result in an entry being written in the log. This includes information on the failure and steps for verification and resolution.

You can get a deeper insight into all the post-migration checks in this guide.

What can you do if you don’t have administrative access to the server? These directions will help:

  • Use SSH to sign in to the destination Plesk server.
  • Check that Plesk Migrator has been installed.
  • Manually copy the mail and web content data from the source to the destination server. With web content, you’ll need to copy the document root directories of any domain you intend to migrate. This should include all included files and subdirectories. You can place the content in any location on the destination server.
  • Create dumps of any databases that belong to the sites you plan to transfer. Next, manually copy them to the destination server.
  • Get the hosting description file ready. You should title the file hosting-description.[yaml/json] (depending on the format you choose) and put it in the /usr/local/psa/admin/sbin/modules/panel-migrator The file should include the list of clients, addon domains, subscriptions, mailboxes, etc. that will be transferred from the source server. Sample hosting description files are available here.
  • Get the migrator tool configuration file ready. Title the file ini and put it in the /usr/local/psa/admin/sbin/modules/panel-migrator directory. This file needs to feature the source server’s access and configuration information. For reference, you can use this sample configuration file.
  • Run this command to create the migration list: /usr/local/psa/admin/sbin/modules/panel-migrator/plesk-migrator generate-migration-list

The resulting file will be titled migration-list and located in the /usr/local/psa/var/modules/panel-migrator/sessions// directory. Inside the migration list, you’ll find a list of the objects to be transferred, such as service plans, domains, etc.

  • Make changes to the migration list. You can take out those domains you’d rather not migrate, assign domains you plan to migrate to service plans, or re-assign them to various customer accounts.
  • This step is optional: use this command to validate the hosting description file: /usr/local/psa/admin/sbin/modules/panel-migrator/plesk-migrator validate

To find more detailed information on hosting description file validation, click here.

  • To start the migration, run this command:/usr/local/psa/admin/sbin/modules/panel-migrator/plesk-migrator transfer-accounts

How to Migrate from a Windows Server with Custom Hosting

In this topic, we’ll explore how to migrate from a Windows server that runs a control panel that isn’t one of the supported source platforms, or one with hosting but without a control panel. These situations are supported:

  • Migrating from a server with custom hosting (with administrative access): This situation involves generating a hosting description file. It features the mailboxes, addon domains, subscriptions, etc. It also shows where web and mail content data can be found on the source server. This file is human-readable, written in JSON or YAML, and covers the majority of well-known hosting services.
  • Migrating from a server with custom hosting (without administrative access): In this situation, the assumption is that you will transfer content data and database dumps from the source to the destination server. A hosting description file will be generated. It should identify where web content data and database dumps can be found on the destination server.

Please be aware, though, that you can only migrate from servers with custom hosting with the command line. You can’t do it using the Plesk interface.

The following directions apply if you have administrative access to the server:

  • Use RDP to sign in to the destination Plesk server
  • Check that Plesk Migrator has been installed
  • Get the hosting description file ready, and (depending on the format) name it hosting-description.[yaml/json]. You should put this in the %plesk_dir%admin\plib\modules\panel-migrator\backend Inside the file should be a list of addon domains, subscriptions, clients, etc. that will be migrated from the source server. Sample hosting description files are available here.
  • Make a directory titled conf in the %plesk_dir%var\modules\panel-migrator Get the migrator tool configuration file ready and name it config.ini. You should put it in the %plesk_dir%var\modules\panel-migrator\conf directory. This should include the configuration and access information for the source server. For reference, you can find the sample configuration file here.
  • Run this command to create the migration list: %plesk_dir%admin\plib\modules\panel-migrator\backend\plesk-migrator.bat generate-migration-list

The resulting file will be called migration-list. It will be located in the %plesk_dir%admin\plib\modules\panel-migrator\backend\ directory. The migration list includes numerous objects to be included in the migration, such as service plans, customer and reseller accounts, etc.

  • Make changes to the migration list. You can take out the domains you don’t want to be transferred, assign domains to be migrated to service plans, or re-assign them to different customer accounts.
  • This step is optional: run the following command to validate the hosting description file: %plesk_dir%admin\plib\modules\panel-migrator\backend\plesk-migrator.bat validate

More information on hosting description file validation is available here.

  • To start the migration, run this command: %plesk_dir%admin\plib\modules\panel-migrator\backend\plesk-migrator.bat transfer-accounts
  • This step is optional: Run an extra content sync with this command: %plesk_dir%admin\plib\modules\panel-migrator\backend\plesk-migrator.bat copy-content

This ensures that any changes to hosting content that could have occurred on the source server during migration are replicated on the destination server. Use one of these commands to re-sync certain content types only:  plesk-migrator.bat copy-web-content, plesk-migrator.bat copy-mail-content, or plesk-migrator.bat copy-db-content.

  • You’re advised to take this step: once the migration has ended, you can check the operability of the objects transferred to the destination server with this command: %plesk_dir%admin\plib\modules\panel-migrator\backend\plesk-migrator.bat test-all

This check will generate a report. It will be saved to a file titled test-all-report. in the \var\modules\panel-migrator\sessions\\ directory. You can find where is located on your server by opening the command prompt and running this command:

reg query "HKLM\SOFTWARE\Plesk\PSA Config\Config" /v PRODUCT_DATA_D /reg:32

The report’s tree structure represents a hierarchy of subscriptions, services, and customer accounts. For each failed post-migration test, an entry will be added to the log. This will feature details about the failure and what you can do to verify or resolve the possible problem.

You can find details on all post-migration checks here.

Take these steps if you don’t have administrative access to the server:

  • Use RDP to sign in to the destination server.
  • Ensure that Plesk Migrator has been installed. If not, follow these directions to install it.
  • Copy the web and mail content data from the source to the destination server manually. In the case of web content, copy the document root directories of those domains you intend to transfer. This should contain all included files and subdirectories too. The content can be placed in any location on the destination server.
  • Generate dumps of all databases that belong to the sites you want to include in migration. Copy them to the destination server manually.
  • Get the hosting description file ready and title it hosting-description.[yaml/json] (depending on the format). This should be put in the %plesk_dir%admin\plib\modules\panel-migrator\backend This should include a list of mailboxes, subscriptions, client list, etc that will be transferred from the source server. Sample hosting description files are available here.
  • Get the migrator tool configuration file ready and name it ini. Put it in the  %plesk_dir%admin\plib\modules\panel-migrator\backend directory. This file should contain the access and configuration information for the source server. For reference, you can check the sample configuration file here.
  • Run the command below to create the migration list:%plesk_dir%admin\plib\modules\panel-migrator\backend\plesk-migrator.bat generate-migration-list

The name of the file created will be migration-list. It will be located in the %plesk_dir%admin\plib\modules\panel-migrator\backend\ directory. On the migration list, you’ll find the list of objects to be migrated. These are service plans, reseller and customer accounts, etc.

  • Change the migration list: you can take out domains you don’t want to include in the migration, assign domains you want to transfer to service plans, or re-assign them to different customer accounts.
  • This step is optional: run this command to validate the hosting description file: %plesk_dir%admin\plib\modules\panel-migrator\backend\plesk-migrator.bat validate

More information on validating hosting description files is available here.

  • Run this command to start the migration: %plesk_dir%admin\plib\modules\panel-migrator\backend\plesk-migrator.bat transfer-accounts

Migration to the New Plesk and Operating System Versions

Migration to the New Plesk and OS systems - Server Migration to Plesk

Another common reason to migrate to a server managed by Plesk is to update the old Plesk version and/or Operating System. Please check the Plesk EOL policy. We recommend that you migrate to the latest Plesk version (Plesk Obsidian) on a supported operating system.

You can check what upgrade/migration options are available for your OS/Plesk version in the Migration Process Guide.

More Common Migration Scenarios

  • Joining and migrating services from several Plesk servers, one by one, to a new, bigger, more powerful server.
  • Migrate part of Plesk subscriptions to a new server.
  • Shift to the Plesk Multi-Server product.
  • Moving data to a server in another datacenter.
  • Switch to a server with upgraded hardware.
  • Transfer from a physical server to a VM/container.

In any case, the Plesk migration process is the same – you always migrate to Plesk using the Plesk Migrator Extension on the target Plesk server.

Common Questions Around Migration to Plesk

Common questions around server migration to Plesk

Usually, when the migration planning has started, the following questions appear.

  1. What should I configure/check/install on both servers?
  2. Are there any ports that need to be opened on the servers?
  3. Will be there any services downtime during migration?
  4. How do you sync outdated data on the old server during migration?
  5. How much disc space do both servers need for migration?
  6. Is it possible to keep IP address of the old server instead of changing the domains’ DNS records?

You can find the answers and more details about the migration process in the Migration Process Guide document.

In most cases, Plesk migrator will warn you about the problems which need to be solved when it does automated pre-checks. Also, it will warn about problems when it does automated post-checks on migrated objects. Based on the warnings you can always do required corrections and repeat the migration of the problem customers/mailboxes/websites/databases any time.

Typical Plesk Migration Steps

Typical Plesk server migration steps

A short overview of the migration steps (more in detail in the Migration Process Guide)

For steps 1 and 2:

  • Install Plesk on the destination server.
  • Install all 3rd party components/software that your services use on the source server.
  • Make sure to install all products licenses.
  • If you plan to migrate databases, make sure that you install and register database servers on the Plesk Panel. Do this in the destination server of the same or higher version than the source server.
  • Install all available PHP versions via Plesk Panel installer on the destination server.
  • For Windows – Install the latest .NET framework version on the server.
  • Then, you can just install the Plesk Migrator Extension on Plesk Panel in the destination server.
  • Start the migration to Plesk from there.
  • Follow the hints of the automated pre-check/post-check procedures.

For step 3 and 4:

This will not interrupt your services on the source server. It will merely copy data from the source server and will validate them on the destination server. It will warn you if something is missing or if you need to configure something.

When you are satisfied with the migration result, you can sync data in step 6 from the source server to update it and switch domains’ DNS (or move IP addresses) to complete the migration in step 7.

Podcast | Understanding Security and its Importance in eCommerce

Podcast eCommerce security Plesk blog

Another month, another episode of the Official Plesk Podcast: Next Level Ops! In this episode, we have Chris Teitzel, the Founder of Chris is a cybersecurity expert, and we’re going to get pretty deep on the importance of security when it comes to your eCommerce store, and how you can reduce liability while focusing on what you do best: running your business.

Plesk podcast Chris Tietzel Lockr

In This Episode: Security, SSL, and PCI Compliance

Chris has quite a résumé. On top of running a cybersecurity agency, offering a product that touts some of the highest-level security available, and teaching people about how to secure their websites, he also sits on the Data Privacy and Integrity Advisory Committee (DPIAC) for the Department of Homeland Security.
As Chris mentions in the episode, every decision they make there, which affects privacy and security for larger organizations, trickles down to small businesses:

All of the policies and all of the procedures and everything that we talk about at scale apply to even the smallest companies. But the hardest part about being a small online retailer is that you don’t have the bandwidth to go and do that.

So while those large organizations have the money and team to implement these regulations and mitigate liability, most of us don’t. What can we do? Luckily, there are a lot of great tools out there to help small business owners do the same thing without the mounds of money. 

The first is using an established payment gateway like Stripe and Square to accept payment processing. You don’t need to become a merchant and accept the legal liability of taking credit cards any more. Within a few minutes, you can set up a Stripe account and be ready to go.

The second is SSL certificates through Let’s Encrypt. If you’re accepting payments, you need to use https, and that requires an SSL certificate (or more accurately, as we discuss in the episode, a TLS certificate). With Let’s Encrypt you can get a free certificate that is just as good as the paid ones, as far as security goes.

These 2 services will allow you to accept payments online without the need for millions of dollars to be compliant.

Key Takeaways

  • SSL stands for Secure Socket Layer, and it allows you to send secure data over the internet. As Chris puts it, “[SSL] allows 2 parties to connect and talk over a secure pipeline,” which establishes, “trust in an untrusted environment.”
  • SSL certificates protect from “Man in the Middle” attacks – basically a bad actor attempts to intercept data as it’s sent from a computer to your website.
  • Let’s Encrypt is quickly becoming the go-to for many people to implement SSL on their site. It’s free and offered by most hosting companies, meaning no website has an excuse not to use it.
  • Using managed hosting for your WordPress or WooCommerce site also helps keep your site secure. This allows you to focus on what you do best, because that’s where you’ll make money.
  • Anyone accepting credit cards needs to be PCI Compliant. This is a global standard set by the major Credit Card companies to ensure data security when processing credit card transactions. Luckily today, we have Stripe and Square, who accept the compliance and liability that goes with it.

The Official Plesk Podcast: Next Level Ops Featuring

Joe Casabona

Joe is a college-accredited course developer and podcast consultant. You can find him at

Chris Teitzel

Chris is the Founder of

Did you know we’re also on Spotify and Apple Podcasts? In fact, you can find us pretty much anywhere you get your daily dose of podcasts. As always, remember to update your daily podcast playlist with Next Level Ops. And stay on the lookout for our next episode!

IP Addresses Management under Plesk

Manage IPs Plesk blog

Plesk is a user-friendly hosting platform designed to help streamline web hosting and server data center automation. It was was developed for providers of Windows and Linux-based commercial hosting services. The Plesk user management model accommodates both shared and dedicated hosting.

Server administrators can utilize Plesk to configure new sites, email infrastructure, and reseller accounts. They can also create and edit DNS entries via Plesk’s interface. Some of the most important solutions Plesk offers include management and automation of domain names, web apps, email accounts, databases and other tasks. Its ready-to-code environment offers effective security, encompassing numerous operating systems and layers.

Below, we’ll explore how Plesk IP address management works.

Plesk allows you to view, add to, and manage the list of registered IP addresses. Each one registered in Plesk needs to be designated as “dedicated” or “shared”.

What does this mean?

  • “Dedicated” IP addresses are restricted to one account, such as Customer, Plesk Administrator, or Reseller. They can be utilized to host a number of sites if they share an account.
  • “Shared” IP addresses may be shared across multiple websites, even if they don’t belong to the same account.

You can expect the following benefits if you designate your IP address as “dedicated”:

  • You’ll be able to host FTP shares that can be accessed anonymously without password authentication
  • You can reduce IP address reputation damage to websites hosted on it in certain negative situations, such as if a site sends spammy emails
  • You’ll be able to secure websites with an SSL/TLS certification if SNI is unavailable. SNI allows you to implement SSL/TLS to protect sites sharing IP addresses. This may not work for every server and browser, though. You can find more on this topic in this guide to SSL/TLS and shared IPs.

Please be aware, though, that you’ll need to have a shared IP address (or one unassigned IP address) on the server before you can create a subscription and host sites.

Here you may find more information regarding various routine tasks related to IP addresses management:

How to View Lists of Registered IP Addresses

If you want to look at a list of IP addresses registered in Plesk, and their key details (e.g. IP address type, number of hosted websites on a specific IP address), go to Tools & Settings > IP Addresses.

To search for IP addresses, use the search menu. You can open this by tapping the arrow button located on the screen’s right-hand side.

How to Add IP Addresses

You can add IP addresses by following these steps:

  • Navigate to Tools & Settings > IP Addresses
  • Hit the Add IP Address button

IP addresses can only be added on the Virtuozzo hardware node when you run Plesk in a Virtuozzo container. The option to add IP address will not be visible.

When using Plesk in a Virtuozzo container, you can find out more about adding IP addresses in Virtuozzo’s online resources. Re-read IP addresses when you have finished adding the IP addresses you want to include.

If you’re running Plesk for Windows, you can’t add IP addresses to, or take them out of, a network interface when DHCP is activated. Disable DHCP for a given network interface if you want to add or remove an IP address.

  • Go to the Interface menu and choose the IP’s network interface
  • Type the IP address and subnet mask into the relevant field
  • This step is for Plesk servers behind NAT: Set the Public IP address. When you want to add a private IP address you intend for hosting public-facing sites, you can combine it with a public IP address by entering it into the Set the Public IP address box. This will be utilized in A records of this IP’s hosted domains.
  • Choose if you want to make the new IP address dedicated or shared
  • Pick the default SSL/TLS certificate to be used for the new IP address. Every IP address will remain secure courtesy of the default (self-signed) certificate. You can find out more about this in the Securing Connections with SSL/TLS Certificates guide.
  • If using Plesk for Windows, you’ll need to pick an FTPS usage policy too.

The FTP server installed on your Plesk server should support FTP over SSL/TLS if you want to enable secure FTP connections. For instance, Serv-U FTP and Gene6 servers offer the correct support.

Hit OK to add the new IP address.

How to Complete the IP Address List Updating Process

The IP addresses list in Plesk can be updated to register every address on the server’s network interfaces. This may prove beneficial in certain situations, such as:

  • You’re running Plesk in a Virtuozzo container and add an IP address through the hardware node
  • You’re manually adding an IP address on the server

In either of these scenarios, you’ll need to update the IP addresses list before you’re able to assign them to subscriptions.

You can update the list of IP addresses by:

  1. Going to Tools & Settings > IP Addresses
  2. Clicking Reread IP

How to Hide IP Addresses

Any IP address registered in Plesk may be hidden, so they don’t show in Tools & Settings > IP Addresses. They will be unavailable for assignments.

For example, you might choose to hide private IP addresses on the server to prevent them from being assigned to a subscription accidentally.

Please be aware, though, that hiding IP addresses that have been assigned to a subscription (or multiple) will lead to a specific error: “the IP address is already used for hosting”.

As a result, the relevant IP addresses will be labeled as “blacklisted” in Tools & Settings > IP Addresses, though they’ll be available to be assigned.

You can hide IP addresses by:

  1. Editing the panel.ini file and adding these lines:


blacklist=”<IP addresses to be hidden>”

The <IP addresses to be hidden> will be a list of IP addresses to be hidden. You may hide IPv4 and IPv6 IP addresses.

Log in to Plesk and navigate to Tools & Settings > IP Addresses. Next, click Reread IP.

How to Unhide IP Addresses

Changed your mind about hiding certain IP addresses? You can unhide them, remove them from the panel.ini file, and Reread IP.

How to Assign the Default Website for an IP Address

The default website for an address will be the first site hosted on it. But if more than one website is hosted on a single IP address, the default website will be returned when the IP address is used for browsing rather than a domain name.

For instance, you may host your website and various others on a single IP address. You might want visitors to view your own site when they browse the IP address, and you can make this happen by selecting your own website as the default.

Here’s how to pick the default site:

  1. Head to Tools & Settings > IP Addresses
  2. Click on the right IP address
  3. Choose the website you want to make the default from the Default site menu
  4. Click the OK button


Using Remote Git Hosting with Plesk

Git hosting Plesk blog header

Introducing Plesk

Plesk is web hosting and data center automation software. It has a hosting control panel designed for providers of Windows- and Linux-based retail hosting services.

The Plesk user management model accommodates dedicated and shared hosting. Server administrators can set up new sites and reseller accounts. They can also edit and create DNS entries via an online interface.

Plesk’s main features include automation and management of: domain names; web applications; email accounts; databases and infrastructure tasks to deliver a ready-to-code environment and cutting-edge security on all operating systems and layers.

Introducing Git

Git is the most widely used version control system. It tracks any adjustments made to files, giving you a detailed record of edits. You’re free to restore previous versions as required.

Collaboration is also simpler: changes made by several users can be combined into a single source.

Git could work well for you, whether you write code for your own use or you operate within a team. It runs locally, while your files and their respective histories remain on your computer. You can take advantage of web-based hosts (e.g. Bitbucket or GitHub) if you want to store a copy of files and revision histories online too.

You’ll find collaborating with developers easier when you have a centrally located space for uploading and downloading changes. Git can combine these changes automatically, allowing two users to focus on separate areas in the same file, without losing their respective work.

How Do Plesk and Git Work Together?

Plesk can be integrated with Git (the most commonly used source code management system for developers) easily. Git repositories can be managed and sites can be deployed from them to specific public directories. It can be a valuable transport for initial publishing and future updates.

Please be aware, though, that this feature isn’t supported in Plesk installations that run on Windows Server 2008.

Take these steps if you want to start working with Git:

  1. Install the Git extension in Plesk
  2. Make a domain in Plesk with a service plan that enables the Git management permission.

You can add two kinds of Git repositories in Plesk. Your choice will vary depending on the situation:

  1. Leveraging a local repository on your workstation. In this scenario, you would transfer the edits to Plesk from your local repository. Plesk would then deploy those adjustments to your site. You can find more in this guide to using local repositories.
  2. Leveraging remote Git hosting. This situation may apply if you work with a remote repository in BitBucket or GitHub already. You would transfer the edits to the remote repository, and Plesk would take them from the remote repository. They would then be deployed to your site. You can find more in this guide covering remote Git hosting.

After you enable Git repositories in your domain, you’ll see a list of created repositories on the domain’s page. The name, current branch, and deployment path for each repository will be included.

The Deploy button close to the repository name enables you to deploy files from a repository (when manual deployment is set up). You can hit the Pull Updates button if you want to gather changes from the remote repository.

How to Use Remote Git Hosting

This may apply if you work with a remote repository in GitHub or BitBucket already.

You would transfer the changes to this remote repository. Plesk would take them and deploy them to your site.

How to Clone a Git Repository

You can clone a remote repository to make a Git repository. Make your way to Websites & Domains, then hit Git. You can click the Add Repository button if you’ve made Git repositories for your domain already. You’ll be presented with a screen for making a new repository.

The first thing to do is pick the location in which your code will be stored. In this case, pick Remote Git hosting like GitHub or BitBucket.

Remote Git repository. Input the path to your remote repository in GitHub or BitBucket (in SSH or HTTPS). There’s no support for HTTP/HTTPS authentication, so you can only use HTTP/HTTPS protocol if a repository doesn’t need to be verified.

If you use a private Git repository, you need to verify with an SSH key created by Plesk. You can check out this guide to using SSH connection for more.

Define the following in the Your Website section:

  • The deployment mode: Automatic deployment is used by default. With this enabled, changes pushed to the Git repository are deployed to the production site automatically. If you want to adjust the deployment mode, hit the automatically deployed link and pick another option in the Deployment Mode window that is opened. If you have chosen Manual deployment, you should deploy files from the Git repository to your hosting manually. When you opt for No deployment, the files won’t be deployed to the production site. You can use this for storing and exchanging code, among other things.
  • A target directory for the publication of Git files on your website. The /httpdocs directory will be utilized instead, though you can switch it to a different existing directory by clicking on the name of the intended directory.

Click OK and Plesk will attempt to clone the remote repository after connecting to it. Once the progress dialog reveals that the cloning has been successful, the new repository will be shown on the Git page.

The new repository will be presented at Websites & Domains > Git. The remote repository’s name will be utilized as a Git repository name, though you can change its name at a later date. To find out more, visit the section dedicated to renaming or removing a repository.

The repository that has been created will be a clone of the remote repository, and can be leveraged to gather changes from it before they’re deployed to the target directory.

How to Use SSH Connection

You can connect to the remote Git repository with SSH. In this situation, when you add a new repository, define the URL of the remote repository in the SSH format. The SSH public key box will be displayed, as will the SSH public key Plesk has generated automatically.

Before you click the OK button, you should add the SSH key to the remote Git’s repository settings. Look at the documentation covering how to add an SSH key for GitHub and BitBucket.

How to Pull and Deploy Files

Once you commit your site files and send them to the remote repository, you should go to Websites & Domains. Next, hit the Pull Updates button positioned beside the repository name. The cloned Git repository will retrieve the changes from the remote repository.

The most recent commit information is available at Websites & Domain > Git.

Plesk utilizes the Automatic deployment mode as standard. After a file has been sent to the repository, it will be deployed to the target directory straight away. You can turn this mode off if you need to.

How to Adjust Branch or Path

Deployment from a new branch

It’s normal to work with multiple branches in a single repository, and just one branch may be active at any time. The master branch will be utilized for deployment as standard.

If you want to add a new branch, you have to make it in your remote repository before you start pulling the changes.

Next, choose any number of active branches in Plesk. Navigate to Websites & Domains > Git, and then hit Change branch and path. Pick the branch name in the Branch menu in the opened window.

When you’ve selected a new branch, hit OK and Plesk will show the new active branch.

Changing the deployment path

The /httpdocs directory is utilized to publish Git files on your site by default. To adjust the path of deployment, go to Websites & Domains > Git. Next, click on the Change branch and path link. Choose the new directory in the opened window.

How to Choose a Deploy Mode

You can pick a deploy mode for your repository easily. Navigate to Websites & Domains > Git. Hit Repository Settings and choose one of the following options at Select deploy mode:

  • Automatic deployment: Pick this option if you’d rather all changes were deployed to the production site straight away.
  • Manual deployment: Files will need to be deployed manually. To do so, hit the Deploy from Repository button at Websites & Domains > Git. Files can be deployed manually by clicking on the Deploy button beside the repository name at Websites & Domains.
  • No deployment (repository hosting): There will be no deployment of files to the production site. This option could prove useful if you were to use a Git repository for storing and exchanging code.

How to Use Webhooks to Pull Automatically

Webhooks can be used to set up your remote repository to send Plesk notifications regarding specific events (such as pushing files to the repository). You can find more information on webhook management in GitHub or BitBucket in the official documentation.

Webhook URLs are made for a repository automatically. You should click Repository Settings if you want to see the webhook URL.

Copy and add the webhook URL to your remote repository. Set it up to be activated in case a push to the repository occurs. With this in effect, Plesk will be notified whenever a file is pushed to the remote repository. Files will be pulled automatically, negating the need to hit the Pull Updates button.

If an automatic deployment is set up for a repository, those files pulled will be deployed to the site instantly.

However, the webhook might fail when called through the HTTPS protocol if Plesk has been secured with a self-signed certificate. This is a result of SSL/TLS handshake problems. Specify the HTTP protocol in the webhook URL if this is the case.

How to Activate Extra Deployment Options

File publishing won’t be adequate to complete the deployment of a website in a lot of situations. For instance, when a framework such as Ruby on Rails is used, you might need to run a data migration task following deployment, using a command like this: bin/rails db:migrate.

Plesk provides you with the option to specify one or more extra commands that will run each time the files are deployed to the site. Navigate to Websites & Domains > Git, and click on Repository Settings. Choose Enable additional deploy actions, then enter one or more shell commands. These will run whenever deployment of the repository contents takes place. You should input each individual command in a fresh line.

Please be aware, though, that a chrooted environment will be used for running specified commands on Linux, if SSH access is prohibited for the domain’s system user. The home directory of the subscription’s system user will be used as the file system root for that subscription. No executable files outside the chroot jail will be run.

So, if the path to your site were /var/www/vhosts/ in a chrooted environment, the path would be ./httpdocs. You would be unable to execute commands outside one level above the /httpdocs directory.

How to View Commit Logs

If you want to view the entire commit history for the present branch, visit Websites & Domains > Git. Then, click on the Commit Logs link. This information will be presented for every commit:

  • unique identifier
  • time
  • user name
  • commit message

To update the commit log, hit Refresh.

The commit logs can be filtered by any parameter. For instance, you can view all the commits performed by a specific user beginning at a specific date. Click the “down arrow” button, input the relevant search parameters, and hit Search.

How to Change a Repository’s Name or Remove it

A repository can be renamed at any point. For example, you might opt to retitle a repository from website-dev to website once development has been finished, to avoid potential confusion. Make your way to Websites & Domains > Git and hit Repository Settings. Input the new name into the Repository name box.

What should you do if you want to take out the repository? Click on the Remote Repository link on the Git screen. Plesk will take out the repository, but the target directory with the published data will stay the same.

What is NIXStats, How Did it Originate, and More

Server monitoring is an elixir for online businesses. It gives priceless insights into the functioning of your site, and saves you from unexpected problems. By keeping web performance in check and pinpointing downtime causes and solutions, monitoring software frees up time to perform the tasks that matter to you.

That’s why the WebPros Group, of which Plesk is a member, invited an exciting new company to the family this year: NIXStats.

Founded in 2016, this powerful, easy-to-use monitoring platform was pioneered by Vincent Van Megen, who has now joined the team along with his business to help web professionals succeed through best-in-class server monitoring. NIXStats provides robust, affordable and simplified solutions for online businesses, through a monitoring dashboard that anyone can understand and manage.  

So, the Plesk team took the time to learn about our new monitoring genius, talking to him in this exclusive interview. We explored what made him interested in monitoring, and how he sees the future in the industry.

Meet our Head of Monitoring, Vincent Van Megen, in the video below!

Vincent, with his extensive experience in the industry, found that there were no user friendly solutions for monitoring servers. He designed a software for his own team, before realizing its wide-reaching appeal. So, he dedicated himself to making it into an open source monitoring agent that anyone could benefit from. And so, NIXStats was born. Everything from CPU usage, memory updates, loading times, and more, collated on a single dashboard, built for ease.

At the start of 2021, the innovative platform caught the interest of WebPros, and NIXStats joined the group in March. That’s when Vincent became a member of the team too, aiming to make the lives of web professionals easier, along with the other brands like Plesk, cPanel and beyond.

Everyone at WebPros is delighted to have a new Head of Monitoring, and there are many exciting integrations planned for the future in WebPros products. Learn more about WebPros and NIXStats at their dedicated pages, and watch this space for exciting future integrations and releases!

CloudTalk 2021 – Join Plesk at the Virtual MatchMaking Summit

Cloudtalk 2021 Plesk blog

Throughout the past 12 months, attending conferences has been an impossibility. But in this new dawn of online communication, we are discovering that technology can bring people together in a way that had not been imagined before.

So, Plesk has been busy preparing for a season of virtual conferences and networking events to invite previously unreachable members of our community!

That’s why this May we’re getting ready to attend and present at another event to meet web professionals: CloudTalk 2021. As part of this two-day event uniting IT professionals from 20 countries (at least!), attendees can enjoy networking, expert presentations, and a virtual fair, from the comfort of their personal spaces.

So, what is CloudTalk?

…and how can I join?

CloudTalk is the top Eurasia Cloud Tech event, built to make connections with like-minded professionals and rediscover brands and product ideas that ignite innovation.

Let’s take a look at the agenda:

Cloudtalk agenda Plesk blog

Within this event structure, there are several tracks where you can enjoy presentations that provide valuable insight into business and Cloud Technologies. At Plesk, we are proud to once more welcome the inspirational Jan Loeffler, CTO and product genius at Plesk, to the stage.

Want to be a part of it? Here are the details:

Jan Loeffler Cloudtalk Plesk blog

A Platform for Builders: How to win over Web Developers
Online business is booming. Almost every industry is seeing increased digitalization, which comes with many advantages and challenges. In this presentation, Jan will explore the new landscape of online business, speaking more specifically about the architects behind them: web builders.

Jan Loeffler Cloudtalk Plesk blog
A Platform for Builders: How to win over Web Developers
Online business is booming. Almost every industry is seeing increased digitalization, which comes with many advantages and challenges. In this presentation, Jan will explore the new landscape of online business, speaking more specifically about the architects behind them: web builders.

And this is just the tip of the iceberg. Here are some of the key topics to be discussed in the various virtual ‘halls’:

  • Private cloud adoption
  • DevOps
  • Hyper-converged infrastructures
  • Securing Hybrid Cloud
  • Hyperscaling
  • DX optimization
  • …and much more!


We’re offering a promotion for Standard Passes to CloudTalk! With the Plesk promocode, you can attend this two-day event… for free!

How does it work? Well, enter the CloudTalk ticket page and select ‘Standard Pass’. Then, enter this code in the section ‘Promotion Code’:


That’s it! Easy, right?

So let’s review. Attending online events is the height of fashion right now, and you get to meet people who you would otherwise be unable to reach. And CloudTalk is free for you, Plesk member! We look forward to meeting you virtually at CloudTalk 2021.

Hosting Control Panels of 2021 – The Definitive Guide

Hosting Control Panels 2021

If you’re involved in managing servers for web hosting then you’ll appreciate the importance of having a simple, yet highly effective method of monitoring and looking after your hosting infrastructure. The most effective way of managing all the processes related to routine tasks of hosting infrastructure is to use a web hosting control panel.

Continue reading

Linux Server Security – Best Practices for 2021

Linux Server Security

Linux server security is on sufficient level from the moment you install the OS. And that’s great to know because… hackers never sleep! They’re kind of like digital vandals. Taking pleasure – and sometimes money too – as they inflict misery on random strangers all over the planet.

Anyone who looks after their own server appreciates the fact that Linux is highly secure right out the box. Naturally, it isn’t completely watertight. But it does do a better job of keeping you safe than most other operating systems.

Still, there are plenty of ways you can improve it further. So here are some practical ways how you can keep the evil hordes from the gates. It will probably help if you’ve tinkered under the hood of a web server before. But don’t think that you have to be a tech guru or anything like that.

Deactivate network ports when not in use

Deactivate network ports when not in use

Leave a network port open and you might as well put out the welcome mat for hackers. To maintain web host security you can use the “netstat” command to inform you which network ports are currently open. And also which services are making use of them. This should close off another avenue of attack for hackers.

You also might want to set up “iptables” to deactivate open ports. Or simply use the “chkconfig” command to shut down services you won’t need. Firewalls like CSF let you automate the iptables rules, so you could just do that. If you use Plesk platform as your hosting management software – please pay attention to this article about Plesk ports.

The SSH port is usually 22, and that’s where hackers will expect to find it. To enhance Linux server security, change it to some other port number you’re not already using for another service. This way, you’ll be making it harder for the bad guys to inject malware into your server. To make the change, just go to /etc/ssh/sshd_config and enter the appropriate number.

Update Linux Software and Kernel

Update software for better Linux server security

Half of the Linux security battle is keeping everything up to date because updates frequently add extra security features. Linux offers all the tools you need to do this, and upgrading between versions is simple too. Every time a new security update becomes available, you need to review it and install it as soon as you can. Again, you can use an RPM package manager like yum and/or apt-get and/or dpkg to handle this.

# yum update


# apt-get update && apt-get upgrade

It’s possible to set up RedHat / CentOS / Fedora Linux so that you get yum package update notifications sent to your email. This is great for Linux security and you can also apply all security updates using a cron job. Apticron can be used to send security mitigations under Debian / Ubuntu Linux. You can also use the apt-get command/apt command to configure unattended-upgrades for your Debian/Ubuntu Linux server:

$ sudo apt-get install unattended-upgrades apt-listchanges bsd-mailx

Reduce Redundant Software to Increase Linux Security

For greater Linux server security hardening It’s worth doing a spring clean (at any time of the year) on your installed web services. It’s easy for surplus apps to accumulate and you will probably find that you don’t need half of them. In the future, for better Linux server security try not to install software that you don’t need. It’s a simple and effective way to reduce potential security holes. Use an RPM package manager like yum or apt-get and/or dpkg to go through your installed software and remove any that you don’t need any more.

# yum list installed
# yum list packageName
# yum remove packageName


# dpkg --list
# dpkg --info packageName
# apt-get remove packageName

Turn off root logins to improve Linux server security

Linux servers the world over allow the use of “root” as a username. Knowing this, hackers will often try subverting web host security to discover your password before slithering inside. It’s because of this that you should not sign in as the root user. In fact, you really ought to remove it as an option, creating one more level of difficulty for hackers. And thus, stopping them from being able to get past your security with just a lucky guess.

So, all it takes is for you to create a separate username. Then use the “sudo” special access command to execute root level commands. Sudo is great because you can give it to any users  you want to have admin commands, but not root access. Because you don’t want to compromise security by giving them both.

So you deactivate the root account, but before, check you’ve created and authorized your new user. Next, go to /etc/ssh/sshd_config in nano or vi, then locate the “PermitRootLogin” parameter. Change the default setting of “yes” to “no” and then save your changes.

GnuPG encryption for web host security

GnuPG encryption

When data is on the move across your network, hackers will frequently attempt to compromise Linux server security by intercepting it. Always make sure anything going to and from your server has password encryption, certificates and keys. One way to do this is with an encryption tool like GnuPG. It uses a system of keys to ensure nobody can snoop on your info when in transit.

Change/boot to read-only

All files related to the kernel on a Linux server are in the “/boot” directory. The standard access level for the directory is “read-write”, but it’s a good idea to change it to “read-only”. This stops anyone from modifying your extremely important boot files.

Just edit the /etc/fstab file and add LABEL=/boot /boot ext2 defaults, rows 1 2 to the bottom. It is completely reversible, so you can make future changes to the kernel by changing it back to “read-write” mode. Then, once you’re done, you can revert back to “read only”.

A better password policy enhances Web Host Security

better password policy - linux server security

Passwords are always a security problem because humans are. People can’t be bothered to come up with a lot of different passwords – or maybe they can’t. So what happens? They use the same ones in different places. Or worse yet – combinations that are easy to remember, like “password” or “abcde”. Basically, a gift to hackers.

Make it a requirement for passwords to contain a mix of upper AND lower case letters, numbers, and symbols. You can enable password ageing to make users discard previous passwords at fixed intervals. Also think about banning old passwords, so once people use one, it’s gone forever. The “faillog” command lets you put a limit on the amount of failed login attempts allowed and lock user accounts. This is ideal to prevent brute force attacks.

So just use a strong password all the time

Passwords are your first line of defense, so make sure they’re strong. Many people don’t really know what a good password looks like. That it needs to be complex, but also long enough to make it the strongest it can be.

At admin level, you can help users by securing Plesk Obsidian and enforcing the use of strong passwords which expire after a fixed period. Users may not like it, but you need to make them understand that it saves them a lot of possible heartache.

So what are the ‘best practices’ when setting up passwords?

  1. Use passwords that are as long as you can manage
  2. Avoid words that appear in the dictionary (like “blue grapes”)
  3. Steer clear of number replacements that are easy to guess (like “h3ll0”)
  4. Don’t reference pop culture (such as “TARDIS”)
  5. Never use a password in more than once place
  6. Change your password regularly and use a different one for every website
  7.  Don’t write passwords down, and don’t share them. Not with anybody. Ever!

The passwords you choose should increase Web Host Security by being obscure and not easy to work out. You’ll also help your security efforts if you give your root (Linux) or RDP (Windows) login its own unique password.

Linux security security needs a firewall

Firewall helps Linux server security - Plesk

A firewall is a must have for web host security, because it’s your first line of defense against attackers, and you are spoiled for choice. NetFilter is built into the Linux kernel. Combined with iptables, you can use it to resist DDos attacks.

TCPWrapper is a host-based access control list (ACL) system that filters network access for different programs. It has host name verification, standardized logging and protection from spoofing. Firewalls like CSF and APF are also widely used, and they also come with plugins for popular panels like cPanel and Plesk.

Locking User Accounts After Unsuccessful Logins

For Linux security, the faillog command shows unsuccessful login attempts and can assign limits to how many times a user can get their login credentials wrong before the account is locked. faillog formats the contents of the failure log from the /var/log/faillog database/log file. To view unsuccessful login attempts, enter:


To open up an account locked in this way, run:

faillog -r -u userName

With Linux security in mind be aware that you can use the passwd command to lock and unlock accounts:

lock Linux account

passwd -l userName

unlock Linux account

passwd -u userName

Try disk partitions for better Web host security

disk partitions - linux server security

If you partition your disks then you’ll be separating OS files from user files, tmp files and programs. Try disabling SUID/SGID access (nosuid) along with binaries (noexec) on the operating system partition

Avoid Using Telnet, FTP and Rlogin/Rsh Services

With the majority of network configurations, anyone on the same network with a packet sniffer can intercept FTP, telnet, or rsh commands, usernames, passwords, and transferred files. To avoid compromising Linux server security try using either OpenSSH, SFTP, or FTPS (FTP over SSL), which gives FTP the benefit of SSL or TLS encryption. To move outdated services like NIS or rsh enter this yum command:

# yum erase xinetd ypserv tftp-server telnet-server rsh-server

For Debian/Ubuntu Linux server security, give the apt-get command/apt command a try to get rid of non-secure services:

$ sudo apt-get --purge remove xinetd nis yp-tools tftpd atftpd tftpd-hpa telnetd rsh-server rsh-redone-server

Use an Intrusion Detection System

NIDS or Network intrusion detection systems keep watch for malevolent activity against Linux server security like DOS attacks, port scans, and intrusion attempts.

For greater Linux server security hardening it’s recommended that you use integrity checking software before you take a system into a production environment online. You should install AIDE software before connecting the system to a network if possible. AIDE is a host-based intrusion detection system (HIDS) which monitors and analyses a computing system’s internals. You would be wise to use rkhunter rootkit detection software as well.

Logs and Audits

You can’t manage what you don’t measure, so if you want to stop hackers then your system needs to log every single time that intruders try to find a way in. Syslog is set up to store data in the /var/log/ directory by default and it can also help you to identify the potential surreptitious routes inside that misconfigured software can present.

Secure Apache/PHP/NGINX server

Edit httpd.conf file and add:

ServerTokens Prod
ServerSignature Off
TraceEnable Off
Options all -Indexes
Header always unset X-Powered-By

Restart the httpd/apache2 server on Linux, run:

$ sudo systemctl restart apache2.service


$ sudo systemctl restart httpd.service

Activate CMS auto-updates

Activate CMS auto-updates

CMSs are quite complex, so hackers are always trying to exploit security loopholes with them. Joomla!, Drupal and WordPress, are all hugely popular platforms, so developers are constantly working on new security fixes. This means updates are important and should be applied straight away. The best way to ensure this happens is to activate auto-updates, so you won’t even have to think about it. Your host isn’t responsible for the content of your website. So it’s up to you to ensure you update it regularly. And it won’t hurt to back it up once in a while either.

Backup regularly

Backup regularly - linux server security - cloud

Regular and thorough backups are probably your most important security measure. Backups can help you recover from a security disaster. Typical UNIX backup programs use dump and restore, and these are we recommend them. For maximum Linux security, you need to backup to external storage with encryption, which means something like a NAS server or cloud-based service.

Protect Email Directories and Files

These Linux security tips wouldn’t be complete without telling you that Linux has some great ways to protect data against unauthorized access. File permissions and MAC are great at stopping intruders from getting at your data, but all the Linux permissions in the world don’t count for anything if they can be circumvented—for instance, by transplanting a hard drive to another machine. In such a case you need to protect Linux files and partitions with these tools:

  • For password-protected file encryption and decryption, use the gpg
  • Both Linux and UNIX can add password protection to files using openssl and other tools.
  • The majority of Linux distributions support full disk encryption. You should ensure that swap is encrypted too, and only allow bootloader editing via a password.
  • Make sure root mail is forwarded to an account that you check.

System Accounting with auditd

Auditd is used for system audits. Its job is to write audit records to the disk. This daemon reads the rules in /etc/audit.rules at start-up. You have various options for amending the /etc/audit.rules file such as setting up the location for the audit file log. Auditd will help you gain insight into these common events:

  • Occurrences at system startup and shutdown (reboot/halt).
  • Date and time an event happened.
  • The user who instigated the event (for example, perhaps they were attempting to access /path/to/topsecret.dat file).
  • Type of event (edit, access, delete, write, update file, and commands).
  • Whether the event succeeded or failed.
  • Records events that Modify time and date.
  • Discover who modified network settings.
  • Record actions that change user or group information.
  • Show who changed a file etc.

Use Kerberos

Kerberos is a third-party service offering authentication that aids Linux security hardening. It uses shared secret cryptography and assumes that packets moving on a non-secure network are readable and writable. Kerberos is based on symmetric-key cryptography and so needs a key distribution center. Kerberos lets you make remote login, remote copy, secure inter-system file copying, and other risky actions safer and it also gives you more control over them. Kerberos authentication prevents unauthorized users from spying on network traffic and grabbing passwords.

Hardening Security Of Your Linux Server Using Plesk

Linux Server Security Summary

That’s a lot of tips, but you need to keep your linux server security updated in a world of thieves and vandals. These despicable beings are hard at work all the time, always looking to exploit any chink in a website’s armor. If you give them the slimmest opportunity to disrupt your business, they will happily take advantage of it. Since there’s such a huge army of them, you need to make sure that your castle has extremely strong defenses.

Let us know how many of these tips you have implemented, or if you have any questions in the comments below.