9
Komische Einträge im Log von HAProxy
Hallo,
ich habe hier einen Exchange Server der Hinter einem HAProxy als WAF im Internet steht.
Ich habe diese Einträge im Log gefunden, die ich mir nicht erklären kann.
"tarpit_403" ist mein Default Backend was als 404 fungiert.
Der HAProxy hat nur das Zertifikat für die benötigten Hostnamen.
Ein Aufruf mit https und der IP führt zu diesem Fehlercode: SSL_ERROR_UNRECOGNIZED_NAME_ALERT und diesem Log Eintrag "haproxy-main/1: SSL handshake failure (error:0A0000EA:SSL routines::callback failed)".
Alles korrekt.
Das heisst der Aufruf muss mit einem korrekten Hosteintrag erfolgt sein.
Sonst wäre er in einen SSL Fehler gelaufen.
Aber die URL "POST /EWS/Exchange.asmx HTTP/1.1" passt ja zu der ACL von HAProxy.
Warum verwendet er nicht das richtige Backend?
Ich habe diese Log-Einträge nur für "/EWS".
Alle andere Sortierungen funktionieren einwandfrei.
Hat hier Jemand einen Tipp für mich?
Hier die gekürzte Config
ich habe hier einen Exchange Server der Hinter einem HAProxy als WAF im Internet steht.
Ich habe diese Einträge im Log gefunden, die ich mir nicht erklären kann.
Feb 18 01:43:03 PublicProxyxxxxxxxxx haproxy[506211]: [Eine deutsche IP-Adresse ASN 15943]:38590 [18/Feb/2024:01:42:57.867] haproxy-main~ tarpit_403/<NOSRV> -1/6060/-1/-1/6006 403 2104 - - PR-- 4/4/0/0/0 0/0 "POST /EWS/Exchange.asmx HTTP/1.1" "tarpit_403" ist mein Default Backend was als 404 fungiert.
Der HAProxy hat nur das Zertifikat für die benötigten Hostnamen.
Ein Aufruf mit https und der IP führt zu diesem Fehlercode: SSL_ERROR_UNRECOGNIZED_NAME_ALERT und diesem Log Eintrag "haproxy-main/1: SSL handshake failure (error:0A0000EA:SSL routines::callback failed)".
Alles korrekt.
Das heisst der Aufruf muss mit einem korrekten Hosteintrag erfolgt sein.
Sonst wäre er in einen SSL Fehler gelaufen.
Aber die URL "POST /EWS/Exchange.asmx HTTP/1.1" passt ja zu der ACL von HAProxy.
Warum verwendet er nicht das richtige Backend?
Ich habe diese Log-Einträge nur für "/EWS".
Alle andere Sortierungen funktionieren einwandfrei.
Hat hier Jemand einen Tipp für mich?
Hier die gekürzte Config
frontend haproxy-main
mode http
no option httpclose
bind *:443 ssl crt /etc/haproxy/certs/ strict-sni
option forwardfor
....
acl exchange_ews path_beg -i /EWS
acl exchange_ews path_beg -i /ews
....
acl ACL_owa.xxxxx.com hdr(host) -i owa.xxxxx.com autodiscover.xxxxx.com
use_backend xxxxx_exchange1_exchange_ews if ACL_owa.xxxx.com exchange_ews
default_backend tarpit_403
backend tarpit_403
timeout tarpit 6s
errorfile 403 /etc/haproxy/403.html
http-request tarpit deny_status 403
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 11249789051
Url: https://administrator.de/forum/komische-eintraege-im-log-von-haproxy-11249789051.html
Ausgedruckt am: 29.03.2025 um 10:03 Uhr
9 Kommentare
Neuester Kommentar
Nabend.
Da ist noch eine Zeile (15) nicht ganz anonymisiert.
Das sieht für mich auch erst einmal sauber aus.
Aus Interesse:
Ist das ein Standalone HAProxy oder auf einer *Sense?
Gruß
Marc
Da ist noch eine Zeile (15) nicht ganz anonymisiert.
Das sieht für mich auch erst einmal sauber aus.
Aus Interesse:
Ist das ein Standalone HAProxy oder auf einer *Sense?
Gruß
Marc
Ohne haproxy im Detail zu kennen, aber HTTP und TLS sind ja halbwegs universell:
Wenn der Client per TLS-SNI den korrekten Namen im TLS-Handshake mitgibt, wird er im korrekten Frontend landen.
Wird dann aber ein falscher oder überhaupt kein "Host:"-Header im HTTP-Request mitgegeben, greift deine ACL nicht mehr und der Client landet im Tarpit.
Kannst du selbst mit openssl nachstellen und testen:
Wenn der Client per TLS-SNI den korrekten Namen im TLS-Handshake mitgibt, wird er im korrekten Frontend landen.
Wird dann aber ein falscher oder überhaupt kein "Host:"-Header im HTTP-Request mitgegeben, greift deine ACL nicht mehr und der Client landet im Tarpit.
Kannst du selbst mit openssl nachstellen und testen:
~ openssl s_client -connect 'hostname:443' -name 'name.im.ssl-zertifikat'
<... Handshake ...>
HEAD / HTTP/1.1
Host: ganzandererhost.example
Connection: close
<CRLF><CRLF>
1
Hallo,
Danke
Stefan
Danke
Ist das ein Standalone HAProxy oder auf einer *Sense?
Standalone in der DMZStefan
Zitat von @LordGurke:
Ohne haproxy im Detail zu kennen, aber HTTP und TLS sind ja halbwegs universell:
Wenn der Client per TLS-SNI den korrekten Namen im TLS-Handshake mitgibt, wird er im korrekten Frontend landen.
Wird dann aber ein falscher oder überhaupt kein "Host:"-Header im HTTP-Request mitgegeben, greift deine ACL nicht mehr und der Client landet im Tarpit.
Ohne haproxy im Detail zu kennen, aber HTTP und TLS sind ja halbwegs universell:
Wenn der Client per TLS-SNI den korrekten Namen im TLS-Handshake mitgibt, wird er im korrekten Frontend landen.
Wird dann aber ein falscher oder überhaupt kein "Host:"-Header im HTTP-Request mitgegeben, greift deine ACL nicht mehr und der Client landet im Tarpit.
Aber warum funktionieren denn die ActiveSync Einträge? Die kommen ja auch nicht mit Hostnamen in der Anfrage.
Feb 18 20:07:04 PublicProxyxxxxxxxx haproxy[518120]: 40.101.78.221:37247 [18/Feb/2024:20:06:14.693] haproxy-main~ xxxx_exchange1_exchange_ActiveSync/xxxx_exchange1_WAN1 0/0/26/-1/50032 504 198 - - sH-- 8/8/7/7/0 0/0 "POST /Microsoft-Server-ActiveSync?Cmd=Ping&User=xxxx%5Cxxxx&DeviceId=xxxx&DeviceType=Outlook HTTP/1.1" Ich habe diese Einträge nur mit /EWS
Ich stelle mir halt die Frage ob das ein Problem in der Funktion oder Sicherheit sein könnte.
Stefan
Ich habe mal mit Postman einen Zugriff ausgeführt.
POST
https://owa.xxxxxxxxx.com/EWS/Exchange.asmx
Keine Parameter
Hier funktioniert alles normal.
Ich bin verwirrt.
POST
https://owa.xxxxxxxxx.com/EWS/Exchange.asmx
Keine Parameter
Feb 18 20:16:29 PublicProxyxxxxxx haproxy[518120]: [Meine IP]:54872 [18/Feb/2024:20:16:29.575] haproxy-main~ xxxx_exchange1_exchange_ews/xxxx_exchange1_WAN1 0/0/0/14/14 401 276 - - ---- 4/3/0/0/0 0/0 "POST /EWS/Exchange.asmx HTTP/1.1" Hier funktioniert alles normal.
Ich bin verwirrt.
Hallo,
ich habe es gefunden.
Diese Art von Log erscheint wenn ich per HTTP (ohne s) auf /EWS zugreifen möchte.
Bzw. alle Zugriff via HTTP.
Man kann es auch sehen an "haproxy-main_http" bzw. "haproxy-main".
Wenn man nur hinschaut.
Es ist also kein Benutzer oder sonstiger Fehler.
Nur ein Hinweis, dass ein Zugriff auf https umgeleitet wurde.
Frage: Warum fragt ein Handy oder Outlook /EWS ohne https überhaupt an?
Ist das normal?
Stefan
ich habe es gefunden.
Diese Art von Log erscheint wenn ich per HTTP (ohne s) auf /EWS zugreifen möchte.
Bzw. alle Zugriff via HTTP.
Man kann es auch sehen an "haproxy-main_http" bzw. "haproxy-main".
Wenn man nur hinschaut.
frontend haproxy-main_http
mode http
no option httpclose
bind *:80
# Forward non SSL on the proxy
http-request redirect scheme https code 302 unless { ssl_fc }Es ist also kein Benutzer oder sonstiger Fehler.
Nur ein Hinweis, dass ein Zugriff auf https umgeleitet wurde.
Frage: Warum fragt ein Handy oder Outlook /EWS ohne https überhaupt an?
Ist das normal?
Stefan
1
Moin,
Gruß,
Dani
Frage: Warum fragt ein Handy oder Outlook /EWS ohne https überhaupt an?
Was für ein Hersteller, welches Modell, welche App wird verwendet?Gruß,
Dani
Zitat von @Dani:
Frage: Warum fragt ein Handy oder Outlook /EWS ohne https überhaupt an?
Was für ein Hersteller, welches Modell, welche App wird verwendet?Outlook 2019, aktuelle iPhone mit nativer Mail-App und Outlook-App gemischt.
Ich sammele Daten und mache daraus eine neue Frage.
Info am Rande.
Mit diesen Einträge kann man sehen welcher Hostname verwendet wurde und den Agentstring.
Mit diesen Einträge kann man sehen welcher Hostname verwendet wurde und den Agentstring.
http-request capture req.hdr(Host) len 32
http-request capture req.hdr(User-Agent) len 100
