#plesk 12

UPGRADES notwendig für Server mit Plesk 11.x / Debian Wheezy (7.x)

Debian 7.x ist Out, denn aktuell ist Debian Version 8.x Jessie! End of Live-Datum für Debian 7.x ist der 26.04.2016, ab dem nur noch die wichtigsten Sicherheits-Updates im LTS-Support bis max. Mai 2018 geben wird!

Parallel dazu wird Support für Plesk 11.x nur noch bis 13. Juni 2016 geleistet und nur noch die wichtigsten Sicherheits-Updaes wird es nur noch bis 13.12.2016 geben!

Was Kunden mit…

New Post has been published on https://www.securityinet.com/review-hebrew-in-parallels-plesk/

Review: Hebrew in Parallels Plesk ?

Review: Hebrew in Parallels Plesk ?

New Post has been published on https://www.securityinet.com/new-skin-for-plesk-12/

New Skin for Plesk 12

We’ve always strived to keep Plesk visually modern and pleasant for users, so we have created a new additional skin for Plesk 12. We would love to hear your opinion on this skin, as we’re evaluating it as a possible replacement for current default Plesk skin.

Try this new look&feel and let us know what you think.

The primary goal of the new skin was to make Plesk look more modern. We wanted the skin to be neat and clean, without unnecessary graphical elements that can distract users from perceiving important information. This path has eventually led us to “flat” design focused on minimalistic usage of UI elements and typography without complex visual decorations like shadows, glows, textures, and gradients. We wanted Plesk to have a “simple”, but at the same time “cool and modern” look.

Below are some screenshots that illustrate the new skin.

Service Provider View – Home page

Service Provider View – Tools & Settings

Power User View – Websites & Domains

Power User View – Add New Email Address

Power User View – Files

Power User View – Adaptation For Mobile Devices

What is next

Updating icons to suit the new style.

Implementing responsive UI for Service Provider View (getting rid of frames), so it will work nicely on mobile devices

And much more…

Tell us what we’ve missed and what do you think about this skin.

Thank you!

Good lyck

  New Skin for Plesk 12

New Post has been published on https://www.securityinet.com/what-is-plesk-12-application-pool-in-iis/

What is Plesk 12 application pool in IIS?

This article describes when, why, and how many application pools are created by Plesk in IIS.

There are two types of application pools in Plesk: shared and dedicated. Shared application pools are assigned to serve sites that do not have dedicated pools. Dedicated pools are used to serve only the sites of the customer or reseller to whom the pool is assigned. Dedicated pools isolate sites of different customers or resellers from each other. It increases the stability of different sites if one of the customer’s or reseller’s sites crashes. For more information about application pools and their management see the Plesk Administrator’s Guide.

I am not going to describe dedicated and shared application pools, instead my aim is to write about how Plesk application pools are related to IIS application pools. Generally, it does not matter what type of application pool (shared or dedicated) Plesk creates – they are all provisioned in the same way. Let’s introduce two terms:

Plesk application pool – a pool that a Plesk user is allowed to manage. The pool’s settings can be managed in Plesk UI, and it can be either shared or dedicated.

IIS application pool – a pool that is created directly in IIS (one you can see in the IIS Manager).

It is important to understand that Plesk application pools are represented in IIS as groups of IIS application pools. It means that an application pool in Plesk (whether shared or dedicated) includes several IIS application pools. The number of IIS application pools in the group depends on the number of sites with different ASP.NET versions that are served by the corresponding Plesk application pool.

For example, consider a subscriber that has a dedicated Plesk application pool and two sites, “domain1.com” and “domain2.com”. “domain1.com” uses .NET v4.0, while “domain2.com” uses .NET v2.0. In this case, two application pools are created in IIS: “domain1.com(domain)(2.0)(pool)” for “domain2.com”, and “domain1.com(domain)(4.0)(pool)” for “domain1.com”. Note that in this case the IIS application pool serving “domain2.com” is named “domain1.com(domain)(2.0)(pool)” because the site belongs to the “domain1.com” web space.

Configuration in Plesk:

