fail2ban i unraid (container) - skriver iptables till container istället för host

Permalänk
Medlem

fail2ban i unraid (container) - skriver iptables till container istället för host

Har satt upp en fail2ban container (lscr.io/linuxserver/fail2ban) i unraid, jag har inte modifierat template något, så den har alltså redan "--cap-add=NET_ADMIN --cap-add=NET_RAW" som extra parameters och den körs på host nätverket. Den kommer dock som standard EJ inställt på privileged mode, men har även testat med det aktiverat, utan framgång.

När jag bannar något (fail2ban-client set jailname banip 1.2.3.4 t.ex) så "lyckas" bannen på så sätt att fail2ban tycker att det är ok och kollar man status på det jail man bannat IP på så står det t.ex "1 banned" och fail2ban.log säger att den har bannat det IP, men iptables hamnar på fail2ban containern och inte i hosten (unraid), således så blir ju ingenting faktiskt bannat i och med att inkommande inloggningsförsök inte går genom fail2ban.

har suttit i ett par dagar nu med allt från google och chatgpt till diverse olika forum och websökningar, men lyckas ta mej.. inte lösa det, så hoppas väl att någon här sitter med både unraid och fail2ban i en container och vet hur det ska lösas.

Permalänk
Hedersmedlem

fail2ban ska så klart köras på systemet där inloggningen sker, annars fyller det ingen funktion, eftersom det bannar utifrån misslyckade inloggningsförsök den ser i loggen på systemet där det körs.

Men en mycket bättre lösning är att stänga av lösenordsinloggning helt och bara tillåta inloggning med nyckel, då finns inget behov av att använda fail2ban alls.

Visa signatur

I am a prototype for a much larger s󠅄󠅘󠅕󠄐󠅞󠅕󠅕󠅔󠄐󠅤󠅟󠄐󠅒󠅕󠄐󠅟󠅒󠅣󠅕󠅢󠅦󠅕󠅔󠄐󠅑󠅞󠅔󠄐󠅥󠅞󠅔󠅕󠅢󠅣󠅤󠅟󠅟󠅔󠄐󠅧󠅑󠅣󠄐󠅟󠅞󠅓󠅕󠄐󠅣󠅑󠅤󠅙󠅣󠅖󠅙󠅕󠅔󠄐󠅒󠅩󠄐󠄷󠅟󠅔󠄞󠄐󠄾󠅟󠅧󠄐󠅧󠅕󠄐󠅓󠅑󠅞󠄐󠅙󠅝󠅠󠅜󠅕󠅝󠅕󠅞󠅤󠄐󠅤󠅘󠅕󠄐󠅣󠅑󠅝󠅕󠄐󠅖󠅥󠅞󠅓󠅤󠅙󠅟󠅞󠅑󠅜󠅙󠅤󠅩󠄐󠅧󠅙󠅤󠅘󠄐󠅔󠅑󠅤󠅑󠄝󠅝󠅙󠅞󠅙󠅞󠅗󠄐󠅑󠅜󠅗󠅟󠅢󠅙󠅤󠅘󠅝󠅣󠄞ystem

Permalänk
Medlem
Skrivet av Aphex:

fail2ban ska så klart köras på systemet där inloggningen sker, annars fyller det ingen funktion, eftersom det bannar utifrån misslyckade inloggningsförsök den ser i loggen på systemet där det körs.

Men en mycket bättre lösning är att stänga av lösenordsinloggning helt och bara tillåta inloggning med nyckel, då finns inget behov av att använda fail2ban alls.

Får känslan av att du kanske inte läste mitt inlägg?
Det ska gå att köra fail2ban som container och få den att ändra iptables på hosten genom att köra som host network med de nämnda extra parameters.

Dessutom handlar det inte om ssh eller något alls på hosten som ska övervakas.

Jag är inte ute efter andra lösningar. Jag är ute efter en lösning på problemet jag skapade tråden för.

Permalänk
Medlem

vilken container har du laddat ner eller har du gjort en egen container? detta framgår inte.

edit: om du kör fail2ban från linuxservier.io så låter det som att du glömt sätta --net=host om jag läser dokumentationen rätt.

Permalänk
Medlem
Skrivet av Vetulus:

vilken container har du laddat ner eller har du gjort en egen container? detta framgår inte.

edit: om du kör fail2ban från linuxservier.io så låter det som att du glömt sätta --net=host om jag läser dokumentationen rätt.

Alltså förlåt mig, men är det ingen på sweclockers som läser inläggen man gör längre innan de svarar? Det framgår i mitt inlägg både vilken container jag kör samt att jag kör den i host nätverk.

