Description

PoW Shield provides DDoS protection on OSI application layer by acting as a proxy that utilizes proof of work between the backend service and the end user. This project aims to provide an alternative to general anti-DDoS methods such as Google's ReCaptcha that has always been a pain to solve. Accessing a web service protected by PoW Shield has never been easier, simply go to the url, and your browser will do the rest of the verification automatically for you.

PoW Shield aims to provide the following services bundled in a single webapp / docker image:

• proof of work authentication
• ratelimiting and ip blacklisting
• web application firewall

(New) Article on LinkedIn

Featured on Pentester Academy TV

Story on Medium

Features

• Web Service Structure
• Proxy Functionality
• PoW Implementation
• Dockerization
• IP Blacklisting
• Ratelimiting
• Unit Testing
• WAF Implementation
• Multi-Instance Syncing (Redis)
• SSL Support

Supported via PoW Phalanx controller:

• Multi-instance Management
• Whitelist tokens
• Blacklist IP syncing
• Dynamic difficulty control
• Dashboard

Alternate implementation in Go PoW-Shield-Go (WIP) for stress testing purposes and future optimized production version.

How it Works

So basically, PoW Shield works as a proxy in front of the actual web app/service. It conducts verification via proof-of-work and only proxies authorized traffic through to the actual server. The proxy is easily installable, and is capable of protecting low security applications with a WAF.

Here’s what happens behind the scenes when a user browses a PoW Shield-protected webservice:

1. The server generates a random hex-encoded “prefix” and sends it along with the PoW Shield page to the client.
2. Browser JavaScript on the client side then attempts to brute-force a “nonce” that when appended with the prefix, can produce a SHA256 hash with the number of leading zero-bits more than the “difficulty” D specified by the server. i.e. SHA256(prefix + nonce)=0…0xxxx (binary, with more than D leading 0s)
3. Client-side JavaScript then sends the calculated nonce to the server for verification, if verification passes, the server generates a cookie for the client to pass authentication.
4. The server starts proxying the now authenticated client traffic to the server with WAF filtering enabled.

Configuration

You can configure PoW Shield via the following methods.

• nodejs: .env (example: .env.example)
• docker-compose: docker-compose.yaml (example: docker-compose.example.yaml)
• docker run: -e parameter

Environmental Variables

Usage

Nodejs

Prerequisites

• Docker ^19.0.0
• Nodejs ^14.0.0

# Clone repository
git clone https://github.com/RuiSiang/PoW-Shield.git

# Install dependencies
npm install

# Configure settings
cp -n .env.example .env
# Edit .env
nano .env

# Transpile
npm run build

#############################################
# Run with db (redis), recommended & faster #
# install redis first                       #
# sudo apt-get install redis-server         #
#############################################
npm start
#############################################

#############################################
#        Run without db (mock redis)        #
#############################################
npm run start:standalone # linux
npm run start:standalone-win # windows
#############################################

# Test functionalities(optional)
npm test

Docker (repo)

####################################################
# Docker run with db (redis), recommended & faster #
####################################################
docker run -p 3000:3000 -e BACKEND_URL="http://example.com" -d ruisiang/pow-shield
####################################################

####################################################
#        Docker run without db (mock redis)        #
####################################################
docker run -p 3000:3000 -e BACKEND_URL="http://example.com" -e NODE_ENV="standalone" -d ruisiang/pow-shield
####################################################

####################################################
#                  Docker Compose                  #
####################################################
# Copy docker-compose.example.yaml
cp -n docker-compose.example.yaml docker-compose.yaml
# Edit docker-compose.yaml
nano docker-compose.yaml

# Start the container
docker-compose -f docker-compose.yaml up
####################################################

Stress Test

Note: This only works on non-containerized version of PoW Shield, and that your system might experience unstability when running the test.

# Start the stress test
npm run stress

# If you changed the PORT variable in .env, you should also change the target variable in the stress test script
nano scripts/stress.sh

The following tests are are conducted on a single thread of a i7-10870H CPU with a 60 second period for each concurrent parameter.

Mass GET

Nonce Flood

From the above sample, we can see that the appropriate max load estimate for PoW Shield is around 512 concurrent connections. Error rates and latencies deteriorate beyond normal acceptance afterwards. Hence in a load-balanced environment on the machine (1 PoW Shield instance on each of it's 8 cores), it should be able to handle a maximum of approximately 4096 concurrent connections (clients) at a total request rate of 32k requests/second.

References

• Proof-of-work by Fedor Indutny (PoW utility functions)
• Shadowd by Zesecure (WAF rules)

License

MIT