Sind IP-Adressen „trivial zu fälschen“?


65

Ich habe einige Hinweise zum neuen öffentlichen DNS-Dienst von Google gelesen :

Ich habe im Abschnitt Sicherheit diesen Absatz bemerkt:

Bis eine systemweite Standardlösung für DNS-Schwachstellen, wie das DNSSEC2-Protokoll, universell implementiert ist, müssen offene DNS-Resolver eigenständig einige Maßnahmen ergreifen, um bekannte Bedrohungen abzuwehren. Viele Techniken wurden vorgeschlagen; Eine Übersicht über die meisten von ihnen finden Sie in IETF RFC 4542: Maßnahmen zur Verbesserung der Ausfallsicherheit von DNS gegenüber gefälschten Antworten . In Google Public DNS haben wir die folgenden Ansätze implementiert und empfehlen diese:

  • Überprovisionierung von Maschinenressourcen zum Schutz vor direkten DoS-Angriffen auf die Resolver selbst. Da es für Angreifer trivial ist, IP-Adressen zu fälschen, ist es unmöglich, Abfragen basierend auf IP-Adresse oder Subnetz zu blockieren. Der einzig wirksame Weg, solche Angriffe abzuwehren, besteht darin, die Last einfach aufzunehmen.

Das ist eine deprimierende Erkenntnis; Selbst bei Stack Overflow / Server Fault / Super User verwenden wir häufig IP-Adressen als Grundlage für Sperren und Sperren aller Art.

Zu denken, dass ein "talentierter" Angreifer trivial jede gewünschte IP-Adresse verwenden und so viele eindeutige gefälschte IP-Adressen synthetisieren könnte, wie sie möchten, ist wirklich beängstigend!

Also meine Frage (n):

  • Ist es für einen Angreifer wirklich so einfach, eine IP-Adresse in freier Wildbahn zu fälschen?
  • Wenn ja, welche Abhilfemaßnahmen sind möglich?

Gefälschte IPs sollten kein Problem für IP-basierte Verbote sein, da das ultimative Ziel darin besteht, sich Zugang zu verschaffen, was legitime Antworten erfordert. Einige der größeren Risiken sind jedoch: IP-Adressen, die von vielen Personen gemeinsam genutzt werden (Schulen, Arbeitsplätze, Internetcafés usw.), und IP-Adressen, die sich nach einem Modem-Reset auf nicht statischen DSLs ändern können.
Halil Özgür

Bei vielen Angriffen mit gefälschten Adressen ist der Zugriff nicht das primäre Ziel. Ich vermute, dass die verschiedenen Verstärkungsangriffe mit DNS häufiger auftreten. DNS ist reizvoll (mit DNSSEC schlechter) - Sie können ein kleines <100-Byte-Paket mit einer gefälschten Quelladresse senden, wodurch die gefälschte Adresse eine 7x bis 40x-Verstärkung als Antwort erhält.
Michael Graff

Antworten:


50

Wie von vielen anderen angegeben, ist es trivial, IP-Header zu fälschen, solange es nicht wichtig ist, eine Antwort zu erhalten. Dies ist der Grund, warum es meistens bei UDP auftritt, da TCP einen 3-Wege-Handshake erfordert. Eine bemerkenswerte Ausnahme ist die SYN-Flut , die TCP verwendet und versucht, Ressourcen auf einem empfangenden Host zu binden. Auch hier spielt die Quelladresse keine Rolle, da die Antworten verworfen werden.

Ein besonders schlimmer Nebeneffekt der Fähigkeit von Angreifern, Quelladressen zu fälschen, ist ein Backscatter- Angriff. Es gibt eine ausgezeichnete Beschreibung hier , aber kurz, es ist das Gegenteil von einer traditionellen DDoS - Attacke:

  1. Übernimm die Kontrolle über ein Botnetz.
  2. Konfigurieren Sie alle Ihre Knoten so, dass sie für böswillige Pakete dieselbe Quell-IP-Adresse verwenden . Diese IP-Adresse wird Ihr letztes Opfer sein.
  3. Senden Sie Pakete von allen von Ihnen kontrollierten Knoten an verschiedene Adressen im Internet, richten Sie sich an Ports, die im Allgemeinen nicht geöffnet sind, oder stellen Sie eine Verbindung zu gültigen Ports (TCP / 80) her, die behaupten, Teil einer bereits vorhandenen Transaktion zu sein.

