Archiv für die '2-alert 'category

«Ältere Einträge

TCP-Optionen Challenge - Hinweise

18. November 2009

Früher habe ich geschrieben eine Herausforderung zu einem tcpdump / WinDump Filter, der Pakete, die die TCP-Option "Window Scale" gesetzt haben einzufangen schreiben würde. Einige Leute sind in der Nähe, aber ich wollte ein paar Tipps zu posten. Außerdem habe ich kein Problem mit Ihnen per E-Mail direkt an mich, sondern um die Herausforderung, die Sie haben, um die Antwort zu den Kommentaren nach zu gewinnen. So gibt es keine Frage, wer die Antwort gefunden, zuerst.

Alle TCP-Optionen werden durch ein "Registry Kind"-Wert (ähnlich der ICMP Feld "Typ") angegeben. Im Fall von Window Scale, ist, dass Wert 3. Außerdem enthalten alle TCP-Optionen mit Ausnahme von NOP eine sekundäre Feld "Länge". Diese legt fest, wie viele Bytes der Optionen ist mit, darunter die "Registry Kind" Byte. Im Fall von Window Scale die Länge beträgt immer 3. Also haben wir:

  • 1 Byte für Registry Art
  • 1 Byte für Länge
  • 1 Byte für die tatsächliche WScale Wert

Tipp 2: Wenn Sie noch nie in die TCP-Optionen Bereich haben gebohrt, hat tshark einem kühlen Option:

tshark-n-r capture-file.cap-T Felder-e tcp.options

Dadurch wird der gesamte TCP-Optionen Bereich in Hex-Ausgang, so dass Sie zumindest sehen können, wie es aussieht.

Finale Ahnung, ich habe eine Linux-SYN-Paket, das WScale bis 5 Sets für Sie zu nutzen, um den Filter zu überprüfen veröffentlicht.

linux-syn

Viel Glück!

Chris

Keine Kommentare »

Posted in 2-Alarm , Packet Decoding

Tags:

TCP-Optionen Herausforderung

18. November 2009

Ich habe ein bisschen los, einschließlich der Veröffentlichung einer neuen Referenz-Tool für das Apple iPhone und iPod. Das Tool ist Call Packet Decode und ich habe Setup einen alternativen Ort zu helfen, pflegen sie.

Ich fühle mich vernachlässigt diese Seite in den letzten paar Wochen schlecht, so habe ich beschlossen, zu werfen, eine weitere Herausforderung. Der Gewinner erhält eine kostenlose Kopie der oben genannten Packet Decode-Tool. OK, so dass Sie nicht in der Lage sein, auf den Erlös den Ruhestand, aber hoffentlich wird das Tool die Ihnen das Leben ein bisschen leichter. ;)

Also hier ist die Herausforderung:

Schreiben Sie eine tcpdump oder WinDump Filter, der nur erfassen werden Pakete, die das TCP "Window Scale"-Option eingestellt haben. Alle anderen TCP-Option Einstellungen können ignoriert werden.

Ziemlich einfach, nicht wahr? Erste Person, um die Antwort in den Kommentaren Beitrag erhält den Preis.

2 Kommentare »

Posted in 2-Alarm , Packet Decoding

Tags:

Tshark Challenge - Uber-Geek Antwort

13. Oktober 2009

In meinem letzten Beitrag habe ich links mit einer Frage: Angesichts dessen, was wir in der Dekodierung Datei mit tshark, welche Auswirkungen (wenn überhaupt) gäbe es, wenn wir eine Stateful Inspection Firewall zwischen dem Angreifer und dem Webserver Ort gesehen? Mit anderen Worten, wenn der Angreifer läuft ein Paket-Sniffer, würden sie immer noch die Web-Server ein Auslaufen von 404-Fehlern?

Und die Antwort ist ...

Vielleicht. :)

Nicht alle Stateful-Inspection-Firewalls sind gleich. Einige Griff Pakete etwas anders als andere. Zum Beispiel einige (wie Checkpoint, Netscreen und andere) lassen Nicht-SYN-Paketen zu ermöglichen Regeln erzeugen neue Staat Tabelleneinträge. Einige (Cisco, Netfilter und andere) erzeugt nur einen Staat Tabelle mit der richtigen Session-Aufbau (muss TCP drei Pakettypen Handshake zu sehen).

Die NIPS schickte eine gültige Reset-Paket an den Angreifer im Internet. Jede der oben genannten Firewalls würde die Reset-Paket und entfernen Sie den Eintrag aus dem Zustand Tisch. Wenn die Web-Server zu kommunizieren jedoch weiter, würde nur den ersten Satz von Firewalls lassen die Pakete austreten, um den Angreifer. Der zweite Satz von Firewalls würde einfach drop den Verkehr. In der Tat, wenn wir ihnen bei der Einrichtung mit einer deny-Regel statt eines Rückgangs der Regel würden sie die Sitzung auf dem Webserver zu töten damit das Problem zu lösen, indem die NIPS erstellt.

Warum haben manche Anbieter lassen Quittungspaketen erzeugen neuen Zustand Tabelleneinträge? Dies scheint ein wenig eingängig als eine legitime Sitzung immer los ist, mit einem SYN-Paket zu starten. Es gibt zwei Gründe dies macht gute funktionelle Sinn:

  • Die Aktualisierung der Firewall-Regeln nicht umbringt aktiven Sitzungen
  • Active-Active-Setup wird der Verkehr vor pass auf staatliche Tabelle sync

Natürlich haben wir die Funktionalität auf Kosten der Sicherheit erhöht. Leider ist die typische Trade-off.

Hoffe, Sie hatten Spaß mit dieser Herausforderung. Wenn Interesse besteht werde ich nach mehr in die Zukunft.

2 Kommentare »

Posted in 2-Alarm , Network Security , Packet Decoding

Tags:

Tshark Challenge - The Final Antworten

9. Oktober 2009

In meinem letzten Beitrag hatten wir festgestellt, dass die Trace-Datei einer Sitzung, in einem einzigen geschliffen netzwerkbasierte Intrusion Prevention-System versucht, einen Angriff von einem HTTP-Client auf einem Webserver zu stoppen enthalten hatte. Wir schlossen daraus, dass der Client die Daten angefordert hat Blick eher verdächtig, und erwies sich das System eines Dritten (der NIPS) war verantwortlich für die Reset-Pakete während der Sitzung übermittelt.

In diesem Beitrag müssen wir noch zwei Fragen beantworten:

  1. War der Angriff erfolgreich?
  2. Warum hat die Web-Server ignorieren die TCP-Reset-Packet von der NIPS übertragen?

War der Angriff erfolgreich?

Der Angreifer war auf der Suche um herauszufinden, ob die Datei "startstop.html" in der "Administrator"-Verzeichnis wurde. Werfen wir einen Blick auf eines der Pakete an den Angreifer nach dem Reset-Pakete übermittelt wurden:

tshark-n-r challenge1.cap-x frame.number == 11

11 0.711825 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP Segment einer zusammengesetzt PDU]

0000 00 50 8b EA 20 ab 00 b0 d0 20 7d e3 08 00 45 00. P.. .... } ... E.

0010 01 a7 37 47 40 00 40 06 73 8b 21 0c f7 04 94 4e .. 7G @. @. S..! ... N

0020 f7 0a 00 50 69 2a 3a 88 39 cd 6a 97 b9 4c 80 19 ... Pi *:.. 0,9 j. L..

0030 19 20 8c d4 00 00 01 01 08 0a 3d 76 0e d3 00 EC. ... ... ..= V ....

0040 48 4b 48 54 54 50 2f 31 2e 31 20 34 30 34 20 4e HKHTTP/1.1 404 N

0050 6f 74 20 46 6f 75 6e 64 0D 0A 44 61 74 65 3a 20 ot gefunden .. Datum:

0060 54 75 65 2c 20 32 35 20 4a 75 6e 20 32 30 30 32 Tue, 25 Juni 2002

0070 20 30 30 3a 33 34 3a 35 38 20 47 4d 54 0d 0a 53 00.34.58 GMT .. S

0080 65 72 76 65 72 3a 20 41 70 61 63 68 65 0d 0A 43 erver: Apache .. C

0090 6f 6e 6e 65 63 74 69 6f 6e 3a 20 63 6c 6f 73 65 nschluss: close

00A0 0d 0A 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 .. Content-Type:

00B0 74 65 78 74 2f 68 74 6d 6c 3b 20 63 68 61 72 73 text / html; chars

00C0 65 74 3d 69 73 6f 2d 38 38 35 39 2d 31 0D 0A 0D et = iso-8859 bis 1 ...

00d0 0a 3c 21 44 4f 43 54 59 50 45 20 48 54 4d 4c 20. <! DOCTYPE HTML

00e0 50 55 42 4c 49 43 20 22 2d 2f 2f 49 45 54 46 2f PUBLIC "- / / IETF /

00f0 2f 44 54 44 20 48 54 4d 4c 20 32 2e 30 2f 2f 45 / DTD HTML 2.0 / / E

0100 4e 22 3e 0a 3c 48 54 4d 4c 3e 3c 48 45 41 44 3e N ">. <HTML> <HEAD>

0110 0a 3c 54 49 54 4c 45 3e 34 30 34 20 4e 6f 74 20. <TITLE> 404 Not

0120 46 6f 75 6e 64 3c 2f 54 49 54 4c 45 3e 0a 3c 2f Found </ TITLE>. </

0130 48 45 41 44 3e 3c 42 4f 44 59 3e 0a 3c 48 31 3e HEAD> <BODY>. <H1>

0140 4e 6f 74 20 46 6f 75 6e 64 3c 2f 48 31 3e 0a 54 Nicht Found </ H1>. T

0150 68 65 20 72 65 71 75 65 73 74 65 64 20 55 52 4c er angeforderte URL

0160 20 2f 63 66 69 64 65 2f 41 64 6d 69 6e 69 73 74 / CFIDE / Administ

0170 72 61 74 6f 72 2f 73 74 61 72 74 73 74 6f 70 2e rator / StartStopp.

0180 68 74 6d 6c 20 77 61 73 20 6e 6f 74 20 66 6f 75 html nicht fou

0190 6e 64 20 6f 6e 20 74 68 69 73 20 73 65 72 76 65 nd auf dieser dienen

