tvh-linux/Custem-Firewall

Fork 0

Go to file

Tord-Vincent Heggland 056eedf680 keep empty firewall directories

2026-05-10 13:27:00 +02:00

chains

keep empty firewall directories

2026-05-10 13:27:00 +02:00

hooks

keep empty firewall directories

2026-05-10 13:27:00 +02:00

.gitignore

first

2026-05-10 13:15:32 +02:00

lib.sh

first

2026-05-10 13:15:32 +02:00

load-chains.sh

first

2026-05-10 13:15:32 +02:00

README.md

first

2026-05-10 13:15:32 +02:00

README.md

Firewall-oppsett for `/opt/firewall`

Dette repoet inneholder firewall-logikk for en Linux-host med iptables, Docker og eventuelt WireGuard.

Målet er at firewall-reglene skal være:

lesbare
flyttbare
enkle å ta backup av
mulige å versjonskontrollere med Git
trygge å laste inn flere ganger
adskilt fra systemets egne chains
mulig å laste automatisk ved boot med systemd

Repoet ligger her:

/opt/firewall

1. Hvorfor dette oppsettet finnes

Firewall-regler som skrives direkte i terminalen med iptables, finnes bare aktivt i kernel mens maskinen kjører.

Eksempel:

sudo iptables -A FORWARD -j ACCEPT

Dette er ikke nok som varig dokumentasjon eller drift.

Hvis maskinen rebooter, eller hvis reglene endres senere, er det lett å miste oversikt.

Derfor ligger firewall-logikken som filer i:

/opt/firewall

Da kan reglene:

leses
endres
kjøres på nytt
legges i Git
kopieres til en annen maskin
lastes automatisk med systemd

2. Filstruktur

Dette oppsettet bruker denne strukturen:

/opt/firewall
├── README.md
├── lib.sh
├── load-chains.sh
├── chains/
└── hooks/

Forklaring:

/opt/firewall/README.md

Dokumentasjon for hvordan firewall-oppsettet fungerer.

/opt/firewall/lib.sh

Felles hjelpefunksjoner som kan brukes av flere firewall-script.

Typiske funksjoner i lib.sh kan være:

sjekke om en chain finnes
lage en chain hvis den mangler
flushe egne chains
legge til regler uten duplikater
koble chains sammen

/opt/firewall/load-chains.sh

Hovedscriptet som laster firewall-reglene.

Dette er scriptet systemd bør kjøre ved boot.

/opt/firewall/chains/

Mappe for egne chain-filer.

Eksempel:

/opt/firewall/chains/wg-admin.sh
/opt/firewall/chains/wg-guest.sh
/opt/firewall/chains/docker-filter.sh

/opt/firewall/hooks/

Mappe for scripts som kan brukes av andre tjenester, for eksempel WireGuard PostUp, PostDown, eller egne systemd-hooks.

3. Hovedprinsipp

Systemet har egne chains med store bokstaver:

INPUT
OUTPUT
FORWARD
DOCKER
DOCKER-USER

Egne private chains bør bruke små bokstaver:

custom-forward
wg-admin
wg-guest
docker-filter

Dette gjør det lett å se forskjell på:

systemets egne chains
Docker sine chains
egne firewall-chains

4. Hvorfor bruke egne chains

Man bør ikke legge all logikk direkte i FORWARD.

Ryddigere prinsipp:

FORWARD
  -> custom-forward
       -> wg-admin
       -> wg-guest

For Docker:

DOCKER-USER
  -> docker-filter

Da kan egne chains ryddes og lastes inn på nytt uten å flushe hele systemets firewall.

Dette er spesielt viktig på maskiner som bruker:

Docker
WireGuard
SSH
Caddy
Pi-hole
andre nettverkstjenester

5. Idempotente regler

Firewall-script bør kunne kjøres flere ganger uten å lage duplikate regler.

Ikke gjør dette ukritisk:

iptables -A FORWARD -j custom-forward

Hvis scriptet kjøres fem ganger, får du fem like regler.

Bruk heller denne logikken:

