Changing WP Multisite Structure from subdomains to subdirectories and vice versa

WordPress Multisite Structure Change

If you’ve ever installed WordPress Multisite, you know the first thing it asks you to do is “Please, choose if you want the sites of your WordPress network to use subdomains or subdirectories. You will not be able to change this later.” From hereon, you’d need to follow different steps, depending on your choice, with no reversal. But life takes many turns and you may find yourself needing to change the model down the road, which WordPress doesn’t permit natively. What to do?

Here’s the verdict: you can change WordPress multisite from subdomains to subfolders and vice versa. But it requires some delicate actions, therefore we strongly suggest you backup your database, wp-config.php and .htaccess files, in case of any issues. Warning: Never do this in production.

Change WordPress Multisite from subdomains to subfolders

That is, going from http://site1.mydomain.com/ to http://mydomain.com/site1/.

Step 1

In our wp-config.php configuration file,  look for the line:

define( 'SUBDOMAIN_INSTALL', true );

and replace it with the following:

define( 'SUBDOMAIN_INSTALL', false );

Save changes.

Step 2

Go to the .htaccess file and look for the rules that are between #BEGIN WordPress and #END WordPress. You’ll have this:

# BEGIN WordPress

RewriteEngine On

RewriteBase /

RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin

RewriteRule ^wp-admin$ wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]

RewriteCond %{REQUEST_FILENAME} -d

RewriteRule ^ - [L]

RewriteRule ^(wp-(content|admin|includes).*) $1 [L]

RewriteRule ^(.*\.php)$ $1 [L]

RewriteRule . index.php [L]

# END WordPress

and we will replace it with:

# BEGIN WordPress

RewriteEngine On

RewriteBase /

RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin

RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]

RewriteCond %{REQUEST_FILENAME} -d

RewriteRule ^ - [L]

RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]

RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]

RewriteRule . index.php [L]

# END WordPress

Keep the changes.

Step 3

Access the database and look for the table wp_blogs, you’ll find something similar to this:

WordPress Multisite - wp_blogs table

As our intention is to move to subfolders, we must manually set all the sites of our multisite with the main domain in the domain field of the table wp_blogs. And in the path field we’ll put the name of what used to be our subdomain. This table would look like this:

WP Multisite Structure change - wp_blogs table changes
WordPress Multisite - wp_blogs table check

If you have just a few sites, you can easily do this task manually. But if you have hundreds or thousands of sites, you may want to write a small script to automate this task.

Step 4

As you know, WordPress stores all your links and so it’s necessary to have a replacement of all the URLs of all our sites. For this, you’ll need to use WP-CLI or the Search & Replace script. However, never do this manually or by making updates directly to the database, because there’s likely to be serialized information that we may lose.

Fifth step

Check that everything is working correctly.

Change WordPress Multisite from subfolders to subdomains

In case you want to pass a multisite of subfolders to subdomains, the process is exactly the same, but in reverse:

  1. For security copies of the database and the wp-config.php and .htaccess files
  2. Set the >SUBDOMAIN_INSTALL to true in wp-config.php
  3. Change the rules in the htaccess by the subdomains (more info here)
  4. Change the domain column of the wp_blogs table in all sites, establishing the subdomains of each site. Simply leave the pathfield with the bar /
  5. Through the Search & Replace or WP-CLI script, replace all URLs of the type mydomain.com/site1 with site1.mydomain.com
  6. Check that everything is working correctly.

Need a server to manage your WordPress site? Check out Plesk WordPress Edition: The right platform with all the tools you need to run a managed WordPress server – simple and secure.

Did this work for you? Let us know of any issues in the comments.

arrow icon - Plesk

How to Secure Nginx Against Malicious Bots

Nginx Security

Protective measures for a server are very important and there are several ways to protect your websites and apps from malicious bots. We’ll be looking at different bots and how they operate, and how you can use Plesk’s security measures to secure Nginx against malicious bots.

Malicious Bot Types

Nginx vs malicious bots

There are Bots that scan API keys on Git (Scanbots) and bots that download web pages. But even worse, you’ll find hackers using bots as a group of hijacked computers to take down websites (botnets). Or even send out innumerable spam emails (Spambots). Let’s take a deeper look at the latter two.  

Bots For Spamming Emails     

Spambots are special programs that crawl the internet for email addresses posted in forums, discussions boards, comments and websites. Spam generally means unwanted and unwarranted emails. They usually look for ‘mailto’ expressions (HTML used to display email IDs online), with a format such as the one below.

<ahref=“mailto:[email protected][email protected], [email protected],[email protected]&subject=Web%20News“>Email Us

