Pilot light with reserved capacity: How to optimize DR cost using On-Demand Capacity Reservations

Post Syndicated from Antoine Boucherie original https://aws.amazon.com/blogs/architecture/pilot-light-with-reserved-capacity-how-to-optimize-dr-cost-using-on-demand-capacity-reservations/

For digital enterprises to remain competitive, resilience is essential for maintaining reliability and building customer trust. End users expect applications to be available 24 hours a day, leading companies to develop increasingly sophisticated methods to provide continuous operation of critical services. Some companies, such as financial services companies, have to meet regulatory requirements such as Digital Operational Resilience Act (DORA) and are expected to manage the risk of outsourcing critical applications. They must design for high availability and plan for potential impairments. By proactively planning for potential disruptions, they’re not just mitigating risks – they’re building trust and delivering unparalleled value to their customers.

When assessing your own applications, you should define a set of objectives, perform a business impact analysis and a risk assessment. This way, you can estimate the impact to the business if the application isn’t available. This results in categorization of the applications and influence their design according to the AWS resilience lifecycle framework. Each application is given a specific Recovery Point Objective (RPO) and Recovery Time Objective (RTO), depending on its criticality for the business.

Not all applications fall in the most critical category. You allocate resources according to the results of the assessment and make trade-offs when designing applications. For example, you’ll have a more stringent RTO and RPO for—and be willing to spend more time and money on—a critical application than on a less critical application. The challenge becomes how to minimize the risk of breaching a specific RTO while optimizing for resources, such as cost and operational complexity.

At AWS, we provide guidance through the Well-Architected Framework and specifically within the Reliability pillar. Disruption can happen at several levels, and we recommend that you explore and prepare for four types of disruptions in the AWS Resilience Hub: application, infrastructure, Availability Zone, and AWS Region.

We recommend that you use managed services and make sure that all production workloads are designed to take advantage of multiple Availability Zones in AWS Regions. If your application also needs to be protected against the unlikely risk of Regional impairment, you should consider a multi-Region disaster recovery (DR) strategy.

You can select from several DR strategies: backup and restore, pilot light, warm standby, and multi-site active-active:

  • Backup and restore – This strategy might not provide the necessary RPO or RTO required for a highly critical application.
  • Multi-site active-active – This strategy increases significantly the cost and operational complexity of your application.
  • Pilot light – This strategy allows for a RPO or RTO in the tens of minutes by having the data asynchronously copied to the secondary Region and ready to be accessed. However, unlike a warm standby, the application servers aren’t deployed and aren’t ready to serve traffic. The pilot light strategy allows for a lower cost but brings a risk that you might not be able to provision the compute capacity you need when you want to fail over to the secondary Region, especially if you require a specific instance type.

In this post, we explore an intermediate strategy between the pilot light and the warm standby strategies: pilot light with reserved capacity. You can use this strategy to reserve compute capacity in a secondary Region while also limiting cost.

The following diagram illustrates where the pilot light with reserved capacity solution lies in the spectrum of disaster recovery strategies.

spectrum of disaster recovery strategies

Reserving capacity, on demand

On-Demand Capacity Reservations were launched in 2018. They make it possible to reserve capacity in the Availability Zone of your choice without a long-term contract. You have the flexibility to create, modify, or cancel reservations at your discretion. It’s especially well-suited if your application is dependent on a specific instance type or size.

Optimizing the cost of On-Demand Capacity Reservations with a Savings Plan

On-Demand Capacity Reservations is a reservation mechanism and doesn’t require a commitment. However, you can optimize your spending by combining the capacity reservation with an AWS Savings Plan. By using Savings Plans, you can achieve up to a 72% discount, a very significant cost reduction for DR instances that have to stay available all year long.

Optimizing the cost of On-Demand Capacity Reservations by sharing Capacity Reservations

To further optimize the cost, you can use your reserved capacity in another account when you don’t need it for DR.

Here’s an example in which we share On-Demand Capacity Reservations with our development and test account:

We have a three-tier application running in production in a primary AWS Region. This application is composed of a load balancer forwarding traffic to a fleet of application servers running on Amazon Elastic Compute Cloud (Amazon EC2) instances, backed by an Amazon Relational Database Service (Amazon RDS) database. All services used by this application are configured to use multiple Availability Zones in this primary Region.

We use the pilot light strategy, so the application data is being replicated to the disaster recovery environment in a secondary Region using Amazon RDS cross-Region read replicas. However, the load balancer and EC2 services aren’t running in DR to limit cost and operational complexity. Following best practices, each environment is running in a different AWS account.

The following diagram illustrates the pilot light strategy setup for our example.

pilot light strategy setup for our example

To reserve capacity in case of failover to the secondary Region, we create an On-Demand Capacity Reservation in the DR account, according to our baseline compute capacity. Because we don’t need this capacity until we fail over the application from the primary to the secondary Region, we share those On-Demand Capacity Reservations with a development and test account hosting our nonproduction environment in the secondary Region. On-Demand Capacity Reservations are Availability Zone specific (and hence Region specific) and can be shared with either AWS accounts or AWS Organizations using AWS Resource Access Manager (AWS RAM).

Best practices are to share those On-Demand Capacity Reservations with a nonproduction organizational unit (OU) within an organization or to directly share with the account(s) hosting the testing environments (for example, user acceptance testing or preproduction). Those environments are usually very similar to the production account in baseline sizing, in order to perform load and performance testing. This is an important point: you want to be able to retrieve those On-Demand Capacity Reservations when needed without impacting other critical applications.

The following diagram illustrates the Capacity Reservations sharing with the development and test account.

Capacity Reservation sharing with development and test account

If an impairment affects our production environment in the primary Region, we can trigger failover to the secondary Region. To reclaim capacity, we need to terminate the EC2 instances running in our development and test account. Capacity becomes available nearly immediately after these instances are successfully terminated. Separately, we can also stop the sharing of On-Demand Capacity Reservations to make sure that the development and test account can’t consume that capacity again. Know that merely unsharing your reservation without terminating development and test instances might not result in complete or immediate capacity retrieval. This is because when you unshare an On-Demand Capacity Reservation, the instances in the consumer account continue to run, and capacity is only returned to the owner account if additional capacity is available in the Amazon EC2 service on-demand pool.

The following diagram illustrates the failover to the DR environment in a secondary Region.

cancellation of the capacity reservations sharing

Steps

Here is a possible approach to take advantage of On-Demand Capacity Reservations to reduce the application’s total infrastructure cost:

  1. Calculate the baseline compute capacity necessary for the DR environment in the secondary Region in the event of failover, including the compute that might already be running in this secondary Region for data stores (for example, a Kafka broker running on Amazon EC2). How much vCPU and RAM is required or what are the exact EC2 instances necessary to host the whole application in case of failover of the production from the primary to the secondary Region.
  2. Create an On-Demand Capacity Reservation for the exact EC2 instances that the application need as a baseline in the DR account. Capacity Reservation Fleet is also a possible choice to reserve capacity across multiple instance types, which is often the case for Amazon Elastic Kubernetes Service (Amazon EKS) or Amazon Elastic Container Service (Amazon ECS) clusters, for example. Creating a Capacity Reservation Fleet will create multiple Capacity Reservations that can be shared independently. It’s also recommended to apply for Savings Plans on those On-Demand Capacity Reservations to save up to 72%.
  3. Share those On-Demand Capacity Reservations from the DR account to one or several accounts, depending on your need. In our example, we share the On-Demand Capacity Reservations with the development and test account, effectively allowing the development and test environment to use compute capacity that has already been reserved.
  4. In case of impairment in the primary Region, terminate the development and test instances first and then stop the On-Demand Capacity Reservation sharing The DR account will recover those reservations. If you want to keep the development and test instances, you will be charged at the on-demand rate.
  5. Redeploy in an automated manner the application in the DR account on new EC2 instances behind a load balancer.

Benefits

By purchasing On-Demand Capacity Reservations in the DR account, you make sure that you always have Amazon EC2 capacity access when required and for as long as you need it. By sharing those On-Demand Capacity Reservations with another AWS account or organization, you can share the cost of the application’s compute capacity with other environments, reducing your application’s total cost of ownership. The additional cost of the DR instances can even reach zero, if your instances are completely consumed by nonproduction environments such as development and testing.

DR savings over On-Demand
Compute Savings Plan – 1 year, no upfront Around 27% (for example, for m7i instance)
Compute Savings Plan – 3 years, all upfront Up to 66%
Instance Savings Plan – 3 years, all upfront Up to 72%
Reservation shared and consumed 100% by development and test environment Up to 100%

Limits

Although you can reserve DR capacity at a minimal cost using the pilot light with reserved capacity solution, there are some limits to keep in mind.

Firstly, we advise looking at this solution only if the Recovery Time Objective of the application, in case of Regional disruption, is in hours because you need to take into account the time needed to:

  • Detect the impairment in the primary Region.
  • Trigger the failover procedure.
  • Terminate the used instances to retrieve capacity (estimated time in minutes)
  • Stop the On-Demand Capacity Reservations sharing and automatically retrieve them in the DR account (estimated time in minutes).
  • Launch the compute infrastructure with the necessary application software in the DR account. You need to make sure that it matches the On-Demand Capacity Reservations according to the criteria used (open or targeted)

If your application requires a lower RTO, we recommend exploring the warm standby strategy.

Secondly, this strategy can only be used for application servers running EC2 instances and ECS or EKS clusters on EC2 because On-Demand Capacity Reservations aren’t available for managed services such as AWS Fargate or AWS Lambda. For those managed services, we recommend having them up and running like in a warm standby strategy, with a minimum baseline capacity that you’re comfortable with.

Thirdly, it requires some nonproduction development and test usage in the selected secondary Region to use the shared On-Demand Capacity Reservation.

Finally, it’s important to consider that this solution brings some complexity and extra operational work. You should plan well ahead, automate the operational tasks where possible, but most importantly, regularly test that the failover of the application works according to plan. We encourage you to perform your own game days to support your operational resilience.

Deciding whether this strategy is a good fit for your application will ultimately be a decision based on your business and regulatory requirements.

Conclusion

In this post, we explained how to reserve capacity in a secondary Region using On-Demand Capacity Reservations. We highlighted how cost can be optimized using Savings Plans and by sharing reserved capacity with noncritical workloads. We saw how we can recover that capacity for the DR environment, in the event of a disaster, to allow the application to continue to serve end users. We looked at the benefits and limits of the pilot light with reserved capacity solution and the necessary steps to put it in place.

About the Authors

Simplify allowlist management and lock down origin access with Cloudflare Aegis

Post Syndicated from Mia Malden original https://blog.cloudflare.com/aegis-deep-dive/

Today, we’re taking a deep dive into Aegis, Cloudflare’s origin protection product, to help you understand what the product is, how it works, and how to take full advantage of it for locking down access to your origin. We’re excited to announce the availability of Bring Your Own IPs (BYOIP) for Aegis, a customer-accessible Aegis API, and a gradual rollout for observability of Aegis IP utilization.

If you are new to Cloudflare Aegis, let’s take a step back and understand the product’s purpose and security benefits, process, and how it came to be. 

Origin protection then…

Allowlisting a specific set of IP addresses has long existed as one of the simplest ways of restricting access to a server. This firewall mechanism is a starting state that just about every server supports. As we built Cloudflare’s network, one of the first features that customers requested was the ability to restrict access to their origin, so only Cloudflare could make requests to it. Back then, the most natural way to support this was to tell our customers which IP addresses belong to us, so they could allowlist those in their origin firewall. To that end, we have published our IP address ranges, providing an easy configuration to ensure that all traffic accessing your origin comes from Cloudflare’s network.


However, Cloudflare’s IP ranges are used across multiple Cloudflare services and customers, so restricting access to the full list doesn’t necessarily give customers the security benefit they need. With the frequency and scale of IP-based and DDoS attacks every day, origin protection is absolutely paramount. Some customers have the need for more stringent security precautions to ensure that traffic is only coming from Cloudflare’s network and, more specifically, only coming from their zones within Cloudflare.

Origin protection now…

Cloudflare has built out additional services to lock down access to your origin, like authenticated origin pulls (mTLS) and Cloudflare Tunnels, that no longer rely on IP addresses as an indicator of identity. These are part of a global effort towards Zero Trust security: whereas the Internet used to operate under a trust-but-verify model, we aim to operate as nothing is trusted, and everything is verified. 

Having non-ephemeral IP addresses — upon which the firewall allowlist mechanism relies — does not quite fit the Zero Trust system. Although mTLS and similar solutions present a more modern approach to origin security, they aren’t always feasible for customers, depending on their hardware or system architecture. 

We launched Cloudflare Aegis in March 2023 for customers seeking an intermediary security solution. Aegis provides a dedicated IP address, or set of addresses, from which Cloudflare sends requests, allowing you to further lock down your origin’s layer 3 firewall. Aegis also simplifies management by only requiring you to allowlist a small number of IP addresses.


Normally, Cloudflare’s publicly listed IP ranges are used to egress from Cloudflare’s network to the customer origin. With these IP addresses distributed across Cloudflare’s network, the customer traffic can egress from many servers to the customer origin.


