Was taugt die Norton Internet Security 2003?

[Alexander Foken]

Moin Moin !

HTTP benutzt für Request und Response eine einzige Verbindung, die (beim Surfen) vom LAN (innen) zum Internet (außen) aufgebaut wird. Du kannst von außen keinen Request faken.

Schon klar, aber Router können kein TCP udn schon gar kein HTTP also habe ich diese Ebenen außer Acht gelassen.

Du irrst. Ein NAT-Router (und davon reden wir die ganze Zeit) *muß* außer IP auch TCP und UDP können. Und damit FTP "blödensicher" funktioniert, muß der Router auch teilweise FTP verstehen.

Das problem muss sich auf IP Ebene lösen lassen, nur wie? Wie gesagt glaueb ich zu wissen dass es da so sequenzen gibt an der der Router eine "IP-Antwort" erkennt und entsprechend weiterleitet, aber eben da es auf IP Ebene läuft frage ich mich wieso das zuverlässig funktionieren soll!

Nein. Siehe Posting [pref:t=45082&m=246097] von Henryk Plötz.

wie unterscheidet er es von irgendeinem Request in welchem protokoll auch immer an so einen Port der ja nicht per Port-Forewarding weitergeleitet wird?

Der "Surf-Request" kommt von innen, die Connection-Daten (Source-IP, Source-Port, Dest-IP, Dest-Port, Translation-IPs und -Ports) werden gespeichert, bis die Connection abgebaut wird.
wie kann auf IP-Ebene eine Verbindung aufgebaut werden? IMHO gibt es doch nur auf TCP-Ebene eine echte Verbindung, oder?

Davon rede ich die ganze Zeit. Die IP-Parameter sind Teil der TCP-Verbindung.

Von außen kommende TCP-Verbindungen werden entweder abgelehnt oder an einen Server hinter dem Router weitergeleitet, je nach Konfiguration.
Der Router sieht doch nur ein IP-Paket mit Source IP und Dest. IP. Heißt also das Router die noch Paketfilter NAT... haben noch zusätzlich das TCP/UDP Protokoll implementiert haben.
OK, dann relativiert sich natürlich so einiges was ich geschrieben habe, hatte ich nicht dran gedacht ;-)

Aahhh! Der Groschen ist gefallen.

Aber wenn das TCP implementiert wird heitß das doch noch nicht dass der Router auch tatsächlich eine TCP Verbindung herstellt, oder? Das kann ich mir nämöoch nicht vorstelle. Ich würde vermuten dass der Router die TCP-Daten extrahieren und verstehn kann, um z.B. bestimmte Ports zu filtern, hm, aber wenn NAT funktionieren soll dann braucht er schon sowas wie eine echte TCP-Verbindung, oder er speichert die Daten irgendwie anders zwischen, er bedient sich also der Daten die seine Clients und der Host verwenden. Denn eine TCP-Verbindung ist ja eine logische Verbindung zw. 2 Rechnern, die Router dazwischen verwenden AFAIK nur das IP-Protokoll um die Daten weiterzureichen. IMHO kann der Router gar keien TCP-Verbinding aufbauen denn der Client will ja explizit eine TCP-Verbindung zu einem ganz anderen Rchner aufbauen, daher vermute ich dass der Riuter nur die Daten extrahiert und sich selbst irgendwo zwischenspeichert und kontrolliert.

Nimm Dir eine gute Enführung zu TCP/IP zur Hand ... (Schande über mich - habs studiert und trotzdem keinen guten Link zur Hand).

http://www.tldp.org/HOWTO/IP-Masquerade-HOWTO/index.html könnte Dich interessieren (wenn Du den Linux-spezifischen Teil ignorierst). Dort sind auch viele weiterführende Links.

Der Client *muß* eine Verbindung zum NAT-Router machen, weil das sein *einziger* Weg nach draußen ist. Der Client macht die Verbindung nicht gezielt zum NAT-Router auf, aber dieser fühlt sich angesprochen, manipuliert die Connection-Daten (NAT Teil 1) und baut seinerseits eine Connection ins "böse Internet" auf (NAT Teil 2). Die Daten für beide Connections (jeweils Source und Dest IP und Port) legt er in einer Tabelle (NAT-Tabelle) ab. So weiß der NAT-Router zu jeder Zeit, welche Intern-Verbindung zu welcher Extern-Verbindung gehört.

Gut, wenn ein Router TCP versteht kann er anhand der TCP-Header ja ne ganze Menge kontrollieren. Meinst Du also dass der Router dann die Aufgabe des eigentlichen Empfängers übernimmt und den TCP-Header auch tatsächlich auf entsprechende Daten wie Sequenznummer... überprüft?

Ja.

Würde ein Router nicht hoffnungslos überlastet wenn er wirklich wie ein echter Empfänger diese ganzen Angaben prüft?

Nein. TCP/IP ist recht einfach gestrickt, die Tests beschränken sich auf ein paar Bit-Operationen.

Um gegen den von mir skizzierten Angriff gewappnet zu sein, muss der Router Daten des TCP-Requests(ich weiß hier nicht die genauen Bezeichnungen auswendig, ich nenne es jetzt einfach mal so) , und muss dann die TCP-Response mit zu erwartenden Daten vergleichen.

