| View previous topic :: View next topic |
| Author |
Message |
Shadows
Apprentice
Joined: 30 Apr 2004
Posts: 178
|
 Posted: Sat Sep 25, 2004 11:08 pm Post subject: |
 |
|
Der einzige der es (außer dem Ursprungsposter) verstanden hat ist moe und vielleicht noch Deever.
Den anderen sei vielleicht folgendes als kleiner Tip gegeben:
Hier von einer "Firewall" zu sprechen ist vielleicht nicht das richtige und scheinbar genau der Grund, warum einige den Sinn hinter der Sache nicht verstehen können. Nennen wir es einfach "Applikationsbasierte Netzwerkzugriffskontrolle (ANK) (tm)"
Der Sinn einer Firewall besteht darin, den Verkehr zwischen zwei Netzwerken basierend auf Regeln zu schützen. Damit ist sowohl der eingehende sowie der ausgehende Netzwerkverkehr gemeint. Das hat aber erstmal überhaupt rein nie gar nix mit einzelnen Rechnern oder gar Applikationen zu tun. Null. Niente. Nada.
Der Sinn einer ANK besteht darin, einen einzelnen Rechner hauptsächlich vor AUSgehendem Netzwerkverkehr zu schützen - mehr nicht. Und wir vergessen jetzt einfach mal die so called "Personal Firewalls" - das ist nämlich nicht mehr als eine Marketingseifenblase. Es ist nämlich immer noch ein Unterschied, ob ich Netzwerkpakete bestimmter Protokolle oder bestimmter Programme filtere. Meine Firewall lässt nämlich HTTP-Pakete ungehindert passieren, aber wer sagt mir, dass die Maleware ihre Pakete nicht über HTTP tunnelt? Firewalls besitzen nämlich keinerlei Intelligenz - der User aber sehr wohl (sollte man zumindest meinen). Und genau deswegen macht das auch Sinn, den Zugriff Applikationsbasiert zu überwachen. Period.
| amne wrote: | | Vielleicht können sich die Beitragenden in diesem Thread ja darauf beschränken, wie man jetzt auf Programmebene Zugriff aufs Netz gibt so wie bei Zonealarm. |
Gibt es meines Wissens (und das soll erstmal nichts heißen ;) ) noch nicht, obwohl es rein programmiertechnisch auf den ersten Blick kein großer Aufwand sein sollte, alle vorhandenen Netzwerkinterfaces auf die zugreifenden Programme hin zu überprüfen. Ich weiß auch gar nicht, warum immer gleich alle auf den IP-Stack zugreifen wollen - schließlich soll sowas ja Protokollunabhängig funktionieren und was liegt da näher, als die Netzwerkinterfaces zu überwachen?
| ohoiza wrote: | naja, zumindest bei meiner kernelversion (2.6.7-mm6) lässt sich für netfilter folgende option einstellen:
Code:
CONFIG_IP_NF_MATCH_OWNER:
Packet owner matching allows you to match locally-generated packets based on who created them: the user, group, process or session.
damit ließe sich doch eigentlich das gewünschte zonealarm-verhalten bewerkstelligen, oder? |
Auf den ersten Blick sieht das ganz danach aus, als ob man das damit hinkriegen könnten. Man bräuchte natürlich nur noch ein Userspace-Programm, welches neue Pakete abfängt und die Regeln nach Interaktion mit dem Benutzer on-the-fly hinzufügt/löscht/ändert.
Greetz
Shad
_________________
# 1:
PIII 450, Intel 440BX, 448 MB SD-RAM ATI Rage IIC AGP 8 MB, SB AWE 64 PnP
# 2:
Athlon XP M 2800+ Desktop edition (running on 1.666 and 100 FSB) [was: Duron 800 (Spitfire)], Via KT266, 512 MB SD-RAM, GeForce 3 64 MB, Sound onBoard |
|
| Back to top |
|
 |
