it-swarm-eu.dev

Kann ich der Quell-IP einer HTTP-Anfrage vertrauen?

Wenn Sie versuchen, eine HTTP-Anforderung mit einer gefälschten IP-Adresse auszugeben, schlägt der Handshake TCP] fehl, sodass die HTTP-Anforderung aufgrund des SYN nicht abgeschlossen werden kann/ACK vom Server erreicht den bösen Client nicht ...

... in den meisten Fällen. Aber lassen Sie uns jetzt diese vier Fälle größtenteils ignorieren:
- Man in the Middle (MITM) greift an
- Der Fall, in dem der böse Client das Netzwerk des Webservers kontrolliert
- Der Fall, wenn der böse Client eine andere IP in seinem eigenen lokalen Netzwerk fälscht
- BGP-Angriffe

Dann kann ich tatsächlich der IP-Adresse einer HTTP-Anfrage vertrauen?

Hintergrund: Ich denke darüber nach, eine Karte mit IP-Adressen und Ressourcennutzung zu erstellen und IP-Adressen zu blockieren, die zu viel Ressourcen verbrauchen. Aber ich frage mich, ob es zum Beispiel eine Möglichkeit gibt, eine unendliche Anzahl von IP-Adressen zu fälschen (indem erfolgreiche HTTP-Anforderungen mit gefälschten IPs ausgegeben werden), so dass der Webserver Ressourcennutzung durch IP- Puffer wächst sehr groß und verursacht Speicherfehler.

(Hmm, vielleicht könnte ein böser Internet-Router sehr viele Anfragen vortäuschen. Aber sie sind nicht böse, oder? (Dies wäre ein MITM-Angriff? Deshalb habe ich oben meistens Missachtung gesagt))

41
KajMagnus

Ja (mit Ihrer Annahme, dass der Client die Rückgabe des Handshakes bei einer gefälschten IP abfangen kann), wenn Sie die Dinge richtig machen. HTTP-Anforderungen werden über TCP ausgeführt. Bis der Handshake abgeschlossen ist, beginnt der Webserver nicht mit der Verarbeitung der HTTP-Anforderung. Zugegeben, ein zufälliger Benutzer könnte versuchen, das Ende eines Handshakes zu fälschen. Da sie jedoch raten müssen, dass der Server ACK generiert hat, sollten sie nur eine 1: 2 ^ 32 (~ 4 Milliarden) Chance haben, dies jedes Mal erfolgreich zu tun.

Stellen Sie, wie Ladadadada kommentierte, sicher, dass Sie nicht den falschen Wert der Remote-IP-Adresse in Ihrer Webanwendung ermitteln. Sie möchten die IP-Adresse aus dem IP-Datagramm-Header (insbesondere der Quell-IP-Adresse). Sie möchten keine Werte wie X-Forwarded-For/X-Real-IP , die trivial gefälscht werden können, da sie im HTTP-Header festgelegt sind. Testen Sie auf jeden Fall, indem Sie versuchen, einige IP-Adressen zu fälschen. mit say a Browser Plugin oder manuell mit telnet yourserver.com 80.

Der Zweck dieser Felder besteht darin, dass Web-Proxys (dh Cache-Inhalte, um sie schneller bereitzustellen) mit Webservern über die tatsächliche IP-Adresse des Benutzers und nicht über die IP-Adresse der Proxys (möglicherweise für Hunderte von Benutzern) kommunizieren können. Da dieses Feld jedoch von jedem festgelegt werden kann, sollte es nicht vertrauenswürdig sein.

23
dr jimbob

Kann ich der Quell-IP einer HTTP-Anfrage vertrauen?

Sie können sich ziemlich sicher sein, dass die Quell-IP-Adresse einer HTTP-Anforderung die Quelladresse der TCP - Verbindung ist, die die Anforderung generiert hat.

Wann man einer IP-Adresse vertraut, ist eine komplizierte kontextspezifische Frage, aber nicht wirklich das, was Sie fragen.

Sie sind besorgt über die Auswirkungen der Verwendung/Implementierung von IP-Ratenbeschränkungen auf Anwendungsebene und über eine zusätzliche Anfälligkeit für Denial-of-Service-Angriffe?

Ich frage mich, ob dies in der App-Ebene zusätzliche Sicherheitslücken mit sich bringt, ja.

Dies hängt ganz von Ihrer Implementierung ab, sowohl von der Richtlinie als auch von der Technologie.

  • Für welche Art von Ressource möchten Sie den Verbrauch begrenzen?
  • Was möchten Sie mit dieser Tarifgrenze erreichen?
  • In welchem ​​Zeitraum möchten Sie eine Buchhaltung durchführen?
  • Wo möchten Sie das Limit anwenden?
  • Ist die IP-Adresse der beste Schlüssel für das Ratenlimit?
  • Was sind die wahrscheinlichen Gründe für einen übermäßigen Verbrauch?
  • Wie sollte die Benutzererfahrung bei übermäßigem Verbrauch sein?

Abhängig von den Antworten auf diese Fragen kann das Ratenlimit an anderer Stelle in der Dienstinfrastruktur besser platziert werden, z. dedizierte Firewall, lokale Firewall. Wenn der Zugriff authentifiziert ist, ist der authentifizierte Berechtigungsnachweis möglicherweise ein besserer Schlüssel für die Tarifabrechnung, und Ihre Grenzen werden definiert.

2
MattH

Was wäre der Sinn bei der Ausgabe von gefälschtem SYN an einen HTTP-Server, wenn Sie nicht beabsichtigen, den TCP Handshake) fortzusetzen? Ihr Webserver wird die HTTP-Anforderung nur sehen, wenn der (möglicherweise gefälschte) Der Client erhält die SYN/ACK und baut weiterhin die Sitzung TCP] auf und sendet eine HTTP-Anforderung.

Speichern Sie die Datenbank auf der Festplatte und strukturieren Sie sie geschickt (wie einen Baum) für schnelle Suchvorgänge.

Wenn der Kunde gefälscht ist oder nicht, macht das wirklich einen Unterschied für Sie? Wenn sie sich schlecht benehmen, benehmen sie sich schlecht, egal ob sie gefälscht sind oder nicht.

Aus Sicht eines Webservers würde ich die Remote-IP als die wahre Remote-IP betrachten.

1
MattBianco