Configuration of pools in IIS:

The same is true for shared application pools. The maximum number of IIS application pools assigned to a single Plesk application pool is three (one pool for ASP.NET 1, for ASP.NET 2, and one for ASP.NET 4). When a user switches ASP.NET version for a site in Plesk, if an IIS application pool with the chosen ASP.NET version does not exist, one is created.

To sum it up, it is not possible to explicitly control the number of application pools in IIS using Plesk. Keep in mind that whenever you switch on the dedicated Plesk application pool for a user, the real number of dedicated pools in IIS could increase by more than one.

Why is a Plesk application pool a group of IIS application pools?

An application pool in IIS can only serve sites with only one version of ASP.NET. So, if a subscriber has sites with different ASP.NET versions, several application pools in IIS are required, one for each version of ASP.NET. A Plesk application pool is a set of application pool settings that should be applied for all the sites of the subscriber. Consequently, if there are sites with different ASP.NET versions, then the set of application pool settings should be applied for all application pools in IIS.

How do Plesk application pool settings work?

When application pool settings are changed in Plesk, they are applied to all corresponding application pools in IIS. For instance, if a Plesk application pool consists of three IIS application pools, and a user changes “The maximum number of worker processes” setting via the Plesk GUI, then the value of this setting will be applied to all IIS application pools included in the Plesk application pool. Consequently, the real maximum number of worker processes in the system is increased by three times the number set in Plesk.

  Ref. devblog.plesk.com

New Post has been published on https://www.securityinet.com/protecting-your-wordpress-installations-with-fail2ban-in-plesk-12/

Protecting your wordpress installations with fail2ban in Plesk 12

There is no two ways about it: having your server compromised sucks. Seeing your website defaced or infected with malicious scripts feels like a punch in the gut. Did you know that modern brute force tools can test millions of passwords per second? It takes around 15 minutes to crack an average password (eight symbols in length, consisting of mixed-case letters, numbers, and special symbols). Is there anything you can do to protect yourself?

Luckily, the answer is yes. Plesk 12 comes with a comprehensive set of security tools.We have got the ModSecurity support to protect web applications, and the automatic security hardening for WordPress. But today I would like to tell you about a different tool called Fail2ban. Fail2ban is effective against brute force attacks, and can be used to protect any service running on your server.

Here is how Fail2ban works:

Fail2ban constantly monitors logs of the services it protects, matching every new log entry against a pre-defined set of rules.

Once a suspicious entry is found in a log, Fail2ban notes the IP of the potential attacker and starts counting. Every time the IP performs suspicious activity, Fail2ban adds one to the counter.

Once a pre-defined number of attempts is reached, Fail2ban can do two things:

Send an email notification, and/or

Ban the attacker’s IP for a pre-defined length of time.

In this article we will give step-by-step instructions illustrating how you can use Fail2ban to protect your WordPress installation from brute force attacks. To do so, we will need to follow these steps:

Create a filter, which is a set of one or more regular expressions. The filter is used to search the logs for suspicious activity.

Create a jail, which is a set of rules covering an individual scenario. The settings of the jail determine what is to be done once an attack is detected.

Step 1: Creating the filter.

To create a filter for WordPress, go to Tools & Settings > IP Address Banning (Fail2Ban), open the Jails tab, and click Manage filters > Add Filter. Give the filter a name, and paste the following into the Content field:

[Definition] failregex = ^<HOST> .* "POST .*wp-login.php HTTP/.*" 200 ignoreregex =

so that it looks like this:

As you can see, the filter contains a single regular expression, and it will trigger every time the WordPress login page is loaded – for example, after a failed authentication attempt.

Step 2: Creating the jail

To create the jail, return to the Jails tab and click Add Jail. Start by naming your jail and selecting the filter you have just created from the Filter menu. Once you are done, it is time to add the most important component of the jail – the actions.

Actions define what happens when a jail is activated. There are four preconfigured actions in Fail2ban:

Ban the attacker on a single port.

Ban the attacker on multiple ports.

Ban the attacker on all ports.

Send a notification email to a specified email address.

