Lets Encrypt http code 400

[guest24551]

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!

[JeGr]

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. :)

[guest24551]

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.

[lfirewall1243]

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?

[guest24551]

Zwischen internet und opnsense? Nur die fritzbox.

[JeGr]

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. :)

[guest24551]

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?

[JeGr]

> - 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?

[guest24551]

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:

Code Select Expand

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.

Code Select Expand

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.

[micneu]

mal eine ganz doofe frage, was hat deine firewall einbrüche mit dem titel deiner anfrage zu tun ("Lets Encrypt http code 400")?

[guest24551]

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 ...

[micneu]

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.

[bit-project-de]

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.