Introduction:
After upgrading our Oracle E-Business Suite environment to AD-TXK Delta 15, we encountered a front-end access issue the application URLs were not opening even though all services were up and running. This post walks through our investigation, the root cause related to ModSecurity, and how we resolved it.
Symptoms:
- EBS login page was not accessible after the
- All application tier services (adstrtal.sh) reported as running
- No errors in standard EBS logs (error_log, access_log) that directly explained the
Root Cause:
Upon deeper investigation, we examined the ModSecurity configuration file located at:
/$ORACLE_BASE/fs2/FMW_Home/webtier/instances/EBS_web_OHS2/config/OHS/EBS_web/security2. conf.
We found that the file contained restrictive deny rules that were blocking valid HTTP methods and host headers, introduced or tightened as part of the AD-TXK 15 upgrade.
Issue:
SecDefaultAction “phase:2,log,deny,status:400”
SecRule REQUEST_METHOD “!^(GET|HEAD|POST)$” “phase:1,id:100010,deny,log,status:405” SecRule REQUEST_METHOD “!^(GET|HEAD|POST|DELETE|PUT)$”
“phase:1,id:100009,deny,log,status:405″
SecRule REQUEST_HEADERS:Host
!^(preprod.com(:443)?|preprod.com.com:(8000|4443))$ phase:1,id:100017,deny,log,t:lowercase,status:400
SecDefaultAction”phase:2,log,deny,status:400,t:lowercase,t:replaceNulls,t:compressWhitespace,t:normalisePath”
Solution:
To restore EBS front-end access, we modified the ModSecurity directives from deny to allow in security2.conf.
/$ORACLE_BASE/fs2/FMW_Home/webtier/instances/EBS_web_OHS2/config/OHS/EBS_web/security2. conf
SecDefaultAction “phase:2,log,allow,status:400”
SecRule REQUEST_METHOD “!^(GET|HEAD|POST)$” “phase:1,id:100010,allow,log,status:405” SecRule REQUEST_METHOD “!^(GET|HEAD|POST|DELETE|PUT)$”
“phase:1,id:100009,allow,log,status:405”
SecRule REQUEST_HEADERS:Host
!^(prerprod.com(:443)?|preprod.com:(8000|4443))$ phase:1,id:100017,allow,log,t:lowercase,status:400
SecDefaultAction “phase:2,log,allow,status:400,t:lowercase,t:replaceNulls,t:compressWhitespace,t:normalisePath”
After making these changes, we restarted the opmn in application tier:
adopmnctl.sh stopall
adopmnctl.sh startall
The EBS front-end became accessible again, and the issue was resolved.
Important Note: AutoConfig Overwrites This File
Every time AutoConfig is executed, it can overwrite the security2.conf file and revert the allow rules back to deny.
Action Item:
After every AutoConfig run, review and reapply the allow directives in security2.conf as needed.
To prevent this from being missed:
- Add it to your post-AutoConfig checklist
- Consider automating the reconfiguration using a shell script or a version-controlled template
Conclusion:
- ModSecurity rules should be validated post-upgrade and after every AutoConfig
- Keep a backup of the working security2.conf and use automation to reapply it if