01a0 72 2e 3c 50 3e 0a 3c 2f 42 4f 44 59 3e 3c 2f 48 r. <P>. </ BODY> </ H

01b0 54 4d 4c 3e 0a 00 03 00 07 TML> ... ..

So die Antwort auf die Angreifer auf die Frage, "Ist die Datei auf dem Server befindet, ist in jedem Paket des Servers an den Client nach dem Reset-Pakete ausgegeben wurden beantwortet?. Nun stellt sich die Frage, hat der Angreifer sehen, diese Informationen?

Wenn Sie die Reset-Paket an den Angreifer geschickt wurde, sollte die Reset der TCP-Sitzung getötet haben. Dies bedeutet, dass, wenn diese Daten angekommen, der empfangende Port (TCP/26922) sollten in einem geschlossenen Zustand gewesen sein. Wäre dies tatsächlich wahr gewesen, würde ich erwarten, um zu sehen, ein Reset / ACK auf dem Rückweg von dem Angreifer das System sagt uns, dass TCP/26922 ist jetzt geschlossen. Wir sehen nie die Pakete.

Warum also nicht den entfernten Port zu schließen? Die Reset-Paket gültig ist, so sollte es die Sitzung beendet haben. Eine versierte Angreifer wird ein Paket-Sniffer im Hintergrund laufen, während Sie ihren Angriff. Es ist möglich, dass der Angreifer herausgefunden haben, was los war und einfach erstellt eine Firewall-Regel auf ihren Angriff System Herausfiltern aller eingehenden Reset-Pakete. Dies würde ihr Werkzeug erlaubt haben, um weiter funktionieren. Auch ohne die Firewall-Regeln ihre Paket-Sniffer würde die Antworten, die sie suchen, enthalten. So gibt es eine sehr gute Chance, der Angreifer hat, was wir sind anfällig für rechnete, trotz der Tat ein NIPS ist der Schutz des Netzwerks.

Warum hat die Web-Server ignorieren Sie die Reset-Paket?

Unsere letzte Frage ist, warum hat die Web-Server ignorieren Sie die Reset-Paket von der NIPS geschickt. Dies führt zu zwei Problemen:

  • Die Info der Angreifer wollte sich weiter austreten
  • Wenn der Angreifer mehrere Datei-Sonden konnten sie füllen die Session-Tabelle auf dem Webserver

Der zweite Punkt ist ein wenig beängstigend, weil es eigentlich die NIPS wodurch der Schutz vor DoS-Angriff wäre nur durch das Töten der einen Seite der Verbindung korrekt. Also selbst wenn wir gepatcht wurden und up to date, Lieferanten Gang, den wir bezahlt Geld für enden würde, tötet unsere Web-Server. Gee Ich hasse es, wenn ich Geld, um DoS mir zu verbringen. ;)

Nehmen wir noch einen Blick auf die Reset-Pakete:

tshark-n-r challenge1.cap frame.number == 6 oder frame.number == 7

6 0.031319 12.33.247.4 -> 148.78.247.10 TCP 80> 26922 [RST, ACK] Seq = 1 Ack = 222 Win = 0 Len = 0

7 0.031385 148.78.247.10 -> 12.33.247.4 TCP [TCP ACK verloren Segment] 26922> 80 [RST, ACK] Seq = 1 Ack = 222 Win = 0 Len = 0

Beachten Sie, dass tshark sagt uns Paket 7 ist ein verlorener Segment. In anderen Worten, tshark sagen uns, dass die TCP-Sequenznummer nicht innerhalb des Fensters den Host erwartet. Ein Blick auf die Reihenfolge und bestätigen Zahlen erklärt, warum. Die Werte sind identisch mit denen im Paket 6. Sie können aus dem letzten Beitrag nicht vergessen, dass Paket 6 und 7 hatten auch die gleiche IP-ID-Wert (45.298).

So scheint es, dass hier was passiert ist:

  • Client eine HTTP-Angriff auf unsere Web-Server
  • NIPS erkannt Angriff
  • NIPS schickte eine gültige TCP-Reset, um den Angreifer, um die Sitzung zu töten
  • NIPS vertauscht die Quell-und Ziel-IP-Adressen im Paket, neu berechnet die CRC, und dann an der gleichen wieder auf den Web-Server
  • Web-Server ignoriert das zurückgesetzt, da sie nicht enthalten ein akzeptables Sequenznummer

Vielleicht fragen Sie sich: "Wie hat der Verkäufer zu verpassen?". Meine beste Vermutung ist, dass der Verkäufer einige simulierte Angriffe liefen, die Angriffs-Tool nicht zeigen, sie anfällig Dateien, so dass sie davon ausgegangen war alles OK arbeitet. In anderen Worten, ein Anbieter, der ein Produkt zu Netzwerken auf den Draht zu schützen geschaffen nie die Mühe gemacht zu schauen, was ihr Produkt tatsächlich tat auf den Draht zu suchen. Hummm ...

Bonus Frage

OK, wenn Sie Spaß mit diesem, hier ist ein Bonus-Frage zu beantworten, die endgültig beweisen Sie Ihre uber-Aussenseiter-Status auf dem Gipfel des geheimen Pyramide:

Nehmen wir statt eine Stateful Inspection Firewall zwischen diesem Subnetz und den Angreifer. Will der Angreifer noch in der Lage sein, die Antworten mit einem Packet-Sniffer zu sehen?

Ich werde nach der Antwort nächste Woche.

Keine Kommentare »

Posted in 2-Alarm , Packet Decoding

Tags:

Tshark Challenge - Hinweise 4

8. Oktober 2009

In meinem letzten Beitrag haben wir festgestellt, dass das Client-System war wahrscheinlich läuft eine Art Werkzeug, um auf bekannte gefährdete Dateien Sonde. Wir haben immer noch die Reset-Pakete jedoch zu erklären, als auch, warum der Server war, sie zu ignorieren.

Im Moment haben wir nicht einmal wissen, wo diese Paketerfassung in Bezug auf die beiden Endpunkte wurde. Ich werde tshark laufen mit dem "T-fields"-Schalter zum Ausdrucken der TTL Information. Durch die Analyse der TTLs, sollten wir in der Lage sein zu bestimmen, wo wir im Verhältnis zu dem Client und dem Server Sniffing. Ich bin auch zum Ausdrucken der IP-IDs, um zu sehen, ob es irgendwelche Auffälligkeiten im Paket bestellen sind.

Hier ist die Befehls-und Ausgang:

tshark-r challenge1.cap-T Felder-e frame.number-e ip.src-e tcp.srcport-e ip.ttl-e ip.id

1 148.78.247.10 26922 49 0x2a6b

2 12.33.247.4 80 64 0 × 0000

3 148.78.247.10 26922 49 0x2a95

4 148.78.247.10 26922 49 0x2a96

5 12.33.247.4 80 64 0 × 3743

6 12.33.247.4 80 255 0xb0f2

7 148.78.247.10 26922 255 0xb0f2

8 12.33.247.4 80 64 0 × 3744

9 12.33.247.4 80 64 0 × 3745

10 12.33.247.4 80 64 0 × 3746

11 12.33.247.4 80 64 0 × 3747

12 12.33.247.4 80 64 0 × 3748

13 12.33.247.4 80 64 0 × 3749

14 12.33.247.4 80 64 0x374a

15 12.33.247.4 80 64 0x374b

16 12.33.247.4 80 64 0x374c

17 12.33.247.4 80 64 0x374d

148.78.247.10 ist der Client. Wir wissen, dass, weil es die Sitzung initiiert hat und dessen Kommunikation über eine obere Quell-Port. 12.33.247.10 ist unser HTTP-Server kommuniziert über Port 80.

In Paket 1 sehen wir die Client verfügt über eine TTL von 49 Jahren. Der nächste Start TTL Übereinstimmung für ein bekanntes Betriebssystem ist 64, so dass dies sagt uns der Kunde ein Linux-, UNIX-oder Mac-System sitzen 15 Hops entfernt. In Paket 2 sehen wir den Server mit einem TTL-Wert von 64, also muss es einer der zuvor genannten Betriebssysteme sitzen auf dem lokalen Netzwerk befinden. Also, wir sind auf dem gleichen Kollision Domäne wie der Server, sondern saß 15 Hops vom Client.

Es gibt ein Problem jedoch. Schauen Sie sich Pakete 6 und 7. Hier sehen wir die TTL beider Systeme ändern zu 255. Ein OS wird sich nie ändern ist es TTL während einer Sitzung, so sieht das sehr suspekt. Darüber hinaus haben wir bereits festgestellt, dass der Kunde sitzt 15 Hops von uns entfernt. 255 ist die größtmögliche TTL-Wert als das TTL-Feld nur ein einziges Byte (Byte 8 im IP-Header). Also auch wenn die Quell-IP-Adresse Ansprüche auf den Remote-Client sein, es gibt keine Möglichkeit das Paket könnte überall, sondern aus dem lokalen Netzwerk stammen. Wenn das Paket einen oder mehrere Router überquert hatte, würde der TTL-Wert niedriger sein.

Die IP-ID-Informationen nicht richtig entweder zu suchen. In den ersten drei Pakete vom Client sehen wir die IP-ID-Werte 0x2a6b (10859), 0x2a95 (10.901) und 0x2a96 (10.902). Dies sagt uns der Kunde möglicherweise mit einer +1 inkrementelle IP ID, wir hatten einfach nicht sehen, 42 der Pakete zwischen dem ersten und zweiten Paket übertragen. Die nächste IP ID sehen wir aus der Client 0xb0f2 (45.298). OK, es sei denn, wir über 34.000 Pakete vermisst, ist diese IP-ID nicht jive.

Beachten Sie die obige Analyse wäre nur theoretisch gäbe es nicht die uneinheitliche TTL-Werte. Mit nur drei Pakete zu betrachten, können wir nicht genau identifizieren die IP-ID zu erhöhen. Es ist auch möglich, aber sehr sehr unwahrscheinlich, dass die IP-ID Inkrement völlig zufällig ist und das System nur zufällig zwei inkrementellen IP-IDs, einer nach dem anderen zuweisen. Dennoch verbinden die TTL und IP-ID-Informationen zusammen und sie zeigen, dass dieses letzte Paket konnte nicht aus dem gleichen System stammen.

