Cyberattacks are constantly evolving in their sophistication, variety, and volume. The gap between the effort needed for a successful attack and the effort needed to protect an app is greater than ever before. The attacker has to find just a single flaw to exploit, while the protector must guard the entire gamut of components comprising an app. This asymmetry will only increase as app architectures become more complex.

As an IT admin, you might be managing on-prem solutions and cloud solutions. You might be migrating apps to the cloud. Or you might have tiered architecture or a mesh of microservices to manage. From a security perspective, you need to be able to adapt to each component’s footprint in the overall architecture, while providing a holistic view that includes traffic volume, the state of your app infrastructure, communication between the various components, and much more.

In this blog post, we’ll explore how Citrix Application Delivery Controller (ADC) and Citrix Application Delivery Management (ADM) can be used together to help secure the various components of your architecture and provide visibility into the traffic between these components and the app as a whole.

Citrix ADC comes in a variety of form factors — hardware, software, containerized, VM, and bare metal. It’s flexible enough to get in between tiered architectures and microservice meshes and can provide services like load balancing, caching, SSL offload, and more to optimize delivery and help to secure the microservice. Citrix ADC implements the entire networking stack, all homegrown from L1 to L7. Battle hardened over more than a decade of securing and delivering diverse apps, Citrix ADC defends and protects against a host of attacks aimed at various points in the networking stack and application layer.

Citrix ADC also tracks thousands of conditions and states, ranging from simple volume/velocity metrics such as how many requests are being served to details such as the number of times we’ve encountered a situation where we’ve had to retransmit a TCP packet multiple times.

With Citrix ADC, you have access to information you can use to enhance visibility into your entire networking stack, as well as into application behavior. This gives you a detailed view of what’s going on in a Citrix ADC and in an app, as well as provides a rich source for analytics and supports behavior modeling.

When managed by Citrix ADM, a Citrix ADC can serve up valuable information to admins. Each component in your architecture can be front-ended by a Citrix ADC, which can track the traffic climate, attacks, unusual behaviors, and component-specific delivery metrics. That data is relayed to Citrix ADM, which pieces it all together to give you an overview of the entire solution. For example, with this information, Citrix ADM provides a service graph that captures details of traffic flow and communication between various components of your architecture, as shown below.

It also powers our artificial intelligence / machine learning models. Each component has its own traffic peculiarities and norms. Using the historical data, we can derive behavioral models that can be used to detect and highlight unusual behaviors from a security point of view.

Securing Apps with Citrix ADC and Citrix ADM

To secure apps, we use a host of deterministic techniques as well as probabilistic models, and Citrix ADC packs powerful web app firewall and bot management capabilities. Detection techniques include signatures, IP reputation, geolocation, device fingerprinting, bot traps, blacklists, captcha, and more. The web app firewall protects against web attacks, detecting session poisoning, cookie/form-field tampering, injection attacks, cross-site scripting, sensitive information leaks, and more. These are then further buttressed with probabilistic models.

Citrix ADM service keeps tabs on historical traffic patterns for each component. It examines traffic vitals such as the data flowing in and out, concurrent connections, the total clients connecting, the number of clients connecting from each geo, the typical size of responses, and requests to the app, flagging any abnormalities. The models account for the ebb and flow of traffic at various points in the day and on different days of the week. If your app typically receives requests with response sizes in the range of 1KB to 4KB and suddenly there is a response going out that’s several megabytes, the models will automatically flag it as shown below. (Click image to view larger.) This can come in handy if someone manages to find a weakness to exploit in your app.

Individual client behaviors are also tracked along various parameters, and we use machine learning and statistical models to understand typical client behaviors. Clients that deviate from these often warrant a deeper look. For example, a web scanner tends to leave a behavioral footprint that is different from that of legitimate clients. We use unsupervised learners and clustering-based approaches to detect anomalies; legitimate clients tend to cluster well.

As much as admins should focus on external traffic parameters and L7, it’s also critical to consider lower networking layers. After all, a chain is only as strong as its weakest link. A simple way to trigger resource exhaustion is to conduct attacks that require an app to lock up a resources. For example, sending TCP packets out of order implies that the receiver needs to queue them as it waits for the missing bits. Out-of-order packets aren’t always a sign of an attack. But when you see a lot of them, you likely have a problem. Citrix ADC recognizes these situations and drops the requests. We let the customer know there has been an attack, as shown in the Citrix ADM dashboard below.

There are various attacks that exploit the same principle of not letting a connection/transaction complete. Slowloris (HTTP and DNS) trigger resource exhaustion by sending partial requests over several packets, slowly forcing the receiver to queue and wait for completion. Similarly, FragmentSmack is aimed at the IP layer and locks up resources with numerous IP fragments. You can use Citrix ADC to protect against these attacks, as well as against ICMP floods, UDP floods, and ARP poisoning.

Another common vector used in DoS attacks on an application is DNS. Because the protocol runs over UDP, it’s easy to spoof IP addresses and generate numerous queries to non-existent subdomains, triggering a flood of NXDOMAIN responses. Any downstream caches also quickly get flooded. Such scenarios are detected by the NXDOMAIN flood attack indicator. Citrix ADC enables you to limit caching, establish rate limits for DNS queries, and block queries based on patterns.

Together, Citrix ADC and Citrix ADM give you a versatile solution that can front-end and secure the components of your app architecture and adapting to each, all while delivering the holistic view you need. To learn more, check out he following resources: