ÃÛ¶¹ÊÓƵ

Transcript

Ensuring the security of your AEM site against a range of potential attacks is a top priority for organizations. To enhance your site’s defenses, various methods are available, and in this tutorial, our focus will be on employing the ModSecurity core rule set commonly known as CRS. What makes this approach distinct is, it’s implemented at the AEM published dispatcher level. This fortifies both the dispatcher and AEM published tiers against potentially harmful requests, whether they have passed through AEM’s built-in or your custom CDN tier. Before we proceed, let’s briefly introduce CRS, which is a component of the Open Web Application Security project, or OASP for short. OASP is also responsible for the OASP Top 10 Web Application Security Awareness document. The CRS project extends this by providing practical implementation of these Top 10 security risks through CRS rules. In this tutorial, our aim is to safeguard the weakened site from Denial of Service or DOS attacks. This will be achieved by enabling ModSecurity CRS and configuring the DOS protection CRS rule. So, let’s embark on our journey to enhance our proficiency in web security. I have cloned the AEM weakened sites project and successfully deployed both the ALL and dispatcher packages to my Rapid Development Environment, or RDE, using the aio rde install command. As evident, the weakened site is operating as expected. To simulate a DOS attack, I have developed a simple JMeter script to orchestrate 50 HTTP requests, each for the weakened home and adventurous pages within a 60-second window. To ensure these requests traverse through AEM’s built-in CDN, I have incorporated a no-cache query parameter with a unique random value for each request. Upon executing this simulated DOS attack using the JMeter script, the outcome is significant. All 100 HTTP requests result in a 200 HTTP response code, indicating effective service by the AEM published instances. Let’s proceed to the Enable ModSecurity CRS DOS protection remote tutorial branch within the weakened project. This specific branch contains essential modifications to the dispatcher module. These configuration changes are to activate ModSecurity CRS and customization of the DOS protection CRS rule. Let’s dwell into the pivotal files underlying these changes. You’ll notice that we have streamlined our CRS rules by disabling all but six of them. It is achieved by renaming the corresponding files as .conf.disabled. Now, turning our attention to specifics, the DOS protection rule file encapsulates the details of how denial-of-service attacks are defined, managed, and logged. We also have the initialization.conf file, which is responsible for initializing core rules. For targeted exceptions, the exclusion rules before CRS.conf file comes into play, allowing the incorporation of site-specific exclusions. The core of our CRS setup resides in CRS-setup.conf file. Further customizations are added through CRS-setup.custom.conf file. In our case, for this tutorial, we have tailored the DOS protection rule by setting up three variables that define the threshold for identifying bursts of requests. It is interpreted as making more than 25 requests excluding static files within 60 seconds is considered a burst, and after two bursts, meaning 50 requests, the client is blocked for 600 seconds. Moving on, the modsecurity.conf file houses essential mod security configurations, including rule inclusions, the state of the security rule engine, and logging levels. Lastly, in the vcanvhost file, the overarching mod security config file is integrated. Just remember to position this include directive outside the virtual host definition to ensure smooth operation. This wraps up the config file change review. Moving on, when working with AM as a cloud service, a recommended practice is to validate your dispatcher configuration adjustments locally prior to deployment. This validation can be performed using the validation script from the AM SDK’s dispatcher tools. Now, with the validation process successfully completed, we are clear for the subsequent deployment to the RDE. To initiate deployment, we will first generate the dispatcher artifact package using the maven command. Once the package is ready, we will deploy it to the RDE through am rde install command and specifying the artifact file we have built. With the deployment concluded, let’s ensure the vcan site renders correctly. Now, I will rerun the same DOS attack simulation JMeter script against this newly deployed dispatcher code. The view results in table JMeterListener displays a notable change. The status shifts to failed response after the defined DOS counter threshold, which is 50 requests in our case. Further analysis of the individual requests reveals a consistent occurrence of the FIO3 HTTP response code. This validation confirms that the mod security CRS rule effectively mitigated the simulated DOS attack. Now, let’s delve into the specifics of the DOS attack incident by examining the HTTP error log file within the published dispatcher. Reviewing the log entries, my current IP address is clearly logged alongside an error message and comprehensive request details. This logging mechanism provides valuable insight for further analysis. This concludes our tutorial. So, for optimal results, it’s recommended to collaborate closely with your organization’s web security team to review and configure the most suitable CRS rules for your setup. In summary, AMS Cloud Services built-in CDN plays a pivotal role in safeguarding your website. The integration of the mod security-based approach introduces an additional layer of security, allowing flexible implementation of rules and configurations tailored to your specific requirements. This cohesive integration ensures a robust and adaptable defense strategy for your AMS-side security. Thank you and let’s keep attackers at bay.