Rules of AEM

How to Use Crypto Support in AEM to Encrypt/Decrypt Data? While working with AEM, The AEM dev-ops / developer team sometimes have a requirements to call third-party APIs/Services. Configurations related to these APIs/Services like username, passwords, client id/secrets, API keys are usually stored in a code repository in the form of OSGi configuration. This sensitive information should be stored encrypted rather than plain-text format. This is possible through the OOTB AEM Crypto Support bundle. This bundle provides services for encrypting and decrypting the confidential/secured data through system-wide keys (hmac and master files).   What are the Features of Crypto Support? Decryption happens at runtime. No one can decrypt the data through the UI. There’s no UI to decrypt the encrypted data. So, the information remains secure. What are hmac/master keys? Encryption/decryption happens through keys (hmac and master files). These keys get generated during the first startup of AEM instance

Crypto Support in AEM (Syncing HMAC among AEM instances) AEM OOTB provides a feature where we can encrypt the secured and confidential data through OOTB AEM Crypto Support and store it in a code repository in the form of OSGi configuration. Crypto Support is based on keys (hmac and master files) which are unique for each AEM instance. Encrypted text generated for the same plain-text string on one AEM instance will be different from another instance. This can raise alarms in cases where we have the same OSGi configuration values shared among Author and Publish instances under the same topology. For e.g. /apps/project/config.prod/com.day.cq.db.dbservice.xml Here DB password for Default DB Service will be same across all Prod AEM instances. So, in order to make sure that the same encrypted value works on all Prod instances, we will have to sync hmac and master files among Prod Author and Publish instances. Vital Points to know before HMAC SYNC  Sync of HMAC/keys will break the AEM SSL and

LOGGING OF THE X-FORWARDED-FOR HEADER The dev-opes team , struggles to find the end user IP while working / troubleshooting the DOS, D-DOS attacks/issue.  To troubleshoot such issue first thing you need to do is , log the end user IP.  Please follow the steps to do the same.  In the Apache HTTP Server's access_log, add this to the httpd.conf file in the dispatcher servers: LogFormat "%{X-Forwarded-For}i %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined LogFormat "%h %l %u %t \"%r\" %>s %b" common LogFormat "%{Referer}i -> %U" referer LogFormat "%{User-agent}i" agent In Microsoft IIS add X-Forwarded-For in the  "Advanced Logging"  configuration. That would log the correct end-user IP. Use the output showing the IP and User-Agent to analyse whether it is a malicious attack and block the offending IPs if it makes sense. 2. SET DISPATCHER.LOG'S LOG LEVEL TO DEBUG:

Prevent Denial of Service (DoS) Attacks : AEM  A denial of service (DoS) attack is an attempt to make a computer resource unavailable to its intended users. You can get more information on DDoS prevention in Apache At the dispatcher level, there are two methods of configuring to prevent DoS attacks: Use the mod_rewrite module (for example,  Apache 2.4 ) to perform URL validations (if the URL pattern rules are not too complex). Prevent the dispatcher from caching URLs with spurious extensions by using  filters .  For example, change the caching rules to limit caching to the expected mime types, such as .html .jpeg .gif .swf .js .doc .pdf .ppt .... as per your project requirement. An example configuration file is given below,  for  this includes restrictions for mime types.      When configuring Dispatcher you should restrict external access as much as possible. The      following example provides example for the minimal access for external visitors, you can refer the default file.  /fi

 SSL handshake error while replication  While configuring the SSL between author and publish servers, for a secured data flow you want to make the replication calls also over HTTPS.  Assumption -      Author and publish servers will have working SSL and sling security check should be pass.  Error -   Replication test  failed PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target   OR    Error while sending request: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated Cause -  This issue comes as replication agents try to find the certificates with exact name. and it ignores the wild card certificates.  Solution  -  Login to AEM , open replication agent which has the error. Edit the replication agent Go to transport  Make ssl to R elaxed . 

Added Security in AEM via Headers:-  In design a robust architecture AEM Architects, Developers, Infrastructure Engineers regularly come across a challenge for adding the additional security in AEM.  In this article, we will understand the key security headers which can be used in webserver and give an additional layer of security for your Publish server and content.  I have used Apache webserver for all the examples.  This article covers -  1 - X-XSS protection  2 - HTTP Strick Transport Security 3 - X-Frame Option  4 - Content Security  1- X-XSS Protection:-  X-XSS-Protection header can prevent some level of XSS (cross-site-scripting ) attacks.  Configure the x-xss-protection header to 1 in your apache httpd.conf file or Vhost file if you have for all domains as applicable.   <IfModule mod_headers.c>   <FilesMatch "\.(htm|html)$">                         #Force XSS (should be on by default in most browsers anyway)