In beiden in (3) genannten Fällen antworten viele Hosts mit einem nicht erreichbaren ICMP oder einem TCP-Reset, der auf die Quelladresse des schädlichen Pakets abzielt . Der Angreifer hat jetzt potenziell Tausende von nicht gefährdeten Computern im Netzwerk, die mithilfe einer gefälschten Quell-IP-Adresse einen DDoS-Angriff auf sein ausgewähltes Opfer ausführen.

In Bezug auf die Minderung ist dieses Risiko tatsächlich eines, das nur ISPs (und insbesondere ISPs, die Kundenzugang anstatt Transit bieten) in den Griff bekommen können. Hierfür gibt es zwei Hauptmethoden:

  1. Eingangsfilterung - stellt sicher, dass die in Ihr Netzwerk eingehenden Pakete aus Adressbereichen stammen, die sich auf der anderen Seite der eingehenden Schnittstelle befinden. Viele Router-Anbieter implementieren Funktionen wie die Unicast-Umkehrpfadweiterleitung , bei der anhand der Routing- und Weiterleitungstabellen des Routers überprüft wird, ob der nächste Hop der Quelladresse eines eingehenden Pakets die eingehende Schnittstelle ist. Dies wird am besten beim ersten Layer-3-Hop im Netzwerk (dh Ihrem Standard-Gateway) durchgeführt.

  2. Ausgangsfilterung - stellt sicher, dass Pakete, die Ihr Netzwerk verlassen, nur von Adressbereichen stammen, die Sie besitzen. Dies ist die natürliche Ergänzung zur Ingress-Filterung und im Wesentlichen ein Teil des „guten Nachbarn“. Stellen Sie sicher, dass der Datenverkehr auch dann nicht an Netzwerke weitergeleitet wird, wenn Ihr Netzwerk durch böswilligen Datenverkehr gefährdet ist.

Diese beiden Techniken sind am effektivsten und am einfachsten zu implementieren, wenn sie in Edge- oder Access-Netzwerken ausgeführt werden, in denen Clients mit dem Anbieter kommunizieren. Das Implementieren einer Eingangs- / Ausgangsfilterung über der Zugriffsschicht wird aufgrund der Komplexität mehrerer Pfade und des asymmetrischen Routings schwieriger.

Ich habe gesehen, dass diese Techniken (insbesondere die Ingress-Filterung) in einem Unternehmensnetzwerk sehr effektiv eingesetzt werden. Vielleicht kann jemand mit mehr Erfahrung als Dienstanbieter einen besseren Einblick in die Herausforderungen beim Einsatz von Ingress- / Egress-Filtern im Internet geben. Ich stelle mir vor, dass der Hardware- / Firmware-Support eine große Herausforderung darstellt und dass Upstream-Anbieter in anderen Ländern nicht in der Lage sind, ähnliche Richtlinien umzusetzen ...


Hört sich böse an. Kann ein Administrator also etwas tun, wenn er feststellt, dass sein Server auf diese Weise als Ziel ausgewählt wurde? Könnte es möglich sein, die ICMP-Pakete und die TCP-Rücksetznachrichten von allen IPs vorübergehend zu blockieren? Würden Sie überhaupt in der Lage sein, halbnormal zu arbeiten?
UpTheCreek

45

Ist es für einen Angreifer wirklich so einfach, eine IP-Adresse in freier Wildbahn zu fälschen?

Klar, wenn es mir egal ist, tatsächlich Antworten zu erhalten, kann ich sehr einfach Pakete mit jeder beliebigen Quelladresse versenden. Da viele ISPs keine guten Egress-Regeln haben, wird alles, was ich im Allgemeinen fälsche, zugestellt.

Wenn der Angreifer tatsächlich eine bidirektionale Kommunikation benötigt, wird dies sehr schwierig. Wenn sie eine bidirektionale Kommunikation benötigen, ist es in der Regel einfacher, einfach einen Proxy zu verwenden. Was sehr einfach einzurichten ist, wenn Sie wissen, was Sie tun.

Das Sperren von Personen nach IP-Adresse ist in SF / SO / SU mäßig wirksam, da die Site http / https verwendet, was eine bidirektionale Kommunikation erfordert.


16
http (s) ist hier der Schlüssel. DNS verwendet UDP, sodass die gesamte Kommunikation über einzelne Pakete ohne Bestätigungen im Protokoll erfolgt.
Noah

16
Vermutung ist wie E-Mail. Sie können mit jeder gewünschten Adresse senden, es sei denn, Sie möchten Antworten erhalten
Jorge Bernal

@Jorge: Auf jeden Fall. Die E-Mail / Post-Analogie eignet sich hervorragend, um dies den Endbenutzern zu erklären.
Evan Anderson

In DNS kann auch TCP verwendet werden, aber das macht den Leuten derzeit Angst. Es ist jedoch kein ACK integriert, da die Antwort das ACK ist.
Michael Graff

6
@noah - eigentlich ist TCP der Schlüssel, nicht HTTP. Es ist nicht unmöglich, TCP zu fälschen, aber es ist 100-mal schwieriger als UDP.
Alnitak,

22

Kleiner Proof of Concept für Zordeches Antwort (mit Ubuntu):

$ sudo apt-get install hping3
$ sudo hping3 -1 --spoof 11.10.10.20 www.google.com
HPING www.google.com (eth0 64.233.169.105): icmp mode set, 28 headers + 0 data bytes

Dann in einer anderen Konsole:

$ sudo tcpdump -i eth0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
13:30:19.439737 IP 11.10.10.20 > yo-in-f105.1e100.net: ICMP echo request, id 31297, seq 0, length 8

Also ja, trivial, aber dann erhalten Sie die Antworten nicht wie zuvor erwähnt, es sei denn, Sie haben Zugriff auf 11.10.10.20 oder haben irgendwo zwischen www.google.com und 11.10.10.20 einen Schnüffler (und der müsste ganz vorne stehen) von jedem Ende, da Sie die Route der Pakete nicht vorhersagen können). Außerdem lässt das Spoofer-Gateway (ISP) dieses Paket möglicherweise nicht aus der Tür, wenn eine IP-Überprüfung durchgeführt wird und die Quelle schlecht riecht.


1
Aber ISPs kümmern sich normalerweise nicht um die Paketinspektion, oder?
Pacerier

13

IP-Adressen können leicht für den unidirektionalen UDP- Verkehr gefälscht werden. Bei TCP-Paketen können Sie nur mit SYN-Paketen eine halboffene TCP-Verbindung herstellen. Dies ist auch die Basis für eine Art DOS-Angriff. Sie können jedoch keine HTTP-Verbindung mit einer gefälschten Adresse herstellen (wenn Sie beispielsweise Sitzungen filtern, um dieselbe IP-Adresse zu verwenden). Sie können zwar eine IP-Adresse in den Paketen fälschen, dies ist jedoch nur für bestimmte Arten von Denial-of-Service-Angriffen hilfreich.


Meinen Sie damit, dass es schwierig ist , eine HTTP-Verbindung mit einer gefälschten Adresse herzustellen, oder dass dies gar nicht möglich ist ?
Pacerier

Im offenen Internet ist das unmöglich. Wenn Sie sich im selben LAN befinden, gibt es einige Tricks, die den anderen Computer dazu bringen können, Datenverkehr an Sie zu senden ( web.eecs.umich.edu/~zhiyunq/pub/… ). Sie können sich das so vorstellen. UDP ist wie das Versenden einer Postkarte. Sie können einen beliebigen Namen auf die gewünschte Absenderadresse schreiben. TCP ist wie eine Konversation, bei der Sie die Konversation nicht fortsetzen können, wenn Sie nicht die richtige Absenderadresse eingeben. Einige der anderen Antworten hier erklären es viel besser.
FryGuy

10

In diesem Artikel wurde ausdrücklich über DNS gesprochen. DNS verwendet sowohl UDP- als auch TCP-Pakete. Die UDPs können gefälscht werden, aber nicht die TCPs. TCP erfordert einen 3-Wege-Handshake . Wenn die IP-Adresse für ein TCP-Paket gefälscht ist, erhält der fälschende Computer keine Antwort und die Verbindung schlägt fehl. UDP ist, wie in anderen Antworten erwähnt, "fire and forget" und erfordert keine Antwortkommunikation. DoS-Angriffe erfolgen aus diesem Grund fast ausschließlich in Form von UDP-Paketen.

Im Zusammenhang mit Stack Overflow- und Familiensites ist das von Takaun Daikon angesprochene Problem sehr berechtigt. Es gibt viele Möglichkeiten, eine neue IP-Adresse vom ISP zu erhalten. Das Ändern einer MAC-Adresse ist eindeutig am einfachsten und funktioniert für viele ISPs. Darüber hinaus können viele Leute, die albern sind, einen öffentlichen Proxy oder TOR verwenden. Das eindeutige Blockieren der Ursprungs-IP für diese Pakete würde lediglich den Proxy- oder TOR-Abschlussknoten blockieren.

Ist die Sperrung von IP-Adressen also gültig? Hölle ja es ist. Aber Sie werden mit Fehlern enden. Sie werden einige IP-Adressen blockieren, die wirklich nicht die Ursache des Problems sind (dh Proxies), und Sie werden auch Leute haben, die Ihre Blockierungen durch Ändern der IP-Adressen umgehen. Die Person, die das Pech hat, die gesperrte IP später zu erhalten, kann nicht auf die SO-Site-Familie zugreifen. Aber die Fehlerrate sollte klein sein. Es sei denn, Sie blockieren große Mengen von IP-Adressen. Aber wenn Sie ein oder zwei am Tag blockieren, sollte es Ihnen gut gehen.

Möglicherweise möchten Sie ein etwas ausgefeilteres Schema einführen, in dem Sie blockieren, jedoch nur für einen Zeitraum wie ein Jahr. Wenn Ihr Netzwerk in der Lage ist, die Bandbreite zu drosseln oder die Verbindung zu begrenzen, können Sie auch ein Schema in Betracht ziehen, bei dem Duschtaschen, auf denen Apache-Benchmarks auf Ihrer Site ausgeführt werden, nur in einen Käfig mit sehr begrenzter Bandbreite gestellt werden.


1
Sie können gefälscht werden. Schauen Sie sich einfach an, wie Sie TCP-Sitzungen entführen. google.com/search?q=hijack+tcp+session
Dan

Wenn der Angreifer nicht von Anfang an Zugriff auf den Datenverkehr hat, sind TCP-Sequenzierungsangriffe mit modernen Betriebssystemen ziemlich unpraktisch. Wenn sie sowieso ein Mann in der Mitte sind, müssen sie wahrscheinlich sowieso nicht einmal TCP-Verbindungsentführungen durchführen.
Evan Anderson

10

IP-Spoofing wird fortgesetzt, da ISPs faul sind.

Mein ISP weiß verdammt gut, dass ich an einer bestimmten Adresse oder zumindest im Subnetz bin, in dem ich mich befinde. Trotzdem kann ich jede Quelladresse verwenden. Warum ist das so? Einfach, kosten.

Wenn ich hier und da ein paar Adressen fälsche, kostet es meinen ISP nichts. Wenn jeder Benutzer meines Internetdienstanbieters zwischen 1:00 und 2:00 ein Paket fälschte, wäre dies immer noch kaum ein Fehler auf dem Radar. Wenn ein Botnetz jedoch viele gefälschte Pakete von vielen Hosts auf vielen ISPs sendet, stürzt der Zielcomputer oder das Netzwerk ab.

Die finanzielle Realität ist, dass Spoofing nichts kostet, wenn Sie nicht angegriffen werden. Die Filterung in der Nähe des Kunden kostet Geld, und derjenige, der das Geld ausgibt, erzielt nur eine geringe Rendite, wenn er weiß, dass er ein guter Netzwerkbürger ist.