iptables -C FORWARD -j custom-forward 2>/dev/null || iptables -A FORWARD -j custom-forward

Forklaring:

iptables -C sjekker om regelen finnes
hvis den ikke finnes, legges den inn med iptables -A
da kan scriptet kjøres flere ganger trygt

6. Rolle til `lib.sh`

lib.sh bør inneholde felles funksjoner.

Eksempel på typiske funksjoner:

chain_exists() {
    local chain="$1"
    iptables -L "$chain" -n >/dev/null 2>&1
}

ensure_chain() {
    local chain="$1"

    if ! chain_exists "$chain"; then
        iptables -N "$chain"
    fi
}

flush_chain() {
    local chain="$1"

    if chain_exists "$chain"; then
        iptables -F "$chain"
    fi
}

ensure_rule() {
    local chain="$1"
    shift

    if ! iptables -C "$chain" "$@" >/dev/null 2>&1; then
        iptables -A "$chain" "$@"
    fi
}

ensure_jump() {
    local from_chain="$1"
    local to_chain="$2"
    shift 2

    if ! iptables -C "$from_chain" "$@" -j "$to_chain" >/dev/null 2>&1; then
        iptables -A "$from_chain" "$@" -j "$to_chain"
    fi
}

Poenget med lib.sh er at chain-script slipper å gjenta samme hjelpefunksjoner.

7. Rolle til `load-chains.sh`

load-chains.sh er hovedscriptet.

Det bør gjøre omtrent dette:

sette trygg shell-modus
finne repo-path
source /opt/firewall/lib.sh
aktivere IPv4 forwarding hvis maskinen skal route trafikk
lage private chains
flushe bare egne private chains
koble egne chains inn i systemets chains
laste regler fra /opt/firewall/chains/

Eksempel på start:

#!/usr/bin/env bash
set -euo pipefail

BASE_DIR="/opt/firewall"

source "$BASE_DIR/lib.sh"

sysctl -w net.ipv4.ip_forward=1 >/dev/null

load-chains.sh bør være scriptet systemd kjører.

8. Eksempel på private chains

Vanlige private chains kan være:

custom-forward
wg-admin
wg-guest
docker-filter

Eksempel på oppretting:

ensure_chain custom-forward
ensure_chain wg-admin
ensure_chain wg-guest
ensure_chain docker-filter

Eksempel på rydding:

flush_chain custom-forward
flush_chain wg-admin
flush_chain wg-guest
flush_chain docker-filter

Viktig:

Bare egne chains bør flushes.

Ikke flush disse ukritisk:

INPUT
OUTPUT
FORWARD
DOCKER
DOCKER-USER

9. WireGuard-logikk

Eksempelnett:

wg-admin: 10.10.10.0/24
wg-guest: 10.10.11.0/24

Typisk logikk:

wg-admin:
  - får full forward-tilgang

wg-guest:
  - får begrenset tilgang
  - kan eventuelt få DNS
  - resten avvises

Eksempel:

ensure_jump custom-forward wg-admin -s 10.10.10.0/24
ensure_jump custom-forward wg-guest -s 10.10.11.0/24

ensure_rule wg-admin -j ACCEPT

ensure_rule wg-guest -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ensure_rule wg-guest -p udp -d 10.10.11.1 --dport 53 -j ACCEPT
ensure_rule wg-guest -p tcp -d 10.10.11.1 --dport 53 -j ACCEPT
ensure_rule wg-guest -j REJECT

Tilpass IP-adresser til eget oppsett.

10. Docker-logikk

Docker lager egne chains automatisk.

Vanlige Docker-chains:

DOCKER
DOCKER-USER
DOCKER-ISOLATION-STAGE-1
DOCKER-ISOLATION-STAGE-2

Egne Docker-regler bør normalt kobles inn via:

DOCKER-USER

Eksempel:

ensure_jump DOCKER-USER docker-filter

I docker-filter kan du legge egne regler.

Eksempel:

ensure_rule docker-filter -m conntrack --ctstate RELATED,ESTABLISHED -j RETURN
ensure_rule docker-filter -s 10.10.10.0/24 -j RETURN
ensure_rule docker-filter -j RETURN

