Azure Web Application Firewall?

 

Azure Web Application Firewall?

Azure Web Application Firewall (WAF) on Azure Application Gateway provides centralized protection of your web applications from common exploits and vulnerabilities. Web applications are increasingly targeted by malicious attacks that exploit commonly known vulnerabilities. SQL injection and cross-site scripting are among the most common attacks.

WAF on Application Gateway is based on Core Rule Set (CRS) 3.1, 3.0, or 2.2.9 from the Open Web Application Security Project (OWASP).

What problem it'll solve for your application( Features)?

  • SQL-injection protection.
  • Cross-site scripting protection.
  • Protection against other common web attacks, such as command injection, HTTP request smuggling, HTTP response splitting, and remote file inclusion.
  • Protection against HTTP protocol violations.
  • Protection against HTTP protocol anomalies, such as missing host user-agent and accept headers.
  • Protection against crawlers and scanners.
  • Detection of common application misconfigurations (for example, Apache and IIS).
  • Configurable request size limits with lower and upper bounds.
  • Exclusion lists let you omit certain request attributes from a WAF evaluation. A common example is Active Directory-inserted tokens that are used for authentication or password fields.
  • Create custom rules to suit the specific needs of your applications.
  • Geo-filter traffic to allow or block certain countries/regions from gaining access to your applications.
  • Protect your applications from bots with the bot mitigation ruleset.
  • Inspect JSON and XML in the request body

https://docs.microsoft.com/en-us/azure/web-application-firewall/media/ag-overview/waf1.png

Image Source: https://docs.microsoft.com/en-us/azure/web-application-firewall

Protection

  • Protect your web applications from web vulnerabilities and attacks without modification to back-end code.
  • Protect multiple web applications at the same time. An instance of Application Gateway can host up to 40 websites that are protected by a web application firewall.
  • Create custom WAF policies for different sites behind the same WAF
  • Protect your web applications from malicious bots with the IP Reputation ruleset
  • read more on MSDN

Fund Transfer from WazirX to Binance and Vice Versa Free

 

How To Transfer Cryptocurrency, Coins From WazirX To Binance? A Step-by-step Procedure

WazirX was acquired by Binance, a worldwide cryptocurrency exchange, in November 2019. Binance is one of, if not the largest, cryptocurrency exchanges in the world. Binance has a number of innovative crypto trading capabilities that no other Indian crypto exchange has. Furthermore, Binance offers the largest cryptocurrency collection on their site, with more than 500 coins and tokens accessible for purchase. Users of WazirX who want to acquire more cryptocurrencies that aren't available on their platform but are available on Binance can do so by linking their Binance and WazirX accounts.


You should have account on both exchanges with same email id and/Or Mobile Number

Login to Binance

Go to Wallet >> Valina Options >> WazirX,  Below is the Binance Screen shot


Once you logged over WazirX using Binance  your both app will be connected to each other(No Cost so nothing to worried, both are the same company now)

then you will click, you will find following screen


Now you can transfer token or USDT or other allowed crypto between screen writhing few second with Zero Cost.

Transfer WazirX to Binance

Login to WazirX

 Go to my walled and Selected UDT pairs crypto like INR/USDT  click on withdraw, screenshot for the same



you will seed an option to send to Binace, select it and transfer token very fast , secure and absolutely now cost. 


You will get 10% Discount on your trading fee if you join with Below invitation


Binance Joining Link: https://accounts.binance.com/en/register?ref=GW4QZ68E



How to Make a Custom URL Shortener Using C# and .Net Core 3.1

C# and .Net Core 3.1:  Make a Custom URL Shortener


Since a Random URL needs to be random and the intent is to generate short URLs that do not span more than 7 - 15 characters, the real thing is to make these short URLs random in real life too and not just a string that is used in the URLs


Here is a simple clean approach to develop custom solutions


Prerequisite:  Following are used in the demo.


Add a class file named ShortLink.cs and put this code: here we are creating two extension methods.

public static class ShortLink
{
    public static string GetUrlChunk(this long key)=> 
        WebEncoders.Base64UrlEncode(BitConverter.GetBytes(key));

    public static long GetKeyFromUrl(this string urlChunk)=> 
        BitConverter.ToInt64(WebEncoders.Base64UrlDecode(urlChunk));
}


Here is the Calling Sample code 
using System;
using System.Text;
using Microsoft.AspNetCore.WebUtilities;

namespace UrlShorten
{
    class Program
    {
        static void Main(string[] args)
        {
              
            string value = "SOME MEANING DYNAMIC/STATIC CONTENT";
            // Convert the string into a byte[].
            byte[] asciiBytes = Encoding.ASCII.GetBytes(value);
            long temp = 0;
            foreach (var item in asciiBytes)
                temp += item;
            // key = Tiks + sub of string bytes: that will be always unique
          var key = DateTime.UtcNow.Ticks + temp;
            Console.WriteLine($"Dynamic Key: {key}");
            var generatedUrl = key.GetUrlChunk();
            Console.WriteLine($"Generated URL: {generatedUrl}");
            Console.WriteLine($"Key From URL: {generatedUrl.GetKeyFromUrl()}");
            Console.ReadKey();
        }
    }
}