UDP und ICMP sind am einfachsten zu fälschen, aber TCP ist auch möglich. Es erfordert ein unsicheres Remote-Betriebssystem, das vorhersehbare Folgenummern verwendet, um es auszunutzen. Manchmal sind es die Lastenausgleichsmaschinen, die die Folgenummern ändern und vorhersehbar machen. TCP ist also möglich - aber schwieriger.

DNS-Antispoofing konzentriert sich hauptsächlich auf die Sicherheit, um zu verhindern, dass jemand eine falsche Antwort an einen rekursiven Resolver sendet. Die Flooding-Aspekte von UDP sind nicht DNS-spezifisch, außer dass eine einzelne kleine Abfrage (z. B. für '.') Eine ziemlich große Antwort hervorruft. Somit ergibt es einen schönen Verstärkungsvektor. Es gibt viele andere UDP-Protokolle, die funktionieren, aber DNS wird überall verwendet, und es ist leicht, Maschinen zu finden, mit denen Angriffe verstärkt werden können.

DNSSEC macht dies mit UDP-Paketen, die eine Größe von 4 KB erreichen können, noch schlimmer.


6

Bei DNS-basierten (D) DOS-Angriffen ist es trivial, IP-Adressen zu fälschen, da es sich in der Regel um UDP-Pakete handelt, bei denen man die Daten vergessen muss. Bei HTTP-Datenverkehr ist dies nicht der Fall. Sie müssen sich also entweder im selben lokalen Netzwerk wie der Webserver befinden (dies ist natürlich durchaus möglich, je nachdem, wo Ihre Site gehostet wird) oder Sie müssen die Zwischenrouter steuern.


6

Sie können einen Brief an jeden senden, und wenn Sie den Umschlag nicht mit einer Absenderadresse versehen (oder die falsche), können sie alle Junk-Mail-Filter der Welt beauftragen und Ihre Nachricht nicht herausfiltern, ohne sie zu öffnen (zu verarbeiten) ) es.

Wenn der Absender jedoch eine Antwort wünscht, sollte die Absenderadresse korrekt sein, oder es müsste einen Mechanismus auf Anwendungsebene geben, um die richtige Adresse zu erhalten. Ich kann Sie also glauben machen, dass Sie einen Brief von Nana öffnen, aber selbst wenn ich Sie mit dem Inhalt des Briefes täusche, werden Sie Nana keinen an CASH ausgestellten Scheck an eine Adresse in Nigeria schicken (es sei denn, Nana ist Nigerianerin) ). Herausforderung / Reaktion ist also eine wirksame Verteidigung, solange Sie nicht auch ein Mann im Mittelalter sind.


5

Ich kann jede beliebige Quell-IP-Adresse in einem Datagramm festlegen.
Ob mein ISP ein solches Paket ins Freie lassen würde, ist eine andere Frage.


Gibt es überhaupt eine Möglichkeit, den ISP-Filter zu umgehen?
Pacerier

5

Dies ist sicherlich eine Realität, mit der man sich befassen muss, aber das zugrunde liegende Problem ist wirklich nicht technisch: Menschen mit böswilliger Absicht, die versuchen, böswillige Dinge zu tun. Die eigentliche Lösung muss daher auch nichttechnisch sein.

Ich denke, was Stackoverflow getan hat, ist genau die richtige Lösung für die Behandlung der zweiten Verteidigungslinie: Die Techniken zur Einschränkung potenzieller Spam-Benutzer durch die verschiedenen Möglichkeiten, ihre Fähigkeit zur Interaktion mit der Plattform einzuschränken, bevor ein gewisses Maß an "Glaubwürdigkeit" erreicht wird.

Diese Techniken tragen nicht nur zur Verbesserung der Gesamtqualität der Website bei, sondern regen die Benutzer auch dazu an, sich stärker einzubringen und glaubwürdigere / zuverlässigere Antworten zu geben.

Aus technischer Sicht ist es am besten, wenn Sie wie von Google vorgeschlagen vorgehen: Nehmen Sie die zusätzliche Last nur effizient auf.

Tolle Arbeit und immer besser werden!


3