To add an action, select it from the Action menu and click Add. You can add any number of actions to a jail. You may need to customize the action to suit your needs (for example, to provide the desired mail address to send notifications to, or to specify what ports should be closed to the offending IP).

Once the actions are configured, you need to specify one or more log files Fail2ban will check for the signs of an attack – those go in the Log path field. To protect a specific WordPress installation, specify the path to its Apache access log files, found at:

/var/www/vhosts/<WordPress installation domain name>/logs/access_log

and

/var/www/vhosts/<WordPress installation domain name>/logs/access_ssl_log

You can specify more than a single log to protect multiple WordPress installations. Alternatively, you can use the * mask to protect all of them, like this:

/var/www/vhosts/*/logs/access_*log

Finally, there are two optional parameters you can set: the maximum number of failed login attempts and the IP address ban period. The first is the number of “strikes”, unsuccessful login attempts, leading to a ban; the second is the length of the resulting ban in seconds. For example, if you set the value of the first parameter to 3, and the second to 300, after a third unsuccessful login attempt the jail will trigger and ban the attacker for five minutes. If these values are left undefined for a jail, server-level Fail2ban settings are used.

You can see an example of a fully configured jail on the screenshot below:

Note that jails are created on a per-service basis (as in, one for SSH, one for SMTP etc.), but there can be multiple jails for a single service, covering different scenarios. Once the jail is created, all that remains is to enable Fail2ban: 1. Go to Tools & Settings > Services Management and make sure that the IP Address Banning (Fail2ban) service is running. 2. Go to Tools & Settings > IP Address Banning (Fail2Ban), open the Settings tab and select the Enable intrusion detection checkbox. 3. Finally, open the Banned IP Addresses tab and click Switch On IP Address Banning.

Step 3: Action!

Now it is the time to test Fail2ban to make sure its protection works (let us assume that the settings of your jail match those on the screenshot above). Open the login page of your WordPress install and try logging in with incorrect login and/or password. Then do it again. And one more time for good measure. If you have set up everything correctly, you will not get another chance – the jail you created will activate and ban you for five minutes. And here is what was happening “under the hood” in the meantime:

 You try authenticating with incorrect credentials for the first time. The “POST /wp-login.php HTTP/1.0″ entry gets written to the Apache access log. As Fail2ban monitors this log, and the entry matches the regular expression defined in the filter, Fail2ban notices the authentication attempt and starts counting. Okay, maybe you mistyped your password. Mistakes happen.

You try authenticating for the second time. Same as above, only the counter is now at two. This is getting suspicious, but Fail2ban gives you one more chance.

You try authenticating for the third time. Okay, now this is getting downright fishy. Three strikes, you are out! Fail2ban creates a temporary rule in the iptables barring you from accessing the server and sends a notification to “[email protected]”.

If you do not actually get banned, it means that there is a misconfiguration somewhere. Here are some troubleshooting steps that may help:

Make sure that the Fail2ban service is running, that intrusion detection is enabled, and that IP banning is turned on, as described above.

Make sure that the jail is activated (by the way, all newly created jails are activated by default).

Make sure that the filter you created actually catches the relevant log entries with the fail2ban-regex command.

The syntax of fail2ban-regex is as follows:

fail2ban-regex <path to the access_log file> /etc/fail2ban/filter.d/<filter name>

Look for the Failregex value in the output. If it is zero, the filter is configured incorrectly. Naturally, Fail2ban can be used to protect any service on the server, not just WordPress. Using the examples provided above as reference, you can create custom filters and jails to fit your scenario.

Further information about Fail2ban is available here: Fail2ban documentation: http://www.fail2ban.org/wiki/index.php/MANUAL_0_8 Plesk documentation: http://download1.parallels.com/Plesk/PP12/12.0/Doc/en-US/online/plesk-administrator-guide/73381.htm

  Ref. devblog.plesk.com

Protecting your wordpress installations with fail2ban in Plesk 12

Good luck !

Comments from devblog.plesk.com website :)

9 Comments to “Protecting Your WordPress Installations With Fail2ban”

Gavin says:

April 23, 2015 at 4:43 am

Hi,

Great to see this getting promoted – we’ve been using Fail2Ban for WP logins for a while now.

However, there is an issue with your suggested filter regex – that will catch ALL posts to wp-login.php, not just failed logins. Apache will return a 200 code on failed login and a 302 on success, so the filter regex should be:

failregex = .*] “POST /wp-login.php HTTP/.*” 200

Note that this will only work for WP installations in the webroot. I’m not sure how to adapt the regex to allow for installations in a subdirectory. By default, the Plesk Application installer installs WordPress into a subdirectory /wordpress (which is really annoying!).

Also, regarding the log path, your suggestion will only catch non-SSL WP logins, to allow for both SSL and non-SSL you would need to use “access*_log”.

We use this log path to track ALL Plesk domains, both SSL and non-SSL (on CentOS 6):

logpath = /var/www/vhosts/system/*/logs/access*_log

