Archiv verlassen und diese Seite im Standarddesign anzeigen : Echte Application-Firewall für Linux?
SimonX
2005-07-12, 02:26:58
Und damit meine ich nicht einen Proxy, der alle Daten einzeln an nimmt und weiter gibt.
Ich suche eine Möglichkeit, so ähnlich wie z.B. ZoneAlarm, einzelene Applikationen den Zugriff auf das Internet bzw. Teile davon zu verwehren.
Am Liebsten wäre es mir wenn man das bis zur Library (Shared-Library) runterbrechen kann.
Kennt jemand Links? Meine Google-suche hat mich nur auf Proxy verwiesen.
Kenne ich nichts, aber welches Linuxprogram könnte dir denn schon suspekt sein?
DryIce
2005-07-12, 03:26:28
ZoneAlarm für Linux?
Wie wäre es hiermit?
#!/bin/bash
echo -n Starting firewall.
while true; do
sleep 1
echo -n .
if [ $(($RANDOM%13)) -eq 2 ]; then
break;
fi
done
echo
echo Your system is now secure\!
while true; do
sleep $(($RANDOM%53))
echo "Blocked attack from host $(($RANDOM%256)).$(($RANDOM%256)).$(($RANDOM%256)).$(($RANDOM%255+1)) on port $(($RANDOM%65535+1))!!!"
done
exit 0
Für alle die es nicht verstanden haben: Duz war ein Scherz (oder auch nicht :| ) ;D ;D ;D
Zu den Programmen, die einzelne Anwendungen sperren: das ganze ist mehr oder minder ein Marketinggag ohne wirklichen Nutzen (im Gegenteil, es ist sogar gefährlich!): Diese ganzen Persönlichen Firewalls, die einzelnen Anwendungen erlauben oder verbieten, ins Netz zu gehen, sind nicht wirklich sinnvoll.
Man kann leicht einen Trojaner bauen, der sich als Inernet Explorer oder Firefox oder was auch immer tarnt, und der FW vorgaukelt, er dürfe raustelefonieren. Außerdem ist es immer besser portbasierte Regeln zu nutzen. Wenn ich z.B. im Zonealarm einstelle, dass der IE raustelefonieren darf, dann darf er das über alle Ports, nicht nur über 80. In Verbindung mit einem getarnten Programm ist das ein Paradis für einen Hacker. Und der Anwender fühlt sich sicher.
Sag uns am besten mal was genau du vorhast. Dann können wir vll. gezielter helfen.
Viele Dienste lassen sich auch so abschalten oder man kann die entsprechenden Port mit der Firewall im Kernel sperren (iptables)
Schwerer wirds bei Programen wie mldonkey oder icq etc. weil die sich immer einen offenen Port suchen.
http://www.seifried.org/security/ports/
Lokadamus - nixBock
2005-07-12, 07:13:20
mmm...
Es gibt ein Projekt, was eine FW erweitert hat. Da Anwendungen bestimmte Pakete erzeugen (Ethereal lässt grüssen ;)), können diese ausgefiltert werden. Wie das Projekt heisst, fällt mir gerade nicht ein. Ein Nachteil dabei ist, dass der Netzwerkverkehr ab einer bestimmten Anzahl User etwas langsamer werden kann ...
Edit: Beim Suchen in Google bin ich über Codeseeker, was wohl nicht mehr weiterentwickelt wird (vielleicht in ein anderes Projekt übergegangen? ), gestossen und L7- Filter (http://l7-filter.sourceforge.net/), was der Beschreibung nach das ist, was einer Application Firewall entsprechen würde. ... Proxy- Lösungen? www.fwtk.org (Seite momentan down?) ...
DryIce: Solche Diskussionen gab es schon.
Ich bin aber der Meinung, daß man unter dem Strich mit einer Personal Firewall doch besser fährt als ohne (allein die Heimtelefoniererei kann verboten werden. Ja ich weiss, wenn jemand es darauf anlegt, dann auch nicht).
Voraussetzung sind abgeschaltete Dienste und nach Möglichkeit einen anständigr Router etc. trotz Personal Firewall aber trotzdem.
(del676)
2005-07-12, 09:37:26
DryIce: Solche Diskussionen gab es schon.
Ich bin aber der Meinung, daß man unter dem Strich mit einer Personal Firewall doch besser fährt als ohne (allein die Heimtelefoniererei kann verboten werden. Ja ich weiss, wenn jemand es darauf anlegt, dann auch nicht).
Voraussetzung sind abgeschaltete Dienste und nach Möglichkeit einen anständigr Router etc. trotz Personal Firewall aber trotzdem.
das ist schlicht falsch
mit einer PFW vergrößerst du den angreifbaren Code der von aussen erreichbar ist locker um das 1000 - 10000 fache.
und ich hätte gedacht von solch dummen PFW diskussionen endlich erlöst zu sein wenn man nichtmehr ins windepp forum schaut :(
drdope
2005-07-12, 10:30:27
und ich hätte gedacht von solch dummen PFW diskussionen endlich erlöst zu sein wenn man nichtmehr ins windepp forum schaut :(
Und wie immer stirbt die Hoffnung zuletzt...
Harleckin
2005-07-12, 10:38:21
(..)
Man kann leicht einen Trojaner bauen, der sich als Inernet Explorer oder Firefox oder was auch immer tarnt, und der FW vorgaukelt, er dürfe raustelefonieren. Außerdem ist es immer besser portbasierte Regeln zu nutzen. Wenn ich z.B. im Zonealarm einstelle, dass der IE raustelefonieren darf, dann darf er das über alle Ports, nicht nur über 80. In Verbindung mit einem getarnten Programm ist das ein Paradis für einen Hacker. Und der Anwender fühlt sich sicher.
(..)
Bullshit. Die Verbindung läuft ganz sicher auf der Clientseite nicht über Port 80! In diesem Fall bedient sich das System an den "Dynamically Allocated Ports" Bereich. (49152 -> 65535)
Wie schon genannt, schau dir das http://l7-filter.sourceforge.net/ Projekt genau an und beschäfitige dich mit dem Netfilter/iptables von GNU/Linux.
Evil E-Lex
2005-07-12, 11:21:22
Wie schon genannt, schau dir das http://l7-filter.sourceforge.net/ Projekt genau an und beschäfitige dich mit dem Netfilter/iptables von GNU/Linux.
Wenn ich das richtig sehe, ist l7-filter protokollbasiert. Das ist zwar um einiges sinnvoller als applikationsbasierte Filter, aber nicht genau das was der OP wollte. Eine Firewall-Lösung für Linux die applikatinosbasiert filtern kann ist die FW-1 von Checkpoint, dürfte allerdings der Preisrahmen für den Privateinsatz sprengen. :)
Gruß,
Evil
Harleckin
2005-07-12, 13:04:33
Wenn ich das richtig sehe, ist l7-filter protokollbasiert. Das ist zwar um einiges sinnvoller als applikationsbasierte Filter, aber nicht genau das was der OP wollte. Eine Firewall-Lösung für Linux die applikatinosbasiert filtern kann ist die FW-1 von Checkpoint, dürfte allerdings der Preisrahmen für den Privateinsatz sprengen. :)
Gruß,
Evil
Sry, bitte nochmal für mein Verständnis.
Die FW-1 von Ceckpoint läuft meinetwegen auf einen dedizierten Server und kann leider auch nur Protokollweise Entscheidungen fällen.
Ob nun auf Client X, Outlook oder Evolution läuft, kann diese Appliance auch nicht abwägen!
SimonX
2005-07-12, 13:05:57
Hmm, soweit ich das sehe ist meine Frage nur soweit beantwortet worden, das es keine Application-Firewall für Linux gibt, denn ich meine mit Application-Firewall nicht die Proxy-implementierung.
Ich suche eine Möglichkeit sowas zu konfigurieren:
Group abc
program /usr/bin/*
user root,admin
allow tcp,udp,raw,icmp
end
Group xyz
library /usr/local/lib/libcABC.so.1.0
program *
user *
allow tcp
end
Group x1
program *
group untrusted
deny *
end
Sowas gibts bis jetzt nicht, richtig?
Evil E-Lex
2005-07-12, 14:03:31
Sry, bitte nochmal für mein Verständnis.
Die FW-1 von Ceckpoint läuft meinetwegen auf einen dedizierten Server und kann leider auch nur Protokollweise Entscheidungen fällen.
Ob nun auf Client X, Outlook oder Evolution läuft, kann diese Appliance auch nicht abwägen!
Das kam mir gerade auch in den Sinn (Verdammte hochglanz-Datenblätter) :). Ich werd mir wohl doch mal die Zeit nehmen müssen so ein Ding aufzusetzen, damit ich mir das mal näher anschauen kann.
Gruß,
Evil
stabilo_boss13
2005-07-12, 14:37:17
...
Group x1
program *
group untrusted
deny *
end
Sowas gibts bis jetzt nicht, richtig?Wir regeln die Zugriffe alle über IPTables und Squid (http://www.squid-cache.org/). Das ist nicht ganz einfach, weil sehr viele Möglichkeiten zur Verfügung stehen und man sich erst einarbeiten muss.
Ein Beispiel für das von dir gewünschte Szenario (soweit ich das richtig verstanden habe) findest du hier: http://www.squid-handbuch.de/hb/node49_ct.html
Eine Einführung in IPTables findest du hier: http://www.pl-forum.de/t_netzwerk/iptables.html
SimonX
2005-07-12, 16:38:54
squid scheint schon in die Richtung zu gehen, aber es scheint sich nur auf User oder/und Ports zu beziehen.
Ich möchte aber auch generell einer Applikation das öffnen eines TCP sockets verbieten und das unabhänig vom User.
So würde ich z.B. realplayer das Recht jeglichen Socket zu öffnen verwehren.
Ich will aber auch einer Library libXYZ.so für jeden User erlauben Connections ins Internet auf zu bauen.
Somit müsste squid auch irgendwie mit bekommen welche Applikation (und in dieser Applikation, von welcher Library) diesen Socket geöffnet hat.
Das könnte man squid vielleicht noch beibringen aber das wird ohne eine Kernelextension wohl nicht gehen.
Harleckin
2005-07-12, 16:43:54
squid scheint schon in die Richtung zu gehen, aber es scheint sich nur auf User oder/und Ports zu beziehen.
Ich möchte aber auch generell einer Applikation das öffnen eines TCP sockets verbieten und das unabhänig vom User.
So würde ich z.B. realplayer das Recht jeglichen Socket zu öffnen verwehren.
Ich will aber auch einer Library libXYZ.so für jeden User erlauben Connections ins Internet auf zu bauen.
Somit müsste squid auch irgendwie mit bekommen welche Applikation (und in dieser Applikation, von welcher Library) diesen Socket geöffnet hat.
Das könnte man squid vielleicht noch beibringen aber das wird ohne eine Kernelextension wohl nicht gehen.
Also den Zugriff auf Bibliotheken zu beschränken halte ich für arg kompliziert.
Hmm, mir würde spontan noch SE Linux und grsecurity einfallen.
Lokadamus
2005-07-12, 17:43:15
mmm...
*Schreib langenText, lösch langen Text wieder, reg auf, weil kein Proxy genommen werden soll und dann doch* ... anstatt IPTables würde ich http://www.shorewall.net/ empfehlen. Shorewall erstellt für IPTables die Konfiguration, wobei es leicht zu konfigurieren ist. Hab Squid + Dansguardin in der Firma am laufen Dansguardian kostet Geld, filtert aber nach Inhalt noch Sachen. Eine kostenlose Alternative mit eingeschränktem Funktionsumfang wäre Squid-Guard ...
stabilo_boss13
2005-07-13, 09:11:59
Ich möchte aber auch generell einer Applikation das öffnen eines TCP sockets verbieten und das unabhänig vom User.
So würde ich z.B. realplayer das Recht jeglichen Socket zu öffnen verwehren.Neben dem Blocken von Ports kann man über Squid aber auch u.a. Dateiendungen aussperren. Vielleicht hilft dir, wenn du .rm-Dateien sperrst.
Du erstellst eine Datei mit den unerwünschten Endungen:
\.afx$
\.asf$
...
\.avi$
...
\.mp3$
\.mpeg$
\.mpg$
\.qt$
\.ra$
\.ram$
\.rm$
... usw.
Dazu erstellst du eine Regel:
acl deniedtypes url_regex "/squid/etc/verbotene_dateiendungen"
Und weist Squid an, den Zugriff zu verweigern:
http_access deny deniedtypes
SimonX
2005-07-13, 12:29:14
Eigentlich geht es mir eher um das Blockieren von Spyware/Adware die mit Sicherheit unter Linux auftauchen wird.
Da man diese Software nicht kennt, kann man sie nicht über Address/Protocol Beschränkungen blockieren.
Wie es ausschaut gibt es das, was ich will, noch nicht. Vielleicht kann ich ja selbst was auf die Beine stellen.
Evil E-Lex
2005-07-13, 22:36:41
Eigentlich geht es mir eher um das Blockieren von Spyware/Adware die mit Sicherheit unter Linux auftauchen wird.
Da man diese Software nicht kennt, kann man sie nicht über Address/Protocol Beschränkungen blockieren.
Wie es ausschaut gibt es das, was ich will, noch nicht. Vielleicht kann ich ja selbst was auf die Beine stellen.
Was macht dich so sicher das sowas auch auf Linux kommen wird? Bei den allermeisten Linux-Distributionen arbeitet der normale Anwender nicht als root, da wird schon die Installation derartiger Programme erheblich erschwert. Dazu kommt, dass es keinen IE gibt, der nunmal das Haupteinfallstor für Spy und Adware ist. Linux ist als Plattworm außerdem nicht interessant genug, es hat am Desktop viel zu wenig Marktanteil.
Ganz davon abgesehen, sind Spy-/Adwareblocker konzeptionell fraglich, da Sie nur reagieren und nicht agieren können. Wenn der Anwender nicht mitdenkt wird er so oder so Opfer deratiger Programme.
Gruß,
Evil
Lokadamus - nixBock
2005-07-14, 08:32:48
Eigentlich geht es mir eher um das Blockieren von Spyware/Adware die mit Sicherheit unter Linux auftauchen wird.
Da man diese Software nicht kennt, kann man sie nicht über Address/Protocol Beschränkungen blockieren.
Wie es ausschaut gibt es das, was ich will, noch nicht. Vielleicht kann ich ja selbst was auf die Beine stellen.mmm...
Das wird es auch nie geben. Ich frage mich eher, was du da aufbauen willst. Arbeiten die Leute direkt an der Kiste? ... Malware hält man dadurch auf, das man bestimmte Rechte entzieht (nicht Root usw.) und dadurch die Eintrittsmöglichkeit entzieht.
Malware als Application sperren dürfte ein vergeblicher Versuch sein, du müsstest dazu TCP und ähnliches sperren, da du nie weiss, als was sich Malware nächstes mal einnisten kann. Eine normale Firewall, welche nach beiden Seiten gesperrt ist, ist die Grundlage für ein sicheres Netzwerk. HTTP, FTP und Co. laufen über einen Proxy, SMTP muss in der FW freigeschaltet werden, sollte aber nur Verkehr zwischen extern Anbieter und eigenem Mailserver erlauben ...
Um es kurz zu machen: Eine PFW-Implementierung ist nur Client-seitig zu realisieren. Woher soll auch ein Paketfilter/Proxy 100% wissen, von welcher Anwendung was kommt?
Übrigens bin ich ein Befürworter von PFW, wenn denn den Usern die Grenzen dieser Lösungen aufgzeigt werden. Ich möchte gar nicht erst wissen, wie das Internet ohne diese Teile aussehen würde...
Und auch Paketfilter/Proxies können mit vertretbarem Aufwand getunnelt werden. Dann läuft man aber häufig auch schon Gefahr, seinen Arbeitsplatz zu riskieren.
das ist schlicht falsch
mit einer PFW vergrößerst du den angreifbaren Code der von aussen erreichbar ist locker um das 1000 - 10000 fache.
und ich hätte gedacht von solch dummen PFW diskussionen endlich erlöst zu sein wenn man nichtmehr ins windepp forum schaut :(
Gerade Direct X 9 auf Windows 2000 installiert. Selbst das will nach Hause telefonieren. Fast alles von M$ will nach Hause telefonierne. Andere Software auch.
Ich weiß das es möglich ist, daß ein Programm trotz PFW nach Hause telefoniert. So raffiniert sind aber die wenigsten.
Also wie willst du das Telefonieren verhindern? Die übliche Antwort? Solche Software nicht installieren? Na dann viel Spass ohne Direct-X 9 unter Win2000 (Beispiel).
Meine Meinung:
Dienste abschalten + PFW (+ Router -NAT- falls vorhanden)
BananaJoe
2005-08-31, 12:13:58
http://www.fs-security.com/
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.