In my previous blog, I covered securing of the communication of your authentication providers.
In this posting, we will cover the configuration of the web tier. It is your war file deployment, and probably the most exposed part of your deployment, especially if you're facing the public web.
Reduce the attack surface.
The less you have deployed, the less that can be attacked. Although the default BI install will deploy a number of components, you likely don't need them all.
You may see a list like this of war files deployed:
AdminTools - designed for running advanced direct queries against the BI repository. If you don't use this, remove it. You could also consider running it on a separate, local access only deployment.
BOE - This is the core of the BI deployment, includes CMC, BI Launchapd and OpenDocument functionality. Note that using wdeploy, you can split the CMC and BI Launchpad deployment, and put the CMC functionality on another, more locked down application server.
dswsbobje - web service used by Crystal Reports for Enterprise, Dashboard designer, and your custom applications. Again something you can remove if none of the above apply to you.
BusinessProcessBI - this is an SDK which is not needed for core functionality. If you're not deploying custom applications that make use of this, this is something you can remove from your deployment.
clientAPI - contains Crystal Reports ActiveX controls for custom application deployment. You can almost certainly remove this.
MobiServer & MobileBIService - if you are not deploying mobile, you should have no need for these.
docs - This is the default tomcat documentation. They are also available online, so there should not be any need for these to be deployed. They contain information about the version of tomcat which is not necessary.
Tomcat Security
Refer to your tomcat guide. The following is an excerpt from the tomcat guide on default web applications:
Tomcat ships with a number of web applications that are enabled by default. Vulnerabilities have been discovered in these applications in the past. Applications that are not required should be removed so the system will not be at risk if another vulnerability is discovered.
http://tomcat.apache.org/tomcat-7.0-doc/security-howto.html#Default_web_applications
Apache regularly publishes its list of fixed vulnerabilities here:
http://tomcat.apache.org/security-7.html
BI SP's regularly bundle updates of Tomcat. SAP continually monitors the bundled applications and works to deliver any updates as part of the regular maintenance cycle. We regularly monitor the security listings of tomcat, and use that to drive our updates.
If you are unable to stay on the latest support packages, you may want to consider reviewing the list of vulnerabilities and using your own update of Tomcat at least until such time when you can deploy the latest BI4.x support pack.
Tomcat User Account
The user account only needs to read files under tomcat. Create a user for the tomcat service account, give the service account "Logon as a User" rights, and read only rights on the tomcat folder.
Hide CMS Information
The single biggest benefit is usability, because users will not accidentally lose the information or put in a typo and try to connect to the wrong place.
There is no reason why someone should try to communicate anywhere other than the CMS. so set the CMS.visbile=false setting in the BIlaunchpad.properties file and the CmcApp.properties files.
Change the following:
# You can specify the default CMS machine name here
cms.default=VANTGVMWIN902:6400
# Choose whether to let the user change the CMS name
cms.visible=false
Now, there is less chance to redirect any shared secrets, credentials or other information to a server of their choosing.
Secure the communication channel - Use TLS
This should be a fairly well accepted policy already.
While terms like HTTPS and SSL are thrown around, this should really mean "TLS" behind the scenes. TLS is a newer protocol for secure communication. SSLv3 has now been rendered insecure, and you should be configuring your application servers to use the TLSv1 or higher protocol.
If you are not using SSO exclusively to logon to the BI web apps, (likely to be the case with CMC which does not support SSO), you should be encrypting the traffic and logging on with HTTPS. Otherwise, the logon credentials will be passed from the browser to Tomcat or the application server of you choice in clear text over the wire.
You've heard of POODLE? Disable SSLv3 in Tomcat while you're at it.
Do you use flash? Dashboarding, aka XCelsius
The BI install installs a file called crossdomain.xml. It's an XML document that grants a web client—such as Adobe Flash Player, Adobe Reader, etc.—permission to handle data across multiple domains.
The default is very inclusive,
<cross-domain-policy>
<site-control permitted-cross-domain-policies="all"/>
<allow-http-request-headers-from domain="*" headers="*" secure="false" />
<allow-access-from domain="*" secure="false" />
</cross-domain-policy>
and you should take steps to lock it down if you will allow hosting of flash based content.
As this configuration file is completely outside of the SAP BI control, please refer to Adobe's documentation for crossdomain.xml
Protect Credentials
If you're setting up Active Directory SSO, make sure you're not storing the credentials as a java option, but protect the password with a keytab instead.
Don't do this (notice the wedgetail.idm.sso password in clear text):
Do this instead:
1. Create a keytab with the ktpass command
The details for this are contained in the whitepaper attached to sap note http://service.sap.com/sap/support/notes/1631734
The whitepaper is a must for anyone setting up AD for the first time.
2. Copy the.keytab file to the c:\windows\ directory of the application server
3. Add the following line to C:\Program Files (x86)\SAP BusinessObjects\Tomcat\webapps\BOE\WEB-INF\config\custom\global.properties idm.keytab=C:/WINDOWS/<your keytab file name>
If you're using Trusted Authentication, make sure you secure the shared secret file, so that only the process that your web application server is running as can access it. Consider using OS file level encryption to further lock this file down.
Web Application Container Server
If you are using the WACS, to host your restful web services, or possibly the CMC, the configuration for secure communication is done through server properties in the CMC.
What about Cross Site Scripting, SQL Injection, OWASP TOP 10?! IS IT SAFE!!??
SAP has a very strict release criteria, and a secure development cycle implemented. Testing includes, and is not limited to, static code scanning, dynamic analysis tools, manual penetration testing and security architecture reviews. You can find out more about our security processes here:
Conclusion
The secure approach is to treat your internal network that all your end users access as compromised. Just think of the latest Sony attack as an example, to see the value of encrypting the communication channels.
Additionally, leveraging firewalls to block off parts of the network to would be attackers is also valuable. Firewalls and server communication are covered in part 3.
Feel free to add you comments/questions on other areas, the blog will get updated with any additional bits that may have been missed here.
- SAP Managed Tags:
7 Comments