Hope that helps.

Reply

Gavin says:

April 23, 2015 at 7:40 am

Correction … it would be pretty simple to modify the filter regex to accommodate for WordPress installations in a subdirectory — using a wildcard — but the performance hit would be too great to justify it.

Reply

Alexey Stepanov says:

April 23, 2015 at 11:46 am

Thanks for the comment, Gavin. Truth be told, the article was meant to give a brief overview of Fail2ban and its capabilities rather than provide comprehensive instructions. Good catch about the HTTP status code and the need to parse both access_log and the access_ssl_log though! As for the regular expression, we will discuss it internally and hopefully come up with a solution (which we will be sure to post in the comments).

Reply

Alexey Stepanov says:

April 23, 2015 at 12:40 pm

We have run a few tests, and it looks like the following regular expression does an admirable job of protecting WordPress installations in subdirectories:

failregex = ^ .* “POST .*wp-login.php HTTP/.*” 200

I updated the article taking your feedback into account – thanks again for sharing!

Reply

Gavin says:

April 23, 2015 at 4:47 pm

Hi again,

Great, glad to help.

I just realised we’re not matching in the failregex, as you are — is there any actual need or benefit in matching the in the regex? (Ours seems to work fine without it).

Thanks for the wildcard tip.

Alexey Stepanov says:

April 24, 2015 at 9:33 am

The way I understand it, there are no hard and fast rules for writing regular expressions (other than those governing the syntax, obviously). So I see no problem with your failregexp differing from the one we used – as long as it works, I reckon you’re fine.

Gavin says:

April 24, 2015 at 11:11 am

Just realised that the < and > tags are being stripped out. I do have the <HOST> in my regex. Silly me.

Alexei Yuzhakov says:

April 24, 2015 at 9:01 am

> By default, the Plesk Application installer installs WordPress into a subdirectory /wordpress (which is really annoying!). Since Plesk 12.1 first app will be installed into webroot by default.

Reply

Gavin says:

April 24, 2015 at 11:06 am

Great news! Thanks.

New Post has been published on http://www.securityinet.com/parallels-plesk-12-harden-supercharge-wordpress-site/

Parallels Plesk 12: Harden Up and Supercharge Your WordPress Site

Parallels Plesk 12: Harden Up and Supercharge Your WordPress Site

Web management tools aren’t new, they’ve been around for many years and they all support one-click installs for common web applications. However, for the most part all this does is install the application and then you’re on your own. You don’t have visibility to manage these applications once they’ve been installed.

If you then throw in the fact that users love to install themes and plugins, the management becomes even more fun. The solution to this usually involves third-party services to centrally manage our WordPress sites. Wouldn’t it be nice if these management features were built into our hosting control panel? Well, with the latest version of Plesk, this is now possible.

Parallels Plesk is one of the leading hosting control panel and automation platforms on the market. If you’ve used a few hosting providers, chances are you’ve used Plesk.

In this article I’ll walk you through how to use Plesk 12 with a focus on the features that are most relevant to WordPress professionals, mainly the WordPress Toolkit. I will also touch on some of the other areas that those who manage multiple WordPress sites will be interested in.