Wir haben mehrere IP-ID-Daten vom Server zu arbeiten, also nehmen wir mal einen Blick auf die. Die IDs sind:

  • 0 (0)
  • 0 × 3743 (14147)
  • 0xb0f2 (45298)
  • 0 × 3744 (14148)
  • 0 × 3745 (14149)
  • 0 × 3746 (14150)
  • 0 × 3747 (14151)
  • 0 × 3748 (14152)
  • 0 × 3749 (14153)
  • 0x374a (14154)
  • 0x374b (14155)
  • 0x374c (14156)
  • 0x374d (14157)

Werfen Sie einen Blick auf die dritte aufgeführten IP-ID, die vom Paket-6 in der Spur ist. Beachten Sie, dass alle anderen IP-IDs inkrementelle +1 sind, aber das IP ID nicht angehört. In der Tat können wir zeigen, dass der Server erhöht sie IP ID um +1 und das ist gibt es keine Möglichkeit dieses Paket vom Server stammen.

Humm. Ich frage mich, ob dieser Verdacht Pakete Line-Up mit den seltsamen setzt sahen wir:

tshark-r challenge1.cap-T Felder-e frame.number-e ip.src-e tcp.srcport-e ip.ttl-e ip.id-e tcp.flags.reset

1 148.78.247.10 26922 49 0x2a6b 0

2 12.33.247.4 80 64 0 × 0000 0

3 148.78.247.10 26922 49 0x2a95 0

4 148.78.247.10 26922 49 0x2a96 0

5 12.33.247.4 80 64 0 × 3743 0

6 12.33.247.4 80 255 0xb0f2 1

7 148.78.247.10 26922 255 0xb0f2 1

8 12.33.247.4 80 64 0 × 3744 0

9 12.33.247.4 80 64 0 × 3745 0

10 12.33.247.4 80 64 0 × 3746 0

11 12.33.247.4 80 64 0 × 3747 0

12 12.33.247.4 80 64 0 × 3748 0

13 12.33.247.4 80 64 0 × 3749 0

14 12.33.247.4 80 64 0x374a 0

15 12.33.247.4 80 64 0x374b 0

16 12.33.247.4 80 64 0x374c 0

17 12.33.247.4 80 64 0x374d 0

Ah ha! Also, wenn wir die Pakete mit dem seltsamen TTL und IP ID-Werte aussehen, das waren die seltsamen Reset-Pakete während der Sitzung übermittelt.

Es sieht für mich wie ein drittes System wird in das Gespräch springen, um die Reset-Pakete zu übertragen. Da diese seltsame Pakete eine TTL von 255 haben, wissen wir, es muss auf demselben Kollisionsdomäne wie, wo wir sind Sniffing werden. Da es auf dem gleichen Kollisionsdomäne ist, kann der Ethernet-Header-Informationen hilfreich sein:

tshark-r challenge1.cap-T Felder-e frame.number-e eth-e tcp.flags.reset

1 Ethernet II, Src: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab), Dst: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3) 0

2 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3), Dst: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab) 0

3 Ethernet II, Src: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab), Dst: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3) 0

4 Ethernet II, Src: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab), Dst: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3) 0

5 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3), Dst: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab) 0

6 Ethernet II, Src: D-Link_8f: e0: 0c (00:50: ba: 8f: e0: 0c), Dst: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab) 1

7 Ethernet II, Src: D-Link_8f: e0: 0c (00:50: ba: 8f: e0: 0c), Dst: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3) 1

8 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3), Dst: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab) 0

9 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3), Dst: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab) 0

10 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3), Dst: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab) 0

11 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3), Dst: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab) 0

12 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3), Dst: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab) 0

13 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3), Dst: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab) 0

14 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3), Dst: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab) 0

15 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3), Dst: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab) 0

16 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3), Dst: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab) 0

17 Ethernet II, Src: DellComp_20: 7d: e3 (00: b0: d0: 20.07 d: e3), Dst: HewlettP_ea: 20: ab (00:50:8 b: ea: 20: ab) 0

So, wenn der Client aus dem Internet kommt, durchläuft es ein HP-System als entweder einen Router oder eine Firewall. Unser Web-Server auf Dell-Hardware läuft. Beachten Sie unsere zurückgesetzt (Pakete 6 und 7) sind beide durch das gleiche System mit einem D-Link NIC generiert.

Warum haben die D-Link-System versuchen, die Sitzung zu töten? Dies geschah kurz nach den Client gesendet die verdächtige Datei anfordern. Es sieht für mich wie die D-Link System ist eigentlich ein einziges geschliffen Intrusion Prevention System (IPS). Wenn ein Angriff erkannt wird, versucht das IPS den Angriff durch die Übertragung von Reset-Pakete an beiden Enden der Verbindung zu verhindern.

Aber wir haben noch einige unbeantwortete Fragen. War der Angriff erfolgreich und warum der Server scheinen die IPS Versuch, die Sitzung zu töten ignorieren?

Biegen Sie in die nächste Episode, um herauszufinden.

Keine Kommentare »

Posted in 2-Alarm , Packet Decoding

Tags:

Analyse-Pakete mit tshark

1. Oktober 2009

In einem früheren Beitrag habe ich diskutiert, wie man die Display-Ausgabe in Anpassung tshark . Die Post generiert ein großes Interesse, so habe ich beschlossen, einige zusätzliche Informationen über die Verwendung tshark Pakete entschlüsseln hinzuzufügen. Dieser Beitrag wird vorausgesetzt, dass das eine Verbindung mit oben zu lesen.

Warum anstelle von tcpdump / WinDump tshark?

Viele alte Zeit Decoder schwören tcpdump , und es ist Windows-Pendant WinDump . Beide sind großartige Werkzeuge, aber sie haben sich ein wenig altmodisch. Während Patches immer noch von Zeit zu Zeit veröffentlicht werden, wenig getan wurde, zu aktualisieren oder erweitern ihre Decodierfähigkeit. Wireshark auf der anderen Seite, so gut es Tools wie tshark ist enthalten, gehören dekodieren Unterstützung für Hunderte von Protokollen und die Liste wächst die ganze Zeit. Obwohl Sie sicherlich analysieren können Pakete ohne Decoder, machen sie den Prozess gehen viel schneller.

Warum tshark statt Wireshark?

Wireshark ist ein großes Werkzeug, wenn Sie dabei eine eingehende Analyse Nutzlast sind. Es kann ein wenig langweilig aber sein, wenn Sie ein bestimmtes Feld über mehrere Pakete folgen wollen. Zum Beispiel sagen wir, wir wollen die TCP Sequence Number Inkrement über mehrere Pakete zu beobachten. Mit Wireshark, würde ich die Sequenz-Nummer Lage im mittleren Bereich und Seite durch jedes Paket beachten. Da gibt es keine Möglichkeit, Line-Up der Wert über mehrere Pakete, bin ich gezwungen, vorherigen Werte erinnern, wenn die Durchführung meinen Berechnungen. Mit tshark können wir jedoch etwas tun:

tshark-n-T Felder-e ip.src-e tcp.seq-e tcp.len

64.111.96.38 0 0

64.111.96.38 1 0

64.111.96.38 1 363

64.111.96.38 364 1448

64.111.96.38 1812 1448

64.111.96.38 3260 1448

64.111.96.38 4708 1448

64.111.96.38 6156 1448

64.111.96.38 7604 1448

64.111.96.38 10500 310

64.111.96.38 9052 1448

64.111.96.38 10810 0

Denken Sie daran, dass die TCP Sequence Number (das zweite Feld) auf die Größe der Nutzlast (das dritte Feld) sollte basierend erhöhen. Beachten Sie, dass Pakete, 10 und 11, wo in der falschen Reihenfolge empfangen. Dies könnte bedeuten, gibt es mehrere Wege zur Verfügung zwischen unserer Lage und der identifizierten IP-Adresse. Während Wireshark würde zeigen, uns diese Informationen sowie, in dieser Ansicht ist es ein bisschen einfacher, um den Fluss zu folgen.

Mehr über die Anzeige Felder

Wie in meinem früheren Post diskutiert, ebenso wie oben gezeigt, die "-T"-Schalter verwendet werden, um die Ausgabe angezeigt zu manipulieren. Sie können aus XML-, Postscript-oder Text wählen. Die meisten nützliche Option ist "Felder" wie können Sie damit auswählen, welche spezifischen Felder, die Sie drucken wollen aus. Wie oben gezeigt, kann das "-e"-Schalter dann verwendet, um die Felder, die Sie anzeigen möchten identifizieren. Die vollständige Liste der Filter finden Sie hier . Eine nette Spickzettel der am häufigsten verwendeten Werte gefunden werden kann hier .

Wenn Sie ein bestimmtes Protokoll zu definieren, wird tshark zeigt einige der wichtigsten Felder aus, die Header. Zum Beispiel, um nur den Ethernet-Header aussehen:

tshark-T Felder-e eth

Ethernet II, Src: TyanComp_56: 3b: 14 (00: e0: 81:56:3 b: 14), Dst: Dell_d1: zB: ef (00.12.03 f: d1: zB: ef)

Ethernet II, Src: TyanComp_56: 3b: 14 (00: e0: 81:56:3 b: 14), Dst: Dell_d1: zB: ef (00.12.03 f: d1: zB: ef)

Ethernet II, Src: TyanComp_56: 3b: 14 (00: e0: 81:56:3 b: 14), Dst: Dell_d1: zB: ef (00.12.03 f: d1: zB: ef)

Beachten Sie die Art und CRC-Felder werden nicht angezeigt, da sie nicht als "interessant" als Quelle und Ziel-MAC-Adresse. Wir müssten diese Felder genau zu definieren (ip.type und ip.trailer), wenn wir sie sehen wollen.

Ein Nebeneffekt des Drucks Felder ist, dass tshark wird eine leere Zeile für jedes Paket, das keine der angegebenen Feld hinzuzufügen. Dies kann ein Schmerz bei der Analyse von HTTP-Pakete als nicht jedes Paket einen URI enthält. Ein einfacher Weg, um dies zu reinigen, ist eine Pipe durch grep. Zum Beispiel:

tshark-T Felder-e http.request.uri | grep-v "^ $"

/

/ Styles.css

/ Templates / classic / images / starsnstripes.gif

/ Templates / classic / images / unionjack.gif

/ Templates / classic / images / amazon.header.gif

/ C_images/2009/05/07/71090.2.jpg

In meinem letzten Beitrag habe ich diskutiert grep sowie wo man eine kostenlose Version für Windows zu greifen. Die oben genannten Befehl grep verwendet die "-v"-Schalter, um alle Zeilen, die keine dem angegebenen Wert entsprechen. "^ $" Definiert eine leere Zeile. Das obige Befehl grep filtert alle Leerzeilen.

Weitere Anzeigeoptionen

Tshark hat eine Reihe anderer nützlicher Display-Optionen. Zum Beispiel können Sie Header am Anfang der Ausgabe zu drucken:

tshark-n-T Felder-e ip.src-e ip.dst-E header = y

ip.src ip.dst

64.111.96.38 12.5.200.100

64.111.96.38 12.5.200.100

64.111.96.38 12.5.200.100

Wenn Sie zum Importieren der Daten in eine Tabellenkalkulation oder Datenbank planen, können Sie definieren, welche Zeichen zwischen den Feldern zu verwenden:

tshark-T Felder-e ip.src-e ip.dst-e tcp.dstport-E header = y-E separator =;

ip.src; ip.dst; tcp.dstport

64.111.96.38; 12.5.200.100; 34831

64.111.96.38; 12.5.200.100; 34831

64.111.96.38; 12.5.200.100; 34831

Packet Statistiken

Tshark verfügt über eine solide statistische Funktion als gut. Wenn Sie viele Dateien verarbeiten müssen, ist es manchmal helfen, mit Blick auf die Roh-Statistik zu beginnen. Das "z"-Schalter wird benutzt, um die Statistiken, die Sie analysieren möchten angeben. Normalerweise werden diese am Ende der Dekodierung Informationen gedruckt werden, aber wenn man das "-q" verwenden Schalter nur die Stats gedruckt werden. Hier ein Beispiel:

C: \ Test> tshark-q-z http, stat,-z http-, Baum-r test.cap

================================================== =============

HTTP / Packet Zählerwert Rate Prozent

-----------------------

Insgesamt HTTP Packets 64915 0.048999

HTTP-Request-Packets 459 0.000346 0,71%

GET 24 0.000018 5,23%

HEAD 433 0.000327 94,34%

OPTIONS 2 0.000002 0,44%

HTTP-Response-Pakete 448 0.000338 0,69%

??: Broken 0 0.000000 0.00%

1xx: Informationelle 0 0,000000 0.00%

2xx: Erfolg 12 0,000009 2,68%

200 OK 12 0,000009 100,00%

3xx: Redirection 0 0,000000 0.00%

4xx: Client Error 436 0,000329 97.32%

404 Not Found 432 0,000326 99.08%

403 Forbidden 4 0,000003 0,92%

5xx: Server Error 0 0,000000 0.00%

Andere HTTP Packets 64008 0.048314 98,60%

================================================== =============

================================================== =============

HTTP-Statistik

* HTTP Status Codes in Antwortpakete

HTTP 200 OK

HTTP 403 Forbidden

HTTP 404 Not Found

* Liste der HTTP-Request-Methoden

GET 24

OPTIONEN 2

HEAD 433

================================================== =============

Ein paar Dinge bleiben in dieser Ausgabe. Zunächst haben wir vier 403-Fehler anzeigt, dass jemand versucht hat, etwas, das sie nicht hatten Berechtigung für den Zugriff. Auch aus von 459 HTTP-Anfragen wurden 432 von ihnen für nicht vorhandene Dateien. Wir sehen auch eine Menge von "HEAD" Anfragen, die ein Proxy sein könnte, oder könnte ein Angreifer versuchen, um nicht auf die Web-Server-Zugriff protokolliert halten. Offensichtlich diesem Capture-Datei enthält einige vermuten, Verkehr, weitere Untersuchungen rechtfertigt.

Tshark kann sogar zu produzieren allgemeine Durchsatz Statistiken, wenn Sie sie benötigen. Dies ist eine hervorragende Möglichkeit, für DoS-Angriffe zu überprüfen:

tshark-q-z io, stat, 10-r test.cap

================================================== =============

IO-Statistik

Interval: 10,000 Sek.

Column # 0:

| Column # 0

Time | Bilder | bytes

000.000-010.000 254 145081

010.000-020.000 145 80003

020.000-030.000 125 65527

030.000-040.000 4 264

================================================== =============

Hinweis tshark druckt die Rahmen-und Byte-Anzahl für jedes Intervall angegeben, in Sekunden angegeben. Das einzige Problem ist, dass wenn Sie Paketanalyse off des Drahtes sind, stats nicht angezeigt werden, bis die Aufnahme endet.

Exec Zusammenfassung

Tshark ist ein überaus fähiger Paket-Analyse-Tool, das es Kollegen tcpdump und WinDump übertroffen hat. Kombinieren Sie die umfangreichen Decodierfähigkeit zusammen mit dem flexiblen Ausgabe angezeigt und tshark geworden das Werkzeug der Wahl für viele Paket-Decoder.

Keine Kommentare »

Posted in 2-Alarm , Network Security , Packet Decoding

Tags:

Passiv Fingerprinting VMware Virtual Systems

15. September 2009

Es gibt einige hervorragende Arbeiten auf, wie Sie erkennen, ob ein Betriebssystem als VMware Image des Gasts läuft geschrieben worden. Automatisierte Tools wurden sogar freigelassen, um den Prozess zu beschleunigen. Alle übernehmen jedoch, dass Terminal oder Eingabeaufforderung zugreifen erforderlich ist, um die Erkennung durchzuführen. Nur wenige Menschen wissen, dass es möglich ist, passiv zu erkennen VMware Gast ohne jede Ebene des Netzzugangs. In der Tat, wenn Sie wissen, worauf zu achten ist, können Sie sogar feststellen, welche Version von VMware ist Gastgeber der virtuellen System.

Passive Fingerprinting

Passive Fingerprinting ist eine Technik, wo durch eine Remote-Betriebssystem durch die Nuancen in der IP-Pakete, die er produziert identifiziert werden kann. Zum Beispiel die Nutzlast des Echo-Request-Pakete sind ziemlich einzigartig Betriebssystem Betriebssystem. In einem früheren Post I diskutiert, wie verschiedene Betriebssysteme unterschiedliche Zeit nutzen, um Werte zu leben. Durch die Analyse dieser Variationen in der IP-Pakete, können Sie eine ziemlich genaue Aufgabe der Identifizierung der Source-Betriebssystem. In der Tat oft Sie können sogar sehen, die Patch-Reversion-Niveau des Systems.

VMware virtuelle Systeme

VMware unterstützt zwei Modi für den Anschluss eines Gast-Betriebssystem zu einem Netzwerk. Sie können NAT sie hinter dem Gastgeber, oder verbinden Sie es im Bridging-Modus. Viele Leute denken, dass Bridging-Modus gibt dem Gast-Betriebssystem direkten Zugriff auf die Netzwerkkarte, aber sie vergessen, dass VMware sitzt immer noch zwischen den Gast-Betriebssystem und dem Host-System die Treiber der Netzwerkkarte ausgeführt werden. Es ist nicht ungewöhnlich für diese Schicht, um Änderungen in der IP-Pakete, bevor sie sie auf den Draht zu machen. Also, wenn Sie wissen, welche Veränderungen zu suchen, können Sie erkennen, wenn VMware-Software ist zwischen Betriebssystem und dem lokalen Netzwerk sitzen.

VMware macht mehrere Änderungen an den IP-Datenstrom. In diesem Beitrag werden wir nur bei zwei von diesen Änderungen (Fenstergröße und-Skalierung) schauen, und ich werde es dem Leser überlassen, zu versuchen und die anderen. Darüber hinaus werden verschiedene Versionen von VMware ändern Sie die IP-Datenstrom in unterschiedlicher Weise. Wenn Sie wissen, welche Änderungen für jede Version sind, können Sie ermitteln Sie die Version der VMware sitzt zwischen dem Gast-Betriebssystem und dem Netzwerk.

Fenstergröße und Fensterskalierung

TCP verwendet Fenstergröße zu ermitteln, wie viele Daten, bevor ein Remote-System muss Pause übertragen werden können, und warten auf eine Bestätigung. Zum Beispiel, wenn "System A" sagt, "System B", "Fenster size = 1400", "System B" darf nur unter einem in voller Größe Ethernet-Paket zu senden, bevor er warten muss. Nach dem 1400 Byte übertragen werden, "System B" ist nicht zulässig, keine weiteren Daten mehr senden, bis es eine Bestätigung, dass die Daten erhält von "System A". Fenstergröße wird on the fly angepasst, so "System A" kann schließlich werben "window size = 1600". Dies bedeutet, "System B" können jetzt in voller Größe Paket von einem kleinen Paket, bevor es zu Pause auf eine Bestätigung folgte. Fenstergröße ist eine Methode der Ablaufsteuerung zu helfen, sicherzustellen, dass das empfangende System nicht sehen mehr Daten, als es die Puffer verarbeiten kann.

Fenstergröße geht zurück auf die ursprüngliche Implementierung von TCP. Zum Zeitpunkt 16 Bit reserviert waren (Bytes 14 und 15 in der TCP-Header), um festzulegen, wie viele Bytes konnte vor der Pause auf eine Bestätigung übertragen werden. Das heißt, wir könnten eine maximale Fenstergröße von 65.535 Byte angeben. Das ist mehr als groß genug, um 1980-Standards, aber nicht so toll, wenn man etwa 1 Gb und schnellere Netzwerke sprechen. In den frühen 90-Fenster-Skalierung wurde als TCP-Option hinzugefügt. Fensterskalierung wird nur in den ersten TCP-Paket durch ein System (SYN-oder SYN / ACK-Paket) geschickt beworben und ist ein Multiplikator für die ausgeschriebene Fenstergröße. Angenommen, eine Fenstergröße von 1400 Bytes. Wenn das Fenster Skala 3, würde der Mathematik werden:

(2 * 2 * 2) * 1.400 = 11.200

