Hallo!
Habe da eine Frage/ein Problem mit meiner OPNSense!
Habe vor einiger Zeit die Hardware gewechselt und dann bei der Neuinstallation auf "ZFS" gewechselt - damit ich vor Updates die Sicherungsfunktion "boot environments" nutzen kann.
An meiner Installation/Einrichtung selbst habe ich eigentlich nicht wirklich was geändert - mit vorigen Installationen konnte ich also mein jetziges Problem nicht beobachten.
Die OPNSense lief 78 Tage seit dem letzten Update durch - vor ein paar Tagen habe ich dann wieder mal Updates gemacht und musste beim Einloggen feststellen, dass mein Datenträger quasi voll ist!
Habe daraufhin überall wo ich es gefunden habe, Trends/Logs/... gelöscht - hat nur ein paar GB gebracht.
Jetzt einige Tage später, ist nun meine SSD völlig voll!?
Woran könnte das liegen, bzw. wie gehe ich hier am Besten vor!?
Danke!
LG
Mach ma
zfs list
bectl list
Man sieht doch, dass der meiste Platz in /var/log belegt ist.
Also würde ich mich auf dem CLI anmelden und "du -sc --si /var/log/*" aufrufen, um zu sehen, welche Log-Dateien genau hier über alle Maßen anwachsen. Dann kann man sich die Logdateien ansehen und schauen, ob es wirklich ein Problem gibt oder ob irgendwo der Log-Level einfach zu hoch eingestellt ist.
Das kann man dann in der Web-GUI reduzieren (oder den Fehler beseitigen, falls einer da ist).
Man kann auch unter System: Settings: Logging -> Reiter "Statistics" nachsehen, ob für irgendeine Kategorie auffällig viele Einträge vorhanden sind.
Eine Möglichkeit, dafür zu sorgen, dass das Log niemals den Datenträger vollschreiben kann, ist, unter System: Settings: Miscellaneous die Logs nur ins RAM schreiben zu lassen. Dann werden die Logs nicht persistiert, aber das System bleibt dann immer lauffähig.
Quote from: meyergru on July 02, 2024, 06:43:16 PM
Man sieht doch, dass der meiste Platz in /var/log belegt ist.
Hier vertust du dich. Es sind insgesamt in dem Zpool noch rund 40M frei. Alles andere ist voll. Die Belegungs-Anzeigen der einzelnen Datasets sind "belegt" und "belegt plus diese 40M" und das ins Verhältnis gesetzt.
Kann bei ZFS verwirrend sein.
Schau auf die absoluten Zahlen. / sind 432G von 432G ...
Also @heiligst - bitte die Ausgabe der beiden Befehle. Danke.
Quote from: Patrick M. Hausen on July 02, 2024, 06:33:59 PM
Mach ma
zfs list
bectl list
Hallo!
Siehe Screenshots im Anhang.
cd /
du -skx * | sort -rn
Und bitte copy & paste von Text in einem Code-Block und keine Screenshots. Danke.
Quote from: Patrick M. Hausen on July 02, 2024, 06:50:58 PM
cd /
du -skx * | sort -rn
Und bitte copy & paste von Text in einem Code-Block und keine Screenshots. Danke.
root@OPNsense:/ # du -skx * | sort -rn
446624422 usr
4580515 var
1731085 conf
179647 boot
8676 lib
3746 sbin
2693 etc
2688 tmp
920 bin
113 libexec
46 root
5 entropy
5 COPYRIGHT
4 dev
1 zroot
1 sys
1 rescue
1 proc
1 net
1 mnt
1 media
1 home
cd usr
du -skx * | sort -rn
... und so weiter, bis du den "Brocken" gefunden hast.
Quote from: Patrick M. Hausen on July 02, 2024, 06:55:37 PM
cd usr
du -skx * | sort -rn
... und so weiter, bis du den "Brocken" gefunden hast.
Hm, da kommen dann 2 ähnlich große Ordner - in die komme ich nicht rein.
root@OPNsense:/usr/bin # du -skx * | sort -rn
42521 lldb
42449 c++
28381 ld.lld
10305 lldb-server
5969 llvm-objdump
5937 llvm-nm
5769 llvm-ar
3481 llvm-readelf
2689 llvm-profdata
2441 llvm-addr2line
2365 gcov
2309 llvm-objcopy
1993 llvm-size
433 openssl
309 ex
297 apropos
245 c++filt
233 llvm-strings
229 flex
153 bmake
137 less
137 dtc
121 bc
121 awk
113 ztest
113 ftp
105 readelf
105 netstat
101 telnet
77 unzstd
77 objcopy
73 byacc
69 systat
61 wg
61 edit
61 ctfconvert
57 truss
57 nm
53 rpcgen
53 localedef
53 addr2line
49 m4
49 lzcat
49 cu
49 ctfmerge
49 bsnmpget
45 top
45 sort
41 patch
41 gunzip
41 drill
41 bsdtar
37 mkimg
37 kdump
37 find
33 tftp
33 pmcstudy
33 pargs
33 iscsictl
33 indent
33 diff
33 dialog
33 bsdiff
33 ar
29 sed
29 lpr
25 vmstat
25 unifdef
25 lprm
25 lpq
25 gprof
25 crunchgen
25 crontab
25 bunzip2
25 bsdcpio
21 zinject
21 vtfontcvt
21 pr
21 nc
21 mt
21 mkcsmapper
21 install
21 host
21 hd
21 finger
21 fetch
21 egrep
21 diff3
21 at
17 zstream
17 unzip
17 tr
17 tail
17 sockstat
17 size
17 sdiff
17 rpcinfo
17 nfsstat
17 mkuzip
17 mkesdb
17 ministat
17 login
17 file
17 elfdump
17 ctlstat
17 ctfdump
17 ctags
17 chpass
17 chat
17 cal
17 banner
13 xo
13 xargs
13 whois
13 whereis
13 wall
13 usbhidctl
13 usbhidaction
13 uptime
13 units
13 ul
13 su
13 strings
13 smbutil
13 script
13 rs
13 rfcomm_sppd
13 reset
13 readlink
13 rctl
13 printf
13 posixshmcontrol
13 opiepasswd
13 man
13 logger
13 locate
13 locale
13 limits
13 lesskey
13 last
13 killall
13 jot
13 join
13 ipcs
13 ipcrm
13 getent
13 getconf
13 getaddrinfo
13 gencat
13 gcore
13 fstat
13 fmt
13 env
13 dpv
13 cut
13 csplit
13 crunchide
13 compress
13 col
13 cmp
13 btsockstat
9 yes
9 xstr
9 write
9 who
9 which
9 what
9 wc
9 vis
9 users
9 unvis
9 uniq
9 unexpand
9 uname
9 tsort
9 truncate
9 tput
9 touch
9 time
9 tee
9 tcopy
9 tabs
9 split
9 soelim
9 showmount
9 seq
9 rwho
9 rwall
9 rusers
9 ruptime
9 rup
9 resizewin
9 renice
9 proccontrol
9 printenv
9 pathchk
9 paste
9 passwd
9 opiekey
9 nl
9 nice
9 newkey
9 newgrp
9 mktemp
9 mkstr
9 minigzip
9 lzmainfo
9 lzdec
9 lsvfs
9 look
9 logname
9 logins
9 lockf
9 lock
9 lessecho
9 leave
9 ldd
9 lastcomm
9 lam
9 ktrdump
9 ktrace
9 ident
9 iconv
9 head
9 groups
9 getopt
9 fold
9 file2c
9 expand
9 etdump
9 elfctl
9 du
9 dirname
9 crypt
9 cpuset
9 comm
9 column
9 colrm
9 cksum
9 chkey
9 chgrp
9 cap_mkdb
9 c99
9 bzip2recover
9 bthost
9 bspatch
9 bsdcat
9 brandelf
9 beep
9 basename
9 backlight
9 b64encode
9 b64decode
9 asa
9 apply
5 znew
5 zmore
5 zforce
5 xzdiff
5 unifdefall
5 tty
5 true
5 stdbuf
5 shar
5 revoke
5 rev
5 protect
5 perror
5 pagesize
5 opieinfo
5 nohup
5 mkfifo
5 mkdep
5 mesg
5 lp
5 lorder
5 lesspipe.sh
5 keylogout
5 keylogin
5 gzexe
5 fsync
5 false
5 clear
5 c89
5 bzegrep
1 zstreamdump
1 timeout
1 tar
1 pkill
1 pgrep
1 ld
1 cpio
1 chsh
1 chfn
1 bzless
1 alias
1 CC
Kannst Du mal den Output von "zpool status -t" zeigen?
Und in welche Ordner "kommst Du nicht rein"?
Quote from: meyergru on July 02, 2024, 07:12:00 PM
Kannst Du mal den Output von "zpool status -t" zeigen?
Und in welche Ordner "kommst Du nicht rein"?
root@OPNsense:/usr/bin # zpool status -t
pool: zroot
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
zroot ONLINE 0 0 0
nvd0p4 ONLINE 0 0 0 (untrimmed)
errors: No known data errors
In die Ordner lldb + c++.
Egal welche Logs ich lösche, ich gewinne kaum Speicherplatz.
In /usr/bin werden die 446 G nicht stecken. Was ist denn die Ausgabe von dem
cd /usr
du -skx * | sort -rn
Versuch mal "df --si ; zpool set autotrim=on zroot; zpool trim zroot; sleep 30; zpool status -t; df --si"
Lasst mich doch bitte mal machen ...
Guckt mal den "zfs list" output an. Da sind 431 G REFER in dem Dataset, dass unter / gemountet ist und davon ist *nichts* nennenswertes in irgendeinem anderen Dataset.
Aus der ersten Ausgabe von
cd /
du -skx * | sort -rn
sieht man, dass das alles unterhalb von /usr liegt.
Also als nächstes:
cd /usr
du -skx * | sort -rn
Und bitte die Ausgabe.
Mein Verdacht: da schreibt irgendein Plugin irgendwo unter /usr/local irgendwas voll. Wissen wir aber noch nicht.
/var/log ist komplett irrelevant - ich verweise wieder auf die Ausgabe von "zfs list".
Und Snapshots sind es auch nicht, deren Platz würde nämlich in der Ausgabe von "du" gar nicht auftauchen. Wir haben aber >400 G in /usr ...
Was Patrick sagt, stimmt - mein Irrtum, es sind nicht die Logs, sondern /usr/*.
Soweit ich das sehe, sind lldb und c++ aber nicht unter /usr, sondern unter /usr/bin und sahen außerdem unverdächtig aus.
Übrigens: Du kommst schneller voran, wenn Du "du -kxd 4 /usr | sort -rn | head -50" aufrufst.
Tja, dürfte jetzt so voll, dass gar nichts mehr geht.
Internet funktionierte nicht mehr - über Konsole ,,reboot" - tja, jetzt irgendwie tot.
Toll, Freundin hat morgen HomeOffice...
Kannst du dich per SSH anmelden? Könntest du mal die Kommandos ausführen, die ich dir ausführlich geschrieben habe?
Ich mein, wie soll man dir sonst helfen?
Nein, ist tot.
Monitor dran geht noch.
Hier komme ich irgendwie nicht weiter?!
Hab jetzt nur mehr mein Handy und kann nicht mal ein Foto uploaden, weil zu groß?!
zroot 454G
zroot/ROOT 453G
zroot/ROOT/default 453G
Alle anderen Ordner sind klein.
SSD - 0B available
cd /usr
du -skx * | sort -rn
Dann das oberste fetteste Verzeichnis - welches ist das?
Quote from: Patrick M. Hausen on July 02, 2024, 07:39:20 PM
Lasst mich doch bitte mal machen ...
Guckt mal den "zfs list" output an. Da sind 431 G REFER in dem Dataset, dass unter / gemountet ist und davon ist *nichts* nennenswertes in irgendeinem anderen Dataset.
Aus der ersten Ausgabe von
cd /
du -skx * | sort -rn
sieht man, dass das alles unterhalb von /usr liegt.
Also als nächstes:
cd /usr
du -skx * | sort -rn
Und bitte die Ausgabe.
Mein Verdacht: da schreibt irgendein Plugin irgendwo unter /usr/local irgendwas voll. Wissen wir aber noch nicht.
/var/log ist komplett irrelevant - ich verweise wieder auf die Ausgabe von "zfs list".
Und Snapshots sind es auch nicht, deren Platz würde nämlich in der Ausgabe von "du" gar nicht auftauchen. Wir haben aber >400 G in /usr ...
Der größte Brocken ist dann:
455117636 local
cd /usr/local
du -skx * | sort -rn
Und diesmal?
Quote from: Patrick M. Hausen on July 03, 2024, 10:46:32 PM
cd /usr/local
du -skx * | sort -rn
Und diesmal?
Hm, interessant!
454251583 AdGuardHome
cd /usr/local/AdGuardHome
du -skx * | sort -rn
Genau das hatte ich dir aber gestern geschrieben - immer das größte Verzeichnis nehmen, dort rein wechseln, dann dasselbe Spiel von vorn.
Quote from: Patrick M. Hausen on July 03, 2024, 10:48:50 PM
cd /usr/local/AdGuardHome
du -skx * | sort -rn
Genau das hatte ich dir aber gestern geschrieben - immer das größte Verzeichnis nehmen, dort rein wechseln, dann dasselbe Spiel von vorn.
Das ist (leider) völliges Neuland...
Im Unterordner ,,data" sind folgende 2 großen ,,Dateien"
384617113 querylog.json
69494905 querylog.json.1
Bahnhof für mich...
cd /usr/local/AdGuardHome/data
rm querylog*
shutdown -r now
Quote from: Patrick M. Hausen on July 03, 2024, 10:53:24 PM
cd /usr/local/AdGuardHome/data
rm querylog*
shutdown -r now
Bin dabei - Dateien dürften gelöscht worden sein; Reboot läuft.
Kann man das mit den Logdateien bei Adguard dann irgendwo um/einstellen?
Bei meinen vorigen Installationen hatte ich damit nie Probleme!
Vielen vielen Dank!
OPNSense läuft jetzt wieder.
"Komisch" - jetzt habe ich nur mehr 65GB!?
In AdGuardHome habe ich eigentlich bei den Logs/Statistiken jeweils 30 Tage eingestellt!?
Du hast die aktiv so eingestellt, dass die so gross werden - bei mir macht AGH das nicht.
Klick dich mal durch das Admin-UI. Da weiß ich jetzt auch nicht auswendig, wo die Einstellung liegt. Irgendwas mit Aufbewahrungszeit ...
Und: hättest du gestern schon haben können, wenn du einfach geantwortet hättest. Ich hab mir extra Zeit genommen und bin hier vor dem Rechner sitzen geblieben. Gestern wie heute.
Das ist ja kein Supportkanal von Deciso. Das ist ein Anwender-Forum. Ich bin halt schon >30 Jahre im Geschäft und mach hier kostenlos Support. So wie @meyergru und andere in diesem Thread auch.
Aber wenn die Kacke so richtig am dampfen ist, dann darf man von dem Menschen mit dem Problem schon ein wenig Einsatz erwarten, oder?
Nix für ungut, hoffe, es läuft jetzt wieder alles.
Patrick
Quote from: heiligst on July 03, 2024, 11:07:39 PM
"Komisch" - jetzt habe ich nur mehr 65GB!?
ZFS komprimiert per Default und Logfiles sind dafür in der Regel besonders geeignet.
Quote from: heiligst on July 03, 2024, 11:07:39 PM
In AdGuardHome habe ich eigentlich bei den Logs/Statistiken jeweils 30 Tage eingestellt!?
Nun, vielleicht hast du in einem Monat > 400 G an Queries. Das musst du aber nun wirklich selbst rausfinden. :P
Quote from: Patrick M. Hausen on July 03, 2024, 11:08:11 PM
Du hast die aktiv so eingestellt, dass die so gross werden - bei mir macht AGH das nicht.
Klick dich mal durch das Admin-UI. Da weiß ich jetzt auch nicht auswendig, wo die Einstellung liegt. Irgendwas mit Aufbewahrungszeit ...
Und: hättest du gestern schon haben können, wenn du einfach geantwortet hättest. Ich hab mir extra Zeit genommen und bin hier vor dem Rechner sitzen geblieben. Gestern wie heute.
Das ist ja kein Supportkanal von Deciso. Das ist ein Anwender-Forum. Ich bin halt schon >30 Jahre im Geschäft und mach hier kostenlos Support. So wie @meyergru und andere in diesem Thread auch.
Aber wenn die Kacke so richtig am dampfen ist, dann darf man von dem Menschen mit dem Problem schon ein wenig Einsatz erwarten, oder?
Nix für ungut, hoffe, es läuft jetzt wieder alles.
Patrick
Ja, danke dafür - hatte gestern irgendwann keinen Nerv mehr dafür, weil ich die "Vorgehensweise" auch irgendwie nicht verstanden habe...
Wieder was gelernt ...
Werde mal auf 7 Tage umstellen und beobachten.
So eine Last liegt bei mir eigentlich nicht an - ev. hat sich da irgendwo mal ein Fehler eingeschlichen mit den zahlreichen Updates!?
Mal sehen..
Trotzdem nochmals danke!
LG
Quote from: heiligst on July 03, 2024, 11:13:46 PM
Werde mal auf 7 Tage umstellen und beobachten.
So eine Last liegt bei mir eigentlich nicht an - ev. hat sich da irgendwo mal ein Fehler eingeschlichen mit den zahlreichen Updates!?
Guck dir die Queries einfach mal an. Evtl. hast du da irgendein dödeliges $Device, das jede Sekunde irgendeinen Müll abfragt. Kommt bei Consumer-Hardware (IoT, Smart TV, whatever) ja schon mal vor.
Ja, da muss ich die nächsten Tage/Wochen einen Blick drauf haben - mal sehen.
Hab sämtliche Statistiken/Logs in AGH jetzt mal auf 15 Tage eingestellt ...
Danke!
Tja, nach ein paar Tagen mal übers GUI von AGH die Logs gelöscht - tja, heute ist sie wieder abgeschmiert!
Hatte die Logs auf 7 Tage eingestellt - irgendwo ist da eine ordentliche Baustelle.
Habs jetzt auf 1 Tag gestellt - msl sehen...
Wenn du alle Request logst ... kann man machen. Dann reicht aber ein hirntotes Gerät, das dir jede Sekunde einen Request an den AGH hin wirft, dann passiert eben genau das.
Guck dir doch mal an, was das für Anfragen sind. Meist ist es ein Client, der 99% verursacht.
So, in der Zwischenzeit gab es ein AGH-Update und auch Updates von OPNSense.
Momentan habe ich bei AGH 3 Tage Speicherung der LOG's eingestellt - die Speicherplatzbelegung hält sich so in Grenzen.
Hab mir das bei AGH mal angesehen - habe aber keinen Plan.
Ich habe extrem viele DNS-Anfragen und sollten bei den Top-Clients nicht nur interne IP-Adressen (meiner Geräte) stehen!?
Wer/wie/wo/was fragt da so extrem viel/oft bei cisco.com an!?
Na dann klick doch bei Cisco.com mal auf die 68.000.000 rechts drauf, dann siehst du doch, welcher Client das macht!
Muss ich am Abend probieren - irgendwie kam da beim letzten Mal nichts...
So, Screenshot anbei.
Sorry für die "blöde" Frage - kenne mich da 0 aus - was sagt mir das jetzt, bzw. wie unterbindet man das!?
Das sind ja dann irgendwie externe "Abfragen", oder?
Meine "Geräte" haben ja alle "192.xxxxxxx".
Danke!
Du hast es irgendwie geschafft, deinen AGH nach außen zu öffnen. Poste doch mal alle Firewall- und alle Port-Forward-Regeln auf WAN ...
Da die IP extern ist und AGH offenbar auf der OpnSense läuft, braucht es kein NAT. Da reicht es, den DNS-Port auf dem WAN-Interface zu öffnen oder eine zu weit gefasste Floating-Regel.
Quote from: meyergru on August 03, 2024, 03:19:31 PM
Da die IP extern ist und AGH offenbar auf der OpnSense läuft, braucht es kein NAT. Da reicht es, den DNS-Port auf dem WAN-Interface zu öffnen oder eine zu weit gefasste Floating-Regel.
Ich benutz für AGH ein Port-Forward von Port 53 auf 127.0.0.1:53530 - wenn man das versehentlich statt für LAN für alle Interfaces macht, hat man auch den beobachteten Effekt.
Also am besten mal alles posten ...
Mal so aus Interesse. Wie bekommt man in einem solchen Fall, in dem man Port 53 freigegeben hat eigentlich externe Anfragen? Ich meine klar, an der Tür klopfen ja ständig Dienste an, aber rutscht man irgendwann in die Rolle eines DNS-Resolvers? Sodass auch "normale" Nutzer anfragen stellen?
Das habe ich mich auch schon gefragt: Normalerweise nicht.
Die abgebildeten Anfragen stammen alle aus einem Netz, das z.B. bei Crowdsec unbekannt ist. Die Abfragen gehen auf Cisco.com, ist ein bisschen mysteriös. Wenn ein Großteil der Anfragen von dort kommt, stellt soch die Frage, warum.
Danke für euren bisherigen Input - werde mir das heute/morgen mal ansehen.
Interessant ist halt, dass ich das Problem erst seit Kurzem habe und ich selber nicht geändert habe => vermutlich wieder irgendwo etwas durch ein Update "verpfuscht"!?
So, hoffe ich habe alles.
grober Aufbau:
Kabelmodem im "bridge-modus" - stellt also nur das "Internet" zur Verfügung - Rest (DHCP,....) läuft alles über OPNSense.
Schnittstelle igb0 = vlan1 = mein lokales Heimnetzwerk (Notebooks / Server / .....)
opt2 = vlan20 = eigenes Netzwerk für Drucker
opt1 = vlan30 = eigenes Netzwerk für HomeOffice/Gäste - voller Zugriff aufs Internet und auf die Drucker
unbound läuft auf Port 5335 - dies ist auch so bei ADH hinterlegt (also: 192.168.1.1:5335)
"fließende" Regeln
Regeln fürs LAN/Heimnetzwerk (VLAN1)
Regeln WAN
Ich bin gespannt, was die versierteren Kollegen sagen, aber für mich sieht es so aus, dass du den IP-Adressen von Spam-House exklusiven Zugriff auf dein Netzwerk gewährst. Sprich: bei mir gehen die Alarmglocken an, dass sich bei angedachter Blockregel kein Block-Symbol aka X befindet. Wahrscheinlich wirst du auch alle externen IP-Adressen auf Ubound in dieser Blockliste finden.
Exakt - die 3 WAN-Regeln sind ja alle allow statt deny. Das Netz ist weit offen und zwar ausgerechnet für die externen Adressen, die auf den 3 Listen drauf sind ...
Ich frage einfach mal, um für mich hier auch was mitzunehmen:
1. Wenn hier keine Floating Rules vorhanden wären, wäre die Auswirkung der falsch gesetzten WAN-Regel gleich 0? Weil Floating Rules (nach internen) als 2. Regelgruppe bearbeitet werden und diese über alle Interfaces hinweg gelten, kommt es hier überhaupt erst zu einem Problem?
2. Wäre es möglich, dass durch das Anlegen einer weiteren NAT, bei der ich von der WAN-IP auf die LAN-IP NAT'e, externe IP-Adressen Zugriff auf mein gesamtes Netzwerk im LAN hätten? Ich überlege, wie es noch schlimmer gehen könnte. Weil aktuell (aus Frage 1 heraus) kann ich ja nicht auf Geräte im bspw. LAN zugreifen oder?
Edit: Wobei ich mich etwas korrigieren müsste. Die Floating Rules nennen 192.168.1.1 als Ziel. Das ist vermutlich der Gateway von LAN. Wie könnte dann das NAT für alle Netzwerke außer LAN funktionieren? Selbst wenn ich unter Interfaces zahlreiche Netzwerke angeben, wird das NAT doch nur für das Netzwerk funktionieren, für das der GW 192.168.1.1 ist oder?
Wie kommt dann eine WAN IP zu Unbound?
Quote from: Baender on August 06, 2024, 03:45:01 PM
1. Wenn hier keine Floating Rules vorhanden wären, wäre die Auswirkung der falsch gesetzten WAN-Regel gleich 0?
Nein, sie wären genau so katastrophal.
Quote from: Baender on August 06, 2024, 03:45:01 PM
Weil Floating Rules (nach internen) als 2. Regelgruppe bearbeitet werden und diese über alle Interfaces hinweg gelten, kommt es hier überhaupt erst zu einem Problem?
Die Floating-Regeln haben aber nur für sich genommen kein Implicit Deny. Es gibt nur ein Implicit Deny ganz am Ende der Regel-Bearbeitung:
Floating --> Interface Group --> Interface --> Deny.
Sonst könnte man ja gar keine Regeln anlegen, wenn "nix" bei Floating quasi alles dicht machen würde.
Wenn die Regeln "quick" sind, gilt die Reihenfolge oben, die erste Regel, die matcht, wird genommen und die Aktion (allow/deny) ausgeführt.
Quote from: Baender on August 06, 2024, 03:45:01 PM
2. Wäre es möglich, dass durch das Anlegen einer weiteren NAT, bei der ich von der WAN-IP auf die LAN-IP NAT'e, externe IP-Adressen Zugriff auf mein gesamtes Netzwerk im LAN hätten? Ich überlege, wie es noch schlimmer gehen könnte. Weil aktuell (aus Frage 1 heraus) kann ich ja nicht auf Geräte im bspw. LAN zugreifen oder?
Dazu würde es eingehendes Port-Forwarding brauchen, damit man das LAN erreicht, wenn das LAN ein RFC-1918-Netz verwendet. Allerdings ist das LAN im Moment über IPv6 weit offen. Da findet ja kein NAT statt.
Bezieht sich deine Aussage von "Nein, sie wären genau so katastrophal." exklusiv auf den Umstand mit IPv6? Anders gefragt, welcher Schaden entstünde bei einem reinen IPv4-Anschluss und der expliziten Deaktivierung der IPv6-Funktionalität in OPNsense?
Quote from: Baender on August 06, 2024, 04:09:34 PM
Bezieht sich deine Aussage von "Nein, sie wären genau so katastrophal." exklusiv auf den Umstand mit IPv6? Anders gefragt, welcher Schaden entstünde bei einem reinen IPv4-Anschluss und der expliziten Deaktivierung der IPv6-Funktionalität in OPNsense?
Ein allow all auf WAN nur mit IPv4 und mit einem RFC-1918-Netz intern wäre schwieriger auszunutzen und evtl. gar nicht. Es gibt in IP seit RFC 791 eine Source-Routing Option. D.h. man kann dem Paket eine Ziel-Adresse aber auch einen oder mehrere Zwischenstationen mitgeben.
Wenn der ISP das nicht raus filtert, dann könnte man also ein Paket mit Ziel 192.168.1.<internerserver> an 1.2.3.4 (WAN-Adresse) werfen und gucken, was passiert.
Quote from: Patrick M. Hausen on August 06, 2024, 01:53:14 PM
Exakt - die 3 WAN-Regeln sind ja alle allow statt deny. Das Netz ist weit offen und zwar ausgerechnet für die externen Adressen, die auf den 3 Listen drauf sind ...
Hm, sch.. - stimmt.
"rein" in die FW sollten ja genau diese Adressen "gesperrt" werden...
:o
Hab das vor einiger Zeit mal nach einem HowTo eingerichtet - mal sehen ob ich das noch finde - ob das dort dann falsch war, oder ob ich mich da irgendwo/irgendwie "verhaut" habe!
Danke!
D.h. diese 3 "WAN-in-Regeln" auf "block" - dann sollte es wieder passen.
In AGH sollten dann bei den Clients eigentlich nur mehr meine Geräte stehen, oder?
LG
Eigentlich schon.
Aber nochmal im Ernst: was erhoffst du dir von diesen drei Regeln auf WAN? Der Effekt - wenn das die einzigen Regeln sind, und sie korrekt auf "block" stehen - ist nämlich absolut Null.
Ganz ohne jede Regel auf WAN wird doch sowieso alles geblockt.
Nur wenn du unter den drei Block-Regeln dann irgendwelche Allow-Regeln hast für eingehende Dienste, ergibt das Ganze überhaupt einen Sinn.
WireGuard habe ich bei den "fließenden Regeln" hinterlegt - das fällt ja dann auch da rein, oder nicht?
Generell (abgesehen von meinem "allow" Fehler) wird das bei den HowTo's/Videos auch so eingerichtet.
Möchte halt die entsprechenden gefährlichen IP-Adressen/Länder blocken.
LG
Floating wird vor den Interface-Regeln abgearbeitet, also kann man WireGuard auch von den ganzen geblockten Adressen aus kontaktieren und der Block auf WAN ist ein No-Op, weil ja sowieso alles geblockt wird, was nicht erlaubt ist.
Vergiss Videos. Mehr als 90% sind völliger Müll. Zieh die WireGuard Regel von Floating nach WAN und zwar hinter die Block-Regeln um, wenn das ganze irgendeinen Sinn haben soll. Beschäftige dich mit Firewall-Grundlagen. Mit Büchern.
Die WAN-Regeln habe ich korrigiert - Zugriffe sind jetzt wieder normal.
Hm, interessant - dann schiebe ich die WG-Regel mal von "floating" direkt aufs WAN-Interface.
Bei der Liveansicht sieht man aber, dass auch jetzt schon massig UDP-Anfragen geblockt.
Danke für deine bisherige Hilfe!
LG
Ich find ja - unter uns - echt spannend, wie du mit diesem Thema umgehst.
1. "Der Datenträger läuft voll" - das ist 4 Wochen her. Dass ein zentrales Stück Infrastruktur bei dir nicht funktioniert.
2. Wir hatten dann innerhalb von einem Kalendertag raus, dass die Logs von AdGuard Home "schuld" waren.
3. Dann hast du 3 Wochen gebraucht um im AdGuard Home UI (!) mal auf die Requests zu klicken und rauszufinden, dass das externe Adressen sind ...
Finde ich, gelinde gesagt, recht sportlich.
Ich würde jetzt meine OPNsense und jeden internen Host, bei dem das auch nur annähernd praktikabel ist, komplett löschen und neu installieren.
Du hast über einen knappen Monat alle deine internen Systeme von extern erreichbar gemacht.
Just sayin'
Naja, aufgrund fehlender inbound NAT-Regeln war nur die OpnSense selbst per IPv4 erreichbar. Und per IPv6 waren zwar alle Geräte erreichbar, aber deren EUI-64 muss man entweder sehen oder raten...
Trotzdem sollte man ein bisschen was davon verstehen, wenn man sich an so etwas wie OpnSense heranwagt. Am besten wäre es auch, die Wirkung von Block-Regeln mal zu testen, also selbst externe Portscans zu machen, um zu prüfen, ob so etwas nicht "aus Versehen" passiert ist.
Quote from: meyergru on August 06, 2024, 10:15:02 PM
Naja, aufgrund fehlender inbound NAT-Regeln war nur die OpnSense selbst per IPv4 erreichbar. Und per IPv6 waren zwar alle Geräte erreichbar, aber deren EUI-64 muss man entweder sehen oder raten...
Ja, stimmt schon. Siehe meine Antworten an @Baender. Im Firmenumfeld würde ich nach so einem F*up aber tatsächlich alle Systeme offline nehmen und untersuchen. Mindestens.
Quote from: Patrick M. Hausen on August 06, 2024, 10:07:45 PM
Ich find ja - unter uns - echt spannend, wie du mit diesem Thema umgehst.
1. "Der Datenträger läuft voll" - das ist 4 Wochen her. Dass ein zentrales Stück Infrastruktur bei dir nicht funktioniert.
2. Wir hatten dann innerhalb von einem Kalendertag raus, dass die Logs von AdGuard Home "schuld" waren.
3. Dann hast du 3 Wochen gebraucht um im AdGuard Home UI (!) mal auf die Requests zu klicken und rauszufinden, dass das externe Adressen sind ...
Finde ich, gelinde gesagt, recht sportlich.
Ich würde jetzt meine OPNsense und jeden internen Host, bei dem das auch nur annähernd praktikabel ist, komplett löschen und neu installieren.
Du hast über einen knappen Monat alle deine internen Systeme von extern erreichbar gemacht.
Just sayin'
Na ja,
1. Es fällt kein Profi vom Baum - schon gar nicht, wenn man nix in der Richtung gelernt/studiert hat.
2. Habe ich neben dem "IT-Hobby" auch noch ein paar andere Dinge zu tun....
3. Im Nachhinein ist man immer "gescheiter" - wieder ein paar Dinge dazu gelernt.
Werde entsprechende Block-Listen auch "nach draußen" hinterlegen und bei den betreffenden PC's einen Scan laufen lassen.
Quote from: meyergru on August 06, 2024, 10:15:02 PM
Naja, aufgrund fehlender inbound NAT-Regeln war nur die OpnSense selbst per IPv4 erreichbar. Und per IPv6 waren zwar alle Geräte erreichbar, aber deren EUI-64 muss man entweder sehen oder raten...
Trotzdem sollte man ein bisschen was davon verstehen, wenn man sich an so etwas wie OpnSense heranwagt. Am besten wäre es auch, die Wirkung von Block-Regeln mal zu testen, also selbst externe Portscans zu machen, um zu prüfen, ob so etwas nicht "aus Versehen" passiert ist.
Danke für den Tipp mit den Port-Scans.
QuoteResult: 90.146.xx.xxx
ftp-data (20) Not Available Port 20 on 90.146.72.xxx ist geschlossen!
ftp (21) Not Available Port 21 on 90.146.72.xxx ist geschlossen!
ssh (22) Not Available Port 22 on 90.146.72.xxx ist geschlossen!
telnet (23) Not Available Port 23 on 90.146.72.xxx ist geschlossen!
smtp (25) Not Available Port 25 on 90.146.72.xxx ist geschlossen!
(42) Not Available Port 42 on 90.146.72.xxx ist geschlossen!
whois (43) Not Available Port 43 on 90.146.72.xxx ist geschlossen!
domain (53) Not Available Port 53 on 90.146.72.xxx ist geschlossen!
(67) Not Available Port 67 on 90.146.72.xxx ist geschlossen!
(69) Not Available Port 69 on 90.146.72.xxx ist geschlossen!
http (80) Not Available Port 80 on 90.146.72.xxx ist geschlossen!
pop3 (110) Not Available Port 110 on 90.146.72.xxx ist geschlossen!
(115) Not Available Port 115 on 90.146.72.xxx ist geschlossen!
(123) Not Available Port 123 on 90.146.72.xxx ist geschlossen!
(137) Not Available Port 137 on 90.146.72.xxx ist geschlossen!
(138) Not Available Port 138 on 90.146.72.xxx ist geschlossen!
netbios-ssn (139) Not Available Port 139 on 90.146.72.xxx ist geschlossen!
imap2 (143) Not Available Port 143 on 90.146.72.xxx ist geschlossen!
snmp (161) Not Available Port 161 on 90.146.72.xxx ist geschlossen!
bgp (179) Not Available Port 179 on 90.146.72.xxx ist geschlossen!
https (443) Not Available Port 443 on 90.146.72.xxx ist geschlossen!
microsoft-ds (445) Not Available Port 445 on 90.146.72.xxx ist geschlossen!
shell (514) Not Available Port 514 on 90.146.72.xxx ist geschlossen!
(933) Not Available Port 933 on 90.146.72.xxx ist geschlossen!
pop3s (995) Not Available Port 995 on 90.146.72.xxx ist geschlossen!
socks (1080) Not Available Port 1080 on 90.146.72.xxx ist geschlossen!
ms-sql-s (1433) Not Available Port 1433 on 90.146.72.xxx ist geschlossen!
(3128) Not Available Port 3128 on 90.146.72.xxx ist geschlossen!
(3268) Not Available Port 3268 on 90.146.72.xxx ist geschlossen!
mysql (3306) Not Available Port 3306 on 90.146.72.xxx ist geschlossen!
ms-wbt-server (3389) Not Available Port 3389 on 90.146.72.xxx ist geschlossen!
(5900) Not Available Port 5900 on 90.146.72.xxx ist geschlossen!
(5938) Not Available Port 5938 on 90.146.72.xxx ist geschlossen!
http-alt (8080) Not Available Port 8080 on 90.146.72.xxx ist geschlossen!
Ich habe genau die Probleme gehabt, habe dann UFS, und es läuft. Habe auch ein pfSense 2.7.2 mit ZFS, die probleme gibt es nicht.