RETURN betyr at trafikken går tilbake til Docker sin normale behandling.

11. Pi-hole og Docker

Hvis Pi-hole kjører i Docker bridge-nettverk, kan Pi-hole ofte se Docker gateway eller container-IP som klient, ikke ekte klient-IP.

For å se ekte klient-IP kan man vurdere:

host network
macvlan
kjøre Pi-hole direkte på host
bruke routing der klientens kilde-IP bevares

Dette README-et handler primært om firewall-logikken, ikke selve Pi-hole-oppsettet.

12. Manuell lasting av firewall

Kjør:

sudo /opt/firewall/load-chains.sh

Hvis scriptet ikke er kjørbart:

sudo chmod +x /opt/firewall/load-chains.sh

Kjør med debug:

sudo bash -x /opt/firewall/load-chains.sh

13. Se aktive regler

Vis regler som kommandoer:

sudo iptables -S

Vis regler med tellere:

sudo iptables -L -n -v

Vis NAT-regler:

sudo iptables -t nat -S

Vis Docker sin user-chain:

sudo iptables -S DOCKER-USER

14. Systemd-tjeneste

Systemd kan brukes til å laste firewall-reglene automatisk ved boot.

Tjenesten bør ligge her:

/etc/systemd/system/custom-firewall.service

Innhold:

[Unit]
Description=Custom firewall rules from /opt/firewall
Documentation=file:/opt/firewall/README.md
Wants=network-online.target
After=network-online.target docker.service

[Service]
Type=oneshot
ExecStart=/opt/firewall/load-chains.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

15. Lage systemd-tjenesten manuelt

Lag filen:

sudo nano /etc/systemd/system/custom-firewall.service

Lim inn:

[Unit]
Description=Custom firewall rules from /opt/firewall
Documentation=file:/opt/firewall/README.md
Wants=network-online.target
After=network-online.target docker.service

[Service]
Type=oneshot
ExecStart=/opt/firewall/load-chains.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Lagre filen.

Deretter:

sudo chmod +x /opt/firewall/load-chains.sh
sudo systemctl daemon-reload
sudo systemctl enable custom-firewall.service
sudo systemctl start custom-firewall.service

16. Forklaring av systemd-filen

Description=Custom firewall rules from /opt/firewall

Beskrivelse av tjenesten.

Documentation=file:/opt/firewall/README.md

Peker til denne dokumentasjonen.

Wants=network-online.target
After=network-online.target docker.service

Tjenesten starter etter at nettverk er oppe.

Hvis Docker finnes, starter firewall-oppsettet etter Docker. Dette er nyttig fordi Docker lager DOCKER-USER.

Type=oneshot

Scriptet kjøres én gang og avsluttes.

ExecStart=/opt/firewall/load-chains.sh

Dette scriptet laster firewall-reglene.

RemainAfterExit=yes

Systemd markerer tjenesten som aktiv etter at scriptet er ferdig.

Dette gir mening fordi reglene fortsatt ligger aktive i kernel.

WantedBy=multi-user.target

Gjør at tjenesten kan aktiveres ved vanlig boot.

17. Hvis firewall må starte før WireGuard

Hvis firewall-reglene må være klare før wg0 starter, kan man legge til:

Before=wg-quick@wg0.service

Da blir unit-filen:

[Unit]
Description=Custom firewall rules from /opt/firewall
Documentation=file:/opt/firewall/README.md
Wants=network-online.target
After=network-online.target docker.service
Before=wg-quick@wg0.service

[Service]
Type=oneshot
ExecStart=/opt/firewall/load-chains.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Ikke bruk Before=wg-quick@wg0.service hvis du ikke trenger det.

For mange oppsett holder det at firewall-reglene lastes etter nettverk og Docker.

18. Aktivere tjenesten

Etter at filen er laget:

sudo systemctl daemon-reload
sudo systemctl enable custom-firewall.service
sudo systemctl start custom-firewall.service

Sjekk status:

systemctl status custom-firewall.service