With Aegis, a customer does not necessarily have an Aegis IP address on every server if they are using IPv4. That means requests must be routed through Cloudflare’s network to a server where Aegis IP addresses are present before the traffic can egress to the customer origin. 


How requests are routed with Aegis

A few terms, before we begin:

  • Anycast: a technology where each of our data centers “announces” and can handle the same IP address ranges

  • Unicast: a technology where each server is given its own, unique unicast IP address

Dedicated egress Aegis IPs are located in a particular set of specific data centers. This list is handpicked by the customer, in conversation with Cloudflare, to be geographically close to their origin servers for optimal security and performance in tandem. 

Aegis relies on a technology called soft-unicasting, which allows us to share a /32 egress IPv4 amongst many servers, thereby enabling us to spread a single subnet across many data centers. Then, the traffic going back from the origin servers (the return path) is routed to their closest data center. Once in Cloudflare’s network, our in-house L4 XDP-based load balancer, Unimog, ensures that the return packets make it back to the machine that connected to the origin servers at the start.

This supports fast, local, and reliable egress from Cloudflare’s network. With this configuration, we essentially use Anycast at the BGP layer before using an IP and port range to reach a specific machine in the correct data center. Across Cloudflare’s network, we use a significant range of egress IPs to cover all data centers and machines. Since Aegis customers only have a few IPv4 addresses, the range is limited to a few data centers rather than Cloudflare’s entire egress IP range.


The capacity issue

Every IP address has 65,535 ports. A request egresses from exactly one port on the Aegis IP address to exactly one port on the origin IP address. 

Each TCP request consists of a 4-way tuple that contains:

  1. Source IP address

  2. Source port

  3. Destination IP address

  4. Destination port

A UDP request can also consist of a 4-way tuple (if it’s connected) or a 2-way tuple (if it’s unconnected), simply including a bind IP address and port. Aegis supports both TCP and UDP traffic — in either case, the requests rely upon IP:port pairings between the source and destination. 

When a request reaches the origin, it opens a connection, through which data can pass between the source and destination. One source port can sustain multiple connections at a time, only if the destination ip:ports are different. 

Normally at Cloudflare, an IP address establishes connections to a variety of different destination IP ports or addresses to support high traffic volumes. With Aegis, that is no longer the case. The challenge with Aegis IP capacity is exactly that: all the traffic is egressing to the same (or a small set of) origin IP address(es) from the same (or a small set of) source IP address(es). That means Aegis IP addresses have capacity constraints associated with them.

The number of concurrent connections is the number of simultaneous connections for a given 4-way tuple. Between one client and one server, the volume of concurrent connections is inherently limited by the number of ports on an IP address to 65,535 — each source ip:port can only support a single outbound connection per destination IP:port. In practice, that maximum number of concurrent connections is often lower due to assignments of port ranges across many servers and imperfect load distribution. 

For planning purposes, we use an estimate of ~80% of the IP capacity (the volume of concurrent connections a source IP address can support to a destination IP address) to protect against overload, in case of traffic spikes. If every port on an IP address is maintaining a concurrent connection, that address would reach and exceed capacity — it would be overloaded with port usage exhaustion. Requests may then be dropped since no new connections can be established. To build in resiliency, we only plan to support 40k concurrent connections per Aegis IP address per origin.

Aegis with IPv6

Each customer who onboards with Cloudflare Aegis receives two /64 prefixes to be globally allocated and announced. That means, outside of Cloudflare’s China Network, every Cloudflare data center has hundreds or even thousands of addresses reserved for egressing your traffic directly to your origin. Without Aegis, any data center in Cloudflare’s Anycast network can serve as a point of egress – so we built Aegis with IPv6 to preserve that level of resiliency and performance. The sheer scale of IPv6, with its available address space, allows us to cushion Aegis’ capacity to a point far beyond any reasonable concern. Globally allocating and announcing your Aegis IPv6 addresses maintains all of Cloudflare’s functionality as a reverse proxy without inducing additional friction.

Aegis with IPv4

Although using IPv6 with Aegis facilitates the best possible speed and resiliency for your traffic, we recognize the transition from IPv4 to IPv6 can be challenging for some customers. Moreover, some customers prefer Aegis IPv4 for granular control over their traffic’s physical egress locations. Still, IPv4 space is more limited and more expensive — while all Cloudflare Aegis customers simply receive two dedicated /64s for IPv6, enabling Aegis with IPv4 requires a touch more tailoring. When you onboard to Aegis, we work with you to determine the ideal number of IPv4 addresses for your Aegis configuration to maintain optimal performance and resiliency, while also ensuring cost efficiency. 

Naturally, this introduces a bottleneck — whereas every Cloudflare data center can serve as a point of egress with Aegis IPv6, only a small fraction will have that capability with Aegis IPv4. We aim to mitigate this impact by careful provisioning of the IPv4 addresses. 

Now that BYOIP for Aegis is supported, you can also onboard an entire IPv4 /24 prefix or IPv6 /64 for Aegis, allowing for a cost-effective configuration with a much higher volume of capacity.

When we launched Aegis, each IP address was allocated to one data center, requiring at least two IPv4 addresses for appropriate resiliency. To reduce the number of IP addresses necessary in your layer 3 firewall allowlist, and to manage the cost to the customer of leasing IPs, we expanded our Aegis functionality so that one address can be announced from up to four data centers. To do this, we essentially slice the available IP port range into four subsets and provision each at a unique data center. 

A quick refresher: when a request travels through Cloudflare, it first hits our network via an ingress data center. The ingress data center is generally near the eyeball, who is sending the request. Then, the request is routed following BGP – or Argo Smart Routing, when enabled – to an exit, or egress, data center. The exit data center will generally fall in close geographic proximity to the request’s destination, which is the customer origin. This mitigates latency induced by the final hop from Cloudflare’s network to your origin.

With Aegis, the possible exit data centers are limited to the data centers in which an Aegis IP address has been allocated. For IPv6, this is a non-issue, since every data center outside our China Network is covered. With IPv4, however, the exit data centers are limited to a much smaller number (4 x the number of Aegis IPs). Aegis IP addresses are allocated, then, to data centers in close geographic proximity to your origin(s). This maximizes the likelihood that whichever data centers would ordinarily have been selected as the egress data center are already announcing Aegis IP addresses. Theoretically, no extra hop is necessary from the optimal exit data center to an Aegis-enabled data center – they are one and the same. In practice, this cannot be guaranteed 100% of the time because optimal routes are ever-changing. We recommend IPv6 to ensure optimal performance because of this possibility of an extra hop with IPv4.

A brief comparison, to summarize:

Aegis IPv4

Aegis IPv6

Physical points of egress

4 physical data center sites (1-2 cities near origin) per IP address

All 300+ Cloudflare locations (excluding China network)

Capacity

One IPv4 address per 40,000 concurrent connections per origin

Two /64 prefixes for all Aegis customers (>36 quintillion IP addresses)

~50,000x capacity of IPv4 config

Pricing model

Monthly fee based on IPv4 leases or BYOIP for Aegis prefix fees

Included with product purchase or BYOIP for Aegis prefix fees

Now, with Aegis analytics coming soon, customers can monitor and manage their IP address usage by Cloudflare data centers in aggregate. Every Cloudflare data center will now run a service with the sole purpose of calculating and reporting Aegis usage for each origin IP:port at regular intervals. Written to an internal database, these reports will be aggregated and exposed to customers via Cloudflare’s GraphQL Analytics API. Several aggregation functions will be available, such as average usage over a period of time, or total summed usage.

This will allow customers to track their own IP address usage to further optimize the distribution of traffic and addresses across different points of presence for IPv4. Additionally, the improved observability will support customer-created notifications via RSS feeds such that you can design your own notification thresholds for port usage.

How Aegis benefits from connection reuse & coalescence

As we mentioned earlier, requests egress from the source IP address to the destination IP address only when a connection has been established between the two. In early Internet protocols, requests and connections were 1:1. Now, once that connection is open, it can remain open and support hundreds or thousands of requests between that source and destination via connection reuse and connection coalescing. 

Connection reuse, implemented by HTTP/1.1, allows for requests with the same source ip:port and destination IP:port to pass through the same connection to the origin. A “simple” website by modern standards can send hundreds of requests just to load initially; by streamlining these into a single origin connection, connection reuse reduces the latency derived from constantly opening and closing new connections between two endpoints. Still, any request from a different domain would need to create a new, unique connection to communicate with the origin. 

As of HTTP/2, connection coalescing can group requests from different domains into one connection if the requests have the same destination IP address and the server certificate is authoritative for both domains. Depending on the traffic patterns routing from the eyeball to an Aegis IP address, the volume of connection reuse & coalescence can vary. One connection most likely facilitates the traffic of many requests, but each connection requires at least one request to open it in the first place. Therefore, the worst possible ratio between concurrent connections and concurrent requests is 1:1. 

In practice, a 1:1 ratio between connections and requests almost never happens. Connection reuse and connection coalescence are very common but highly variable, due to sporadic traffic patterns. We size our Aegis IP address allocations accordingly, erring on the conservative side to minimize risk of capacity overload. With the proper number of dedicated egress IP addresses and optimal allocation to Cloudflare points of presence, we are able to lock down your origin with IPv4 addresses to block malicious layer 7 traffic and reduce overall load to your origin. 

Connection reuse and coalescence pairs well with Aegis to reduce load on the origin’s side as well. Because a request can be reused if it comes from the same source IP:port and shares a destination IP:port, routing traffic from a reduced number of source IP addresses (Aegis addresses, in this case) to your origin facilitates a smaller number of total connections. Not only does this improve security by limiting open connection access, but also it reduces latency since fewer connections need to be opened. Maintaining fewer connections is also less resource intensive — more connections means more CPU and more memory handling the inbound requests. By reducing the number of connections to the origin through reuse and coalescence, HTTP/2 lowers the overall cost of operation by optimizing resource usage. 

Recap and recommendations

Cloudflare Aegis locks down your origin by restricting access via your origin’s layer 3 firewall. By routing traffic from Cloudflare’s network to your origin through dedicated egress IP addresses, you can ensure that requests coming from Cloudflare are legitimate customer traffic. With a simple flip-switch configuration — allow listing your Aegis IP addresses in your origin’s firewall — you can block excessive noise and bad actors from access. So, to help you take full advantage of Aegis, let’s recap:

  • Concurrent connections can be, at worst, a 1:1 ratio to concurrent requests.

  • Cloudflare bases our IP address usage recommendations on 40,000 concurrent connections to minimize risk of capacity overload.

  • Each Aegis IP address supports an estimated 40,000 concurrent connections per origin IP address.

Additionally, we’re excited to now support:

For customers leasing Cloudflare-owned Aegis IP addresses, the Aegis API will allow you to enable and disable Aegis on zones within your parent account (parent being the account which owns the IP lease). If you deploy your Aegis IP addresses across multiple accounts, you’ll still rely on Cloudflare’s account team to enable and disable Aegis on zones within those additional accounts.

For customers who leverage BYOIP for Aegis, the Aegis API will allow you to enable and disable Aegis on zones within your parent account and within any accounts to which you delegate prefix permissions. We recommend BYOIP for Aegis for improved configurability and cost efficiency. 

BYOIP

Cloudflare-owned IPs

Enable Aegis on zones on parent account

✓

✓

Enable Aegis on zones beyond parent account

✓

✗

Disable Aegis on zones on parent account

✓

✓

Disable Aegis on zones beyond parent account

✓

✗

Access Aegis analytics via the API

✓

✓

With the improved Aegis observability, all Aegis customers will be able to monitor their port usage by IP address, account, zone, and data centers in aggregate via the API. You will also be able to ingest these metrics to configure your own, customizable alerts based on certain port usage thresholds. Alongside the new configurability of Aegis, this visibility will better equip customers to manage their Aegis deployments themselves and alert us to any changes, rather than the other way around.

We also have a few adjacent recommendations to optimize your Aegis configuration. We generally encourage the following best practices for security hygiene for your origin and traffic as well.

  1. IPv6 Compatibility: if your origin(s) support IPv6, you will experience even better resiliency, performance, and availability with your dedicated egress IP addresses at a lower overall cost.

  2. HTTP/2 or HTTP/3 adoption: by supporting connection reuse and coalescence, you will reduce overall load to your origin and latency in the path of your request.

  3. Multi-level origin protection: while Aegis protects your origin at the application level, it pairs well with Access and CNI, Authenticated Origin Pulls, and/or other Cloudflare products to holistically protect, verify, and facilitate your traffic from edge to origin.

If you or your organization want to enhance security and lock down your origin with dedicated egress IP addresses reach out to your account team to onboard today.

Introducing Cloudy, Cloudflare’s AI agent for simplifying complex configurations

Post Syndicated from Alex Dunbrack original https://blog.cloudflare.com/introducing-ai-agent/

It’s a big day here at Cloudflare! Not only is it Security Week, but today marks Cloudflare’s first step into a completely new area of functionality, intended to improve how our users both interact with, and get value from, all of our products.