Wenn das Fenster Skala 4, wird die Mathematik:

(2 * 2 * 2 * 2) * 1.400 = 22.400

So Window Scaling erlaubt es uns, jetzt werben viel größere Fenstergrößen. Diese Erklärung ist recht simpel, aber sollte dem Leser eine gute Vorstellung davon, wie Fenstergröße und Maßstab funktioniert. Für weitere Informationen siehe RFC 1323 oder die TCP Wiki .

Backtrack 3 Final als Stand-alone-Host

Hier ist eine SYN / ACK Antwort auf eine Verbindungsanfrage durch einen Backtrack 3-System (Linux 2.6.21.5 kernel) läuft auf einem dedizierten Host zurückgegeben:

> IP (tos 0 × 0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), Länge 60) 192.168.100.4.80> 192.168.100.50.44943: S, cksum 0 × 9552 (richtige ), 2760872392:2760872392 (0) ack 4071399005 win 5792 <mss 1460,sackOK,timestamp 5362662 198395,nop, wscale 5>

Beachten Sie das erste Fenster Skala ist 5, was bedeutet, das aktuelle Fenster eine Größe von 32 * 5792 = 185.344. Das ist ziemlich üblich, dass Linux-Systemen mit einer post 2.6.17 Kernel.

Jetzt werfen wir einen Blick darauf, wie die Größe des Fensters für Backtrack 3 wird erhöht:

[Root @ fubar ~] # tshark-n-T Felder-e ip.src-e tcp.window_size-e tcp.options.wscale_val dst host 192.168.100.50

Capturing auf eth0

192.168.100.4 5792 5

192.168.100.4 245

192.168.100.4 336

192.168.100.4 426

192.168.100.4 517

192.168.100.4 607

192.168.100.4 698

192.168.100.4 788

192.168.100.4 879

192.168.100.4 969

192.168.100.4 1060

Früher habe ich tshark zur Säuberung der Ausgang, so dass wir auf den Feldern wir eigentlich über Pflege konzentrieren konnte. Die oben genannten Trace ist eine große Datentransfers zu 192.168.100.4 (BT3 stand alone) über TCP/80, wie im obigen tcpdump Spur zu zeigen. Beachten Sie, dass wir ziemlich deutlich erkennen, wie die Größe des Fensters über die Daten Sitzung erhöht wurde.

Backtrack 3 Final, Gast unter Windows XP Workstation

Werfen wir also einen Blick auf die Fenstergröße und-Skalierung betroffen, wenn das Betriebssystem hinter VMware Sitzen erhalten. In diesem Test lief ich BT 3 als Gast-Betriebssystem auf einem Windows XP-Workstation-Host. Früher habe ich VMware Player 2.5.3 und schrieb eine eigene VMX-Datei auf der BT 3 iso laufen.

Hier ist eine erste SYN / ACK-Paket:

> IP (tos 0 × 0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), Länge 60) 192.168.100.7.80> 192.168.100.50.35245: S, cksum 0x670d (richtig), 3795217952:3795217952 (0) ack 4108648760 win 5792 <mss 1460,sackOK,timestamp 5210512 208486,nop, wscale 4>

Beachten Sie, dass während die ursprüngliche Fenstergröße entspricht dem Stand-alone-BT 3-System, VMware hat das Window Scaling von 5 (32x) bis 4 (16x) gesunken.

Hier ist der Strom von Paketen durch den Gast-System zurückgegeben:

[Root @ fubar ~] # tshark-n-T Felder-e ip.src-e tcp.window_size-e tcp.options.wscale_val dst host 192.168.100.50

Capturing auf eth0

192.168.100.7 5792 4

192.168.100.7 490

192.168.100.7 671

192.168.100.7 852

192.168.100.7 1033

192.168.100.7 1214

192.168.100.7 1395

192.168.100.7 1576

192.168.100.7 1757

192.168.100.7 1938

192.168.100.7 2119

Beachten Sie, dass nach dem ersten Paket der ausgehandelten Fenster größer angezeigt, aber wenn Sie Faktor in das Fenster Skala Multiplikator der gesamten Fenstergröße endet als etwas kleiner als BT 3, wenn es auf einem dedizierten System ausgeführt wird. Nicht allzu überraschend als virtuelle Systeme in der Regel langsamer als dedizierte Systeme, aber wir haben nur zwei Unterschiede, die wir suchen, um festzustellen, ob der Host stand-alone oder als Gast virtuelle Bild kann getaggt.

Backtrack 3 Final, Gäste auf Fedora 11

Natürlich ist die große Frage ist ", war die Größe des Fensters verändern sich durch den Windows XP-Host oder VMware?". VMware umgeht die Windows-IP-Stack bei der Übertragung auf den Draht, so dass die Host-Betriebssystem sollte keine Auswirkungen auf den Paket-Stream haben. Um dies zu überprüfen, lassen Sie uns den gleichen Test mit der gleichen Version des VMware Player, nur diesmal verwenden wir Linux als Host-Betriebssystem werde es versuchen. Hier ist das SYN / ACK:

> IP (tos 0 × 0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), Länge 60) 192.168.100.13.80> 192.168.100.50.43363: S, cksum 0x6ef7 (richtig), 3423175369:3423175369 (0) ack 483782889 win 5792 <mss 1460,sackOK,timestamp 579990 366817,nop, wscale 4>

Hier ist der Strom der Pakete von TCP/80 auf dem Gast-BT 3-System zurück:

[Root @ fubar ~] # tshark-n-T Felder-e ip.src-e tcp.window_size-e tcp.options.wscale_val dst host 192.168.100.50

Capturing auf eth0

192.168.100.13 5792 4

192.168.100.13 490

192.168.100.13 671

192.168.100.13 852

192.168.100.13 1033

192.168.100.13 1214

192.168.100.13 1395

192.168.100.13 1576

192.168.100.13 1757

192.168.100.13 1938

192.168.100.13 2119

Beachten Sie die Ergebnisse sind identisch mit, wenn BT3 war das Gast-Betriebssystem auf Windows XP. Während also diese Methode nicht identifizieren wird das Host-Betriebssystem verwendet wird, können wir konsequent entscheiden, ob BT3 auf einem dedizierten System oder als Gast via VMware läuft. Während es durchaus möglich ist, auf ein spezielles System zu modifizieren, um erscheinen zu einem virtuellen Gast zu sein, bewirkt das Gegenteil nicht zu sein scheinen machbar.

Exec Zusammenfassung

Dadurch, dass eine eingehende Verständnis der IP und die Nuancen von verschiedenen Betriebssystemen erzeugt, ist es möglich, festzustellen, ob ein Betriebssystem auf einem dedizierten System oder als Gast via VMware läuft. Änderungen durch die VMware-Wrapper gemacht hinterlassen verräterische Spuren. Ein Smart-Paket weenie nutzen können, diese Hinweise auf die Virtualisierungs-Status der Source-Betriebssystem zu ermitteln.

Keine Kommentare »

Posted in 2-Alarm , Packet Decoding

Tags:

Eine Hintertür zu verstecken hinter eine aktive Windows-Listening-Port

3. September 2009

Es ist eine gängige Technik. Sie vermuten, einem Ihrer Systeme kompromittiert wurde, so dass Sie laufen einen Port-Scanner gegen das System. Die Hoffnung ist, dass, wenn das System Hintertür Sie eine undokumentierte-Listening-Port zu identifizieren. Aber was, wenn ein cleverer Angreifer versteckt die Hintertür im Klartext vor Ort? Was, wenn sie die Hintertür verstecken sich hinter einen vorhandenen Port du eigentlich erwarten, dass das Lauschen auf dem System? Leider ist dies viel zu einfach zu bewerkstelligen, wenn der Host unter Windows.

Die Art, wie UNIX

Auf einem UNIX-oder Linux-System werden Listening-Ports immer exklusiv geöffnet. In anderen Worten, wenn eine E-Mail-Verfahren eröffnet TCP/25 eingehende Mail-Verbindungen zu akzeptieren, wird jede andere Anwendung, die auf TCP/25 hören Versuche erhalten eine bind-Fehler und der Zugriff verweigert werden. Der einzige Weg, den zweiten Antrag auf TCP/25 binden können, ist zum ersten kill off der Mail-Prozess mit dem Hafen. So nur eine Anwendung zu einem Zeitpunkt ist immer Zugang zu einem Socket gestattet.

Der Windows-Weg

In Windows wird exklusiven Zugang zu einer Listening-Port optional. Seine völlig legal, mehrere Anwendungen hören auf dem gleichen TCP-oder UDP-Port haben. Dies kann natürlich vereinfachen den Prozess der Einrichtung einer Hintertür hinter einer bestehenden Anwendung.

Mit Windows ist Exklusivität der Socket-Zugang tatsächlich ein Prozess, der im Laufe der Jahre hat sich weiterentwickelt. Windows 95, 98 und ME hatten eigentlich keine Möglichkeit, einen Port exklusiv zu öffnen. Es gab nichts, eine Anwendung zu tun, um ein anderes Andocken an den gleichen Abhörport verhindern könnte. Für Windows-Versionen zwischen NT und XP, ist es möglich, exklusiven Zugriff auf den Port über den SO_EXCLUSIVEADDRUSE Option Anfrage. Wenn exklusiven Zugang ist nicht ausdrücklich angeforderter jedoch ist der Standard zurückgreifen, um die Bereitstellung eines gemeinsamen Zugang.

Mit Windows 2003 und später, ist die Standard-exklusiven Zugriff auf den Port, wenn nicht beide Anwendungen, die speziell den gemeinsamen Zugriff über das SO_REUSEADDR Option Anfrage. Die Ausnahme ist, dass, wenn das gleiche Konto wird verwendet, um beide Anwendungen zu starten, den gemeinsamen Zugriff noch möglich ist, es sei denn, exklusiven Zugang speziell angefordert wird. Das heißt, wenn ein cleverer Angreifer können ihre Hintertür über das System-Konto zu starten, diese erhöhte Sicherheit wird in der Regel besiegt werden.

Probieren Sie es selbst

Um zu testen, wie das funktioniert, müssen Sie eine Kopie der Windows-Version von netcat . Kopieren nc.exe in einem der Verzeichnisse in Ihrer Pfadangabe. Sobald Sie das tun, öffnen Sie eine Eingabeaufforderung und führen Sie den folgenden Befehl ein:

C: \> nc-l-P 135

Kann nicht greifen 0.0.0.0:135 mit bind

Wir haben gerade gesagt, Netcat zu hören (-l) auf TCP-Port (-p) 135. Wenn Windows das erste startet, öffnet Microsoft RPC TCP/135 mit dem SO_EXCLUSIVEADDRUSE Option. So, wenn Sie eine Anwendung (wie Netcat) versucht, auf TCP/135 hören, empfängt sie das bind error oben gezeigt. Dies ist die Art von Verhalten, das wir gerne die ganze Zeit sehen würden.

Versuchen Sie nun das Öffnen eines Ports, die nicht bereits im Einsatz:

C: \> nc-l-p 1234

Es sollte aussehen, als ob der Befehl hängen (Eingabeaufforderung nicht zurück). Dies sagt Ihnen, dass Netcat ist nun auf Port TCP/1234. Um dies zu überprüfen, öffnen Sie ein zweites Eingabeaufforderung und geben folgenden Befehl ein:

C: \> netstat-an | find "1234"

TCP 0.0.0.0:1234 0.0.0.0:0 LISTENING

Dies zeigt uns, dass Netcat ist jetzt hören auf TCP/1234 auf alle Netzwerk-Schnittstellen.

Wenn Netcat einen Port öffnet es nicht Anfrage exklusiven Zugang zum Hafen. Dies bedeutet, es ist möglich, binden Netcat zu einem bestehenden Listening-Port, der nicht bereits exklusiv geöffnet. Um dies zu testen, öffnen Sie eine dritte und vierte Eingabeaufforderung. Geben Sie den gleichen Befehl Netcat in jede, die Sie ausführen innerhalb der ersten Eingabeaufforderung. Jeder Befehl sollte ohne Fehler ausgeführt.

Bedeutet dies, Netcat hört mehrmals? Gehen Sie zurück zu dem zweiten Fenster der Eingabeaufforderung, und versuchen Sie den folgenden Befehl ein:

C: \> netstat-aon | find "1234"

TCP 0.0.0.0:1234 0.0.0.0:0 ABHÖREN 448

TCP 0.0.0.0:1234 0.0.0.0:0 ABHÖREN 3044

TCP 0.0.0.0:1234 0.0.0.0:0 ABHÖREN 3016

Wir haben in der "o" Schalter, der ausdruckt die Prozess-ID für die Anwendung Offenhalten der Listening-Port hinzugefügt. Beachten Sie, dass eine andere Instanz von Netcat verantwortlich für jede der Lauthören-Ports ist. Da Netcat nicht erfordert exklusiven Zugriff auf den Port, können wir auf den Hafen mehrfach zu hören.

So was passiert, wenn jemand versucht, den Port zu verbinden? Probieren Sie es aus und finden Sie heraus mit folgendem Befehl:

C: \> nc 127.0.0.1 1234

Dies ist ein Test

Sie sollten den Text "This is a test" erscheint nur in einer Instanz der Netcat Zuhörer. Wenn Sie diese Sitzung aktiv und offen ein (weiteres) Eingabeaufforderung, und geben:

C: \> nc 127.0.0.1 1234

Das ist test 2

Sie sollten diesen Text sehen, in einer anderen Instanz der Netcat Zuhörer erscheinen.

Was haben wir gelernt

Da Windows nicht erforderlich Anwendungen exklusiven Zugriff auf einen Port, ist es möglich, eine bösartige Hintertür hinter einem legitimen Anwendung auf dem gleichen Listening-Port haben. Dies macht die Hintertür nicht nachweisbar bei der Durchführung eines Port-Scan. Um die Hintertür, müssen Sie zunächst damit beschäftigt die legitime Anwendung mit einer aktiven Sitzung zu verbinden, aber das ist leicht zu erreichen.

Keine Kommentare »

Posted in 2-Alarm , Windows Security

Tags:

Spoofing Ihre IP-Adresse während einer Port-Scan - Teil 2

31. August 2009

In meinem letzten Beitrag habe ich diskutiert Leerlauf-Scan und wie es einem Angreifer erlauben, ihre IP-Adresse während einer Port-Scan-Maske. In dieser Ausgabe werden wir uns einige Spuren suchen, als auch darüber diskutieren, wie zu erkennen, wenn ein Leerlauf-Scan hat sich gegen das Netzwerk verwendet.

Die Überwachung der IP-ID Inkrement

Lassen Sie uns, indem Sie die Pakete, die Überwachung der IP-ID-Feld auf dem Windows-System waren zu starten. Hier ist, was unser Testpaket aussah:

07:22:15.367140 IP (tos 0 × 0, ttl 64, id 63897, offset 0, flags [none], proto TCP (6), Länge 40) 192.168.100.1.2203> 192.168.100.2.0:., Cksum 0xeca2 (richtig) gewinnen 512

Ein paar dieser Felder sind schon interessant. Der TTL-Wert auf "64", die eine Linux-oder UNIX-System schlägt gesetzt. Da wir Rohstoffe schriftlich das Paket direkt an den Draht ist dieser Wert tatsächlich hping gesteuert. 64 nur zufällig das Programm standardmäßig werden, aber wir konnten den Wert auf alles, was wir wollen mit dem "-t"-Schalter ändern.

Die Zieladresse wird als "192.168.100.2.0", die das Paket an TCP-Port 0 war unter der IP-Adresse 192.168.100.2 geschickt bedeutet gedruckt. Windows nicht bieten Dienste auf TCP-Port 0, aber das ist OK. Wir sind nicht wirklich versuchen, den Windows-Systemordner zu verbinden. Wir müssen nur sie, um uns ein IP-Paket, so dass wir die IP-ID-Wert überprüfen können. Wenn wir an einen anderen Port schlagen wollte, könnten wir hping die "-p"-Schalter.

Die ".," Nach der Soll-Vorgabe bedeutet, dass keine TCP-Flags innerhalb des Paketes gesetzt wurden. Dies wird als ein Null-Paket bezeichnet und nie während des normalen IP-Kommunikation auftreten. Aus diesem Grund wird möglicherweise NIDS, NIPS und Firewalls flag it. Wir haben eine Null-Paket, weil wir nicht sagen, hping einem der TCP-Flags gesendet. Zum Beispiel das Hinzufügen der Option "-S"-Schalter würde das SYN-Flag aktiviert haben, "-A" wäre auf der Anerkennung Flagge wiederum und so weiter.

Alle unsere Testpakete auf die Windows-Systemen würde ähnlich aussehen wie diese. Die einzigen Werte, würde sich ändern, sind die Zeitstempel (natürlich), der TCP-Quellport und der CRC-Prüfsumme Wert.

Hier ist, was die Antworten wie frisch aus dem Windows-System aussehen:

07:22:15.367296 IP (tos 0 × 0, ttl 128, id 108, offset 0, flags [none], proto TCP (6), Länge 40) 192.168.100.2.0> 192.168.100.1.2203: R, cksum 0xc431 (richtig), 0:0 (0) ack 918250228 win 0



07:22:16.367453 IP (tos 0 × 0, ttl 128, id 109, offset 0, flags [none], proto TCP (6), Länge 40) 192.168.100.2.0> 192.168.100.1.2204: R, cksum 0xfa78 (richtig), 0:0 (0) ack 2127488152 win 0



07:22:17.367763 IP (tos 0 × 0, ttl 128, id 110, offset 0, flags [none], proto TCP (6), Länge 40) 192.168.100.2.0> 192.168.100.1.2205: R, cksum 0x2b9f (richtig), 0:0 (0) ack 1611256374 win 0

Der wichtigste Wert ist hier die IP-ID, wie "id" identifiziert. In das erste Paket ist auf 108 gesetzt, und dann wird der Wert Schritten von +1 für jedes weitere Paket (109 dann 110). Solange wir auf eine ununterbrochene Folge in die IP-ID finden Sie weiter, wir wissen, das Windows-System überträgt keine andere Pakete außer denen, die Teil dieser Sitzung.

Probing einen geschlossenen Port

Denken Sie daran, dass im Rahmen unseres Scan, werden wir Spoofing werden die Quell-IP-Adresse des Windows-Systems bei der Ziel-Ports auf einem entfernten System. Eine Änderung der IP-ID Inkrement ist, was sagt uns, wir fanden einen offenen Port.

Werfen wir einen Blick auf eines dieser Pakete können:

10:30:28.852602 IP (tos 0 × 0, ttl 64, id 41256, offset 0, flags [none], proto TCP (6), Länge 40) 192.168.100.2.1266> 192.168.100.3.79: S, cksum 0x97a6 (richtig), 1704542340:1704542340 (0) win 512

Beachten Sie die Quell-IP-Adresse ist, dass der Windows-System (192.168.100.2). Wir wissen das nicht aus dem Windows-System kommen aber, weil die TTL auf 64 eingestellt ist. Das ist also ein Paket, das wir von 192.168.100.1 erzeugt mit Hilfe einer zweiten Instanz von hping.

Beachten Sie auch, haben wir TCP Port 79 gezielte und auf das SYN-Flag aktiviert. Hier ist die Antwort, die wir aus dem fernen Ziel erhalten:

10:30:28.852839 IP (tos 0 × 0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), Länge 40) 192.168.100.3.79> 192.168.100.2.1266: R, cksum 0xbb1a (richtig), 0:0 (0) ack 1704542341 win 0

Beachten Sie die "R"-Wert, der uns sagt, die Reset-Flag wurde auf im TCP-Header eingeschaltet. Wir sehen auch "ack" die uns sagt, die Anerkennung Flagge wurde auch gedreht. Das ist ein Fehler-Paket informiert die Quelle, die den TCP-Port in einem geschlossenen Zustand befindet. Beachten Sie auch das Paket ist, das Windows-System übertragen, da das war die Quell-IP-Adresse in das Testpaket.

Wie also wird das Windows-System reagieren? Sie können von meinem letzten Beitrag vergessen, dass die RFCs Zustand sollte man sich nie zu einem Fehler-Paket antworten. Auch wenn das Windows-System hat keine Ahnung, was das Ziel spricht, wird es ruhig verwerfen diesen Fehler Paket. In anderen Worten, das Windows-System keine Antwort senden. Das heißt, wir sollten keine Änderung der IP-ID Inkrement zu sehen.