First Impressions of the WordPress Toolkit in Plesk 12

When I first logged in, it was immediately obvious that the latest version of Plesk is seriously catering to WordPress developers and administrators.

While other web applications are supported, the WordPress-specific features are impressive. Plesk 12 has introduced what they call the ‘WordPress Toolkit‘ and it brings professional WordPress management features to a mainstream web hosting control panel. This includes the ability to detect manual installations, create new installations (with control over various configuration options), perform bulk updates, and manage plugins/themes.

In addition to the WordPress management features, if you want to jump into a specific WordPress dashboard, there’s usually a direct link available in most places within in the Plesk interface. That said, you can easily perform routine tasks without leaving Plesk.

Overview of features:

Security

Update Management

Plugin Management

Theme Management

ServerShield by CloudFlare

ModSecurity

Fail2ban

Outbound Antispam

Range of Editions

Installing WordPress Using the WordPress Toolkit

Installing WordPress is easy and using the WordPress Toolkit is even easier.

To install WordPress, log into Plesk and go to the ‘Applications’ page. On this page you have two options for installing WordPress via the drop-down box in the top right. The first option is ‘Install’ and that will run a default WordPress install.

The second option is ‘Install (Custom)’. This option will provide you with more control over the common configuration options.

With this option you will be able to select the installation path, update settings and admin access.

Further down the screen, you’ll find your standard WordPress configuration options such as your site name, administrator email address, language, and database details.

When your installation is complete, you’ll see the message shown below:

Security

Plesk 12 also includes best-of-breed security controls, with both WordPress-focused options and traditional web security tools.

Check Security

This feature will allow you to perform a security check to make sure WordPress has been configured correctly and general security measures are in place. Users would usually install plugins to achieve the same results, but now this is available natively within Plesk.

How to Use the ‘Check Security’ Feature

There are two ways to access this feature. The first appears when you login to Plesk. Under ‘Websites & Domains’ you’ll find a button labelled ‘Security Scan’ listed next to the WordPress installation name.

The second way to access this feature is by clicking on the WordPress installation name and selecting ‘Check Security’ under the ‘Tools’ menu on the right-hand sidebar.

Selecting either ‘Security Scan’ or ‘Check Security’ will display the screen shown below. The first time you run this on a new site, you will see a few alerts letting you know that there are measures that can be taken to harden your installation. Make sure these options are selected and then click on ‘Secure':

Now, if you re-run this scan or check, it will look like this:

You will notice that some permissions give you the option to ‘Roll Back’, which I can see turning into a real time-saver when troubleshooting.

By following these basic steps above, you have significantly hardened your WordPress site. Too often I see security plugins being promoted as the silver bullet when it comes to security, however, following the basic best practices covered in ‘Security Check’ will offer way more protection from both known and unknown threats. It also removes the need for yet another plugin.

Detecting WordPress Installations

The WordPress Toolkit also includes a ‘Scan’ feature that you can use to detect WordPress sites running version 3.4 and above. This allows you to attach an installation to your WordPress Toolkit sites.

It’s worth noting that Plesk only knows about installations created through the WordPress Toolkit using Plesk’s application installer (based on Application Packaging Standard technology) or those that have been detected during a scan. It’s recommended you periodically scan your client sites for WordPress installations so they can be managed within the WordPress Toolkit.

Changing Your Administrator Username

We should all know not to use the default ‘admin’ as the administrator account, however, if we’re inheriting someone else’s sites there may be an occasion when you’re dealing with the dreaded ‘admin’ username. Or you might just want to change the administrator username.

There are a lot of ways to change your administrator username, most users will use a plugin to do this or create a new user to be the administrator and then delete the old ‘admin’ account.

With the WordPress Toolkit, this is easily managed, simply click on ‘Manage’ as shown below:

This will take you to a page where you can then specify your new administrator username.

Security Core

Security is a central theme to much of the Plesk platform. With Version 12, there are several powerful tools that have been bundled into ‘Security Core’. Here’s a few of the available tools for those who want to take extra steps to harden their sites (which should be everyone!):

ModSecurity