19. Etter endringer

Hvis du endrer script:

sudo systemctl restart custom-firewall.service

Hvis du endrer systemd-filen:

sudo systemctl daemon-reload
sudo systemctl restart custom-firewall.service

20. Stoppe tjenesten

sudo systemctl stop custom-firewall.service

Viktig:

Dette fjerner ikke nødvendigvis firewall-reglene fra kernel.

Siden tjenesten er Type=oneshot, betyr stop hovedsakelig at systemd ikke lenger markerer tjenesten som aktiv.

Hvis du vil fjerne regler, må du lage eget cleanup-script eller rydde egne chains manuelt.

Eksempel:

sudo iptables -F custom-forward
sudo iptables -F wg-admin
sudo iptables -F wg-guest
sudo iptables -F docker-filter

Ikke flush hele firewall-oppsettet ukritisk på en server du er koblet til over SSH.

21. Feilsøking

Sjekk status:

systemctl status custom-firewall.service

Se logger:

journalctl -u custom-firewall.service -xe

Se logger fra siste boot:

journalctl -b -u custom-firewall.service

Kjør script direkte:

sudo /opt/firewall/load-chains.sh

Kjør script med debug:

sudo bash -x /opt/firewall/load-chains.sh

Sjekk om en chain finnes:

sudo iptables -L custom-forward -n -v

Sjekk om en regel finnes:

sudo iptables -C FORWARD -j custom-forward

Sjekk Docker-chain:

sudo iptables -L DOCKER-USER -n -v

22. Backup

Ta backup av aktiv iptables-state:

sudo iptables-save > /opt/firewall/iptables-backup.rules

Men viktigste backup er selve repoet:

/opt/firewall/README.md
/opt/firewall/lib.sh
/opt/firewall/load-chains.sh
/opt/firewall/chains/
/opt/firewall/hooks/

Hvis /opt/firewall ligger i Git, kan oppsettet flyttes og reproduseres.

23. Flytte til annen maskin

Kopier repoet til:

/opt/firewall

Gjør scriptet kjørbart:

sudo chmod +x /opt/firewall/load-chains.sh

Lag systemd-tjenesten:

sudo nano /etc/systemd/system/custom-firewall.service

Lim inn:

[Unit]
Description=Custom firewall rules from /opt/firewall
Documentation=file:/opt/firewall/README.md
Wants=network-online.target
After=network-online.target docker.service

[Service]
Type=oneshot
ExecStart=/opt/firewall/load-chains.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Aktiver:

sudo systemctl daemon-reload
sudo systemctl enable custom-firewall.service
sudo systemctl start custom-firewall.service

Sjekk:

systemctl status custom-firewall.service
sudo iptables -S

24. Viktige regler

Ikke flush hele iptables ukritisk.

Ikke slett Docker sine chains manuelt.

Ikke legg permanente regler bare manuelt i terminalen.

Ikke bland admin-nett, guest-nett og Docker-regler uten tydelige chains.

Bruk egne chains for egen logikk.

La /opt/firewall/load-chains.sh være kilden til sannheten.

La systemd laste firewall-reglene ved boot.

README.md

Firewall-oppsett for /opt/firewall

1. Hvorfor dette oppsettet finnes

2. Filstruktur

3. Hovedprinsipp

4. Hvorfor bruke egne chains

5. Idempotente regler

6. Rolle til lib.sh

7. Rolle til load-chains.sh

8. Eksempel på private chains

9. WireGuard-logikk

10. Docker-logikk

11. Pi-hole og Docker

12. Manuell lasting av firewall

13. Se aktive regler

14. Systemd-tjeneste

15. Lage systemd-tjenesten manuelt

16. Forklaring av systemd-filen

17. Hvis firewall må starte før WireGuard

18. Aktivere tjenesten

19. Etter endringer

20. Stoppe tjenesten

21. Feilsøking

22. Backup

23. Flytte til annen maskin

24. Viktige regler

Firewall-oppsett for `/opt/firewall`

6. Rolle til `lib.sh`

7. Rolle til `load-chains.sh`