UDP ist der Hauptgrund, warum dies so einfach ist. Tatsächlich nutzen Skype und Slingbox die Möglichkeit, IP-Adressen einfach in UDP zu fälschen , um durch NAT zu „ pochen “ und Peer-to-Peer zu ermöglichen.

TCP ist schwieriger, da ein vollständiger SYN / ACK-Zyklus erforderlich ist. Sie können den Server jedoch weiterhin mit hängenden SYN-Paketen überfluten, die an mehrere IP-Adressen weitergeleitet werden und im Wesentlichen eine große Anzahl von Routern binden.


1
Die Router leiten nur Pakete weiter. Sie behalten den TCP-Status nicht bei, daher ist ein Paket ein Paket für sie.
Michael Graff

guter Punkt. So werden Server (oder andere Front-End-Geräte, die SYN / ACK-Aushandlungen durchführen) gebunden, die auf ihre ACK warten :-) Wir haben unsere Load Balancer so konfiguriert, dass sie SYN / ACK vollständig aushandeln, bevor sie an die Server übergeben werden eine bereits offene verbindung, so dass bigtime in diesem fall hilft.
Justin

2

Wie oben erwähnt, ist die Verwendung von Proxys trivial, und es steht eine sehr große Anzahl offener anonymer Proxys zur Verfügung.

Auch ohne einen Proxy kann ich die MAC-Adresse in meiner Firewall auf einen beliebigen neuen Wert einstellen, mein Kabelmodem zurücksetzen und mein ISP weist mir eine brandneue, glänzende IP-Adresse zu.

Und das ist nur für den Anfang. Es gibt noch viele andere Möglichkeiten, um IP-Sperren zu umgehen.


das ist kein Problem. Ein echtes "Problem" ist hier das Design des IP-Protokolls, bei dem nicht überprüft werden muss, ob die IP-Adresse, mit der Sie Ihr IP-Paket erstellen, Ihnen gehört oder nicht. Sie dürfen also einen Sturm von Paketen mit unterschiedlichen Quelladressen (Zieladressen) erstellen, und nichts hindert Sie daran, diese zu versenden.
Monomythos

3
Etwas könnte dich aufhalten. Ihr Internetdienstanbieter könnte Ausgangsfilter auf seinen Routern einrichten, damit Pakete nur weitergeleitet werden können, wenn die Quell-IP-Adresse tatsächlich zu diesem Netzwerk gehört.
Zoredache

2

Wenn ja, welche Abhilfemaßnahmen sind möglich?

Auf der Empfängerseite können Sie nicht viel tun.

Der ISP des Fälschers sollte den ausgehenden Datenverkehr filtern, damit seine Kunden keine IPs aus verschiedenen Netzwerken fälschen können.

Die Routerkonfiguration besteht nur aus wenigen Zeilen, daher gibt es keine gute Entschuldigung, dies nicht zu tun.

Es gibt eine Möglichkeit, den Angreifer zu verfolgen, die jedoch die Mitwirkung Ihrer Upstream-Anbieter erfordert: http://www.cymru.com/Documents/dos-and-vip.html


2

Wie andere betont haben, ist UDP ziemlich trivial zu fälschen, TCP nicht so sehr.

Die bevorzugte, aber leider nicht universell einsetzbare Verteidigung sind Austrittsfilter.

Für ISPs, die DSL-Dienste usw. ausführen, sollte jede virtuelle Leitung mit ip verify unicast reverse-path(oder was auch immer die Nicht-Cisco-Entsprechung ist) konfiguriert werden, die jedes Paket blockiert, dessen Quell-IP-Adresse nicht in den Bereichen liegt, von denen bekannt ist, dass sie über diese Leitung geleitet werden.


1

Ich kann mich erinnern, wie ich in den späten 90ern mit Visual Basic Sockets programmiert habe, und wir konnten die Quell-IP für unsere Verbindung einstellen. Ich erinnere mich vage, dass netstat -an die tatsächliche Quell-IP anzeigte, als wir es versuchten, aber die Apache-Protokolle zeigten die gefälschte IP an; und ich glaube, Apache hat die gefälschte IP auch an die Perl-Module übergeben und so weiter.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.