We’re excited to share a first glance of how we’re embedding AI features into the management of Cloudflare products you know and love. Our first mission? Focus on security and streamline the rule and policy management experience. The goal is to automate away the time-consuming task of manually reviewing and contextualizing Custom Rules in Cloudflare WAF, and Gateway policies in Cloudflare One, so you can instantly understand what each policy does, what gaps they have, and what you need to do to fix them.

Meet Cloudy, Cloudflare’s first AI agent

Our initial step toward a fully AI-enabled product experience is the introduction of Cloudy, the first version of Cloudflare AI agents, assistant-like functionality designed to help users quickly understand and improve their Cloudflare configurations in multiple areas of the product suite. You’ll start to see Cloudy functionality seamlessly embedded into two Cloudflare products across the dashboard, which we’ll talk about below.

And while the name Cloudy may be fun and light-hearted, our goals are more serious: Bring Cloudy and AI-powered functionality to every corner of Cloudflare, and optimize how our users operate and manage their favorite Cloudflare products. Let’s start with two places where Cloudy is now live and available to all customers using the WAF and Gateway products.

WAF Custom Rules

Let’s begin with AI-powered overviews of WAF Custom Rules. For those unfamiliar, Cloudflare’s Web Application Firewall (WAF) helps protect web applications from attacks like SQL injection, cross-site scripting (XSS), and other vulnerabilities. 

One specific feature of the WAF is the ability to create WAF Custom Rules. These allow users to tailor security policies to block, challenge, or allow traffic based on specific attributes or security criteria.

However, for customers with dozens or even hundreds of rules deployed across their organization, it can be challenging to maintain a clear understanding of their security posture. Rule configurations evolve over time, often managed by different team members, leading to potential inefficiencies and security gaps. What better problem for Cloudy to solve?


Powered by Workers AI, today we’ll share how Cloudy will help review your WAF Custom Rules and provide a summary of what’s configured across them. Cloudy will also help you identify and solve issues such as:

  • Identifying redundant rules: Identify when multiple rules are performing the same function, or using similar fields, helping you streamline your configuration.

  • Optimising execution order: Spot cases where rules ordering affects functionality, such as when a terminating rule (block/challenge action) prevents subsequent rules from executing.

  • Analysing conflicting rules: Detect when rules counteract each other, such as one rule blocking traffic that another rule is designed to allow or log.

  • Identifying disabled rules: Highlight potentially important security rules that are in a disabled state, helping ensure that critical protections are not accidentally left inactive.

Cloudy won’t just summarize your rules, either. It will analyze the relationships and interactions between rules to provide actionable recommendations. For security teams managing complex sets of Custom Rules, this means less time spent auditing configurations and more confidence in your security coverage.

Available to all users, we’re excited to show how Cloudflare AI Agents can enhance the usability of our products, starting with WAF Custom Rules. But this is just the beginning.

Cloudflare One Firewall policies


We’ve also added Cloudy to Cloudflare One, our SASE platform, where enterprises manage the security of their employees and tools from a single dashboard.

In Cloudflare Gateway, our Secure Web Gateway offering, customers can configure policies to manage how employees do their jobs on the Internet. These Gateway policies can block access to malicious sites, prevent data loss violations, and control user access, among other things.

But similar to WAF Custom Rules, Gateway policy configurations can become overcomplicated and bogged down over time, with old, forgotten policies that do who-knows-what. Multiple selectors and operators working in counterintuitive ways. Some blocking traffic, others allowing it. Policies that include several user groups, but carve out specific employees. We’ve even seen policies that block hundreds of URLs in a single step. All to say, managing years of Gateway policies can become overwhelming.

So, why not have Cloudy summarize Gateway policies in a way that makes their purpose clear and concise?

Available to all Cloudflare Gateway users (create a free Cloudflare One account here), Cloudy will now provide a quick summary of any Gateway policy you view. It’s now easier than ever to get a clear understanding of each policy at a glance, allowing admins to spot misconfigurations, redundant controls, or other areas for improvement, and move on with confidence.

Built on Workers AI

At the heart of our new functionality is Cloudflare Workers AI (yes, the same version that everyone uses!) that leverages advanced large language models (LLMs) to process vast amounts of information; in this case, policy and rules data. Traditionally, manually reviewing and contextualizing complex configurations is a daunting task for any security team. With Workers AI, we automate that process, turning raw configuration data into consistent, clear summaries and actionable recommendations.

How it works

Cloudflare Workers AI ingests policy and rule configurations from your Cloudflare setup and combines them with a purpose-built LLM prompt. We leverage the same publicly-available LLM models that we offer our customers, and then further enrich the prompt with some additional data to provide it with context. For this specific task of analyzing and summarizing policy and rule data, we provided the LLM:

  • Policy & rule data: This is the primary data itself, including the current configuration of policies/rules for Cloudy to summarize and provide suggestions against.

  • Documentation on product abilities: We provide the model with additional technical details on the policy/rule configurations that are possible with each product, so that the model knows what kind of recommendations are within its bounds.

  • Enriched datasets: Where WAF Custom Rules or CF1 Gateway policies leverage other ‘lists’ (e.g., a WAF rule referencing multiple countries, a Gateway policy leveraging a specific content category), the list item(s) selected must be first translated from an ID to plain-text wording so that the LLM can interpret which policy/rule values are actually being used.

  • Output instructions: We specify to the model which format we’d like to receive the output in. In this case, we use JSON for easiest handling.

  • Additional clarifications: Lastly, we explicitly instruct the LLM to be sure about its output, valuing that aspect above all else. Doing this helps us ensure that no hallucinations make it to the final output.

By automating the analysis of your WAF Custom Rules and Gateway policies, Cloudflare Workers AI not only saves you time but also enhances security by reducing the risk of human error. You get clear, actionable insights that allow you to streamline your configurations, quickly spot anomalies, and maintain a strong security posture—all without the need for labor-intensive manual reviews.

What’s next for Cloudy

Beta previews of Cloudy are live for all Cloudflare customers today. But this is just the beginning of what we envision for AI-powered functionality across our entire product suite.

Throughout the rest of 2025, we plan to roll out additional AI agent capabilities across other areas of Cloudflare. These new features won’t just help customers manage security more efficiently, but they’ll also provide intelligent recommendations for optimizing performance, streamlining operations, and enhancing overall user experience.

We’re excited to hear your thoughts as you get to meet Cloudy and try out these new AI features – send feedback to us at [email protected], or post your thoughts on X, LinkedIn, or Mastodon tagged with #SecurityWeek! Your feedback will help shape our roadmap for AI enhancement, and bring our users smarter, more efficient tooling that helps everyone get more secure.


Watch on Cloudflare TV

Making Application Security simple with a new unified dashboard experience

Post Syndicated from Michael Tremante original https://blog.cloudflare.com/new-application-security-experience/

Over the years, we have framed our Application Security features against market-defined product groupings such as Web Application Firewall (WAF), DDoS Mitigation, Bot Management, API Security (API Shield), Client Side Security (Page Shield), and so forth. This has led to unnecessary artificial separation of what is, under the hood, a well-integrated single platform.

This separation, which has sometimes guided implementation decisions that have led to different systems being built for the same purpose, makes it harder for our users to adopt our features and implement a simple effective security posture for their environment.

Today, following user feedback and our drive to constantly innovate and simplify, we are going back to our roots by breaking these artificial product boundaries and revising our dashboard, so it highlights our strengths. The ultimate goal remains: to make it shockingly easy to secure your web assets.

Introducing a new unified Application Security experience.

If you are a Cloudflare Application Security user, log in to the dashboard today and try out the updated dashboard interface. To make the transition easier, you can toggle between old and new interfaces.


Security, simplified

Modern applications are built using a variety of technologies. Your app might include a web interface and a mobile version, both powered by an API, each with its own unique security requirements. As these technologies increasingly overlap, traditional security categories like Web, API, client-side, and bot protection start to feel artificial and disconnected when applied to real-world application security.

Consider scenarios where you want to secure your API endpoints with proper authentication, or prevent vulnerability scanners from probing for weaknesses. These tasks often require switching between multiple dashboards, creating different policies, and managing disjointed configurations. This fragmented approach not only complicates workflows but also increases the risk of overlooking a critical vulnerability. The result? A security posture that is harder to manage and potentially less effective.

When you zoom out, a pattern emerges. Whether it’s managing bots, securing APIs, or filtering web traffic, these solutions ultimately analyze incoming traffic looking for specific patterns, and the resulting signal is used to perform actions. The primary difference between these tools is the type of signal they generate, such as identifying bots, enforcing authorization, or flagging suspicious requests. 

At Cloudflare, we saw an opportunity to address this complexity by unifying our application security tools into a single platform with one cohesive UI. A unified approach means security practitioners no longer have to navigate multiple interfaces or piece together different security controls. With a single UI, you can configure policies more efficiently, detect threats faster, and maintain consistent protection across all aspects of your application. This simplicity doesn’t just save time, it ensures that your applications remain secure, even as threats evolve.

At the end of the day, attackers won’t care which product you’re using. But by unifying application security, we ensure they’ll have a much harder time finding a way in.

Many products, one common approach

To redefine the experience across Application Security products, we can start by defining three concepts that commonly apply:

  • Web traffic (HTTP/S), which can be generalised even further as “data”

  • Signals and detections, which provide intelligence about the traffic. Can be generalised as “metadata”

  • Security rules that let you combine any signal or detection (metadata), to block, challenge or otherwise perform an action on the web traffic (data)

We can diagram the above as follows:


Using these concepts, all the product groupings that we offer can be converted to different types of signals or detections. All else remains the same. And if we are able to run and generate our signals on all traffic separately from the rule system, therefore generating all the metadata, we get what we call always-on detections, another vital benefit of a single platform approach. Also note that the order in which we generate the signals becomes irrelevant.

In diagram form:


The benefits are twofold. First, problem spaces (such as account takeover or web attacks) become signal groupings, and therefore metadata that can be queried to answer questions about your environment.

For example, let’s take our Bot Management signal, the bot score, and our WAF Attack Score signal, the attack score. These already run as always-on detections at Cloudflare. By combining these two signals and filtering your traffic against them, you can gain powerful insights on who is accessing your application*:


Second, as everything is just a signal, the mitigation layer, driven by the optional rules, becomes detection agnostic. By providing the same signals as fields in a unified rule system, writing high level policies becomes a breeze. And as we said earlier, given the detection is always-on and fully separated from the mitigation rule system, exploring the data can be thought of as a powerful rule match preview engine. No need to deploy a rule in LOG mode to see what it matches!

We can now design a unified user experience that reflects Application Security as a single product.

* note: the example here is simplistic, and the use cases become a lot more powerful once you expand to the full set of potential signals that the platform can generate. Take, for example, our ability to detect file uploads. If you run a job application site, you may want to let crawlers access your site, but you may *not* want crawlers to submit applications on behalf of applicants. By combining the bot score signal with the file upload signal, you can ensure that rule is enforced.

Introducing a unified Application Security experience

As signals are always-on, the user journey can now start from our new overview page where we highlight security suggestions based on your traffic profile and configurations. Alternatively, you can jump straight into analytics where you can investigate your traffic using a combination of all available signals.

When a specific traffic pattern seems malicious, you can jump into the rule system to implement a security policy. As part of our new design, given the simplicity of the navigation, we also took advantage of the opportunity to introduce a new web assets page, where we highlight discovery and attack surface management details.

Of course, reaching the final design required multiple iterations and feedback sessions. To best understand the balance of maintaining flexibility in the UI whilst reducing complexity, we focused on customer tasks to be done and documenting their processes while trying to achieve their intended actions in the dashboard. Reducing navigation items and using clear naming was one element, but we quickly learned that the changes needed to support ease of use for tasks across the platform.

Here is the end result:


To recap, our new dashboard now includes:

  • One overview page where misconfigurations, risks, and suggestions are aggregated

  • Simplified and redesigned security analytics that surfaces security signals from all Application Security capabilities, so you can easily identify and act on any suspicious activity

  • A new web assets page, where you can manage your attack surfaces, helping improve detection relevance

  • A single Security Rules page that provides a unified interface to manage, prioritise, and customise all mitigation rules in your zone, significantly streamlining your security configuration

  • A new settings page where advanced control is based on security needs, not individual products

Let’s dive into each one.

Overview

With the unified security approach, the new overview page aggregates and prioritizes security suggestions across all your web assets, helping you maintain a healthy security posture. The suggestions span from detected (ongoing) attacks if there are any, to risks and misconfigurations to further solidify your protection. This becomes the daily starting point to manage your security posture.


Analytics

Security Analytics and Events have been redesigned to make it easier to analyze your traffic. Suspicious activity detected by Cloudflare is surfaced at the top of the page, allowing you to easily filter and review related traffic. From the Traffic Analytics Sampled Log view, further below in the page, new workflows enable you to take quick action to craft a custom rule or review related security events in context.


Web assets