Apart from mailto, others have resorted to using words, just to make it difficult for Spambots to crawl email addresses. For instance, instead of  ‘‘[email protected]’’, others prefer to use this format rather: support[at]abz[dot].com on the web. However, spam programs identify these different formats and affect users. Costing time, money and productivity.

Bots For Hijacking Computers

Malicious botnets are a network of infected computers with malicious software controlled as a group by hackers to perform distributed denial of service attacks (DDOS). Botnet makes a way for malware to enter networks and control them.

Let’s look at how attackers use botnet hijack computers by studying a click-fraud botnet which made a profit for its creators through Google search program.

Paco Redirector is a botnet trojan which affected search engines, such as Google and Bing. Here’s how.

  1. First, it infects users’ computers when they download and install fake versions of popular software
  2. Afterward, Paco changes browser’s local registry keys to include two entries to ensure malware starts at boot time.
  3. Finally, the malware implements a proxy configuration file that captures traffic and routes it through attackers command and controlled server.

How to Secure Nginx Server against malicious Bots

Due to the fact that most websites run on an Nginx server, we need to know how to secure Nginx against malicious bots. We can protect the resources running on Nginx servers by using Plesk extensions and Fail2ban.

1. Using SpamExperts Email Security Extension

Using SpamExperts Email Security Extension

SpamExperts specifically protects a hosting environment from threats like spam and viruses. It comes with an incoming filter, which separates valid emails from unsolicited ones. And also an outgoing filter, which prevents your IP address from being blacklisted since spam can be sent from your compromised account within your web infrastructure.

2. Using DDOS Deflate Interface Extension

Using DDOS Deflate Interface Extension

Hackers often use malicious bots to automatically brute-force authentication. So, you can use DDOS Deflate Interface to mitigate DDOS attacks by blocking IP addresses which exceed the configured threshold.

3. Using Fail2ban to Block Internet Bots

Fail2ban is a prevention software that protects servers like Nginx from bot attacks. You can install Fail2ban software by using the following command:

apt-get install fail2ban

Ubuntu users can make use of this command to install Fail2ban whilst Fedora and CentOS users can use the command below:

yum install fail2ban

Afterwards use the following command to create a second copy of Fail2ban local configuration file:

cp /etc/fail2ban/jail.conf /etc/fail2ban/local.conf    

Below is a screenshot of the Fail2ban jail configuration file:                   

Fail2ban jail configuration file screenshot - How to Secure Nginx Against Malicious Bots - Plesk

Search for the maxretry parameter and set it to 5. Maxretry is the parameter used to set the limit for the number of retry by a host. If the host exceeds this limit, the host is banned.

Maxretry parameter

Apart from the maxretry parameter in the configuration file, there are other parameters such as Ingoreip which is used to set the list of IP addresses which will not be banned.
Then execute the following commands to run Fail2ban package on the server:

 sudo systemctl enable fail2ban    

 sudo systemctl start fail2ban

Now let ‘s go ahead to configure Fail2ban to monitor nginx server logs.

Because these hackers use bots to perform brute-force, we can create a specific jail for login attempt by adding the following content to the jail.conf file under [nginx-http-auth]

enable = true
filter = nginx-auth
action = iptables-multiport[name=NoAuthFailures,port="http,https"]
logpath = /var/log/nginx*/*error*.log
bantime = 600
maxretry = 6[nginx-login]
enabled = true
filter = nginx-login
action = iptables-multiport[name=NoLoginFailures, port="http,https"]
logpath = /var/log/nginx*/*access*.log
bantime = 600
maxretry = 6

Finally you can create filter for the [nginx-http-auth] by navigating to the following path:

cd /etc/fail2ban/filter.d

The screenshot below shows all files inside the filter.d directory

Files inside the filter.d directory

Open the file nginx-http-auth.conf and add the following content below failregex specification.

^ \[error\] \d+#\d+: \*\d+ no user/password was provided for | authentication, client: <HOST>, server: \S+, request: "\S+ \S+ HTTP/\d+\.\d+", host: "\S+"\s*$

Save and close the nginx-auth.conf.  You can now activate your nginx jail by using the following command:

 sudo service fail2ban restart

These solutions may not be the only ways to stop bots from attacking your Nginx server.  However, you can rely on these methods to avoid the negative effects of malicious bots. Get in touch with one of our Plesk experts if you need further assistance regarding a bot attack.

How useful and straightforward was this guide? Any issues? Let us know in the comments below.

arrow icon - Plesk

Three New Web Application Threats and their Solutions

Web Application Threats

Malicious users will try to access your web application without your consent. Therefore, you should implement the necessary security features to protect yourself from new web application threats: Spoofing, information disclosure and data tampering. Let’s see how together we can mitigate threats using Plesk security tools.

1. Spoofing

Spoofing