Jag kanske är trött och irriterad men det är rätt tröttsamt att i varje inlägg man gör få svara på massa onödiga svar där frågorna redan finns besvarade i det första inlägget (det här är LÅNGT IFRÅN första gången det händer).

Men för att vara överjävligt övertydliga så JA jag kör redan host network på fail2ban containern. Och det är linuxserver.io containern (som jag misstänker att du upptäckte eftersom du editerade inlägget)

Permalänk
Medlem
Skrivet av naaw:

Alltså förlåt mig, men är det ingen på sweclockers som läser inläggen man gör längre innan de svarar? Det framgår i mitt inlägg både vilken container jag kör samt att jag kör den i host nätverk.

Jag kanske är trött och irriterad men det är rätt tröttsamt att i varje inlägg man gör få svara på massa onödiga svar där frågorna redan finns besvarade i det första inlägget (det här är LÅNGT IFRÅN första gången det händer).

Men för att vara överjävligt övertydliga så JA jag kör redan host network på fail2ban containern. Och det är linuxserver.io containern (som jag misstänker att du upptäckte eftersom du editerade inlägget)

Jag förstår att du är frustrerad, man blir det oftast med XY Problem, men en workaround du kan göra nu är att köra något script som kopierar regler från containern till din host och jag skulle också rekommendera att du tar dig till forum/discord som linuxserver.io själva har skapat - det kanske finns en enkel förklaring som de känner till som vi andra inte gör då jag inte ens kände till att f2b fanns som en container då jag personligen inte riktig ser poängen med en container för detta.

Permalänk
Medlem
Skrivet av Vetulus:

Jag förstår att du är frustrerad, man blir det oftast med XY Problem, men en workaround du kan göra nu är att köra något script som kopierar regler från containern till din host och jag skulle också rekommendera att du tar dig till forum/discord som linuxserver.io själva har skapat - det kanske finns en enkel förklaring som de känner till som vi andra inte gör då jag inte ens kände till att f2b fanns som en container då jag personligen inte riktig ser poängen med en container för detta.

Ser inte att detta skulle vara ett XY-problem. Men ok, du får definiera det som du vill.

Ja jag får nog vända mig till deras discord istället.

Och för att jag är nyfiken, varför ser du inte någon poäng med att ha det i en container? Jag själv ser inte poängen med att lägga till saker direkt i hosten om jag inte absolut måste när man kan ha det i containers. Jag brukar vilja hålla mina hostar rena från allt annat än vad de är uppsatta att göra (köra docker, proxmox eller vad det nu kan vara.)

Permalänk
Medlem
Skrivet av naaw:

Ser inte att detta skulle vara ett XY-problem. Men ok, du får definiera det som du vill.

Ja jag får nog vända mig till deras discord istället.

Och för att jag är nyfiken, varför ser du inte någon poäng med att ha det i en container? Jag själv ser inte poängen med att lägga till saker direkt i hosten om jag inte absolut måste när man kan ha det i containers. Jag brukar vilja hålla mina hostar rena från allt annat än vad de är uppsatta att göra (köra docker, proxmox eller vad det nu kan vara.)

Jag tänker som jag gör då jag kommer från en plats då man använder container teknologi när man snabbt behöver en instans av något som man sedan även kan utöka horisontellt med flera instanser eller minska utan att behöva göra större systemändringar. Att bara köra en enstaka instans av något som alltid skall köras bör vara en del av host i mitt tycke då jag inte ser hur man kan vilja ha fler än 1 fail2ban på per host. Visst är det trevligt att hålla rent i systemet och dylikt men för att sätta det i perspektiv så är det för mig som att skala hela bananen, kasta skalet och sedan äta bananen med kniv och gaffel.

Permalänk
Hedersmedlem

När du säger

Citat:

iptables hamnar på fail2ban containern

hur ser du det?
Iptables-regler lever i kerneln och någon sådan finns inte i en docker-container, det är hostens kernel du pratar med när du kör programmet iptables i en container och NET_ADMIN-capabilityn är vad som tillåter dig att göra det.

Hur ser din output från
iptables -L
ut om du kör det i container resp på host?

Visa signatur

