Secure Your Defense-in-Depth Strategy To Combat Layer 7 DDoS Attacks
Last updated on: August 21, 2023
Qualys’ security team has observed a rapid increase in volumetric application-layer attacks on our services due to changing threat landscapes. Our security team constantly updates and enhances its defense-in-depth strategy in response to such volumetric and evolving threats.
To combat layer 7 DDoS (Distributed Denial of Service), we are adding another layer of protection beyond our perimeter, capable of handling TBs of volumetric attacks and improving the overall availability and security of our cloud platform and services. Moreover, this enhancement will allow Qualys’ security team to prevent future service disruptions.
When this enhancement goes live, you will need to do the following to access the cloud platform. These IP addresses must be whitelisted on your proxy, web gateway, or firewall:
162.159.152.21 and 162.159.153.243
During this transition of previous pod URLs under the Cloudflare L7 protection, our security/NOC teams are closely monitoring the customer traffic. Our NOC team has noticed a few of our customers are using the legacy methods for API calls (e.g., https://qualysguard.qg2.apps.qualys.com/api/2.0/fo/asset/host/vm/detection) rather than dedicated Qualys API endpoints (e.g., https://qualysapi.qg2.apps.qualys.com/api/2.0/fo/asset/host/vm/detection) which might result in API response failure post migration to Cloudflare.
Note: This change is applicable for both API v 1.0 and API v 2.0
Qualys recommends customers to use dedicated Qualys API endpoints for all API use cases. Please refer below mentioned links from our documentation.
The phased rollout of enhancements across our PODs has been extended to give customers more time to make the needed changes. We apologize for any inconvenience and new rollout dates are listed below in the table. We appreciate your patience as we aim to improve our services and provide the best possible customer experience.
Should you need more insights, refer to these commonly asked questions.
Here is where you can check your POD status: https://status.qualys.com/
POD Name | Release Date | Expected Implementation Date |
---|---|---|
UK POD 01 | 22-May-23 | 03:00 AM – 05:00 AM UTC |
AE POD 01 | 29-May-23 | 04:00 PM – 06:00 PM UTC |
IN POD 01 | 05-Jun-23 | 03:00 PM – 05:00 PM UTC |
US POD 03 | 12-Jun-23 | 06:00 AM – 08:00 AM UTC |
US POD 02 | 13-Jul-23 | 06:00 AM – 08:00 AM UTC |
US POD 01 | 13-Jul-23 | 06:00 AM – 08:00 AM UTC |
CA POD 01 | 24-Jul-23 | 06:00 AM – 08:00 AM UTC |
EU POD 02 | 31-Jul-23 | 03:00 AM – 05:00 AM UTC |
EU POD 01 | 7-Aug-23 | 03:00 AM – 05:00 AM UTC |
AU POD 01 | 14-Aug-23 | 04:00 PM – 06:00 PM UTC |
KSA POD 01 | 05-Sep-23 | 04:00 PM – 06:00 PM UTC |
If you need any further assistance, please do not hesitate to contact our support team via the support channel.
Are you going to release guidance on how this will actually work? It’s my understanding of Cloudflare that your customers shouldn’t have to make any changes with you utilizing their services. Is this change just impacting users of the UI and / or API or does it impact Agents as well?
What is the impact to customers if we don’t do this? Would this block agents from connecting to the cloud? Will it block GUI access? What about 3rd party integrations? Please explain this better so we can justify the change control on our end.
Must they be whitelisted for all ports and for TCP and UDP? any other protocols?
More information is required, please. What ports, protocols, direction?
You might find some answers to your questions in the FAQs for this change here: https://success.qualys.com/support/s/article/000007183
Agree with others, various components “access the cloud platform”, whether it be my browser to access the UI, API calls, agents etc etc. I too would like to know more about what in particular will be impacted. Thanks