OPNsense Forum
International Forums => German - Deutsch => Topic started by: guest24551 on June 29, 2020, 09:10:10 pm
-
Hallo an alle,
ich hoffe heute ist jemand guter Laune und kann mir vielleicht helfen.
Ich versuche seit gestern mir ein Zertifikat über Acme bereitstellen zu lassen. Allerdings bekomme ich ständig den example.com:Verify error:Fetching http://example.com/.well-known/acme-challenge/hlnnJ0Kkupptfisydh32i9MymLsGgR_CPxz3trctzbI: Timeout during connect (likely firewall problem)
Ich bekomme auch beim Domain check einen Timeout. Ich verwende keinen HAProxy, da ich im Moment nur Opnsense im Betrieb habe und der Aufwand IMO etwas größer ist, als bei den meisten Anleitungen.
Ich habe meine Domain bei STRATO reserviert. A Record und DynDNS sind aktiv. Die Weiterleitung funktioniert auch.
Leider erhalte ich permanent diesen 400er Code. Ich habe Opnsense vor kurzem neu aufgesetzt und will weg von den selbst signierten certs ... Ich teste also auf factory default.
Wenn ich meine Domain checke, erhalte ich folgende Meldung:
Fatal: Check of /.well-known/acme-challenge/random-filename has a timeout. Creating a Letsencrypt certificate via http-01 challenge can't work. You need a running webserver (http) and an open port 80. If it's a home server + ipv4, perhaps a correct port forwarding port 80 extern ⇒ working port intern is required. Port 80 / http can redirect to another domain port 80 or port 443, but not other ports. If it's a home server, perhaps your ISP blocks port 80. Then you may use the dns-01 challenge. Trouble creating a certificate? Use https://community.letsencrypt.org/ to ask.
Der Port von Lets encrypt ist 35800. Normalerweise sollte das Plugin auch den Port automatisch umleiten/freischalten, oder irre ich mich?
-
Die Lösung steht doch bereits in deiner Beschreibung...
Er kann domain.xyz/.well-known/... Nicht erreichen...
Hast du eine entsprechende Weiterleitung eingerichtet damit man von extern via Port 80 auf dein Letsencrypt Port kommt?
Wo steht, dass dies automatisch gemacht wird? Es gibt die Möglichkeit (!) automatisch haproxy zu konfigurieren lassen...
Aber mit Port Weiterleitung ist mir das neu
Gesendet von meinem LG-H815 mit Tapatalk
-
In den meisten Anleitungen wird nirgends erwähnt, dass man noch zusätzliche Ports freischalten muss, damit HTTP-01 funzt. Also gehe ich von vorn herein davon aus, dass das Plugin automatisch alles richtig einstellt. Hat bei anderen (siehe youtube) scheinbar auch geklappt.
Nichts desto trotz, habe ich vorhin mal port 80 auf wan über tcp + ipv4 geöffnet. Ich habe das 1x als rule und 1x als nat portforwarding getestet. Beides hat nicht geklappt. Letsencrypt empfiehlt zwar selbst port 80 offen zu halten, aber warum das trotzdem nicht funktioniert, ist mir ein rätsel.
Meine rule:
allow
in on wan
tcp - ipv4
from *
port 80
to this firewall
port 35800
Man muss doch die Oberfläche ohne solchen Aufwand auch irgendwie über letsencrypt zertifizieren lassen können? So wie ich das den meisten Dokus entnommen habe, braucht man nur den account, die überprüfungsmethode und das zertifikat. natürlich sollte man noch die domain besitzen ...
-
Und warum 35800? Hast du Acme so konfiguriert, dass er auf Port 35800 hören soll? Da du nichts zu deiner Konfiguration wie Screens oder sonstwas postest, ist das hier stochern im Nebel wenn du uns keine Anhaltspunkte lieferst :)
-
Kannst du mal bitte deine Konfiguration als Bilder anhängen, so kann man sehen wo Fehler sind.
Ich habe es bei mir am laufen, habe es vor ca. 1,5 Jahren nach einer Anleitung aus dem netz gemacht.
Gesendet von iPad mit Tapatalk Pro
-
Komisch das ich keine Benachrichtigung über neue Antworten erhalten habe ....
Bzgl. des Ports habe ich mich vertippt: 43580 ist der richtige
Ich habe die letzten Tage versucht herauszufinden, ob man das ganze über DNS-01 machen kann, aber Strato hat scheinbar keine API für dafür. Bzw. es haben scheinbar andere geschafft, aber keiner verrät wo er was und wie eingestellt hat.
TXT-Record habe ich bei meiner Subdomain hinterlegt. Ich habe da einen Text als eine Art Passwort hinterlegt. (vermute mal das das so gemacht wird) Allerdings weiß ich nicht welchen FQDN ich bei der Überprüfung mit nsupdate angeben soll, oder was da in das Textfeld kommt.
[Wed Jul 1 21:08:12 CEST 2020] d_api='/usr/local/share/examples/acme.sh/dnsapi/dns_nsupdate.sh'
[Wed Jul 1 21:08:12 CEST 2020] Found domain api file: /usr/local/share/examples/acme.sh/dnsapi/dns_nsupdate.sh
[Wed Jul 1 21:08:12 CEST 2020] Adding txt value: W9jKa184fu9XN_UMctUYR5wiOqF41bJEvheq6j45U2Q for domain: _acme-challenge.sub.example.com
[Wed Jul 1 21:08:12 CEST 2020] adding _acme-challenge.sub.example.com. 60 in txt "W9jKa184fu9XN_UMctUYR5wiOqF41bJEvheq6j45U2Q"
[Wed Jul 1 21:08:12 CEST 2020] error updating domain
[Wed Jul 1 21:08:12 CEST 2020] Error add txt for domain:_acme-challenge.sub.example.com
[Wed Jul 1 21:08:12 CEST 2020] _on_issue_err
[Wed Jul 1 21:08:12 CEST 2020] Please check log file for more details: /var/log/acme.sh.log
[Wed Jul 1 21:08:12 CEST 2020] url='https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/70781975/jfXZnw'
[Wed Jul 1 21:08:12 CEST 2020] payload='{}'
[Wed Jul 1 21:08:12 CEST 2020] POST
[Wed Jul 1 21:08:12 CEST 2020] _post_url='https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/70781975/jfXZnw'
[Wed Jul 1 21:08:12 CEST 2020] _CURL='curl -L --silent --dump-header /var/etc/acme-client/home/http.header --trace-ascii /tmp/tmp.YMDhxuuE -g '
Da momentan mein Firejail Firefox probleme mit File up und download hat, tippe ich mal schnell meine einstellungen runter.
Was genau im Bezug auf die Config wollt ihr sehen? Ich habe mich an einem Youtube Video orientiert. https://www.youtube.com/watch?v=gVOEdt-BHDY
Meine Settings:
-Plugin aktiviert
-Auto. Erneuerung.
-Port 43580
-Automation Timeout 600
Konten:
-Aktiv
-namexyz
-meine mail
Überprüfungsmethode:
-name opnsense
-Herausforderung (HTTP-01 und DNS-01 getestet)
Für DNS-01:
Dienst: nsupdate
sleep 120
FQDN habe ich mal zum test einfach meine Subdomain eingegeben
Gemeinsamer Schlüssel wäre vermutlich die value aus dem TXT record?
Für HTTP-01:
HTTP-Dienst: Opnsense Webdienst
Interface: WAN
"automatische IP-Erkennung" aktiviert
Zertifikat:
- Active
- Common Name: sub.example.com
- Konto "xyz"
- Überprüfungsmethode "opnsense"
- Auto renew
- Intervall 60
- Key length 4096 Bit
- DNS Alias Mode (Not using DNS alias mode) Habe auch automatic ausprobiert.
-
ok, erster unterschied, ich setze cloudflare als dns diens bei mir ein, so kann ich meinen eigenen dyndns-dienst betrtreiben und die api wird von der sense unterstützt.
-
Eigentlich wollte ich einen Domänenumzug vermeiden... :/
Scheinbar muss ich bei Strato etwas druck machen, wenn hier niemand eine passable Lösung hat. :'(
-
Warum Domänenumzug?
Musst nur den entsprechenden NS Eintrag von cloudflare angeben...
Habe ich selbst ebenso im Einsatz...
Gesendet von meinem LG-H815 mit Tapatalk
-
Heise hatte dazu mal einen Artikel in der ct.
Gesendet von iPad mit Tapatalk Pro
-
Warum Domänenumzug?
Musst nur den entsprechenden NS Eintrag von cloudflare angeben...
Habe ich selbst ebenso im Einsatz...
Gesendet von meinem LG-H815 mit Tapatalk
Wenn das so einfach ist, gucke ich mir das mal an. Danke für den Hinweis!
Das DNS Thema und seine Möglichkeiten sind noch Neuland für mich. ^^
-
Heise hatte dazu mal einen Artikel in der ct.
Gesendet von iPad mit Tapatalk Pro
Meinst du diesen Artikel?
https://www.heise.de/select/ct/2018/4/1518744647738615 (https://www.heise.de/select/ct/2018/4/1518744647738615)
-
Melde dich einfach mal bei cloudflare an und gib deine Domäne ein.. Was du dann machen musst, steht dort....
PS. Bei mir hat es sogar mehr als 24 Stunden gedauert...
Gesendet von meinem LG-H815 mit Tapatalk
-
Mache ich, danke nochmal. :)
-
> Mache ich, danke nochmal. :)
Zur kurzen Erklärung: Du musst nicht die Domain umziehen, du musst lediglich die Möglichkeit haben (hat soweit ich mich erinnere Strato), die DNS Server der Domain zu ändern. Sobald man sich bei Cloudflare o.ä. registriert bekommt man 2 CF DNS Server zugewiesen. Diese trägt man als neue DNS Server für die Domain ein und schon liegen alle DNS Einstellungen danach bei Cloudflare. Dazu sollte man allerdings vorher wissen was man übernehmen muss (Mail Einträge etc. sonst klappt plötzlich kein Mail mehr :))
-
Das ist sehr gut zu wissen. So einfach wird sowas nirgends erklärt und wenn doch, dann braucht man glück beim googlen. :D
Momentan kämpfe ich mit Einbrüchen bei Opnsense https://forum.opnsense.org/index.php?topic=17994.0 , weswegen ich vielleicht erst in ein paar Tagen so richtig testen kann ob das ganze auch so funktioniert.
Aber danke nochmal für die kurze Erläuterung!
-
ich verstehe zwar den Post bzw. das Topic bzgl. DNS Attacke von extern nicht (warum sollte man seinen internen Resolver nach außen öffnen? Macht keinen Sinn), aber anderes Thema. :)
-
Nix nach außen öffnen. Geht darum wie man den angriffsvektor dns udp 53 richtig absichert, so dass das nicht mehr vorkommt. Meine rules haben bisher nicht funktioniert.
-
In den meisten Anleitungen wird nirgends erwähnt, dass man noch zusätzliche Ports freischalten muss, damit HTTP-01 funzt. Also gehe ich von vorn herein davon aus, dass das Plugin automatisch alles richtig einstellt. Hat bei anderen (siehe youtube) scheinbar auch geklappt.
Nichts desto trotz, habe ich vorhin mal port 80 auf wan über tcp + ipv4 geöffnet. Ich habe das 1x als rule und 1x als nat portforwarding getestet. Beides hat nicht geklappt. Letsencrypt empfiehlt zwar selbst port 80 offen zu halten, aber warum das trotzdem nicht funktioniert, ist mir ein rätsel.
Meine rule:
allow
in on wan
tcp - ipv4
from *
port 80
to this firewall
port 35800
Man muss doch die Oberfläche ohne solchen Aufwand auch irgendwie über letsencrypt zertifizieren lassen können? So wie ich das den meisten Dokus entnommen habe, braucht man nur den account, die überprüfungsmethode und das zertifikat. natürlich sollte man noch die domain besitzen ...
Hängt vor deiner OPNsense noch ein Gerät?
-
Zwischen internet und opnsense? Nur die fritzbox.
-
Wenn zwischen Sense und Web nur noch die FB ist und auch DNS nicht nach außen geöffnet ist, was für einen Angriffsvektor hat dann dein lokaler DNS? Verstehe ich gerade nicht, aber egal - vermutlich wieder eines der Kommunikations- oder Verständnisprobleme was DNS wo tut oder nicht tut. Hoffe du kannst den ACME dann ordentlich testen. :)
-
Was heißt DNS nach außen geöffnet? Ich habe DNS nicht explizit mit einer Rule nach außen erlaubt.
Ich habe folgendes getestet:
- Rules auf eingerichtet:
-- Erlaube UDP DNS Verbindung (IN/OUT TCP/UDP/ auf WAN zu OpenDNS Nameservern)
-- Blockiere alle anderen Anfragen (IN/OUT TCP/UDP Port DNS)
- WAN Kabel wieder rein. (Hat nicht lange gedauert bis die Firewall wieder mit den Angriffsservern kommuniziert hat)
-- Im Maltrail wurde ein Angriff über "IPv4" protokolliert
-- Anschließend wurde mein FW Protokoll mit folgenden Logs zugespammt:
Connection WAN 192.168.2.65:<Port >1024> zu xyz.server:53 Rule: Let anything out the Firewall itself)
Das heißt die Firewall erlaubt es von sich aus meine Rule für DNS zu umgehen.
Habe ich hier verständnisprobleme, oder muss ich bei der DNS Config mehr beachten?
-
> - Rules auf eingerichtet:
Ich glaube da fehlt ein Wort? :)
> Erlaube UDP DNS Verbindung (IN/OUT TCP/UDP/ auf WAN zu OpenDNS Nameservern)
Gibts da nen Screenshot? Das klingt falsch und sinnfrei auf WAN ein INcoming 53 für OpenDNS. Macht keinen Sinn für mich?
> -- Blockiere alle anderen Anfragen (IN/OUT TCP/UDP Port DNS)
Wo? Auf WAN? Da sollte mit default block any eh schon alles zu sein.
> Connection WAN 192.168.2.65:<Port >1024> zu xyz.server:53 Rule: Let anything out the Firewall itself)
Das ist aber ne interne IP. Welche? Wer hat denn .2.65? Auf dem WAN eingehend kann die nicht sein, da es "let anything von firewall out" ist, muss es die Firewall selbst sein? Hat deine Firewall .2.65? Warum soll das dann was "böses" sein, wenn die Firewall Abfragen per DNS schickt (schließlich sendet sie AN 53, nicht VON 53, fragt also an und gibt keine Antwort).
Vielleicht hab ich was überlesen, dann Sorry, aber so machts keinen Sinn für mich bzw. klingt nach sinnfreiem Alarm wo keiner ist?
-
Ich tu mir mit Firewall Regeln noch relativ schwer. Z.B. wann man einen Invert einsetzen muss..
Zum besseren Verständnis bzgl. IP
Internet
:
: Cable - Vodafone Germany
:
.-----+-----.
| Gateway | Fritz-Box Cable Router
'-----+-----'
|
WAN | 192.168.2.65 Opnsense DHCP
|
.-----+------.
| OPNsense
'-----+------'
|
LAN | 192.168.1.1/24
|
.-----+------.
| LAN-Client | Debian
'-----+------'
Das Problem ist folgendes:
Meine Firewall wird permanent von irgendwo aus über Port 53 gescannt und dann angegriffen.
Siehe Log Suricata:
2020-07-13T14:46:01.939317+0200
2020-07-13T14:46:01.939317+0200
2831048 blocked WAN 54.235.136.99 443 192.168.2.65 7439 ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org)
Es dauert nicht lange, dann wird die Schwachstelle gefunden. Suricata hilft mir nicht, genauso wenig wie die Default Firewall rules. Es dauert immer ein paar Tage nach der Einrichtung, aber irgendwann wird dann per UDP ein haufen cryptischer Pakete von den Angreifern übertragen, die Suricata irgendwie infizieren.
2020-07-08T23:10:00 suricata[38610]: [100658] <Notice> -- all 3 packet processing threads, 4 management threads initialized, engine started.
2020-07-08T23:06:58 suricata[38610]: [100658] <Error> -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "drop smb any any -> $DC_SERVERS 445 (msg: "ATTACK AD [PTsecurity] Possible MS-RPRN abuse. Hash or Ticket theft"; flow: to_server, established, no_stream; content:"SMB"; offset: 5; depth: 3; content: "|05 00 00|"; distance: 0; content: "|41 00|"; distance: 19; within: 2; content: "|00 01 00 00|"; distance: 36; within: 4; content: "|5C 00 5C 00|"; fast_pattern; distance: 0; flowbits: isset, DCERPC.BIND.SPOOLSS; reference: url, posts.specterops.io/not-a-security-boundary-breaking-forest-trusts-cd125829518d; reference: url, github.com/ptresearch/AttackDetection; metadata: Open Ptsecurity.com ruleset; classtype: attempted-recon; sid: 10004153; rev: 1;)" from file /usr/local/etc/suricata/opnsense.rules/pt.research.rules at line 273
2020-07-08T23:06:58 suricata[38610]: [100658] <Error> -- [ERRCODE: SC_ERR_UNDEFINED_VAR(101)] - Variable "DC_SERVERS" is not defined in configuration file
2020-07-08T23:06:58 suricata[38610]: [100658] <Error> -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "drop tcp !$DC_SERVERS any -> $DC_SERVERS 389 (msg: "ATTACK [PTsecurity] DCShadow: Fake DC Creation"; flow: established, to_server; content: "|68 84 00|"; content: "CN="; distance: 5; within: 3; content: "CN=Servers,CN="; distance: 0; content: ",CN=Sites,CN=Configuration,DC="; distance: 0; content: "objectClass"; distance: 0; content: "server"; distance: 0; reference: url, blog.alsid.eu/dcshadow-explained-4510f52fc19d; classtype: attempted-admin; reference: url, github.com/ptresearch/AttackDetection; metadata: Open Ptsecurity.com ruleset; sid: 10002559; rev: 2; )" from file /usr/local/etc/suricata/opnsense.rules/pt.research.rules at line 215
2020-07-08T23:06:58 suricata[38610]: [100658] <Error> -- [ERRCODE: SC_ERR_UNDEFINED_VAR(101)] - Variable "DC_SERVERS" is not defined in configuration file
2020-07-08T23:06:58 suricata[38610]: [100658] <Error> -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "drop tcp !$DC_SERVERS any -> $DC_SERVERS [1024:] (msg: "ATTACK AD [PTsecurity] DCShadow Replication Attempt - DRSUAPI_REPLICA_ADD from non-DC"; flow: established, to_server, no_stream; content: "|05 00 00 03|"; depth: 4; content: "|05 00|"; distance: 18; within: 2; flowbits: isset, RPC.Bind.DRSUAPI; reference: url, blog.alsid.eu/dcshadow-explained-4510f52fc19d; classtype: attempted-admin; reference: url, github.com/ptresearch/AttackDetection; metadata: Open Ptsecurity.com ruleset; sid: 10002558; rev: 1; )" from file /usr/local/etc/suricata/opnsense.rules/pt.research.rules at line 213
2020-07-08T23:06:58 suricata[38610]: [100658] <Error> -- [ERRCODE: SC_ERR_UNDEFINED_VAR(101)] - Variable "DC_SERVERS" is not defined in configuration file
2020-07-08T23:06:58 suricata[38610]: [100658] <Error> -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "alert tcp !$DC_SERVERS any -> $DC_SERVERS [1024:] (msg: "ATTACK AD [PTsecurity] DCShadow Replication Attempt"; flow: established, to_server; content: "|05 00 0B|"; depth: 3; content: "|35 42 51 E3 06 4B D1 11 AB 04 00 C0 4F C2 DC D2|"; distance: 0; flowbits: set, RPC.Bind.DRSUAPI; flowbits: noalert; reference: url, blog.alsid.eu/dcshadow-explained-4510f52fc19d; classtype: attempted-admin; reference: url, github.com/ptresearch/AttackDetection; metadata: Open Ptsecurity.com ruleset; sid: 10002557; rev: 2; )" from file /usr/local/etc/suricata/opnsense.rules/pt.research.rules at line 211
2020-07-08T23:06:58 suricata[38610]: [100658] <Error> -- [ERRCODE: SC_ERR_UNDEFINED_VAR(101)] - Variable "DC_SERVERS" is not defined in configuration file
2020-07-08T23:06:58 suricata[38610]: [100658] <Error> -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "drop tcp $HOME_NET any -> $DC_SERVERS 88 (msg: "ATTACK [PTsecurity] Overpass the hash. Encryption downgrade activity to ARCFOUR-HMAC-MD5"; flow: no_stream, established, to_server; content: "|A1 03 02 01 05 A2 03 02 01 0A|"; offset: 12; depth: 10; content: "|A1 03 02 01 02|"; distance: 5; within: 6; content: "|A0 03 02 01 17|"; distance: 6; within: 6; content: "krbtgt"; distance: 0; xbits: set, Krb5.AsReq, track ip_src, expire: 10; classtype: attempted-user; reference: url, github.com/ptresearch/AttackDetection; metadata: Open Ptsecurity.com ruleset; sid: 10002228; rev: 1; )" from file /usr/local/etc/suricata/opnsense.rules/pt.research.rules at line 171
2020-07-08T23:06:58 suricata[38610]: [100658] <Error> -- [ERRCODE: SC_ERR_UNDEFINED_VAR(101)] - Variable "DC_SERVERS" is not defined in configuration file
2020-07-08T23:05:51 suricata: [100658] <Warning> -- [ERRCODE: SC_WARN_DEFAULT_WILL_CHANGE(317)] - in 5.0 the default for decoder event stats will go from 'decoder.<proto>.<event>' to 'decoder.event.<proto>.<event>'. See ticket #2225. To suppress this message, set stats.decoder-events-prefix in the yaml.
2020-07-08T23:05:51 suricata: [100526] <Notice> -- This is Suricata version 4.1.8 RELEASE
2020-07-08T23:05:51 suricata[83153]: [100201] <Notice> -- Stats for 'igb0+': pkts: 91822, drop: 5207 (5.67%), invalid chksum: 0
2020-07-08T23:05:51 suricata[83153]: [100201] <Notice> -- Stats for 'igb0': pkts: 142974, drop: 0 (0.00%), invalid chksum: 0
2020-07-08T23:05:50 suricata[83153]: [100201] <Notice> -- Signal Received. Stopping engine.
2020-07-08T22:56:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 54.225.66.103:443 -> 192.168.2.65:28014
2020-07-08T22:56:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 54.225.66.103:443 -> 192.168.2.65:44941
2020-07-08T22:46:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 174.129.214.20:443 -> 192.168.2.65:43728
2020-07-08T22:46:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 174.129.214.20:443 -> 192.168.2.65:51898
2020-07-08T22:36:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 23.21.213.140:443 -> 192.168.2.65:27449
2020-07-08T22:36:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 23.21.213.140:443 -> 192.168.2.65:29040
2020-07-08T22:26:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 184.73.165.106:443 -> 192.168.2.65:25054
2020-07-08T22:26:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 184.73.165.106:443 -> 192.168.2.65:55965
2020-07-08T22:16:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 174.129.214.20:443 -> 192.168.2.65:9766
2020-07-08T22:16:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 174.129.214.20:443 -> 192.168.2.65:63278
2020-07-08T22:06:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 54.225.66.103:443 -> 192.168.2.65:24312
2020-07-08T22:06:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 54.225.66.103:443 -> 192.168.2.65:8201
2020-07-08T21:56:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 107.22.251.25:443 -> 192.168.2.65:37805
2020-07-08T21:56:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 107.22.251.25:443 -> 192.168.2.65:10832
2020-07-08T21:46:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 107.22.188.116:443 -> 192.168.2.65:42865
2020-07-08T21:46:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 107.22.188.116:443 -> 192.168.2.65:51207
2020-07-08T21:36:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 107.22.188.116:443 -> 192.168.2.65:13562
2020-07-08T21:36:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 107.22.188.116:443 -> 192.168.2.65:33944
2020-07-08T21:26:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 174.129.255.253:443 -> 192.168.2.65:62216
2020-07-08T21:26:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 174.129.255.253:443 -> 192.168.2.65:57836
2020-07-08T21:16:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 54.221.234.156:443 -> 192.168.2.65:13134
2020-07-08T21:16:01 suricata[83153]: [Drop] [1:2831048:2] ETPRO POLICY Observed SSL Cert (IP Lookup - ipify .org) [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 54.221.234.156:443 -> 192.168.2.65:3524
Mein Problem ist, dass ich nicht weiß wie ich das verhindern kann. Niemand weiß so richtig mir zu helfen, denn scheinbar versagen hier die Sicherheitsmechaniken von Opnsense.
Ich möchte Anfragen über OpenDNS filtern, aber alles was von außen kommt und nicht von OpenDNS ist, soll geblockt werden. Das ist die Theorie, aber ob die Praxis auch so funktioniert, weiß ich eben nicht, denn meine Rules ziehen anscheinend nicht.
Wenn meine Rules so Sinnfrei sind, würde ich gerne erfahren, wie ich sie sonst gestalten müsste, bzw. wo ich Nachfragen müsste, wenn es um solche Themen geht... Scheinbar weiß mir bei Intrusion Detection auch niemand zu helfen.
-
mal eine ganz doofe frage, was hat deine firewall einbrüche mit dem titel deiner anfrage zu tun ("Lets Encrypt http code 400")?
-
Ich weiß das es etwas off topic ist, aber hier antwortet mir wenigstens jemand. Das eigentliche Topic hatte ich bereits verlinkt, aber da meldet sich keiner ...
-
ich finde das keine schöne art. bitte trenne doch die themen.
und wenn dir keiner antwortet, na dann hat keiner was zu sagen. du kannst nicht erwarten in einem forum wo die leute ihre private freizeit investieren, das du sofort eine antwort bekommst.
das ist meine persönliche meinung. für mich ist das thema jetzt beendet.
viel spaß noch im forum, und denke dran, wir helfen uns hier gegenseitig.
-
Auch wenn es schon ein alter Post ist. Das Problem ist, dass Traffic, der von einem privaten Netz hinter der Firewall kommt (also der Self-Check des Cert-Managers bei HTTP-Challenge), der kommt über das private Interface der Firewall rein und nicht über das WAN Interface, auf welchem der LoadBalancer läuft. Dementsprechend versandet der Traffic auf der Firewall und findet nicht den Weg zurück zum privaten Host auf dem Cert-Manager läuft. Daher failed der Self-Check. Die Fehlermeldungen des Cert-Managers sind dabei nicht hilfreich, da sie irreführend sind. Das Problem habe ich damals auf der PFSense mit einer Kombination aus NAT-Reflection und Port-Forwarding regeln gelöst. Auf OpnSense bin ich gerade auch etwas ratlos.