So verhindern Sie Continuous ACK-Pakete an meinen Server

444
K Joe

Ich habe festgestellt, dass mein Server durchgehende ACK-Pakete von verschiedenen Standorten erhalten hat. Stoppen Sie niemals, wie unten (ich habe zum Erfassen tcpdump verwendet)

  1. Die Remote-Standorte verwenden https.
  2. enthält akamai, amazon..etc, was echt sein sollte.

Ich frage mich, ob es zu diesen Sites bisher erfolglose Verbindungen gab, dann passierte dies.

Ich würde gerne wissen, wie man diese ACK-Pakete nicht bekommt.

23:12:37.555238 IP prg02s12-in-f1.1e100.net.https > 192.168.192.128.52285: Flags [FP.], seq 0, ack 1, win 64240, length 0 23:12:37.555242 IP 17.167.192.152.https > 192.168.192.128.49292: Flags [FP.], seq 0, ack 1, win 64239, length 0 23:12:37.555246 IP prg02s12-in-f14.1e100.net.https > 192.168.192.128.49961: Flags [FP.], seq 0:55, ack 1, win 64240, length 55 23:12:37.555253 IP 17.164.1.38.https > 192.168.192.128.49844: Flags [FP.], seq 0:37, ack 1, win 64240, length 37 23:12:37.555293 IP a2-16-84-128.deploy.akamaitechnologies.com.https > 192.168.192.128.49850: Flags [FP.], seq 0:31, ack 1, win 64240, length 31 23:12:37.555301 IP 125.209.252.12.https > 192.168.192.128.49929: Flags [FP.], seq 0, ack 1, win 64240, length 0 23:12:37.555307 IP prg02s12-in-f4.1e100.net.https > 192.168.192.128.49964: Flags [FP.], seq 0:55, ack 1, win 64240, length 55 23:12:37.655195 IP fra07s31-in-f1.1e100.net.https > 192.168.192.128.58291: Flags [FP.], seq 0, ack 1, win 64240, length 0 23:12:37.655227 IP ec2-54-193-107-210.us-west-1.compute.amazonaws.com.https > 192.168.192.128.50448: Flags [FP.], seq 0:7, ack 1, win 64240, length 7 23:12:37.655233 IP fra07s31-in-f1.1e100.net.https > 192.168.192.128.41618: Flags [FP.], seq 0:110, ack 1, win 64240, length 110 23:12:37.655238 IP ec2-54-154-38-161.eu-west-1.compute.amazonaws.com.5223 > 192.168.192.128.48941: Flags [FP.], seq 0:7, ack 1, win 64240, length 7 23:12:37.655243 IP fra07s31-in-f1.1e100.net.https > 192.168.192.128.54130: Flags [FP.], seq 0:110, ack 1, win 64240, length 110 23:12:37.655247 IP prg02s12-in-f1.1e100.net.https > 192.168.192.128.52285: Flags [FP.], seq 0, ack 1, win 64240, length 0 23:12:37.655254 IP 17.167.192.152.https > 192.168.192.128.49292: Flags [FP.], seq 0, ack 1, win 64239, length 0 23:12:37.655259 IP prg02s12-in-f14.1e100.net.https > 192.168.192.128.49961: Flags [FP.], seq 0:55, ack 1, win 64240, length 55 23:12:37.655265 IP 17.164.1.38.https > 192.168.192.128.49844: Flags [FP.], seq 0:37, ack 1, win 64240, length 37 23:12:37.655271 IP a2-16-84-128.deploy.akamaitechnologies.com.https > 192.168.192.128.49850: Flags [FP.], seq 0:31, ack 1, win 64240, length 31 23:12:37.655275 IP 125.209.252.12.https > 192.168.192.128.49929: Flags [FP.], seq 0, ack 1, win 64240, length 0 23:12:37.655281 IP prg02s12-in-f4.1e100.net.https > 192.168.192.128.49964: Flags [FP.], seq 0:55, ack 1, win 64240, length 55 
1
Für fast jedes Paket in einer TCP-Verbindung sollte das ACK-Flag auf 1 gesetzt sein. Zusätzlich würde ich für eine Reihe von halb geöffneten Verbindungen viele eingehende Verbindungsanfragen mit SYN-Set und ohne ACK erwarten. Für jedes zweite Paket in der Verbindung ist ein ACK-Flag gesetzt. Frank Thomas vor 8 Jahren 2
Sie haben recht, ich habe einige Pakete mit Wireshark erfasst, diese Pakete sollten [SYN, ACK] und nicht [ACK] sein. Es gibt einige unbekannte Gründe dafür, dass es keine ACK-Pakete gibt. Ist es möglich, diese Art von Paketen automatisch zu löschen? K Joe vor 8 Jahren 0
Sie senden Daten an diese Webserver und sie bestätigen dies. Was lässt Sie glauben, dass dies etwas anderes ist, als wie es aussieht - legitime Daten werden anerkannt? David Schwartz vor 8 Jahren 1
Wie @DavidSchwartz feststellte, ist dies ein normales Verhalten für TCP. Die einzige Möglichkeit, ACKs zu reduzieren, ist SACK, aber beide Seiten müssen sich damit einverstanden erklären. Bei SACK wird ein ACK nach einer Gruppe von Paketen anstatt nur einem gesendet und alle nicht empfangenen Teile werden detailliert beschrieben. https://www.ietf.org/rfc/rfc2018.txt MaQleod vor 8 Jahren 0

0 Antworten auf die Frage