Wenn man den Web-Traffic zwischen einem Reverse Proxy (z.B. HAProxy) und einem Web Server (z.B. apache) zwecks Problemdiagnose analysieren will geht das nur mit tcpdump auf dem Web Server, da im Browser die HTTP Header, welche vom Reverse Proxy kommen nicht angezeigt werden.
Die einfachste Möglichkeit ist hier einfach auf dem Web Server tcpdump mit der Einschränkung auf die IP des Reverse Proxies und den Port auf dem Webserver laufen zu lassen:
(in diesem Beispiel hat der Reverse Proxy die IP 192.168.1.10 und verbindet auf den Web Server mit der IP: 192.168.1.80 auf Port 80)
[root@webserver ~]# tcpdump -i any -n -A host 192.168.1.10 and dst port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type EN10MB (Ethernet), capture size 262144 bytes
11:54:07.209092 IP 192.168.1.10.49030 > 192.168.1.80.http: Flags [S], seq 1732911455, win 29200, options [mss 1460,sackOK,TS val 3851445168 ecr 0,nop,wscale 7], length 0
E..<B.@.@.w............PgJ!_......r..C.........
..c.........
11:54:07.209204 IP 192.168.1.10.49030 > 192.168.1.80.http: Flags [.], ack 3322847288, win 229, options [nop,nop,TS val 3851445168 ecr 784805205], length 0
E..4B.@.@.w............PgJ!`...8...........
..c...-U
11:54:07.209210 IP 192.168.1.10.49030 > 192.168.1.80.http: Flags [P.], seq 0:141, ack 1, win 229, options [nop,nop,TS val 3851445168 ecr 784805205], length 141: HTTP: HEAD / HTTP/1.1
E...B.@.@.w[...........PgJ!`...8...........
..c...-UHEAD / HTTP/1.1
Host: www.example.com
User-Agent: curl/7.64.1
Accept: */*
X-Forwarded-Proto: https
X-Forwarded-For: 93.184.216.34
11:54:07.209557 IP 192.168.1.10.49030 > 192.168.1.80.http: Flags [.], ack 207, win 237, options [nop,nop,TS val 3851445169 ecr 784805205], length 0
E..4B.@.@.w............PgJ!..........c.....
..c...-U
11:54:07.229871 IP 192.168.1.10.49030 > 192.168.1.80.http: Flags [R.], seq 141, ack 207, win 237, options [nop,nop,TS val 3851445189 ecr 784805205], length 0
E..4B.@.@.w............PgJ!..........K.....
..c...-U
Obwohl man die Header hier schon sieht bekommt man noch etliches „Kauderwelsch“ des Netzwerkverkehrs mit.
Übersichtlicher wird, wenn man noch perl mit ins boot holt:
[root@webserver ~]# stdbuf -oL -eL /usr/sbin/tcpdump -i any -n -A -s 10240 "tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)" | egrep -a --line-buffered ".+(GET |HTTP\/|POST )|^[A-Za-z0-9-]+: " | perl -nle 'BEGIN{$|=1} { s/.*?(GET |HTTP\/[0-9.]* |POST )/\n$1/g; print }'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 10240 bytes
12:04:10.395903 IP 192.168.1.10.49396 > 192.168.1.80.http: Flags [P.], seq 3378467363:3378467504, ack 468830870, win 229, options [nop,nop,TS val 3852048355 ecr 785408392], length 141: HTTP: HEAD / HTTP/1.1
......a.HEAD / HTTP/1.1
Host: www.example.com
User-Agent: curl/7.64.1
Accept: */*
X-Forwarded-Proto: https
X-Forwarded-For: 93.184.216.34
HTTP/1.1 301 Moved Permanently
HTTP/1.1 301 Moved Permanently
Date: Wed, 18 Aug 2021 10:04:10 GMT
Server: Apache OpenSSL
Location: www.example.com/
Content-Type: text/html; charset=iso-8859-1
Damit sieht man nun schon die HTTP Header, welche vom Reverse Proxy beim Web Server ankommen.
Hallo!
Kurze Frage:
Kann man den HTTPS-Traffic auch debuggen – oder ist der Traffic durch das Zertifikat geschützt? Hintergrund: ich leite von einem ReverseProxy den Traffic über eine https-Verbindung zum Webserver. Hier möchte ich prüfen, ob der „Forwarded-For“ Header ankommt.
Mit dem 2. Befehl von hier bekomme ich jedoch kein Log angezeigt.. Auch, wenn ich den Befehl auf HTTPS abändere:
stdbuf -oL -eL /usr/sbin/tcpdump -i any -n -A -s 10240 „tcp port 443 and (((ip[2:2] – ((ip[0]&0xf)<>2)) != 0)“ | egrep -a –line-buffered „.+(GET |HTTPS\/|POST )|^[A-Za-z0-9-]+: “ | perl -nle ‚BEGIN{$|=1} { s/.*?(GET |HTTPS\/[0-9.]* |POST )/\n$1/g; print }‘
HTTPS Traffic kann man (natürlicherweise) nicht so einfach debuggen, da der ja verschlüsselt ist.
Da du in diesem Falle wahrscheinlich im Besitze des SSL Keys bist, welcher das Zertifikat verwendet kannst du damit den HTTPS Traffic entschlüsseln, was aber etwas komplizierter ist.
Du solltest mit einer google Suche nach „tcpdump decrypt https traffic“ zum Ziel kommen. 😉