Hi @ll,
ich plage mich nun seit ein paar Jahren damit ab Nextcloud für mich / meine family selber _sicher_ zu hosten.
Nun habe ich mich dazu entschlossen das NGINX NAXSI Konstrukt für Nextcloud an den Nagel zu hängen, da das ohne experten Wissen und fachgerechte Hilfe für mich einfach zu kompliziert ist. Ich habe mich sehr bemüht eigene Rules zu erstellen und konnte zwar den Dienst immer erreichen und auch mit der Cloud arbeiten, aber dann kam es z.B. beim automatischen Upload von Daten immer probleme. Bot Protection hab ich deaktiviert, aber das schien keine Auswirkung zu haben.
Letztlich habe ich erkannt, dass gewisse Basic Rules für CSS und SQL Injections gewisse legitime Anfragen blockieren. Ich habe versucht mit höher gewichteten White Listings diese Rules zu ignorieren, aber das klappt leider nicht so ganz. Ich denke meine Profil Posts historie spricht da für sich...
Jedenfalls habe ich ein ungutes Gefühl mit Halbwissen Dinge zu whitelisten und öffentlich zu exposen. Ich bin durchaus in der Lage Nextcloud mit der Standard konfiguration und ohne NAXSI zur Verfügung zu stellen. Aber aus Erfahrung in der Vergangenheit kann ich sagen, dass das die Sicherheit nur von kurzer dauer ist. Ich habe schon diverse Angriffe an den eigenen Systemen erfahren und daraus immer konsequenzen gezogen. Ich bin einer der sehr gerne einen möglichst hohen Sicherheitsstandard hegt und bediene mich sämtlicher hardening guides die online zur Verfügung stehen. Meine Seiten sind alle immer mit A+ getestet, gültige certs, cloudflare, 2FA (in Nextcloud) usw.
Der letzte Angriff den ich bei mir vor ein paar Jahren erfahren habe, war ein MITM Proxy welcher meine Login maske von Nextcloud wiedergespiegelt hat, aber nach meiner 2FA Authentifizierung nicht auf das eigene Dashboard weitergeleitet hat. Ich dachte erst mein Proxy sei falsch konfiguriert, aber in Maltrail und ein paar Logs erhielt ich dann gewissheit, dass sich da jemand aus holland oder einem anderen Land eingeschaltet hat...
Keines meiner Dienste die ich public erreichbar habe, waren so vielen angriffen ausgesetzt wie Nextcloud.
Long story short...
Mittlerweile bin ich von meinem Raspberry Pi Cloud Setup auf Unraid umgestiegen und habe mir da ein paar Container bereit gestellt die ich auch nicht unbedingt exposen will. Bis auf einen, aber da hatte ich noch niiiee ein Problem.
Ich habe bei mir auf der OPNSense, Wireguard mit Unbound DNS + DoT, und Adguard mit laufender private DNS resolving eingerichtet. Ich komme überall hin und kann meine Hosts über den FQDN erreichen. Alles Top.
Jetzt bin aber an einem Punkt wo ich nicht weiß was mehr Sinn machen würde. Damit Nextcloud im Docker ordentlich läuft, will ich das ganze möglichst komfortabel mit HTTPS und einem proxy lösen. Ich möchte auf IPv4 und selfsigned Zertifikate verzichten. Ich habe die chance den NPM (NGINX Proxy Manager) in Unraid bereit zu stellen, aber das reicht nicht um die URL aufrufen zu können. Da nur der OPNsense NGINX den Servernamen kennt, der aber auf die Außenwelt eingestellt ist, würde jede Anfrage weiterhin aus dem Internet kommen. Ich weiß jetzt nicht, ob es sinn macht, die Konfiguration aus dem OPNsense NGINX zu entfernen und auf HAProxy umzustellen der nach innen zielt. Oder könnte ich die HTTPS Lauschadresse im NGINX auf 2 Subnetze beschränken? Anschließend könnte man NAXSI deaktivieren, da man für interne Anfragen aus einem vertrauenswürdigen Netz keine zusätzliche WAF braucht (obwohl's auch ein nice to have wäre. ;D )
Viele Wege führen nach Rom...
Die Alternative wäre eben der Forward Proxy auf der OPNsense und der NPM ausm Unraid.
Habt ihr bessere Vorschläge? Bin für jede Hilfe dankbar! 8)
Viele Grüße
Das os-caddy Plugin macht eigentlich alles automatisch. Ich habe das als extern erreichbaren Proxy vor meiner Nextcloud und die Kommunikation zw. Caddy und Nextcloud läuft unverschlüsselt über plain HTTP. Das ist in einem geswitchten Netz eigentlich auch kein Problem.
Wildcard SSL Zertifikat + Reverse Proxy der per default eine statische Seite ausliefert.
99,99999% dieser "Angriffe" machen Requests auf die IP Adresse und schlagen fehl, weil dort nur die statische Seite ausgeliefert wird.
Alle Subdomains sind dann "privat", d.h. man erreicht den Dienst nur wenn man die Subdomain kennt.
Caddy würde jeden Request ohne den korrekten SNI-Namen sowieso ablehnen.
Hi, erstmal danke für den Vorschlag.
Caddy war mir neu. Habs mir mal angesehen und bin gerade dabei mich durch die Doc's zu wühlen. Dabei ist mir aber auch wieder folgendes aufgefallen.
QuoteThere is no TCP/UDP stream and WAF (Web Application Firewall) support in this plugin. For a business grade Reverse Proxy with WAF functionality, use os-OPNWAF. For TCP/UDP streaming, use either os-nginx or os-haproxy.
os-OPNWAF ist vermutlich ein Enterprise Plugin für Kunden, oder?
Und weiter..
QuoteAs an alternative to a WAF, it is simple to integrate Caddy with CrowdSec. Check the tutorial section for guidance
Das heißt dann also, ich hätte eine sehr abgespeckte funktionalität, da ich kein Premium bzw. Business Plan habe. Durch die Limitierung der Blocklisten im free plan, besteht ein höheres Risiko angegriffen zu werden. Richtig?
Alternativ kann man hier auch den Zugriff über Internal IPs beschränken wie ich hier gerade lese.
QuoteThey can be used to restrict access per domain. In this example, they are used to restrict access to only internal IPv4 networks, refusing connections from the internet.
os-OPNWAF ist keine Erweiterung von os-caddy, sondern ein eigener Reverse Proxy mit WAF basierend auf Apache2 in der OPNsense Business Edition.
Und zum allgemeinen Angriffsrisiko, wenn man nicht angegriffen werden will trennt man sich einfach vom Internet. Dann müssen die bösen Buben schon ins Haus einbrechen um an die leckeren Daten auf dem Storage zu kommen.
Und am besten WLAN aus.
Quote from: Monviech on June 20, 2024, 07:18:01 PM
os-OPNWAF ist keine Erweiterung von os-caddy, sondern ein eigener Reverse Proxy mit WAF basierend auf Apache2 in der OPNsense Business Edition.
Das war mir schon klar. Ich wollte nur die Bestätigung, dass das nichts für normalsterbliche ist. ^^
Ich hab's jetzt auch soweit mehr oder weniger fertig. Nextcloud wäre jetzt theorethisch aufrufbar. Allerdings kommt meine Anfrage nicht am Server an, weil ich die Access Listen hinzugefügt habe. Im Prinzip habe ich den Zugriff auf interne Subnetze limitiert. Jedoch wird meine Anfrage erst ins internet geleitet, wo es dann wieder zurück zu Caddy kommt, anstatt den direkten Weg zu gehen. Ich sehe aber nirgends dokumentiert wie du genau diesen Fall verhinderst.
Im Prinzip bräuchte ich eine Regel die Anfragen auf https://<nextcloud.domain>/ automatisch an Caddy weiterleitet, statt ins Internet.
Ne Ahnung wie ich das am besten anstelle? Ein Alias ruft nur Adressen ab. Welche alternativen hätte ich also hier?
Die Anfragen werden nicht ins internet geleitet. Caddy hört auf der öffentlichen IP Adresse deiner Firewall und antwortet direkt. Es ist also egal wenn die Anfrage aus deinem Internen Netz zur öffentlichen IP geht, die OPNsense hat die ja auf dem Interface.
Du kannst mit tcpdump überprüfen was mit dem Traffic passiert.
Der Fall dass es über das Internet geht kann nur passieren, wenn du 2 WAN Anschlüsse hättest, und durch eine reply-to Regel der Traffic zum Standardgateway des Providers geroutet wird, von wo aus er auf dem zweiten WAN Anschluss zurückkommt.
Ich habe nur einen WAN Anschluss.
Beim TCPDump habe ich nun folgendes rauslesen können:
Mein LAN Client sendet einen query request an meinen DNS Server und erhält die Adresse von meiner OPNsense.
Kurze Zeit darauf erhalte ich "Destination Unreachable"
Der Dienst ist natürlich erreichbar, aber dadurch das Caddy die Abfrage abwimmelt, ist es das eben nicht.
Unter Remote IP Stand meine Public IP.
"info","ts":"2024-06-22T09:01:52Z","logger":"http.log.access.37fc6c8b-42c2-41e0-baba-c38516660295","msg":"NOP","request":{"remote_ip":"X.X.X.X","remote_port":"6102","client_ip":"X.X.X.X","proto":"HTTP/2.0","method":"GET","host":"ncloud.example.com","uri":"/login","headers":{"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8"],"Dnt":["1"],"Te":["trailers"],"Accept-Language":["de,en-US;q=0.7,en;q=0.3"],"Sec-Fetch-Site":["none"],"Sec-Gpc":["1"],"Priority":["u=1"],"Sec-Fetch-Mode":["navigate"],"Sec-Fetch-User":["?1"],"User-Agent":["Mozilla/5.0 (X11; Linux x86_64; rv:127.0) Gecko/20100101 Firefox/127.0"],"Accept-Encoding":["gzip, deflate, br, zstd"],"Upgrade-Insecure-Requests":["1"],"Sec-Fetch-Dest":["document"]},"tls":{"resumed":true,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"ncloud.example.com"}},"bytes_read":0,"user_id":"","duration":0.000012932,"size":0,"status":0,"resp_headers":{"Server":["Caddy"],"Alt-Svc":["h3=\":443\"; ma=2592000"]}}
Im Caddy Log sehe ich nur solche Meldungen. Vielleicht übersehe ich auch was...
Ich verstehe hier leider nicht ganz was passiert.
Wenn die Anfrage z.B aus dem LAN kommt mit der öffentlichen IP Adresse der OPNsense als Ziel, und es auf dem LAN interface die Firewall Regeln gibt, dass "This Firewall" auf Port 80 und 443 erreicht werden darf, sollte Caddy richtig funktionieren.
Vielleicht gibt es noch alte Port Forward oder Outbound NAT Regeln die die Quell IP oder Ziel IP des Pakets ändern.
Ich kann es mir auch nicht erklären.
Hier meine Rules:
Wenn die interne IP Adresse deines Clients mit der öffentlichen IP Adresse der OPNsense ersetzt wird, ist hier irgend ein Source NAT.
Dafür müsste ich alle Netzwerke kennen und alle Regeln von "/ui/diagnostics/firewall/statistics#rules".
Hier jetzt Troubleshooting zu betreiben ist asynchron recht schwer.
Ich empfehle die automatischen NAT Reflection Regeln auszuschalten. Alle Port Forward Regeln aus. Bei Outbound auf Manuell gehen (achtung dadurch wird das Internet nicht mehr funktionieren, hier muss dann manuelle Outbound Masquerading Regeln angelegt werden.)
Dann nochmal mit dem internen Client die Webseite aufrufen. Dann sollte eigendlich kein NAT mehr irgendwelche Adressen verändern.
Ist aber alles nur Vermutung gerade, die Firewall Regeln als xml ohne Zusammenhang der Infrastruktur helfen mir gerade nicht. Da es aber sehr viele Leute richtig hinbekommen Caddy in Betrieb zu nehmen, ist hier sehr wahrscheinlich ein Konfigurationsfehler der OPNsense die Ursache.
Aber das merkwürdige ist, ich habe keine custom NAT rules.
Allgemein habe ich nicht sehr viele Regeln, außer es handelt sich um meine Server bzw. Unraid Netze.
LAN und VPN sind recht "offen" also mit erlaube any to any.
igc0 = WAN, igc1=LAN und wg0=wireguard
rules
filter rules
@0 scrub in on wireguard all max-mss 1360 fragment reassemble
@1 scrub in all fragment reassemble
@0 block drop in log on ! igc1 inet from 192.168.1.0/24 to any
@1 block drop in log inet from <__automatic_73dcf8_0:6> to any
@2 block drop in log on ! igc2 inet from 192.168.100.0/25 to any
@3 block drop in log on ! igc3 inet from 192.168.200.0/25 to any
@4 block drop in log on ! wg0 inet from 100.65.0.0/24 to any
@5 block drop in log on ! igc0 inet from 192.168.178.0/24 to any
@6 block drop in log on ! igc4 inet from 192.168.99.0/26 to any
@7 block drop in log on igc1 inet6 from fe80::e63a:6eff:fe5d:9b3c to any
@8 block drop in log on igc2 inet6 from fe80::e63a:6eff:fe5d:9b3d to any
@9 block drop in log on igc3 inet6 from fe80::e63a:6eff:fe5d:9b3e to any
@10 block drop in log on igc0 inet6 from fe80::e63a:6eff:fe5d:9b3b to any
@11 block drop in log on igc4 inet6 from fe80::e63a:6eff:fe5d:9b3f to any
@12 block drop in log inet all label "02f4bab031b57d1e30553ce08e0ec131"
@13 block drop in log inet6 all label "02f4bab031b57d1e30553ce08e0ec131"
@14 pass in log quick inet6 proto ipv6-icmp all icmp6-type unreach keep state label "1d245529367b2e34eeaff16086aeafe9"
@15 pass in log quick inet6 proto ipv6-icmp all icmp6-type toobig keep state label "1d245529367b2e34eeaff16086aeafe9"
@16 pass in log quick inet6 proto ipv6-icmp all icmp6-type neighbrsol keep state label "1d245529367b2e34eeaff16086aeafe9"
@17 pass in log quick inet6 proto ipv6-icmp all icmp6-type neighbradv keep state label "1d245529367b2e34eeaff16086aeafe9"
@18 pass out log quick inet6 proto ipv6-icmp from (self:7) to fe80::/10 icmp6-type echoreq keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
@19 pass out log quick inet6 proto ipv6-icmp from (self:7) to ff02::/16 icmp6-type echoreq keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
@20 pass out log quick inet6 proto ipv6-icmp from (self:7) to fe80::/10 icmp6-type echorep keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
@21 pass out log quick inet6 proto ipv6-icmp from (self:7) to ff02::/16 icmp6-type echorep keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
@22 pass out log quick inet6 proto ipv6-icmp from (self:7) to fe80::/10 icmp6-type routersol keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
@23 pass out log quick inet6 proto ipv6-icmp from (self:7) to ff02::/16 icmp6-type routersol keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
@24 pass out log quick inet6 proto ipv6-icmp from (self:7) to fe80::/10 icmp6-type routeradv keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
@25 pass out log quick inet6 proto ipv6-icmp from (self:7) to ff02::/16 icmp6-type routeradv keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
@26 pass out log quick inet6 proto ipv6-icmp from (self:7) to fe80::/10 icmp6-type neighbrsol keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
@27 pass out log quick inet6 proto ipv6-icmp from (self:7) to ff02::/16 icmp6-type neighbrsol keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
@28 pass out log quick inet6 proto ipv6-icmp from (self:7) to fe80::/10 icmp6-type neighbradv keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
@29 pass out log quick inet6 proto ipv6-icmp from (self:7) to ff02::/16 icmp6-type neighbradv keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
@30 pass in log quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type echoreq keep state label "42e9d787749713a849d8e92432efdfaa"
@31 pass in log quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type echoreq keep state label "42e9d787749713a849d8e92432efdfaa"
@32 pass in log quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type routersol keep state label "42e9d787749713a849d8e92432efdfaa"
@33 pass in log quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type routersol keep state label "42e9d787749713a849d8e92432efdfaa"
@34 pass in log quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type routeradv keep state label "42e9d787749713a849d8e92432efdfaa"
@35 pass in log quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type routeradv keep state label "42e9d787749713a849d8e92432efdfaa"
@36 pass in log quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type neighbrsol keep state label "42e9d787749713a849d8e92432efdfaa"
@37 pass in log quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type neighbrsol keep state label "42e9d787749713a849d8e92432efdfaa"
@38 pass in log quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type neighbradv keep state label "42e9d787749713a849d8e92432efdfaa"
@39 pass in log quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type neighbradv keep state label "42e9d787749713a849d8e92432efdfaa"
@40 pass in log quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type echoreq keep state label "8752fca75c6be992847ea984161bd3f1"
@41 pass in log quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type routersol keep state label "8752fca75c6be992847ea984161bd3f1"
@42 pass in log quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type routeradv keep state label "8752fca75c6be992847ea984161bd3f1"
@43 pass in log quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type neighbrsol keep state label "8752fca75c6be992847ea984161bd3f1"
@44 pass in log quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type neighbradv keep state label "8752fca75c6be992847ea984161bd3f1"
@45 pass in log quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type echoreq keep state label "71dd196398b3f1da265dbd9dcad00e70"
@46 pass in log quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type routersol keep state label "71dd196398b3f1da265dbd9dcad00e70"
@47 pass in log quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type routeradv keep state label "71dd196398b3f1da265dbd9dcad00e70"
@48 pass in log quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type neighbrsol keep state label "71dd196398b3f1da265dbd9dcad00e70"
@49 pass in log quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type neighbradv keep state label "71dd196398b3f1da265dbd9dcad00e70"
@50 block drop in log quick inet proto tcp from any port = 0 to any label "7b5bdc64d7ae74be1932f6764a591da5"
@51 block drop in log quick inet proto udp from any port = 0 to any label "7b5bdc64d7ae74be1932f6764a591da5"
@52 block drop in log quick inet6 proto tcp from any port = 0 to any label "7b5bdc64d7ae74be1932f6764a591da5"
@53 block drop in log quick inet6 proto udp from any port = 0 to any label "7b5bdc64d7ae74be1932f6764a591da5"
@54 block drop in log quick inet proto tcp from any to any port = 0 label "ae69f581dc429e3484a65f8ecd63baa5"
@55 block drop in log quick inet proto udp from any to any port = 0 label "ae69f581dc429e3484a65f8ecd63baa5"
@56 block drop in log quick inet6 proto tcp from any to any port = 0 label "ae69f581dc429e3484a65f8ecd63baa5"
@57 block drop in log quick inet6 proto udp from any to any port = 0 label "ae69f581dc429e3484a65f8ecd63baa5"
@58 pass log quick inet6 proto carp from any to ff02::12 keep state label "cf439d72ef4d245e8ad4a1405df1f665"
@59 pass log quick inet proto carp from any to 224.0.0.18 keep state label "2ffa978d51f7b3fbc9000c2895106ee7"
@60 block drop in log quick proto tcp from <sshlockout:0> to (self:14) port = 8908 label "db8f7226d24fe8390da89c8bfcab11d4"
@61 block drop in log quick proto tcp from <sshlockout:0> to (self:14) port = 8443 label "8a7589316cc5c5cb69c0eb81112fb366"
@62 block drop in log quick from <virusprot:0> to any label "8e367e2f9944d93137ae56d788c5d5e1"
@63 pass in log quick on igc1 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "5168be2cca1e130b1ef2ac18161356a8"
@64 pass in log quick on igc1 proto udp from any port = bootpc to (self:14) port = bootps keep state label "0b032d1bab91fc97e4a7faf03a7f17c3"
@65 pass out log quick on igc1 proto udp from (self:14) port = bootps to any port = bootpc keep state label "5039e43005a9aa50eb032af274cc9aad"
@66 pass in log quick on igc1 inet6 proto udp from fe80::/10 to fe80::/10 port = dhcpv6-client keep state label "fef3d333d96a8d3558956de1fffc61cc"
@67 pass in log quick on igc1 inet6 proto udp from fe80::/10 to ff02::/16 port = dhcpv6-client keep state label "fef3d333d96a8d3558956de1fffc61cc"
@68 pass in log quick on igc1 inet6 proto udp from fe80::/10 to ff02::/16 port = dhcpv6-server keep state label "d2bd536587a9f5680c1f850b2d346839"
@69 pass in log quick on igc1 inet6 proto udp from ff02::/16 to fe80::/10 port = dhcpv6-server keep state label "3420206ced96c01ef73fbc4ac9deb745"
@70 pass in log quick on igc1 inet6 proto udp from fe80::/10 to (self:7) port = dhcpv6-client keep state label "0fd202708c326aebbe44ab710b6d3652"
@71 pass out log quick on igc1 inet6 proto udp from (self:7) port = dhcpv6-server to fe80::/10 keep state label "83f6c28de8efae9b444094e4a5bf898c"
@72 pass in log quick on igc2 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "07daf606e4baa82915478774a40f014d"
@73 pass in log quick on igc2 proto udp from any port = bootpc to (self:14) port = bootps keep state label "1e13125d68d267924569eadb69fa1ad1"
@74 pass out log quick on igc2 proto udp from (self:14) port = bootps to any port = bootpc keep state label "4eb553ee95bcbf5299054b24b13f5528"
@75 pass in log quick on igc3 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "102fc1c757023ef7f945d512ed212862"
@76 pass in log quick on igc3 proto udp from any port = bootpc to (self:14) port = bootps keep state label "09ef23f01c5890e379d587e8e2d3dea0"
@77 pass out log quick on igc3 proto udp from (self:14) port = bootps to any port = bootpc keep state label "4d95e0fbab26f616dedb0dda7c7581c3"
@78 pass in log quick on igc0 proto udp from any port = bootps to any port = bootpc keep state label "f994f615e00b8be0042263f86c79913f"
@79 pass out log quick on igc0 proto udp from any port = bootpc to any port = bootps keep state label "5cf7ab808da1fcbca1ddb9ba9b46b669"
@80 pass in log quick on igc4 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "5abb7d88958c4e6df293f4bdf4663c7b"
@81 pass in log quick on igc4 proto udp from any port = bootpc to (self:14) port = bootps keep state label "033633dc5b7d01a4ed8a7ee32de9e4f6"
@82 pass out log quick on igc4 proto udp from (self:14) port = bootps to any port = bootpc keep state label "d0acc14b6054e272353f9b9147abb923"
@83 block drop in quick inet from <crowdsec_blacklists:38091> to any label "3dece8d37a64bb42cdb4de03f79519e7"
@84 block drop in quick inet6 from <crowdsec6_blacklists:29> to any label "2fe2f572b74d29f8a46214fc4c95b151"
@85 block drop in log quick on igc0 inet from <bogons:853> to any label "b7cd97a164650b538506fb551a0369e7"
@86 block drop in log quick on igc0 inet6 from <bogonsv6:144340> to any label "f140a48ddade668b9d6f5259669a1d5c"
@87 block drop in log quick on igc0 inet from 10.0.0.0/8 to any label "1eb94a38e58994641aff378c21d5984f"
@88 block drop in log quick on igc0 inet from 127.0.0.0/8 to any label "1eb94a38e58994641aff378c21d5984f"
@89 block drop in log quick on igc0 inet from 100.64.0.0/10 to any label "1eb94a38e58994641aff378c21d5984f"
@90 block drop in log quick on igc0 inet from 172.16.0.0/12 to any label "1eb94a38e58994641aff378c21d5984f"
@91 block drop in log quick on igc0 inet from 192.168.0.0/16 to any label "1eb94a38e58994641aff378c21d5984f"
@92 block drop in log quick on igc0 inet6 from fc00::/7 to any label "45afd72424c84d011c07957569151480"
@93 pass in quick on lo0 all no state label "7535c94082e72e2207679aadb26afd92"
@94 pass out log all flags S/SA keep state allow-opts label "fae559338f65e11c53669fc3642c93c2"
@95 pass in log quick on igc1 proto tcp from any to (self:14) port = 8443 flags S/SA keep state label "b3d0aa308cae0f22daa73b5ebfdd6380"
@96 pass in log quick on igc1 proto tcp from any to (self:14) port = 8908 flags S/SA keep state label "b3d0aa308cae0f22daa73b5ebfdd6380"
@97 pass out log route-to (igc0 192.168.178.1) inet from (igc0:1) to ! (igc0:network:1) flags S/SA keep state allow-opts label "43ddc4e7182143cfd0e584aa8c76e779"
@98 pass log quick on igc1 inet proto tcp from any to <GIT_IP_Whitelist:2> port = https flags S/SA keep state label "5fe609e54818e435919c8acdc9ae5fc8"
@99 pass log quick on igc2 inet proto tcp from any to <GIT_IP_Whitelist:2> port = https flags S/SA keep state label "5fe609e54818e435919c8acdc9ae5fc8"
@100 pass log quick on igc3 inet proto tcp from any to <GIT_IP_Whitelist:2> port = https flags S/SA keep state label "5fe609e54818e435919c8acdc9ae5fc8"
@101 pass log quick on wg0 inet proto tcp from any to <GIT_IP_Whitelist:2> port = https flags S/SA keep state label "5fe609e54818e435919c8acdc9ae5fc8"
@102 pass log quick on igc0 inet proto tcp from any to <GIT_IP_Whitelist:2> port = https flags S/SA keep state label "5fe609e54818e435919c8acdc9ae5fc8"
@103 pass log quick on igc1 inet proto tcp from any to 140.82.121.4 port = ssh flags S/SA keep state label "f4ba95622bae15933a258d80d7ce1e8c"
@104 pass log quick on igc2 inet proto tcp from any to 140.82.121.4 port = ssh flags S/SA keep state label "f4ba95622bae15933a258d80d7ce1e8c"
@105 pass log quick on igc3 inet proto tcp from any to 140.82.121.4 port = ssh flags S/SA keep state label "f4ba95622bae15933a258d80d7ce1e8c"
@106 pass log quick on wg0 inet proto tcp from any to 140.82.121.4 port = ssh flags S/SA keep state label "f4ba95622bae15933a258d80d7ce1e8c"
@107 pass log quick on igc0 inet proto tcp from any to 140.82.121.4 port = ssh flags S/SA keep state label "f4ba95622bae15933a258d80d7ce1e8c"
@108 pass in quick inet proto tcp from any to ! <GIT_IP_Whitelist:2> flags S/SA keep state label "d3591b10e43743e30a709ce7663b59fa"
@109 pass in quick inet proto udp from any to ! <GIT_IP_Whitelist:2> keep state label "d3591b10e43743e30a709ce7663b59fa"
@110 block drop log quick on igc1 inet from <Malicious_IPs:18916> to any label "676a9f50666a42c84301e677e1372c22"
@111 block drop log quick on igc1 inet6 from <Malicious_IPs:18916> to any label "676a9f50666a42c84301e677e1372c22"
@112 block drop log quick on igc2 inet from <Malicious_IPs:18916> to any label "676a9f50666a42c84301e677e1372c22"
@113 block drop log quick on igc2 inet6 from <Malicious_IPs:18916> to any label "676a9f50666a42c84301e677e1372c22"
@114 block drop log quick on igc3 inet from <Malicious_IPs:18916> to any label "676a9f50666a42c84301e677e1372c22"
@115 block drop log quick on igc3 inet6 from <Malicious_IPs:18916> to any label "676a9f50666a42c84301e677e1372c22"
@116 block drop log quick on wg0 inet from <Malicious_IPs:18916> to any label "676a9f50666a42c84301e677e1372c22"
@117 block drop log quick on wg0 inet6 from <Malicious_IPs:18916> to any label "676a9f50666a42c84301e677e1372c22"
@118 block drop log quick on igc0 inet from <Malicious_IPs:18916> to any label "676a9f50666a42c84301e677e1372c22"
@119 block drop log quick on igc0 inet6 from <Malicious_IPs:18916> to any label "676a9f50666a42c84301e677e1372c22"
@120 block drop log quick on igc4 inet from <Malicious_IPs:18916> to any label "676a9f50666a42c84301e677e1372c22"
@121 block drop log quick on igc4 inet6 from <Malicious_IPs:18916> to any label "676a9f50666a42c84301e677e1372c22"
@122 block drop log quick on igc1 inet from any to <Malicious_IPs:18916> label "be5085ce30e680463235dc3d9e4c436d"
@123 block drop log quick on igc1 inet6 from any to <Malicious_IPs:18916> label "be5085ce30e680463235dc3d9e4c436d"
@124 block drop log quick on igc2 inet from any to <Malicious_IPs:18916> label "be5085ce30e680463235dc3d9e4c436d"
@125 block drop log quick on igc2 inet6 from any to <Malicious_IPs:18916> label "be5085ce30e680463235dc3d9e4c436d"
@126 block drop log quick on igc3 inet from any to <Malicious_IPs:18916> label "be5085ce30e680463235dc3d9e4c436d"
@127 block drop log quick on igc3 inet6 from any to <Malicious_IPs:18916> label "be5085ce30e680463235dc3d9e4c436d"
@128 block drop log quick on wg0 inet from any to <Malicious_IPs:18916> label "be5085ce30e680463235dc3d9e4c436d"
@129 block drop log quick on wg0 inet6 from any to <Malicious_IPs:18916> label "be5085ce30e680463235dc3d9e4c436d"
@130 block drop log quick on igc0 inet from any to <Malicious_IPs:18916> label "be5085ce30e680463235dc3d9e4c436d"
@131 block drop log quick on igc0 inet6 from any to <Malicious_IPs:18916> label "be5085ce30e680463235dc3d9e4c436d"
@132 block drop log quick on igc4 inet from any to <Malicious_IPs:18916> label "be5085ce30e680463235dc3d9e4c436d"
@133 block drop log quick on igc4 inet6 from any to <Malicious_IPs:18916> label "be5085ce30e680463235dc3d9e4c436d"
@134 block drop in log quick inet from any to <Malicious_IPs:18916> label "15d4b08e375bd5b4a1bfe3b8dd0e8eaf"
@135 block drop in log quick inet6 from any to <Malicious_IPs:18916> label "15d4b08e375bd5b4a1bfe3b8dd0e8eaf"
@136 block drop in log quick on igc1 inet from any to <crowdsec_blacklists:38091> label "33d9f0f6541d0b4f4e3d0cff2c201978"
@137 block drop in log quick on igc2 inet from any to <crowdsec_blacklists:38091> label "33d9f0f6541d0b4f4e3d0cff2c201978"
@138 block drop in log quick on igc3 inet from any to <crowdsec_blacklists:38091> label "33d9f0f6541d0b4f4e3d0cff2c201978"
@139 block drop in log quick on wg0 inet from any to <crowdsec_blacklists:38091> label "33d9f0f6541d0b4f4e3d0cff2c201978"
@140 block drop in log quick on igc0 reply-to (igc0 192.168.178.1) inet from any to <crowdsec_blacklists:38091> label "33d9f0f6541d0b4f4e3d0cff2c201978"
@141 block drop in log quick on wireguard inet from any to <crowdsec_blacklists:38091> label "33d9f0f6541d0b4f4e3d0cff2c201978"
@142 block drop in log quick on igc1 inet from any to <crowdsec6_blacklists:29> label "257e8fa5902cc9c5e1428aad8d1b5953"
@143 block drop in log quick on igc2 inet from any to <crowdsec6_blacklists:29> label "257e8fa5902cc9c5e1428aad8d1b5953"
@144 block drop in log quick on igc3 inet from any to <crowdsec6_blacklists:29> label "257e8fa5902cc9c5e1428aad8d1b5953"
@145 block drop in log quick on wg0 inet from any to <crowdsec6_blacklists:29> label "257e8fa5902cc9c5e1428aad8d1b5953"
@146 block drop in log quick on igc0 reply-to (igc0 192.168.178.1) inet from any to <crowdsec6_blacklists:29> label "257e8fa5902cc9c5e1428aad8d1b5953"
@147 block drop in log quick on wireguard inet from any to <crowdsec6_blacklists:29> label "257e8fa5902cc9c5e1428aad8d1b5953"
@148 pass in log quick on igc0 reply-to (igc0 192.168.178.1) inet proto udp from any to (igc0:1) port = 51820 keep state label "d1a7879fa18dc8ea0aa7df5c99b10957"
@149 pass in quick on igc0 reply-to (igc0 192.168.178.1) inet proto tcp from any to (igc0:1) port = http flags S/SA keep state label "e1c879a2f139a936f547b953d96c3ea8"
@150 pass in quick on igc0 reply-to (igc0 192.168.178.1) inet proto tcp from any to (igc0:1) port = https flags S/SA keep state label "e1c879a2f139a936f547b953d96c3ea8"
@151 pass in quick on igc0 reply-to (igc0 192.168.178.1) inet proto tcp from any to (self:7) port = http flags S/SA keep state label "da8e692e0c200ca488800341b823ad5f"
@152 pass in quick on igc0 inet6 proto tcp from any to (self:7) port = http flags S/SA keep state label "da8e692e0c200ca488800341b823ad5f"
@153 pass in quick on igc0 reply-to (igc0 192.168.178.1) inet proto tcp from any to (self:7) port = https flags S/SA keep state label "c79619348261fdc4b0204ec4a93888bf"
@154 pass in quick on igc0 inet6 proto tcp from any to (self:7) port = https flags S/SA keep state label "c79619348261fdc4b0204ec4a93888bf"
@155 pass in quick on igc1 inet from (igc1:network:1) to any flags S/SA keep state label "7ec30a775f5761dbf17c1d22463d22f8"
@156 pass in quick on igc1 inet proto tcp from any to (self:7) port = http flags S/SA keep state label "5a3af4610c82e86b6113ec6de17d01e6"
@157 pass in quick on igc1 inet proto tcp from any to (self:7) port = https flags S/SA keep state label "f2db1a9c60f4c9b97b664231fc82661f"
@158 pass in log quick on igc2 inet proto tcp from any to any port = http flags S/SA keep state label "e1547fc82abbc47d6ef7b9440d85e82b"
@159 pass in log quick on igc2 inet6 proto tcp from any to any port = http flags S/SA keep state label "e1547fc82abbc47d6ef7b9440d85e82b"
@160 pass in log quick on igc2 inet proto tcp from any to any port = https flags S/SA keep state label "f95e87d88701fc2304c8e349665351ff"
@161 pass in log quick on igc2 inet6 proto tcp from any to any port = https flags S/SA keep state label "f95e87d88701fc2304c8e349665351ff"
@162 block drop in log quick on igc2 inet all label "7197d9fcb10047f871039c7c234b4dbf"
@163 block drop in log quick on igc2 inet6 all label "7197d9fcb10047f871039c7c234b4dbf"
@164 pass in quick on wg0 inet from (wg0:network:1) to any flags S/SA keep state label "2e8c745ab1902678c973687535685c2b"
@165 pass in quick on wg0 inet6 from (wg0:network:*) to any flags S/SA keep state label "2e8c745ab1902678c973687535685c2b"
@166 pass in quick on wg0 inet6 from fe80::/10 to any flags S/SA keep state label "2e8c745ab1902678c973687535685c2b"
@167 block drop in quick on wg0 inet all label "40581bc9034fd36869d4ab7e5becf3f8"
@168 block drop in quick on wg0 inet6 all label "40581bc9034fd36869d4ab7e5becf3f8"
@169 pass in quick on igc3 inet proto tcp from any to any port = http flags S/SA keep state label "1ee9e2a05608bfdb51125289d53f8f0f"
@170 pass in quick on igc3 inet6 proto tcp from any to any port = http flags S/SA keep state label "1ee9e2a05608bfdb51125289d53f8f0f"
@171 pass in quick on igc3 inet proto tcp from any to any port = https flags S/SA keep state label "a38d8e0ca66004679bc5382f1f5cfb46"
@172 pass in quick on igc3 inet6 proto tcp from any to any port = https flags S/SA keep state label "a38d8e0ca66004679bc5382f1f5cfb46"
@173 block drop in log quick on igc3 inet all label "74bd3df10ff01798ced3ef3c799b8204"
@174 block drop in log quick on igc3 inet6 all label "74bd3df10ff01798ced3ef3c799b8204"
@175 pass in log quick on igc4 inet proto tcp from any to any port = https flags S/SA keep state label "eb48731bc83c94b53075159c2f99a83e"
@176 pass in log quick on igc4 inet6 proto tcp from any to any port = https flags S/SA keep state label "eb48731bc83c94b53075159c2f99a83e"
@177 pass in log quick on igc4 inet proto tcp from any to any port = http flags S/SA keep state label "f373f203f7e75e24591ab4035e1e4b65"
@178 pass in log quick on igc4 inet6 proto tcp from any to any port = http flags S/SA keep state label "f373f203f7e75e24591ab4035e1e4b65"
@179 block drop in log quick on igc4 inet all label "bb19ae9f9b0fc5379daa88758052b390"
@180 block drop in log quick on igc4 inet6 all label "bb19ae9f9b0fc5379daa88758052b390"
@181 pass in quick on wireguard inet from (wireguard:network:1) to any flags S/SA keep state label "2be27c99ad49942931537e63da8b9c23"
@182 block drop in log quick on wireguard inet from (wireguard:network:1) to any label "53ceaf9f9d50ae2042c06b1322219941"
@183 anchor "acme-client/*" all
@184 anchor "iperf" all
nat rules
@0 no nat proto carp all
@1 nat on igc0 inet from (igc1:network:1) to any port = isakmp -> (igc0:0) static-port
@2 nat on igc0 inet from (lo0:network:1) to any port = isakmp -> (igc0:0) static-port
@3 nat on igc0 inet from (igc2:network:1) to any port = isakmp -> (igc0:0) static-port
@4 nat on igc0 inet from (igc3:network:1) to any port = isakmp -> (igc0:0) static-port
@5 nat on igc0 inet from (wg0:network:1) to any port = isakmp -> (igc0:0) static-port
@6 nat on igc0 inet from (igc4:network:1) to any port = isakmp -> (igc0:0) static-port
@7 nat on igc0 inet from 127.0.0.0/8 to any port = isakmp -> (igc0:0) static-port
@8 nat on igc0 inet from (igc1:network:1) to any -> (igc0:0) port 1024:65535
@9 nat on igc0 inet from (lo0:network:1) to any -> (igc0:0) port 1024:65535
@10 nat on igc0 inet from (igc2:network:1) to any -> (igc0:0) port 1024:65535
@11 nat on igc0 inet from (igc3:network:1) to any -> (igc0:0) port 1024:65535
@12 nat on igc0 inet from (wg0:network:1) to any -> (igc0:0) port 1024:65535
@13 nat on igc0 inet from (igc4:network:1) to any -> (igc0:0) port 1024:65535
@14 nat on igc0 inet from 127.0.0.0/8 to any -> (igc0:0) port 1024:65535
@15 nat-anchor "acme-client/*" all
@0 no rdr proto carp all
@1 no rdr on igc1 proto tcp from any to (igc1:2) port = 8443
@2 no rdr on igc1 proto tcp from any to (igc1:2) port = 8908
@3 rdr-anchor "acme-client/*" all
Ich werde zum Test mal deinen Vorschlag umsetzen _und_ mal die Local Access List im Caddy entfernen. Wenn ich von draußen rein komme, müsste die Config soweit stimmen und mich rein lassen.
Nochmal ein kurzes Update.
Ich habe die Acces Liste entfernt und es geht. Also von außen habe ich keine Probleme und die Config scheint soweit auch zu passen.
Ich habe mir nochmal den tcpdump angesehen.. hatte vorher meinen filter falsch. Aber ich sehe doch die Antwort und mein DNS Server gibt mir folgendes zurück:
Flags: 0x8182 Standard query response, Server failure
1... .... .... .... = Response: Message is a response
.000 0... .... .... = Opcode: Standard query (0)
.... .0.. .... .... = Authoritative: Server is not an authority for domain
.... ..0. .... .... = Truncated: Message is not truncated
.... ...1 .... .... = Recursion desired: Do query recursively
.... .... 1... .... = Recursion available: Server can do recursive queries
.... .... .0.. .... = Z: reserved (0)
.... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
.... .... ...0 .... = Non-authenticated data: Unacceptable
.... .... .... 0010 = Reply code: Server failure (2)
Wer ist denn DNS Server in deinem Netz? Unbound mit standardkonfig auf der OPNsense? Oder etwas spezielles?
Du hast Recht, bei deinen Regeln sehe ich keine speziellen NAT oder RDR Regeln.
Hier ist ein DNS Problem im Gang.
Ich hatte bei Unbound auf der OPNsense ein paar Domains die nicht aufgelöst werden konnten (rekursiv). Hier half es Weiterleitungen für einzelne Domains so konfigurieren, die z.B. auf 1.1.1.1 zeigen. Dann wird für die einzelne Domain nicht der rekursive Weg sondern eine Weiterleitung genommen um das Ergebnis der Auflösung von 1.1.1.1 zu bekommen.
Ich habe dieses Adguard und Unbound konstrukt auf der OPNsense direkt.
Hi again,
danke übrigens für die bisherige Hilfe.
ich habe mir meine DNS config nochmal genaustens angesehen. Ich hatte es bei meiner Wireguard Einrichtung neu angepasst.
Ich hatte mir dafür diesen Guide angesehen: https://windgate.net/setup-adguard-home-opnsense-adblocker/
Im prinzip habe ich es 1:1 wie dort beschrieben.
Nochmal um mein Verständnis wegen..
Wenn Unbound als DNS Server fungiert, muss dem ja irgendwie der FQDN genannt werden. Das mein DNS Query Request fehl schlägt, scheint ja dann eigentlich folglich richtig, weil meine subdomain ja kein Host an sich ist. Das ist nur eine eingestellte Subdomain die entweder als A-Record bei Cloudflare, oder bei Caddy als Subdomain hinterlegt ist. Wie bekommt mein DNS Server dann also mit wo genau die Adresse hinterlegt ist. Somit wird die Anfrage also an Cloudflare weitergeleitet, welcher dann die Antwort mit meiner Pub-IP zurück gibt.
Ich vermisse den Punkt an dem mein DNS Server merkt, dass es da local einen Proxy gibt der diese Antwort an den DNS Server weiter reicht.
Dadurch das ich bei meiner DNS/Adblock config nach mehrmaligen drüber gucken, keinen Fehler erkenne, muss es an dem fehlenden A Record liegen.
Ich habe händisch in Unbound>Überschreibungen>Host Überschreibungen einen A Record (ncloud.example.com = <opnsense IP>) angelegt, aber scheinbar wird das ignoriert. Ich erhalte weiterhin meine public IP "Standard query response, No error" als Antwort von unbound. Sofern ich den trace im Wireshark richtig lese. Ich weiß nicht ob der letzte Host, oder der erste Host mit der richtigen Antwort als Source angezeigt wird.
Ich habe bei mir im Unbound lediglich in DNS over TLS - 4 DNS Server gelistet.
Unter System>Einstellungen>Allgemein habe ich keinen DNS Server eingetragen.
Sonst noch eine idee?
Kein Problem, kann nur gerade nicht mehr helfen.
Ich benutze Unbound als rekursiven DNS Server ohne Schnickschnack. (Kein DNS over TLS, kein Adguard Home... etc...)
Wenn was nicht klappt einfach die Komplexivität verringern bis DNS richtig funktioniert.
Ich habs gelöst.
Ich bin hier im Forum fündig geworden:
https://forum.opnsense.org/index.php?topic=23576.0
Quote... in the Bootstrap DNS Servers under DNS Settings...
192.168.11.1:5353 (My firewall IP)
127.0.0.1:5353 Nachdem ich das bei mir eingetragen hab, hat der Zugriff mit lokalen IP's problemlos geklappt.
Jetzt hätte ich noch eine letzte Frage.
Wieso greift mein Header nicht? Hab ich den falsch formuliert? (Siehe Bild)
Danke nochmal für jede Hilfe. Ihr habt mir die entscheidenden Tipps gegeben.
Hallo super dass du weiterkommst.
Wegen dem Header, zeig mir bitte mal das Caddyfile.
Ich habe vorerst nur den einen Header.
# DO NOT EDIT THIS FILE -- OPNsense auto-generated file
# Global Options
{
log {
include http.log.access.37fc6c8b-42c2-41e0-baba-c38516660295
output net unixgram//var/caddy/var/run/log {
}
format json {
time_format rfc3339
}
}
dynamic_dns {
provider cloudflare <some token>
domains {
example.com *
}
}
email <redacted>
grace_period 10s
import /usr/local/etc/caddy/caddy.d/*.global
}
# Reverse Proxy Configuration
# Reverse Proxy Domain: "37fc6c8b-42c2-41e0-baba-c38516660295"
*.example.com {
log 37fc6c8b-42c2-41e0-baba-c38516660295
tls {
dns cloudflare <Token>
}
@3bc73ecf-09b3-40ed-9ae2-1a29fc02bca6 {
host ncloud.example.com
}
handle @3bc73ecf-09b3-40ed-9ae2-1a29fc02bca6 {
@0ca7ce31-a10f-46f1-90a0-b8a87f40a05f {
client_ip 100.65.0.0/24 192.168.1.0/24
}
handle @0ca7ce31-a10f-46f1-90a0-b8a87f40a05f {
handle {
reverse_proxy 192.168.200.2:8666 {
header_up Strict-Transport-Security "max-age=15552000; "
fail_duration 30s
}
}
}
}
}
import /usr/local/etc/caddy/caddy.d/*.conf
Ich glaube das Problem ist das "; " am Ende. Da ist ein Leerzeichen, und ich weiß nicht ob das ; dort sein darf.
Ich bin wiedermal ratlos.
Die Syntax schient wohl nix auszumachen, weil es eh nicht am Server ankommt. Ich bekomme aber noch mehr Fehler/Warnmeldeungen als vorher angezeigt.
Die Header in NGINX zu erstellen und zu nutzen war einfacher als das hier. :D
Was ich in der Einrichtungswarnung bei Nextcloud erhalte:
Einige Header sind in deiner Instanz nicht richtig eingestellt - Der HTTP-Header `X-Content-Type-Options` ist nicht auf `nosniff` gesetzt. Dies stellt ein potenzielles Sicherheits- oder Datenschutzrisiko dar und es wird empfohlen, diese Einstellung zu ändern. - Der HTTP-Header `X-Robots-Tag` ist nicht auf `noindex,nofollow` gesetzt. Dies stellt ein potenzielles Sicherheits- oder Datenschutzrisiko dar und es wird empfohlen, diese Einstellung zu ändern. - Der HTTP-Header `X-Frame-Options` ist nicht auf `sameorigin` gesetzt. Dies stellt ein potenzielles Sicherheits- oder Datenschutzrisiko dar und es wird empfohlen, diese Einstellung zu ändern. - Der HTTP-Header `X-Permitted-Cross-Domain-Policies` ist nicht auf `none` gesetzt. Dies stellt ein potenzielles Sicherheits- oder Datenschutzrisiko dar und es wird empfohlen, diese Einstellung zu ändern. - Der HTTP-Header `X-XSS-Protection` enthält nicht `1; mode=block`. Dies stellt ein potenzielles Sicherheits- oder Datenschutzrisiko dar und es wird empfohlen, diese Einstellung zu ändern. - Der HTTP-Header `Referrer-Policy` ist nicht auf "no-referrer", "no-referrer-when-downgrade", "strict-origin", "strict-origin-when-cross-origin" oder "same-origin" gesetzt. Dadurch können Verweisinformationen preisgegeben werden. Siehe die W3C Recommendation. - Der `Strict-Transport-Security`-HTTP-Header ist nicht gesetzt (er sollte mindestens `15552000` Sekunden betragen). Für erhöhte Sicherheit wird empfohlen, HSTS zu aktivieren. Weitere Informationen findest du in der Dokumentation ↗.
Was ich eingestellt habe:
handle @0ca7ce31-a10f-46f1-90a0-b8a87f40a05f {
handle {
reverse_proxy 192.168.200.2:8666 {
header_up Referrer-Policy "no-referrer"
header_up Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
header_up X-Content-Type-Options "nosniff"
header_up X-Frame-Options "SAMEORIGIN"
header_up X-Permitted-Cross-Domain-Policies "none"
header_up X-Robots-Tag "noindex, nofollow"
header_up X-XSS-Protection "1; mode=block"
fail_duration 30s
}
}
}
Auf dem Server in den Logs finde ich z.B. sowas:
"reqId":"VUfbD1ANpY87CywcjSff","level":0,"time":"2024-06-24T07:38:13+00:00","remoteAddr":"172.17.0.1","user":"--","app":"webdav","method":"GET","url":"/remote.php/dav/",
"message":"No public access to this resource., No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorizatio
n: Bearer' header found. Either the client didn't send one, or the server is mis-configured, No 'Authorization: Basic' header found. Either the client didn't send one, or
the server is misconfigured","userAgent":"Nextcloud Server Crawler","version":"29.0.2.2","exception":{"Exception":"Sabre\\DAV\\Exception\\NotAuthenticated","Message":"No
public access to this resource., No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' he
ader found. Either the client didn't send one, or the server is mis-configured, No 'Authorization: Basic' header found. Either the client didn't send one, or the server i
s misconfigured","Code":0,"Trace":[{"file":"/var/www/html/3rdparty/sabre/event/lib/WildcardEmitterTrait.php","line":89,"function":"beforeMethod","class":"Sabre\\DAV\\Auth
\\Plugin","type":"->","args":[["Sabre\\HTTP\\Request"],["Sabre\\HTTP\\Response"]]},{"file":"/var/www/html/3rdparty/sabre/dav/lib/DAV/Server.php","line":456,"function":"em
it","class":"Sabre\\DAV\\Server","type":"->","args":["beforeMethod:GET",[["Sabre\\HTTP\\Request"],["Sabre\\HTTP\\Response"]]]},{"file":"/var/www/html/3rdparty/sabre/dav/l
ib/DAV/Server.php","line":253,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->","args":[["Sabre\\HTTP\\Request"],["Sabre\\HTTP\\Response"]]},{"file":"/va
r/www/html/3rdparty/sabre/dav/lib/DAV/Server.php","line":321,"function":"start","class":"Sabre\\DAV\\Server","type":"->","args":[]},{"file":"/var/www/html/apps/dav/lib/Se
rver.php","line":374,"function":"exec","class":"Sabre\\DAV\\Server","type":"->","args":[]},{"file":"/var/www/html/apps/dav/appinfo/v2/remote.php","line":35,"function":"ex
ec","class":"OCA\\DAV\\Server","type":"->","args":[]},{"file":"/var/www/html/remote.php","line":172,"args":["/var/www/html/apps/dav/appinfo/v2/remote.php"],"function":"re
quire_once"}],"File":"/var/www/html/3rdparty/sabre/dav/lib/DAV/Auth/Plugin.php","Line":152,"message":"No public access to this resource., No 'Authorization: Basic' header
found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mi
s-configured, No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured","exception":{},"CustomMessage":"No public access
to this resource., No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' header found. Eit
her the client didn't send one, or the server is mis-configured, No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured
"}}
Ist bei der Nextcloud Trusted Proxies konfiguriert?
https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/reverse_proxy_configuration.html#defining-trusted-proxies
Wenn du Probleme mit den Headern hast, das ist jetzt gar nicht mehr so mein Gebiet. Vielleicht kannst du dort in der https://caddy.community bessere Hilfe finden.
Wobei ich glaube es fehlt das + bei dem Header. Aber unsicher hier. Gehe nur nach Anleitung
https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#headers
header_up +Some-Header "first value"
header_up +Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
Das + scheint hier leider auch nicht zu helfen. Ich habe mir die Doku vorher auch mal angesehen. Ich bin auch unsicher, ob man vielleicht Header "ersetzen" bzw. mit seinem Header überschreiben muss.
Quote
header_down sets, adds (with the + prefix), deletes (with the - prefix), or performs a replacement (by using two arguments, a search and replacement) in a response header coming downstream from the backend.
handle @0ca7ce31-a10f-46f1-90a0-b8a87f40a05f {
handle {
reverse_proxy 192.168.200.2:8666 {
header_up +Referrer-Policy "no-referrer"
header_up +Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
header_up +X-Content-Type-Options "nosniff"
header_up +X-Frame-Options "SAMEORIGIN"
header_up +X-Permitted-Cross-Domain-Policies "none"
header_up +X-Robots-Tag "noindex, nofollow"
header_up +X-XSS-Protection "1; mode=block"
fail_duration 30s
}
Proxy config
'trusted_proxies' =>
array (
0 => '192.168.200.1', #Opnsense Interface für Unraid
),
Was ich leider bei Caddy in der GUI nicht finde, sind so Weiterleitungen wie diese hier aus der Nextcloud Doku:
redir /.well-known/carddav /remote.php/dav/ 301
redir /.well-known/caldav /remote.php/dav/ 301
Dafür das Caddy so einfach ist, ist es doch schon ganz schön kompliziert. :D
Interessant finde ich auch diese Meldung. Sowas hatte ich vorher mit NGINX nicht.
Dein Datenverzeichnis und deine Dateien sind wahrscheinlich vom Internet aus erreichbar. Die .htaccess-Datei funktioniert nicht. Es wird dringend empfohlen, deinen Webserver dahingehend zu konfigurieren, dass das Datenverzeichnis nicht mehr vom Internet aus erreichbar ist oder dass du es aus dem Document-Root-Verzeichnis des Webservers herausverschiebst.
Quote from: W0nderW0lf on June 24, 2024, 12:03:34 PM
Was ich leider bei Caddy in der GUI nicht finde, sind so Weiterleitungen wie diese hier aus der Nextcloud Doku:
redir /.well-known/carddav /remote.php/dav/ 301
redir /.well-known/caldav /remote.php/dav/ 301
Das machst du ja auch in dem Webserver, unter dem deine Nextcloud-Instanz läuft und nicht auf dem vorgelagerten Reverse-Proxy.
Da muss ich dir widersprechen.
QuoteThe redirects for CalDAV or CardDAV does not work if Nextcloud is running behind a reverse proxy. The recommended solution is that your reverse proxy does the redirects.
Das gleiche hatte ich bei mir im NGINX auch drin gehabt.
Quelle? Ich habe das genau so am laufen.
In Nginx:
location = /.well-known/carddav { return 301 /remote.php/dav/; }
location = /.well-known/caldav { return 301 /remote.php/dav/; }
Quelle: https://docs.nextcloud.com/server/29/admin_manual/installation/nginx.html
In Caddy auf der OPNsense hab ich einen Eintrag - externe Domain + Handler --> interne IP-Adresse, Port 80, keine Spezialitäten, gar nichts.
Steht hier in Service Discovery als erstes drin
https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/reverse_proxy_configuration.html#defining-trusted-proxies
Caddy ist einfach wenn man Standard will, weil es vieles automatisch macht.
Wie bei allem kann es auch hier schnell kompliziert werden wenn es um mehr als den reinen Standard geht. Webroot ändern, header, redirects, rewrites etc... geht. So wie bei nginx und apache2 auch.
Was dann einfach oder schwer ist, entscheidet jeder für sich.
Dass es mit den Headern nicht klappt ist wahrscheinlich irgend ein Logikfehler aber ich kenne mich hier zu wenig aus. Wenn es aber eine Schwäche der Template generierung vom Caddyfile ist, kann ich es beheben wenn ich weiß was der Fehler ist.
EDIT: Redirects sind in der Caddy GUI (noch nicht) eingebaut. Hat bisher keiner auf github gefragt.
EDIT2: Ich frage wegen den headern mal die Caddy Entwickler ob das so stimmt oder nicht.
Quote from: W0nderW0lf on June 24, 2024, 12:15:10 PM
Steht hier in Service Discovery als erstes drin
https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/reverse_proxy_configuration.html#defining-trusted-proxies
Halte ich für Quatsch:
$ curl -v https://**********/.well-known/carddav
* Host **********:443 was resolved.
* [HTTP/2] [1] OPENED stream for https://**********/.well-known/carddav
< HTTP/2 301
< alt-svc: h3=":443"; ma=2592000
< content-type: text/html
< date: Mon, 24 Jun 2024 10:17:49 GMT
< location: http://**********/remote.php/dav/
< referrer-policy: no-referrer
< server: Caddy
< server: nginx
< strict-transport-security: max-age=15768000; includeSubDomains; preload
< x-content-type-options: nosniff
< x-frame-options: SAMEORIGIN
< x-permitted-cross-domain-policies: none
< x-robots-tag: noindex, nofollow
< x-xss-protection: 1; mode=block
< content-length: 162
<
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Connection #0 to host ********** left intact
Ich habe eine Antwort von den Caddy Maintainern:
- Security headers sind wie ein Vertrag zwischen Browser und Web Applikation. Sie sollten also in der Nextcloud direkt gesetzt werden. Für den Reverse Proxy sind sie dann transparent.
- Wenn das aus irgend einem Grund nicht geht, sollte "header_down" verwendet werden. Aber das ist unnötig, da diese Header immer in der Applikation selbst gesetzt werden sollen.
Danke. Siehe meinen CURL-output.
Quote from: Patrick M. Hausen on June 24, 2024, 12:20:17 PM
Halte ich für Quatsch:
$ curl -v https://**********/.well-known/carddav
* Host **********:443 was resolved.
* [HTTP/2] [1] OPENED stream for https://**********/.well-known/carddav
< HTTP/2 301
< alt-svc: h3=":443"; ma=2592000
< content-type: text/html
< date: Mon, 24 Jun 2024 10:17:49 GMT
< location: http://**********/remote.php/dav/
< referrer-policy: no-referrer
< server: Caddy
< server: nginx
< strict-transport-security: max-age=15768000; includeSubDomains; preload
< x-content-type-options: nosniff
< x-frame-options: SAMEORIGIN
< x-permitted-cross-domain-policies: none
< x-robots-tag: noindex, nofollow
< x-xss-protection: 1; mode=block
< content-length: 162
<
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Connection #0 to host ********** left intact
Ich hab's mir ja nicht aus dem Finger gesaugt. ^^ Wenn das offiziell so dokumentiert ist, gehe ich auch davon aus das die schon wissen warum sie das schreiben.
Mein Curl sieht ähnlich aus wie deiner. Keine Fehler. Und das ist auch das was mich stutzig macht. Den aufruf mache ich über den weg von innen. Wenn ich aber über den Browser navigiere sieht das wieder anders aus.
curl -v https://ncloud.example.com/.well-known/carddav
* Host ncloud.example.com:443 was resolved.
* IPv6: (none)
* IPv4: 192.168.1.1
* Trying 192.168.1.1:443...
* Connected to ncloud.example.com (192.168.1.1) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / x25519 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
* subject: CN=*.example.com
* start date: Jun 21 13:40:44 2024 GMT
* expire date: Sep 19 13:40:43 2024 GMT
* subjectAltName: host "ncloud.example.com" matched cert's "*.example.com"
* issuer: C=US; O=Let's Encrypt; CN=E5
* SSL certificate verify ok.
* Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
* Certificate level 1: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using sha256WithRSAEncryption
* Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://ncloud.example.com/.well-known/carddav
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: ncloud.example.com]
* [HTTP/2] [1] [:path: /.well-known/carddav]
* [HTTP/2] [1] [user-agent: curl/8.8.0]
* [HTTP/2] [1] [accept: */*]
> GET /.well-known/carddav HTTP/2
> Host: ncloud.example.com
> User-Agent: curl/8.8.0
> Accept: */*
>
* Request completely sent off
< HTTP/2 301
< alt-svc: h3=":443"; ma=2592000
< content-type: text/html; charset=iso-8859-1
< date: Mon, 24 Jun 2024 11:08:10 GMT
< location: http://ncloud.example.com/remote.php/dav/
< referrer-policy: no-referrer
< server: Caddy
< server: Apache/2.4.59 (Debian)
< strict-transport-security: max-age=15768000; includeSubDomains; preload
< x-content-type-options: nosniff
< x-frame-options: SAMEORIGIN
< x-permitted-cross-domain-policies: none
< x-robots-tag: noindex, nofollow
< x-xss-protection: 1; mode=block
< content-length: 335
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://ncloud.example.com/remote.php/dav/">here</a>.</p>
<hr>
<address>Apache/2.4.59 (Debian) Server at ncloud.example.com Port 80</address>
</body></html>
* Connection #0 to host ncloud.example.com left intact
Ich habe nochmal ein wenig verglichen und frage mich, ob das ein Fehler seitens Caddy, oder ein fehler meinerseits ist.
Wenn ich die Access Liste entferne, den HSTS Header über "header_down" nachreiche und wieder von außen auf Nextcloud zugreife, erhalte ich keine Warnmeldung.
Alle Header werden Ordnungsgemäß angezeigt. die .htaccess Warnmeldung verschwindet und ich habe keine Fehler mehr.
Nur wenn ich die Access Liste wieder rein nehme erhalte ich wieder massig Fehler und warnings über den Browser angezeigt.
@Patrick
Kannst du testen ob es bei dir auch passiert, wenn eine Access List die Nextcloud einschränkt, dass es die Header Probleme gibt?
Meine Nextclouds sind leider in der Cloud (lol) und sind in einem Plesk. Kann es grade nicht richtig testen.
Von innen, ohne Access List, IP-Adresse ist aber natürlich die externe IP der OPNsense:
< HTTP/2 301
< alt-svc: h3=":443"; ma=2592000
< content-type: text/html
< date: Mon, 24 Jun 2024 19:04:57 GMT
< location: http://*********/remote.php/dav/
< referrer-policy: no-referrer
< server: Caddy
< server: nginx
< strict-transport-security: max-age=15768000; includeSubDomains; preload
< x-content-type-options: nosniff
< x-frame-options: SAMEORIGIN
< x-permitted-cross-domain-policies: none
< x-robots-tag: noindex, nofollow
< x-xss-protection: 1; mode=block
< content-length: 162
Dasselbe mit Access List:
< HTTP/2 301
< alt-svc: h3=":443"; ma=2592000
< content-type: text/html
< date: Mon, 24 Jun 2024 19:07:41 GMT
< location: http://*********/remote.php/dav/
< referrer-policy: no-referrer
< server: Caddy
< server: nginx
< strict-transport-security: max-age=15768000; includeSubDomains; preload
< x-content-type-options: nosniff
< x-frame-options: SAMEORIGIN
< x-permitted-cross-domain-policies: none
< x-robots-tag: noindex, nofollow
< x-xss-protection: 1; mode=block
< content-length: 162
Also: same same. Ich habe auch keine header_down Konfiguration oder sonst etwas. Alle Header und die Redirects für die Service Discovery ist im Nginx der Nextcloud konfiguriert, wie es m.E. sein sollte. Die Caddy Config ist die einfachst mögliche, Domain, Handler, aus.
Einziger möglicher Unterschied: ich verwende zwischen Caddy und den Backends nach Möglichkeit kein HTTPS sondern Plain HTTP. In einem 100% geswitchten VLAN basierten Netz soll mir mal einer zeigen, wie er von einer gehackten Maschine den Traffic zwischen Caddy und einer anderen Maschine abgreifen will :)
Und ich muss mich im Backend nicht mit Zertifikaten rumärgern. Die sind ja alle in isolierten Netzen. Und dann hab ich zum Teil Java-Anwendungen und SSL mit Java ist so eklig ... ne ne ne, das darf alles der Reverse Proxy machen.
Danke fürs testen.
Im reverse proxy hab ich kein TLS aktiviert gesehen, also fällt der unterschied weg.
Dann ist was in der Nextcloud falsch konfiguriert.
Aber ich denke jetzt sind wir hier am Ende angelangt. Viel helfen kann ich nicht mehr da es ja grundsätzlich funktioniert wenn die Infrastruktur zu stimmen scheint.
Vielen Dank nochmal für das Testen und die bisherige Hilfe.
Die Verschlüsselung kann vielleicht ein Grund sein für das Problem. Auf der anderen Seite wollte ich lediglich meine Weiche von außen nach innen verlegen, ohne großartig was umzustellen, bis auf eben die FW. Meine Nextcloud war im Grunde schon gut voreingestellt. Also ich musste wenig bis gar nichts konfigurieren. Es funktioniert ja an sich. Ich erhalte nur eben die Fehlermeldungen. Ich muss das ganze nochmal ein bisschen im Detail analysieren. Aber fraglich ob ich hier im Forum weitere Hilfe zu dem Thema erhalte, weil vermutlich sonst niemand so eine konfiguration auf die Beine gestellt hat.
Ich persönlich hasse Zertifikats Warnungen und "Ausnahmen". Es ist einfach ein nice to have, eine funktionierende Verschlüsselung innerhalb des eigenen Netzes zu haben. Gibt mir halt ein gutes Gefühl nach all den Jahren der Unsicherheit. ;D
Sorry für den Spam hier, aber erst jetzt sehe ich diesen Error im Caddy.
"error","ts":"2024-06-25T06:53:33Z","logger":"http.log.access.37fc6c8b-42c2-41e0-baba-c38516660295","msg":"handled request","request":{"remote_ip":"100.65.0.10","remote_port":"47471","client_ip":"100.65.0.10","proto":"HTTP/1.1","method":"PROPFIND","host":"ncloud.example.com","uri":"/remote.php/dav/files/odin/","headers":{"Cookie":["REDACTED"],"Content-Length":["107"],"Content-Type":["text/xml; charset=UTF-8"],"Depth":["0"],"Authorization":["REDACTED"],"User-Agent":["Mozilla/5.0 (Android) Nextcloud-android/3.29.0"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"","server_name":"ncloud.example.com"}},"bytes_read":0,"user_id":"","duration":3.001101121,"size":0,"status":502,"resp_headers":{"Server":["Caddy"],"Alt-Svc":["h3=\":443\"; ma=2592000"]}}
"status":502,"resp_headers" = Bad Gateway
Ich denke damit kann ich erstmal arbeiten.