Ja. Aber der Vergleich geht sehr schnell, weil TCP so einfach ist. Schritt 2 des TWH wird immer abgeleht, wenn nicht ein passender Schritt 1 im TCP/IP-Stack gespeichert ist (Source/Dest-IP/Port, TCP Sequence Numbers).

Aber ich frage mich ob er das überhaupt muss, denn wenn mit so einem Rsponse was nicht stimmt, sagen wir mal ich schicke dem Router ein Paket in einem Eigenen Protokoll für meinen bösen Trojaner, und packe das ganez in einen solchen TCP-Response, dann müsste doch theoretisch das Betriebssystem, wenn es eben diesen Response nicht erwartet dieses Paket verwerfen, und der Router bräuchte sich um sowas gar nicht kümmern, oder?

Der NAT-Router verwirft das Paket, weil Du den Schritt 2 des TWH vor dem Schritt 1 machen willst. Es ist für den Router wesentlich einfacher, Schrott gleich wegzuwerfen, als zu versuchen, diesen Job den Clients reinzudrücken.

Hm, bin irgendwie etwas verwirrt wie man vermutlich merkt ;-)

In der Tat.

AFAIK merkt sich ja der Router einen "IP-Request" eines seiner Clients und kann dann den "Response" entsprechend wieder zurückleiten,

Nein, Du würfelst HTTP und TCP durcheinander. Der Client baut eine TCP-Connection zum Server auf (Three-Way-Handshake), dabei verändert der NAT-Router klammheimlich die Connection-Daten in den IP-Paketen, so daß es von außen so aussieht, als käme die Connection vom Router.
Aha! Aber baut der Router jetzt wirklich eien TCP-Verbindung auf oder "fummelt" er nur ein bisschen in den Paketen rum?

Das kannst Du sehen, wie Du willst: Von außen gesehen kommt die Verbindung vom NAT-Router, von innen gesehen ist der Router (fast) unsichtbar, er ist nur einer von vielen HOPs zum Server. Was im Router passiert, steht u.a. in /usr/src/linux. ;-) Und natürlich in den vielen HOWTOs zum Thema.

Trenne HTTP und TCP in deinem Kopf. Von außen kann ohne HTTP-Request kein HTTP-Response kommen.
Das trenne ich durchaus, die von mir fälschlicherweise verwendeten Begriffe verwirren Dich vermutlich :-)

Oh ja. Du benutzt HTTP-Begriffe für TCP, und Du gehst -- dem Text nach -- davon aus, daß HTTP-Request und HTTP-Response getrennte Verbindungen benutzen. Der HTTP-Request baut implizit eine TCP-Verbindung auf, die vom Server auch für den HTTP-Response benutzt wird. Bei HTTP/0.9 und HTTP/1.0 ist dann Schluß (Verbindungsabbau), bei HTTP/1.1 mit Keep-Alive wird die TCP-Verbindung für weitere Request-Response-Paare benutzt, bis Client oder Server keinen Bock mehr haben ("Connection: closed").

TCP-Connections von außen werden überwiegend geblockt.
OK, ich denke ich habe es verstanden ;-) Mein Idee war es halt von außen so zu tun als ob man mitten in einer TCP-Verbindung wäre, aber vermutlich würde das dann spätestens beim Client scheitern da die TCP-Implementierung nichst mit solchen Paketen anfangen könnte, also vergiss es ;-)

Nein, das wird jetzt ausdiskutiert! ;-)

Mit sehr viel Aufwand ist es möglich, eine bestehendenTCP-Verbindung zu "hijacken", damit kann man (wenn man netzwerktechnisch dicht am Client bzw. Router ist) eine TCP-Verbindung zu einer anderen Maschine umleiten. Dazu muß der Angreifer aber für jedes einzelne TCP-Paket schneller antworten als der Original-Server, zumindest bis der Original-Server die Verbindung als abgerissen ansieht.

Was ich jetzt noch nicht wirklich weiß - würden Router TCP-Pakete "blind" weiterleiten, oder prüfen sie tatsächlich wie der Client ob das Paket überhaupt "gültig" ist da angefordert?

Das fällt unter Port-Filter.

Man kann NAT-Router so einstellen, daß sie nach bestimmten Regeln filtern. Zum Beispiel alle IP-Adressen blocken, die ausschließlich für pr0n oder die Konkurenz arbeiten. Oder nur bestimmte Clients für den Internet-Zugang zulassen. Oder alle Ports zu "bösen" Diensten (Telnet, Chat, Peer-To-Peer, Windows-Dienste) blocken. Meistens blockiert man auch gleich noch HTTP (und oft auch FTP) und läßt diese über einen Proxy laufen. So läufts bei mir in der Firma: Ich kann gar nicht raus, nur passives FTP und HTTP über einen Proxy funktionieren - soweit die Regeln für alle "normalen" Mitarbeiter. Ich habe auch noch eine ISDN-Karte, mit der ich mich am Proxy vorbei mogeln kann, um auf Server beim Kunden zu kommen.

Danke für die Erklärung

Jederzeit wieder.

Alexander