@sys3Dem stimme ich zu. Allerdings sollte es doch reichen, wenn die Gefahr (also „Achtung! Es gibt Hacker!“) allgemein bekannt ist und nicht die Lösung. Der Anwender >>muß<< sich dann selber informieren. Wenn Du einem Nachbar erzählst, daß es eine Gefahrenquelle auf seinem Grundstück gibt und ein paar Monate danach verletzt Du Dich dort, dann kann er sich auch nicht darauf berufen, daß Du ihm nicht darauf hingewiesen hast, daß ein Zaun das Problem lösen könnte.
Zudem gibt es ja noch den Grundsatz: Unwissenheit schützt vor Strafe nicht.
Das Problem ist, daß es an eindeutigen Gesetzen dazu fehlt. Aus diesem Grund versuchen wir ja hier krampfhaft, das Debakel mit parallelen auf die alten Gesetze abzubilden (wobei wir gewiss einige Fehler machen). Das es keine entsprechenden Gesetze für das Internet gibt, war ja klar. Dafür sind die Gesetze viel zu alt. Aber ich habe wenigstens auf etwas >>Greifbares<< gehofft, was sich darauf anwenden läßt. Ich selber habe nichts Eindeutiges dazu gefunden. Viele Dinge widersprechen sich da.
Mich beschäftigt dieses Thema ja nicht erst seit heute. Ich habe mich schon mit vielen Menschen darüber unterhalten, viele Artikel im Internet gelesen (allerdings nie etwas eindeutiges gefunden ) und mich auch mit Rechtsgelehrten darüber unterhalten. Und selbst bei Denen herrschen unterschiedliche Ansichten (wobei ich erwähnen muß, daß dort niemand mit dem Spezialgebiet Internetrecht dabei war). Summa Summarum gibt es mehr Stimmen, die meinen, daß es auch bei einer Privatperson eine grobe Fahrlässigkeit darstellen könnte, wenn auf deren System weder ein Virenscanner, noch eine Firewall installiert ist. Was eine grobe Fahrlässigkeit in Bezug auf diese Thematik genau darstellt, ist allerdings nirgends festgelegt (logisch, weil die Gesetze zu alt sind). Mit anderen Worten entscheidet das der Richter. Liegt aber eine grobe Fahrlässigkeit vor, so ist auch eine Privatperson rechtlich angreifbar.
Bei Geschäftspersonen herrscht die fast einhellige Meinung, daß diese in jedem Fall rechtlich zur Verantwortung gezogen werden können. Was aber unterscheidet ihn von einer Privatperson? In Bezug auf das PC-Fachwissen doch oftmals nichts, oder?
Das alles ist schon ziemlich schwer zu überschauen und hier scheint es leider auch niemanden zu geben, der uns etwas Handfestes dazu sagen kann. Ich möchte aber spätestens morgen Abend die nächste Zusammenfassung schreiben. Den Hinweis auf die Haftbarkeitsproblematik möchte ich auf jeden Fall darin aufnehmen, da sie sehr wichtig ist. Also habe ich vor, dort folgendes festzuhalten:
„… Mit anderen Worten greift der Hacker über das Netz auf Deinen PC zu und geht von dort aus (sozusagen unter Deinem Namen) auf das System, welches er angreifen will. Damit verschleiert er seine eigene Absenderadresse. Im >>schlimmsten Fall<< wird der Betreiber des PCs oder Netzwerkes - also Du – dafür rechtlich zur Verantwortung gezogen. Zunächst wirst Du des Hackens verdächtigt und bist in Erklärungsnot. Aber selbst wenn Du nachweisen kannst, daß jemand aus der ferne Deinen PC für den Angriff missbraucht hat, >>könnte<< es ein rechtliches Problem für Dich geben: Wurde auf Deinem System keine Firewall installiert und hätte eine Firewall die Übernahme Deines PCs verhindern können, so könnte ein Richter der Auffassung sein, daß Du grob fahrlässig gehandelt hast. In diesem Fall >>könnte<< eine Klage gegen Dich (sogar als Privatperson) erfolgreich sein, da Du Deiner Sorgfallspflicht nicht nachgekommen bist und ein anderer dadurch Schaden erlitten hat. Dadurch, daß Dein System nicht richtig vor Missbrauch geschützt wurde, war es dem Hacker erst möglich, darüber hinweg in andere Systeme einzudringen und seine Adresse zu verschleiern. Grundlegend haftest Du für Dein Eigentum und so obliegt es auch Deiner Verantwortung, den PC (oder Server) vor Missbrauch zu schützen. Das alles greift natürlich nur in einem vertretbaren Rahmen. Das bloße Vorhandensein einer Firewall und eines Virenscanners sollte ausreichend sein, um eine grobe Fahrlässigkeit Deinerseits sicher auszuschließen. Für mehr Infos darüber lese bitte die vorherigen Beiträge.“
Was hältst Du davon? Ich möchte damit auf die >>mögliche<< Gefahr einer rechtlichen Konsequenz aufmerksam machen. Kann ich das so formulieren?
Verdammt, daß passiert mir aber auch immer wieder.
Bye, Ronald
hallo,
ich bin neu hier in diesem forum und habe folgendes problem.
wir haben seit januar 2004 dsl bekommen, an dem wlan-router waren 3 rechner dran, u.a. ein notebook.
wir haben den router (sinus154) nicht passwort geschützt, da wir in einer kleinen ortschaft wohnen.
das dsl hat uns ein bekannter eingerichtet, der längere zeit bei uns wohnte.
im dezember, passierte es dann, alle unsere rechner wurden beschlagnahmt durch eine hausdurchsuchung.
angeblich wurde einer unserer rechner, oder auch alle 3 rechner zum datenmissbrauch bei ebay verwendet.
die rechner befinden sich immer noch in untersuchung.
es war an keinem rechner ein firewall eingeschaltet, die 3 rechner werden von uns, ( meine frau und ich, und auch öfters freunde unterschiedlich genutz, praktisch weiss jeder von jedem sein passwort.
am router war glaube ich die firewall auch nicht an.
nun meine frage, kann ein aussenstehender an unsere rechner drankommen, die waren ja praktisch immer eingeschaltet, ist es möglich daten auf unsere rechner zu spielen, etwa logfiles oder cookies, das es dann so aus sieht als wäre es von einem unserer rechner passiert? ist das möglich ?
ich habe gelesen wenn es ein sog. DOS ist dann müsste man unter win/system an jenem " Tattag " bufferoferflow oder ähnliches sehen.
danke
ich habe Deinen Beitrag mal in das Security-Forum gestellt, da er hier nicht zur aktuell diskutierten Thematik der FAQ passt. Dort gehe ich dann näher darauf ein.
Zusammenfassung zum Thema: Tunneln durch die Firewall / ein Tunnel mit dynamischer Portumleitung: der SSH-Tunnel
SSH (Secure Shell) ist sowohl ein Programm als auch ein Netzwerkprotokoll, welches eine gesicherte und verschlüsselte Verbindung zwischen zwei Rechnern ermöglicht. SSH findet auf unterschiedliche Weise Anwendung:
Ähnlich wie bei den Programmen rlogin, telnet und rsh kann man sich mit Hilfe des Programms ssh auf einem entfernten Computer einloggen, eine Konsole öffnen und dort Programme ausführen. Im Unterschied zu den alten Techniken ermöglicht das dabei verwendete SSH-Protokoll eine abhörsichere Verbindung zwischen den Rechnern.
Das SSH-Protokoll wird ebenfalls bei den Programmen SFTP und SCP für den gesicherten Dateitransfer als Alternative zu den kryptographisch unsicheren ftp und rcp verwendet.
Über SSHFS lässt sich ein entferntes Dateisystem mounten, wobei der Datentransfer dank des SSH-Protokolls verschlüsselt übertragen wird.
Zudem wurde der SSH-Netzwerkdienst entwickelt, um Netzwerkprotokolle beliebiger Dienste mithilfe des SSH-Protokolls übertragen zu können. Dafür packt ein Hilfsprogramm auf dem Client die zu übertragenen Netzwerkpakete in das SSH-Protokoll und schickt diese dann mit entsprechenden Instruktionen an den SSH-Dienst des Servers. Dadurch ist es möglicht, die Netzwerkpakete zu verschlüsseln und auf der Gegenseite wieder zu entschlüsseln, bevor sie an den Netzwerkdienst weitergereicht werden, für den die Daten tatsächlich bestimmt sind. Auf diese Weise wird eine verschlüsselte Datenübertragung über unsichere Netzwerke hinweg auch für Netzwerkdienste realisiert, die normalerweise über keine eigene Verschlüsselung verfügen. Als Beispiel kann darüber eine ansonsten unverschlüsselte VNC-Verbindung abgesichert werden. Da hierfür die Daten des genutzen Dienstes in das SSH-Protokoll eingebettet werden, spricht man vom Tunneln.
Der SSH-Tunnel: Wurde die Firewall so konfiguriert, dass sie den Port 22 (SSH) für Verbindungen zum Internet zulässt, so ist es nun möglich, einen SSH-Tunnel zu einem Internetserver einrichten. Dank des Aufbaus eines SSH-Tunnels ist man dann in der Lage, sämtliche Netzwerkdienste des Zielsystems, als auch die Netzwerkdienste der Rechner hinter dem Zielsystem zu nutzen – also auch jene Dienste, welche durch die Firewall eigentlich gesperrt sind.
Um bei unserem Beispiel aus dem Tunnel-Beitrag zu bleiben, installiert der Mitarbeiter dazu auf seinem privaten Internetserver (im Folgenden Tunnelserver genannt) einen SSH-Dienst, welcher an dem SSH-Standardport 22 lauscht und so auf seine Anfragen wartet. Auf dem Arbeitsplatz-PC installiert er ein beliebiges SSH-Client-Programm.
Die Grundkonfiguration der Tunnelsoftware (SSH-Client-Programm)
Port X (Listen- oder auch Source-Port genannt): Hier muss ein beliebiger, freier Netzwerkport des eigenen Computers angeben werden, den die Tunnelsoftware als Kommunikationsport nutzen darf.
Kommunikationspartner: Hier trägt man den Tunnelserver und den Port des SSH-Dienstes (Port 22) ein.
Remote Host: Will man auf einen Dienst zugreifen, der auf dem Tunnelserver läuft, so lässt man diesen Eintrag hier leer oder trägt dort „localhost“ ein. Die folgenden Beispiele beziehen sich zunächst auf diese Einstellung. Soll ein Dienst angesprochen werden, der auf einem Rechner hinter dem Tunnelserver läuft, dann siehe unter „den SSH-Tunnel als Forward-Gateway verwenden“.
Port Y (Remote- oder auch Destination-Port): Hier legt man fest, an welchen Dienst des Tunnelservers die Pakete schlussendlich geschickt werden sollen. Durch Port Forwarding des SSH-Dienstes werden dann alle Pakete nach ihrer Rückkonvertierung dorthin weitergeleitet.
Der Verbindungsaufbau
Sämtliche Pakete, welche nun an Port X des lokalen Computers eingehen, werden von der Tunnelsoftware automatisch verschlüsselt und in das SSH-Protokoll gepackt. So aufbereitet werden die Daten an den Tunnelserver auf Port 22 (zum SSH-Dienst) geschickt:
Eingehende Netzwerkpakete am PC-Port X-->Tunnelsoftware=verschlüsseln der Pakete + einbetten in das SSH-Protokoll-->weiterleiten an „Tunnelserver:Port 22“
Der SSH-Dienst des Tunnelservers extrahiert die Daten aus dem SSH-Protokoll und entschlüsselt sie. Auf diese Weise werden die Pakete in das Ursprungsformat zurückkonvertiert, ohne das der SSH-Dienst das Ursprungsformat kennen muss. Danach leitet der SSH-Dienst die Pakete an den Port Y des eigenen Servers weiter.
Tunnelserver:Port22=Eingang des SSH-Dienstes-->SSH-Dienst=extrahieren der Pakete + Entschlüsselung -->weiterleiten an „localhost:Port Y“ (Port Y=Port eines auf dem Internetserver laufenden Dienstes)
Beispiel: den ftp-Dienst des Tunnelservers nutzen
In der Tunnelsoftware trägst man für Port Y einfach 21 ein (21=Port des ftp-Dienstes, welcher auf dem Tunnelserver natürlich laufen muss, um ihn nutzen zu können).
Jetzt startet man mit Hilfe der Tunnelsoftware eine Sitzung, welche den Tunnel aufbaut und dabei dem SSH-Dienst des Tunnelservers mitteilt, dass die eingehenden Pakete dieser Sitzung per Port Forwarding an Port 21 seines eigenen Systems weiterzureichen sind.
Nun konfiguriert man ein beliebiges ftp-Client-Programm dahingehend, dass es sämtliche Anfragen an Port X des lokalen Computers schickt (dem Kommunikationsport der Tunnelsitzung). Mit anderen Worten: Zielsystem=“localhost:X“.
Nun startet man das ftp-Client-Programm, welches den lokalen Port X kontaktiert. Dank der Tunnelsoftware erhält der ftp-Client so eine Verbindung zum ftp-Dienst des Tunnelservers. Man kann damit genauso arbeiten, als wenn das ftp-Client-Programm eine direkte Verbindung zum ftp-Dienst des Servers aufgebaut hat. Im Hintergrund aber werden die Daten verschlüsselt übertragen und durch die Firewall getunnelt.
Kommunikation auf dem Client:
ftp Client, Ziel=“localhost:X“ (X=Eingangsport der Tunnelsoftware auf dem PC)-->Tunnelsoftware=Umwandeln zum SSH-Protokoll -->weiterleiten an „Tunnelserver:Port 22“
Kommunikation auf dem Server:
Tunnelserver:Port22=Eingang des SSH-Dienstes-->SSH-Dienst=Zurückkonvertieren in das Ursprungsformat-->weiterleiten an „localhost:21“ (21=Port des auf dem Tunnelserver laufenden ftp-Dienstes)
Beispiel: eMails per POP3 vom Tunnelserver abholen
Port Y=110 (da der POP3-Dienst auf dem Tunnelserver an Port 110 auf seine Anfragen wartet)
Tunnel-Sitzung starten
Beliebiges eMail-Programm so konfigurieren, dass es die POP3-eMails über „localhost:X“ abholt (X=Tunnel-Kommunikationsport des lokalen PCs). Kennung und Passwort für den eMail-Account angeben, eMails einlesen, fertig. Der Vorteil dieser Methode: Kennung und Passwort werden bereits verschlüsselt übertragen
Kommunikation auf dem Client:
eMail Client, Ziel=“localhost:X“ (X=Eingangsport der Tunnelsoftware auf dem PC)-->Tunnelsoftware=Umwandeln zum SSH-Protokoll -->weiterleiten an „Tunnelserver:Port 22“
Kommunikation auf dem Server:
Tunnelserver:Port22=Eingang des SSH-Dienstes-->SSH-Dienst=Zurückkonvertieren in das Ursprungsformat-->weiterleiten an „localhost:110“ (110=Port des auf dem Tunnelserver laufenden POP3-Dienstes)
Mehrere Tunnelsitzungen parallel starten
Wenn mehrere Tunnel-Sitzungen parallel gestartet werden sollen (z.B. eine Sitzung für ftp und eine Sitzung für POP3), so muss man pro Sitzung natürlich einen andern (lokalen) Port X festlegen.
Remote Host: Den SSH-Tunnel als Forward-Gateway verwenden
Bei der Konfiguration des SSH-Clients stößt man neben der Angabe für den Remote Port (Port Y) auch auf die Angabe eines möglichen Remote Hosts. Wird das Feld hier nicht leer gelassen bzw. nicht localhost dort eingetragen, so reicht der SSH-Dienst beim Port Forwarding die Netzwerkpakete an den dort angegebenen Rechner in seinem privaten Netz weiter:
Kommunikation auf dem Client:
Eingehende Netzwerkpakete an den eigenen PC auf Port X („localhost:X“)->Tunnelsoftware=Umwandeln zum SSH-Protokoll-->weiterleiten an „Tunnelserver:Port 22“
Kommunikation auf dem Server:
Tunnelserver:Port22=Eingang des SSH-Dienstes-->SSH-Dienst=Zurückkonvertieren in das Ursprungsformat-->weiterleiten an „AdresseDesRemoteHostsAusDemNetzDesTunnelservers: PortY“ (Y=Port des auf dem Remote Host laufenden Dienstes)
Hinweis: Befindet sich der Internetserver mit seinem SSH-Dienst in der DMZ, so muß auch der Rechner zu dem die Pakete weitergereicht werden sollen, in der DMZ stehen (es sei denn, die innere DMZ-Firewall lässt die Anfragen durch, was nicht zu empfehlen ist). Mit anderen Worten muss der Remote Host vom Tunnelserver aus ansprechbar sein, damit dieser Mechanismus funktioniert.
Der Zugriffsschutz
Sobald die SSH-Sitzung (der Tunnel) aufgebaut wird, muss man sich an dem Tunnelserver authentifizieren. Das geht wahlweise über Kennung und Passwort, oder über die Angabe einer Kennung und einer RSA-Schlüsseldatei.
Aber auch der Tunnelserver muss sich gegenüber dem Client identifizieren. Damit der Client sicher sein kann, dass der vermeintliche Tunnelserver auch der tatsächlich angeforderte Server ist, weist sich der Server mit einem RSA-Zertifikat aus.
Nach erfolgreicher Authentifizierung für die Sitzung ein temporärer Schlüssel erzeugt, mit dem die gesamte nachfolgende Kommunikation verschlüsselt wird, wobei je nach Protokollversion und Konfiguration ein anderer Verschlüsselungsalgorithmus zum Einsatz kommt.
Zusammenfassung zum Thema: Tunneln durch die Firewall / ein Tunnel welcher alle Portanfragen weiterleitet: der VPN-Tunnel
In der FAQ wurde bereits beschrieben, was VPN macht. Nun geht es darum, VPN einmal aus Sicht des Tunnels zu betrachten.
Im Folgenden wird die VPN-Kommunikation über "Port X" zur besseren Lesbarkeit stark vereinfacht formuliert. Wie sie tatsächlich abläuft und warum der VPN-Tunnel über eine externe Firewall (also über PAT hinweg) Probleme bereitet, erfährst Du hier.
Einen Rechner per VPN auf ein anderes Netz zugreifen lassen („Site-to-End“-Verbindung)
In diesem Beispiel läuft auf dem Internetserver ein VPN-Dienst, der an einem festen Port X auf Anfragen wartet. Dieser Server wird im folgenden VPN-Server genannt. Aus dem internen Netz wird über eine VPN-Client-Software eine VPN-Sitzung eröffnet:
[VPN-Client=Verbindung zum VPN-Server:PortX herstellen]--privates Netz 1-->[Firewall=PortX erlaubt]--externes Netz-->[VPN-Server:PortX = VPN-Dienst: Authentifizierung durchführen + Sitzung erstellen + der Sitzung virtuell eine interne IP-Adresse zuweisen]
Der VPN-Server:
Jeder Sitzung wird eine freie, interne IP-Adresse aus einem Pool zugewiesen, den der VPN-Server verwaltet. Alle künftig eingehenden Pakete der Sitzung erhalten diese IP-Adresse als Absender, ehe sie in das interne, private Netz weitergeleitet werden.
Der VPN-Client:
Nachdem die Sitzung aufgebaut wurde, verwaltet die VPN-Client-Software die Netzwerkkarten des PCs. Die Tunnelsoftware sorgt dafür, dass ausschließlich Anfragen des VPN-Servers diesen Client erreichen (alle anderen Clients des Netzwerks, an dem der VPN-Client physikalisch angeschlossen ist, können ihn für die Dauer der Sitzung nicht mehr erreichen). Zudem werden sämtliche ausgehenden Anfragen des Client von der VPN-Software abgefangen, verschlüsselt, in das VPN-Protokoll eingebettet und an den VPN-Partner geschickt. Dann passieren die Pakete den Tunnel:
[Client=Netzwerkanfrage an ZielRechnerImPrivatenNetz2:PortA]-->[VPN-Client-Software=Verschlüsselung + Pakete in das VPN-Protokoll einbetten + Weiterleitung an VPN-Server:PortX]--privates Netz 1-->[Firewall=PortX ist erlaubt]--externes Netz (z.B. Internet)-->Weiterleiten an den VPN-Server:PortX
Der VPN-Server:
Der VPN-Server nimmt die Pakete entgegen, merkt sich deren Absenderadresse, holt die ursprünglichen Netzwerkpakete dort heraus, entschlüsselt sie, trägt die zur VPN-Sitzung gehörende, interne IP-Adresse als Absender ein (im folgenden „gespoofte Adresse“ genannt) und leitet die Pakete in das eigene, private Netz weiter (tatsächlich erhalten die Pakete schon vom VPN-Client ihre interne Adresse, bevor sie vom separat adressierten VPN-Protokoll verpackt werden, jedoch ist diese Sichtweise für ein einfaches Verständnis besser):
VPN-Server:PortX=Eingang-->[VPN-Dienst=Extrahieren der Ursprungspakete + Entschlüsselung + Absender spoofen (beachte den Kommentar von oben) + Weiterleitung ins eigene, private Netz]--privates Netz 2-->[ZielRechnerImPrivatenNetz2:PortA=Pakete empfangen]
Der Zielrechner:
Der Zielrechner nimmt die Anfrage entgegen, bearbeitet sie und schickt die Antwort wieder zurück zur gespooften Absenderadresse. Da der VPN-Server den Adressraum (das Subnetz) der gespooften IP-Adressen verwaltet, oder aber über virtuelle Netzwerkadapter diesen Adressraum abbildet, werden die Antwortpakete von den Netzwerkkomponenten dorthin geschickt. Der VPN-Server konvertiert nun die Pakete, trägt die ursprüngliche Absenderadresse der Sitzung als Zieladresse ein und leitet die VPN-Pakete dorthin zurück.
Aus der Sicht des Anwenders ist die VPN-Verbindung eine Point-To-Point-Verbindung zwischen seinem Computer und dem Netz des VPN-Servers. Die Rechner aus dem dazwischen liegenden, eigenen Netz des PCs sind für ihn somit nicht mehr erreichbar. Für den Benutzer sieht es also so aus, als würden die Daten über eine exklusive (dedizierte) Verbindung gesendet. Will man diesen Effekt verhindern, so muss man die VPN-Verbindung in einem so genannten „Split-Tunneling“-Modus laufen lassen.
Merkmale der VPN-Verbindung:
Die Daten ab dem VPN-Server bis zum Zielrechner werden unverschlüsselt übertragen.
Der VPN-Server und auch die Rechner aus seinem Netz können auf die Dienste des VPN-Clients genauso zugreifen, als stände er in ihrem eigenen Netz. Die Dienste müssen jedoch an den virtuellen VPN-Netzwerkadapter gebunden sein.
Weder der VPN-Server, noch die Rechner aus seinem Netz sind jedoch in der Lage, auf die anderen Rechner zuzugreifen, welche im physikalischen Netz des VPN-Clients stehen.
zwei Rechner per VPN miteinander verbinden
Es kann vorkommen, dass vertrauliche Daten vor den Augen der übrigen Rechner des eigenen Netzes geschützt transportiert werden sollen. VPN hilft dabei, die Rechner abhörsicher miteinander zu verbinden. Der VPN-Tunnel dient also nicht nur dazu, durch eine Firewall zu tunneln, sondern auch dazu, dass Rechner im eigenen Netz verschlüsselt miteinander kommunizieren können. Das funktioniert genauso, wie oben beschrieben, jedoch wird der VPN-Server dahingehend konfiguriert, dass keine Anfragen an seine Rechner weitergeleitet werden. So sind nur Anfragen zulässig, die sich an den VPN-Server selbst richten:
[VPN-Client=Anfrage an VPN-Server:PortA]-->[VPN-Client-Software=Verschlüsselung + Pakete in das VPN-Protokoll einbetten + Weiterleitung an den VPN-Server:PortX]--privates Netz 1-->[Firewall=PortX erlaubt]--externes Netz-->[VPN-Server:PortX = VPN-Dienst: Extrahieren der Ursprungspakete + Entschlüsselung + Weiterleitung an den Bestimmungsport A]-->[VPN-Server:PortA=Pakete erreichen den gewünschten Dienst des VPN-Servers]
zwei Netzwerke über VPN miteinander verbinden (Site-to-Site)
Hier befindet sich auf beiden Seiten ein VPN-Server (auch VPN-Gateway genannt), welche sich beim Aufbau des Tunnels gegenseitig authentifizieren. Beide VPN-Gateways verwalten ihre eigenen Subnetze. Netzwerkpakete, die an ein Subnetz des jeweils anderen VPN-Gateways adressiert sind, werden nun über die (in der Regel verschlüsselte) VPN-Verbindung in das andere Netzwerk übertragen:
[alle Rechner]<--internes Netz1-->[VPN-Gateway]<===verschlüsselte Verbindung im externen Netz (z.B. Internet)===>[VPN-Gateway]<--internes Netz2-->[alle Rechner]
Es sieht für den Anwender so aus, als wenn jemand die beiden Netzwerke einfach über ein Kabel miteinander verbunden hätte (rein metaphorisch gesprochen / es wird keine VPN-Client-Software benötigt). Das bedeutet auch, dass beide Netzwerke kompatibel zueinander sein müssen (ganz wie bei der Verbindung zweier Netzwerksegmente auch).
Viele professionelle Firewalls enthalten VPN-Gateways. Sie sind auch in der Lage, die zu tunnelnden Pakete zu filtern, da sie diese analysieren, bevor sie verschlüsselt werden – also noch bevor sie den Tunnel passieren.
Will man über dieselbe Firewall auch auf das Internet zugreifen, so muss sie im „Split Tunneling“-Modus betrieben werden, was allerdings die Angriffmöglichkeiten auf die VPN-Verbindung erhöht.
Zusammenfassung zum Thema: virtuelle Netzwerkkarten / spezifische Route, sowie deren Zusammenhang zum VPN-Client und Split Tunneling
Wozu benötigt man virtuelle Netzwerkkarten?
In einem TCP/IP-Netz bindet sich jeder Netzwerkdienst an eine IP-Adresse des Rechners (z.B. 192.168.1.1) und lauscht dort an einem festen Port, über den er die Anfragen aus dem Netz entgegennimmt. Will man eine weitere Version des gleichen Dienstes installieren, so geht das nicht ohne weiteres, da der bereits installierte Dienst den begehrten Port für sich beansprucht hat. Die Lösung für das Problem liefert die zusätzliche IP-Adresse der virtuellen Netzwerkkarte (ipconfig –a eth0:0 192.168.1.2). Dank ihr lässt sich auf denselben PC ein weiterer Dienst des gleichen Typs installieren, welcher über die zusätzliche IP-Adresse angesprochen wird.
Mit anderen Worten lassen sich auf diese Weise z.B. mehrere eigenständige http-Dienste parallel installieren, welche beide den Port 80 verwenden. Der erste http-Dienst kann wie gewohnt über 192.168.1.1:80 angesprochen werden, wohingegen der zweite http-Dienst dank der virtuellen Netzwerkkarte nun über 192.168.1.2:80 zu erreichen ist.
Das ist allerdings nur eine Anwendungsmöglichkeit von vielen. Oftmals wird einem Dienst eine eigene IP-Adresse zugewiesen, um ihn rechnerunabhängig zu machen. Falls ein anderer Rechner den Dienst übernehmen soll, weil z.B. der Server ausgefallen ist, kann die IP-Adresse einfach auf den Dienst eines anderen Servers übernommen werden. Der Client merkt von dem Umzug nichts.
Zudem muss sich eine virtuelle Netzwerkkarte nicht unbedingt an einen physikalischen Adapter binden. Auf diese Weise ist die so erstellte IP-Adresse nur von den Programmen des Rechners, nicht jedoch vom Netzwerk aus ansprechbar. Solche internen, virtuellen Netzwerkkarten werden unter anderem für VPN-Clients verwendet.
Welche Absenderadresse erhalten Netzwerkpakete, die den Rechner verlassen?
Die Absenderadresse hängt von den eingestellten Routen des PCs ab (die Routen eines Rechners lassen sich über die Konsole mit dem Befehl "route print" anzeigen). Per default ist dort eingetragen, dass alle Netzwerkanfragen über einen bestimmten Netzwerkadapter gehen. Das kann die physikalische Netzwerkkarte oder der virtuelle Adapter sein. Man kann die Routen jedoch so einstellen, dass bestimmte Adressbereiche über den einen Adapter gehen und andere Bereiche den anderen Adapter passieren (Befehl „route –add“). Die Absenderadresse wird durch den verwendeten Adapter bestimmt.
Eine weitere Möglichkeit, die Absenderadresse festzulegen, findet sich auf Applikationsebene: Jedes Programm kann vor seiner Netzkommunikation die installierten Adapter vom System auflisten lassen und sich dann fest an einen der Adapter binden. Sämtliche Netzwerkanfragen des Programms gehen nun über diesen ausgewählten Adapter. Die Netzwerkpakete erhalten so die Absenderadresse von ihm.
Die virtuelle Netzwerkkarte einer VPN-Sitzung
Die Tunnelsoftware sorgt dafür, dass die Rechner aus dem physikalischen Netz des Clients keine Verbindung mehr zum Client aufbauen können und ausschließlich Anfragen des VPN-Servers diesen Client erreichen. Zudem werden sämtliche ausgehenden Anfragen dieser Karte abgefangen, verschlüsselt und in das VPN-Protokoll eingebettet. Nun stellt sich die Frage, wie der VPN-Client das realisiert:
Zunächst legt die VPN-Client-Software bei der Erstellung einer Sitzung eine eigene, interne virtuelle Netzwerkkarte an (den VPN-Adapter). Der VPN-Adapter bleibt nur lokal adressierbar und lässt sich somit nicht vom Netz aus ansprechen. Per Systemroute können alle Programme dieses Rechners ihre Netzwerkpakete nur noch an den VPN-Adapter schicken. Alle dort eingehenden Pakete werden nun automatisch von der Tunnel-Software in Empfang genommen.
Der VPN-Netzwerkadapter erhält dieselbe IP-Adresse, welche der Session auf dem VPN-Server zugewiesen wurde (siehe unter „Einen Rechner per VPN auf ein anderes Netz zugreifen lassen“). Zum einen wird dadurch dem Client die Möglichkeit gegeben, über Standardmethoden die gerade aktuelle, eigene IP-Adresse innerhalb des (VPN-) Netzes zu erfragen. Zum anderen erhalten auch alle darüber verschickten Netzwerkpakete bereits hier eine für das Zielnetz gültige Absenderadresse. Allerdings werden diese Pakete von der Tunnelsoftware nun verschlüsselt und in das separat adressierbare VPN-Protokoll verpackt (tatsächlich ist es das TCP/IP-Protokoll, welches dem VPN-Protokoll als Transportmittel dient und die Adressierung realisiert). Diese Pakete werden über den physikalischen Adapter zum Tunnelpartner ins Netz geschickt. Auf diese Weise erhalten die VPN-Pakete die Absenderadresse des PCs und nicht die des VPN-Adapters. Nur so können die Antwortpakete adressierungstechnisch auch wieder zum PC gelangen.
Erst wenn der VPN-Server die ursprünglichen Pakete aus dem VPN-Protokoll heraus extrahiert hat, kommen auch wieder ihre ursprünglichen Adressen zum Vorschein (Zielsystem=Rechner aus dem Netz hinter dem VPN-Server und Absender=Adresse des VPN-Netzwerkadapters).
[Netzwerkanfrage des Clients: Ziel=RechnerXYZAusDemPrivatenNetz2:PortA / Absender=IP-AdresseDesVPN-Netzwerkadapters:PortB]-->[VPN-Client-Software=Verschlüsselung + Pakete in das VPN-Protokoll einbetten + Adressierung der neu erstellen Pakete: Ziel=VPN-Server:PortX / Absender=IP-AdresseDesPhysikalischenNetzwerkadaptersDesClients :PortY]--privates Netz 1-->[Firewall=PortX ist erlaubt]--externes Netz (z.B. Internet)-->[VPN-Server:PortX=Extrahieren der Ursprungspakete + Entschlüsselung + Weiterleitung ins eigene, private Netz an die in dem Ursprungspaket enthaltene Adresse]--privates Netz 2-->[RechnerXYZAusDemPrivatenNetz2:PortA=Pakete empfangen]
Es liegt nun an dem VPN-Server, die an das VPN-Netzwerkadapter adressierten Antwortpakete des Zielsystems abzufangen, in das VPN-Protokoll zu packen und die VPN-Pakete wieder an die physikalisch vorhandene Netzwerkadresse zurückzuschicken, damit sie den Client erreichen können.
Split-Tunneling und deren Angriffsflächen auf VPN-Verbindungen
Das Verständnis für den internen Aufbau der VPN-Kommunikation wird wichtig, wenn man den „Split Tunneling“-Modus der VPN-Verbindung verstehen will. Im „Split-Tunneling“-Modus wird der Client während der VPN-Sitzung nicht von seinem eigenen Netz abgeschottet. So werden per Routeseinstellungen lediglich die Verbindungen zu einem bestimmten Adressbereich über den virtuellen VPN-Adapter geschickt. Für die anderen Adressbereiche werden dem PC die restlichen Netzwerkadapter wieder zugänglich gemacht. Zudem lassen sich die externen Zugriffe auf den PC wieder aktivieren.
Ethickerds weisen oft darauf hin, dass dieser Modus zahlreiche Techniken ermöglicht, um die VPN-Sitzung zu kompromittieren. Sämtliche Netzwerkdienste des Clients (auch RATs) können während der VPN-Verbindung noch immer von allen Rechners seines eigenen Netzes in Anspruch genommen werden. Auch lassen sich auf diese Weise während der VPN-Verbindung unbemerkt beliebige Daten an einen internen Rechner schicken. Zudem kann über den Umweg der applikationsgebundenen Netzwerkkommunikation die Route ausgetrickst werden, um die Anfragen an einen Server im eigenen Netz umzuleiten.
Zusammenfassung zum Thema: Der „VPN Pass-Through“-Modus einer Firewall kurz erklärt.
Der Beitrag wurde in einer angepaßten Form in die "Firewall FAQ für Laien" verschoben. Sorry für das Durcheinander. Wenn die FAQ fertiggestellt ist, wird es das Problem nicht mehr geben. Bis dahin bitte ich um Nachsicht.
Zusammenfassung zur Frage: Was ist ein (ciruit level- / dedicated- / generischer-) Proxy?
Ein Proxy beschreibt eine bestimmte Art der Kommunikation (eine einfache Erklärung dazu findest Du in der „Firewall FAQ für Laien“).
Technisch gesehen handelt es sich bei einem Proxy um eine aktive Netzwerkkomponente, welche als Vermittlungsstelle fungiert, indem sie die Verbindung zum Zielsystem stellvertretend für den Client aufnimmt. Das Zielsystem sieht daher als Absender nur den Proxy, der wiederum die Antwortpakete des Zielsystems an den wirklichen Client weiterleitet. Die Definition eines Proxys ist unabhängig vom OSI Layer oder weiteren Funktionalitäten. Einzig die Art der Kommunikation macht einen Proxy aus.
Dank seiner Funktionsweise kann ein Proxy die Netzwerkpakete in beiden Richtungen zusammensetzen, analysieren und filtern, noch bevor sie die tatsächlichen Kommunikationspartner erreichen. Da das Zielsystem nicht den Client, sondern nur den Proxy sieht, sind mögliche Angriffe aus dem externen Netz an den dafür prädestinierten Proxy gerichtet und treffen nicht direkt den Client (solange die Pakete nicht wie beim (static-) NAT ungefiltert 1:1 an den internen Rechner durchgereicht werden). Auch verhilft das PAT-Konzept einem Proxy dazu, mit nur einer einzigen externen Netzwerkadresse tausenden internen Clients zeitgleich den Zugriff auf das externe Netz zu ermöglichen.
Einem weit verbreiteten Irrtum zufolge, stellt das Zwischenspeichern von Internetseiten eine der grundlegenden Eigenschaften eines Proxys dar, obgleich ein Proxy diese Eigenschaft haben kann, aber nicht muss.
Sichtbarkeiten
Der konventionelle Proxy
Ein konventioneller Proxy stellt sich für beide Kommunikationspartner sichtbar als Vermittlungsstelle zwischen das Quell- und Zielsystem. Das Client kommuniziert so bewusst mit dem Proxy und bittet ihn, stellvertretend für ihn die Kommunikation mit dem Zielsystem zu übernehmen. Allerdings muss die Software des Quellsystems diese spezielle Verbindungsart unterstützen. So wird z.B. der Internetbrowser derart konfiguriert, dass er sämtliche Internetanfragen nicht direkt zur Zieladresse schickt, sondern als Anforderung formuliert zum Proxy sendet.
Der transparent Proxy
Aus Sicht des internen Netzes verhält sich der transparente Proxy ähnlich einem Router, wohingegen er aus Sicht des externen Netzes ein Proxy darstellt. Im Detail bedeutet das, dass der so genannte transparent Proxy nur für das Zielsystem, nicht jedoch für den Client sichtbar ist. So glaubt der Client aus dem internen Netz, dass er direkt auf das Zielsystem zugreift (z.B. auf eine Webseite). Der Benutzer muss also im Browser keinen Proxy eintragen und gelangt dennoch auf die richtige Seite. Tatsächlich wurde der Proxy als Vermittler zwischen dem Internet und dem privaten Netz konfiguriert. Das bedeutet, dass alle Anfragen an Adressen, welche nicht zum eigenen Netz gehören, von den default Gateways zum Proxy weitergereicht werden. Auf diese Weise gehen Netzwerkanfragen an Internetserver automatisch über den Proxy ins Internet, ohne dass der Anwender dies bemerkt oder gar beeinflussen kann. Die Internetserver sehen als Kommunikationspartner wiederum nur den Proxy, der deren Antwortpakete an die internen Clients weiterleitet.
Auch eine statische Paketfilter Firewall, welche man allgemeinhin als Firewall Router bezeichnet, kann durchaus im Proxy-Modus laufen. Man spricht hierbei von einem ciruit level Proxy, welcher auf Layer 3 (für die Filterung) und 4 (für die Adressumsetzung) im OSI-Schichtenmodell operiert. Er sorgt dafür, dass sich die Paketfilter Firewall von ihrem passiven Routerdasein in eine aktive (sichtbare) Netzwerkkomponente verwandelt, was die Firewall u.a. in die Lage versetzt, die IP-Adresse des Clients zu verbergen und somit das statische NAT-Konzept umzusetzen (auch Basic NAT genannt).
Demgegenüber kommt der Layer 3 & 4 Proxy auch auf PAT-Geräten zum Einsatz, die eine dynamische Paketfilterung realisieren, welches je nach Implementierung auch NAPT, dynamic NAT, IP- bzw. NAT- Masquerading oder hide-NAT genannt wird.
Die Stateful Inspection Firewall (kurz SIF) nutzt für ihre Filterregeln neben dem Layer 3 & 4 zusätzlich eine über den OSI-Layer 7 erstellte Statustabelle der Netzwerkpakete, die es ihr ermöglicht, dynamische Portregeln auch für Protokolle zu erstellen, für deren Koordinierung sie in die Pakete hineinsehen muss.
Da sich die hier erstellten Regeln einzig auf die Port- und Adressfilterung und nicht auf weitere Paketinhalte beziehen, sind sie unabhängig vom Protokoll für alle Netzwerkpakete gleichermaßen gültig, weshalb der „ciruit level Proxy“ manchmal auch als „generischer Proxy“ bezeichnet wird.
dedicated Proxy
Der Name „dedicated Proxy“ ist etwas ungünstig gewählt, da es sich hierbei nicht um eigenständige Proxies handelt, sondern um Filtermodule für Netzwerkpakete, welche auf einer Firewall die im Proxy-Modus läuft aufgesetzt werden können. Da sie für ihre Arbeit in die Pakete hineinsehen müssen, setzen sie auf dem OSI Layer 7 auf und kommen deshalb ausschließlich auf einer Application Level Firewall (kurt ALF) zum Einsatz. Ein "dedicated Proxy" ist somit nichts weiter als ein Softwarepaket, welches in der Lage ist, ein bestimmtes Protokoll zu analysieren. Für jedes Protokoll gibt es einen eigenen dedicated Proxy, welche man technisch gesehen besser als spezialisierte content Filter bezeichnen kann. Sie kommen z.B. als SMTP-Virenscanner, http-Filter, ftp-Verbindungs- und Befehlsfilter zum Einsatz. Auf einer einzigen ALF können mehrere dedicated Proxies gleichzeitig laufen.
Hinweis: Einige Hersteller bieten für ihre Stateful Inspection Firewall (SIF) auch dedicated Proxies an. Das ist grundsätzlich möglich, da eine SIF ebenfalls auf dem OSI Layer 7 aufsetzt. Dennoch widerspricht dies völlig dem Konzept von checkpoint, dem Entwickler der SIF. Da der Layer 7 ausschließlich zur Erstellung der Statustabelle genutzt werden soll, um dynamische Portregeln zu ermöglichen, wurde die SIF ganz klar als Paketfilter Firewall klassifiziert. Werden jedoch die dedicated Proxies aktiviert, so ist die SIF tatsächlich keine Paketfilter Firewall mehr und gehört dann eher in die Rubrik "Application Level Firewall mit generischem Layer 3 & 4 Proxy (nach OSI)".
generischer Layer 7 Proxy (nach OSI)
Es handelt sich hierbei um ein protokollunabhängiges Softwaremodul, mit dem man beliebige Ports auf einer Application Level Firewall sperren bzw. freischalten kann, ohne jedoch die Möglichkeit zu haben, die Paketinhalte damit zu analysieren. Ein generischer Layer 7 Proxy ist also nichts anderes, als ein simpler Paketfilter inmitten einer ALF.
reverse Proxy
Die Reverse Proxies einer Firewall bieten die gleiche Funktionalität wie Port Forwarding. Da sie das Netzwerkprotokoll verstehen, sind sie zudem in der Lage, die Daten der Netzwerkpakete zu analysieren und zu bearbeiten. So können sie z.B. einen Virenscan vornehmen oder Regeln realisieren, die sich auf die Paketinhalte beziehen.
Reverse Proxies werden auch dazu verwendet, um an der Firewall vorbei auf einen internen Rechner zugreifen zu können. Dazu baut der interne Rechner eine Verbindung zu einem externen Rechner auf, wodurch der externe Rechner nun über die Firewall hinweg mit dem internen Rechner kommunizieren kann (gemäß PAT). Läuft auf dem externen Rechner ein Reverse Proxy, so können nun beliebige andere Rechner auf den internen Rechner hinter der Firewall zugreifen, indem sie ihre Anfragen an den Reverse Proxy des externen Rechners schicken (der Reverse Proxy leitet die Anfragen an den internen Rechner weiter). Der interne Rechner ist somit über die Adresse des externen Rechners auf dem Port des Reverse Proxys erreichbar.
NAT-Router; und warum ein DSL-Router kein Router, sondern ein Proxy ist
Technisch gesehen entspricht ein NAT-Router einem transparent Proxy, was bedeutet, dass er sich im internen Netz ähnlich einem Router verhält, jedoch aus Sicht des externen Netzes ein Proxy darstellt. Aus marketingtechnischen Gründen wurden diese Geräte jedoch schlicht „NAT-Router“ genannt, um dem Anwender zu verdeutlichen, dass er für die Kommunikation zum Internet keinen Proxy mehr angeben muss. Deren populärster Vertreter ist der DSL-Router, der aus demselben Grund den irreführenden „Router“ im Namen trägt. Da diese Geräte aus technischer Sicht nicht wirklich viel mit einem konventionellen Router gemein haben, wirft der Begriff oft Missverständnisse auf. Vor allem wenn man bedenkt, dass viele Anwender dazu kurz „Router“ sagen. Netzwerktechnisch gesehen liegen zwischen diesen beiden Begriffen jedoch Welten. Mehr dazu: siehe den Artikel zum Router
Es gibt Tage, an denen ich keine Zeit habe, mich um die Dinge zu kümmern, die mir sonst noch spaß machen. :-/ So auch in den letzten Wochen, die mir keine Luft ließen, mich um die FAQ zu kümmern. Es hat lediglich zur Beantwortung von PNs gereicht. Sorry.
Das kann jederzeit wieder passieren. Das bedeutet aber nicht, daß die FAQ stirbt!
Heute wurden also die verspäteten Proxy-Beitrage geliefert (ein Beitrag in der FAQ für Laien und ein weiterer hier). Es folgt in den nächsten Tagen ein Beitrag zum Thema „Gateway“, welcher schon einmal hier im Forum diskutiert wurde. Danach kommen wir zu den interessanten Fragen: Wie man eine Desktop-Firewall umgeht, etc. Diese Themen werden dann auch wieder im „Frage / Antwort“-Stil geführt (also unter eurer hoffentlich regen Mitarbeit). Bis dahin bitte ich noch um ein wenig Geduld.
Zusammenfassung zur Frage: Was ist ein Gateway? Und warum passen die Begriffe „default Gateway“, „Application Level Gateway“ und „Screened Gateway“ nicht zur Gatewaydefinition?
Gateway
Ein Gateway nimmt die Konvertierung eines Protokolls in ein anderes vor (bspw. IPX nach IP). Auch eine dienstbasierte Umsetzung ist hier möglich (z.B. eMail zu SMS, eMail zu Fax, etc.). Zu diesem Zweck kann das Gateway auf beliebige Schichten des OSI-Referenzmodells aufsetzen.
Warum widerspricht das „default Gateway“ der Gatewaydefinition?
Bei der TCP/IP-Konfiguration einer Netzwerkkarte wird auch ein so genanntes „default Gateway“ angegeben. Das allerdings setzt keine Protokolle um. Stattdessen leitet es lediglich alle nicht zu einem Subnetz gehörenden Netzwerkanfragen in ein anderes Subnetz weiter. Damit übernimmt das „default Gateway“ schlicht die Funktionen eines Routers. Warum aber widerspricht das „default Gateway“ der Gatewaydefinition?
Als TCP/IP noch in den Kinderschuhen steckte, war man nicht selten gezwungen, Netzwerke unterschiedlichen Typs miteinander zu verbinden und damit zwangsläufig die Protokolle zu konvertieren. Denn dieser „Exot“ wurde mit Protokollen wie DECnet, SNA und Novells IPX/SPX konfrontiert. Der Begriff „default Gateway“ sollte dem Administrator klar machen, dass man hier ein Gateway eintragen kann. Allerdings „kann“ heißt nicht „muss“, denn was anstelle des „default Gateways“ tatsächlich eingesetzt wird, hängt von der jeweiligen Netzwerkarchitektur ab.
Mit der Vorherrschaft des TCP/IP-Protokolls zog der Router immer öfter an die Stelle des Gateways. Mittlerweile gibt es in diesem Segment kaum noch Gateways, da die Netze fast alle über das TCP/IP-Protokoll kommunizieren. Eine Protokollumsetzung ist also nicht mehr erforderlich, weshalb die Bezeichnung „default Router“ heutzutage treffender wäre.
Warum passen auch „Application Level Gateways“ und „Screened Gateways“ nicht in die Gatewaydefinition?
Eine Application Level Firewall wird auch als „Application Level Gateway“ bezeichnet. Genau wie Screened Gateways wandeln sie in der Regel jedoch keine Protokolle um und widersprechen so ebenfalls der Gatewaydefinition. Beide Firewallarten arbeiten allerdings auf dem OSI Layer 7, was ihnen eine Protokollkonvertierung ermöglicht. Das diese Möglichkeit wegen mangelnder Notwendigkeit nur sehr selten genutzt wird, ist für die Betitelung belanglos.
Hallo zusammen.
Ich werde nun erläutern, wie man Desktop-Firewalls umgehen kann – auch ohne Einsetzen von „The Hack“. Denn die große Masse solcher Firewalls bietet auch so nicht optimalen Schutz und lässt den normalen - User mit mehreren Sicherheitsrisiken allein – obwohl die Hersteller jener Firewalls deren Benutzern optimale Sicherheit versprechen.
So ist es für den „bösen Hacker“ oftmals nicht einmal notwendig, die Firewall im Sinne eines Hacks zu umgehen.
Vorher noch eine kleine Anmerkung am Rande:
Ich habe darauf geachtet, diesen Beitrag so zu gestalten, dass meiner Meinung nach keine große Nachahmungsgefahr von Seiten unserer werten r00t-Kids vorliegt. Sollte einer der hiesigen Foren-Mitarbeiter trotzdem der Meinung sein, dass irgendetwas davon hier nicht richtig aufgehoben sei, so möge er/sie es mir bitte mitteilen, damit ich es entsprechend „entschärfen“ kann. Man kann ja nie wissen.
Wenn deswegen etwas ein wenig ungenau oder weniger konkret ausgefallen ist, wäre ich natürlich auch noch zu ein paar Erklärungen betreffend das Thema bereit.
1.
Als Beispiel möchte ich hier Zone Labs ZoneAlarm Pro aufführen.
Jeder, der diese Personal-Firewall benutzt, kennt deren Anfragen, ob neu installierten Programmen der Zugriff nach außen gestattet werden soll und die Kontrolle des Applikationsfilters, ob es das darf.
Nun wird natürlich nicht jeder weniger aufgeklärte Internet-Nutzer wissen, dass hinter z.B. einer „kernel.exe“ seine T-Online-Software steckt oder was eine „svchost.exe“ ist.
Ich wage also anzunehmen, dass es Leute geben wird, die deshalb allen Programmen den Zugriff nach innen/außen gestatten werden (dass Gegenteil würde schlecht funktionieren, denn dann würden sie ihrer Internet-Software Knüppel zwischen die Beine werfen – und da das kein Newbie möchte…*schmunzel*), aber kommen wir zum Hauptpunkt dieses Abschnitts zurück: Wenn sich nun das Programm trickler.exe anmeldet, hinter dem ein Virus steckt, was dem Anwender allerdings nicht bekannt ist, wird dieser dem Programm den Zugriff ins Netz gestatten – und obwohl es sich hierbei offenbar um „schädliche“ Software handelt, wird die Desktop-Firewall ihm diesen kommentarlos gestatten, indem sie den entsprechenden Port freigibt und eventuell direkt noch Platz für mehr schafft…
Effektiv bedeutet das also, dass die beste Firewall nichts ausrichten kann, wenn der Anwender sie nicht zu bedienen weiß, also jedes Programm ins Internet verbinden darf, sobald der Benutzer gefragt wird. Und dass einige Firewalls gerne Berichte über erfolgreiches Abwehren eines Angriffs ausgeben, verbessert die Situation nicht gerade.
Gut, aber kommen wir nun zum "fun-factor" , der sich für die Angreifer aus einer Reihe von Firewalls ergibt.
2. Zugriffsrechte:
Unter Windows NT hat jedes Programm die Zugriffsrechte auf derselben Ebene wie die Personal Firewall – vorausgesetzt, man ist als „Administrator“ angemeldet. Dass es schon lange Programme gibt, die PFWs einfach beenden, dürfte bekannt sein; folglich wird eine D-Firewall in solch einem Fall nichts ausrichten können.
Also schleusen wir ein Programm als Anhängsel eines Virus’ oder Trojaners ein, das die Firewall ausschaltet – und schon haben wir alles, was wir wollten, Spaß und Amusément inklusive.
Dieser Beispielcode (Urheber mir leider nicht bekannt) sollte in etwa erwähnten Effekt bei der Personal-Firewall ZoneAlarm haben:
Option Explicit
Private Declare Function CloseHandle Lib "kernel32" (ByVal hObject As
Long) As Long
Private Declare Function TerminateProcess Lib "kernel32" (ByVal hProcess
As Long, ByVal uExitCode As Long) As Long
Private Declare Function OpenProcess Lib "kernel32" (ByVal
dwDesiredAccess As Long, ByVal bInheritHandle As Long, ByVal dwProcessId
As Long) As Long
Const PROCESS_TERMINATE = &H1
Private Declare Function GetWindowThreadProcessId Lib "user32" (ByVal
hWnd As Long, lpdwProcessId As Long) As Long
Private Declare Function FindWindow Lib "user32" Alias "FindWindowA"
(ByVal lpClassName As String, ByVal lpWindowName As String) As Long
Private Sub Close_ZoneAlarm()
Dim xhwnd As Long
Dim pwid As Long
xhwnd = FindWindow(vbNullString, "ZoneAlarm")
GetWindowThreadProcessId xhwnd, pwid
Dim Task As Long, result As Long
Task = OpenProcess(PROCESS_TERMINATE, 0&, pwid)
TerminateProcess Task, 1&
CloseHandle Task
End Sub
End Code
Möglichkeiten entsprechendes Programm einzuschleusen findet man bei Windows sowieso an jeder Ecke…
3. Änderungen in der Registry:
Gegenstand des Geschehens ist wieder das „böse Programm“ aus Punkt 2, das wir dem unvorsichtigen Windowsnutzer untergeschoben haben. Über Tauschbörsen soll das ja gut gehen, aber da er wahrscheinlich JavaScript sowie VBScript aktiviert haben wird, kann man es auch an gut jeder anderen Stelle an den Mann bringen.
Allerdings handelt es sich nun um ein Programm, das Änderungen in den Registry-Einträgen der Personal-Firewall vornimmt; Möglichkeiten, die man nun hat, wären zum Beispiel folgende:
- Man bewirkt, dass die Firewall beim Booten nicht gestartet wird
- Man löscht entsprechende Einträge in der Registry und ersetzt die Desktop-Firewall durch ein entsprechend präpariertes Programm, indem man den Aufruf des User-Frontends mit dessen Dateinamen überschreibt.
4. Autoklicker:
Prozedur: Vortäuschen von Benutzeraktionen über den Windows-Nachrichtendienst; der Autoklicker wartet, bis der Benutzer gefragt wird, ob ein Programm ins Internet verbinden darf und sendet dem Fenster entsprechende Nachrichten, sodass quasi jedem Programm der Zugriff gestattet wird.
5. Denial of Service die andere Art:
Klemmen wir einmal einen PC vom Internet ab.
Manche Firewall enthalten ein so genanntes IDS, das den Nachrichtenverkehr nach bekannten Angriffsmustern scannt. Bei Erkennung eines vermeintlichen Angriffs wird der komplette Datenverkehr zwischen dem betroffenen PC und dem Angreifer unterbunden.
Da ein einfaches IP-Paket, das einen oft von Trojanern benutzten Port nutzt, bereits als Angriff erkannt werden kann, fälschen wir hier die Absenderadresse und können so sperren lassen, was uns beliebt. Macht man dies mit dem DNS-Server, wird die Firewall den entsprechenden PC vom Netz abschneiden.
Man kann eine Desktop-Firewall also auch anders benutzen, anstatt sie zu umgehen.
6. Weitere Möglichkeiten wären außerdem der Einsatz von Buffer Overflows, einer www-shell, die diverse Möglichkeiten bietet, einen PC trotz Firewall fernzusteuern und der gute alte, „manuelle“ Hack.
--
Außer diesen „populäreren“ Angriffsmöglichkeiten gibt es natürlich noch mehr, die ich hier aber nicht aufführen möchte.
Stattdessen lehne ich mich nun zurück und warte darauf zu sehen, wie dieses Tutorial fortgesetzt wird.
Ich denke es ist sinnvoll, jeden Beitrag einer der folgenden Sicherheitskategorien zuzuordnen, welche sich auf eine gebräuchliche HOME-Firewall beziehen (auch DLS-Router / -Firewall oder externe Firewall bzw. Hardwarefirewall für den Homebereich genannt). Ziel ist es, deren Möglichkeiten richtig einordnen zu können:
Angriffsmethoden, welche auch eine externe Firewall nicht oder nur rudimentär unterbinden kann
Angriffsmethoden, bei der eine externe Firewall dabei hilft, den Schaden zu begrenzen
Angriffsmethoden, welche sich durch eine externe Firewall verhindern oder deutlich erschweren ließen
Zudem gibt es die folgenden Unterkategorien, welche die für die jeweilige Attacke benötigten Rechte darstellen:
Die Malware benötigt Administratorrechte, um die Attacke ausführen zu können. Dies ist natürlich dann gegeben, wenn der Anwender unter einem Administratoraccount arbeitet, während er die Malware unbemerkt startet (oftmals über Autostartmechanismen). Hierbei ist jedoch zu beachten, dass es durchaus genügen kann, wenn die Malware nur ein einziges Mal unter einem Administratoraccount gestartet wurde. Genau wie unter UNIX gibt es auch unter Windows zahlreiche Möglichkeiten, dem Programm von nun ab immer Administratorrechte zu geben (also vollkommen unabhängig von den Rechten der nachfolgenden Anwender => einmal Admin, immer Admin; auch nach jedem Neustart des Rechners).
Hinweis: In einigen Fällen kann sich die Malware auch Administrationsrechte verschaffen, obwohl sie niemals von einem Administrator aufgerufen wurde. Das ist allerdings nur möglich, wenn das System einen veralteten Stand aufweißt und die Malware so eine bekannte und ungeschlossene Sicherheitslücke des Systems ausnutzen kann.
Zudem sollte man wissen, dass sämtliche Kennungen unter Windows 3.x, 9x, ME und XP Home (nicht XP Professional) mit Administratorrechten laufen. Hier gibt es also keinen kennungsbezogenen Schutz gegen die Attacke der Malware.
Eine normale (unprivilegierte) Benutzerkennung genügt, um die Attacke ausführen zu können.
Abhängig von der Desktopfirewall funktioniert die Attacke bei einigen Herstellern nur mit Administratorrechten, währenddessen bei anderen Herstellern die Attacke unter jeder Benutzerkennung funktioniert.
Beispiel: Diese Methode gehört zur Sicherheitskategorie 1B
Bei Attacken aus denen die Richtung der Netzwerkkommunikation nicht eindeutig hervorgeht, werden beide Kommunikationsrichtungen separat betrachtet, um deren Sicherheitskategorie festzulegen:
K1 (PC->Internet): Die Malware baut eine Verbindung vom PC zum Internetserver auf. Sie könnte sich z.B. an einen IRC-Server binden, um ihre Anweisungen zu empfangen.
K2 (Internet->PC): Die Malware bindet sich an einem Port des PCs und wartet auf eine Anfrage aus dem Internet, die an diesen Port gerichtet ist. Ein Rechner aus dem Internet muss also die Verbindung zum PC herstellen, um auf die Malware zugreifen zu können.
Ich habe diese Themen mit Usern aus einem anderen Forum besprochen. Anders als ursprünglich angekündigt, werde ich hier nicht nur die leichte Kost zusammenfassen, sondern alle dort angesprochenen Möglichkeiten auflisten. Ich denke, es passt in dieser Form in eine FAQ für Fortgeschrittene. Dafür sind die Zusammenfassungen sehr oberflächlich gehalten und dienen lediglich als Übersicht.
Teil 1 von 3 der Zusammenfassung zur Frage: Wie lässt ist die Applikationszugriffskontrolle einer Desktopfirewall unterwandern?
Als Entscheidungshilfe gibt die Desktopfirewall scheinbar nützliche Informationen zu dem Programm aus, welches gerade versucht, eine Verbindung zum Netzwerk herzustellen. Die Firewall hat jedoch gar nicht die Möglichkeit herauszufinden, ob es wirklich das „Windows Subsystem“, den „Spoolerdienst“ oder die nette „Malware von nebenan“ ist, die auf das Netz zugreifen möchte. Sie vertraut einfach den Informationen, welche sie von der anfragenden Applikation erhält. Die Malware kann sich also frech als „Internetexplorer“ ausgeben oder von sich behaupten, das „Windows Subsystem“ oder ein ähnlich wichtig klingendes Instrument des Betriebsystems zu sein. Viele Anwender erlauben daraufhin den Netzwerkzugriff.
K2 (Internet->PC): Diese Methode gehört zur Sicherheitskategorie2 (der PC ist zwar infiziert, aber die Kommunikation kommt nicht zustande, solange der Malwareport von der externen Firewall nicht auf den PC geleitet wird)
Die Zugriffsregeln der Desktopfirewall können im ungünstigsten Fall einfach von der Malware überschrieben werden. So ändert sie die Einstellungen dahingehend, dass sie eine Verbindung ins Netz aufbauen darf.
K2 (Internet->PC): Diese Methode gehört zur Sicherheitskategorie2 (der PC ist zwar infiziert, aber die Kommunikation kommt nicht zustande, solange der Malwareport von der externen Firewall nicht auf den PC geleitet wird)
Ein Plugin-Trojaner kann jederzeit eigene Verbindungen zu seinem Internetserver aufbauen, sobald der Browser gestartet wurde. Da die Verbindungsanforderung aus dem Browserprogramm heraus erfolgt, nachdem der Anwender die Netzwerkkommunikation durch die Firewall hindurch erlaubt hat, passiert auch die geheime Verbindung unbemerkt die Firewall. Diese Kommunikation lässt sich leicht vor den Augen des Anwenders verbergen.
Die Malware erhascht zunächst z.B. Passworte oder andere, bis dato geheime Daten. Dann erstellt sie eine lokale html-Datei, welche die folgende Zeile enthält:
Nun wird die lokale html-Datei mit dem Standardbrowser geöffnet. Das Problem: Der Standardbrowser hat zu einer hohen Wahrscheinlichkeit bereits durch den Anwender das Recht erhalten, ungefragt auf das Internet zugreifen zu dürfen. Arbeitet der Browser die Seite ab und gelangt auf die obige Zeile, so kontaktiert er den dort angegebenen Server und übermittelt ihm so die Daten.
Um nicht aufzufallen, kann die Internetseite einen harmlosen Text ausgeben oder sogar versteckt gestartet werden, so dass der Anwender den Zugriff nicht bemerkt. Die Firewall kann den Zugriff nicht verhindern, da der Anwender es zuvor irgendwann einmal gestattet hat, dass der Internetbrowser auf das Internet zuzugreifen darf. Sie macht tatsächlich alles richtig und befolgt lediglich die Regeln des Anwenders.
Hinweis: Der Realplayer kommuniziert übrigens auf diese Weise unter Umgehung der Firewall mit dem Internet - natürlich auch dann, wenn die Personal Firewall die "normale" Kommunikation des Realplayers mit dem Internet erkannt und angeblich unterbunden hat.
Eine Malware die im Kernelspace operiert, kann die Applikationszugriffskontrolle einer Desktopfirewall nicht erkennen. Der Grund ist einfach: Die Malware stellt hierbei keinen Prozess dar, sondern einen Thread aus dem Kernelspace.
K2 (Internet->PC): Diese Methode gehört zur Sicherheitskategorie2 (der PC ist zwar infiziert, aber die Kommunikation kommt nicht zustande, solange der Malwareport von der externen Firewall nicht auf den PC geleitet wird)
Eine Desktopfirewall kann 16-Bit Anwendungen nicht voneinander unterscheiden, wenn diese in einer virtuellen (DOS-) Umgebung ablaufen (ntvdm). Das gilt somit für jede 16-Bit Anwendung, wenn sie unter NT, w2k, XP oder neuer gestartet wird. Gibt man also eine dieser Anwendungen für den Netzwerkzugriff frei, so können auch alle anderen 16-Bit Programme ungehindert auf das Netzwerk zugreifen.
K2 (Internet->PC): Diese Methode gehört zur Sicherheitskategorie2 (der PC ist zwar infiziert, aber die Kommunikation kommt nicht zustande, solange der Malwareport von der externen Firewall nicht auf den PC geleitet wird)
Vor einem ähnlichen Problem steht die Desktopfirewall mit dem svchost-Prozess. Er realisiert eine „generische Dienstgruppierung“, was im Klartext bedeutet, dass innerhalb eines svchost-Prozesses mehrere Dienste ablaufen. Das wird aus Performancegründen so realisiert, da das System dadurch nicht mehr zwischen unnötig vielen Prozessen wechseln muss. Es kann mehrere svchost-Prozesse geben. Welche Dienste unter welchem svchost-Prozess zusammengefasst werden, lässt sich frei konfigurieren. Eine Malware kann sich über diesen Weg dort ebenfalls ganz legal einklinken. Die Desktopfirewall sieht so die Malware nicht, da sie kein eigener Prozess ist (sie stellt lediglich einen weiteren Thread der jeweiligen svchost.exe dar). Wurde dem betreffenden svchost-Prozess bereits die Kommunikation mit dem Netz gestattet, so kann nun auch die Malware ungehindert mit dem Netzwerk kommunizieren.
K2 (Internet->PC): Diese Methode gehört zur Sicherheitskategorie2 (der PC ist zwar infiziert, aber die Kommunikation kommt nicht zustande, solange der Malwareport von der externen Firewall nicht auf den PC geleitet wird)
Ein weiteres, unfreiwilliges TOR zur Welt stellen die meisten Anonymisierungsdienste dar. Diese werden im Internetbrowser in der Regel als lokaler Proxy eingetragen. Das bedeutet, dass ein Proxyprogramm auf dem eigenen Rechner läuft und dort an einem lokalen Port auf die Anfragen des Internetexplorers wartet. Diese Anfragen schickt das Programm dann weiter in das Internet. Sinn des Programms ist es, persönliche Daten herauszufiltern, welche der Browser ohne den Proxy ins Netz übertragen würde. Der Proxy kann die Anfrage auch an einen (ggf. dynamisch ermittelten) Proxyserver aus dem Internet schicken, um die eigene Absender-IP-Adresse gegenüber dem Ziel zu verbergen. Wird ein vollwertiger Anonymisierungsdienst verwendet, dann verschlüsselt der lokale Proxy sogar alle zu übertragenen Daten und schickt diese zu einem Partnerserver bzw. einem Serververband ins Netz, der die Daten entschlüsselt und zum Ziel geleitet. So kennt nicht einmal der Internetprovider das Ziel, geschweige denn den Inhalt der Datenpakete.
Was für die Anonymität gut ist, stellt für die Desktopfirewall ein großes Problem dar. Die Netzwerkkommunikation wird über einen zentralen Prozess geleitet: Den lokalen Proxy. Die meisten Programme übernehmen nun einfach die Proxyeinstellungen des Standardbrowsers, bevor sie mit dem Internet kommunizieren. Hat der Proxy das Recht erhalten, auf das Netzwerk zuzugreifen, dann wurde damit unbewusst die Internetverbindung für alle Programme erlaubt, welche die Browsereinstellung für sich adoptiert haben.
Teil 2 von 3 der Zusammenfassung zur Frage: Wie lässt ist die Applikationszugriffskontrolle einer Desktopfirewall unterwandern?
Die Verwendung von Fensternachrichten stellt unter Windows ein Problem für Desktopfirewalls dar. Öffnet die Firewall z.B. einen Dialog, um den Anwender zu fragen, ob eine Applikation auf das Netz zugreifen darf oder nicht, so erzeugt der Klick mit der Maus auf die OK-Taste eine Fensternachricht, welche die Firewallapplikation davon in Kenntnis setzt, das der Anwender genau diese Taste betätigt hat. Das Problem: Die Nachricht kann jedes Programm an den Dialog der Firewallapplikation schicken, ohne dass die Firewallapplikation feststellen kann, ob die Nachricht tatsächlich vom Anwender oder einer Fremdapplikation stammt. Eine Malware kann sich auf diese Weise also selbst die Berechtigung zum Netzwerkzugriff erteilen, noch ehe der Anwender interagieren kann. Der Anwender sieht lediglich ein kurzes Aufflackern des Firewalldialoges, was in der Regel aber derart schnell vonstatten geht, dass der Anwender das nicht als Attacke erkennt.
K2 (Internet->PC): Diese Methode gehört zur Sicherheitskategorie2 (der PC ist zwar infiziert, aber die Kommunikation kommt nicht zustande, solange der Malwareport von der externen Firewall nicht auf den PC geleitet wird)
Die Entwickler von Desktopfirewalls lernen von den Tricks diverser Malware. So fangen einige der Firewalls Systemfunktionen ab, die verwendet werden, um eine Applikation aus einer anderen Applikation heraus zu starten. So können sie erkennen, wenn z.B. der Standardbrowser nicht von dem Anwender, sondern aus einer Fremdapplikation heraus gestartet wurde, um eine Verbindung mit dem Internet zu erhalten (ein Verfahren, welches sich u.a. tag-Trojaner zueigen machen). Per Dialog kann der Anwender dies nun erlauben oder verbieten. Diese Technik soll jedoch zwischen dem Aufruf durch eine Fremdapplikation und dem „händischen“ Aufruf durch den Anwender unterscheiden, da letzteres ja erlaubt ist und daher keine Warnung erzeugen soll. Genau das kann sich die Malware zunutze machen, um diese Barriere zu umgehen. So erzeugt sie z.B. nacheinander folgende Systemnachrichten:
- Drücken von [Windows-Taste]+[r] zum Öffnen des "Ausführen"-Dialogs
- maschinelle Eingabe des aufzurufenden Programmnamens + [Enter]-Taste
Für die Firewallsoftware erscheint der Programmaufruf so, als ob der Anwender ihn von Hand gestartet hätte. Sie erkennt darin keinen Regelverstoß und lässt den Aufruf ohne Warnung zu. Der Anwender sieht lediglich ein sehr kurzes Aufklappen des Run-Dialogs von Windows.
Das Programm, welches auf das Netzwerk zugreifen darf, kann durch die Malware infiziert oder gar ausgetauscht werden. Leider gibt es noch immer einige Desktopfirewalls, die eine Infektion nicht erkennen.
K1 (PC->Internet): Diese Methode gehört zur Sicherheitskategorie1B (Schreibrecht auf das Programm vorausgesetzt, sonst 1A) / in Ausnahmefällen auch zur Sicherheitskategorie2B (siehe hier)
K2 (Internet->PC): Diese Methode gehört zur Sicherheitskategorie2 (der PC ist zwar infiziert, aber die Kommunikation kommt nicht zustande, solange der Malwareport von der externen Firewall nicht auf den PC geleitet wird)
Die Fensternachrichten können auch dazu verwendet werden, um einen PC per Internetbrowser komplett fernzusteuern. Ein Beispiel dafür liefert die „wwwsh“, welche beim Chaos Seminar des CCC Ulm vorgestellt wurde. Als Kommunikationsinterface lässt sich hier das URL-Fenster verwenden, worin die Malware alle Serveranfragen hineinschreibt und dem Server dadurch Daten übermitteln kann. Als Antwort veranlasst der Server, dass der Browser automatisch auf eine andere URL geleitet wird, wodurch sich die URL-Zeile des Browsers verändert. Die veränderte „Antwort“-Zeile liest die Malware wieder aus und erhält so ihre Anweisungen. Es gibt mehrere Methoden, das Browserfenster zu verstecken, sodass der Anwender keinen Hinweis auf die versteckte Kommunikation erhält. Und wenn der Anwender dem Browser die Erlaubnis erteilt hat, ungefragt mit dem Internet zu kommunizieren, geht diese Kommunikation natürlich durch die Desktopfirewall hindurch.
Einige Desktopfirewalls interpretieren die DNS-Anfrage einer Applikation nicht als Netzwerkzugriff, welcher zuvor von dem Anwender erlaubt werden muss. In solchen Fällen kann die Malware auch einen DNS-Tunnel dazu verwenden, um an der Firewall vorbei mit dem Netzwerk zu kommunizieren. Das Tunneln aller anderen Protokolle hingegen hat für sich noch lange keinen Einfluss auf die Funktionstüchtigkeit der Applikationszugriffskontrolle einer Desktopfirewall. Diese muss durch die Malware also noch separat ausgehebelt werden, damit die geheime Netzwerkkommunikation der Desktopfirewall nicht auffällt.
Der Prozess versteht es, sich aus der Prozessliste des Systems auszuklinken. Die Desktopfirewall sieht den Prozess also nicht. Da die Applikationszugriffskontrolle auf einer Prozesskontrolle basiert, geht im ungünstigsten Fall der Netzwerkzugriff an diesem Feature vorbei – also ohne dass die Desktopfirewall einen Regelverstoß erkennt.
K2 (Internet->PC): Diese Methode gehört zur Sicherheitskategorie2 (der PC ist zwar infiziert, aber die Kommunikation kommt nicht zustande, solange der Malwareport von der externen Firewall nicht auf den PC geleitet wird)
Indem die System Service Dispatch Table modifiziert wird, lässt sich verhindern, dass die Desktopfirewall vom System benachrichtigt wird, wenn ein Netzwerkzugriff erfolgt. Die Malware gaukelt der Desktopfirewall also vor, dass keine Netzaktivität besteht, was zur Folge hat, dass sie den unerlaubten Zugriff nicht bemerkt.
K2 (Internet->PC): Diese Methode gehört zur Sicherheitskategorie2 (der PC ist zwar infiziert, aber die Kommunikation kommt nicht zustande, solange der Malwareport von der externen Firewall nicht auf den PC geleitet wird)
Firewalls sind auf vorgefertigte Systemroutinen angewiesen, wie sie z.B. in der winsock.dll bzw. w32sock.dll zu finden sind. Sie werden u.a. benötigt, um auf den TCP/IP-Stack überwachend zugreifen zu können. Es gibt Malware, welche einfach die relevanten dll’s durch eigene Versionen ersetzen, um die Firewall an ihrer Arbeit zu hindern.
K2 (Internet->PC): Diese Methode gehört zur Sicherheitskategorie2 (der PC ist zwar infiziert, aber die Kommunikation kommt nicht zustande, solange der Malwareport von der externen Firewall nicht auf den PC geleitet wird)
Teil 3 von 3 der Zusammenfassung zur Frage: Wie lässt ist die Applikationszugriffskontrolle einer Desktopfirewall unterwandern?
Ähnlich wie bei einem Bootsektorvirus kann sich eine Malware in den MBR schreiben. So wird sie geladen, noch bevor das Betriebssystem gestartet wird. Auch hier ist es ihr möglich, unbemerkt auf das Netzwerk zuzugreifen. Ob und wie sich die Malware parallel zum geladenen Betriebssystem halten kann, hängt davon ab, welches Betriebssystem verwendet wird. Diese Aufgabe ist allerdings nicht ganz trivial. Natürlich wird kaum jemand den Aufwand betreiben, nur um eine Desktopfirewall zu umgehen. Allerdings gibt es solche Ansätze, um Passworte für verschlüsselte Partitionen zu tracen, welche von dem Verschlüsselungsprogramm noch vor dem Start des Betriebssystems abgefragt werden. Es ist wichtig zu wissen, dass eine solche Malware auch in der Lage ist, die geraubten Informationen über das Netz zu übertragen, ohne dass die installierte Desktopfirewall das verhindern kann.
K2 (Internet->PC): Diese Methode gehört zur Sicherheitskategorie2 (der PC ist zwar infiziert, aber die Kommunikation kommt nicht zustande, solange der Malwareport von der externen Firewall nicht auf den PC geleitet wird)
Manchmal ist es möglich, die Applikationszugriffskontrolle einer Desktopfirewall durch das unsanfte Beenden des Moduls einfach auszuhebeln. Die Malware könnte auch den Aufruf des Moduls aus der Registry löschen bzw. durch ähnlich aussehende Programme ersetzen. Zudem lässt sich manchmal das User-Frontends mit dem Dateinamen eines entsprechend präparierten Programms überschreiben.
K2 (Internet->PC): Diese Methode gehört zur Sicherheitskategorie2 (der PC ist zwar infiziert, aber die Kommunikation kommt nicht zustande, solange der Malwareport von der externen Firewall nicht auf den PC geleitet wird)
Es ist auch möglich über angepasste Geräte- oder Filtertreiber eine Kommunikation mit dem Netz aufzubauen, ohne dass sich eine Applikation sichtbar an einen Port bindet. Bildlich gesehen wird ein Bypass für die Netzwerkkommunikation verwendet, was dazu führt, das die Applikationszugriffskontrolle der Desktopfirewall nicht erkennen kann, wer die Pakete sendet oder empfängt. Zudem kann der Kernelthread des (Filter-) Treibers verhindern, dass die Firewall etwas von dem Datentransfer erfährt.
K2 (Internet->PC): Diese Methode gehört zur Sicherheitskategorie2 (der PC ist zwar infiziert, aber die Kommunikation kommt nicht zustande, solange der Malwareport von der externen Firewall nicht auf den PC geleitet wird)
Eine virtuelle Netzwerkkarte (IP-Aliasing) schafft einen eigenen TCP/IP-Stack, der im ungünstigsten Fall einfach an der Desktopfirewall vorbei sendet. Vor allem ältere Desktopfirewalls, die nur eine einzige Netzwerkkarte verwalten können, lassen sich dadurch umgehen. Aber auch einige neue Modelle haben damit Probleme, wenn die virtuelle Netzwerkkarte nicht schon beim Start der Firewallsoftware vorhanden ist.
K2 (Internet->PC): Diese Methode gehört zur Sicherheitskategorie2 (der PC ist zwar infiziert, aber die Kommunikation kommt nicht zustande, solange der Malwareport von der externen Firewall nicht auf den PC geleitet wird)
Des Weiteren kann eine Malware die Netzwerkpakete einer bestehenden Verbindung um Informationen erweitern und erweiterte Informationen auswerten. So ist ein unbemerkter Informationsaustausch mit dem Kommunikationspartner möglich, der an die Firewall vorbeigeht. Dadurch lässt sich die Malware auch durchaus fernsteuern. Der Clou ist, dass die Malware dazu keine eigene Verbindung zum Internetserver aufbauen muss, was ja bereits auffallen könnte. Sie nutzt vielmehr die bestehende Verbindung, welche sie manipuliert. Allerdings ist das auch der große Nachteil dieser oft zitierten Attacke: Die Malware ist darauf angewiesen, dass der Anwender von sich aus eine Verbindung zu genau diesem Kommunikationspartner aufbaut, damit sie aktiv werden kann.
Eine andere Methode ist es, über dll-Injektion innerhalb eines laufenden Prozesses einen eigenen Thread zu starten. Der Thread läuft sinnbildlich wie ein eigenes Programm im Adressraum des injizierten Prozesses. Die Malware kann so einen Prozess auswählen, der auf das Netz zugreifen darf und unter dem Deckmantel des Prozesses ebenfalls auf das Netz zugreifen. Der Clou: Die Programmdatei des Prozesses wird dabei nicht verändert, sodass ein simpler Quersummencheck noch lange keinen Hinweis auf eine Injektion liefert. Das erscheint logisch, wenn der Thread erst dann durch die Malware injiziert wird, nachdem der Prozess bereits gestartet wurde. Diesen Job erledigt ein zweiter Prozess, welcher unauffällig im Hintergrund läuft, oder aber ein eigens dafür erzeugter Thread, den der Malwareprozess vorzugsweise in einen Systemdienst injiziert, bevor sich die Malware wieder beendet. So läuft die Malware kaum Gefahr, entdeckt zu werden.
Einige Desktopfirewalls versuchen die dll-Injektion anhand von bestimmten Funktionsaufrufen zu erkennen (z.B. OpenProcess, VirtuallAllocEx, WriteProcessMemory, CreateRemoteThread, etc.). Dazu wird die passende API gehookt und somit auf die eigene Funktion gelenkt, welche eine höchst eigene Zugriffskontrolle realisiert und bei einem Regelverstoß Alarm auslöst und die Injektion unterbindet. Die Malware kann sich der Kontrolle entziehen, wenn sie die originalen Funktionsadressen direkt anspringt. Dadurch wird die umgeleitete Funktion der Desktopfirewall nicht aufgerufen, weshalb der Zugriff nicht bemerkt wird. Für die Malware wirkt sich diese Methode allerdings Nachteilig aus, wenn sich durch ein Servicepack die System-dll der verwendeten APIs und damit die ersehnte Einsprungadresse ändert.
dll-Injektion lässt sich auch durch das Verändern der Programmdatei realisieren. Der Vorteil für die Malware ist, dass es keinen zweiten Prozess bedarf, der die Programmdatei erst dann mit der dll injiziert, wenn das Programm bereits läuft. Auch werden die ggf. überwachten API-Funktionen der indirekten dll-Injektion nicht mehr benötigt. Der Nachteil ist, dass die Veränderung der Programmdatei auffällig ist und nicht nur viele Desktopfirewalls, sondern auch verschiedene Virenscanner auf das Verändern von exe-Code allarmierend reagieren.
Diese Methode gehört zur Sicherheitskategorie1B / wenn der Anwender jedoch kein Schreibrecht auf die anzupassende Programmdatei hat, gehört die Methode zur Sicherheitskategorie1A.
Natürlich lässt sich auch durch den Austausch einer von dem Programm beanspruchten dll eine Injektion des eigenen Malware-Threads realisieren.
Diese Methode gehört zur Sicherheitskategorie1B / wenn der Anwender jedoch kein Schreibrecht auf die dll-Datei hat, gehört die Methode zur Sicherheitskategorie1A.
Unter Windows lässt sich eine dll-Injektion auch durch die simple Änderung eines Registryeintrags realisieren, welcher bewirkt, dass bei jedem Start einer Applikation auch eine bestimmte dll in deren Prozessraum geladen wird.
Zusammenfassung zur Frage: Wie lässt ist das Firewallmodul einer Desktopfirewall umgehen (IP-Sperrlisten, Port- und Protokollregeln Außerkraftsetzen)?
Der IP-Filter einer Desktopfirewall lässt sich bei einigen Modellen durch eine übermäßige Fragmentierung der Nutzdaten umgehen. Dank einer Tiny- bzw. Overlapping-Fragment-Attack kann es somit gelingen, mit einer vermeintlich gesperrten IP-Adresse Zugriff auf einen freigegebenen Dienst des Rechners zu erlangen.
Eine virtuelle Netzwerkkarte (IP-Aliasing) schafft einen eigenen TCP/IP-Stack, der im ungünstigsten Fall einfach an der Desktopfirewall vorbei sendet. Vor allem ältere Desktopfirewalls, die nur eine einzige Netzwerkkarte verwalten können, lassen sich dadurch umgehen. Aber auch einige neue Modelle haben damit Probleme, wenn die virtuelle Netzwerkkarte nicht schon beim Start der Firewallsoftware vorhanden ist.
K2 (Internet->PC): Diese Methode gehört zur Sicherheitskategorie2 (der PC ist zwar infiziert, aber die Kommunikation kommt nicht zustande, solange der Malwareport von der externen Firewall nicht auf den PC geleitet wird)
Genau wie bei externen Firewall ist es auch bei Desktopfirewalls möglich, die Portregeln indirekt durch das Tunneln erlaubter Protokolle zu umgehen.
Manchmal ist es möglich, die Desktopfirewall und damit die Portregeln durch unsanftes Beenden einfach auszuhebeln. Die Malware könnte auch den Aufruf des Firewallmoduls aus der Registry löschen bzw. durch ähnlich aussehende Programme ersetzen. Zudem lässt sich manchmal das User-Frontends mit dem Dateinamen eines entsprechend präparierten Programms überschreiben. Auch ist es bei einigen Desktopfirewalls möglich, die Portregeln durch die Malware direkt zu manipulieren.
Alle Methoden zur direkten Umgehung von Portregeln einer Desktopfirewall (nicht Tunneln) gehören zur Sicherheitskategorie2C
Zusammenfassung zur Frage: Wie lässt ist der Stealth Mode einer Desktopfirewall umgehen?
Viele Desktopfirewalls bieten eine art Tarnkappe für den PC an, genannt "Stealth Mode", welcher bewirkt, dass der PC auf keinerlei Anfragen aus dem Netz reagiert (DROP). Der PC soll sich dadurch im Netz so verhalten, als wäre er nicht anwesend. Das Konzept klingt einleuchtend: Was ein Angreifer nicht sieht, kann er nicht angreifen. Nur ist das nicht ganz richtig. Denn wird eine IP-Adresse durch einen Scan per ICMP Echo Requests aus einem anderen Subnetz angesprochen und ist die IP-Adressen ungültig bzw. der PC nicht eingeschaltet, so schickt der Router auf Pings eine „Destination unreachable“-Antwort. Die Desktopfirewall hingegen antwortet einfach nicht. Keine Antwort ist in diesem Fall also auch eine Antwort: Auf diese Weise signalisiert die Desktopfirewall dem Angreifer, dass es sich um eine gültige IP-Adresse eines Rechners handelt, auf dem eine Desktopfirewall installiert wurde. Auch ein Portscann ist noch immer möglich. Das Problem, dass es bei Anfragen zu einer Zeitüberschreitung kommt, lässt sich umgehen, indem der Portscanner die Anfragen parallel zum Rechner schickt. Keine Antwort bedeutet, dass der Port gefiltert wurde. Der Portscan wird durch den „Stealth Mode“ ausgebremst, aber nicht verhindert.
LAN (Angriff aus dem internen Netz heraus): Diese Methode gehört zur Sicherheitskategorie1
K2 (Internet->PC): Diese Methode gehört zur Sicherheitskategorie3 (der PC ist durch PAT der externen Firewall ohnehin für die Aussenwelt nicht sichtbar)
Zusammenfassung zum Thema: Sicherheitslücken die durch eine Desktopfirewall überhaupt erst entstehen
Es gibt Desktopfirewalls, die nachweislich eigene Verbindungen zu ihren Internetservern herstellen. Das geschieht natürlich ohne dass sie selbst darauf hinweisen. Hier geht die Kommunikation also nicht einfach nur an die Desktopfirewall vorbei, sondern wird sogar noch von ihr initiiert. Selbst wenn laut Herstellerangaben lediglich Daten für statistische Zwecke übermittelt werden, bleibt das eine höchst fragwürdige Aktion. Denn oftmals wird die Desktopfirewall installiert, weil man solche ungewollten Zugriffe verhindern möchte. Wenn es sich um "closed source"-Produkte handelt, kann man zudem nicht wirklich sicher sein, welche Daten tatsächlich übermittelt wurden und ob es nicht noch andere, geheime Funktionalitäten gibt, die der Anwender nicht wissen soll^^
K2 (Internet->PC): Diese Methode gehört zur Sicherheitskategorie2 (die Kommunikation kommt nicht zustande, solange der Port von der externen Firewall nicht auf den PC geleitet wird)
Manchmal ist es möglich, durch manipulierte Netzwerkanfragen an den zu schützenden Rechner die Desktopfirewall derart zu überlasten, dass sie nach der Attacke nicht mehr ordnungsgemäß funktioniert. Zumindest aber lässt sich für die Zeit der Attacke das komplette System in die Knie zwingen. Auf diese Weise ermöglicht die Firewallsoftware erst eine DoS-Attacke auf das zu schützende System.
So werden z.B. bei einem so genannten Stream-Angriff Datenpakte generiert, die nicht zu einer bestehenden Verbindung gehören. Um Portscanns zu entdecken, überprüft die Firewall ständig ob die Pakete zur bestehenden Verbindung gehören, was bei der Flut der Pakete eine Überlastung der Software zur Folge hat. Im ungünstigsten Fall kann sich dabei innerhalb von ein paar Minuten das Kernelmodul verabschieden, was die Firewall nach der Attacke wirkungslos macht.
LAN (Angriff aus dem internen Netz heraus): Diese Methode gehört zur Sicherheitskategorie1
K2 (Internet->PC): Diese Methode gehört zur Sicherheitskategorie3 (ein Versuch die Desktopfirewall direkt zu attackieren scheitert an PAT der externen Firewall)
Ein Personalprotektor lässt sich mit personenbezogenen Daten wie Namen, Adresse und Kreditkarteninfos füttern. Er soll verhindern, dass die angegebenen Einträge ins Netz übermittelt werden. Leider funktioniert dies nicht, wenn die Daten verschlüsselt sind, was in der Regel der Fall ist, wenn eine Malware die Daten ins Netz sendet. Ein fragwürdiger Schutz also, da die Firewall eine Sicherheit vortäuscht, die es effektiv nicht gibt.
Schlimmer noch: Alle geheimen Daten liegen so zentral an einer Stelle. Gelingt es einem Eindringling auf diese Daten zuzugreifen, so stehen ihm mit einem Schlag alle schützenswerten Informationen zur Verfügung. Nicht zuletzt lassen sich auch Attacken von außen auf Personalprotektoren vornehmen, welche z.B. über das Internet alle möglichen Zahlenkombinationen abfragen und so anhand der gesperrten Zahlen erkennen, welche PINs der Anwender im Personalprotektor hinterlegt hat, etc.
Im Klartext schafft der Personalprotektor hier zusätzliche Angriffspunkte, die es ohne ihn nicht gibt. Zudem kann er die Übermittlung schützenswerter Daten über das Netz nicht wirklich verhindern, schafft dafür aber eine Grundlage für zahlreiche, unbegründete Fehlermeldungen. Man kann also nur davon abraten, ihn zu verwenden.
Einige Desktopfirewalls enthalten ein Intrution Detection System (IDS), welche manchmal auch den Netzwerkverkehr nach bekannten Angriffsmustern untersuchen. Sobald ein Angriff erkannt wird, kann die Firewall den Datenverkehr zwischen dem PC und dem Absender des Angriffs für eine gewisse Zeit unterbinden. Verheerend wirkt sich dieses Feature allerdings aus, wenn die Desktopfirewall keine Listen von Servern pflegt, die nicht gesperrt werden dürfen. Dann ermöglicht das IDS einem Angreifer eine effiziente DoS-Attacke, indem einfach Angriffsmuster mit veränderten Absenderadressen an den PC gesendet werden. So wird der PC in kürzester Zeit vom Netz abgetrennt, da er wichtige Netzwerkkomponenten wie „default Gateway“ und DNS-Server, sowie die Kommunikationspartner im eigenen Netzsegment stück für stück durch die Sperrung der Desktopfirewall verliert.
Diese Methode gehört zur Sicherheitskategorie3 (ein Versuch die Desktopfirewall aus dem externen Netz heraus direkt zu attackieren scheitet an PAT der externen Firewall)
Genau wie bei allen anderen auf dem PC installierten Softwareprodukten auch, kann die Desktopfirewall fehlerhaft programmiert worden sein und somit ungewollt neue Angriffspunkte für den PC liefern. Da viele ihrer Komponenten mit erweiterten Rechten laufen (im so genannten Systemkontext) oder gar Kernelkomponenten installieren, wirken sich jedoch Programmier- und Designfehler hier besondern verheerend auf die Sicherheit und Stabilität des Systems aus.
Ein Buffer-Overflow ist ein Fehler in einem Programm. Wenn ein Programmierer für eine bestimmte Aktion (Kopieren bzw. Einlesen von Daten, auch das Lesen von Benutzereingaben) einen zu kleinen Speicherbereich (Puffer) vorgesehen hat und nicht überprüft, ob die Eingabe auch in diesen passt, wird durch überlange Eingaben über den Puffer hinaus ein Teil des Programmspeichers überschrieben. Auf diese Weise kann beliebiger anderer Code im Kontext des Programms ausgeführt werden. Ein Programmcode, der den Programmierfehler ausnutzt, nennt man Exploit.
Wie schon erwähnt ist auch die Desktopfirewall eine Software, die solche Fehler aufweisen kann. Im ungünstigsten Fall erlangt der Angreifer durch den Exploit nicht nur erweiterte Rechte. Manchmal erhält er dadurch überhaupt erst Zugriff auf das System, wie es bei dem fehlerhaft programmierten PAM (Protocol Analysis Module) von BlackICE und RealSecure der Fall war. Der Fehler verhalf dem UDP-basierten Wurm „Witty“ zu seinem zweifelhaften Ruhm.
Lokal: Diese Methode gehört zur Sicherheitskategorie1B (die externe Firewall kann gegen lokale Aktivitäten nichts unternehmen)
K2 (Internet->PC): Diese Methode gehört zur Sicherheitskategorie3 (ein Versuch die Desktopfirewall aus dem externen Netz heraus direkt zu attackieren scheitet an PAT der externen Firewall)
Wechselt eine Systemkomponente auf den Anwenderdesktop, um dort z.B. einen Dialog auszugeben, kann es einem Angreifer gelingen, dadurch erweiterte Rechte zu erlangen. Stark vereinfacht ausgedrückt läuft alles was Fensternachrichten empfängt potentiell Gefahr dazu missbraucht zu werden, fremden Code auszuführen. Zumindest aber kann der Thread zu Aktionen überredet werden, die der Programmierer so nicht vorgesehen hat. Deshalb warnt Microsoft davor, solche Designfehler zu begehen (ein Dienst sollte niemals auf den Anwenderdesktop wechseln). Ob das aus fahrlässiger Bequemlichkeit oder aus Unwissenheit heraus passiert, bleibt das Geheimnis des Programmierers. Fest steht, dass solche Designfehler immer mal wieder in Desktopfirewalls auftauchen.
Diese Methode gehört zur Sicherheitskategorie1B. (die externe Firewall kann gegen lokale Aktivitäten nichts unternehmen)
Erläuterung zur Bezeichnung „Sicherheitskategorie 1 und in AusnahmefällenSicherheitskategorie 2“
Warum keine Sicherheitskategorie 3?:
Zunächst einmal sollte man sich darüber im Klaren sein, dass die externe Firewall keine Befugnisse auf dem lokalen System (dem PC) hat. Sie kann gegen die lokalen Aktivitäten eines Programms also nicht unternehmen. Lediglich Attacken, die aus dem externen Netz kommen und den PC angreifen sollen, kann sie unterbinden. Nicht mehr und nicht weniger.
Warum stellt die Sicherheitskategorie 2 nur eine Ausnahmesituation dar?:
Sollte die Malware, nachdem sie die Desktop Firewall ausgetrickst hat, über einen durch die externe Firewall gesperrten Port mit dem externen Netz kommunizieren wollen, dann – und nur dann – kann die externe Firewall den Schaden begrenzen. Verwendet die Malware hingegen einen freien ausgehenden Port (z.B. Port 80), dann ist auch die externe Firewall machtlos.
Die Applikationszugriffskontrolle basiert auf einer Prozesskontrolle und ist deshalb einzig und allein der lokal installierte Desktopfirewall vorbehalten. Da die externe Firewall aus rein technischen Gründen nicht im Stande ist, diesen Job zu übernehmen, kann sie hier auch keinen Schutz bieten. Ohne die Desktop Firewall bedarf es also nicht einmal einer Attacke, um durch die externe Firewall hindurch auf das externe Netz zugreifen zu können. Deshalb fällt der so klassifizierte Angriff in die Sicherheitskategorie 1 und in Ausnahmefällen in die Sicherheitskategorie 2, denn die schützende Wirkung der Portsperre ist zwar unwahrscheinlich, aber nicht unmöglichen.
Hinweis zur Sicherheitskategorie 2:
Sonderfälle bestätigen die Regel, was an dieser Stelle nicht verschwiegen werden darf. Denn es gibt durchaus Methoden, welche einer externen Firewalls dabei helfen, das Manko der Prozesskontrolle ansatzweise auszugleichen. So lassen sich bei einigen professionellen, externen Firewalls über protokollspezifische Filter auch Applikationszugriffsregeln erstellen, was jedoch eine große Ausnahme darstellt (solche Filter gibt es nur für eine feste und sehr kleine Anzahl bekannter Applikationen; zudem sind sie stark von der Applikationsversion abhängig, was dazu führt, dass sie nur sehr selten eingesetzt werden). Auch ist es möglich, dass die externe Firewall über einen speziellen Filter verfügt, welcher nach bekannten Malwaresignaturen in den Netzwerkpaketen eines Dienstes sucht und die Pakete bei Identifikation sperrt (=>Konzept eines IDS + IRS (IPS) als Firewall-AddOn). Zudem gibt es die Möglichkeit, dass sich jede Applikation vor der Netzwerkkommunikation wenigstens einmal bei der exterenen Firewalll authentifizieren muss (das ist ebenfalls abhängig vom verwendeten Protokoll und meist beschränkt auf HTML). Diese Features erhöhen die schadensbegrenzende Wirkung der externen Firewall auch jenseits der Portsperre. Da sie jedoch bei externen Home-Firewalls kaum anzutreffen sind, stellen sie zumindest in dieser Sparte ganz klar eine Ausnahme dar.
Ein paar Posts zuvor hatten wir folgendes Problem erörtert, welches ich aufgrund neuer Erkenntnisse hier noch einmal zusammenfassen möchte:
Was hat es für eine rechtliche Konsequenzen, wenn ein Hacker über ein heimlich installiertes Hackertool in den Rechner eines anderen eindringt (im folgenden Rechner1 genannt). Dann geht er von Rechner1 auf das System, welches er tatsächlich angreifen will (Rechner2). Der Angriff fliegt auf. Die IP-Adresse von Rechner1 ist auf Rechner2 registriert und der Betreiber von Rechner2 verklagt daraufhin den Betreiber von Rechner1.
Voraussetzung für den konstruierten Fall ist, dass die Übernahme von Rechner1 mit Hilfe einer Firewall hätte verhindert werden können. Das Problem: Auf dem System von Rechner1 befindet sich keine Firewall.
Ein Mix aus den Internetrecherchen und privaten, sowie öffentlichen Diskussionen aus diesem Forum ergab folgendes Resultat:
Zunächst wird der Betreiber von Rechner1 als Täter verdächtigt und ist in Erklärungsnot. Aber selbst wenn er nachweisen kann, dass jemand aus der Ferne seinen PC für den Angriff missbraucht hat, könnte es ein rechtliches Problem für ihn geben: Wurde sein System nicht geschützt und hätte z.B. eine Firewall die Übernahme des PCs verhindern können, so könnte ein Richter der Auffassung sein, dass er grob fahrlässig gehandelt hat. In diesem Fall wäre eine erfolgreiche Klage gegen ihn möglich, da er seiner Sorgfallspflicht nicht nachgekommen ist und ein anderer dadurch Schaden erlitten hat.
Haftet man für sein Eigentum oder präziser für das Betreiben desselben, würde das bedeuten, dass es auch seiner Verantwortung obliegt, den PC (oder Server) vor Missbrauch zu schützen. Um diese These zu untermauern, eignet sich folgender Vergleich: Jeder kann sich ein Auto zulegen, aber fahren darf man es erst, wenn man sich über die geltenden Regeln und möglichen Konsequenzen seiner Handlungen informiert hat. Bei einem Auto gibt es dafür eine Nachweispflicht: Den Führerschein. Bei einem Fahrrad ist das nicht der Fall, obwohl man sich auch hier an diese Regeln halten muss. Im Schadensfall hilft es einem Radfahrer nicht zu behaupten, dass er die betreffende Verkehrsregel nicht kannte. Die Verpflichtung sich zu informieren resultiert folglich nicht aus dem Erwerb eines Führerscheins, sondern von dem Gebrauch einer Sache. Das Modell lässt sich auf alles Mögliche abbilden. Wird etwas unsachgemäß angewendet oder bietet eine Gefahrenquelle, die nicht geschützt wird, so besteht die Gefahr, dass man als Betreiber im Schadensfall dafür haftbar gemacht werden kann.
Die Annahme war nun, dass dies bei einem Rechner nicht anders ist. Jeder kann sich demzufolge zwar einen Rechner zulegen, nur betreiben darf man ihn erst, nachdem man sich über den Gebrauch ausreichend informiert hat. Das schließt den Schutz des Systems vor Missbrauch mit ein, auch wenn er sich gewiss in einem vertretbaren Rahmen bewegen muss, so die These.
Das Problem: Wirklich eindeutige Aussagen dazu findet man weder im Internet, noch in einschlägigen Computerzeitschriften. Und die Vermutung lag nahe, dass im oben gezeigten Statement aus rechtlicher Sicht viele Fehler gemacht wurden. Da sich das Thema auf diese Weise nicht eindeutig klären ließ, habe ich eine Online-Rechtsberatung in Anspruch genommen. Das Resultat möchte ich euch nicht vorenthalten:
„Die Ermittlungsbehörden (Staatsanwaltschaft - Polizei) soweit eingeschaltet - würden den Betreiber von Rechner 1 aufgrund der IP als Urheber des Angriffs ermitteln, was für den Betreiber zu erheblichen Unannehmlichkeiten (strafrechtliche Verfolgung) führen würde. Kann der Betreiber des Rechners 1 beweisen, dass ein Hackertool ohne sein Wissen tätig geworden ist, dürfte der Betreiber 1 aus dem Schneider sein. Handelt es sich aber um ein Hackertool, welches seine Spuren verwischt, kommt der Betreiber von Rechner 1 in arge Erklärungsnöte, wenn die Ermittler nicht noch Spuren des Tools finden können.
Eine zivilrechtliche Verfolgung/Haftung des Betreibers/Eigentümers von Rechner 1 setzt voraus, dass diesen eine Verkehrspflicht treffen würde. Dies bedeutet, dass jemand der in seinem Verantwortungsbereich Gefahren schafft oder andauern läßt, alle geeigneten, erforderlichen und zumutbaren Vorkehrungen treffen muss, um Gefahren von Dritten abzuwenden. Dies könnte hier die Installation einer Firewall bedeuten. Nach dem derzeitigen Stand gibt es eine solche Verpflichtung aber weder gesetzlich noch durch richterliche Entscheidung. Jeder hat zwar dafür Sorge zu tragen, dass sein Eigentum Dritten nicht schadet, eine Verpflichtung zur Installation einer Firewall resultiert daraus aber (derzeit) nicht. Meines Erachtens wird es dazu in absehbarer Zeit auch nicht kommen, denn zunächst kann jeder selbst entscheiden, ob und wie er seinen PC sichert.
Hinweis: Ein Gericht könnte dies im Streitfalle anders sehen, da das richterliche Ermessen einen erheblichen Auslegungsspielraum zuläßt.
Dazu noch ein Beispiel: Wenn jemand in ein Haus unter einem Vorwand mal telefonieren zu wollen eindringt, dort ein Messer stiehlt und einen Dritten mit diesem Messer tötet, ist der Inhaber des Messers nicht für die Tat verantwortlich, nicht einmal dann, wenn er das Messer hat offen liegen.“
Dieses Antwortschreiben lässt schon eine menge Licht ins Dunkel, was ich für das folgende Fazit nutzen möchte:
Wird ein fremder Rechner für eine Attacke missbraucht und fliegt die Attacke wie oben beschrieben auf, so ist das mit erheblichen Unannehmlichkeiten für den Betreiber des Rechners verbunden.
Der Betreiber ist in Erklärungsnot. Zu seiner Entlastung muss er bzw. die forensische Analyse der Ermittlungsbehörde den Beweis erbringen, dass die Attacke über ein Hackertool gestartet wurde und nicht von dem Betreiber des Rechners erfolgt ist. Ob die bloße Existenz eines Hackertools auf dem Rechner genügt oder ob die Beweispflicht darin besteht, zu belegen, dass das Hackertool auch zur Zeit des Angriffs benutzt wurde, konnte das Schreiben nicht eindeutig klären. Die Vermutung liegt nahe, dass diese Entscheidung vom Richter abhängig sein wird.
Eine gesetzliche Verpflichtung sein System durch präventive Maßnahmen zu schützen, gibt es nicht. Jedoch bedeutet das nicht, dass man bei einem Missbrauch keine rechtlichen Konsequenzen zu befürchten hat, nur weil man ja nicht verpflichtet war, das System zu schützen. Alles hängt von den entlastenden Beweisen und nicht zuletzt vom Richter ab, was ein wenig an russisches Roulett erinnert, wenn man ein offenes System mit dem Internet verbindet.
AW: Firewall FAQ für Fortgeschrittene 
) und mich auch mit Rechtsgelehrten darüber unterhalten. Und selbst bei Denen herrschen unterschiedliche Ansichten (wobei ich erwähnen muß, daß dort niemand mit dem Spezialgebiet Internetrecht dabei war). Summa Summarum gibt es mehr Stimmen, die meinen, daß es auch bei einer Privatperson eine grobe Fahrlässigkeit darstellen könnte, wenn auf deren System weder ein Virenscanner, noch eine Firewall installiert ist. Was eine grobe Fahrlässigkeit in Bezug auf diese Thematik genau darstellt, ist allerdings nirgends festgelegt (logisch, weil die Gesetze zu alt sind). Mit anderen Worten entscheidet das der Richter. Liegt aber eine grobe Fahrlässigkeit vor, so ist auch eine Privatperson rechtlich angreifbar.
Linear-Darstellung
