Archiv verlassen und diese Seite im Standarddesign anzeigen : proxy darf nicht umgangen werden !
folgendes problem:
in der firma laeuft ein w2k server, die clients laufen mit w2k pro und als proxy lauft ein suse linux 7.3 mit iptables.
jetzt habe ich in der squid.conf eintraege gemacht die verhindern sollen das bestimmte seiten aufgerufen werden duerfen (danke akittstein, tomes u.a.):D
da ich dann auf dem client einstellen muss das er den proxyserver verwenden muss funktioniert das auch, aber jeder user kann das entsprechende haeckchen wieder entfernen und somit haben die eintraege in der squid.conf keine wirkung mehr. normaler weisse sollte man jetzt eine gruppenrichtlinie erstellen die das untersagt und die auch nur diese einstellung zulaesst, das der client den proxy als proxy verwenden muss.
nur fehlen mir hierzu die mittel da sie entweder im urlaub oder krank sind.:D
gruss,
uwer
GIBT ES AUCH DIE MOEGLICHKEIT SOWAS IN DER FIREWALL MIT IPTABLES ZU REGELN :confused:
NAT abschalten, für das Netz, indem sich die User tummeln.
Dann können die nur noch über den Proxy surfen. Falls die aber andere Services als http,https,ftp brauchen, geht das natürlich nicht.
Ansonsten kannst Du natürlich traffic, der als destination Port 80, 21, 443 hat am internen Interface der Firewall blocken bzw. expliziert nur Port 8080 erlauben.
prinzipiell nur dem proxy webzugriff gewähren ...
Falls Du noch einen Suchbegriff möchtest:
Das nennt sich "transparenter Proxy"...
schau mal
http://www.linuxforen.de/forums/showthread.php?s=&threadid=35137
Hi,
verbiete in der FORWARD Chain Zugriffe auf Destination-Port 80. Oder leite die Request auf den Proxy weiter.
Ciao, Bernie
Hallo uwer,
bom hat die einzig wahre Möglichkeit aufgezeigt: Du mußt NAT bzw. Masquerading an Deinem Gateway abschalten.
Alle anderen Möglichkeiten (Port 80/tcp blockieren etc.) führen nur dazu, dass eine Teilmenge der im Internet erreichbaren Webserver nicht mehr direkt angesteuert werden können. Wer weiß jedoch schon, auf welchen Ports außer dem 80er Webserver in der ganzen Welt noch laufen? Im Zweifel gibt es zigtausende, die beispielsweise auf dem Port 8080 laufen könnten und Deine Anwender kommen auf diese ungehindert dran, denn Du kannst ja nicht alle Ports sperren (oder doch? dann also direkt weg mit dem Masquerading).
Auch ein transparenter Proxy bringt Dich nicht weiter. Dieses Vorgehen hat gleich zwei Nachteile:
1. Du fängst auf Deinem Gateway TCP-Connects auf dem Port 80 ab und leitest sie auf den Proxy um. Das funktioniert genau so lange, wie das obige Szenario ausgeschlossen wäre ... ist es jedoch nicht.
2. Ein Squid im transparenten Modus ist nicht in der Lage, SSL/TLS-Verbindungen zu handeln. SSL/TLS kannst Du damit vergessen und somit hast Du sichere Transaktionen auf SSL/TLS-fähige Webserver unmöglich gemacht. Auch das ist nicht wirklich eine Lösung.
Es bleibt Dir der Weg, das Masquerading abzuschalten, damit ausschließlich die User das Internet benutzen können, die über den Proxy gehen ... dann jedoch mit allen Vorteilen des Proxys für die User (z.B. Caching) und allen Vorteilen für den Admin (ACLs).
Harry
Falls Du auf dem Gateway neben HTTP(S)/FTP noch andere Dienste routest/maskierst (SMTP, DNS, NTP, etc.), dann solltest Du Dir evtl. Gedanken über die Installation von Application Level Gateways machen, die die anderen Dienste auf Applikationsebene zwischen Deinem LAN und dem externen Netz vermitteln, damit Du auch für diese Dienste kein IP-Routing bzw. Masquerading benötigst und zudem den sicherheitsrelevanten Vorteil der Application Level Gateways genießen kannst.
Ein flaches IP-Routing wäre so ziemlich das unsicherste, was zwischen LAN und unsicherem Netz stehen kann. Dicht davon gefolgt sind Lösungen, die einen reinen Paketfilter implementieren bzw. auf Masquerading aufsetzen.
Zwar kann ein potentieller Angreifer nicht mehr direkt mit IP-Paketen von aussen in das LAN gelangen (oder vielleicht doch) jedoch sind die Server, die direkt mit dem externen Netz sprechen durchaus kompromittierbar, da sie ja direkt in das unsichere Netz vermitteln müssen und von dort auch direkte Antworten erwarten.
Eine hinreichend sichere Lösung wäre somit über Application Level Gateways (idealerweise in Verbindung mit Paketfiltern) realisierbar, wobei auf Routing und Masquerading zwischen den beiden Netzen komplett verzichtet wird (soweit es sich halt umsetzen läßt und zumeist geht das).
Nur mal so als Anregung ... :D
Harry
Original geschrieben von Harry
Eine hinreichend sichere Lösung wäre somit über Application Level Gateways (idealerweise in Verbindung mit Paketfiltern) realisierbar, wobei auf Routing und Masquerading zwischen den beiden Netzen komplett verzichtet wird (soweit es sich halt umsetzen läßt und zumeist geht das).
Harry
Aber dann kostet es ihn eine Menge Geld....
IMHO wäre dann Linux mit Boardmitteln das falsche Produkt.
Ich würde dann zu einer SOHO Appliance, wie z.B. der Symantec Appliance greifen oder kennst Du freie Application Layer Gateways?
freie Applikations-Gateways:
Squid (HTTP/FTP)
Proxy-Suite (FTP + ?)
Dante (SOCKS-Proxy)
also ich danke euch erstmal fuer die super antworten :D
aber ich muss gestehen das, dass was ihr zum teil von euch gebt fuer mich boemische doerfer sind :(
das heisst ich muss jetzt ersmal ein bueschen was aufarbeiten und schauen wie ich dass dann mit dem proxy vereinbaren kann. ich bin im moment erstmal etwas ueberfordert :o ich werde mich aber wieder auf dieses thema melden sobald ich fragen habe.:D
kann sein das, dass fuer euch schon alles zum alltaeglichen brot gehoert aber fuer einen newbie wie mich, na ja.
THX THX THX THX THX :D
Original geschrieben von Jinto
freie Applikations-Gateways:
Squid (HTTP/FTP)
Proxy-Suite (FTP + ?)
Dante (SOCKS-Proxy)
Fortsetzung:
- bind9
- Postfix
- rinetd
- ...
Eine solche Lösung muß auch nicht mehr Geld kosten oder zwingend kommerziell sein. Die Frage der Lösung orientiert sich vielmehr am Know-How des Administrationspersonals aber wie schon gesagt:
Nur mal so als Anregung :D
Harry
das freie Application Gateway fuer UNIX/Linux --> delegate
http://www.delegate.org/delegate/
T;o)Mes
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.