raspap-webgui icon indicating copy to clipboard operation
raspap-webgui copied to clipboard

[Bug]: Iptables firewall rules update to block traffic on abended tunnel

Open frankozland opened this issue 1 year ago • 3 comments

Code of Conduct

  • [X] I agree to follow this project's Code of Conduct.

Issue reporting checklist

Operating System

Raspberry Pi OS (64-bit) Lite Bookworm

Quick install or Manual setup?

Quick install

Onboard wireless chipset or external adapter?

Onboard wireless chipset

Hardware

Raspberry Pi 4 Model B

RaspAP version

3.1.3 (Latest)

Other software or services running with RaspAP?

Yes (specify below)

Contact details (optional)

[email protected]

Bug description

config/iptables_rules.json

        {
            "name": "firewall policies",
            "fw-state": true,
            "comment": "Policy rules (firewall)",
            "rules": [
                "-P INPUT DROP",
                "-P FORWARD ACCEPT",
                "-P OUTPUT ACCEPT",
                "-t nat -P PREROUTING ACCEPT",
                "-t nat -P POSTROUTING ACCEPT",
                "-t nat -P INPUT ACCEPT",
                "-t nat -P OUTPUT ACCEPT"
            ]

With '-P FORWARD ACCEPT' and any cli/openvpn/wg goes down, packets will still flow. Masquerade means "FORWARD ANY MEANS POSSIBLE"

So if tunnel dies, packets still traverse.

This should be changed to '-P FORWARD DROP'

2ndly - if i have already applied custom firewall rules, they should be honored vs raspap changing them. For example, in my firewall i specificed '-P FORWARD DROP'. RASPAP ignored what i configured and changed it to '-P FORWARD ACCEPT'.

I think Raspap should check to see if i have any rules that its about to change and give option not to change them if already set.

Steps to reproduce

install raspap apply personal custom firewall rules enable tunnel

Screenshots

No response

Additional context

No response

Relevant log output

No response

frankozland avatar Aug 24 '24 21:08 frankozland

There is a 2nd bug as well - wireguard only uses udp - so its ok to say -A INPUT -p UDP.

But openvpn allows both UDP and TCP. But i dont think -A INPUT -P is needed at all - in rules below, i left it in just for consistency, but removed the -p UDP.

What is happening is very easy to reproduce on either wireguard or openvpn. Simply stop wg if thats the tunnel or stop openvpn if thats the vpn tunnel.

Traffic will still flow.

Below is a better kill switch for both. If the tunnel drops, traffic stops.

The basic jist - MASQUERADE is a-ok but ONLY if traversing the vpn tunnel. If vpn tunnel isnt there? Any forwarded packet is dropped. If tunnel re-established? Packets flow.

In current ruleset as deployed - traffic will flow if the tunnel is there or not. For most users this will be not desired.

I think you also want to be sure to drop any tun+ to tun+ traffic (thats an attack), and wg+ to wg+ (same attack).

For custom CLI vpn, if you can identify the tunnel name from 'ip a' (or known from publisher), same rules will protect traffic to be sure it flows thru whatever tunnel name they create.

Confirmed with iptraf (sudo apt-get install iptraf)

            "name": "openvpn",
            "comment": "Rules for tunnel device (tun)",
            "ip-version": 4,
            "dependson": [
                  { "var": "openvpn-enable", "type": "bool" },
                  { "var": "openvpn-serverip", "type": "string", "replace": "$IPADDRESS$" },
                  { "var": "ap-device", "type": "string", "replace": "$INTERFACE$" }
            ],
            "rules": [
                "-A INPUT -s $IPADDRESS$ -j ACCEPT",
                "-A FORWARD -i tun+ -o wlan+ -j ACCEPT",
                "-A FORWARD -i tun+ -o tun+ -j DROP",
                "-A FORWARD -i wlan+ -o tun+ -j ACCEPT",
                "-A FORWARD -i eth+ -o tun+ -j ACCEPT",
                "-A FORWARD -i tun+ -o eth+ -j ACCEPT",
                "-t nat -A POSTROUTING -o $INTERFACE$ -j MASQUERADE",
                "-P FORWARD DROP"
            ]

        },
        {
            "name": "wireguard",
            "comment": "Rules for wireguard device (wg)",
            "ip-version": 4,
            "dependson": [
                  { "var": "wireguard-enable", "type": "bool" },
                  { "var": "wireguard-serverip", "type": "string", "replace": "$IPADDRESS$" },
                  { "var": "client-device", "type": "string", "replace": "$INTERFACE$" }
            ],
            "rules": [
                "-A INPUT -p udp -s $IPADDRESS$ -j ACCEPT",
                "-A FORWARD -i wg+ -o wlan+ -j ACCEPT",
                "-A FORWARD -i wg+ -o wg+ -j DROP",
                "-A FORWARD -i wlan+ -o wg+ -j ACCEPT",
                "-A FORWARD -i eth+ -o wg+ -j ACCEPT",
                "-A FORWARD -i wg+ -o eth+ -j ACCEPT",
                "-t nat -A POSTROUTING -o $INTERFACE$ -j MASQUERADE",
                "-P FORWARD DROP"
            ]
        }

frankozland avatar Aug 24 '24 22:08 frankozland

I dont know if i did this right - but i updated the json file with changes. I confirmed changes - stopping wireguard stopped all traffic. Restarted wireguard traffic flowed again.

https://github.com/RaspAP/raspap-webgui/pull/1650

frankozland avatar Aug 24 '24 22:08 frankozland

@frankozland thanks for this. the iptables_rules.json file is used by the Insiders edition, so the PR would need to be applied to this repo. The file was committed to this repo at some stage but is unused by the code. WG has an optional kill switch (also Insiders, for now) that's implemented with PostUp/PreDown scripts that apply identical iptables rules. Maybe the best move here is to implement an OpenVPN kill switch in the public repo.

billz avatar Aug 25 '24 15:08 billz

This issue is stale because it has been open for 30 days with no activity.

github-actions[bot] avatar Sep 25 '24 02:09 github-actions[bot]

This issue was closed because it has been inactive for 14 days since being marked as stale.

github-actions[bot] avatar Oct 10 '24 02:10 github-actions[bot]