I am a prototype for a much larger s󠅄󠅘󠅕󠄐󠅞󠅕󠅕󠅔󠄐󠅤󠅟󠄐󠅒󠅕󠄐󠅟󠅒󠅣󠅕󠅢󠅦󠅕󠅔󠄐󠅑󠅞󠅔󠄐󠅥󠅞󠅔󠅕󠅢󠅣󠅤󠅟󠅟󠅔󠄐󠅧󠅑󠅣󠄐󠅟󠅞󠅓󠅕󠄐󠅣󠅑󠅤󠅙󠅣󠅖󠅙󠅕󠅔󠄐󠅒󠅩󠄐󠄷󠅟󠅔󠄞󠄐󠄾󠅟󠅧󠄐󠅧󠅕󠄐󠅓󠅑󠅞󠄐󠅙󠅝󠅠󠅜󠅕󠅝󠅕󠅞󠅤󠄐󠅤󠅘󠅕󠄐󠅣󠅑󠅝󠅕󠄐󠅖󠅥󠅞󠅓󠅤󠅙󠅟󠅞󠅑󠅜󠅙󠅤󠅩󠄐󠅧󠅙󠅤󠅘󠄐󠅔󠅑󠅤󠅑󠄝󠅝󠅙󠅞󠅙󠅞󠅗󠄐󠅑󠅜󠅗󠅟󠅢󠅙󠅤󠅘󠅝󠅣󠄞ystem

Permalänk
Medlem
Skrivet av Aphex:

När du säger hur ser du det?
Iptables-regler lever i kerneln och någon sådan finns inte i en docker-container, det är hostens kernel du pratar med när du kör programmet iptables i en container och NET_ADMIN-capabilityn är vad som tillåter dig att göra det.

Hur ser din output från
iptables -L
ut om du kör det i container resp på host?

från fail2ban containerns console:

root@Unraid:/# iptables -L # Warning: iptables-legacy tables present, use iptables-legacy to see them Chain INPUT (policy ACCEPT) target prot opt source destination f2b-audiobookshelf-auth tcp -- anywhere anywhere multiport dports https Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain f2b-audiobookshelf-auth (1 references) target prot opt source destination REJECT all -- 1.2.3.4 anywhere reject-with icmp-port-unreachable RETURN all -- anywhere anywhere root@Unraid:/#

från unraid terminalen:

root@Unraid:~# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination LIBVIRT_INP all -- anywhere anywhere Chain FORWARD (policy ACCEPT) target prot opt source destination LIBVIRT_FWX all -- anywhere anywhere LIBVIRT_FWI all -- anywhere anywhere LIBVIRT_FWO all -- anywhere anywhere DOCKER-USER all -- anywhere anywhere DOCKER-ISOLATION-STAGE-1 all -- anywhere anywhere ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED DOCKER all -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED DOCKER all -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED DOCKER all -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere WIREGUARD all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination LIBVIRT_OUT all -- anywhere anywhere Chain DOCKER (3 references) target prot opt source destination ACCEPT tcp -- anywhere 172.17.0.2 tcp dpt:7474 ACCEPT tcp -- anywhere 172.19.0.14 tcp dpt:http ACCEPT tcp -- anywhere 172.17.0.7 tcp dpt:http ACCEPT tcp -- anywhere 172.19.0.3 tcp dpt:8081 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:8443 ACCEPT udp -- anywhere 172.17.0.3 udp dpt:19132 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25500 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25501 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25502 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25503 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25504 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25505 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25506 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25507 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25508 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25509 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25510 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25511 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25512 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25513 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25514 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25515 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25516 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25517 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25518 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25519 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25520 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25521 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25522 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25523 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25524 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25525 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25526 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25527 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25528 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25529 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25530 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25531 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25532 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25533 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25534 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25535 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25536 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25537 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25538 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25539 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25540 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25541 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25542 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25543 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25544 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25545 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25546 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25547 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25548 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25549 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25550 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25551 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25552 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25553 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25554 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25555 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25556 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25557 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25558 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25559 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25560 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25561 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25562 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25563 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25564 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25565 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25566 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25567 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25568 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25569 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25570 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25571 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25572 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25573 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25574 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25575 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25576 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25577 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25578 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25579 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25580 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25581 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25582 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25583 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25584 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25585 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25586 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25587 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25588 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25589 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25590 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25591 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25592 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25593 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25594 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25595 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25596 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25597 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25598 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25599 ACCEPT tcp -- anywhere 172.17.0.3 tcp dpt:25600 ACCEPT tcp -- anywhere 172.19.0.12 tcp dpt:8181 ACCEPT tcp -- anywhere 172.19.0.5 tcp dpt:5055 ACCEPT tcp -- anywhere 172.19.0.11 tcp dpt:8989 ACCEPT tcp -- anywhere 172.19.0.9 tcp dpt:7878 ACCEPT tcp -- anywhere 172.19.0.6 tcp dpt:9696 ACCEPT tcp -- anywhere 172.19.0.4 tcp dpt:6246 ACCEPT tcp -- anywhere 172.19.0.7 tcp dpt:8080 ACCEPT tcp -- anywhere 172.19.0.7 tcp dpt:64223 ACCEPT udp -- anywhere 172.19.0.7 udp dpt:64223 ACCEPT tcp -- anywhere 172.19.0.2 tcp dpt:6767 ACCEPT tcp -- anywhere 172.19.0.15 tcp dpt:http ACCEPT tcp -- anywhere 172.19.0.15 tcp dpt:hosts2-ns ACCEPT tcp -- anywhere 172.19.0.15 tcp dpt:https ACCEPT tcp -- anywhere 172.17.0.8 tcp dpt:6501 Chain DOCKER-ISOLATION-STAGE-1 (1 references) target prot opt source destination DOCKER-ISOLATION-STAGE-2 all -- anywhere anywhere DOCKER-ISOLATION-STAGE-2 all -- anywhere anywhere DOCKER-ISOLATION-STAGE-2 all -- anywhere anywhere RETURN all -- anywhere anywhere Chain DOCKER-ISOLATION-STAGE-2 (3 references) target prot opt source destination DROP all -- anywhere anywhere DROP all -- anywhere anywhere DROP all -- anywhere anywhere RETURN all -- anywhere anywhere Chain DOCKER-USER (1 references) target prot opt source destination RETURN all -- anywhere anywhere Chain LIBVIRT_FWI (1 references) target prot opt source destination ACCEPT all -- anywhere 192.168.122.0/24 ctstate RELATED,ESTABLISHED REJECT all -- anywhere anywhere reject-with icmp-port-unreachable Chain LIBVIRT_FWO (1 references) target prot opt source destination ACCEPT all -- 192.168.122.0/24 anywhere REJECT all -- anywhere anywhere reject-with icmp-port-unreachable Chain LIBVIRT_FWX (1 references) target prot opt source destination ACCEPT all -- anywhere anywhere Chain LIBVIRT_INP (1 references) target prot opt source destination ACCEPT udp -- anywhere anywhere udp dpt:domain ACCEPT tcp -- anywhere anywhere tcp dpt:domain ACCEPT udp -- anywhere anywhere udp dpt:bootps ACCEPT tcp -- anywhere anywhere tcp dpt:bootps Chain LIBVIRT_OUT (1 references) target prot opt source destination ACCEPT udp -- anywhere anywhere udp dpt:domain ACCEPT tcp -- anywhere anywhere tcp dpt:domain ACCEPT udp -- anywhere anywhere udp dpt:bootpc ACCEPT tcp -- anywhere anywhere tcp dpt:bootpc Chain WIREGUARD (1 references) target prot opt source destination root@Unraid:~#

Permalänk
Hedersmedlem

Ok. Jag ger dig två möjligheter så får du undersöka vilken som är rätt:

1) f2b-containern är isolerad i en egen net namespace och du behöver kanske göra det här:
https://docs.docker.com/engine/security/userns-remap/#disable...

2) du har olika varianter av iptables i host och container, den ena modifierar nftables istället. Varningen om iptables-legacy ger en hint. https://developers.redhat.com/blog/2020/08/18/iptables-the-tw...

Berätta gärna om något av det hjälpte

Visa signatur

I am a prototype for a much larger s󠅄󠅘󠅕󠄐󠅞󠅕󠅕󠅔󠄐󠅤󠅟󠄐󠅒󠅕󠄐󠅟󠅒󠅣󠅕󠅢󠅦󠅕󠅔󠄐󠅑󠅞󠅔󠄐󠅥󠅞󠅔󠅕󠅢󠅣󠅤󠅟󠅟󠅔󠄐󠅧󠅑󠅣󠄐󠅟󠅞󠅓󠅕󠄐󠅣󠅑󠅤󠅙󠅣󠅖󠅙󠅕󠅔󠄐󠅒󠅩󠄐󠄷󠅟󠅔󠄞󠄐󠄾󠅟󠅧󠄐󠅧󠅕󠄐󠅓󠅑󠅞󠄐󠅙󠅝󠅠󠅜󠅕󠅝󠅕󠅞󠅤󠄐󠅤󠅘󠅕󠄐󠅣󠅑󠅝󠅕󠄐󠅖󠅥󠅞󠅓󠅤󠅙󠅟󠅞󠅑󠅜󠅙󠅤󠅩󠄐󠅧󠅙󠅤󠅘󠄐󠅔󠅑󠅤󠅑󠄝󠅝󠅙󠅞󠅙󠅞󠅗󠄐󠅑󠅜󠅗󠅟󠅢󠅙󠅤󠅘󠅝󠅣󠄞ystem

Permalänk
Medlem
Skrivet av Aphex:

Ok. Jag ger dig två möjligheter så får du undersöka vilken som är rätt:

1) f2b-containern är isolerad i en egen net namespace och du behöver kanske göra det här:
https://docs.docker.com/engine/security/userns-remap/#disable...

2) du har olika varianter av iptables i host och container, den ena modifierar nftables istället. Varningen om iptables-legacy ger en hint. https://developers.redhat.com/blog/2020/08/18/iptables-the-tw...

Berätta gärna om något av det hjälpte

tack, ska kolla på det ikväll när barnen sover och återkommer när jag har ett resultat.

Permalänk
Medlem
Skrivet av Aphex:

Ok. Jag ger dig två möjligheter så får du undersöka vilken som är rätt:

1) f2b-containern är isolerad i en egen net namespace och du behöver kanske göra det här:
https://docs.docker.com/engine/security/userns-remap/#disable...

2) du har olika varianter av iptables i host och container, den ena modifierar nftables istället. Varningen om iptables-legacy ger en hint. https://developers.redhat.com/blog/2020/08/18/iptables-the-tw...

Berätta gärna om något av det hjälpte

Länken med iptables informationen gjorde mig tyvärr inte särskilt smartare och kunde inte fånga upp i texten om det fanns någon idé om förändring jag kan göra. MEN jag testade att köra "iptables-nft -L" i unraid terminalen och då såg jag den ban jag gjort, som jag inte såg med iptables -L.

root@Unraid:~# iptables-nft -L # Warning: iptables-legacy tables present, use iptables-legacy to see them Chain INPUT (policy ACCEPT) target prot opt source destination f2b-audiobookshelf-auth tcp -- anywhere anywhere multiport dports https Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain f2b-audiobookshelf-auth (1 references) target prot opt source destination REJECT all -- 1.2.3.4 anywhere reject-with icmp-port-unreachable RETURN all -- anywhere anywhere

nu är jag ju oerhört okunnig inom detta så förstår inte riktigt vad som händer. Och om det nu är så att den faktiskt lägger till iptables korrekt så förstår jag inte varför jag fortfarande kan komma åt/logga in på tjänsten trots att IP är bannat (har så klart inte testat med 1.2.3.4 när jag testat "skarpt")

Permalänk
Medlem

Tittar man på github på konfigurationen som verkar vara gjord för den här containern så verkar den inte följa rekommendationen i fail2ban-dokumentationen för Docker+unraid.

Konfigurationen saknas i tråden så läsaren kan hur som helst bara gissa hur den ser ut i just din container.

Situationen är nog ungefär så här:

  • unraid (som bygger på Slackware?) kör både iptables-legacy/xtables och nft/nftables och låter användaren välja?

  • unraid har som filosofi att den inte ska ha en brandvägg utan skyddas av en extern brandvägg? Dokumentation för brandvägg saknas under "Security" i manualen.

  • Docker-projektet har aldrig uppgraderats till native nft, utan kör fortfarande iptables och hoppas på att kompabilitetslagret ska funka och inte ska göra användaren för förvirrad (yeah, right).

  • fail2ban-projektet kör nft i default-konfigurationen (github-repot), vilket är vettigt, via iptables-kommandot(?), vilket är sådär.

  • Containern är inte dokumenterat testad eller dokumenterad med avseende på vilken host den testats på, dvs iptables eller nft?

  • Du vet inte skillnaden mellan de två filtreringssystemen, hur de interagerar och vad iptables-kommandot pekar på på host respektive i container.

Goda förutsättningar för en Frankenbrandvägg.

Men det är nog inte problemet. Min gissning på varför regeln inte tar är att den hamnat i INPUT (till hosten) i stället för i FORWARD (till containern). Hade regeln matchats så skulle den fungerat oavsett interaktion mellan nftables och iptables/xtables, enligt dokumentationen. Så läs fail2ban-dokumentationen för Docker, om du nu måste köra via Docker.

Defence in depth är bra, men du har rimligen börjat med att se till att all åtkomst görs via VPN och helst att VPN:et är begränsat till vissa source-IP på edge. Sannolikheten att någon då blir "korrekt bannad" är ju nära noll.