Web assets is a new concept introduced to bridge your business goals with threat detection capabilities. A web asset is any endpoint, file, document, or other related entity that we normally would act on from a security perspective. Within our new web asset page, you will be able to explore all relevant discovered assets by our system.

With our unified security platform, we are able to rapidly build new use-case driven threat detections. For example, to block automated actions across your e-commerce website, you can instruct Cloudflare’s system to block any fraudulent signup attempts, while allowing verified crawlers to index your product pages. This is made possible by labelling your web assets, which, where possible, is automated by Cloudflare, and then using those labels to power threat detections to protect your assets.


Security rules

The unified Security rules interface brings all mitigation rule types — including WAF custom rules, rate limiting rules, API sequence rules, and client side rules — together in one centralized location, eliminating the need to navigate multiple dashboards.

The new page gives you visibility into how Cloudflare mitigates both incoming traffic and blocks potentially malicious client side resources from loading, making it easier to understand your security posture at a glance. The page allows you to create customised mitigation rules by combining any detection signals, such as Bot Score, Attack Score, or signals from Leaked Credential Checks, enabling precise control over how Cloudflare responds to potential threats.


Settings

Balancing guidance and flexibility was the key driver for designing the new Settings page. As much as Cloudflare guides you towards the optimal security posture through recommendations and alerts, customers that want the flexibility to proactively adjust these settings can find all of them here.


Experience it today

This is the first of many enhancements we plan to make to the Application Security experience in the coming months. To check out the new navigation, log in to the Cloudflare dashboard, click on “Security” and choose “Check it out” when you see the message below. You will still have the option of opting out, if you so prefer.

Let us know what you think either by sharing feedback in our community forum or by providing feedback directly in the dashboard (you will be prompted if you revert to the old design).

Watch on Cloudflare TV

HTTPS-only for Cloudflare APIs: shutting the door on cleartext traffic

Post Syndicated from Suleman Ahmad original https://blog.cloudflare.com/https-only-for-cloudflare-apis-shutting-the-door-on-cleartext-traffic/

Connections made over cleartext HTTP ports risk exposing sensitive information because the data is transmitted unencrypted and can be intercepted by network intermediaries, such as ISPs, Wi-Fi hotspot providers, or malicious actors on the same network. It’s common for servers to either redirect or return a 403 (Forbidden) response to close the HTTP connection and enforce the use of HTTPS by clients. However, by the time this occurs, it may be too late, because sensitive information, such as an API token, may have already been transmitted in cleartext in the initial client request. This data is exposed before the server has a chance to redirect the client or reject the connection.

A better approach is to refuse the underlying cleartext connection by closing the network ports used for plaintext HTTP, and that’s exactly what we’re going to do for our customers.

Today we’re announcing that we’re closing all of the HTTP ports on api.cloudflare.com. We’re also making changes so that api.cloudflare.com can change IP addresses dynamically, in line with on-going efforts to decouple names from IP addresses, and reliably managing addresses in our authoritative DNS. This will enhance the agility and flexibility of our API endpoint management. Customers relying on static IP addresses for our API endpoints will be notified in advance to prevent any potential availability issues.

In addition to taking this first step to secure Cloudflare API traffic, we’ll release the ability for customers to opt-in to safely disabling all HTTP port traffic for their websites on Cloudflare. We expect to make this free security feature available in the last quarter of 2025.

We have consistently advocated for strong encryption standards to safeguard users’ data and privacy online. As part of our ongoing commitment to enhancing Internet security, this blog post details our efforts to enforce HTTPS-only connections across our global network. 

Understanding the problem