Here is the final output


c# Copy an Azure Storage blob into Subfolder or Subdirectories

 Copying All Blob of given Container into the same container and under subfolder?

Here are few key points about the copying blob in Azure Storage Account:

  • When you copy a blob within the same storage account, it's a synchronous operation.
  •  When you copy across accounts it's an asynchronous operation.
  • The source blob for a copy operation may be a block blob, an append blob, a page blob, or a snapshot. If the destination blob already exists, it must be of the same blob type as the source blob. An existing destination blob will be overwritten.
  • The destination blob can't be modified while a copy operation is in progress. A destination blob can only have one outstanding copy operation. In other words, a blob can't be the destination for multiple pending copy operations.


To copy a blob, call one of the following methods:

  • StartCopyFromUri
  • StartCopyFromUriAsync

We are using  .Net Core 3.1

Step  1Install-Package Azure.Storage.Blobs -Version 12.10.0

Step 2:  use the following code to move your container (named images)file into the same container  under a subfolder name called 

for example, if your current file store in images/my-pic.png this code will move to images/my-folder/my-pic.png


private static async Task CopyBlobToSubFolderAsync(BlobContainerClient container)
{
    
        // Get the name of the first blob in the container to use as the source.
        string blobName = container.GetBlobs().FirstOrDefault().Name;

        // Create a BlobClient representing the source blob to copy.
        BlobClient sourceBlob = container.GetBlobClient(blobName);

        // Ensure that the source blob exists.
        if (await sourceBlob.ExistsAsync())
        {
            // Lease the source blob for the copy operation 
            // to prevent another client from modifying it.
            BlobLeaseClient lease = sourceBlob.GetBlobLeaseClient();

            // Specifying -1 for the lease interval creates an infinite lease.
            await lease.AcquireAsync(TimeSpan.FromSeconds(-1));

            // Get the source blob's properties and display the lease state.
            BlobProperties sourceProperties = await sourceBlob.GetPropertiesAsync();

            // Get a BlobClient representing the destination blob with a unique name.
            BlobClient destBlob = 
                container.GetBlobClient("my-folder/" + sourceBlob.Name);

            // Start the copy operation.
            await destBlob.StartCopyFromUriAsync(sourceBlob.Uri);

            // Get the destination blob's properties and display the copy status.
            BlobProperties destProperties = await destBlob.GetPropertiesAsync();

         
            // Update the source blob's properties.
            sourceProperties = await sourceBlob.GetPropertiesAsync();

            if (sourceProperties.LeaseState == LeaseState.Leased)
            {
                // Break the lease on the source blob.
                await lease.BreakAsync();

                // Update the source blob's properties to check the lease state.
                sourceProperties = await sourceBlob.GetPropertiesAsync();
            }
        }   
}



Challenges of Microservices and When To Avoid Them

 When not to use microservices?


  • Your defined domain is unclear or uncertain
  • Improved efficiency isn’t guaranteed
  • Application size is small or uncomplex


Challenges of Microservices


Microservices could be more expensive than monolithic applications.

A poor design may lead to:
  • Increased latency
  • Reduced speed of calls across different services
  • A cascading failure may overwhelm your server
  • Poorly breaking down a module into microservices 
  • Handling Distributed Transactions in the Microservice

Running overproduction





Disclaimer: following above screenshots from pluralsight.com

What Are Deployment Strategies?

 What Are Application Deployment Strategies?

An application deployment strategy is a way to upgrade an application with the new version of code. The aim is to make the changes without downtime in a way that the user barely notices the improvements.

In this post, we are going to talk about the following strategies:

  1. Recreate: Version A is terminated and then version B is rolled out.
  2. Ramped (rolling-update/incremental): Version B is slowly rolled out and replacing version A.
  3. Blue/Green: Version B is released alongside version A, then the traffic is switched to version B.     A canary deployment consists of gradually shifting production traffic from version A to version B. Usually, the traffic is split based on weight. For example, 90 percent of the requests go to version A, 10 percent go to version B.
  4. Canary: Version B is released to a subset of users, then proceeds to a full rollout.
  5. A/B testing: Version B is released to a subset of users under specific conditions.
  6. Shadow: Version B receives real-world traffic alongside version A and doesn’t impact the response.

Ramped/Rolling update/Incremental