Probing einen offenen Port

Werfen wir nun einen Blick auf, was passiert, wenn wir einen Hafen, der tatsächlich in einem geöffneten Zustand Ziel. Hier ist das Testpaket. Hinweis: Es ist ziemlich ähnlich wie die letzte, außer jetzt sind wir überprüfen TCP-Port 80.

10:29:46.947964 IP (tos 0 × 0, ttl 64, id 15249, offset 0, flags [none], proto TCP (6), Länge 40) 192.168.100.2.1984> 192.168.100.3.80: S, cksum 0x476b (richtig), 947341260:947341260 (0) win 512

Hier ist die Antwort vom Ziel. Beachten Sie, dass wir ein "S" statt eines "R", die sie SYN-Flag auf, anstatt die Reset-Flag eingeschaltet bedeutet zu sehen. Dies ist das Ziel Weise der Unterrichtung der Quelle, die den TCP-Port 80 offen ist und eine Anwendung sitzt dahinter Service-Verbindungen.

10:29:46.953333 IP (tos 0 × 0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), Länge 44) 192.168.100.3.80> 192.168.100.2.1984: S, cksum 0x0de6 (richtig), 262246932:262246932 (0) ack 947341261 win 5840 <mss 1460>

Also dieses Mal das Windows-System ein Paket empfängt, sagt: "Sicher, Sie können den TCP-Port 80 zu verbinden." Dies ist ein Problem für die Windows-System, weil es keine Verbindung Eintrag sagen, dass es tatsächlich versucht, an Port 80 auf dem Ziel verbinden hat. Ohne die Verbindung Eintrag, hat Windows keine Möglichkeit zu wissen, welche Anwendung forderte die Sitzung. In diesem Sinne, ist es das einzige, was sie tun können, übermitteln ein Reset-Paket an das Ziel zu töten die Sitzung. Hier ist, was das Paket aussah:

10:29:46.953439 IP (tos 0 × 0, ttl 128, id 176, offset 0, flags [none], proto TCP (6), Länge 40) 192.168.100.2.1984> 192.168.100.3.80: R, cksum 0x5df1 (richtig), 947341261:947341261 (0) win 0

Beachten Sie, dass Windows das nächste verfügbare IP-ID in der IP-Header (176) gestempelt. So hatten wir die Überwachung der IP-ID Zuwachs auf dem Windows-System in einer anderen Sitzung, würden wir sehen: 173, 174, 175, 177, 178, 179. In anderen Worten, wir würden erkennen, dass 176 wurde vermisst (+2 aus dem vorherigen Paket) zu haben. Dies würde unsere Indiz dafür sein, dass die TCP/80 Sonde geschickt, um das Ziel einen offenen Port zu treffen.

Identifizieren eines Leerlauf-Scan

So eine müßige Scan hat eine ausgezeichnete Arbeit der Maskierung der wahre Quell-IP-Adresse eines Port-Scan. Dies bedeutet, dass ohne Zugang zu Informationen über die Windows-Host (etwas, das nicht vorhanden sein wird, wenn der Angriff ihre Hausaufgaben gemacht hat) anmelden, werden wir niemals in der Lage sein, den wahren Quell-IP-Adresse des Angriffs zu entdecken.

Gibt es eine Möglichkeit, um eine inaktive Scan wurde als ein straight forward Port-Scan durchgeführt, so dass wir sagen, ob es sich lohnt die Untersuchung der Quell-IP-Adresse ist wissen? Es gibt in der Tat ein paar Hinweise, wir suchen können.

Prüfwiederholungen

Ist der betroffene System hinter einer Firewall sitzen, werden Sie feststellen, einen Unterschied in der Anzahl der Prüfwiederholungen im Vergleich zu einem normalen Port-Scanner. Wenn jemand einen normalen Port-Scanner läuft, wird der Scanner in der Regel getroffen offene Ports nur einmal, sondern Firewall-Ports mehrfach. Dies liegt daran, die Firewall-Ports keine Antwort zurück. Der Scanner macht mehrere Versuche, um sicherzustellen, dass die Pakete nicht nur verloren gehen. Da die offenen Ports tatsächlich reagieren wird, ist nur ein Testpaket erforderlich.

Wenn ein Leerlauf-Scan durchgeführt wird, ist das Gegenteil der Fall. Wenn ein Firewall-Port wird untersucht es wird keine IP ID Inkrement ändern auf dem Windows-System sein. So nur eine Prüfung erforderlich ist, um zu bestätigen dies nicht durch aktives Zuhören Port. Wenn ein offener Port ist jedoch sondiert werden wir eine Veränderung der IP-ID des Windows-Systems zu erhöhen. Während denke, dass wir dies auf uns zu finden einen offenen Port, könnte es genauso gut sein, weil das Windows-System geschickt ein Broadcast. Wir werden also wollen mehrere Sonden gegen die offene Schnittstelle, um sicherzustellen, das Windows-IP-ID-Daten konstant bleibt durchzuführen.

Also:

  • Probe Firewall-Ports häufiger als offene Ports = normal Port-Scanner
  • Probe offenen Ports immer häufiger, dass Firewall-Ports = idle-Scan

Timing

Normaler Port-Scans werden extrem schnell. Es ist nicht ungewöhnlich, dass Hunderte von Sonde Pakete pro Sekunde zu sehen. Mit einem Leerlauf-Scan haben wir aber die Dinge ein wenig langsamer zu nehmen. Das ist, weil wir die IP-ID der gefälschten Adresse muss überprüfen, senden Sie das Testpaket erlauben genügend Zeit für die Sonde, um eine Antwort zu entlocken, geben die gefälschte System genug Zeit, um mit einem Reset zu reagieren, wenn erforderlich (also mit einer IP-ID ), und überprüfen Sie dann die IP-ID wieder zu sehen, ob der Zuwachs hat sich geändert.

Versuchen Sie, alle diese Schritte zu schnell führen, und Sie werden die Kosten der Genauigkeit zu zahlen. Zum Beispiel nmap unterstützt Idle-Scans mit der "-SI"-Schalter. Der Standardwert extrem schnelle Scangeschwindigkeit funktioniert gut, wenn alle Systeme auf dem gleichen vermittelten Netzwerk befinden. Wenn die Hosts 15 Hops entfernt voneinander auf dem Internet jedoch ist meine Erfahrung die Richtigkeit Rating fällt erheblich, wenn Sie verlangsamen die Scan-Geschwindigkeit.

Also:

  • Hunderte von Paketen pro Sekunde = normal Port-Scanner
  • Ein Dutzend oder weniger Pakete pro Sekunde = möglich im Leerlauf zu scannen, könnte nur eine Slow-Scan werden

TTL-Feld

Sehen wir uns wieder auf die gefälschte Testpaket sowie die legitimen Resetverhalten durch das Windows-System gesendet:

10:29:46.947964 IP (tos 0 × 0, ttl 64, id 15249, offset 0, flags [none], proto TCP (6), Länge 40) 192.168.100.2.1984> 192.168.100.3.80: S, cksum 0x476b (richtig), 947341260:947341260 (0) win 512



10:29:46.953439 IP (tos 0 × 0, ttl 128, id 176, offset 0, flags [none], proto TCP (6), Länge 40) 192.168.100.2.1984> 192.168.100.3.80: R, cksum 0x5df1 (richtig), 947341261:947341261 (0) win 0

Sie können die TTLs bemerkt haben, sind weg von einander. Wenn diese beiden Pakete waren in der Tat von 192.168.200.2 entstand dann würden sie beide den gleichen Ausgangspunkt TTL-Wert. Die Tatsache, dass sie anders sind sagt uns, dass einer von ihnen gefälschte ist.

Wenn Sie die Überwachung des Umfangs des Zielsystems und feststellen, dass die SYN-und Reset-Pakete unterschiedlichen TTL-Werten haben, ist das ein Hinweis darauf, dass es sich eventuell um eine müßige scannen. Nun, wie bereits erwähnt, ist es durchaus möglich, die TTL auf das, was wir wollen in unserer gefälschten Paket gesetzt. So eine intelligente Angreifer ist einfach gehen zu ihrem Ausgangspunkt TTL auf 128 gesetzt, um besser zu imitieren das Windows-System. Wenn sie dies tun, ist Ihre einzige Hoffnung, dass der Angreifer und das Windows-System eine unterschiedliche Anzahl von Hops entfernt sind. In anderen Worten, wenn Sie konsequent die SYN-Pakete mit einer TTL von 115, aber das setzt konsequent eine TTL von 113, sind Sie wahrscheinlich Blick auf ein Leerlauf-Scan.

Wenn die TTLs übereinstimmen, können wir nicht ausschließen, eine müßige scannen. Der Angreifer kann nur sein, dass gut.

Also:

  • TTLs von SYNs und RST stimmen aber nicht überein = idle-Scan
  • TTLS von SYNs und RST match = normale Port-Scanner oder Smart Idle-Scanner

IP ID Wert

Der beste Weg, eine inaktive Scan-Tag nutzen die gleiche Sache der Angreifer verwendet, nämlich die IP-ID-Wert. Nehmen Sie einen Blick auf die beiden letzten decodierten Paketen. Beachten Sie, dass die IP-ID in der ersten 15249 ist aber in der zweiten ist es 176. Wenn Sie sehen, eine müßige scannen sind, werden Sie feststellen, der Rest Pakete konsequent über eine IP-ID von +2 (dasselbe der Angreifer sieht), aber die SYN-Pakete werden einige völlig unabhängig Wert haben. Die IP-ID Zuwachs in der SYN-Pakete könnte vorhersehbar oder es könnte zufällig sein. Ganz ehrlich, es spielt keine Rolle. Was zählt ist, dass man einige Muster in IP-ID der Rest-Pakete, die nicht jive mit der IP-IDs in der SYN-Pakete vor Ort.

Also:

  • IP-ID des SYN und RST-Pakete erscheinen im Zusammenhang = normal Port-Scanner
  • IP ID Zuwachs von RST entspricht nicht SYNs = idle-Scan

Exec Zusammenfassung

