evilsocket / shieldwall

zero-trust remote firewall instrumentation

ShieldWall embraces the zero-trust principle and instruments your server firewall to block inbound connections from every IP on any port, by default. The website allows you to push policies to your agents and temporarily unlock certain ports from your IP.

More on this project.

Quick Start

Follow the instructions here and then log into your https://shieldwall.me/ account to control the agent.

Compile from Sources

https://github.com/evilsocket/shieldwall/wiki

License

Released under the GPL3 license.

shieldwall's Issues

Logo in github dark mode is almost invisible

Not a really big issue, but the current logo being used for the readme is not easily visible in github's dark mode.
Currently it looks like this:

While there has been discussion for theme context images in GitHub forums, no conclusion seems to have come from it. In the meantime, a white border can be added to the logo to make it more visible (while preserving the same look for the light theme). Something like this:

The same looks nice (and also identical) for the other two themes too:

Same has been implemented by other projects too using a black logo: fastify, next.js.

Unable to set rule type to block

When trying to add a new agent or creating a new rule setting the rule to block does not work. By looking at the network request tab the web app sends a json request with type: allow every time. I am assuming there is an issue with vue js option tags.

Not working inside raspberry pi using docker.

Hello there again.

Inside a raspberry pi I have a docker containers. I have exposed the port 8989 to point to port 80 inside the docker container. So everytime I hit my host ip on port 8989 the request gets forwarded to port 80 inside the container. Shieldwall was unable to block that request.

[False-Positive] Agent loading error.

FP.

Shieldwall does not handle FORWARD chain

Hey and thanks for creating awesome project!

I'm having some difficulty shieldwalling my docker containers, I noticed that Shieldwall doesn't add an entry to FORWARD, so it doesn't get captured. Is this a bug?

# iptables -n -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
SHIELDWALL  all  --  0.0.0.0/0            0.0.0.0/0
LOGNDROP   all  --  0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy DROP)
target     prot opt source               destination
DOCKER-USER  all  --  0.0.0.0/0            0.0.0.0/0
DOCKER-ISOLATION-STAGE-1  all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
DOCKER     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
DOCKER     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain DOCKER (2 references)
target     prot opt source               destination
ACCEPT     tcp  --  0.0.0.0/0            172.18.0.2           tcp dpt:443
ACCEPT     tcp  --  0.0.0.0/0            172.18.0.2           tcp dpt:81

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target     prot opt source               destination
DOCKER-ISOLATION-STAGE-2  all  --  0.0.0.0/0            0.0.0.0/0
DOCKER-ISOLATION-STAGE-2  all  --  0.0.0.0/0            0.0.0.0/0
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Chain DOCKER-ISOLATION-STAGE-2 (2 references)
target     prot opt source               destination
DROP       all  --  0.0.0.0/0            0.0.0.0/0
DROP       all  --  0.0.0.0/0            0.0.0.0/0
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Chain DOCKER-USER (1 references)
target     prot opt source               destination
DROP       tcp  -- !127.0.0.1            0.0.0.0/0            tcp dpt:81
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Chain LOGNDROP (1 references)
target     prot opt source               destination
LOG        all  --  0.0.0.0/0            0.0.0.0/0            limit: avg 10/min burst 5 LOG flags 0 level 4 prefix "shieldwall-dropped: "
DROP       all  --  0.0.0.0/0            0.0.0.0/0

Chain SHIELDWALL (1 references)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     tcp  --  173.245.48.0/20      0.0.0.0/0            tcp dpt:443
[TRUNCATED - Cloudflare]
ACCEPT     tcp  --  127.0.0.1            0.0.0.0/0            tcp dpts:1:65535
ACCEPT     udp  --  127.0.0.1            0.0.0.0/0            udp dpts:1:65535

Thanks!

Question about whitelisting

Sorry to bother you again, but I am running a docker instance on the cloud server that is using shieldwall. I want to whitelist "172.17.0.1", but I'm not able to do so. In the config, it mentions lists of IP's to whitelist, do I add it like"

# list of ip addresses to always allow just in case
allow:
  - '127.0.0.1'
  - '172.17.0.1'

Or:

# list of ip addresses to always allow just in case
allow:
  - ['127.0.0.1', '172.17.0.1']

Release 1.0.3 missing agent.example.yaml

It didn't prevent me from setting up in the end, but using the lazy "I'll just copy the code from the quick start guide to get it working" failed on the install.sh step because it couldn't find agent.example.yaml (I did change the version from 1.0.0 in the quickstart to 1.0.3).

Just figured I'd let you know so you don't get more complaints.

Been looking for something like this for a while, love it!