Den Satz bezüglich der PF "net besser oder schlechter, sondern anders" kann ich in der Form auf jeden Fall unterschreiben, wenn wir daraus jetzt noch ableiten, dass es eben für jede Art von Firewall ihren speziellen Einsatzzweck gibt.
Hm, das scheint also noch nicht klar genug zum Ausdruck gekommen zu sein. Die Zusammenfassung würde ich gerne noch dahingehend anpassen. Kannst Du das bitte Konkretisieren, damit wir nicht aneinander vorbeireden?
Zitat:
Zitat von Catweazle
Zu dem Thema VPN gibt es so viel zu sagen, wo soll ich da anfangen.
Hey, ich hoffe das ist neben dem IDS auch ein Steckenpferd von Dir. Es ist gar nicht so einfach, daß alles in einer kurzen, verständlichen Form zu erklären (Was ist Tunnelung? Was ist ein geschlossenes Netz in einem Trägernetz? Und wie werden die Datenpakete über VPN verschlüsselt?). Da könnte ich wirklich Hilfe gebrauchen. Kannst Du bitte noch etwas näher darauf eingehen?
Zitat:
Zitat von Catweazle
Statisches Natting wandelt private IPs in öffentliche (public) IPs um. Dynamisches Natting wandelt private IPs in eine öffentliche IP um, …
Als unbedarfter Leser: Wo ist da der Unterschied? Und warum muß ich überhaupt eine IP umwandeln, damit ich IPs einsparen kann? Wie funktioniert das?
In Deinem ersten Beitrag des Threads hast Du zur DMZ folgendes geschrieben:
Zitat:
Zitat von Catweazle
Eine DMZ ist eine Zone, welche sowohl von extern als auch von intern durch die Firewall gesichert ist. (Drittes Bein der Firewall). In dieser Zone sind häufig Server angesiedelt, auf welche sowohl vom internen Netz, als auch vom externen Netz zugegriffen wird. Wenn ein solcher Server extern angesiedelt wäre, wären die Zugriffe der internen Mitarbeiter nicht sicher, würde er im internen Netz stehen, wäre das gesamte Netz unsicher, da Verbindungsaufbauten von aussen zugelassen werden müssten.
Das ist eine sehr gute Erklärung, die allerdings noch ein paar Fragen offen lässt: Laut des ersten Satzes wird ein Rechner innerhalb der DMZ also von zwei Firewalls geschützt (Internet->Firewall->DMZ<-Firewall<-internes Netz), richig? Für den unbedarften Leser stellt es sich so dar, als wenn die Rechner in der DMZ doppelt so gut geschützt sind, wie die Rechner hinter der DMZ (also die Rechner im internen Netz). Schließlich wachen hier zwei Firewalls über die Rechner innerhalb der DMZ. Mit anderen Worten scheinen die Rechner aus der DMZ auch gegen Attacken aus dem internen Netz geschützt zu sein. Warum heißt dat Dingen dann DMZ (also Demilitarized Zone -> zu deutsch: entmilitarisierte Zone)? Der Name lässt doch eher auf einen geringeren Schutz schließen.
Zudem: Bei vielen DSL-Routern kann man auch wenigstens einen Rechner komplett in die DMZ „stellen“. Für diesen Rechner lassen sich aber keine Firewallregeln festlegen. Wo sind da die Firewalls?
Und: Zu der Möglichkeit, einen Rechner komplett in die DMZ zu stellen, gibt es bei DSL-Routern in der Regel auch eine Einstellung, die es erlaubt, daß man bestimmte Dienste (Anfragen auf Ports für http, SMTP, eDonkey, etc.) auf eine IP-Adresse im internen Netz weiterleitet. Wo ist da die DMZ?
Fragen über Fragen. Wie gesagt: Alles aus der Sicht eines unbedarften Anwenders.
Das ist eine sehr gute Erklärung, die allerdings noch ein paar Fragen offen lässt: Laut des ersten Satzes wird ein Rechner innerhalb der DMZ also von zwei Firewalls geschützt (Internet->Firewall->DMZ<-Firewall<-internes Netz), richig? Für den unbedarften Leser stellt es sich so dar, als wenn die Rechner in der DMZ doppelt so gut geschützt sind, wie die Rechner hinter der DMZ (also die Rechner im internen Netz). Schließlich wachen hier zwei Firewalls über die Rechner innerhalb der DMZ. Mit anderen Worten scheinen die Rechner aus der DMZ auch gegen Attacken aus dem internen Netz geschützt zu sein. Warum heißt dat Dingen dann DMZ (also Demilitarized Zone -> zu deutsch: entmilitarisierte Zone)? Der Name lässt doch eher auf einen geringeren Schutz schließen.
Hier liegt ganz klar ein Darstellungsmissverständnis vor.
Vielmehr sind die Rechner im LAN durch zwei firewalls geschützt und der Rechner in der DMZ nur durch eine, da, aus der Sicht des internets ganz klar zu erkennen ist
Internet -> Externe Firewall -> DMZ -> interne Firewall -> LAN
(aufdrösel) also: dachte eigentlich durch das "dritte Bein der Firewall" wäre das deutlich geworden.
Sicherlich gibt es DMZen, die sich zwischen externem und internem Gateway aufspannen (Screened Subnet), aber das ist nicht zwingend so.
Grundsätzlich hatte ich das eigentlich folgendermassen darstellen wollen:
externes Interface Firewall (mit evtl. vorgelagertem Paketfilter) -> DMZ Interfache -> internes Interface (mit evtl. vorgelagertem internen Paketfilter).
Die DMZ dient halt dazu, kontrollierten Zugriff von extern und intern auf bestimmte Ressourcen zuzulassen.
Natting:
Der Unterschied besteht darin, dass beim Hide Natting (dynamisch) alle internen IPs auf eine abgebildet werden und beim Statischen Natting einfach nur jeweils eine Interne auf eine Externe umgesetzt wird.
Um die Struktur des internen Netzes zu verbergen wird das Dynamische Natting verwendet, daher wird es auch als Hide Natting bezeichnet.
VPN:
Es gibt unterschiedliche Arten von VPNs:
VPNs zwischen zwei Netzen, die durch Firewalls geschützt werden (werden auch Intranet VPNs genannt) und VPNs zwischen einem Client im Netz und einem Netzwerk (Remote Access VPNs).
Zwischen zwei geschützten Netzen wird das VPN in der Regel durch die Firewall etabliert, indem die beiden Firewall-Komponenten die Pakete zwischen ihren Netzen verschlüsseln.
Verschlüsselung:
Bei einer überschaubaren Anzahl von Instanzen, die evtl. sogar zentral administriert werden würde ich in diesem Fall eine symmetrische Verschlüsselung vorziehen (Beide Instanzen verwenden zum Ver- und entschlüsseln den gleichen Schlüssel, dieser muss vor der ersten verschlüsselten Kommunikation also beiden Instanzen bekannt sein.
Vorteil: Die Ver- und Entschlüsselung ist recht schnell.
Nachteil: Wer den Schlüssel kennt, kann alles mitlesen, für jede Kommunikation wird ein eigenes Schlüsselpaar benötigt (sofern nicht jeder mitlesen können darf .
BSP.: drei Instanzen wollen verschlüsselt miteinander kommunizieren, wenn jeweils nur der Adressat entschlüsseln können darf werden hier drei Schlüsselpaare benötigt, kommt eine Instanz dazu werden es 6 Schlüsselpaare, bei 6 Instanzen 15 Schlüsselpaare
Bei einer größeren Anzahl von Instanzen ohne die Möglichkeit, die Verschlüsselungskomponenten vor der Kommunikation zentral zu konfigurieren (z.B. unterschiedliche Firmen, Behörden oder Privatnutzer) ist das Asymmetrische Kryptierungsverfahren die bessere Wahl.
Beim Asymmetrischen Verschlüsselungsverahren (z.B. Diffie Hellmann) wird ein Schlüssel zur Kryptierung und ein Schlüssel zur Dekryptierung benutzt,
wobei der gemeinsame Schlüssel eines jeden Komminikationspaares aus dem eigenen privaten und dem öffentlichen des gegenübers besteht, entschlüsseln kann nur der jeweilige Adressat mit seinem privaten key.
VPNs machen aber noch mehr, als blosse Verschlüsselung, der eigentliche Clou an VPNs ist die komplette Verkapselung eines Paketes incl. dessen Header, aus dem ja auch Informationen gezogen werden können und der Ersatz durch einen Encryption Protocol Header. Das Paket wird so durch ein unsicheres Netz (z.B. Internet) übertragen und erst an der "Gegenstelle" wieder in seine ursprüngl. Form decodiert.
Zum Thema Personal Firewall und ALG:
Eine Personal Firewall macht im privaten und small office Bereich Sinn, wo kein ausgebildeter Sicherheits-Admin über das Netz "wacht".
In diesem Bereich ist eine Hochsicherheitsfirewall aufgrund des administrativen Aufwandes "unpraktisch".
Ob und in welchem Masse eine PF hinter einer gut administrierten zentralen Firewall in Kombination mit einem IDS/IDR System Sinn macht, sei jedem selbst überlassen....
(aufdrösel) also: dachte eigentlich durch das "dritte Bein der Firewall" wäre das deutlich geworden.
Ja, mir schon. Aber in dem Thread geht es ja nicht um mich.
Dein „Ajeh“ kann ich verstehen. Ist verdammt Zeitraubend, oder? Danke, daß Du trotzdem mitmachst.
Toller Beitrag.
Bye, Ronald
PS "Zum Thema Personal Firewall und ALG": Jetzt weiß ich endlich, was genau Du damit meinst. Mit Deiner Erlaubnis werde ich das jedoch erst in der letzten Zusammenfassung (dem Fazit) mit einfließen lassen, da es in dem aktuellen Beitrag „welche Stärken und Schwächen haben PF gegenüber externen FW“ noch nicht richtig hineinpasst. OK?
ich habe das Konzept für die nächsten Zusammenfassungen zu Gunsten der Übersichtlichkeit noch einmal leicht verändert. Deshalb wäre es hilfreich, wenn die folgende Frage bereits in diesem Part beantwortet wird:
Was ist Port Forwarding bzw. ein Reverse Proxy?
Damit sollten nach der nächsten Zusammenfassung die grundlegenden Fragen zu den Kürzeln und Features geklärt sein. Also, wer kann Helfen?
also wenn ich keine direkten Zugriffe auf einen bestimmten Server zulassen will, dann setze ich einen Reverse Proxy ein.
Dies setzt voraus, dass mein DNS-Server einen entsprechenden Eintrag aufweist und Zugriffe auf Inhalte meines zu schützenden Servers auf den Reverse Proxy umleitet (im Falle des Einsatzes einer Firewall als Reverse Proxy ist dies nicht nötig, da die Zugriffe ja eh über die Firewall laufen).
In der Praxis sieht es also so aus, dass ich eine bestimmte Seite aufrufe, die auf einem Web-Server liegt, ich den Inhalt aber nicht direkt von dem Web-Server bekomme, sondern vom Reverse Proxy.
Ist auf dem Reverse Proxy auch das Caching aktiv, dann kann es zum Beispiel sein, dass beim Zugriff auf statische Inhalte die Antwort direkt aus dem Proxy-Cache kommt, ohne dass auf den Server zugegriffen wird (spart Bandbreite) ein weiterer Vorteil ist, dass Angriffe auf den Server fehlschlagen, wenn diese auf Vulnerabilities des Web-Servers (Apache oder IIS) zielen, da der Kommunikationspartner ja ein Proxy ist, der diese Vulnerabilitie überhaupt net aufweist.
Der nächste Punkt ist, dass ein möglicher Angreifer auf dem Proxy hängen bleibt, der evtl. Zugriff auf den Server erfolgt ausschliesslich durch den Proxy selber.
Wenn ich eine Instanz (Router/Firewall o.Ä.) mit Network Adress Translation (Hide Natting) einsetze, dann ist für externe Stellen die IP des externen Interfaces meiner o.g. Instanz die einzig erreichbare Adresse.
Sofern hier jetzt kein reverse Proxy läuft, bringt es ja nichts, wenn jemand von extern meinen Router, meine FW auf Port 80 anspricht, da dort ja kein Server lauscht.
Also setze ich entweder einen Reverse Proxy (auf meiner FW) ein, oder aktiviere Port Forwarding auf meinen Webserver auf meinem Router.
es ist schwer zu übersehen, daß immer weniger Forumsleser einen aktiven Beitrag zum Thread liefern. Das mag daran liegen, daß die Thematik mittlerweile zu langweilig geworden ist oder möglicher Weise auch derart speziell, daß kaum noch jemand etwas konstruktives dazu beitragen kann oder will. Womöglich passt einigen von euch auch die Art der Vortragsweise nicht. Vielleicht entspricht der Thread auch einfach nicht euren Erwartungen. Da ich meine Zeit nicht umsonst investieren möchte, muß ich es auf jeden Fall vermeiden, daß ich mit meiner Arbeit an euch vorbeimanövriere!
Die neue Forumssoftware liefert eine Möglichkeit herauszufinden, ob der Thread für euch hilfreich ist, oder nicht. Leider funktioniert das nicht unter einem Gast-Account. Ihr müsst euch also mit eurer registrierten Kennung anmelden, dann den Thread öffnen und oben auf der Optionsleiste den Menüpunkt „Bewertung“ auswählen. Damit könnt Ihr mir ein Feetback gaben, ob ich den Thread so weiterführen soll, oder nicht.
Ich möchte also jeden, der sich „nur“ lesend mit dem Thread auseinandersetzt, bitten, wenigstens an der Bewertung teilzunehmen.
Auch ohne diesen Hinweis hat der Thread bereits zwei Bewertungen erhalten: Einmal fünf Sterne und einmal einen Stern. Letzteres ist allerdings nur Hilfreich, wenn Du mir damit sagen willst, daß der Thread überflüssig ist und geschlossen werden sollte. Wenn Du allerdings willst, daß sich etwas an dem Thread ändert, dann reicht eine negative Bewertung nicht aus, da dort kein Kommentar untergebracht werden kann. In diesem Fall möchte ich Dich bitten, zusätzlich einen Kommentar hier im Thread zu hinterlegen (notfalls unter dem Gast-Account, wenn Du anonym bleiben möchtest / oder per „persönliche Nachricht“ an mich). Danke.
Wem lediglich die Frage-/Antwort-Strategie des Threads nicht gefällt, da sie etwas von einer „ich Lehrer, Du Schüler: setzen“- Atmosphäre vermittelt, der sollte vor seiner Bewertung bitte das hier lesen und mir im günstigsten Fall einen besseren Vorschlag unterbreiten (da wäre ich Dir sehr verbunden):
Leider hat Stöhnie das aus versehen in den Ursprungsthread gestellt und nicht hier hineingeschrieben. Dort wird aber erklärt, warum der FAQ-Thread so aufgebaut ist.
ok, du (ronald) möchtest, das sich jemand outet, weil "dein" thread als "schrecklich" bewertet wird. dann tu ich das mal hiermit, da habe ich kein problem mit! diesen thread zu schliessen halte ich für nicht nötig, denn ich lese ihn nicht.
und das ist doch komisch, wo ich mich doch eigendlich über gute und hilfreiche themen freue. aber diesen thread lesen...das ist zuviel des guten. er ist einfach abartig: dein agieren, deine wichtigtuerei und die konsequent durchgezogene linie: "wenn hier jemand nicht it´ler ist, wird er nichts, aber auch garnichts checken" - d.h. man könnte auch mal ein bischen noob-kompatiebel schreiben.
[FONT=Comic Sans MS]Auch diese ewigen eingefärbten Grossbuchsaben gehen mir auf den Sack!!![/FONT]
ich habe nun lange genug geschwiegen, ich bin mir im klaren, das ich mir keine freunde hiermit mache, aber ich weiss auch, das ich nicht der einzige bin, der so denkt. also mach ruhig weiter, denn ich ignoriere und meide diesen thread natürlich! und um es nochmal zu verdeutlichen: niemand schätzt einen guten, sachlichen, hilfreichen, lehrreichen, netten thread mehr als ich!
p.s. und lass doch bitte die leute abstimmen oder bewerten wie sie es für richtig halten, ohne rechenschaft dafür ablegen zu müssen! (man könnte echt denken, das du hier etwas zu melden hättest )
"wenn hier jemand nicht it´ler ist, wird er nichts, aber auch garnichts checken" - d.h. man könnte auch mal ein bischen noob-kompatiebel schreiben.
Der Thread ist nicht für Newbies gedacht. Um genau solche Missverständnisse zu vermeiden, habe ich einen entsprechenden Hinweis im Eröffnungsbeitrag hinterlegt. Womöglich hast Du ihn übersehen?
Tastsächlich richtet sich der Thread an aktive Netzwerk+Security-Berater aus dem Forum. Also für Leute wie un.inc, sys3, io.sys, Catweazle, tele und Kommune23 (auch wenn er, wie er sagt, kein IT’ler ist ).
Ich denke, bei diesen Usern sind mehr als genügend Vorkenntnisse vorhanden, um die FAQ zu verstehen. Es gibt allerdings auch Deine gesuchten „noop-kompatiblen“ Beiträge im Thread. Bspw. der erste Part aus der Zusammenfassung „Was ist eine Firewall“ oder „Was ist eine IP-Adresse“, etc. Dennoch wurden diese Dinge nicht deshalb dort festgehalten, damit der Thread Newbies-kompatibel wird. Vielmehr ist das ein Hinweis darauf, wie man diese Thematik als Berater möglichst leicht erklären kann.
Natürlich hätte ich den Thread auch gerne für Dich geschrieben. Und möglicher Weise wäre mir das auch gelungen. Allerdings: Ohne Feedback kann ich mich weder auf Deinen Wissensstand einstellen, noch kann ich den Thread an Deine Bedürfnisse anpassen. Denn hellsehen kann ich nicht.
Zitat:
Zitat von Stöhnie
Auch diese ewigen eingefärbten Grossbuchsaben gehen mir auf den Sack!!!
Zumindest bei den Zusammenfassungen möchte ich durch die Einfärbung erreichen, dass die wichtigen Aussagen hervorgehoben werden. Der restliche, schwarze Text dient lediglich der Hintergrundinformation. Das finde ich praktisch, da man nur dann den gesamten Text lesen muß, wenn man sich für die Hintergrundinfos interessiert.
Allerdings hast Du schon recht: Grob betrachtet sehen die Beiträge aus, wie ein bunter Picasso. Da der Thread jedoch schon recht fortgeschritten ist und Du momentan der einzige Anwender bist, der das bemängelt, werde ich jetzt noch nicht anfangen, alles umzugestalten.
Zitat:
Zitat von Stöhnie
ok, du (ronald) möchtest, das sich jemand outet, weil "dein" thread als "schrecklich" bewertet wird.
Ich wollte nicht wissen, warum ich schlecht bewertet wurde. Nur wenn jemand will, dass sich an dem Thread etwas ändert, sollte man einen Kommentar zu seiner Bewertung abgeben. Denn auch hier gilt: Ich kann nicht Hellsehen.
Zitat:
Zitat von Stöhnie
niemand schätzt einen guten, sachlichen, hilfreichen, lehrreichen, netten thread mehr als ich!
Na, da haben wir ja schon mal etwas gemeinsam. Wie wär’s, wenn Du mir dabei hilfst, dass es auch in diesem Thread klappt?
@All
Momentan sehe ich noch ein ganz anderes Problem. Der Thread bewegt sich gerade von den interessanten Themen weg. So ein theoretischer Kram wie NAT/PAT und Port Forwarding, etc. ist eher langweilig. Allerdings sind sie für eine FAQ notwendig. Doch ich hoffe, daß diese Durststrecke bald überwunden sein wird.
@ Stöhnie: Verschiebung in Tutorials - die Anregung finde ich in Ordnung und stehe auch 100%ig dahinter.
Dass Ronald dazu aufgefordert hat, sich im Thread zu äussern, anstatt nur negativ zu bewerten habe ich so verstanden, dass er um konstruktive Kritik bittet, um evtl. von anderen Forennutzern empfundene Misstände zu ändern, daran kann ich nichts Verwerfliches feststellen.
Teilweise bin ich ja auch net mit allem, was der Ronald so schreibt einverstanden, aber ich finde, mer sollte ihm zugute halten, dass er sich ziemlich viel Arbeit macht und ich denke mal, dass der Thread auch für "Nicht-IT-Professionals" geeignet ist, sofern sie ein gewisses Interesse für die Materie mitbringen.
Wenn dem nicht so ist, sollten wir evtl. gemeinsam versuchen, dass zu ändern, aber wie Ronald schon geschrieben hat, geht das net über eine kommentarlose Negativbewertung.
[...] und ich denke mal, dass der Thread auch für "Nicht-IT-Professionals" geeignet ist, sofern sie ein gewisses Interesse für die Materie mitbringen.
Ich gehöre zu den "Nicht-IT-Professionals" und ich habe auch ein gewisses Interesse an der Materie. Aber - und das hab ich Ronald auch grad auf seine PM geantwortet - man verliert hier irgendwann den Faden.
Ist nicht so, dass ich eine schreib- leseschwäche hätte oder so; aber zwischendurch hab ich hier echt nicht mehr soo viel verstanden.
Daher kann ich mich hier auch nicht mehr beteiligen. Und das wird IMO noch vielen anderen so gehen!
Aber ich schätze mal, wenn jemand wirklich ausführliche Informationen zum Thema Firewall braucht, dann ist er hier ganz gut bedient - nur wird er ein ganzes Weilchen brauchen, um auch alles zu kapieren.
Wie heißt es so schön?: Weniger ist manchmal mehr!
"‘Multiple exclamation marks‘", he went on, shaking his head, "‘are a sure sign of a diseased mind‘." Terry Pratchett
Ich verstehe das Dilemma. Viele Leser hätten statt einer „Firewall FAQ für Fortgeschrittene“ lieber eine FAQ für Laien. In diesem Fall hat Kommune23 recht: Weniger wäre dort natürlich mehr. Dinge wie das OSI-Referenzmodell, die Firewallarten + Mischformen, etc. sind einfach zuviel des Guten. Ohne diese Themen würden allerdings auch Aussagen wie „Paketfilter sind keine Firewalls“ und ähnliches weiterhin Bestand haben. Und auch viele weitere Dinge führen ohne dieses Grundwissen zwangsläufig zu Missverständnissen und gefährlichen Falschaussagen (siehe Ursprungsthread). Und das, obwohl die Berater doch eigentlich helfen wollen.
Um Falschaussagen für die Zukunft zu minimieren, war der Thread für Berater zurechtgeschnitten und nicht für Laien gedacht. Es lag also gar nicht in meiner Absicht, eine Firewall FAQ für Lainen zu schreiben. Meine Schuld. Ich habe das offensichtlich nicht verständlich genug zum Ausdruck gebracht.
Allerdings gehört auch Kommune23 zur Zielgruppe. An ihn geht der Thread offensichtlich ebenfalls vorbei. Auch die mangelnde Bewertung zeigt mir, dass es vielen Lesern ähnlich geht (obwohl ich mir ohnehin nicht vorstellen konnte, dass so viele Leser hier als Berater fungieren wollen). Ich bedaure nur, dass dies nicht schon viel früher zur Sprache gekommen ist.
Da hier bereits sehr viel Arbeit hineingesteckt wurde, werde ich den Thread wohl oder übel zu ende führen. Schließlich handelt es sich ja nicht nur um meine investierte Zeit. Auch wenn es mir unter diesen Voraussetzungen keinen Spaß mehr machen wird, hoffe ich, dass der Thread dennoch für einige Leser informativ und lesenswert sein wird.
Für die bisher angesprochene Kritik hätte ich folgenden Lösungsvorschlag: Wie wäre es, wenn wir den aktuellen Thread unter dem Titel „Firewall FAQ für Fortgeschrittene“ nach Tutorials umziehen lassen. Zudem könnte ich die Laien-kompatiblen Aussagen dort herausfiltern und in einen zusätzlichen Thread mit dem Titel „Firewall FAQ für Laien“ einbinden. Natürlich würden viele Punkte aus der „FAQ für Fortgeschrittene“ dort wegfallen. Lediglich die wichtigsten Einstellungen für Firewalls, ein paar einfache Begriffserklärungen und die grundsätzlichen Verhaltensregeln möchte ich dort in angepasster Form zusammentragen.
Eines ist hierbei sehr deutlich geworden: Die Threads können nur mit eurer Hilfe funktionieren! Das Bewertungssystem soll deshalb im neuen Thread von Anfang an eingesetzt werden und natürlich auch in dem alten Thread weiter Bestand haben. Davon habe ich persönlich nichts – es gibt also KEINE Bonuspunkte für den Account oder dergleichen, die ich mir damit erschleichen könnte oder mit denen ihr meinem Account schaden könnt. Also macht bitte von der Bewertung regen Gebrauch! Danke.
Auch wenn ich mich hierbei wiederhole: Neben dem Sterne-"Barometer" benötige ich dringend eure direkte Kritik (per Beitrag im Thread oder als persönliche Nachricht), denn ich kann nicht Hellsehen. Konstruktive Verbesserungsvorschläge sind natürlich ebenso gerne gesehen. Die FAQ ist für euch gedacht, nicht für mich. So macht es auch keinen Sinn, wenn ihr wie Stöhne den Frust in euch hineinfresst und euch erst viel zu spät Luft verschafft. Wenn der Karren erst einmal gegen den Baum gefahren ist, kann man ihn schlecht in eine andere Richtung lenken! Will sagen: Hätte das jemand früher gesagt, so hätten wir das Missverständnis schon viel früher klären können. Das wäre auch für andere Leser hilfreich gewesen. Zudem war ich von Anfang an für jede Variante bereit: Bei einem etwas intensiveren Engagement solcher Leser, hätte der Thread natürlich ganz andere Formen angenommen.
Ein neuer Thread, ein neuer Versuch. Ihr entscheidet auch diesmal, welche Form er annehmen wird!
Hinweis: Den neuen Thread (FAQ für Laien) möchte ich noch nicht nach Tutorials stellen. Ich werde ihn bis zur Fertigstellung im „Security“-Forum hinterlegen. Ich denke, dass es hier einfach mehr Leser aus der Zielgruppe gibt, als jene, die sich unter Tutorials „verirren“.
Hat jemand von euch andere Vorschläge oder gibt es Einwände?
Ich habe den Thread "Firewall FAQ für Laien" heute Online gestellt. Bitte sagt mir Anhand eurer Bewertung, ob die Richtung so OK ist. Verbesserungsvorschläge sind natürlich gerne gesehen. Danke.
Die Trennung der beiden Threads wurde jetzt fertig gestellt. Der Thread „Firewall FAQ für Fortgeschrittene“ hat dadurch einen etwas anderen Aufbau erhalten (siehe Inhaltsverzeichnis im Eröffnungsbeitrag).
Die Verschiebung der Beiträge hat allerdings zur Folge, dass beide Threads chaotisch geworden sind (der neue Thread enthält nun einen Teil der alten Zusammenfassungen ohne die dazu gehörenden Debatten und in diesem Thread hier fehlen nun etliche Zusammenfassungen). Dem Chaos kann man nur noch mit Hilfe des Inhaltsverzeichnisses Herr werden.
Das kann natürlich nicht so bleiben. Die Lösung: Solange beide Threads noch nicht beendet wurden, belassen wir es, wie es ist (ich wüsste auch nicht, wie ich die bilaterale Form einer Multi-User-FAQ anders realisieren sollte). Nach der Fertigstellung werde ich dann jeden Zusammenfassungsbeitrag herausziehen und in je eine endgültige FAQ untereinander stellen. Damit werden die aktuellen Threads zu diskussionsthreads umgewandelt, auf die ich dann in den Beiträgen verlinken kann. Mit anderen Worten gibt es dann eine FAQ für Laien und eine für Fortgeschrittene, welche wie ein Buch aufgebaut sind (Inhaltsverzeichnis + nahtlos untereinander liegende Beiträge). Also keine Debatten und Zusammenfassungen zu den einzelnen Themen mehr. Dieses Problem lässt sich jedoch wirklich erst dann beseitigen, wenn die Threads zuvor endgültig beendet wurden.
Die Standardeinstellung vieler Firewalls ist auf eine DMZ ausgereichtet, die ähnlich wie Dioden funktioniert, bei denen ein Verbindungsaufbau nur in eine Richtung erlaubt ist. Auf diese Weise wird ein Zugriff der internen Rechner auf die Rechner des DMZ-Netzes ermöglicht. Demgegenüber können die Rechner aus dem DMZ-Netz jedoch keine eigenen Verbindungen zu einem internen Rechner aufbauen.
Zugriffsmöglichkeiten der Rechner pro Netz:
interne Rechner: Die Rechner aus dem internen Netz können auf alle Rechner der DMZ genauso zugreifen, wie auf die Internetserver im externes Netz. Die interne Firewall erlaubt diesen Zugriff, weil der Verbindungsversuch aus dem internen Netz heraus erfolgt. Mit anderen Worten ist der Zugriff ausschließlich von innen nach außen möglich (die internen Rechner sind so vor ungewollten Zugriffen von außen - also aus der DMZ und dem externen Netz - geschützt).
DMZ-Rechner: Die Rechner aus der DMZ können keine eigene Verbindung zu den Rechnern im internen Netz herstellen (die interne Firewall verhindert das). Nicht einmal ein ping wird in diese Richtung funktionieren. Sie können lediglich auf Verbindungen antworten, die von den internen Rechner angefordert wurden (das wiederum erlaubt die interne Firewall). Wie die internen Rechner auch, können die Rechner aus der DMZ jedoch ungehindert auf die Internetserver zugreifen (die externe Firewall erlaubt das). Und natürlich können sie ungehindert auf alle Rechner zugreifen, die sich ebenfalls in der eigenen DMZ befinden.
externe Rechner: Die externen Rechner wie z.B. die Internetserver können von sich aus eine Verbindung zu den Rechnern aus der DMZ aufbauen (in der Regel über Port Forwarding der externen Firewall). Genau wie die DMZ-Rechner sind sie jedoch nicht in der Lage, eine eigene Verbindung zu den internen Rechnern herzustellen (beide Firewalls verhindern das). Sie können lediglich auf Verbindungen antworten, die von den internen Rechner angefordert wurden.
So lässt sich eine halboffene DMZ überwinden:
Es ist schwer, aber nicht unmöglich, die Verbindungsanfragen eines internen Rechners von dem Zielsystem aus derart zu missbrauchen, dass die interne Firewall einen Zugriff auf Ressourcen des internen Rechners erlaubt. Man darf dabei nicht vergessen, dass der DMZ-Rechner in der Hand eines Eindringlings ist und er höchst wahrscheinlich die Kontrolle über alle Dienste des DMZ-Rechners hat, die er auch beliebig durch eigene Programme austauschen kann. Ähnlich wie unter dem PAT-Angriff auf Computer hinter einer externen Firewall beschrieben, könnte z.B. eine FTP-Verbindung zu diesem Rechner dazu verwendet werden, während der Verbindungsanfrage den Rückgabeport der Session zu manipulieren. Auch X-Window bietet mehrere Angriffspunkte für eine Attacke ins interne Netz.
Allerdings muss der Eindringling bei dieser Art des Angriffs darauf warten, dass ein interner Rechner eine entsprechende Verbindung anfordert. Sein Vorteil gegenüber einem externen Server aus dem Internet ist der, dass er an einem Rechner des Unternehmens sitzt, der mit hoher Wahrscheinlichkeit von den internen Rechnern angesprochen wird. Auch kann er ungehindert alle anderen Rechner aus dem DMZ-Netz angreifen und womöglich übernehmen. Zudem muss er von hier aus lediglich die Filter des internen Firewallmoduls überwinden, wohingegen ein externes System zusätzlich die Filter des externen Firewallmoduls bezwingen muss. Die Aussichten für einen erfolgreichen Hack ins interne Netz sind von einem DMZ-Rechner aus also ungleich höher, was jedoch noch lange nicht bedeutet, dass ein solcher Angriff in jedem Fall erfolgversprechend ist.
offene DMZ
Von einer offenen DMZ spricht man, wenn im internen Firewallmodul Regeln festgelegt werden, die es einem Rechner aus dem DMZ-Netz erlauben, eigene Verbindungen zu wenigstens einem Rechner aus dem internen Netz aufzubauen. Das wird unter anderem verwendet, um einem DMZ-eMailserver die Möglichkeit zu geben, eingehende eMails umgehend an den internen eMailserver weiterzureichen. Aber auch Datenbanklookups für Webseiten im E-Commerce-Bereich oder gar Protokollsysteme, die den syslog durchreichen, sind hier nicht selten anzutreffen.
So lässt sich eine offene DMZ überwinden:
Neben den Möglichkeiten, die bereits eine halboffene DMZ bietet, offeriert eine offene DMZ dem Angreifer wesentlich effizientere Methoden, die DMZ zu überwinden. Angenommen der eMailserver aus der DMZ darf für den Abgleich der Daten eine Verbindung zum internen eMailserver aufbauen. Wurde eben dieser DMZ-Server über eine Schachstelle im Netzwerkdienst (D*aemon) der Mailsoftware eingenommen, so stehen die Chancen gut, dass dies auch bei dem internen Server funktioniert, wenn dieser mit demselben Deamon arbeitet. In der Regel wird der interne Server noch wesentlich einfacher zu hacken sein, da interne Server oftmals schlechter geschützt sind und somit aktuelle Sicherheitsupdates fehlen. Anders als bei den Rechnern aus dem DMZ-Netz kann schließlich niemand aus dem Internet direkt auf den internen eMailserver zugreifen, weshalb er augenscheinlich nicht unmittelbar gefährdet ist. Ein fataler Trugschluss. Dabei ist es oftmals gar nicht notwendig, eine DMZ derart zu öffnen. Bezogen auf dieses Beispiel wäre es zeitaufwendiger, aber ungleich sicherer, wenn der interne Server in regelmäßigen Abständen die eMails mit dem DMZ-Server abgleicht, anstatt sich die Daten von dem DMZ-Server schicken zu lassen.
geschlossene DMZ
Am unpraktikabelsten und daher selten zu finden, stellt sich die sicherste Variante in Form einer geschlossenen DMZ dar. Hierbei können die internen Rechner keine Verbindung zu den Rechnern aus dem DMZ-Netz aufbauen. Genauso wenig wie DMZ-Rechner eine Verbindung zu den internen Rechnern herstellen dürfen. Die Rechner aus der DMZ sind somit ausschließlich aus dem externen Netz und über ihre eigene (lokale) Konsole erreichbar.
Lässt sich eine geschlossene DMZ überwinden?
Man kann nicht behaupten, dass es unmöglich ist, eine geschlossene DMZ zu überwinden. Allerdings ergibt das keinen Sinn, den Angriff von hier aus zu starten. Schließlich haben Rechner aus dem externen Netz mehr Zugriffsrechte für die Kommunikation mit den internen Rechnern, als die Rechner aus dem geschlossenen DMZ-Netz. Lediglich direkte Attacken auf das interne Firewallmodul wären von hier aus sinnvoll. Eine entsprechende Schwachstelle der Firewall natürlich vorausgesetzt. Das bedeutet jedoch nicht, dass ein uneingeschränkter Zugriff auf diese Rechner für einen Eindringling uninteressant ist. Die Chance ist auch hier gegeben, dass er den Rechnern wertvolle Informationen entnehmen kann, die ihm bei einer späteren Attacke nützlich sind.
Die „exposed Host“-Falle (eine „DMZ“, die keine DMZ ist)
Um eine DMZ realisieren zu können, werden zwei getrennte Firewallmodule und eine separate DMZ-NIC benötigt. Aus Kostengründen lassen viele Hersteller von billigen Firewalls die dafür benötigte Hardware einfach weg. Ihre so genannte „DMZ“ kann somit keine DMZ-Funktionalitäten unterstützen und macht tatsächlich nichts weiter, als alle Netzwerkanfragen aus dem externen Netz (Internet) an einen Rechner im internen Netz weiterzuleiten, was einem „exposed Host“ entspricht. Dadurch schaltet man den Proxyschutz nebst Firewall für diesen Rechner aus. So ist er nicht nur auf dem einen Port angreifbar, sondern auf allen seinen offenen Ports, was die Angelegenheit natürlich verschlimmert. Da diese (exposed-) DMZ keinerlei DMZ-Funktionalitäten bietet, sollte jedem klar sein: Wird dieser Rechner eingenommen, so hat man den Firewallschutz auch für alle anderen, internen Rechner verloren.
Fazit: Eine pseudo-DMZ a la „exposed Host“ bietet keinen separaten Schutz und macht den Rechner unnötig angreifbar, da Ports zum Rechner geleitet werden, die er für seine Aufgabe nicht benötigt. Demgegenüber leitet eine echte DMZ keine unnötigen Ports zum DMZ-Rechner um und schützt das interne Netz zudem für den Fall, dass ein Angreifer den DMZ-Rechner einnimmt.
So erkennt man eine echte DMZ:
Eine in der Firewall integrierte DMZ stellt ein „drittes Bein“ der Firewall dar. Das bedeutet: Wenn eine Firewall keinen separaten (dritten) Netzwerkanschluß für die DMZ anbietet, dann handelt es sich in der Regel um keine echte DMZ (NIC-1=externes Netz (WAN) / NIC-2=DMZ, NIC-3=internes Netz (LAN), ggf. gekoppelt an einem integrierten Switch). Einzige Ausnahme bilden einige Firewalls mit integriertem Switch oder Router: Selbst wenn sie keinen festen DMZ-Anschluss vorsehen, kann es sein, dass die Firewall den Switch-Port vom Rest des internen Netzes durch einen Filter trennt, sobald man den daran angeschlossenen Rechner in die DMZ stellt.
Es lässt sich ganz leicht testen, ob der Rechner in einer echten DMZ steht oder ob es sich bei der „DMZ“ um einen schlechten „exposed Host“-Verschnitt handelt: Man geht an den Rechner der in der DMZ steht und versucht ''von dort aus'' einen der Rechner aus dem internen Netz per ping zu erreichen. Ist der ping erfolgreich, so ist die DMZ nichts wert. Hier sollte eine andere Firewall eingesetzt werden. Zumindest aber ist unter diesen Bedingungen eine einfache Portweiterleitung besser, als diese Art der „DMZ“ zu nutzen.
Hinweis: Dass die anderen, internen Rechner den DMZ-Rechner anpingen können, ist normal. Nur umgekehrt darf dies nicht funktionieren.
Im normalen Betrieb leitet die Firewall Verbindungsanfragen ausschließlich aus dem internen Netz zum Internet weiter. Um die Antwortpakete zurückschicken zu können, teilt sie jeder Verbindung einen eigenen Rückgabeport zu. Auf diesen Rückgabeport darf nur das angesprochene Zielsystem zugreifen. Dort eingehende Pakete leitet die externe Firewall an den ursprünglichen Rückgabeport des internen Rechners zurück.
Stellt ein Rechner aus dem Internet jedoch eine Anfrage an einen Port der Firewall, welcher ihm nicht zugewiesen wurde, so wird die Anfrage ignoriert. Dadurch werden die Rechner im internen Netz vor unerlaubten Zugriffen aus dem externen Netz geschützt.
ausgehende Verbindung: [interner Rechner (IP1) / Applikation1 = Port 123] -- Anforderung an Internetserver (IP3:Port80) / Absender IP1:Port123 --> [Firewall (IP2) / diese Verbindung = Port 456] – Anforderung an Internetserver (IP3:Port80) / Absender IP2:Port456 -->[Internetserver (IP3) / Port 80=http-Dienst]
Antwortpakete: [Internetserver (IP3) / http-Dienst = Port 80 (der Einfachheit halber)] -- Antwort an Firewall (IP2:Port456) / Absender IP3:Port80 -->[Firewall (IP2) / Port 456 = Rückkonvertierung zur IP1:Port 123] -- Antwort an internen Rechner (IP1:Port123) / Absender IP3:Port80 -->[interner Rechner (IP1), Port 123=Applikation1]
Die Kommunikation mit Port Forwarding:
Möchte ein interner Rechner einen Dienst bereitstellen, auf den beliebige Rechner aus dem externen Netz (dem Internet) zugreifen sollen, so muss man der Firewall einen Port bekannt geben, dessen Anfragen nicht blockiert werden sollen. Man legt auf der Firewall also eine Port-Regel an, die besagt, dass alle Anfragen auf diesen Port von außen automatisch an den internen Rechner weitergereicht werden sollen. Der interne Rechner kann die Anfragen nun bearbeiten.
Anforderung aus dem Internet: [externer (Internet-) Rechner (IP3) / Applikaiton5 = Port 789] -- Anforderung an IP2:Port80 / Absender IP3:Port789 -- externes Netz (Internet) --> [Firewall (IP2) / Port 80 = Weiterleitung an internen Rechner IP1:Port80] -- internes Netz -- Anforderung an internen Rechner (IP1:Port80) / Absender IP3:Port789 -->[interner Rechner (IP1) / Port 80=http-Dienst, der die Anfrage nun entgegennimmt]
Die weitere Kommunikation dieser Sitzung: wie oben beschrieben (Die Kommunikation ohne Port Forwarding / ausgehende Verbindung & Antwortpakete)
Eine Firewall kann VPN auf dreierlei Art unterstützen:
Einige Firewalls können selber als VPN-Einwahlknoten für externe „Home-Anwender“ fungieren (manchmal wird dies nicht durch einen eigenen Dienst auf der Firewall, sondern durch einen VPN-Konzentrator-Modus realisiert, was bedeutet, dass die eingehenden VPN-Anfragen an einen eigenen VPN-Server weitergereicht werden).
Professionelle Firewalls bieten oft eine VPN-Verbindung zu einer weiteren Firewall an und ermöglichen es so, zwei „private Netze“ über das Internet hinweg miteinander zu verbinden (also eine Kopplung von zwei Firmennetzen über 2 VPN Gateways, welche sich in der Firewall befinden).
Die meisten Firewalls bieten jedoch schlicht eine Unterstützung des VPN-Tunnels an – also eine Möglichkeit, durch die Firewall hindurch eine VPN-Verbindung zu einem externen VPN-Knoten aufzubauen. Diese Unterstützung gilt aber lediglich für einen einzigen Client, da der VPN-Rückgabekanal mit dem Rechner verbunden werden muß (per Port-Forward-Regel). Für eine flexible Regel bieten einige Firewalls den „VPN Pass-Through“-Modus an.
Hintergrundinformation:
Mit VPN werden Datenpakete eines >>beliebigen<< Protokolls verschlüsselt und verpackt übers Internet gesandt (mehr zum Thema VPN-Verschlüsselung: siehe den Beitrag von Catweazle).
Das VPN-Verfahren wird Tunneling genannt, da für die Übertragung zwischen den VPN-Knoten sämtliche Netzwerkpakete in ein anderes Protokoll verpackt werden.
Das Internetprotokoll TCP/IP dient VPN lediglich als Transportmittel. Der Inhalt der Netzwerkpakete und die Art des Tunnels werden durch andere Protokolle bestimmt. Es gibt verschiedene Tunneling- bzw. VPN-Protokolle. So ist es z.B. möglich, eine VPN-Verbindung via IPSec (Internet Security Protocol) oder PPTP (Point-to-Point Tunneling Protocol) aufzubauen.
Im Zuge der letzten Zusammenfassung ist noch eine weitere Frage hinzugekommen, welche ich in der nächsten Zusammenfassung mit eurer Hilfe beantworten möchte:
Was versteht man unter dem Begriff „Tunneln“? Und wie lässt sich damit eine Firewall umgehen?
Als "Tunneln" bezeichnet man das leiten von Netzwerkverkehr eines Prtokolls (z.b. HTTP oder VNC) durch ein anderes (z.b. SSH).
Angewandt sieht das dann so aus:
Auf dem Server-System läuft z.b.
- eine Firewall, die nur port 22 offen hat (SSH)
- ein SSH server
- ein VNC Server
Auf dem Client System ist ein
- SSH client (z.b. putty)
- VNC client
installiert.
Problem:
Um vom Clientsystem aus den Server zu steuern (mittels des VNC Protkolls) müsste man die Firewall ausschalten, da diese eine Verbindung über port 5900 (VNC default port) nicht zulässt (in unserem Beispiel)
Außerdem ist VNC per default unverschlüsselt, sodass z.b. jemand das passwort abhören könnte.
Lösung:
Das SSH Protokoll erlaubt ein "Tunneln" von anderen diensten über SSH.
Hierzu baut man eine SSH Verbindung auf, und legt dabei einen Tunnel fest, indem man für den eigentlichen port auf dem Server (=remote port) einen lokalen port festlegt (=local port). Der Netzwerkverkehr der dann an den lokalen port geschickt wird, wird von SSH durch den Tunnel (der eigentlich nur zwischen dem SSH client port auf der client seite und port 22 auf der server seite besteht) geleitet und kommt schließlich auf dem Server am remote port an
unter putty kann man einen tunnel unter
Connection -> SSH -> Tunnels festlegen, hierzu einfach als "sourceport" den local port eintragen und als destination den Socket des Servers.
in unserem Bsp:
Source Port: <Frei wählbar> (ich empfehle den gleichen port also 5900)
destinantion: <IP-Adresse des Servers>:5900
-> Add klicken
dann kann man im VNC client als server localhost:localport tippen, also wenn man als localport (oder Source port in putty 5900 verwendet)
localhost:5900
Was ist jetzt wirklich so toll daran?
-> SSH ist verschlüsselt!
-> man kann effektiv alles tunneln!
-> man kann doppelte Tunnel erstellen (VPN aufmachen + SSH Tunnel erstellen)
soweit mein "kleiner" praktischer Ausflug in die Welt der Tunnel
Du beschreibst hier Tunneling schon völlig korrekt, aber ein Unterschied von VPN Tunneling zu "Tunneling per Hand" ist halt, dass es für die Endnutzer transparent ist.
Aushebeln von Firewallrichtlinien: Der Weg zum Tunneln
Nehmen wir einmal an, ein Firmenmitarbeiter betreibt privat einen Server im Internet. Nachdem sein Arbeitgeber das Firmennetz mit dem Internet verbunden hat, könnte er nun nach belieben aus dem Firmennetz heraus auf seinen privaten Server zugreifen. Ohne jegliche Restriktionen wäre es ihm so z.B. möglich, zwischen seinem Arbeitsplatz und dem privaten Server per ftp Dateien zu kopieren. Dazu muss auf seinem Internetserver lediglich ein ftp-Dienst laufen, welcher am Standard-ftp-Port (Port 21) auf seine Anfragen wartet. Auf seinem Arbeitsplatz installiert er nun ein beliebiges ftp-Client-Programm, welches in der Lage ist, den Dienst zu nutzen und Daten mit seinem Server auszutauschen.
Um so etwas zu verhindern, installiert der Arbeitgeber in unserem Beispiel zunächst eine Paketfilter-Firewall, welche die Kommunikationsversuche zwischen dem Firmennetz und dem Internet filtert. Die Firewall wird so konfiguriert, dass sie lediglich Anfragen an Port 80 zum Internet durchlässt, was zu Folge hat, dass nur noch Internetseiten angezeigt werden können (sämtliche Standard-Ports anderer Dienste werden blockiert – so auch Port 21 für ftp).
[PC des Mitarbeiters]--internes Netz (Firma)-->[Firewall=nur Port 80 in Richtung Internet erlauben]--externes Netz-->[Internetserver]
Nun sucht der Mitarbeiter nach einem Weg, diese Sperre zu überwinden...
Eine einfache Methode ist es, den Dienst auf seinem Internetserver so umzuprogrammieren, dass er nicht mehr am Standardport 21 lauscht, sondern den Port 80 für ftp-Anfragen akzeptiert. Nun muss er noch die ftp-Client-Software dahingehend ändern, dass sie die Anfrage an seinen Server auf Port 80 und nicht auf Port 21 stellt. Und schon läuft seine private ftp-Verbindung wieder.
Schritt eins des Tunnels wurde erreicht: Die Anfragen an seinen Dienst laufen einfach über einen anderen, freigegebenen Port, welcher eigentlich für einen anderen Dienst reserviert wurde (hier der http-Port 80).
Ein Nachteil dieser Methode zeigt sich darin, dass der Mitarbeiter nun keinen x-beliebigen ftp-Client oder Dienst mehr verwenden kann, sondern immer auf die von ihm angepasste Version angewiesen ist. Eine elegantere Methode soll helfen, das Problem zu überwinden: Statt die Software des Clients oder Servers umzuschreiben, installiert er einfach ein zusätzliches Hilfsprogramm in Form eines Port-Forwarding-Tools, welches die Anfragen des ftp-Clients auf Port 21 entgegennimmt und sie automatisch auf Port 80 umleitet. Auf dem Server läuft ebenfalls ein solches Tool, welches die Anfragen an Port 80 entgegennimmt und einfach an den Port 21 des eigenen Servers zurückreicht. Der Vorteil ist, dass dieses Tool mit beliebigen ftp-Clients und Diensten zusammenarbeitet, ohne dass deren Software angepasst werden muß.
Schritt zwei des Tunnels wurde erreicht: Eine programmunabhängige, automatische Umleitung des Ports, genannt „local port forwarding“, wurde realisiert.
Dieser Mechanismus funktioniert so lange, bis der Arbeitgeber statt der Paketfilter-Firewall eine Application Level Firewall (ALF) verwendet, welche in der Lage ist, in die Netzwerkpakete hineinzusehen. Diese Firewall bemerkt nun, dass die Netzwerkpakete nicht http-Konform sind und blockiert diese einfach. Es reicht also nicht, die Pakete per „local port forwarding“ umzuleiten, sie müssen im gleichen Atemzug durch das Umleitungsprogramm auch in das entsprechende Format umgewandelt und auf der anderen Seite wieder in das ursprüngliche Format zurückkonvertiert werden. In unserem Beispiel wird das Format des http-Dienstes also quasi als Verpackung verwendet, um darin hinterlegte, beliebige Daten für die ftp-Verbindung zu transportieren.
Der dritte und letzte Schritt des wirklichen Tunnelns wurde erreicht: Die automatische Konvertierung in ein gültiges Protokoll, damit die Kommunikation auch weiterhin dem RFC-Standard entspricht.
Zu Schritt 2 („local port forwarding“): eine Serverapplikation verwenden
Oben wurde unter Schritt 2 geschrieben, dass man mit Hilfe eines „local port forwarding“-Tools einfach den Port umleitet und daher keine Änderung der Clientsoftware durchführen muss. Das stimmt leider nicht ganz, denn dieser Automatismus ließe sich nicht einrichten, wenn man auf dem System keine Administrationsrechte hat. Auch hier sollte eine elegantere Lösung helfen, das Hindernis zu überwinden:
So hängt sich die clientseitige Port-Forwarding-Software nicht in den IP-Stack, um ausgehende Anfragen an Port X automatisch nach Port Y umzuleiten. Vielmehr lauscht sie an einem eigenen Port des PCs, um alle Pakete, welche an diesem Port eingehen, umleiten zu können. Mit anderen Worten läuft die Port-Forwarding-Software als Serverapplikation auf dem PC, sodass der PC Anfragen an einem seiner eigenen Ports entgegennehmen kann. Sämtliche Anfragen an diesen Port werden der Tunnelsoftware übergeben.
In unserem Beispiel wird nun das ftp-Client-Programm so konfiguriert, dass es seine Anfragen nicht mehr an das Zeilsystem auf Port 21 schickt, sondern an den eigenen Rechner (localhost) auf den Port der Port-Forwarding-Software sendet (Zielsystem = „localhost:Port X“). Die Port-Forwarding-Software wird wiederum so konfiguriert, dass sie alle Pakete, welche an Port X eintreffen automatisch an das Zielsystem auf Port Y weiterreicht (Zeilesystem = „IP-Adresse oder DNS-Name des Servers:Port Y“). Der Vorteil: Die Port-Forwarding-Software benötigt keine Administrationsrechte mehr, um dies zu tun. Zudem können nun mehrere lokale Ports verwendet werden, die man einzeln konfigurieren und mit unterschiedlichen Zielen verbinden kann.
Wenn man sich jetzt noch verdeutlicht, dass die Port-Forwarding-Software wie oben unter Schritt 3 beschrieben auch die Protokollkonvertierung vornimmt, so lässt sie sich zusammenfassend als „Tunnelsoftware“ betiteln. In unserem Beispiel ergibt sich folgendes Schema:
ftp Client, Ziel=“localhost:XX“-->Port XX=Eingangsport der Tunnelsoftware auf dem PC, welche das ftp-Protokolls in http umwandelt-->weiterleiten an „Zielserver:Port 80“
Auf dem Server läuft die Tunnelsoftware nach demselben Prinzip – nur genau anders herum (sie lauscht am Tunnelport, konvertiert alle dort eingehenden Pakete in das Ursprungsformat zurück und leitet sie dann zum Bestimmungsport weiter):
Zielserver:Port 80=Eingangsport der Tunnelsoftware, welche das Protokoll in ftp zurückkonvertiert-->weiterleiten an „localhost:21“ (21=Port des lokalen ftp-Dienstes)
Das besondere am interaktiven SSH-Tunnel gegenüber einem starren Tunnel ist, dass er jedes Protokoll eines beliebigen Dienstes weiterleiten kann. Zudem lässt sich der Remote-Port des Servers vom Client aus konfigurieren. Dadurch wird es ermöglicht, jeden verfügbaren Dienst des Servers über den SSH-Tunnel anzusprechen, ohne den serverseitigen Tunnelpartner umkonfigurieren zu müssen. Zudem lässt sich über die Option „Remote-Host“ vom Client aus auch ein Dienst eines beliebigen Rechners hinter dem Tunnel ansprechen.
Einen flexiblen Tunnel verwenden: die Schritte 1 und 2 dynamisieren
Im Vergleich zum bisher gezeigten starren Tunnel ist das besondere am interaktiven Tunnel, dass sich der Remote-Port des Servers vom Client aus konfigurieren lässt. Dadurch wird es möglicht, jeden verfügbaren Dienst des Servers über den Tunnel anzusprechen, ohne den serverseitigen Tunnelpartner umkonfigurieren zu müssen. Sie können jedes Protokoll eines beliebigen Dienstes weiterleiten. Zudem lässt sich über die Option „Remote-Host“ vom Client aus in der Regel auch ein Dienst eines beliebigen Rechners hinter dem Tunnel ansprechen.
[PC des Mitarbeiters->Tunnelsoftare=Verbindung zum Tunnelserver:PortX herstellen/Verbindungsoption:Remote-Host (Tunnelserver oder ein beliebiger Server hinter dem Tunnel):PortY (Port des Dienstes für den die Daten tatsächlich bestimmt sind)]--internes Netz (Firma)-->[Firewall=PortX in Richtung Internet ist erlaubt]--externes Netz-->[Internetserver (Tunnelserver)/Pakete auspacken und weiterreichen an das durch die Verbindungsoption angegebene Zielsystem (Remote-Host:PortY)]
Neben dem interaktiven Tunnel gibt es auch Tunnel, die sämtliche Pakete in das Netz des Tunnelservers weiterleiten, wodurch sich alle Rechner seines Netzes vom Tunnelclient praktisch direkt ansprechen lassen. Beispiele für beide Tunnelarten:
Ein Tunnel mit interaktiver Port- und „Remote-Host“-Weiterleitung, welche sich individuell auf dem Client konfigurieren lässt, ohne den serverseitigen Tunnelpartner vor Ort anpassen zu müssen. Beispiel: der SSH-Tunnel
Ein Tunnel, welcher ungesehen alle Port- und Host-Anfragen weiterreicht und damit sogar eine uneingeschränkte Verbindung zweier Netzwerke zulässt. Beispiel: der VPN-Tunnel
Einen Tunnel ohne Portumleitung realisieren
In den meisten Fällen, in denen über Tunneling gesprochen wird, handelt es sich tatsächlich um die oben erwähnten drei Schritte (Tunneling=Kommunikation über einen anderen Port per Port-Umleitung und einer entsprechenden Protokollkonvertierung). Wenn man versucht zu verstehen, wie man per Tunneling eine Firewall umgehen kann, so ist es anfänglich verständlicher, wenn man sein Augenmerk auf die ersten beiden Schritte lenkt. Allerdings sind die Schritte 1 und 2 nicht unbedingt erforderlich, um einen Tunnel zu realisieren. Um das zu verstehen, wird der folgende Tunnel etwas näher beleuchtet:
Ein Tunnel ohne Port Forwarding. Beispiel: der DNS-Tunnel
weiterführende Links:
Einen verständlichen Artikel über Tunneling findet Ihr bei heise.de.
Und ein kleiner praktischer Ausflug zum Thema Tunneling wurde in einem Beitrag von tele hinterlegt.
DNS (Domain Name System oder auch Domain Name Service genannt), ist für die Umsetzung der Domain Namen in die dazugehörige IP-Adresse und umgekehrt für die Umsetzung von IP-Adressen zum jeweiligen Domain Namen zuständig. Das DNS-Verfahren wird durch eine verteilte Datenbank realisiert.
Die Namensauflösung im Detail
Nachdem eine Netzwerkanfrage gestartet wurde, sieht das System aus historischen Gründen zunächst in die lokale Datei namens hosts. Über diese Datei wurden vor der Erfindung des DNS alle Internetserver eingetragen. Diese Methode hatte aber den Nachteil, dass die Datei bei zunehmender Serveranzahl immer größer wurde und zudem auf alle Rechner kopiert werden musste. Wird der Rechnername hier nicht entdeckt, geht die Anfrage an den DNS-Server, welcher in der Konfiguration der Netzwerkkarte unter den TCP/IP-Einstellungen eingetragen wurde. In einem privaten Netz wird das mit hoher Wahrscheinlichkeit der eigene DNS-Server sein, welcher sich in dem DSL-Router befindet.
Nun stellt sich zunächst die Frage, weshalb man in der DOS-Konsole „ping www.tweakpc.de“ erfolgreich ausführen kannst, obwohl der DNS-Dienst des privaten Netzes die IP-Adresse von tweakpc.de nicht kennen dürfte. tweakpc.de ist ja schließlich kein Rechner aus dem privaten Netz. Das geht dennoch, da der DNS-Dienst die Anfrage an die nächst höhere DNS-Instanz im Internet weiterreicht. Das funktioniert allerdings nur, wenn das private Netz nebst DNS-Server mit dem Internet verbunden ist.
Wenn der mit dem Internet verbundene Netzwerkadapter des DSL-Routers nicht anders konfiguriert wurde, geht die Anfrage als erstes an den DNS-Server des eigenen Internetproviders. Kennt er den gesuchten Rechnernamen nicht, so wird der DNS-Server der DeNIC befragt, da er alle Adressen mit der Endung .de verwaltet. Hier ist also auch tweakpc.de registriert. Allerdings verwalten die übergeordneten DNS-Server nicht die Adressen der Webserver, sondern nur die Adressen der zuständigen DNS-Server des Providers, welcher die Domain hosted. Mit anderen Worten erhält man von der DeNIC die Adresse des Internetprovider-DNS-Servers, welcher die Domain tweakpc.de verwaltet (=>ns.tweakpc.de).
Nun wird die Anfrage automatisch dorthin weitergereicht, worauf der DNS-Server die zur Anfrage gehörende IP-Adresse zurückschickt.
Hinweis: Die Antwort wird nun zusätzlich im DNS-Server des eigenen Internetproviders zwischengespeichert, sodass eine erneute Adressanfrage an www.tweakpc.de diesen langen Weg nicht mehr gehen muss. Wie lange diese Information zwischengespeichert bleiben darf, wurde im Antwortpaket des DNS-Servers (ns.tweakpc.de) vorgegeben.
Eine Firewall mit Hilfe eines DNS-Tunnels umgehen
Bei einem DNS-Tunnel wird der eigene Aufbau des DNS-Protokolls für den verborgenen Datentransfer missbraucht (genauer das „Name Server Transfer Protocol“).
Wie lässt sich ein DNS-Dienst für einen Tunnel missbrauchen?
Wurde – wie in unserem Beispiel – nach der Adresse www.tweakpc.de gefragt, so liefert der DNS-Server des Providers, welcher die Domain hosted, die Webadresse von tweakpc.de zurück. Der DNS-Server kann aber auch weitere Subdomains von tweakpc.de verwalten. Je nachdem, wie der DNS-Server konfiguriert wurde, könnte die Anforderung an bla.tweakpc.de durchaus eine andere Adresse zurückliefern.
Vorausgesetzt der Server teilt dem Providerserver per Protokolleintrag mit, dass diese Adressen nicht zwischengespeichert werden dürfen, wird bei jeder Anfrage nach (xyz.)tweakpc.de genau dieser DNS-Server befragt. Und genau hier liegt der Angriffpunkt.
So funktioniert der DNS-Tunnel
Auf dem DNS-Server des Internetproviders wird die serverseitige Tunnelsoftware installiert. Auf dem Client läuft eine clientseitige Tunnelsoftware. Der Client startet nun darüber die folgende Anfrage: Gib mir die Adresse von HoleGeheimeDatenInsNetz.tweakpc.de. Die Tunnelsoftware des o.g. DNS-Servers erkennt in der angefragten Sub-Domain-Adresse seinen Befehl. Statt eines Fehlers liefert er nun irgendeine IP-Adresse zurück. Der Trick: Das „Name Server Transfer Protocol“ erlaubt es, weitere Daten „ganz legal“ in die Antwortpakete zu integrieren. Und hier kommt die clientseitige Tunnelsoftware ins Spiel: Sie muss die zusätzlich hinterlegten Daten auslesen und interpretieren können. Deshalb braucht es hier – wie bei einem Tunnel üblich – eine client- und eine serverseitige Tunnelsoftware.
Über den Subdomain-Namen lässt sich also der DNS-Tunnelserver fernsteuern und über die Clientsoftware die so heimlich aus dem Internet eingeschmuggelten Daten interpretieren. Und diese Kommunikation geht an der Firewall vorbei.
Wie lässt sich ein DNS-Tunnel unterbinden?
Eine wirkungsvolle Möglichkeit ist es, den DNS-Dienst nicht mit dem Internet zu verbinden. Dann lassen sich im privaten Netz allerdings auch keine Namen der Internetserver mehr auflösen. Das hat zur Folge, dass eine Internetverbindung grundsätzlich nicht mehr per transparent Proxy möglich ist. Jede Software, welche mit dem Internet kommunizieren will, benötigt dann die Angabe des (Internet-) Proxys.
Linkliste:
Einen ausführlichen und leicht verständlichen Artikel über DNS findest Du im Beitrag von tele.
Der schweizerische Sicherheitsdienstleister „Compass Security Network Computer“ (CSNC) bietet einen kostenlosen DNS-Tunneltest an. Sie haben dafür einen speziellen Client für Windows entwickelt und stellen zudem einen DNS-Server mit ihrer Tunnelsoftware zur freien Verfügung. Eine ausgezeichnete Möglichkeit, um selbst zu testen, ob das eigene Netzwerk für DNS-Tunnel anfällig ist.
Wow. Das ist erstmal geschafft. Ich kann allerdings nicht versprechen, daß ich die beiden noch offenen Punkte bis Ende der Woche nachreichen kann. Mal sehen, was meine Zeit noch hergibt.
So ganz zufrieden bin ich mit dem Tunnelbeitrag nicht. Ich bin mir nicht sicher, ob das Ganze nicht noch einfacher und - wenn möglich - kürzer zu erklären geht. Hatte leider wenig Zeit für den Artikel und etwas besseres ist mir bisher einfach nicht eingefallen. Wenn jemand eine Idee dazu hat, dann nur raus damit.
@tele: Hast Du noch immer vor Deinen DNS-Beitrag wie angekündigt im Punkt 4.2 (Nameserver) zu vervollständigen? Das würde Dein Werk perfekt abrunden.
AW: Was ist eine Firewall? 
Es ist gar nicht so einfach, daß alles in einer kurzen, verständlichen Form zu erklären (Was ist Tunnelung? Was ist ein geschlossenes Netz in einem Trägernetz? Und wie werden die Datenpakete über VPN verschlüsselt?). Da könnte ich wirklich Hilfe gebrauchen. Kannst Du bitte noch etwas näher darauf eingehen? 
) 
Linear-Darstellung
