We are running SonarQube Version 9.9 (build 65466), Scanner MSBuildAgent 5.13.
The Sonar Qube server is deployed in an Azure Tenant, running on a windows VM, with IIS serving as a reverse proxy to enable SSL. The configured datastore is Azure SQL Server. The connection to the server is fronted by Azure Front Door, which is implementing a Web Application Firewall. The web application firewall is utilizing the Azure Default Rule Set 2.1 (this is baselined off of the OWASP Core Rule Set 3.3.2)
I am trying to determine if there is an established set of exclusions for the Sonar Qube server for this ruleset that can be implemented.
I have searched the web and forums, and found references to issues related to Web Application Firewalls, but have not found any official guidance
Noting the above configuration, we are trying to understand the most secure way to configure our web application firewall to eliminate false positives when it inspects SonarQube traffic utilizing the OWASP Core Rule Set (OWASP) 3.3.2.
The web application firewall is a mandated defense in depth requirement by our Information Security team, and rather than starting from scratch in figuring out what exclusions are required - we would like to understand if there is any documented exclusions for SonarQube in relation to the Core Rule Set.
Is anyone aware of any documented exclusions to support SonarQube on premise behind a WAF (specifically the OWASP Core Rule Set)? Before we attempt to go through the effort of identifying and remediating the false positives, we would like to understand if the Sonar Source or the community has any guidance on this subject.
Thank you for the response. We are definitely encountering the first issue from sonar scanner, but we are also hitting some within the web administration tool. If there is no specific guidance, we will investigate the false positives we are encountering in our environment, and work through them.
I invite you to share any findings here, to help future users (and inform us, to see if some official documentation is warranted or changes in the product, or if we need to give feedback to Microsoft…).
Hi Tim!
Did you arrive at a set of exclusion rules that worked for you?
I am also in the process of setting up Sonarqube behing Azure Application Gateway with WAFv2 enabled.
Our WAF was running in prevention mode and that was blocking Sonarqube.
I have for now set the WAF to run in detection mode to get rest of the functionality setup.
But will eventually have to set the WAF back to prevention mode again.
After working with our Security team, we decided to handle these issues not with specific exclusions, but by creating a custom rule based on various request characteristics. For example, most of our agents are internal rather than Microsoft hosted agents, so we had a general rule on the WAF that just allowed known IP addresses from our internal agents through and did not execute all the detailed request inspections. My team did not have permission to modify WAF rules, and the team that did have permission to modify the rules did not want to get into detailed tuning of every 3rd party application it supported, so this is the approach we took.
There are some tradeoffs to this approach (our developers have to be on VPN to access the portal for example) - so it may not be solution for all teams.
Tim
Hi Tim,
Thanks, that’s a decent approach.
I didn’t even think of that! I will buy you a beer!
Yea, SonarQube isn’t publicly exposed for us either.
It will be used by developers over a VPN
and by the build agents that are hosted privately.
So this approach would work for us too!