Moin,
folgendes Szenario:
Fakten:
- Unternehmensnetzwerk mit Windows-Clients (i.w. XPpro, aber auch noch teilweise NT4)
- zentraler Internetzugang über Proxy, Firewall mit SmartFilter und Content Filtering
Problem:
JAP (http://anon.inf.tu-dresden.de/) kann trotz eingeschränkter User-Rechte (kein local admin!) installiert und betrieben werden, da es lediglich eine Java Application ist.
Dadurch ist es problemlos möglich, SmartFilter und ContentFilter zu umgehen. Dies kann nicht durch PortScans oder andere netzwerktechnische Maßnahmen erkannt oder verhindert werden. (?)
Frage:
Gibt es irgendwelche Möglichkeiten, den Einsatz von JAP zu verhindern?
Bleibt das, wie ich vermute, an dem Grundsatzproblem hängen, daß https-Verbindungen über den Unternehmensproxy erlaubt sind?
JAP ist ja nur eine harmlose Form, dies auszunutzen - andere Tunnelmechanismen sind denkbar.
Allerdings ist JAP insofern kritisch, als daß das jeder User via Setup Assistent problemlos installieren und betreiben kann, sogar die Proxy-Einstellungen des Browsers werden mit User-Rechten automatisch verändert(!).
Jede Art von hilfreicher Anmerkung sind erwünscht! 
Gruß,
Malte.
Hallo Malte,
du kannst natürlich über die Systemrichtlinien die Ausführung nicht genehmer Programme verhindern. In der Praxis ist dieses Verfahren aus verschiedenen Gründen aber kaum sinnvoll.
Ich habe mit dieser Fragestellung auch schon beschäftigt, die einzige Möglichkeit, die ich gefunden habe, ist nicht technischen, sondern organisatorischen Charakters. Https-Verbindungen werden zunächst abgelehnt, soweit der aufgerufene Server nicht in einer Positivliste freigeschaltet ist. Die Freischaltung erfolgt formlos durch den Anwender über ein Script, gleichzeitig erfolgt ein Protokolleintrag. Dieses Protokoll kann vom Admin jederzeit überprüft und „zweifelhafte“ Adressen dauerhaft gesperrt werden.
In der Praxis dürfte das bedeuten, dass du https- und http-Anfragen über verschiedene Proxies routest. Selbst umgesetzt habe ich dieses Konzept nicht, da ich insg. nur ca. 150 f. Internet freigeschaltete User habe, und Missbrauch mittels Tunneling schon bei händischer Protokollanalyse früher oder später auffällt.
Gruss,
Schorsch
Hi Schorsch,
du kannst natürlich über die Systemrichtlinien die Ausführung
nicht genehmer Programme verhindern. In der Praxis ist dieses
Verfahren aus verschiedenen Gründen aber kaum sinnvoll.
Eben, zumal JAP eine Java Application ist, und Java generell wollen wir nicht verbieten.
Ich habe mit dieser Fragestellung auch schon beschäftigt, die
einzige Möglichkeit, die ich gefunden habe, ist nicht
technischen, sondern organisatorischen Charakters.
Https-Verbindungen werden zunächst abgelehnt, soweit der
aufgerufene Server nicht in einer Positivliste freigeschaltet
ist. Die Freischaltung erfolgt formlos durch den Anwender über
ein Script, gleichzeitig erfolgt ein Protokolleintrag. Dieses
Protokoll kann vom Admin jederzeit überprüft und
„zweifelhafte“ Adressen dauerhaft gesperrt werden.
In der Praxis dürfte das bedeuten, dass du https- und
http-Anfragen über verschiedene Proxies routest. Selbst
umgesetzt habe ich dieses Konzept nicht, da ich insg. nur ca.
150 f. Internet freigeschaltete User habe, und Missbrauch
mittels Tunneling schon bei händischer Protokollanalyse früher
oder später auffällt.
Dieses Konzept ist hier nicht umsetzbar, da die Anzahl der User _erheblich_ zu groß ist 
Danke dennoch für Deinen Kommentar dazu, ich dachte mir sowas schon.
Gruß,
Malte.
Hallo Malte,
Dieses Konzept ist hier nicht umsetzbar, da die Anzahl der
User _erheblich_ zu groß ist
hast du die Protokolle denn mal dahingehend ausgewertet, wieviele verschiedene https-Basisseiten täglich aufgerufen werden, und wie gross dabei der volatile Anteil ist? Ich behaupte mal so aus dem blauen heraus, dass auch bei einigen 10.000 Anwendern eine durchaus überschaubare Anzahl übrigbleibt - im wesentlichen b2b-Anwendungen und die diversen Online-Banken, bei denen die Mitarbeiter ihre Privatkonten pflegen.
Auch wenn in einem kleinen Unternehmen wie bei mir die soziale Kontrolle erheblich stärker greift - allgemein dürfte das Surfverhalten sich kaum signifikant unterscheiden.
Gruss,
Schorsch
Hallo,
Gibt es irgendwelche Möglichkeiten, den Einsatz von JAP zu
verhindern?
Bleibt das, wie ich vermute, an dem Grundsatzproblem hängen,
daß https-Verbindungen über den Unternehmensproxy erlaubt
sind?
JAP ist ja nur eine harmlose Form, dies auszunutzen - andere
Tunnelmechanismen sind denkbar.
JAP zu sperren ist ja wohl nicht das Problem. Es gibt gerade mal ein paar Mixes dafür. Verbindungen zu diesen IPs kannst Du einfach verhindernn
Ansonsten halt dual-homed Proxy/Firewall verwenden?! Dadurch ist es doch möglich das Tunneln von Protokollen zu verhindern.
ciao
ralf
Hallo,
JAP zu sperren ist ja wohl nicht das Problem. Es gibt gerade
mal ein paar Mixes dafür. Verbindungen zu diesen IPs kannst Du
einfach verhindernn
JAP ist OpenSource - jeder kann sich das auf beliebigen Hosts im Netz installieren. Und hier gibt es genug Irre, die sowas auch tun würden.
Diese Negativliste wäre also sicherlich eine gute Maßnahme - aber noch davon entfernt, ein wirklicher Schutz zu sein.
Ansonsten halt dual-homed Proxy/Firewall verwenden?! Dadurch
ist es doch möglich das Tunneln von Protokollen zu verhindern.
Magst Du mir das genauer erklären?
Gruß,
Malte.
Hi Schorsch,
Dieses Konzept ist hier nicht umsetzbar, da die Anzahl der
User _erheblich_ zu groß ist
hast du die Protokolle denn mal dahingehend ausgewertet,
wieviele verschiedene https-Basisseiten täglich aufgerufen
werden, und wie gross dabei der volatile Anteil ist?
Nein - ich bin weder Firewall- noch Proxy-Admin. ICh kümmere mich mehr um Design und Konzepte.
Ich
behaupte mal so aus dem blauen heraus, dass auch bei einigen
10.000 Anwendern eine durchaus überschaubare Anzahl
übrigbleibt - im wesentlichen b2b-Anwendungen und die diversen
Online-Banken, bei denen die Mitarbeiter ihre Privatkonten
pflegen.
Nun, ich hab mit einem unserer Firewall Admins gesprochen, der meinte, er würde beizeiten mal ein Skript über die Logs laufen lassen, vermutet allerdings, daß die Anzahl der Hosts zu hoch sein wird, als daß wir das mit unseren Personalressourcen mit ner Positivliste abfackeln könnten.
Na mal sehen, ich spreche da demnext mal mit den Windows-Leuten drüber, ob und wie man das von deren Seite aus angehen könnte. Das erscheint mir praktikabler. Danke für die Anregungen dennoch!
Gruß,
Malte.
Auch wenn in einem kleinen Unternehmen wie bei mir die soziale
Kontrolle erheblich stärker greift - allgemein dürfte das
Surfverhalten sich kaum signifikant unterscheiden.
Gruss,
Schorsch
Hallo,
Ansonsten halt dual-homed Proxy/Firewall verwenden?! Dadurch
ist es doch möglich das Tunneln von Protokollen zu verhindern.
Magst Du mir das genauer erklären?
Ein Proxy wahrscheinlich in diesem Fall, über den HTTPS läuft. Dabei baut der Client eine verschlüsselte Verbindung mit dem Proxy auf, dort wird entschlüsselt usw… Dann ist es natürlich auch möglich entsprechende Filter anzuwenden.
Auf die Schnelle gefunden:
http://www.balabit.com/products/zorp_gpl/
Einen Thread habe ich auf die Schnelle auch noch dazu gefunden:
http://honor.trusecure.com/pipermail/firewall-wizard…
Vielleicht bekommst Du ja dadurch ein paar Ideen?
ciao
ralf
Hallo Ralf,
Ansonsten halt dual-homed Proxy/Firewall verwenden?! Dadurch
ist es doch möglich das Tunneln von Protokollen zu verhindern.
Magst Du mir das genauer erklären?
Ein Proxy wahrscheinlich in diesem Fall, über den HTTPS läuft.
Dabei baut der Client eine verschlüsselte Verbindung mit dem
Proxy auf, dort wird entschlüsselt usw… Dann ist es
natürlich auch möglich entsprechende Filter anzuwenden.
Danke für Deine Mühe. Ich hab schonmal an sowas gedacht, aber Zorp kannte ich noch nicht. So etwas wollen wir aus naheliegenden Gründen nicht produktiv einsetzen - die Last, die so etwas erzeugt, ist bei unserer User-Zahl zu hoch und die zu erwartenden Schwierigkeiten ist uns der Nutzen nicht wert - wobei das technisch hochinteressant ist
Letztlich ist es wohl das alte Problem der Gegenläufigkeit von Security und Komfort und zumindest nich von Netzwerkseite aus lösbar, sondern muß von Seiten der Systeme selbst bzw. organisatorisch angegangen werden.
So etwas hatte ich vermutet, aber Brainstorming ist immer gut und hier wurden mir durch eure Anregungen einige Dinge noch klarer bzw. bestätigt.
Grüße,
Malte.