Skip to content

Home

Jump to bottom
ASP-WAF Support Team edited this page Feb 21, 2021 · 1 revision

Why do you need an application firewall?

The nature of a web application is that your application and it's data is likely to be accessible from the world wide web via port 80 and port 443 for SSL requests. A hardware firewall does not understand your application and can't make a decision to block a request as it "makes no sense" it only sees an IP address accessing a port and will allow it, perhaps do some packet sniffing but that's it. In this Wiki we provide general documentation for the firewall and the plug-in that can be used to extend the firewall's functionality.

How does it work

The following image simplifies the workflow in the firewall framework showing the 6 steps a request will go through in the firewall. In the workflow, there are 4 basic steps: 1 The Rule Engine labels requests and tags them with firewall relevant data 2 The Guard engine decides what to do with the request 3 based on your configuration your application is presented with malicious requests, good requests are passed to your endpoint where you have access to all data via the API and in particular the IPageRequest interface 4 Data and decisions are then saved in the internal storage is used for monitoring, reporting and is used by the RuleEngine when processing the next request.

FrameWork

You know what requests make sense in your application

The firewall comes with Default rules and attributes that can be used to annotate rules on each action, page and controller

Rules are pre-populated but can be altered when you register the firewall using the IServiceCollection interface. You can read more on the rules configuration using the online documentation but basically, you will specify 2 policies, Request and Header when you are serving using non-api requests

services.AddFireWall<MyFireWall>(FireWallTrial.License, FireWallTrial.DomainKey, new Uri("https://www.mydomain.com", UriKind.Absolute), options =>
{
    //some of the rules that can be altered
    options.Rules.BlockedPatterns.NoPublicAccessToAdministration.Remove("Membership");
    options.Rules.BlockedPatterns.NotUsedPlugin.Add("DotNetNuke");

    options.Rules.BlockRequest.BlockDuration.RepeatViolations= RepeatViolations.DoublePerIncident;
    options.Rules.BlockRequest.StatusCode= ViolationStatusCode.InternalServerError;
    options.Rules.TolerateMaximumViolations = 5;
    options.Rules.TolerateMaximumViolationsIn = TimeSpan.FromMinutes(5);

    options.Rules.TerminateApplicationOnDiskManipulation = true;
    options.Rules.ViolationsExpireAfter = TimeSpan.FromDays(1);
    options.Rules.TrustedCrossSiteDomains.Add("https://www.myothersite.com");
}

The header configuration, because it can get quite complex comes with a helper as showcased in the bellow snipped

services.AddFireWall<MyFireWall>(FireWallTrial.License, FireWallTrial.DomainKey, new Uri("https://www.mydomain.com", UriKind.Absolute), options =>
{
    //other settings
    options.Rules.Headers.AddDefaultSecurePolicy()
                         .AddFrameOptionsDeny()
                         .AddStrictTransportSecurityNoCache()
                         .DoNotTrack()
                         .SimulateDifferentServer(Walter.Web.FireWall.Headers.ServerSimulation.Apache249Unix)
                         .SimulateDifferentTechnologyStack(Walter.Web.FireWall.Headers.StackSimulation.PHP)                     
                         .AddContentSecurityPolicyTrustOnlySelf();
}

The rules are enforced by the Guard Modules using Filters and Middleware

Clone this wiki locally