tacki
Guru
Joined: 29 Jun 2002
Posts: 418
Location: Germany
|
| Posted: Sat Sep 25, 2004 11:41 pm Post subject: |
|
|
natürlich hab ich auch verstanden was er will. allerdings ist das noch lange keine sicherheit wenn man das auf programmebene macht.
nehmen wir als beispiel mal nen normales gentoo-system.
wer gentoo benutzt wird sicher wget als proggy freischalten. nunja, wget ist bekanntlich sehr verbreitet, und ein 'böses' script wird sicher versuchen über wget mehr 'böse' sachen herunterzuladen und auszuführen. auf diese weise wurde zonealarm unter windows auch mehrmals umgangen (mit dem internet explorer statt wget).
deshalb reicht es nicht wenn man nur diesen kontrollmechanismus einsetzt, sondern wenn dann schon richtig via selinux + firewall. dann ist man relativ sicher 
_________________
"Kazaa ist der beste MP3-Player den es gibt!"
.o( ... ) |
|
| Back to top |
|
|
Sas
Veteran
Joined: 05 Jul 2003
Posts: 1229
Location: Germany
|
| Posted: Sun Sep 26, 2004 12:01 am Post subject: |
|
|
Ich glaube auch nicht, dass ihn hier keiner verstanden hat. In den Augen der Poster wäre er lediglich mit nem richtigen Paketfilter besser bedient. Deshalb raten wir ihm alle dazu.
_________________
42 |
|
| Back to top |
|
|
Shadows
Apprentice
Joined: 30 Apr 2004
Posts: 178
|
| Posted: Sun Sep 26, 2004 12:18 am Post subject: |
|
|
| tacki wrote: | | natürlich hab ich auch verstanden was er will. allerdings ist das noch lange keine sicherheit wenn man das auf programmebene macht. |
Bietet auf Einzelplatzsystemen für ausgehenden Netzwerkverkehr in meinen Augen sogar wesentlich mehr Sicherheit als jede Firewall. Begründung siehe unten.
| tacki wrote: | | wer gentoo benutzt wird sicher wget als proggy freischalten. |
Die Annahme ist schon falsch. Auch hierzu siehe unten.
| tacki wrote: | | nunja, wget ist bekanntlich sehr verbreitet, und ein 'böses' script wird sicher versuchen über wget mehr 'böse' sachen herunterzuladen und auszuführen. auf diese weise wurde zonealarm unter windows auch mehrmals umgangen (mit dem internet explorer statt wget). |
Es ist überhaupt kein Problem, das Programm zu ermitteln, welches wget aufruft. Damit hast Du das Problem auch schon gelöst - selbst die PF-Lösungen unter Windows können das heute schon so gut wie alle. Auch die Möglichkeit, gezielt die PF ohne Erlaubnis des Users zu töten (also das PF einfach zu schließen zum Beispiel) wird von den meisten mit guter Erfolgsquote abgefangen.
Ich habe auf meiner W2k-Installation Sygate Personal Firewall laufen. Natürlich habe ich es so eingestellt, dass ausnahmslos bei jedem Programm das auf das Internet zugreifen will vorher um Bestätigung gefragt wird. Schon alleine durch diese Maßnahme sind die Möglichkeiten für Maleware auf zwei Fälle beschränkt:
1. Fehler im BS / in der PF, sodass die PF bei einem Netzwerkzugriff komplett umgangen wird.
2. Ich klicke auf "Ja, erlauben" obwohl ich das besser nicht tun sollte.
Gegen Punkt eins kannst Du nichts machen - Bugs im BS kannst Du genau so wenig verhindern wie Bugs in Sicherheitssoftware (dazu zählen auch iptables & Co.).
Und gegen Punkt zwei kannst Du sowieso nichts machen - der User ist immer Sicherheitsrisiko Nr. 1 - auf egal welchem System. Das war schon immer so, ist auch heute noch so und wird auch ewig so bleiben.
Und was den Punkt "böse Sachen ausführen" angeht den Du angesprochen hast (im letzten Zitat-Block):
ANK soll lediglich verhindern, dass unerwünschte Programme den Zugriff auf das Netzwerk erhalten. Das Ausführen von schädlichem Code hat überhaupt nichts mit Netzwerkbezogener Sicherheit zu tun (auch nichts mit Firewalls oder sonstigem) sondern ist Sache des Systems. Also wieder ein ganz anderes Thema. Wie ich schon sagte:
Es ist ebenso wenig ein Problem ein Programm / Script zu schreiben, welches über HTTP schädlichen Code aus dem Netz lädt. Und geht auch wunderbar durch Firewalls hindurch.
| sas wrote: | | Ich glaube auch nicht, dass ihn hier keiner verstanden hat. In den Augen der Poster wäre er lediglich mit nem richtigen Paketfilter besser bedient. Deshalb raten wir ihm alle dazu. |
Und genau deswegen bin ich der Meinung, dass ihn hier kaum einer verstanden hat - auch Du nicht wie es scheint. Es geht hier nicht darum, ob ein Paketfilter besser oder schlechter ist - es ist einfach Fakt, dass Paketfilter und ANK zwei verschiedene Sicherheitsfeatures sind, welche beide unterschiedliche Aufgabenbereiche haben. Ein Paketfilter kann nicht leisten was eine ANK kann und umgekehrt. Und in meinem ersten Posting habe ich auch schon beschrieben, wo genau der Unterschied liegt. Beide Ansätze erhöhen die Sicherheit des Systems und ergänzen sich.
Und da beide verschiedene Aufgabenbereiche haben ist die logische Schlussfolgerung, dass all die jenigen, die ihm einen Paketfilter empfehlen obwohl er nach einer Lösung für Applikationsbasierte Netzwerkkontrolle sucht, die, dass eben jene Personen ihn nicht verstanden haben.
Greetz
Shad
_________________
# 1:
PIII 450, Intel 440BX, 448 MB SD-RAM ATI Rage IIC AGP 8 MB, SB AWE 64 PnP
# 2:
Athlon XP M 2800+ Desktop edition (running on 1.666 and 100 FSB) [was: Duron 800 (Spitfire)], Via KT266, 512 MB SD-RAM, GeForce 3 64 MB, Sound onBoard |
|
| Back to top |
|
|
Jtb
Apprentice
Joined: 19 Dec 2003
Posts: 157
Location: Germany/Darmstadt
|
| Posted: Sun Sep 26, 2004 8:47 am Post subject: |
|
|
Hi Shadows,
mir scheint, als hängst du dich an alten Begriffen auf..
Eine Firewall kann heutzutage sehr wohl nicht nur auf Netzwerk- und Transport-Schicht arbeiten (das wäre ein Paketfilter), sondern auch die höherern Schichten einbeziehen (siehe Stateful Inspection) oder sogar Application-Traffic "verstehen" und verändern (siehe Application Gateway/Proxy)..
Die Option CONFIG_IP_NF_MATCH_OWNER ist übrigens nur eine Möglichkeit einen Paket Filter die Option zu geben auch nach Owner des Sockets zu filtern.. D.h. du kannst Paketfilter und ANK nicht trennen.
Zum Thema Sicherheit von Firewalls unter Windows und Linux: sobald man root ist kann man sie sowieso vergessen.. Wer also z.B. versucht, sich mit einem Paketfilter oder ANK vor einem Rootkit zu schützen, hat gleich verloren
Ich weiß zwar nicht, wie MATCH_OWNER funktioniert, aber wenn z.B. ein Binary suid root ist und MATCH_OWNER das dann nicht filtert, hätte der "böse Angreifer" aus dem Internet leichtest Spiel: der User lädt sich ein Programm aus dem Internet runter das er haben will und prüft nachher nicht was denn da eigentlich installiert wurde.. Bei Gentoo muss man das noch von Hand machen, bei Debian ist es einfach ein Source-Eintrag in apt und schon lädt man möglicherweise malware über die ganz normalen Wege runter ohne das irgendeine Firewall hilft...
Ihr könnt also nicht einfach eine Sicherheitssoftware installieren und gut ist...
Wer übrigens seine Firewall so einstellt, dass sie jedesmal nachfragt, braucht entweder sehr viel Geduld um wirklich jedesmal prüfen zu können, ob der Zugriff berechtigt ist oder wird sehr bald immer häufiger schnell auf Ja klicken - aus diesem Grund sind PF imho nicht für den Endanwender geeignet..
_________________
Jens
.. God is real - unless declared integer! |
|
| Back to top |
|
|
Shadows
Apprentice
Joined: 30 Apr 2004
Posts: 178
|
| Posted: Sun Sep 26, 2004 1:43 pm Post subject: |
|
|
Hi jtb :)
| Jtb wrote: | Hi Shadows,
mir scheint, als hängst du dich an alten Begriffen auf..
[...]
Die Option CONFIG_IP_NF_MATCH_OWNER ist übrigens nur eine Möglichkeit einen Paket Filter die Option zu geben auch nach Owner des Sockets zu filtern.. D.h. du kannst Paketfilter und ANK nicht trennen. |
Nein, ich hänge mich nicht an alten Begriffen auf - ich versuche lediglich klar zu machen, dass es zwei verschiedene Aspekte bei der Realisierung von Netzwerksicherheit sind. Das Software wie zum Beispiel netfilter beide Lösungsansätze vereinigen kann habe ich ja nie bestritten. Macht in dem Falle auch Sinn das unter einer einheitlichen Schnittstelle zu verheiraten.
| jtb wrote: | | Eine Firewall kann heutzutage sehr wohl nicht nur auf Netzwerk- und Transport-Schicht arbeiten (das wäre ein Paketfilter), sondern auch die höherern Schichten einbeziehen (siehe Stateful Inspection) oder sogar Application-Traffic "verstehen" und verändern (siehe Application Gateway/Proxy).. |
Ja, auch richtig. Aber stateful inspection funktioniert bis zu einem gewissen Grad ausschließlich Rechnerbezogen und lässt sich nicht auf eine dedicated Firewall auslagern. Bei einer externen Firewall-Lösung gehen nämlich Informationen wie process, parent process, owner, file permissions etc. verloren. Und im erweiterten Sinne ist stateful inspection exakt das, was PFs bieten, und das auf eine sehr komfortable Weise, ohne gleich die Windows-API Doku wälzen zu müssen. Und genau danach hatte der Urposter auch gefragt. Nach einer komfortablen GUI die dynamisch Regeln basierend auf stateful inspection generiert indem sie im laufenden Betrieb mit dem User inter-agiert (<-- ? klingt komisch irgendwie ;) ). Ob diese GUI jetzt auf netfilter oder auf sonst was aufsetzt ist erstmal völlig egal.
| jtb wrote: |
Zum Thema Sicherheit von Firewalls unter Windows und Linux: sobald man root ist kann man sie sowieso vergessen.. Wer also z.B. versucht, sich mit einem Paketfilter oder ANK vor einem Rootkit zu schützen, hat gleich verloren ;) |
Volle Zustimmung - habe ich davor ja auch gesagt. Vor der Installation und Ausführung eines Rootkits und ähnlichem zu schützen ist Aufgabe des Systems und nicht einer Firewall. Aber eine Anwendung a la PF könnte das Rootkit zumindest davon abhalten nach hause zu telefonieren, Kommandos über das Netzwerk zu erhalten, (D)DoS-Attacken zu fahren etc. Wenn in meinem KDE auf einmal ein Fenster aufpoppen würde worin steht "Anwendung /usr/bin/lp versucht eine Verbindung mit Adresse x.x.x.x aufzubauen - möchten Sie das erlauben?" könnte ich mit dem entsprechenden Wissen darauf schließen, dass irgendwas nicht stimmt und diese Aktion unterbinden. Und das ist der ausschließliche Sinn einer PF (oder einer Firewall mit stateful inspection - völlig egal welchen Namen das Kind trägt). Und wie ich in dem Posting davor auch schon gesagt habe - eine schlecht konfigurierte PF bietet ebenso wie eine schlecht konfigurierte Firewall überhaupt keinen Schutz. Aber das Sicherheitsrisiko User ist dafür verantwortlich, und dieses Sicherheitsrisiko wird man nie zu 100% ausschließen können.
| jtb wrote: | | Ich weiß zwar nicht, wie MATCH_OWNER funktioniert, aber wenn z.B. ein Binary suid root ist und MATCH_OWNER das dann nicht filtert, hätte der "böse Angreifer" aus dem Internet leichtest Spiel: der User lädt sich ein Programm aus dem Internet runter das er haben will und prüft nachher nicht was denn da eigentlich installiert wurde.. Bei Gentoo muss man das noch von Hand machen, bei Debian ist es einfach ein Source-Eintrag in apt und schon lädt man möglicherweise malware über die ganz normalen Wege runter ohne das irgendeine Firewall hilft... |
Das Firewalls nicht dazu dienen das herunterladen, installieren und ausführen von schädlicher Software auf den Rechner zu unterbinden habe ich oben ja bereits erwähnt und brauche das nicht nochmal auszuführen. Aber all diese Maßnahmen erhöhen den Grad an Sicherheit, und darum geht es schließlich, wenn man Sicherheitsfeatures in das System implementiert.
| jtb wrote: | | Ihr könnt also nicht einfach eine Sicherheitssoftware installieren und gut ist... |
Dieser Kommentar ist absolut überflüssig. Niemand hat das behauptet. Genau so gut könnte ich sagen "Da man nie 100%ige Sicherheit mit keiner existierenden Software hat, lassen wir es einfach ganz sein". Ebenso blödsinnig. Und ein vernünftig konfiguriertes Ruleset für iptables ist genau so wenig ein Garant für Sicherheit.
| jtb wrote: | | Wer übrigens seine Firewall so einstellt, dass sie jedesmal nachfragt, braucht entweder sehr viel Geduld um wirklich jedesmal prüfen zu können, ob der Zugriff berechtigt ist oder wird sehr bald immer häufiger schnell auf Ja klicken - aus diesem Grund sind PF imho nicht für den Endanwender geeignet.. |
Das zeigt mir, dass Du noch nie mit einer PF gearbeitet hast. Eine PF fragt nur beim ersten Zugriff eines Programms auf das Netzwerk ob es in Ordnung ist, diese Aktion zu erlauben. Für alle weiteren Zugriffe merkt es sich die vom User getroffene Entscheidung. Bsp.: Ich starte den Internet Explorer unter Windows. Ich will Google öffnen, der IE will auf das Netzwerk zugreifen und die PF meldet mir das und fragt ob es das erlauben soll oder nicht. Ich klicke also auf "ja", denn ich habe den IE schließlich gerade geöffnet. Wenn ich jetzt eine andere Seite mit dem IE öffne fragt die PF natürlich nicht mehr nach sondern übernimmt die vorher getroffene Einstellung automatisch. Und das bleibt solange so, bis ich den IE nicht komplett schließe. Wenn ich allerdings danach wieder den IE aufrufe, kommt wieder die Nachfrage der PF usw. Und auch das Argument "dann startest Du einmal den IE und danach nutzt die Maleware den IE um auf das Netz zuzugreifen" zieht auch nicht, da die PF durchaus erkennen kann ob der User den IE bedient oder ein anderes Programm den IE aufgerufen hat. In dem Falle kommt also wieder ein Popup mit dem Hinweis, dass das Programm xy mit Hilfe des IE auf das Netzwerk zugreifen will. Aber das habe ich bereits in dem Posting davor geschrieben.
Generell werde ich das Gefühl nicht los, dass die wenigsten überhaupt genau wissen wie eine PF funktioniert und welchen Zweck sie erfüllt, geschweige denn, dass sie mal damit gearbeitet hätten. Ich rede auch nicht von Dingen die ich nicht kenne oder über die ich nichts weiß - das führt zu nix. Die meisten hören nur "PF" und schalten sofort aus. Das Standardprogramm, gefütter mit Vorurteilen die was-weiß-ich-woher-auch-immer her kommen wird gestartet und die Sache hat sich erledigt. Nicht alles, was eine komfortable GUI bietet ist deswegen gleich ein Kinderspielzeug. Eben so wenig ist per default alles scheiße was aus der Windows-Welt kommt.
Greetz
Shad
_________________
# 1:
PIII 450, Intel 440BX, 448 MB SD-RAM ATI Rage IIC AGP 8 MB, SB AWE 64 PnP
# 2:
Athlon XP M 2800+ Desktop edition (running on 1.666 and 100 FSB) [was: Duron 800 (Spitfire)], Via KT266, 512 MB SD-RAM, GeForce 3 64 MB, Sound onBoard |
|
| Back to top |
|
|
Jtb
Apprentice
Joined: 19 Dec 2003
Posts: 157
Location: Germany/Darmstadt
|
| Posted: Sun Sep 26, 2004 2:07 pm Post subject: |
|
|
Hi Shadowgeschweige denn, dass sie mal damit gearbeitet hätten. Ich rede auch nicht von Dingen die ich nicht kenne oder über die ich nichts weiß - das führts,
bitte die Sachen nicht persönlich nehmen - ich wollte mit dem "Sicherheitssoftware installiert und alles ist gut" nur als Warnung an die anderen Leser setzen..
Das Problem bei einer (Windows) PF war in den Anfängen dass die Software im selben Context lief - dadurch konnte die PF, wie du geschrieben hast, sehr leicht ausgeschaltet werden 
Wenn man dasselbe auf Linux bezieht, sieht man leicht, dass Malware die KDE-Abfrage relativ leicht schließen kann...
Aus internen Microsoft-Quellen weiß ich weiterhin noch, dass es über 7 Möglichkeiten gibt eine PF ins System einzubinden - wobei nur ein paar dokumentiert sind und dafür geeignet Auch deswegen war die erste Generation von PFs unter Windows als nicht sehr stabil bekannt.
Zum Thema PF und Fragen an den User:
"Hilfe, mein Outlook kann sich nicht mehr mit dem Server verbinden" - habe ich schon oft genug gesehen - woher soll ein normaler User wissen, ob POP3 potentiell gefährlich ist oder nicht? Klar, für Leute die POP3 oder SMTP per Telnet sprechen können ist das offensichtlich, aber der normale User ist zufrieden wenn der Rechner geht :-/
PFs können übrigens erst seit kurzem auch AddIns überprüfen und der Krieg zwischen Hersteller und den Malware-Bastlern hat gerade erst begonnen..
Das Problem ist, dass die PFs auch bei jedem eingehenden Verkehr nachfragen - klink dich doch mal in ein Uni-Netz ein und du wirst deinen Spaß haben
btw: ich habe seit ein paar Monaten die interne Firewall von XP SP2 aktiv und ehrlich gesagt reicht sie mir auch - alles darf raus, nichts darf rein..
_________________
Jens
.. God is real - unless declared integer! |
|
| Back to top |
|
|
return13
Guru
Joined: 02 Feb 2004
Posts: 513
Location: Hamburg - Germany
|
| Posted: Sun Dec 19, 2004 12:27 pm Post subject: |
|
|
ich hab eine relative gute Lösung für das Problem gefunden,
ist zwar nicht Perfekt,
aber ein meiner Meinung nach sehr guter Ansatz
Meine Lösung heisst:
http://fireflier.sourceforge.net/
Leider noch nicht im Portage, aber ändert sich vielleicht bald....
Das ebuild gibts zwar schon aber mitn paar fehlern... Verbessrungswürdig
Und das init script ist auch schon geschrieben
Findet alles unter:https://bugs.gentoo.org/show_bug.cgi?id=70667
Zur Zeit empfehle ich aber noch von Hand zu installieren, es sei denn einer von euch rep. das ebuild |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Deutsches Forum (German)
