Understanding the framework

The Framework

The Web Application Framework works by understanding the nature of a requests and maps the request to plausible activity specific to your application. If the request is malicious, if the reputation of the requester or of the device used is cause of concern, or the geographical location is not appropriate... Then the request may be re-directed, rejected or can be allowed for a defined amount of requests.

Associate

Human

Crawler

BOT

Tag & Label

Search engine
Location discovery

Pass request

redirect

Block

Minifier

Geo-Aware

Tag-Helpers

Monitoring

Data storage

The framework works with a set of core classes that you are able to use for configuring your application's security design as well as classes that are accessible to you that you can use to monitor, interact, or overwrite the firewall response.

The most important interfaces

There are several classes in each framework that you will end-up using the most, of those classes in the WAF framework you are likely to use IPageRequest and IFireWall the most. The WAF Framework processes a request in a work flow with 4 distinct activities as described in steps 2,3,4, and 6 of the Web Request Workflow.

using Microsoft.AspNetCore.Mvc;
using System.Collections.Generic;
using Walter.Web.FireWall;

namespace ASP_WAF.Controllers
{
    public class FireWallController : Controller
    {
        IFireWall _fireWall;
        public FireWallController(IFireWall fireWall)
        {
            _fireWall = fireWall;
        }
        public IActionResult Index()
        {
            return View();
        }

        public IActionResult LookWhoIsTalking()
        {
            var report = _fireWall.GetReport(Walter.Web.FireWall.Reporting.ReportTypes.Talking);
            IEnumerable<Walter.Net.LookWhosTalking.TcpProcessHistoricRecord> talking = report.Details.Talking;
            return View(talking);
        }
    }
}

namespace MyWeb.Controllers
{
    using Walter.Web.FireWall;
    using Walter.Web.FireWall.Models;
    public class HomeController : Controller
    {
        private readonly IPageRequest _page;

        public HomeController(IPageRequest page)
        {
            _page = page;
        }
        
        [HttpGet]
        public async Task<IActionResult> Index()
        {
            //get and set GDPR safe cyphered data from the cookie
            if (!_page.User.TryReadCookie("Telephone", out var phone))
            {
                phone = "001.123.567.89 ext 123";
            }
            await _page.User.WriteCookieAsync("Telephone", phone, TimeSpan.FromSeconds(60)).ConfigureAwait(false);
            return View();
        }
        [HttpGet]
        [Ignore(skip: FireWallGuardModules.ALL,skipCount:5)]
        public IActionResult Error()
        {            
            return View(_page.Exceptions);
        }

        [HttpGet]
        [Ignore(skip: FireWallGuardModules.ALL,skipCount:5)]
        public IActionResult Blocked()
        {    
            IReadOnlyList<FireWallStackItem> model = _page.ViolationsStack;        
            return View(model);
        }
    }
}

Two protection layers

The firewall framework consists of 2 layers of functionality that can be configured independently.

• Layer 1: This layer consist of several Guard Modules that analyses the requesting source as well as the responses send back and monitors its activity passively.
• Layer 2: The 2^nd layer makes use of at runtime generated JavaScript and collects data on user interaction as well as the device being used and can therefore only be used by web applications that have a user interface. The 2^nd layer brings additional functionality that you can make use of. The nature of the data collected make it ideal for the use in web statistics as it identifies the browser and enabled HTML features, the type of user, as well as document the interactions and view time spend on each page.

This documentation tells you how to set this up assuming you have a web application that has both REST API as well as render razor pages to users where the users might be using either or both endpoints like a application with Ajax functionality.

There are many ways to solve the same problem using different approaches and we will show with several code samples on how to integrate the firewall framework and how easy this can be implemented using simple scenarios. We also cover the topic of reporting and those annoying troubleshooting tasks that you have to deal with when you are confronted with behaviors that you are not expecting.

Rules - and Endpoint Configurations

The framework uses default rules as well as, annotations and helpers to override or extend the default rules to control access to resources in a .Net application. At the resource level, like actions, pages or REST services. The firewall can be on by default or it can be used to protect only certain endpoints only. One uses this in endpoint protection the same way you would use the Authorization attribute.

Classifications

The firewall framework enables you to interact with requests and possibly alter the response based on user labeling

1. based on the device they use and it's capabilities.
2. the device performance.
3. request behavioral patterns.
4. Honey-Pot interaction.
5. Interaction, or attempts of interactions with the server and ports the requested user are interacting with.
6. Geography and ISP used as well as the trace-rout used for the communication

The 2 central classes that you most likely going to interact with are the IPageRequest as well as the IFireWall. Both classes can be accessed via injected using the dependency framework.

Inside a razor page, you can use attributes inside your normal HTML tags to condition if a tag is rendered for a given country, or type of user. We try and classify users in Search Engines, Humans, or Automated Bots as soon as possible allowing you to adjust your content for it.

Configuring it all

You can configure the rules in the FireWall Configuration as well as in annotation direct on your controllers or the actions in your controllers. Once a “violation” of the “rules” is detected you have the opportunity to:

1. Never reply to the request and make it time-out on the requesters side, this is effective in dealing with, and the blocking of bots. Bots that are scrubbing data normally deal with HTTP error codes quite well, having them wait slows them down dramatically. Not getting an error code does make it harder for the bots to work with your content.
2. Block the request and generate a 50x HTTP response, this saves CPU time and resources by just not answering malicious consumers. Also bots may think the site is down.
3. Return a 40x HTTP response informing the consumer something went wrong.
4. Redirect the request to another location, this can be used to validate the user to content he is allowed to see or allows the user to interact with the system in a way you find appropriate.
5. Allow a user to violate a given rule for a fixed amount of times during a fixed period. This gives a request a “free pass” allowing you to make the firewall less strict and work with Framework HTML annotation to alter/ hide some of the content.