The ramped deployment strategy consists of slowly rolling out a version of an application by replacing instances one after the other until all the instances are rolled out. It usually follows the following process: with a pool of version A behind a load balancer, one instance of version B is deployed. When the service is ready to accept traffic, the instance is added to the pool. Then, one instance of version A is removed from the pool and shut down.

Pros:
  • Easy to set up.
  • Version is slowly released across instances.
  • Convenient for stateful applications that can handle rebalancing of the data.

Cons:
  • Rollout/rollback can take time.
  • Supporting multiple APIs is hard.
  • No control over traffic.

Blue/Green

Version B is released alongside version A, then the traffic is switched to version B.     A canary deployment consists of gradually shifting production traffic from version A to version B. Usually, the traffic is split based on weight. For example, 90 percent of the requests go to version A, 10 percent go to version B.

Pros:
  • Instant rollout/rollback.
  • Avoid versioning issue, the entire application state is changed in one go.
Cons:
  • Expensive as it requires double the resources.
  • Proper test of the entire platform should be done before releasing to production.
  • Handling stateful applications can be hard.


Canary

A canary deployment consists of gradually shifting production traffic from version A to version B. Usually, the traffic is split based on weight. For example, 90 percent of the requests go to version A, 10 percent go to version B.

This technique is mostly used when the tests are lacking or not reliable or if there is little confidence about the stability of the new release on the platform.

Pros:
  • Version released for a subset of users.
  • Convenient for error rate and performance monitoring.
  • Fast rollback.
Con:
  • Slow rollout

A/B testing 

A/B testing deployments consist of routing a subset of users to a new functionality under specific conditions. It is usually a technique for making business decisions based on statistics, rather than a deployment strategy. However, it is related and can be implemented by adding extra functionality to a canary deployment so we will briefly discuss it here. This technique is widely used to test the conversion of a given feature and only roll out the version that converts the most.
 Here is a list of conditions that can be used to distribute traffic amongst the versions:
  • By browser cookie 
  • Query parameters 
  • Geolocalisation 
  • Technology support: browser version, screen size, operating system, etc. 
  • Language

How to fix Kubernetes CrashLoopBackOff

 How to debug/troubleshoot and fix Kubernetes CrashLoopBackOff?

Step 1:

run kubectl describe pod <REPLACE YOUR POD NAME HERE> will give us more information on that pod:

kubectl describe pod nginx-5796d5bc7c-xsl6p --namespace nginx-crashloop
Name:           nginx-5796d5bc7c-xsl6p
Namespace:      nginx-crashloop
Node:           ip-10-0-9-132.us-east-2.compute.internal/10.0.9.132
Start Time:     Tue, 11 Aug 2021 19:11:05 +0200
Labels:         app=nginx-crashloop
                name=nginx
                pod-template-hash=1352816737
                role=app
Annotations:    kubernetes.io/created-by={"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"ReplicaSet","namespace":"nginx-crashloop","name":"nginx-5796d5bc7c","uid":"fb9e9518-f542-11e7-a8f2-065cff0...
Status:         Running
IP:             10.47.0.15
Controlled By:  ReplicaSet/nginx-5796d5bc7c
Containers:
  nginx:
    Container ID:   docker://513cab3de8be8754d054a4eff45e291d33b63e11b2143d0ff782dccc286ba05e
    Image:          nginx
    Image ID:       docker-pullable://nginx@sha256:c4ee0ecb376636258447e1d8effb56c09c75fe7acf756bf7c13efadf38aa0aca
    Port:           <none>
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Tue, 11 Aug 2021 19:13:15 +0200

That will help to understand the issue.

Most of the cases you will find are related to configuration issues in deployment.yaml file.
For I found the reference key for the database password was wrong in myapp.yaml file.
I fixed and redeployed I got fixed this issue. here is hilighted key that was wrong earlier.

apiVersionapps/v1
kindDeployment
metadata
  namemongo-express
  labels:
    appmongo-express
spec:
  replicas2
  selector:
    matchLabels:
      appmongo-express    
  template:
    metadata:
      labels:
        appmongo-express
    spec:
      containers:
      - imagemongo-express
        imagePullPolicyIfNotPresent
        namemongo-express
        ports:
        - containerPort8081
        env:
        - nameME_CONFIG_MONGODB_ADMINUSERNAME
          valueFrom:
            secretKeyRef:
              namemongodb-secrete
              keymongo-root-username
        - nameME_CONFIG_MONGODB_ADMINPASSWORD 
          valueFrom:
            secretKeyRef:
              namemongodb-secrete
              keymongo-root-password
        - nameME_CONFIG_MONGODB_SERVER 
          valueFrom:
            configMapKeyRef:
              namemongodb-map
              keydatabase_url
---
apiVersionv1
kindService
metadata:  
  namemongo-express-service
spec:
  selector:
    appmongo-express
  typeLoadBalancer
  ports:
    - protocolTCP
      port8081
      targetPort8081
      nodePort30002