Spoofing is one of the modern web application threats, despite security measures you may implement back-end to protect users’ credentials. It’s pretending to be someone or something other than yourself. And it can happen in many ways.

Fake User Authentication

Attackers can create a fake login page similar to that of a web application to trick users to log in. So that they can steal users’ login credentials. For spoofing, attackers can even use SET (social engineering tools) to clone a login page of a popular web application.

Fake User Authentication

Cross-Site Request Forgery (CSRF)

Cross-site request forgery tricks a web browser into executing an unwanted action. Like transferring funds from one account to another account in a web application where a user is already logged in. Attackers usually use social engineering tricks to implement CSRF by sending links to authenticated users on social media. In other words, those already logged into a web application.

Then unsuspecting users end up sending a forged request to a server on behalf of a malicious user. Though it’s quite difficult to prevent this, below is how you can mitigate cross-site request forgery.

How to Prevent Spoofing Threats

  • Implement an SSL/TLS Certificate

To defend against authentication spoofing, make sure that a web application such as banking portal has an SSL/TLS certificate in place. Plesk lets customers get these certificates for free in just a few clicks.

Spoofing Threat Prevention

Even less technical customers can use the Let’s encrypt extension on Plesk platform to easily create SSL certificates for their domains. And make it difficult for attackers to create spoofing attacks.

Generate Random Tokens  

Otherwise, to prevent forged requests, you can even use tokens to validate GET/POST requests from users. For example, to enable csrf protection in Flask-based applications, you can use the Flask extension CSRFProtect by enabling it globally.

from flask_wtf.csrf  import  CSRFProtect

csrf =  CSRFProtect(app)

Alternatively, you can use FlaskForm to prevent forgery request in flask web applications. However, the standard way of preventing CSRF threats in Java or PHP web applications is by implementing an anti-CSRF token only visible to the user’s browser and web application inside a session variable with a request. If the value of the session variable and hidden form field match, the user’s request is accepted.

2. Information Disclosure

Information Disclosure Threat

Allowing unauthenticated users to access documents restricted to only authenticated users can be defined as information disclosure. The following describe diverse ways information disclosure can take place.

IDOR – Indirect Object Reference

IDOR attack is possible when a web application provides direct access to the object based on a user-supplied input. It makes it possible for unauthorized users to access resources restricted to them. Let’s assume user A logs in to a banking web portal, then the user is redirected to the following url:

https://mybank.com/acc=00012345

In this case, 00012345 is user A’s account number. If the user wants to access other customers’ account details, user A just needs to change acc=00012345 to acc=000112367.

Therefore, the above action allows a user to access account details of another user without the owner’s consent.

How to prevent

There are different ways to prevent indirect object reference.  Another way to prevent exposure of real identifier to an internal object, like database record, is using a salted hash value to replace the identifier.

https://mybank.com/acc=00012345

https://mybank.com/acc=12eryrxhwgq

SQL Injection

SQL injection is one of the most common ways malicious users use to disclose information restricted from public view.  Attackers can send commands such as SELECT to download an entire database, CREATE to create new users in the database or UPDATE to modify accounts.

How to prevent

You can use prepared statements to prevent an attacker from changing the purpose of a query. A prepared statement separates the query from the data. Thus, the data submitted by an attacker can’t be used to modify the query. Moreover, for flask developers, you can also prevent SQL injection by using SQLAchelmy to interface with the database. It comes with features to prevent SQL injection threats.

3. Data Tampering

Data tampering is the act of intentionally modifying data through unauthorized channels. There can be two states of data: in transit and at rest. In both instances, malicious users can intercept and tamper with data. Here’s how data tampering can take place.

Parameter Pollution

Let’s assume a web application allows users to send sensitive data. Like login credentials or transact funds via GET and POST methods. In this case, an attacker can tamper with URL parameters and modify data.

To prevent parameter pollution threats in a web application, you need to encode user-supplied input whenever a user sends a GET/POST request to the backend server.

Session hijacking

Session hijacking

Session hijacking is also another type of attack where malicious users steal session cookies. Each user is assigned a session when they log into a web application. The sessionID is usually stored in a cookie. Attackers use session hijacking to modify data in transit from the client (web browser) to the web server.   

How to prevent: Generate Random Session IDs.

Moreover, Plesk also provides loads of security extensions for customers to prevent or mitigate threats not mentioned above. For example, the Sucuri Security Scanner extension on Plesk to remotely detect website security issues and weaknesses in the source code.

Sucuri Security Scanner on Plesk - Screenshot

Avoiding these new web application threats

Having said that, don’t just rely on Plesk extensions to protect web applications from web attacks. You also need to use your own secure coding practices to mitigate these threats. So, equip yourself, but stay vigilant.