We are planning to migrate our Liferay production environment to a new Virtual Machine due to recent security attacks happening on the website. Any recommended approach for a smooth and secure migration, while we have already spun up a new Azure VM, we would like to understand:
The best practices, recommended approach for migrating a production Liferay instance to a new VM with 0 or minimal downtime, considering our current Liferay license.
Whether Liferay provides any official tools or utilities for migration
We are keeping the database Azure SQL Server and the document library as is on Azure SQL Server and Azure Storage Container, respectively
Any version-specific considerations (we are currently using Liferay DXP 2024.Q1.8 with recent hotfix being hotfix-65)
Post-migration validation checklist to ensure system integrity
We would appreciate any documentation, references, or recommended procedures anyone can share. Also, please suggest if there is any other production deployment mechanism advisable to ensure easier scalability and security, given our current Azure architecture.
Single Liferay instance hosted on Azure Windows VM behind IIS [Standard E4bds v5/ 4 Core - 32 GB RAM - Windows Server 2019 Datacenter]
Azure SQL server for database [Microsoft SQL Azure (RTM) - 12.0.2000.8]
Azure storage browser for handling Document Library (DL) / file store
Additionally, please let us know if there are any common pitfalls or known issues we should be aware of during such migrations.
If you are migrating in Azure environment itself, it should basically be lift and shift approach. But you mention of security attacks, is it specifically due to improper configuration on VM side or Liferay or any other application that reside with Liferay? Basically, that is the first thing you need to address, or even though you move to a new environment you basically take the threat with you.
These are DDOS attacks with someone entering garbage values on the URL -- eg. : https:abc.com/home?q=グランドセントラル. What is the optimum and the best recommendation for this?
Ouh those are common requests in cloud environments, usually by bots(search engines) or some one running automated scans. The one you shared seems to be a search request. You can check the request IP address to see whether if its from an legitimate bot like Google trying to index your site. Update your robtos.txt (Use Liferay for reference https://www.liferay.com/robots.txt) to prevent bots from crawling certain URL's (some legitimate bots still honor robots.txt) Also, how did you conclude it was DDoS attack and do you have any WAF such as Cloudflare or Azure WAF configured?
Yes, we have WAF in place, and it is the client's IT team who has confirmed for DDoS attacks and BOTs. So they have a new VM in place with a larger capacity and better safety. So what should be our approach?
A few more questions actually. Any idea, on which layer the DDoS attacks were reported, coz WAF protects L7/application layer only ? Also, are you only migrating application server (Liferay) or Web server (Apache/NGINX) as well? Regardless you move to a larger capacity VM, you first need to identify and solve the actual problem (try updating the robots.txt first, also make sure the server accepts connections(http/s) from WAF IP ranges only and then monitor the web server logs). Also, not quite sure what you mean by better safety though.
Clients haven't shared any information yet... all they want us to move everything to a new VM. We have to migrate the liferay application server (Tomcat) AND effectively the web server layer (IIS), but not rebuilding the data layer.
From the details you provided, you are running IIS, Liferay bundle(Tomcat) on a single server [looks like elasticsearch running in embedded mode which is not recommended].
Since you are running Liferay DXP and plan to move to a new server, you might need to get a new activation key from Liferay (Liferay team can assist you with this). Also, check the tomcat configuration and liferay portal properties file for any IP/machine names references. Make sure the db and storage is reachable from the new server.
Split Web, Application and Search to different servers if possible.
Configure firewall in the web server to allow http/s traffic only from WAF IP ranges (contact your WAF provider for this)
Use a minimal linux distro such as RHEL/AlmaLinux (minimal hardened versions should be available at Azure marketplace) for the whole Liferay stack (ofcoz, in the end it comes to the teams capability. A common stack we have seen for Liferay is Apache/NGINX + Tomcat + MySQL/Postgres running on Linux + Cloudflare WAF)
In case you don’t have a commercial WAF, you can look in to mod_security, mod_qos (Apache modules) and fail2ban (Linux IPS). Please note that these can generate false positives if not configured correctly.
Hi Arun, thanks for sharing the solution. I have one more question. Since we have firewall in place and our new VM's public IP is not there. Only I can see private IP. So for our new complimentary activation key should i put the private IP of the VM or the public IP of the firewall ? It's quite confusing. I feel private IP we should put as liferay want to detect the VM. Please help me on this!!
Yes, it should be the IP address of the server running Liferay not the Firewall address. To confirm, you can reach out to the support team as you are under subscription.
Hi Arun, Thanks for your help I was able to migrate. We generated the new complementary activation key, and now our server is working on localhost:8080. Also, just wanted to know if I want the URL to https://abc.ae, I have updated the hosts in VM and mentioned properties like web.server.https.port=443, web.server.host=, web.server.protocol=http. I want to give the URL for checking in VM only to the clients before the DNS cutover. But only my localhost:8080 is showing, but not the URL(https://abc.ae). Can you let me know about this?
These are DDOS attacks with someone entering garbage values on the URL -- eg. : https:abc.com/home?q=グランドセントラル. What is the optimum and the best recommendation for this?
– ArbazSheikhOuh those are common requests in cloud environments, usually by bots(search engines) or some one running automated scans. The one you shared seems to be a search request. You can check the request IP address to see whether if its from an legitimate bot like Google trying to index your site. Update your robtos.txt (Use Liferay for reference https://www.liferay.com/robots.txt) to prevent bots from crawling certain URL's (some legitimate bots still honor robots.txt) Also, how did you conclude it was DDoS attack and do you have any WAF such as Cloudflare or Azure WAF configured?
– arunYes, we have WAF in place, and it is the client's IT team who has confirmed for DDoS attacks and BOTs. So they have a new VM in place with a larger capacity and better safety. So what should be our approach?
– ArbazSheikhA few more questions actually. Any idea, on which layer the DDoS attacks were reported, coz WAF protects L7/application layer only ? Also, are you only migrating application server (Liferay) or Web server (Apache/NGINX) as well? Regardless you move to a larger capacity VM, you first need to identify and solve the actual problem (try updating the robots.txt first, also make sure the server accepts connections(http/s) from WAF IP ranges only and then monitor the web server logs). Also, not quite sure what you mean by better safety though.
– arunClients haven't shared any information yet... all they want us to move everything to a new VM. We have to migrate the liferay application server (Tomcat) AND effectively the web server layer (IIS), but not rebuilding the data layer.
– ArbazSheikh