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
- 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.
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:
- The server generates a random hex-encoded “prefix” and sends it along with the PoW Shield page to the client.
- 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)
- 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.
- The server starts proxying the now authenticated client traffic to the server with WAF filtering enabled.
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
| Variable | Type | Default | Description |
|---|---|---|---|
| PORT | General | 3000 | port that PoW Shield listens to |
| SESSION_KEY | General | secret key for cookie signatures, use a unique one for security reasons, or anyone can forge your signed cookies | |
| BACKEND_URL | General | location to proxy authenticated traffic to, IP and URLs are both accepted(accepts protocol://url(:port) or protocol://ip(:port)) | |
| DATABASE_HOST | Redis | 127.0.0.1 | redis service host |
| DATABASE_PORT | Redis | 6379 | redis service port |
| DATABASE_PASSWORD | Redis | null | redis service password |
| POW | PoW | on | toggles PoW functionality on/off (if not temporary switched off, why use this project at all?) |
| NONCE_VALIDITY | PoW | 60000 | specifies the maximum seconds a nonce has to be submitted to the server after generation(used to enforce difficulty change and filter out stale nonces) |
| DIFFICULTY | PoW | 13 | problem difficulty, number of leading 0-bits in produced hash (0:extremely easy ~ 256:impossible, 13(default) takes about 5 seconds for the browser to calculate) |
| RATE_LIMIT | Rate Limit | on | toggles ratelimit functionality on/off |
| RATE_LIMIT_SAMPLE_MINUTES | Rate Limit | 60 | specifies how many minutes until statistics reset for session/ip |
| RATE_LIMIT_SESSION_THRESHOLD | Rate Limit | 100 | number of requests that a single session can make until triggering token revocation |
| RATE_LIMIT_BAN_IP | Rate Limit | on | toggles ip banning functionality on/off |
| RATE_LIMIT_IP_THRESHOLD | Rate Limit | 500 | number of requests that a single session can make until triggering IP ban |
| RATE_LIMIT_BAN_MINUTES | Rate Limit | 15 | number of minutes that IP ban persists |
| WAF | WAF | on | toggles waf functionality on/off |
| WAF_URL_EXCLUDE_RULES | WAF | exclude rules to check when scanning request url, use ',' to seperate rule numbers, use '-' to specify a range (eg: 1,2-4,5,7-10) | |
| WAF_HEADER_EXCLUDE_RULES | WAF | 14,33,80,96,100 | exclude rules to check when scanning request header, use ',' to seperate rule numbers, use '-' to specify a range (eg: 1,2-4,5,7-10) |
| WAF_BODY_EXCLUDE_RULES | WAF | exclude rules to check when scanning request body, use ',' to seperate rule numbers, use '-' to specify a range (eg: 1,2-4,5,7-10) | |
| SSL | SSL | off | toggles SSL functionality on/off |
| SSL_CERT_PATH | SSL | tests/ssl/mock-cert.pem | path to SSL certificate password |
| SSL_KEY_PATH | SSL | tests/ssl/mock-key.pem | path to SSL key |
| SOCKET | Socket | off | toggles socket functionality on/off |
| SOCKET_URL | Socket | location of PoW Phalanx controller, IP and URLs are both accepted(accepts protocol://url:port or protocol://ip:port) | |
| SOCKET_TOKEN | Socket | subscription token for PoW Phalanx controller |
- 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
####################################################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.shThe following tests are are conducted on a single thread of a i7-10870H CPU with a 60 second period for each concurrent parameter.
| Concurrent Connections | Avg Latency | Error Rate | Requests/Second |
|---|---|---|---|
| 64 | 15.3ms | 0.0000 | 4188 |
| 128 | 30.2ms | 0.0000 | 4229 |
| 256 | 60.4ms | 0.0000 | 4235 |
| 512 | 122.6ms | 0.0142 | 4166 |
| 1024 | 261.7ms | 0.1766 | 3894 |
| 2048 | 1966.5ms | 0.4979 | 1027 |
| 4096 | 4685ms | 0.7179 | 838 |
| Concurrent Connections | Avg Latency | Error Rate | Requests/Second |
|---|---|---|---|
| 64 | 15.6ms | N/A | 4094 |
| 128 | 31.5ms | N/A | 4058 |
| 256 | 61.5ms | N/A | 4159 |
| 512 | 129.5ms | N/A | 3945 |
| 1024 | 264.4ms | N/A | 3858 |
| 2048 | 592.1ms | N/A | 3407 |
| 4096 | 1212.6ms | N/A | 3322 |
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.
- Proof-of-work by Fedor Indutny (PoW utility functions)
- Shadowd by Zesecure (WAF rules)
MIT