We already provide an “Always Use HTTPS” setting that can be used to redirect all visitor traffic on our customers’ domains (and subdomains) from HTTP (plaintext) to HTTPS (encrypted). For instance, when a user clicks on an HTTP version of the URL on the site (http://www.example.com), we issue an HTTP 3XX redirection status code to immediately redirect the request to the corresponding HTTPS version (https://www.example.com) of the page. While this works well for most scenarios, there’s a subtle but important risk factor: What happens if the initial plaintext HTTP request (before the redirection) contains sensitive user information?


Initial plaintext HTTP request is exposed to the network before the server can redirect to the secure HTTPS connection.

Third parties or intermediaries on shared networks could intercept sensitive data from the first plaintext HTTP request, or even carry out a Monster-in-the-Middle (MITM) attack by impersonating the web server.

One may ask if HTTP Strict Transport Security (HSTS) would partially alleviate this concern by ensuring that, after the first request, visitors can only access the website over HTTPS without needing a redirect. While this does reduce the window of opportunity for an adversary, the first request still remains exposed. Additionally, HSTS is not applicable by default for most non-user-facing use cases, such as API traffic from stateless clients. Many API clients don’t retain browser-like state or remember HSTS headers they’ve encountered. It is quite common practice for API calls to be redirected from HTTP to HTTPS, and hence have their initial request exposed to the network.

Therefore, in line with our culture of dogfooding, we evaluated the accessibility of the Cloudflare API (api.cloudflare.com) over HTTP ports (80, and others). In that regard, imagine a client making an initial request to our API endpoint that includes their secret API key. While we outright reject all plaintext connections with a 403 Forbidden response instead of redirecting for API traffic — clearly indicating that “Cloudflare API is only accessible over TLS” — this rejection still happens at the application layer. By that point, the API key may have already been exposed over the network before we can even reject the request. We do have a notification mechanism in place to alert customers and rotate their API keys accordingly, but a stronger approach would be to eliminate the exposure entirely. We have an opportunity to improve!

A better approach to API security

Any API key or token exposed in plaintext on the public Internet should be considered compromised. We can either address exposure after it occurs or prevent it entirely. The reactive approach involves continuously tracking and revoking compromised credentials, requiring active management to rotate each one. For example, when a plaintext HTTP request is made to our API endpoints, we detect exposed tokens by scanning for ‘Authorization’ header values.

In contrast, a preventive approach is stronger and more effective, stopping exposure before it happens. Instead of relying on the API service application to react after receiving potentially sensitive cleartext data, we can preemptively refuse the underlying connection at the transport layer, before any HTTP or application-layer data is exchanged. The preventative approach can be achieved by closing all plaintext HTTP ports for API traffic on our global network. The added benefit is that this is operationally much simpler: by eliminating cleartext traffic, there’s no need for key rotation.


The transport layer carries the application layer data on top.

To explain why this works: an application-layer request requires an underlying transport connection, like TCP or QUIC, to be established first. The combination of a port number and an IP address serves as a transport layer identifier for creating the underlying transport channel. Ports direct network traffic to the correct application-layer process — for example, port 80 is designated for plaintext HTTP, while port 443 is used for encrypted HTTPS. By disabling the HTTP cleartext server-side port, we prevent that transport channel from being established during the initial “handshake” phase of the connection — before any application data, such as a secret API key, leaves the client’s machine.


Both TCP and QUIC transport layer handshakes are a pre-requisite for HTTPS application data exchange on the web.

Therefore, closing the HTTP interface entirely for API traffic gives a strong and visible fast-failure signal to developers that might be mistakenly accessing http://… instead of https://… with their secret API keys in the first request — a simple one-letter omission, but one with serious implications.

In theory, this is a simple change, but at Cloudflare’s global scale, implementing it required careful planning and execution. We’d like to share the steps we took to make this transition.

Understanding the scope

In an ideal scenario, we could simply close all cleartext HTTP ports on our network. However, two key challenges prevent this. First, as shown in the Cloudflare Radar figure below, about 2-3% of requests from “likely human” clients to our global network are over plaintext HTTP. While modern browsers prominently warn users about insecure HTTP connections and offer features to silently upgrade to HTTPS, this protection doesn’t extend to the broader ecosystem of connected devices. IoT devices with limited processing power, automated API clients, or legacy software stacks often lack such safeguards entirely. In fact, when filtering on plaintext HTTP traffic that is “likely automated”, the share rises to over 16%! We continue to see a wide variety of legacy clients accessing resources over plaintext connections. This trend is not confined to specific networks, but is observable globally.

Closing HTTP ports, like port 80, across our entire IP address space would block such clients entirely, causing a major disruption in services. While we plan to cautiously start by implementing the change on Cloudflare’s API IP addresses, it’s not enough. Therefore, our goal is to ensure all of our customers’ API traffic benefits from this change as well.


Breakdown of HTTP and HTTPS for ‘human’ connections

The second challenge relates to limitations posed by the longstanding BSD Sockets API at the server-side, which we have addressed using Tubular, a tool that inspects every connection terminated by a server and decides which application should receive it. Operators historically have faced a challenging dilemma: either listen to the same ports across many IP addresses using a single socket (scalable but inflexible), or maintain individual sockets for each IP address (flexible but unscalable). Luckily, Tubular has allowed us to resolve this using ‘bindings’, which decouples sockets from specific IP:port pairs. This creates efficient pathways for managing endpoints throughout our systems at scale, enabling us to handle both HTTP and HTTPS traffic intelligently without the traditional limitations of socket architecture.

Step 0, then, is about provisioning both IPv4 and IPv6 address space on our network that by default has all HTTP ports closed. Tubular enables us to configure and manage these IP addresses differently than others for our endpoints. Additionally, Addressing Agility and Topaz enable us to assign these addresses dynamically, and safely, for opted-in domains.

Moving from strategy to execution

In the past, our legacy stack would have made this transition challenging, but today’s Cloudflare possesses the appropriate tools to deliver a scalable solution, rather than addressing it on a domain-by-domain basis.

Using Tubular, we were able to bind our new set of anycast IP prefixes to our TLS-terminating proxies across the globe. To ensure that no plaintext HTTP traffic is served on these IP addresses, we extended our global iptables firewall configuration to reject any inbound packets on HTTP ports.

iptables -A INPUT -p tcp -d <IP_ADDRESS_BLOCK> --dport <HTTP_PORT> -j REJECT 
--reject-with tcp-reset

iptables -A INPUT -p udp -d <IP_ADDRESS_BLOCK> --dport <HTTP_PORT> -j REJECT 
--reject-with icmp-port-unreachable

As a result, any connections to these IP addresses on HTTP ports are filtered and rejected at the transport layer, eliminating the need for state management at the application layer by our web proxies.

The next logical step is to update the DNS assignments so that API traffic is routed over the correct IP addresses. In our case, we encoded a new DNS policy for API traffic for the HTTPS-only interface as a declarative Topaz program in our authoritative DNS server:

- name: https_only
 exclusive: true 
 config: |
    (config
      ([traffic_class "API"]
       [ipv4 (ipv4_address “192.0.2.1”)] # Example IPv4 address
       [ipv6 (ipv6_address “2001:DB8::1:1”)] # Example IPv6 address
       [t (ttl 300]))
  match: |
    (= query_domain_class traffic_class)
  response: |
    (response (list ipv4) (list ipv6) t)

The above policy encodes that for any DNS query targeting the ‘API traffic’ class, we return the respective HTTPS-only interface IP addresses. Topaz’s safety guarantees ensure exclusivity, preventing other DNS policies from inadvertently matching the same queries and misrouting plaintext HTTP expected domains to HTTPS-only IPs

api.cloudflare.com is the first domain to be added to our HTTPS-only API traffic class, with other applicable endpoints to follow.

Opting-in your API endpoints

As we said above, we’ve started with api.cloudflare.com and our internal API endpoints to thoroughly monitor any side effects on our own systems before extending this feature to customer domains. We have deployed these changes gradually across all data centers, leveraging Topaz’s flexibility to target subsets of traffic, minimizing disruptions, and ensuring a smooth transition.

To monitor unencrypted connections for your domains, before blocking access using the feature, you can review the relevant analytics on the Cloudflare dashboard. Log in, select your account and domain, and navigate to the “Analytics & Logs” section. There, under the “Traffic Served Over SSL” subsection, you will find a breakdown of encrypted and unencrypted traffic for your site. That data can help provide a baseline for assessing the volume of plaintext HTTP connections for your site that will be blocked when you opt in. After opting in, you would expect no traffic for your site will be served over plaintext HTTP, and therefore that number should go down to zero.


Snapshot of ‘Traffic Served Over SSL’ section on Cloudflare dashboard

Towards the last quarter of 2025, we will provide customers the ability to opt in their domains using the dashboard or API (similar to enabling the Always Use HTTPS feature). Stay tuned!

Wrapping up

Starting today, any unencrypted connection to api.cloudflare.com will be completely rejected. Developers should not expect a 403 Forbidden response any longer for HTTP connections, as we will prevent the underlying connection to be established by closing the HTTP interface entirely. Only secure HTTPS connections will be allowed to be established.

We are also making updates to transition api.cloudflare.com away from its static IP addresses in the future. As part of that change, we will be discontinuing support for non-SNI legacy clients for Cloudflare API specifically — currently, an average of just 0.55% of TLS connections to the Cloudflare API do not include an SNI value. These non-SNI connections are initiated by a small number of accounts. We are committed to coordinating this transition and will work closely with the affected customers before implementing the change. This initiative aligns with our goal of enhancing the agility and reliability of our API endpoints.

Beyond the Cloudflare API use case, we’re also exploring other areas where it’s safe to close plaintext traffic ports. While the long tail of unencrypted traffic may persist for a while, it shouldn’t be forced on every site.

In the meantime, a small step like this can allow us to have a big impact in helping make a better Internet, and we are working hard to reliably bring this feature to your domains. We believe security should be free for all!

На второ четене: „Голямо червено слънце, самотни електрически светлини“

Post Syndicated from original https://www.toest.bg/na-vtoro-chetene-golyamo-cherveno-sluntse-samotni-elektricheski-svetlini/

„Голямо червено слънце, самотни електрически светлини“ от Пламен Антов

На второ четене: „Голямо червено слънце, самотни електрически светлини“

София: изд. „Ерго“, 2019

Позволявам си да напиша тази статия като автор (какъвто всъщност съм, преди да се упражнявам и като рецензент). Не знам дали е „разрешено“, но е неизбежно, когато срещнеш своеобразен литературен близнак в лицето на писателя, за когото ще стане дума. Това припознаване се случи спонтанно, от раз, и върви по линия не толкова на сюжетите, колкото на цялостната нагласа и тоналност; на кръженето около големите, вечни теми; поетичните затишия и чувствеността в езика; реферирането към собствените текстове; предизвикването на читателя и съзнанието, че не си отговорен за удобството му; саботирането на мелодрамата и клишетата (което отнема сантименталността, но не и призрака ѝ); веруюто, че „ако в една идея или мисъл липсва парадоксът, тя е незавършена и невярна“; дори начина, по който две от историите ни (излезли в сборници през същата година) са дотолкова сходни, чак до конкретната сцена, че някой би могъл да ни обвини в плагиатство. Рецензионният поглед е изотвътре, макар и отдалечен, но

радостта автор да срещне и припознае като себе си друг е рядка, особена и плътна.

Запознавам се с творчеството на Пламен Антов чак до неудобство късно, докато той е на литературната сцена отдавна, ала – иска ли питане – изглежда, присъства тихо, ненатрапливо, може би с онова специфично пренебрежение на пътуващия човек от книгата, за която ще стане дума тук: „Голямо червено слънце, самотни електрически светлини“. В края на миналата година „Жанет 45“ издадe и най-новия му сборник, събрал (случайно или не) девет разказа – „Нагоре по реката назад“. Той обединява в един почти митологичен общ разказ истории от далечните му пътувания „в дивото“ и само сенки на сюжети, построени върху архетипни дихотомии, философски разсъждения и напоителни диалози, които разхождат белия културен пътешественик нагоре и назад отвъд западната цивилизация. Силно ви препоръчвам да обърнете внимание и на тази книга.

В „Голямо червено слънце, самотни електрически светлини“ историите също са обединени от пътя и също са автофикционални или дори автобиографични (затова за по-лесно ще наричам героя вътре „автора“), но се случват не из дебрите на далечна Азия и Южна Америка, а в България, по време на пътувания на стоп или с влак. И тук авторът се придвижва в леко абстрактната география, в неназованите градчета, по пътищата между големия град и провинцията, между планините и морето, между голямото червено слънце на свободата и изкуствените електрически светлини на нейното обратно, между невъзможността на природата и неизкоренимостта на цивилизацията – защото „всъщност името изобщо нямаше значение“. Неслучайно всеки път въпросът откъде идва и накъде пътува, отправен към него, остава без ясен отговор.

И тук времето е изведено в скоби или по-скоро авторът се самоизвежда извън него (макар и не така метафизично, както е преминаването между хронологичното и цикличното време в новия му сборник). И тук символично присъства – или по-скоро липсва – часовникът, когато някой друг герой стратегически го попита за часа. Тази неопределеност важи и за времето на самите сюжети; усещането е за флуидност – струва ти се например, че авторът е съвсем млад и пътува през 80-те или 90-те, а после се появява мобилен телефон, докато накрая, в последния разказ, героят съществува в суперпозиция с възрастния си Аз.

Всеки разказ представя някаква среща „по пътя“, и то с различни типове хора.

В някакъв смисъл тези истории са много по-сюжетни и по-социално ангажирани (мразя това леко неточно определение, но не разполагам с по-общопонятно), отколкото новите, които са далеч по-съзерцателни, разсъдителни. (Не, тук съзерцанието далеч не липсва – просто в тях Пламен Антов повече показва, отколкото казва.) Та, авторът среща например пиещи жп работници, деветдесетарски нимфетки, ревниви жени на ръба на нервна криза, бивши любими, избягал престъпник, просяк, пътни работници цигани, хомосексуален пич в мотел, съученици по време на среща на класа, а накрая и изобщо: самия себе си. Момичетата са много. Във всяка история героят по одисеевски копнее, очакван е, отделен е от, съжалява за, пътува към… (и така нататък) едно момиче/жена – на различни възрасти, в различни роли, в различни фази на отношенията, маркиращи и собственото му движение във времето.

И те, и срещите обаче по-скоро не обживяват, а рамкират екзистенциалната самота на героя („космическата ни самота в смъртта“) и тази самота е един от героите в тези разкази, защо не дори главният. Самият автор е отстранен от света, носи известна неприязън, натъртва на своето безразличие, казвайки за себе си:

… все се по-малко гледах да се намесвам в света, все по-малко ме интересуваше той, достатъчно ми беше да бъда само едно невидимо, само едно око невидимо, изпълнено с досада и омерзение.

Или:

Общуването с хората не е моята стихия, аз съм от самотните скитници. Но понякога изведнъж ми става нещо.

Това остава в сила и когато неговите действия го потвърждават, но дори и когато го опровергават. В тези истории например има достатъчно примери за обмен, за даване (цигари, храна, помощ, съчувствие, компания, разговори), но тези дребни жестове се явяват като изключенията, потвърждаващи заблудата, че „малките неща не умират“. Има и вземане в този обмен – от това да те качат по пътя, но най-вече на нечие тяло.

Впрочем цялата книга е пронизана от една смътна, опосредствана, копнежна или неочаквана сексуалност,

която винаги е там. Може би неин е червеният цвят, който се появява на много места (а и на всичко друго, на което можем да го припишем символично).

Та тези срещи са на една самота с друга самота, защото в крайна сметка са просто част от пътя, от преходността му и същевременно от неговата неизменност. От една страна, това са човеколюбиви, протягащи се към другия разкази, написани с на места почти социална чувствителност и дори сантименталност. (Последната, слава богу, веднага подрива или може би дори подиграва себе си, за да не прозвучи евтино, както биваме предупредени в предговора – че тук има „пародии на литературни сюжети и ситуации“.) От друга страна обаче, състои ли се наистина срещата и доколко? Един разказ, в който това е особено видно, е „Самотните електрически светлини“, където отказът на просяка да потвърди присъствието си в носталгичния спомен на приютилия и обгрижилия го герой, оказва съпротива на „сълзливата сантименталност“ на този филмов момент:

И едва сдържах някакъв странен порив да падна на колене пред този непознат, да целуна ръката му и да поискам прошка – със същата сълзлива сантименталност както у Достоевски, само че без капчица религиозен патос, който е по-непоносим от всичко.

Така че срещата е просто забавянето при отминаването, крехкостта на спирането, преди да продължиш. Неслучайно заедно с отсъстващия часовник ,един от другите най-присъстващи символи в историите е цигарата. Героите току си предлагат цигара и пушат заедно, и в нейната краткотрайност, в съскащото ѝ горене-гаснене на вечния студ, в споделената компания на издишания дим е може би смисълът на този повтарящ се мотив.

Онази неопределеност, за която стана дума по-горе, е и по отношение на моралните (и естетическите) координати. Тук те са пресечени, дифузни. И по отношение на разказвача, и по отношение на други герои/постъпки. Самият автор е нюансиран, диалектичен тип, иска ли питане. Във „Влизане в непознат град и излизане“ например сюжетната кулминация го превръща от избавител в насилник (морбидна подигравка на идеята за „спасителя“), а героинята осцилира между жертва и „просеща си“ го изкусителка. Невинността и вината се проникват, мотивацията на действията е противоречива. Бунтът прераства в насилие срещу онази, която в този момент в очите на героя олицетворява еснафското примирение; свеждането на вектора на „пътя“ до кратката затворена отсечка на ежедневното дерзание, конвенционалното примирение и неспособността да зададеш големите, страшните въпроси. Така от красиво и невинно момиче героинята се превръща в „тъпа кукла“, а накрая просто в „нещо, пълно с лайна“.

Подобни преходи има и в „Нощен влак“, и в „Майтап бе, Уили“, и в „Самотните електрически светлини“, и в „Шантав автостоп“. В много разкази отделните жестове на добрина, на протегната ръка биват избавяни от мелодраматичността си именно от замъгления морален фон, от нагласата на героя, от съпътстващите цинични размисли.

На второ четене: „Голямо червено слънце, самотни електрически светлини“

Сходна е ситуацията и по отношение на естетическото. В „Като във филм отпреди новата ера“ онова, което първо е намирал за изключително грозна гледка заедно с нас, ще се разкрие пред автора като „най-красивото нещо на света“ в голотата си. В „Нашата голота“ ще надделее нечовечното, но и небаналното, като реакция пред вестта за смъртта на нечий родител. Еросът отхвърля Танатоса; красотата на един момент на живеене, страст, телесност тук и сега, когато сме „така измамно млади, измамно живи и топли“, отхвърля досадната натрапчивост, неестетичността на смъртта и тленността. Този нетактичен егоизъм отново подрива мелодрамата на момента – той е искрен, жизнеутвърждаващ, справедлив дори.

В предговора към книгата Пламен Антов посочва, че тя е незавършена и в техническия смисъл на думата е така. Но доколкото пътят поражда тези сюжети, да, тази книга е невъзможна за завършване. В крайна сметка дори и пътят да свърши, както си казват героите в „Шантав автостоп“, трябва да започнеш да се връщаш (а това е нов път).

И не съществува никаква утеха, само пътят, само пътят, по който вървиш, тази улица в това безименно, смътно познато или съвсем друго градче, само пътят, който е свобода.

Малко ще е глупаво накрая да обобщя тези разкази и като „хипарски“, макар битническият начин на живот да има доста общо със сюжетната рамка на сборника. (Лично на мен историите ми напомнят и мъничко на Колдуел, и дори на Селинджър). Не върви да ги огранича и до „социални“, никак даже. Те са по малко от всичко, в тях има игра, има закачка с литературни формули и стереотипни образи, има дори авторски нарцисизъм: в „Три“ момичето ще отхвърли героя като реалния автор на книгата, която чете (настоящата, като нас). Има поставени в кавички емоционални изблици, макар и минорни, меланхолични. Има и нещо сурово, момчешко, грубовато. И нещо филмово (честата фраза „звучиш ми като реплика от филм“). И да – онези бегли поетични затишия, словесните пейзажи. Понеже няма начин за завършване на всичко, което казвам, съвсем в духа на тази книга, слагам рязко точката тук.

Активните дарители на „Тоест“ получават постоянна отстъпка в размер нa 20% от коричната цена на всички заглавия от каталога на издателство „Ерго“, както и на няколко други български издателства в рамките на партньорската програма Читателски клуб „Тоест“. За повече информация прочетете на toest.bg/club.

Никой от нас не чете единствено най-новите книги. Тогава защо само за тях се пише? „На второ четене“ е рубрика, в която отваряме списъците с книги, публикувани преди поне година, четем ги и препоръчваме любимите си от тях. Рубриката е част от партньорската програма Читателски клуб „Тоест“. Изборът на заглавия обаче е единствено на авторите – Стефан Иванов и Антония Апостолова, които биха ви препоръчали тези книги и ако имаше как веднъж на две седмици да се разходите с тях в книжарницата.

Сирийският въпрос в раздаването на картите между Великите сили

Post Syndicated from Искрен Иванов original https://www.toest.bg/siriyskiyat-vupros-v-razdavaneto-na-kartite-mezhdu-velikite-sili/

Сирийският въпрос в раздаването на картите между Великите сили

Сирия винаги е оставала някак си „незабелязана“ на фона на останалата част от Близкия изток, като причините за това са много. Най-очевидната от тях е навикът на Великите сили да използват страната като буфер за военните си авантюри през десетилетията, още от времето на древните империи до наши дни. Това е и причината, поради която Сирия е толкова „желана“ от всеки завоевател, който разбира геостратегическото ѝ значение – на юг тя е вход към едни от най-плодородните земи в Близкия изток, а контролът над пристанището ѝ дава възможност и на най-слабия флот да получи директен достъп до Средиземно море. Въпреки древната си история и хилядолетното съжителство на много култури на територията ѝ, страната така и не успява да изгради самостоятелна политическа идентичност, а независимостта ѝ става факт едва след края на Втората световна война, когато арабските държави в региона се превръщат в една от многото арени на сблъсък между САЩ и СССР.

Модерната сирийска държавност и външна политика

Когато Сирия става най-сетне част от ООН през 1945 г., тя все още няма свой покровител сред суперсилите и след кратковремения си политически флирт с Египет тръгва по трудния път на независимостта си. Политическата система на младата нация е сложен компромис от присъствието на мюсюлмани, християни и друзи. Пръв СССР проявява интерес към Сирия, възприемайки я като отправна точка за своя нов политически експеримент – панарабизмът. Това е идеология, която призовава за обединението на всички арабски народи в Близкия изток под знака на социализма в една славна арабска нация, която да се противопостави на американското влияние в региона и на най-близкия съюзник на САЩ – Израел.

Парадоксално, панарабизмът за кратко време се радва на подкрепа дори и от страна на президента Айзенхауер, който вижда в него възможност за частично овладяване на конфликта между Израел и останалите арабски държави. Уви, мечтите на Москва и Вашингтон рухват през 60-те години, когато панарабизмът е в упадък, а апетитите към Сирия са откраднати от Египет, който става първата арабска държава, осмелила се да започне мирен диалог с Израел.

Провалът на панарабизма води до рязко увеличаване на влиянието на движения като „Мюсюлмански братя“, които се стремят към възстановяване на халифата от времето на Османската империя и към пълна ревизия на исляма. Последното е много важно, защото то включва приемане на тълкуванието на някои влиятелни египетски шейхове, виждащи джихада като шести стълб на исляма, а т.нар. „голям джихад“ (ал-джихад ал-акбар) се схваща като неотменимо свързан с „малкия джихад“ (ал-джихад ал-асгар) – свещената война, и като религиозно задължение (фарида), върху което се поставя изключителен акцент.

Тези идеи стават особено популярни сред мюсюлманите в Сирия, но не успяват да спечелят политическа подкрепа в региона в условията на двуполюсна геополитическа надпревара, доминирана от ядрените оръжия и опитите на САЩ и СССР да избегнат Трета световна война. Малко след като планът на Москва да създаде „арабска Югославия“ рухва, остатъците от него дават възможност на партията „Баас“ да установи династична социалистическа диктатура в Сирия, което донякъде тушира набиращия сила политически ислям.

Парадоксалното е, че съществуването на Сирия идеално устройва и САЩ, и СССР, тъй като, въпреки социалистическата формула на властта, династията на Асад няма намерение да разработва ядрено оръжие. Нещо повече, революцията в Иран и заявките на ислямската република, че ще се бори да получи ядрен арсенал, далеч надхвърлят политическите амбиции на сирийците, които се оказват един малък детайл в геополитическата мозайка на региона. На фона на Иран, Афганистан и Ирак, Сирия и Египет попадат в графата на „стабилните държави“, които Москва и Вашингтон могат да използват като балансьори при прокарването на своите геополитически интереси в Близкия изток. А самата династия Асад, от друга страна, няма как да толерира сунитските терористични групировки, защото, за разлика от мнозинството сирийски мюсюлмани, младият Башар Асад и неговото семейство са алавити.

Разривът между Сирия и „големите“

След края на Студената война Сирия тръгва в посока, която все повече започва да я конфронтира с интересите на САЩ в региона. Разпадът на СССР слага край на всяка надежда за възраждане на панарабистката идеология, а терористичните атентати от 11 септември 2001 г. поставят страната пред дилемата дали да подкрепи американския президент Джордж Буш-младши в кръстоносния му поход срещу „Ал-Кайда“. Сложността на този избор се обуславя и от факта, че Сирия е най-дълго присъстващият член в списъка на Държавния департамент на САЩ с държави спонсори на тероризма, тъй като американското правителство от Ислямската революция в Иран насам винаги е приемало Дамаск като сухопътен коридор, по който Техеран доставя оръжия за терористичните мрежи в региона. Тези опасения на САЩ не са безпочвени, защото за доста дълго време алавитският елит в Сирия намира своя естествен съюзник в шиитското русло на аятоласите. В опита си да спаси режима си през 2003–2004 г. Асад сътрудничи последователно на САЩ да разследват ядрата на „Ал-Кайда“ на сирийска територия. В замяна републиканците решават да си затворят очите за нарастващото неодобрение срещу сирийското управление.

Тук е мястото да кажем няколко думи за самата фигура на Башар Асад. Предвид неговото образование и ценз, той определено може да бъде причислен към едни от най-образованите политици в Близкия изток. Ловките му политически маневри и светският му маниер успяват да превърнат Сирия в централизирана политически държава, където политическият ислям не успява да пусне дълбоки корени. Как тогава следва да окачествим управлението му – като диктатура или като някакъв особен тип идеология на Третия свят, която се бори за оцеляване? Отговорът е недвусмислен: Башар Асад се превърна в диктатор и терорист тогава, когато нареди употребата на химическо оръжие срещу собственото си население. Кошмарът продължи цели седем години и беше мълчаливо подминат от много страни членки на Европейския съюз, които виждаха в сирийските бежанци евтина работна ръка. Именно поради тази причина САЩ, Великобритания и Франция не успяха да съберат мнозинство за втора коалиция на желаещите, която да свали Асад още когато той започна репресиите срещу сирийците.

Още големи грешки Башар Асад допусна в края на своето управление. Една от тях беше да се довери на Русия, която му обеща подкрепа срещу ограничено военно присъствие в Сирия. Този крехък баланс можеше да бъде поддържан до момента, в който „Хамас“ не взе решение да удари Израел на 7 октомври. Тук Асад направи и друга грешка – той се довери на Иран и аятоласите, смятайки, че те ще се застъпят за него и ще влязат във война с Израел. По това време недоволството срещу режима на Асад вече достигаше рекордни нива, а израелският премиер Бенямин Нетаняху на няколко пъти предупреди, че едно от условията за траен мир в Близкия изток е пълната демилитаризация на Южна Сирия. Падането на Асад се оказа неизбежно и от любимец на сирийския народ и приемлив за САЩ „светски“ диктатор той се превърна във военнопрестъпник. Съвсем отделен е въпросът, че най-голяма роля за края на режима изигра религиозният кливидж в Сирия между богатото алавитско малцинство начело с Асад и мнозинството бедни сунити в страната, които станаха жертва на политическите амбиции на своя лидер.

„Нова“ Сирия на кръстопът

Когато един диктаторски режим си отиде, логично възниква въпросът защо беше всичко и сега накъде. Новините за Сирия отново не са оптимистични поради няколко основни причини. Първо, исторически факт е, че след Арабската пролет мнозинството от диктаторските режими в Близкия изток и Северна Африка бяха заменени с емирати и халифати. Такава беше съдбата на Либия и Ирак, а Египет остана единственото изключение от това правило заради военното управление на полковник Сиси.

Казано с други думи, бившите диктатури в Близкия изток не подлежат на демократизация и либерализация, защото гражданите им винаги разпознават шариата като алтернатива на диктаторите. Затова и не знаем дали сирийският сценарий няма да се повтори един ден и в Египет, когато властта на Сиси падне. Арабската пролет, с други думи, е един от най-грандиозните провали на Запада, тъй като днес по тези земи властва политическият ислям, а той е в пъти по-опасен от политическите амбиции на хора като Кадафи. Същевременно беше ясно, че не може да се разчита на диктаторите да уважават човешките права, защото и в тяхното съзнание те не значат нищо.

Оптимистичните сценарии за Сирия се свиват и поради факта, че южната ивица от територията ѝ включва земи, исторически принадлежащи на Израел. Лошото е, че точно тези обширни части от Сирия бяха използвани като коридор за иранските оръжия, с които се въоръжават „Хамас“ и „Хизбула“. В този смисъл, за да има траен мир по границата, е необходимо новият политически елит в Сирия да се договори с Израел за поддържането на ограничено военно присъствие в региона, което да отчита както историческите претенции на израелците, така и реалните геополитически възможности за разрешаването на териториалните спорове.

Но най-важно от всичко е да се дадат трайни гаранции на сирийците, че срещу тях няма да бъдат използвани химически оръжия (защото такива в Сирия все още има) и че новата власт, независимо от политическата си формула, няма да осъществява репресии над цивилното население. Единственият гарант за такова обещание може да бъде ООН, която обаче е изключително разделена по въпроса и очевидно не желание да се нагърби с разрешаването му.

Второто важно уточнение е, че за разлика от талибаните в Афганистан, новият лидер на Сирия Ахмад ал-Шараа и неговият най-близък съветник Абдулхамид ал-Ауак имат далеч по-светска биография. Ал-Ауак, който е и автор на новата сирийска Конституция, е преподавал дълги години конституционно право в Турция и е добре запознат със съдбата на Афганистан и Ирак, както и с грешките, които допуснаха Хамид Карзай и иракските управляващи след Саддам Хюсейн. И все пак тези факти не могат да бъдат стабилни аргументи в полза на твърдението, че сценариите от Афганистан и Ирак няма да се повторят в Сирия. В страната все още има американски войски, а бъдещето на руските бази е неясно. 

Същевременно лоялистите на Асад лесно могат да се превърнат в нова версия на талибаните, проповядвайки, че страната е сменила една „благословия“ – руската, с друга – американската. Неясно е и бъдещето на отношенията с Иран – въпрос, който новото правителство в Сирия последователно пренебрегва с аргумента, че приоритет е стабилизацията на страната и премахването на всички остатъци от режима на Асад и че на този етап тези отношения ще се свеждат единствено до изискване на компенсации от Техеран за хаоса, създаден в Сирия. Опасността надеждите на сирийците да бъдат предадени за пореден път все още не е напълно отминала.

Вместо заключение: кой е големият победител?

Естественият печеливш от станалото в Сирия е Република Турция. Падането на алавитския режим и установяването на стабилно сунитско управление работи за интересите на Ердоган, който вижда в новата Сирия възможност да възстанови влиянието на Анкара по тези земи, загубено след разпада на Османската империя. Неоосманизмът като ключова променлива в доктрината на Ердоган до голяма степен е постигнал целите си на Балканите и сега предстои да се насочи към Близкия изток. Тук той неизбежно ще се сблъска с интересите на Израел, което може да стане причина за нова голяма криза в региона.

Дали Турция ще намери баланса между желанието за сбъдването на неоосманския идеал и отношенията с Израел, зависи от политическата воля на Ердоган, който може да стигне много далеч в амбициите си. Втората държава, която определено няма да е доволна от ставащото, е Кралство Саудитска Арабия, което неведнъж е спорило с Турция в рамките на организацията „Ислямска конференция“ за това кой е неформалният лидер в сунитския ислямски свят. Напрежението между Анкара и Рияд е реалност, която също не бива да се пренебрегва.

Сирийският народ, от друга страна, спечели много с падането на Асад, но не е големият победител в тази битка, защото все още не знаем кой ще влезе в ролята на талибаните – новото правителство или старите лоялисти на Асад. И в двата случая предстои дълъг период на стабилизация, който няма как да приключи без още кръвопролития. Липсата на ясен ангажимент от страна на САЩ или Русия, съчетана с мълчанието на ООН, не вещае скорошна стабилност за региона.

Не се знае и как ще реагира Иран – в един момент той може да реши просто да анексира част от сирийските територии, на което правителството няма как да се противопостави, особено ако иранската гвардия е подкрепяна от поддръжниците на Асад и „Хизбула“. Този сценарий, разбира се, е малко вероятен, докато на територията на страната има американски войски, но те няма да са там дългосрочно, тъй като не се знае в какво ще прерасне търговската война срещу Китай, поведена от администрацията на Тръмп.

В тези условия единственият надежден съюзник на Сирия остава Турция, и то докато Ердоган все още управлява. След като десетилетия наред страната е част от геополитическите проекти на СССР за панарабизъм и на САЩ за войната срещу терора, днес Дамаск вече е сегмент на турския неоосманизъм. Дали сирийското правителство ще се примири с тази роля, зависи от два фактора: доколко има възможността да се защитава и доколко може да балансира в отношенията си с Турция и Израел. Предвид ограничената му способност да изгради свой отбранителен потенциал, по всяка вероятност ще се наложи то да лавира между регионалните актьори в Близкия изток – тъжна реалност за сирийците, която сега ги връхлита за трети път.

Improved support for private applications and reusable access policies with Cloudflare Access

Post Syndicated from Kenny Johnson original https://blog.cloudflare.com/improved-support-for-private-applications-and-reusable-access-policies-with-cloudflare-access/

Simplifying secure access for every application

For years, Cloudflare has helped organizations modernize their access to internal resources by delivering identity-aware access controls through our Zero Trust Network Access (ZTNA) service, Cloudflare Access. Our customers have accelerated their ZTNA implementations for web-based applications in particular, using our intuitive workflows for Access applications tied to public hostnames.

However, given our architecture design, we have primarily handled private network application access (applications tied to private IP addresses or hostnames) through the network firewall component of our Secure Web Gateway (SWG) service, Cloudflare Gateway. We provided a small wrapper from Access to connect the two experiences. While this implementation technically got the job done, there were some clear downsides, and our customers have frequently cited the inconsistency.

Today, we are thrilled to announce that we have redesigned the self-hosted private application administrative experience within Access to match the experience for web-based apps on public hostnames. We are introducing support for private hostname and IP address-defined applications directly within Access, as well as reusable access policies. Together, these updates make ZTNA even easier for our customers to deploy and streamline ongoing policy management.

In order to better understand how this feature improves the overall functionality of Access, let’s explore what makes up a “private” application, how they are typically accessed, what was possible before this feature, and what the new feature enables. If you are a networking expert or aficionado, you can skip ahead to A look back: protecting private applications with Cloudflare Zero Trust before Access Private IP Address and Hostname support.

Private applications

A private application in this context, is any application that is only accessible through a private IP address or hostname. 

Private IP addresses

Private IP addresses, often referred to as RFC 1918 IP addresses, are scoped to a specific network and can only be reached by users on that network. While public IP addresses must be unique across the entire Internet, private IP addresses can be reused across networks. Any device or virtual machine will have a private IP address. For example, if I run ipconfig on my own Windows machine, I can see an address of 192.168.86.172.


This is the address that any other machine on my own network can use to reference and communicate with this specific machine. Private IP addresses are useful for applications and ephemeral infrastructure (systems that spin up and down dynamically) because they can be reused and only have to be unique within their specific network. This is much easier to manage than issuing a public IPv4 address to resources – we’ve actually run out of available public IPv4 address space!

In order to host an application on a machine in my network, I need to make that application available to other machines in the network. Typically, this is done by assigning the application to a specific port. A request to that application might then look something like this: http://10.128.0.6:443 which in plain English is saying “Using the hypertext transfer protocol, reach out to the machine at an address of 10.128.0.6 in my network, and connect to port 443.” Connecting to an application can be done in a browser, over SSH, over RDP, through a thick client application, or many other methods of accessing a resource over an IP address.

In this case, we have an Apache2 example web server, running at that address and port combination.


If I attempt to access this IP address outside of the same network as this machine running the web server, then I will either get no result, or a completely different application, if I have something else running on that IP address/port combination in that other network.


Private hostnames

We don’t want to remember 10.128.0.6 every time we want to access this application. Just like the Internet, we can use DNS in our private network. While public DNS serves as the phone book for the entire Internet, private DNS is more like a school directory that is only valid for phone numbers within the campus.

For a private application, I can configure a DNS record, very similar to how I might expose a public website to the world. But instead, I will map my DNS record to a private IP address that is only accessible within my own network. Additionally, private DNS does not require registering a domain with a registrar or adhering to defined top level domains. I can host an application on application.mycompany, and it is a valid internal DNS record. 

In this example, I am running my web server on Google Cloud and will call the application kennyapache.local. In my local DNS, kennyapache.local has an A record mapping it to an IPv4 address within my private network on Google Cloud (GCP).


This means that any machine within my network can use https://kennyapache.local instead of having to remember the explicit IP address.


Accessing private applications outside the private network

Private networks require your machine, or virtual machine, to be connected directly to the same network as the target private IP address or hostname. This is a helpful property to keep unauthorized users from accessing applications, but presents a challenge if the application you want to use is outside your local network. 

Virtual Private Networks (VPNs), forward proxies, and proxy protocols (aka “PAC files”) are all methods to enable a machine outside your private network to reach a private IP address/hostname within the private network. These tools work by adding an additional network interface to the machine and specifying that certain requests need to be routed through a remote private network, not the local network the machine is currently connected to, or out to the public Internet.

When I connect my machine to a forward proxy, in this case Cloudflare’s device client, WARP, and run ipconfig I can see a new network interface and IP address added to the list:


This additional network interface will take control of specific network requests and route those to an external private network instead of the default behavior of my machine, which would be to route to that IP address on my own local network.

A look back: protecting private applications with Cloudflare Zero Trust before Access Private IP Address and Hostname support

We will continue to use our Apache2 server hosted on a GCP private domain as an example private application. We will briefly touch on how Cloudflare Zero Trust was previously used to protect private applications and why this new feature is a huge step forward. Cloudflare Zero Trust has two primary components used to protect application traffic: Cloudflare Access and Gateway.

Cloudflare Access

Cloudflare Access is designed to protect internal applications and resources without the need for a traditional VPN. Access allows organizations to authenticate and authorize users through identity providers — such as Okta, Azure AD, or Google Workspace — before granting them entry to internal systems or web-based applications. 

Until now, Access required that an application had to be defined using a public DNS record. This means that a user had to expose their application to the Internet in order to leverage Access and use all of its granular security features. This isn’t quite as scary as it sounds, because Access allows you to enforce strong user, device, and network security controls. In fact, NIST and many other major security organizations support this model.

In practice, an administrator would map their internal IP address or hostname to a public URL using our app connector, Cloudflare Tunnel. 


Then, the administrator would create an Access application corresponding to that public URL. Cloudflare then sends a user through a single sign-on flow for any request made to that application.


However, this approach does not work for organizations that have strict requirements to never expose an application over public DNS. Additionally, this does not work for applications outside the browser like SSH, RDP, FTP and other thick client applications, which are all options to connect to private applications.

If I tried to SSH to my Access-protected public hostname, I would get an error message with no way to authenticate, since there is no easy way to do a single sign-on through the browser in conjunction with SSH.

Access Private Network applications

Until now, because Access operated using public hostnames, we have handled private network access for our customers using the network firewall piece of Cloudflare Gateway. A few years ago, we launched Access Private Network applications, which automatically generate the required Gateway block policies. However, this was a limited approach that was ultimately just a wrapper in front of two Gateway policies. 


Cloudflare Gateway

Cloudflare Gateway is a secure web gateway that protects users from threats on the public Internet by filtering and securing DNS and web traffic. Gateway acts as a protective layer between end users and online resources by enforcing security controls, like blocking malicious domains, restricting access to risky categories of sites, and preventing data exfiltration. 

Gateway is also used to route user traffic into private networks and acts as a forward proxy. It allows customers to create policies for private IP addresses and hostnames. This is because Gateway relies on traffic being proxied from the user’s machine to the Gateway service itself. This is most commonly done with the Cloudflare WARP client. WARP enables the configuration of which IP addresses and hostnames to send to Gateway for filtering and routing.

Once connected to a private network, through Gateway, a user can directly connect to private IP addresses and hostnames that are configured for that network.

I can then configure specific network firewall policies to allow or block traffic destined to private IP addresses.


Great! Looks like we’ve solved protecting private applications using Gateway. Not quite, unfortunately, as there are a few components of Gateway that are not an ideal model for an application-focused security model. While not discussed above, a few of the challenges we encountered when using Gateway for application access control included:

  • Private applications were mixed in with general Gateway network firewall rules, complicating configuration and maintenance

  • Defining and managing private applications was not possible in Terraform

  • Application access logs were buried in general network firewall logs (these logs can contain all Internet traffic for an organization!)

  • Enforcement within Gateway relied on specific WARP client sessions, which lacked granular identity details

  • Administrators couldn’t use Access Rule Groups or other Access features built specifically for managing application access controls

We knew we could do better.

A unified approach to application access

Knowing these limitations, we set out to extend Access to support any application, regardless of whether it is public or private. This principle guided our efforts to create a unified application definition in Cloudflare Access. Any self-hosted application, regardless of whether it is public or privately routable, should be defined in a single application type. The result is quite straightforward: Access Applications now support private IP addresses and hostnames.


However, the engineering work was not as simple as adding a private IP address and hostname option to Cloudflare Access. Given our platform’s architecture, Access does not have any way to route private requests by itself. We still have to rely on Gateway and the WARP client for that component.

An application-aware firewall

This meant that we needed to add an application-specific phase to Gateway’s firewall. The new phase detects whether a user’s traffic matches a defined application, and if so it sends the traffic to Access for authentication and authorization of a user and their session. This required extending Gateway’s network firewall to have knowledge of which private IP addresses and hostnames are defined as applications.

Thanks to this new firewall phase, now an administrator can configure exactly where they want their private applications to be evaluated in their overall network firewall.


Private application sessions

The other component we had to solve was per-application session management. In an Access public application, we issue a JSON Web Token (JWT) as a cookie which conveniently has an expiration associated. That acts as a session expiration. For private applications, we do not always have the ability to store a cookie. If the request is not over a browser, there is nowhere to put a cookie.

For browser-based private applications, we follow the exact same pattern as a public application and issue a JWT as a means to track the session. App administrators get the additional benefit of being able to do JWT validation for these apps as well. Non-browser based applications required adding a new per-application session to Gateway’s firewall. These application sessions are bound to a specific device and track the next time a user has to authenticate before accessing the application.


Access private applications

Once we solved application awareness and session management in Gateway’s firewall, we could extend Access to support private IP address- and hostname-defined applications. Administrators can now directly define Access applications using private IP addresses and hostnames:


You can see that private hostname and private IP address are now configuration options when defining an Access application.

If it is a non-HTTPS application (whether HTTP or non-browser), the user will receive a client pop-up prompting a re-authentication:


HTTPS applications will behave exactly the same as an Access application with a public hostname. The user will be prompted to log in via single sign-on, and then a JWT will be issued to that specific domain.


Then we see a JWT issued to the application itself.


Introducing Reusable Policies

As part of this work, we were able to address another long-standing pain point in Access —– managing policies across multiple applications was a time-consuming and error-prone process. Policies were nested objects under individual applications, requiring administrators to either rely heavily on Access Groups or repeat identical configurations for each application. 


With Reusable Policies, administrators can now create standardized policies — such as high, medium, or low risk — and assign them across multiple applications. A single change to a reusable policy will propagate to all associated applications, significantly simplifying management. With this new capability, we anticipate that many of our customers will be able to move from managing hundreds of access policies to a small handful. We’ve also renamed “Access Groups” to “Rule Groups,” aligning with their actual function and reducing confusion with identity provider (IdP) groups.

A redesigned user interface

Alongside these functional updates, we’ve launched a significant UI refresh based on years of user feedback. The new interface offers more information at a glance and provides consistent, intuitive workflows for defining and managing applications. 

Looking ahead

While today’s release is a major step forward, there’s more to come. Currently, private hostname support is limited to port 443 with TLS inspection enabled. Later in 2025, we plan to extend support to arbitrary private hostnames on any port and protocol, further broadening Access’s capabilities.

Get started today

These new Access features are live and ready for you to explore. If you haven’t yet started modernizing remote access at your organization, sign up for a free account to test it out. Whether you’re securing private resources or simplifying policy management, we’re excited to see how these updates enhance your Zero Trust journey. As always, we’re here to help — reach out to your account team with any questions or feedback.

Watch on Cloudflare TV

Improving Hugo stability and addressing oncall challenges through automation

Post Syndicated from Grab Tech original https://engineering.grab.com/improving-hugo-stability

Introduction

Hugo plays a pivotal role in enabling data ingestion for Grab’s data lake, managing over 4,000 pipelines onboarded by users. The stability of Hugo pipelines is contingent upon the health of both the data sources and various Hugo components. Given the complexity of this system, pipeline failures occasionally occur, necessitating user intervention when retry mechanisms prove insufficient. These incidents present challenges such as:

  • Limited user visibility into pipeline issues.
  • Uncertainty about resolution steps due to extensive documentation.
  • An overwhelmed Hugo on-call team dealing with ad-hoc requests and growing infrastructure dependencies.
  • Raised Data Production Issues (DPIs) lacking clear Root Cause Analysis (RCA), hindering effective management.

Such challenges ultimately increase data downtime due to prolonged issue triage and resolution times.

To address these problems, we conducted a thorough analysis of failure modes and the efforts required to resolve them. Based on our findings, we propose a comprehensive automation solution.

This blog outlines the architecture and implementation of our proposed solution, consisting of modules like Signal, Diagnosis, RCA Table, Auto-resolution, Data Health API, and Data Health WorkBench, each with a specific function to enhance Hugo’s monitoring, diagnosis, and resolution capabilities.

The blog further details the impact of these automated features, such as enhanced data visibility, reduced on-call workload, and concludes with our next steps, which focus on advancing auto-resolution strategies, enriching the Data Health Workbench, and broadening diagnostics to include more infrastructure components, like Flink, for comprehensive coverage.

Architecture details

We designed the solution based on these principles:

  1. Identify different failure modes based on past issues and analysis from first principles.
  2. Analyse temporal relationships of pipeline execution steps to diagnose issues to failure modes.
  3. Focus on auto-resolution, and add additional features to cover gaps which can’t be immediately addressed by auto-resolution or diagnosis.

The following diagram shows the solution we proposed.

Figure 1. Architecture

The architecture consists of five core modules, each with a specific function:

  1. Signal module: This module is responsible for collecting signals. It gathers three different types of signals that collectively define the health status of the data lake table. The signals include:
    • Failure callback signal: This indicates whether the pipeline runs involving this data lake table are successful or not.
    • SLA alert signal: This indicates whether the pipeline execution involving this data lake table meets the Service Level Agreement (SLA). For an hourly batch job, the expectation is to complete within one hour.
    • Data quality test failure signal: This represents various types of completeness checks to ensure that data lake tables are consistent with the source tables based on their pipeline strategies.
  2. Diagnosis module: This is the core module responsible for diagnosing the root cause of 3 types of failures collected in the Signal module. It determines:
    • The root cause of the failure.
    • The assignee responsible for fixing the error.
    • The auto-resolution method to fix the issue.
    • Manual resolution steps if the auto-resolution fails.
  3. RCA table: This module stores the following information:
    • Signals
    • Assignee information
    • Diagnosis results
    • Auto-resolution methods
    • Manual resolution steps
  4. Auto-resolution module: This module executes the auto-resolution methods to resolve issues automatically.
  5. Data health API: This module provides API access to other platforms. External platforms or pipelines that rely on Hugo onboarded tables can subscribe to the health status and investigate the root cause when a table is deemed unhealthy.
  6. Hugo pipeline health dashboard: A centralised dashboard for Hugo users to visualise the health status of tables, auto resolution status, and manual fix button.

By leveraging these modules, the architecture ensures robust monitoring, diagnosis, and resolution of issues, leading to improved data health and operational efficiency.

Implementation

Signal module

There are two methods for generating these three signals. The failure signal is generated through an airflow callback, while the SLA miss and data completeness test signals are produced by Genchi. Genchi is a data quality observability platform at Grab that performs data quality checks and acts as a crucial enabler for the enforcement of data contracts.

Diagnosis module

As soon as an alert is created, the diagnosis begins. To avoid lengthy diagnosis times, Hugo has developed an innovative approach that eliminates the requirement for parsing extensive logs, such as Spark executor logs or Airflow logs. Instead, it gathers signals transmitted by the computation engine or Grab’s internal platforms.

The diagnosis process can be time-consuming, even with efforts to reduce the time it takes. For example, the SLA diagnoser uses multiple analysers that run sequentially, and some of these analysers (like the Airflow analyser) make API calls that can take a significant amount of time. The more analysers that are involved in the diagnosis process, the longer it can take.

Figure 2. Diagnosis process

Parallelism in diagnosis serves as a solution to lower the overall latency when there is a surge in error traffic. The degree of parallelism differs based on the type of signal. For example, the failure signal diagnosis can be executed in thousands of processes at once, while for SLA miss and data quality test failures signals, the parallelism is determined by the number of partitions in the Kafka topic since these signals are received from Kafka.

Auto-resolution module

Auto-resolution is a flexible framework that enables the implementation of custom handlers for various types of failures. One of the common handlers employs a retry mechanism with backoff for transient errors. For instance, if Hugo receives a failure callback indicating that the root cause is a database replica lag, it would wait for an hour before re-triggering the job. This auto-resolution process runs asynchronously with the diagnosis process.

Data health API

The data health information includes a unique identifier, current status, error details, and the time of the last health check, providing a comprehensive snapshot of the dataset’s health.

Hugo converts the detailed information available in its internal data health API to the data health API specification format to be consumed by Kinabalu, our internal system designed to automate and streamline incident management processes by integrating with multiple systems such as Slack, Jira, Splunk on-call, and Datadog.

Hugo pipeline health dashboard

The Data Health Workbench is a centralised dashboard for Hugo users to visualise the health status of tables, auto-resolution status, and manual fix buttons. It provides a comprehensive view of data health and facilitates efficient issue resolution.

The key features are as follows:

  1. Health status visualisation: Displays the current health status of tables, making it easy to identify unhealthy tables.
  2. Assignee information: Indicates the assignee responsible for fixing the issue, ensuring clear accountability.
  3. How-to-fix guide: Provides step-by-step instructions on how to resolve the issue, empowering users to take immediate action.
  4. Action: Offers an action button to initiate the resolution process with a single click, streamlining issue resolution.
  5. Admin feature with detailed diagnosis information: Provides admins supplementary information, including the reasoning behind the root cause identification and assignee determination, which allows for a deeper understanding of the root cause of issues.

By leveraging the Data Health Workbench, Hugo users can efficiently monitor and manage data health, ensuring data integrity and operational efficiency.

Figure 3. Data Health Workbench

Impact

The implementation of Hugo’s auto-healing and diagnosis features has resulted in significant improvements in stability and operational efficiency for our data pipelines. Here are some key outcomes:

  • Enhanced data visibility: We’ve improved the visibility into the health of datasets, allowing for quick identification of issues and more informed decision-making.
  • Timely resolution of data issues: With automated diagnostic and resolution processes, we ensure that data issues are addressed promptly, minimising data downtime and enhancing overall data availability.
  • Reduced on-call workload: By automating many of the common failure resolutions, the workload on Hugo on-call teams has been significantly reduced. This allows teams to focus on more complex and impactful tasks.
  • Scalable solution for managing complexity: The auto-resolution framework is well-equipped to handle the increasing complexity of data infrastructure, offering scalable solutions for transient errors through custom handlers and retry mechanisms.
  • Improved data contract management: By providing detailed pipeline health information via the Data Health API, we enable precise and accurate DPIs, complete with root cause analysis and assignee information, enhancing the management and resolution of data contract breaches.
  • Valuable reference for other platforms: The insights and methodologies developed through this initiative provide a valuable reference for other platform teams at Grab looking to implement similar automation and diagnostic capabilities.
  • Support for Grab’s success: These enhancements support Grabbers by ensuring easy access to the datasets they need and contribute to the overall success of Grab through reliable data availability.

Next steps

Our next steps involve advancing auto-resolution strategies by focusing on complex solutions like pipeline runtime optimisation to boost efficiency and minimise processing delays. We will enrich the Data Health Workbench with detailed information, enabling users to visualise and understand pipeline health more effectively and make informed corrective actions. Additionally, we plan to broaden our diagnosis capabilities by integrating more infrastructure components, such as Flink health information, to ensure a comprehensive and holistic monitoring approach for all engines within Hugo.

Join us

Grab is a leading superapp in Southeast Asia, operating across the deliveries, mobility and digital financial services sectors. Serving over 800 cities in eight Southeast Asian countries, Grab enables millions of people everyday to order food or groceries, send packages, hail a ride or taxi, pay for online purchases or access services such as lending and insurance, all through a single app. Grab was founded in 2012 with the mission to drive Southeast Asia forward by creating economic empowerment for everyone. Grab strives to serve a triple bottom line – we aim to simultaneously deliver financial performance for our shareholders and have a positive social impact, which includes economic empowerment for millions of people in the region, while mitigating our environmental footprint.

Powered by technology and driven by heart, our mission is to drive Southeast Asia forward by creating economic empowerment for everyone. If this mission speaks to you, join our team today!

Critical Veeam Backup & Replication CVE-2025-23120

Post Syndicated from Rapid7 original https://blog.rapid7.com/2025/03/19/etr-critical-veeam-backup-and-replication-cve-2025-23120/

Critical Veeam Backup & Replication CVE-2025-23120

On Wednesday, March 19, 2025, backup and recovery software provider Veeam published a security advisory for a critical remote code execution vulnerability tracked as CVE-2025-23120. The vulnerability affects Backup & Replication systems that are domain joined. Veeam explicitly mentions that domain-joined backup servers are against security and compliance best practices, but in reality, we believe this is likely to be a relatively common configuration.

Veeam’s advisory indicates that the vulnerability is authenticated, though the CVSS score for CVE-2025-23120 is listed as 9.9. The advisory itself states that “authenticated domain users” can exploit the vulnerability but says little else — it’s possible that additional exploitation criteria will be published later on. According to Veeam, all supported versions of Backup & Replication are affected.

No public proof-of-concept exploit has been released (at time of this blog’s publication). Veeam Backup & Replication has a very large deployment footprint, and backup solutions are commonly targeted by threat actors. Veeam Backup & Replication should not be exposed to the internet and makes for a more effective internal attack vector than an external vector. Still, plenty of previous Veeam Backup & Replication vulnerabilities have been exploited in the wild, including by ransomware groups.

As we have mentioned previously, more than 20% of Rapid7 incident response cases in 2024 involved Veeam being accessed or exploited in some manner, typically once an adversary has already established a foothold in the target environment.

Mitigation guidance

Veeam Backup & Replication 12.3.0.310 and all earlier version 12 builds are vulnerable to CVE-2025-23120, per the vendor advisory.

Customers should update to the latest version of the software (12.3 build 12.3.1.1139) immediately, without waiting for a regular patch cycle to occur. Per the vendor, unsupported software versions were not tested but should be considered vulnerable.

Rapid7 customers

InsightVM and Nexpose customers will be able to assess their exposure to CVE-2025-23120 with a vulnerability check expected to be available in tomorrow’s (Thursday, March 20) content release.

GNOME 48 released

Post Syndicated from jzb original https://lwn.net/Articles/1014799/

GNOME 48 (“Bengaluru”)
has been released. As usual, this release includes a number of new
features and enhancements including support for shortcuts in the Orca
screen reader on Wayland, new fonts, addition of image editing to
Image Viewer, and more.

GNOME 48 includes a number of notable performance improvements. The
most significant of these is the introduction of dynamic triple
buffering. This change has undergone significant review and testing
over a period of five years and improves the perceived smoothness of
changes on screen, with fewer skipped frames and more fluid
animations. This has been achieved by enhancing the concurrency
capabilities of Mutter, the GNOME display manager, and is particularly
effective at handling sudden bursts of activity.

The GNOME 48 release also adds new applications to the GNOME Circle collection,
such as Drum Machine
and the Iotas note-taking
application. See “What’s new
for developers” a rundown of improvements for developers in
GNOME 48.

Apache Tomcat CVE-2025-24813: What You Need to Know

Post Syndicated from Caitlin Condon original https://blog.rapid7.com/2025/03/19/etr-apache-tomcat-cve-2025-24813-what-you-need-to-know/

Apache Tomcat CVE-2025-24813: What You Need to Know

Here at Rapid7, our usual bar for calling a vulnerability an emergent threat is either known exploitation at scale, or likelihood of exploitation at scale. Apache Tomcat CVE-2025-24813 fulfills neither of these criteria, despite a variety of news headlines alleging broad exploitation in the wild. Tomcat is widely deployed and has seen a number of severe vulnerabilities over the years that have had specific configuration dependencies for successful exploitation — this one follows the same pattern.

TL;DR: Patch, but there’s no need to panic. Here’s what you need to know:

  • CVE-2025-24813 is an unauthenticated remote code execution vulnerability in Apache Tomcat’s partial PUT feature disclosed on March 10, 2025. Fixed versions are available.
  • Under specific circumstances, successful exploitation allows attackers to execute code remotely on target systems via unsafe deserialization.
  • Vulnerability details and proof-of-concept (PoC) exploit code are both publicly available.
  • Based on our analysis and those of other research firms, the conditions required for successful exploitation appear to be specific, non-default, and uncommon.
  • CVE-2025-24813 has reportedly been exploited in the wild; however, Rapid7 has been unable to confirm any successful exploitation occurring against real-world production environments. We assess that “exploitation” in this context likely means unsuccessful exploit attempts rather than successful compromise of production systems.
  • Broad exploitation is unlikely given the specific vulnerable configuration requirements (see Exploitability requirements below).

Rapid7 researchers have tested publicly available PoC code and investigated the conditions Apache indicated were required for exploitation. Like other researchers, our team found that the vendor’s exploitable configuration information differs from what we observed during testing. Additionally, our team assessed the exploitable configuration to be relatively uncommon. Based on a GitHub code search query, only a small number of open-source Tomcat projects published publicly on GitHub are using write-enabled default servlet configurations (a pre-requisite for exploitation) — approximately 200, and most have fewer than 30 stars. Rapid7’s vulnerability research team has a full testing report here.

Exploitability requirements

Per the advisory, an attacker could view security sensitive files and/or inject content into those files if ALL of the following were true:

  • writes enabled for the default servlet (disabled by default)
  • support for partial PUT (enabled by default)
  • a target URL for security sensitive uploads that was a sub-directory of a target URL for public uploads (ed: Rapid7 and other researchers found this to be unnecessary for exploitation)
  • attacker knowledge of the names of security sensitive files being uploaded (ed: Rapid7 and other researchers found this to be unnecessary for exploitation)
  • the security sensitive files also being uploaded via partial PUT (ed: Rapid7 and other researchers found this to be unnecessary for exploitation)

An attacker could achieve remote code execution if ALL of the following were true:

  • writes enabled for the default servlet (disabled by default)
  • support for partial PUT (enabled by default)
  • application was using Tomcat’s file-based session persistence (ed: disabled by default) with the default storage location
  • application included a library that may be leveraged in a deserialization attack (ed: this is the case for many Java applications)

Mitigation guidance

The following versions of Apache Tomcat are affected:

  • Apache Tomcat 11.0.0-M1 to 11.0.2 (fixed in 11.0.3 or later)
  • Apache Tomcat 10.1.0-M1 to 10.1.34 (fixed in 10.1.35 or later)
  • Apache Tomcat 9.0.0.M1 to 9.0.98 (fixed in 9.0.99 or later)

For the latest information, please see the Apache Software Foundation’s advisory.

Rapid7 customers

InsightVM and Nexpose customers can assess their exposure to CVE-2025-24813 with pre-existing vulnerability checks.

The collective thoughts of the interwebz