Application Change Analysis

Application change analysis will provide you a centralized view along with the analysis of all the recent changes for different components of a web app and its dependencies. Suppose you have noticed some downtime in your app caused by a changed App Setting, but you do not know what has caused the issue. So, you can enable this feature which help to identify the changes made to web application.

The changes it includes are both infrastructure and deployment. The changes are stored in azure storage called Azure Resource Graph database which includes infrastructure level changes. Another source that saves the changes is App Services back-end.

It takes the snapshot of your web app for every 4 hours. It clearly tells you who made the change and what it is in detail with date-time stamp. It is useful especially when multiple teams are working on same project.

Currently this feature is in public preview.

How to enable Change Analysis Feature

• Navigate to your Azure Web App in the Azure Portal
• Select Diagnose and Solve problems from the Overview Page and click on Health Check

• Click on Application Changes as shown in below image.

• It will open Application Changes and now enable your application changes as illustrated below.

• Whenever there will be any changes in the application, you can go to Application Changes again and click on Scan changes now.

Difference between Azure Front Door Service and Traffic Manager

Azure Front Door Service is Microsoft’s highly available and scalable web application acceleration platform and global HTTP(s) load balancer. Azure Front Door Service supports Dynamic Site Acceleration (DSA), SSL offloading and end to end SSL, Web Application Firewall, cookie-based session affinity, URL path-based routing, free certificates and multiple domain management.

In this article, I will compare Azure Front Door to Azure Traffic Manager in terms of performance and functionality.

Similarity:

Azure Front Door service can be compared to Azure Traffic Manager in a way that this also provides global HTTP load balancing to distribute traffic across different Azure regions, cloud providers or even with your on-premises.

Both AFD & Traffic Manager support:

1. Multi-geo redundancy: If one region goes down, traffic routes to the closest region without any intervention.
2. Closest region routing: Traffic is automatically routed to the closest region.

Differences:

1. Azure Front Door provides TLS protocol termination (SSL offload), and Azure Traffic Manager does not. It means AFDs take load off from the Web Front Ends, which do not have to encrypt or decrypt the request.
2. Azure Front Door provides application layer processing, and Azure Traffic Manager does not.
3. While using AFS, user will experience better performance than traffic manager as AFD uses Anycast, which provides lower latency, thereby providing higher performance.
4. AFD provides WAF feature for your application to provide security from DDoS attacks.
5. We can perform URL rewriting in Azure Front Door but not in Traffic Manager.
6. Traffic manager relies on DNS lookup for network routing while AFD uses reverse proxy which provides faster failover support.
7. AFD caches the static content while no caching mechanism is available in Traffic Manager.

Quick Summary:

Azure Front Door	Traffic Manager
Cross region redirection & availability.	Cross region redirection & availability.
SSL offload	No SSL offload
Uses Reverse proxy	Uses DNS lookup
Caches static content	No caching available
Uses AnyCast & Split TCP	Does not use such service
AFD provides WAF feature	No such feature
99.99% SLA	99.99% SLA

I hope this information helped you. In our next article, we will discuss how to create and use Azure Front Door service.

Cryptocurrency mining attack against Kubernetes clusters

Cryptojacking is the unauthorized use of someone else’s computer to mine cryptocurrency. Hackers are using ransomware-like tactics and poisoned websites to get your employees’ computers to mine cryptocurrencies. Several vendors in recent days have reported a huge surge in illegal crypto-mining activity involving millions of hijacked computers worldwide.

Kubernetes have been phenomenal in improving developer productivity. With lightweight portable containers, packaging and running application code is effortless. However, while developers and applications can benefit from them, many organizations have knowledge and governance gaps, which can create security gaps.

Some of the Past Cases of Cryptocurrency on Kubernetes cluster:

Tesla Case: The cyber thieves gained access to Tesla\’s Kubernetes administrative console, which exposed access credentials to Tesla\’s AWS environment. Once an attacker gains admin privilege of the Kubernetes cluster, he or she can discover all the services that are running, get into every pod to access processes, inspect files and tokens, and steal secrets managed by the Kubernetes cluster.

Jenkins Case: Hackers used an exploit to install malware on Jenkins servers to perform crypto mining, making over $3 million to date. Although most affected systems were personal computers, it’s a stern warning to enterprise security teams planning to run Jenkins in containerized form that constant monitoring and security is required for business critical applications.

Recently, Azure Security Center detected a new crypto mining campaign that targets specifically Kubernetes environments. What differs this attack from other crypto mining attacks is its scale: within only two hours a malicious container was deployed on tens of Kubernetes clusters.

There are three options for how an attacker can take advantage of the Kubernetes dashboard:

1. Exposed dashboard: The cluster owner exposed the dashboard to the internet, and the attacker found it by scanning.
2. The attacker gained access to a single container in the cluster and used the internal networking of the cluster for accessing the dashboard.
3. Legitimate browsing to the dashboard using cloud or cluster credentials.

How could this be avoided?

As per Microsoft\’s Recommendations, follow the below:

1. Do not expose the Kubernetes dashboard to the Internet: Exposing the dashboard to the Internet means exposing a management interface.
2. Apply RBAC in the cluster: When RBAC is enabled, the dashboard’s service account has by default very limited permissions which won’t allow any functionality, including deploying new containers.
3. Grant only necessary permissions to the service accounts: If the dashboard is used, make sure to apply only necessary permissions to the dashboard’s service account. For example, if the dashboard is used for monitoring only, grant only “get” permissions to the service account.
4. Allow only trusted images: Enforce deployment of only trusted containers, from trusted registries.

Refer: Azure Kubernetes Services integration with Security Center

Source: https://azure.microsoft.com/en-us/blog/detect-largescale-cryptocurrency-mining-attack-against-kubernetes-clusters/