Fail2Ban

Outbound Antispam

ServerShield by CloudFlare

We will cover these tools in more detail below.

Update Management

Keeping any web application updated is critical. With WordPress running on 47.38% of identifiable CMSs on the Internet, it’s a popular target for attackers. A key component of WordPress Toolkit is the ability to manage all of your WordPress core updates in one place.

How To Update Multiple Sites

Under the ‘Websites & Domains’ tab select ‘WordPress’ on the right-hand sidebar. This will then display a list of all your WordPress sites. To run either a single or bulk update, select the sites you wish to update and click on the ‘Update ‘ button, it couldn’t get any easier. During my testing, updating WordPress worked flawlessly.

Once the updates have been installed and the process is complete, you’ll get an alert in the bottom right corner of your screen.

Managing Automatic Updates

When the WordPress team announced the move to automatic updates, most of us loved the idea. While I don’t personally ever recommend turning off automatic updates, I can understand why some people like to control updates themselves. Also, core updates such as 4.0 still require manual updating, so performing manual updates is something we all have to do.

Even though there are a few ways to manage updating, such as editing your wp-config.php, or installing a plugin such as WP Updates Settings, once you have more than a few sites, you really need centralized management to make things easier for you.

To turn on (or off) Automatic Updates, just toggle on the ‘Automatic Updates’ switch on your WordPress installation.

I’m a fan of updating early and often, but if you have clients who prefer to take their time, you can at the very least easily check what versions they are running on your systems at a glance.

Managing Plugins

Once you have updates under control, plugins are probably one of the greatest areas of concern when supporting lots of WordPress sites.

Issues such as performance, compatibility, and security are often linked to the choice of plugins. The WordPress Toolkit in Plesk 12 comes with a section to manage plugins. You can access this area under the ‘Websites & Domains’ tab, then select ‘WordPress’ on the right-hand sidebar followed by the ‘Plugins’ tab which will show a global list of plugins that are installed. Here’s what it looks like:

Within the Plugin section, you can perform a number of actions:

Activate/Deactivate

Install

Delete

Update

Search

The ability to search all plugins across your systems is useful if you’ve discovered an incompatibility or a security issue.

If you want to manage plugins for a particular installation, under the ‘WordPress Installations’ tab select the site and then select ‘Plugins’ in the toolbar:

Poorly developed or configured plugins are often a cause of performance issues. With the plugin view you can disable a plugin with one click or install a better alternative.

Another powerful feature is the ability to bulk install plugins. To manage plugins on a single site, click on the site within the ‘Websites & Domains’ tab and then select ‘Manage Plugins’ next to the site you wish to manage. You can then select the plugins that you want active or inactive.

If you want to manage plugins across multiple sites go to ‘WordPress’ in the right hand sidebar to view the ‘WordPress Installations’ page. Then select the sites you wish to bulk install plugins on, then select ‘Plugin’ in the toolbar.

As shown above, you might want to install a troubleshooting plugin such as P3 (Plugin Performance Profiler)on all of your sites to help your clients identify common performance problems. You’ll notice that ‘Activate after installation’ is checked, this is optional.

Managing Themes

Similar to the plugin management feature, you can see a list of all installed and active themes in the ‘Websites & Domains’ tab either by clicking on ‘WordPress’ on the right-hand sidebar and selecting the WordPress site:

Or by clicking on the ‘Themes’ tab:

I know many WordPress developers like to remove the default themes, but I like to leave the default themes for troubleshooting and isolating theme and theme/plugin compatibility issues. This is especially important when you have clients who like ‘experimenting’.

As with the Plugin management section above, the ability to install, activate, and deactivate themes from within Plesk is a huge time-saver.

Enabling ServerShield by CloudFlare

ServerShield is the result of a partnership with Parallels and CloudFlare and is a new key feature of Plesk 12.

People usually associate CloudFlare as ‘just a CDN’ and there’s no doubt it is definitely a world-class CDN, however there’s much more to CloudFlare than that. They also offer a range of security-related features that can further lock down your site.

To enable ServerShield, select the link in the sidebar as shown below:

ServerShield offers easy CloudFlare and StopTheHacker integration for your client sites directly within your Plesk interface, enabling both services couldn’t be any easier.

ServerShield has two main components:

CloudFlare

StopTheHacker

CloudFlare

CloudFlare’s security platform is comprehensive and beyond the scope of this article, but here are a few of the threats CloudFlare helps protect you from:

Comment Spam

SQL Injection

XSS

Malicious and Harvesting Bots

StopTheHacker

StopTheHacker offers daily monitoring of the reputation of your site on malware and phishing blacklists such as Google’s Safe Browsing list. It also offers suggestions on how you fix this if you ever find yourself on the list. Enabling StopTheHacker monitoring for yours or your clients sites is one click away in Core Security, as seen in the screenshot below:

ModSecurity

ModSecurity is a powerful web application firewall and included in all editions of Plesk 12.

Plesk gives you an easy interface to manage ModSecurity’s behaviour. All editions of Plesk 12 include premium ModSecurity rules from AtomiCorp. This means they’ll be updated regularly by a reputable ModSecurity rules provider to protect you from a variety of the latest threats.

As well as AtomiCorp, Plesk’s ModSecurity also ships with the OWASP Core Rule Set (CRS) and the Comodo ModSecurity Rule Set. The OWASP rules are known to be quite restrictive and may cause issues for WordPress, so Parallels recommend using the rules from Atomic or Comodo in this case.

There are also a few nice touches to the ModSecurity interface, like the ability to switch off rules by the ID, CVE, or regular expression. This is very useful if you’re trying to isolate a problem, as some ModSecurity rules can cause false positives.

If you’re looking at hardening your site, ModSecurity is something you’ll want to make sure you’re using (and leaving turned on) so it’s worth spending some time to get to know it.

Fail2Ban

Fail2Ban is a popular application that looks for any suspicious activity in your log files for various services and blocks (or ‘jails’) the IP addresses associated with that activity. This is useful for automatically blocking brute force attacks originating from an IP address or network. The Fail2Ban application can also automate changing firewall rules and send email alerts.

To configure Fail2Ban, go to ‘Tools & Settings > IP Address Banning (Fail2Ban) (in the Security group)’ and select the ‘Enable intrusion detection checkbox’. You can then configure the ban time length, interval between attacks as well as the number of failures before an IP address is banned.

You can also whitelist trusted IP addresses by going to ‘Tools & Settings > IP Address Banning (Fail2Ban) > Trusted IP Addresses > Add Trusted IP’. This is useful so you don’t accidentally end up blocked, or if you want to perform your own security checks on your systems.

Outbound Antispam

The problem of blacklisted IP addresses is something that has plagued even some of the biggest players and is a serious problem when you’re running lots of sites on a single or small range of IP addresses. With Outbound Antispam, you can protect your IP reputation by limiting your outgoing mail. This is an important feature that protects your users from getting their IP address blacklisted.

Selecting the Right Edition

Plesk comes in four flavors, catering for those hosting a few sites all the way up to professional hosting providers. The editions available are:

Web ADMIN Edition

Web APP Edition

Web PRO Edition

Web HOST Edition

All of the editions of Plesk 12 includes the WordPress Toolkit. It comes standard in the Web PRO and Web HOST editions and as an optional extra with Web ADMIN and Web APP edition.

Parallels has put together a handy comparison chart of the various Plesk editions to help you select the right version.

Summary

With WordPress continuing to grow in popularity and with the volume of sites we deploy continuing to grow, any features that help us automate and streamline the management of all our sites is critical.

There’s a lot more to Plesk than what I’ve highlighted in this article, I’ve only covered the WordPress specific goodies. Plesk 12 is taking the lead by including professional WordPress management features, they’re the best I’ve seen in any hosting control panel.

Check out the Plesk 12 demo for yourself here. Or if you’re already using it, I’d love to hear your thoughts in the comments below.

But there is some problem when you install manually WP and not from the apps – you cant control the manual install .

  Original Post: sitepoint

P.s. Did some edit of my own .