Messages

Hallo zusammen,

gerade habe ich die Ursache gefunden: Es war das Intrusion Detection. Pattern 2009954 aus emerging-deleted.rules "ET DELETED Tilde in URI after file, potential source disclosure vulnerability" hat zugeschlagen und musst disabled werden.

Dank an alle, die sich gedanklich schon mit meiner Frage beschäftigt haben.

Grüße
Martin

Hallo zusammen,

ich bin gerade etwas ratlos, wo ich noch länger suchen soll, und hoffe, hier im Forum kann mir jemand den weiterführenden Hinweis geben.

Seit langem (> 1 Jahr) benutze ich den ACME Client, um Zertifikate für mehrere HTTP-Server im nginx von Let's Encrypt ausstellen und verlängern zu lassen. Das funktionierte bis zuletzt Anfang März problemlos. Da müsste die Version 4.8 vom ACME Client installiert gewesen sein. Das nächste Zertifikat sollte am 24.03. verlängert werden. Zu dem Zeitpunkt war die Version 4.9 installiert. Leider lässt sich das Zertifikat nicht mehr via HTTP validieren. Im Logfile finde ich:

Fetching http://<host>.<domain>.de/.well-known/acme-challenge/<xyz>: Timeout after connect (your server may be slow or overloaded)","status": 400

Mit tcpdump auf dem WAN-Interface der opnsense sehe ich auf Port 80 den eingehenden Request:


outbound1.letsencrypt.org.56189 > <IP WAN-Interface>.http: Flags [P.], cksum 0x3218 (correct), seq 1:282, ack 1, win 502, options [nop,nop,TS val 1111388247 ecr 913072126], length 281: HTTP, length: 281
    GET /.well-known/acme-challenge/<xyz> HTTP/1.1
    Host: <host>.<domain>.de
    User-Agent: Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)
    Accept: /
    Accept-Encoding: gzip
    Connection: close

unmittelbar gefolgt von der Antwort:

<IP WAN-Interface>.http > outbound1.letsencrypt.org.56189: Flags [P.], cksum 0xeea1 (correct), seq 1:298, ack 282, win 511, options [nop,nop,TS val 913072285 ecr 1111388247], length 297: HTTP, length: 297
        HTTP/1.1 200 OK
        Content-Type: application/octet-stream
        Content-Length: 87
        Cache-Control: max-age=36000
        Accept-Ranges: bytes
        Connection: close
        Date: Thu, 27 Mar 2025 12:47:31 GMT
        Server: lighttpd/ACME

        <Inhalt der Challenge-Datei>

Diese Antwort scheint aber den Server von Let's Encrypt nicht zu erreichen.

Rufe ich die selbe URL von einem Rechner zwischen dem WAN-Interface und meinem Router auf, so bekomme ich den <Inhalt der Challenge-Datei> angezeigt.
Rufe ich die selbe URL aus dem Internet auf, so bekomme ich auch einen Timeout.

Hier deutet alles auf meinen Router.

Also habe ich einen HTTP-Server im nginx neben HTTPS zusätzlich auf HTTP gestellt und mit einer Firewallregel auf dem WAN-Interface Port 80 zur Firewall erlaubt. Rufe ich die entsprechende URL aus dem Internet auf, so sehe ich mit tcpdump Request und Response und bekomme per HTTP den Redirect auf HTTPS zurück. Der nginx antwortet also auf Port 80 und diese Antwort geht auch über den Router. Also scheint dieser ausgehend Port 80 durchzulassen.

Ich verstehe nun nur nicht, warum auf Port 80 die Antwort vom ACME/lighttpd nicht ankommt.

Und hier gehen mir die Ideen aus.

Fällt jemandem von Euch was dazu ein, was ich analysieren könnte? Ich wäre Euch super dankbar!

Viele Grüße
Martin