Ich hoffe, Sie haben nun ein besseres Verständnis dessen, was auf dem Draht geschieht, wenn ein Angreifer führt einen Leerlauf-Scan. Wenn wir mit einer Leerlauf-Scan ausgerichtet sind, können wir nicht bestimmen, der wahre Quell-IP-Adresse des Angreifers. Das Beste, was wir zu erreichen hoffen kann, ist festzustellen, dass die Scan-Leerlauf-Scan im Vergleich zu einem normalen Port-Scan ist. Es gibt eine Reihe von verräterischen Spuren in Paketen, von denen die besten der IP ID Wert ist.

Keine Kommentare »

Posted in 2-Alarm , Network Security , Packet Decoding

Tags:

Network Mapping über eine Firewall - Teil 3

26. August 2009

In meinen beiden letzten Beiträge Ich sprach über zwei verschiedene Methoden, die verwendet werden, um ein Netzwerk durch eine Firewall Karte werden kann. Die ersten Leveraged ICMP-Time in Transit-Fehlern überschritten, während die zweite verwendet die IP Record Route Option. In beiden Beiträge, die ich gab auch mögliche Lösungen zur Verhinderung von einem Angreifer von der Verwendung dieser Techniken gegen Ihr Netzwerk.

In beiden Fällen jedoch unterstützten Funktionen in kommerziellen grade Firewalls begrenzt unsere Sicherheits-Optionen. In diesem dritten und letzten Teil der Serie, werde ich beschreiben, wie Sie richtig Verhindern dieser Angriffe, wenn Sie eine Open-Source-Firewall befinden. Ich werde spezifisch mit Netfilter , aber viele der Techniken gelten für pf sowie.

Was ist Netfilter?

Netfilter ist die Stateful-Inspection-Firewall, die in jeder modernen Linux-Distribution enthalten ist. Wenn Sie eine Kopie von Linux haben, haben Sie auch eine Kopie des Netfilter. Netfilter wird manchmal auch als iptables bezeichnet, aber das liegt daran, iptables ist der Name des binären Sie verwenden, um den Netfilter Regelbasis zu manipulieren. Netfilter ist ein überaus fähiger Firewall mit zu vielen Funktionen, die in diesem Beitrag nicht decken. Ich empfehle Ihnen, um einige der in den FAQs und Tutorials , wie sie eine ausgezeichnete Arbeit zu beschreiben viele der Features zu tun.

Controlling tcptraceroute

In den ersten Beitrag habe ich beschrieben, wie Tools wie tcptraceroute könnte durch eine offene Firewall-Regel Punsch mit dem Netzwerk sitzen dahinter Karte. Mit kommerziellen Firewalls, waren wir die Steuerung des ausgehenden ICMP-Time in Transit-Fehlern überschritten begrenzt.

Mit Netfilter, haben wir die Fähigkeit, Datenverkehr basierend auf den TTL-Wert kontrollieren. Wir können für einen bestimmten Wert oder einen Wert oberhalb oder unterhalb einer bestimmten Schwelle an. Die unterstützten Switches sind:

  • -M ttl-ttl-eq = Spiel-Pakete mit einer TTL von einem bestimmten Wert
  • -M ttl-ttl-gt = Math-Pakete mit einer TTL höher als ein bestimmter Wert
  • -M ttl-ttl-lt = Spiel-Pakete mit einer TTL unter einen bestimmten Wert

Hier ist eine mögliche Netfilter Regel, die wir verwenden können:

iptables-A FORWARD-m ttl-ttl-lt 5-j DROP

Diese Regel würde vor jeder Genehmigung Regeln in der Regelbasis verarbeitet werden. Die Regel wird einfach anhand der TTL-Wert um zu sehen, wenn es weniger als 5 ist. Wenn ja, wird das Paket verworfen. Da der niedrigste TTL durch ein modernes OS verwendet wird 64, und die meisten Systeme sind über 15 Hops voneinander entfernt auf dem Internet, sollten wir niemals versehentlich herausfiltern legitimen Datenverkehr.

Hier ist tcptraceroute läuft allerdings eine regelmäßige Firewall:

[Root @ fubar ~] # tcptraceroute-n-f 1-m 5-q 1-S 10.1.4.10 80
Ausgewähltes Gerät eth0, Adresse 10.1.1.10, Port 39142 für ausgehende Pakete
Auf den Spuren der Pfad zu 10.1.4.10 auf TCP-Port 80 (http), 5 hops max
1 10.1.2.2 0,353 ms
2 10.1.4.1 0,450 ms
3 10.1.4.10 [open] 0,586 ms

Und hier ist das, was tcptraceroute sieht, wenn wir die oben Netfilter Regel umzusetzen:

[Root @ fubar ~] # tcptraceroute-n-f 1-q 1-S 10.1.4.10 80
Ausgewähltes Gerät eth0, Adresse 10.1.1.10, Port 54531 für ausgehende Pakete
Auf den Spuren der Pfad zu 10.1.4.10 auf TCP-Port 80 (http), 30 hops max
1 10.1.2.2 10,175 ms
2 10.1.4.1 0,464 ms
3 *
4 *
5 *
6 *
7 10.1.4.10 [open] 1,007 ms

Beachten Sie, dass, sobald wir Filterung auf TTL-Wert, den Auftritt unserer Perimeter Veränderungen beginnen. Ohne die Regel ein Angreifer aufzählen oder IP-Adressierung. Selbst wenn wir gefiltert Outbound TimeX Pakete, würden sie immer noch wissen, die richtige Anzahl der Hops. Das Netfilter Regel macht es sehr viel schwieriger, genau zu identifizieren, unsere Netzwerk-Layout.

Hinzufügen bei einigen Täuschung

Eine der mächtigsten Funktionen von Netfilter ist die Fähigkeit zur Anpassung ablehnen Nachrichten. Während die meisten Firewalls Pakete verwerfen, indem er eine administrativ verboten Fehlermeldung, lässt Netfilter Sie aus einer Reihe von verschiedenen unreachable Fehlercodes wählen. Dies macht für einige interessante Möglichkeiten. Betrachten wir zum Beispiel die folgende Regel:

iptables-A FORWARD-m ttl-ttl-lt 5-j REJECT-reject-with icmp-host-unreachable

Diese Regel sagt Netfilter, dass, wann immer es ein Paket mit einer TTL weniger als 5 sieht, ist es eine ICMP-Ziel-Host unreachable Paket zurückgeben sollte. In anderen Worten, Netfilter Identität eines Routers und sagen, die Sende-System, das den Ziel-Host off-line ist. Hier ist ein Beispiel für tcptraceroute Ausgang einmal diese Regel umgesetzt wurde:

[Root @ fubar ~] # tcptraceroute-n-f 1-q 1-S 10.1.4.10 80
Ausgewähltes Gerät eth0, Adresse 10.1.1.10, Port 47555 für ausgehende Pakete
Auf den Spuren der Pfad zu 10.1.4.10 auf TCP-Port 80 (http), 30 hops max
1 10.1.2.2 0,299 ms
2 10.1.4.1 0,450 ms
3 10.1.4.1 0,403 ms! H

Vergleichen Sie diese Ausgabe in den ersten tcptraceroute Ausgang oben gezeigt. Beachten Sie, dass Zeile 3 ist jetzt anders. Mit einer regelmäßigen Firewall, hop drei war eine Antwort von der Ziel-Host. In dieser Ausgabe scheint es jedoch, die Upstream-Router ist eine ICMP Host unreachable (bezeichnet als "! H") bedeutet der Host off-line. Da tcptraceroute denkt der Gastgeber ist off-line, gibt es versucht und nie wirklich erreicht das Ziel-Host.

Während also diese Technik ist ein bisschen Sicherheit durch Unklarheit, es ist effektiv bei der Deaktivierung ein Werkzeug, das normalerweise Punch würde mitten durch eine Firewall. Seit den normalen Verkehr nicht wäre eine ungewöhnlich niedrige TTL-Wert, ist es nicht mit dieser Regel und ist davon unberührt.

Controlling Record Route

In meinem zweiten Beitrag in dieser Serie habe ich darüber gesprochen Record Route und wie es um die Karte durch eine Firewall genutzt werden. Ich diskutierte, dass die Reichweite des Werkzeugs beschränkt ist (max 8 Hopfen, 3, wenn Sie wollen, hop info in beide Richtungen), aber dass es Wege gibt für einen Angreifer, um diese Einschränkung zu erhalten. Ich erwähnte auch, dass die kommerziellen Firewalls in der Regel nicht geben Ihnen die Möglichkeit zur Aufzeichnung Datenverkehr zu kontrollieren.

Mit Netfilter gibt es Unterstützung für die Steuerung von IP-Optionen über die ipv4options Modul (http://netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO-3.html). Die unterstützten Switches sind:

  • -M ipv4options-ssrr = Spiel-Pakete mit strengen Source-Routing-Set
  • -M ipv4options-LSRR = Spiel-Pakete mit Loose Source Routing gesetzt
  • -M ipv4options-rr = Spiel-Pakete mit Record Route festlegen
  • -M ipv4options-ts = Spiel-Pakete mit Zeitstempel gesetzt
  • -M ipv4options-ra = Spiel-Pakete mit Router-Alarm gesetzt
  • -M ipv4options-any-opt = Match-Pakete mit mindestens einem IP Option

Hier ist ein Beispiel für eine Regel, die Pakete mit der Source-Route-Option gesetzt würde blockieren:

iptables-A FORWARD-m ipv4options-rr-j REJECT-reject-with icmp-host-unreachable

Hinweis senden wir die ICMP Host unreachable als Antwort. Dies ist notwendig, um Herunterfahren des Werkzeugs Mapping unserem Netzwerk.

Exec Zusammenfassung

Während kommerzielle Firewall excel an die zentrale Verwaltung und Auswahl von angenehmen Farben für ihre grafische Oberfläche, sie in der Regel blass im Vergleich zu Quelle-Firewalls in Bezug auf die Kontrolle des Datenverkehrs auf dem Draht öffnen. Um ihre Netzwerke zu schützen, müssen Firewall-Administratoren eine bessere Kontrolle der IP-Header als nur die Überprüfung der Quell-und Ziel-IP-Adresse.

Keine Kommentare »

Posted in 2-Alarm , Network Security

Tags: