s.k.

Ein Grund wäre z.B. wenn eine NIC im Server steckt, die zum Router oder einem anderen Netz geht, dessen IP-Adresse aber nicht im DNS registriert werden soll.Oder es handelt sich noch um eine NT4-Domäne. Dann ist das ebenfalls lästig (hier aber wohl nicht einschlägig). Gruß Steffen

@David: Achtung: Nur abschalten, wenn der Host nicht Mitglied einer AD-Domäne ist. Gruß Steffen

Hallo gruemelmonster, Wenn die Admins der Gegenseite auch nur halbwegs wissen, was sie tun, dann schränken sie Euren Zugriff ohnehin bereits auf das unbedingt Notwendige ein. Es gilt der Grundsatz: Für seine eigene Sicherheit ist vorrangig jeder selbst verantwortlich! Deine Bedenken und Dein Ansinnen kann ich aber gleichwohl nachvollziehen. Am ISDN-Router kannst Du aber gar nicht viel machen: Nach Ziel-IPs kannst Du nicht filtern, da Dir die Ziele nicht abschließend bekannt sind (so jedenfalls Deine bisherigen Darstellungen). Du könntest den Kreis der berechtigten Arbeitsstationen anhand der Absender-IP einschränken. Dies setzt aber voraus, dass diese Arbeitsstationen immer die selbe IP-Adresse haben (feste IPs bzw. static DHCP). Besonders manipulationssicher ist das aber sowieso nicht. Sollte bei Deinem Router nicht nur ein Filtern auf Layer 3, sondern auch auf Layer 4 möglich sein, dann könnte man ausgehenden Verkehr noch auf TCP Port 80 und ggf. 443 einschränken (wenn ich Dich richtig verstanden habe, handelt es sich ausschließlich um Webserverzugriffe). Ihr hab doch einen SBS --> Setzt ihr den ISA-Server ein? Dann erlaube doch den Zugriff auf dieses Remotenetz nur über den ISA-Server! Dort kannst Du entsprechende Zielsätze definieren ("*.extern" / 160.0.0.0/8) und den Zugriff darauf nur einer bestimmten Benutzergruppe erlauben. Solange es sich nur um Webzugriffe handelt, genügt hierzu der ISA-Webproxy mit "Webproxyclients" (Browserzugriff). Wenn doch auch andere Protokolle zum Einsatz kommen, kannst Du den Firewallclient nutzen, um auch diesen Datenverkehr benutzerabhängig zu reglementieren. Jedoch musst Du den Verkehr dann über den ISA routen. Vermutlich bedingt dies auch eine kleine Umstellung Deines Netzes. Gruß Steffen

Ganz Recht. Und gerade deshalb sollte dieses Schreiben nicht nur eine Wiedergabe der ausgeführten Arbeiten, sondern ausdrücklich auch eine Bewertung der erbrachten Leistung enthalten. Sonst ist es schließlich keine Empfehlung. Diese Bewertung kann natürlich nur der Zeugniserstellende selbst vornehmen. Dabei ist aber Vorsicht geboten! Zumindest das deutsche Arbeitsrecht hat dazu geführt, dass eine eigene Zeugnissprache entstanden ist. Wenn derjenige, der eine Empfehlung oder ein Zeugnis schreibt, nicht genau weiss, wie Personaler dies lesen und ggf. interpretieren, dann kann ein gut gemeintes Schreiben schnell nach hinten losgehen... Gruß Steffen

Ich hatte Deine Frage so verstanden, dass Du wissen wolltest, ob der ISA ähnlich wie Zonealarm & Co für einzelne Anwendungen dynamisch Zugriffsregeln erstellen kann. Dies ist meines Wissens nicht möglich. Jedenfalls nicht bei Verwendung eines SecureNAT-Clients. Dort "sieht" der ISA schließlich nur den vom Client bzw. der darauf laufenden Applikation generierten Netzwerktraffic. Mit dem Firewallclient ist es hingegen nicht nur möglich, eine Benutzer-Authentifizierung für Nicht-Webprotokolle zu implementieren, sondern auch Informationen über den initiierenden Prozess an den ISA zu übermitteln und dort loggen. Das Regelwerk kann man hingegen trotzdem nicht applikationsabhängig gestalten. Zumindest verstehe ich >>diesen Artikel<< so. Ohnehin scheinst Du aber etwas anderes im Sinn zu haben: Na da hast Du "den Richtigen" gefragt. :shock: Ich nutze weder privat noch beruflich irgend welche Messenger - geschweige denn Videokonferencing. :o Wenn einer auf Arbeit mit diesem Wunsch kommt, dann jage ich ihn weg! :D Achtung jetzt wird's "dünn" :): Das Problem bei VOIP und Videoübertragungen ist meines Wissens die Komplexität und Dynamik der verwendeten Protokolle. Das Streaming erfolgt wohl über nachgelagerte Verbindungen, welche häufig von aussen initiiert werden und/oder wechselnde Ports bzw. Portbereiche verwenden. Dem ist mit einer auf der Transportschicht arbeitenden Firewall nicht beizukommen (jedenfalls nicht ohne diese bis zur Bedeutungslosigkeit zu durchlöchern). Man benötigt also spezielle Anwendungsfilter bzw. Application Level Gateways, welche - auf Layer 7 arbeitend - das verwendete Protokoll "verstehen", um entsprechend dynamisch auf deren Erfordernisse reagieren zu können. Im ISA2000 gab es bspw. einen sog. H.323 Gatekeeper. Hierüber lief dann z.B. Netmeeting. Der H.323 Gatekeeper ist im ISA2004 aber nicht mehr enthalten. Vermutlich weil der Trend zu SIP geht. Ein SIP-Filter bzw. SIP-Proxy ist aber ebenfalls nicht enthalten. :mad: Viel Hoffnung kann ich Dir also nicht machen, dass Du das ans Laufen bekommst. Aber vielleicht hat ja jemand anderes davon mehr Ahnung als ich und liest hier mit... :wink2: Gruß Steffen

Hallo PAT, Nur anhand der spezifischen Kommunikation. Die Anwendung selbst kann nicht überwacht werden. Das ginge ohnehin nur, wenn die Anwendung auf dem ISA selbst laufen würde. Den ISA setzt man aber imho am Besten als dedizierte Firewall ein.Im Übrigen wissen wir doch alle, dass auch die Anwendungsüberwachung nur eine Scheinsicherheit vorgaukelt, welche sich leicht aushebeln lässt. Gruß Steffen

Windows Update Möglichkeiten.pdf Gruß Steffen

Sollte man meinen. Ich hatte das aber mal mit einem XPpro-Volumendatenträger getestet. Es funktionierte nicht! Gruß Steffen

In 2 Wochen werde ich es voraussichtlich testen (müssen). Wenns nicht klappt, bekommst Du die Rechnung für das XP Update... ;) :p Gruß Steffen

@PAT: Ich hab zwar auch keine guten Augen, aber aber einen guten Viewer! :p Da steht wirklich auch XP home drauf! :jau: @arnd: Hab gerade bei Cancom geschaut. Da gibt es das als Box-Produkt. Allerdings ist dieses doppelt so teuer, wie die SB-Version! :shock: Fragt sich nur, ob dies mir nur die Berechtigung einräumt, von home auf pro zu gehen (durch Neuinstall) oder ob man damit auch tatsächlich ein Update einer vorhandenen Installation unter Beibehaltung der Funktionsfähigkeit der bereits installierten Programme ausführen kann. Mich würde ganz und gar nicht wundern, wenn nur ersteres der Fall wäre... Gruß Steffen

Hallo, Wenn ich mich Recht erinnere, mutmaßte die c't lediglich, dass MS künftig verhindern könnte, dass Updates und Servicepacks auf ein solches System eingespielt werden könnten. Meiner Erinnerung nach haben sie geschrieben, dass Servicepacks funktionerten. Kann aber durchaus sein, dass ich mich irre. Habe die c't leider nicht zur Hand... Gleichwohl muss ich Dir Recht geben: Dieser Weg ist eigentlich keine wirklich gangbare Option! :( Das Problem bleibt: Wie migriere ich ein XP Home auf XP pro ohne eine Neuinstallation? Ich stehe nämlich demnächst vor dem gleichen Problem... Funktioniert ein Update mit einer Updateversion von XP, wie Schotte es anmerkte? Gruß Steffen

Hallo Mike, Die VW ist in diesem Fall Upstreamproxy. Geht ganz simpel über eine Webverkettung: http://www.msisafaq.de/Anleitungen/2004/Konfiguration/Webverkettung.htmAngenehmer Nebeneffekt einer solchen Verfahrensweise: Du kannst einen (wegen der Clientauthentifizierung gegenüber AD) intern stehenden und in die Domäne eingebundenen ISA-Proxy sowie die daran angeschlossenen Clients im Hinblick auf externe DNS-Auflösungen "dumm" halten. Eine externe DNS-Auflösung muss nur der Upstreamproxy können. Dieser steht idealerweise in einer DMZ. Man muss hier ein paar Fragen trennen:1. Authentifizierungsverfahren: Die per default verwendete windowsintergrierte Auth. macht meines Erachtens wenig Sinn, wenn der Zugriff aus dem Internet erfolgt. Da diese Hosts ohnehin nicht die Logininfos der Domäne verwenden werden, klappt der Single sign on nicht - es kommt eine Eingabemaske hoch. Da die Standardauth. die Passwörter aber unverschlüsselt überträgt, ist die formularbasierte Auth. i.V.m. SSL-Verschlüsselung die beste Wahl. Damit die User dort nicht immer Domänenname\Username eintragen müssen, sorge ich dafür, dass der User Pricipal Name mit der email-Adresse übereinstimmt. Dann können sich die User sowohl beim OWA als auch bei der Windows-Anmeldung im LAN mit ihrer email-Adresse als Benutzernamen anmelden. Das verstehen auch die dümmsten User... 2. Zugriffsregelung per Firewall: Der einfachste Weg wäre es natürlich, Zugriffe von außen über TCP-Port 443 einfach zum intern stehenden IIS/Ex weiterzuleiten. Dies ist aber nicht empfehlenswert. 1. Nachteil: Du kannst nicht in den Datenverkehr reinschauen und auf Applikationsebene filtern. 2. Nachteil: Du lässt direkten Datenverkehr zwischen WAN und LAN zu. Das widerspricht zu Recht den Grundsätzen für einen sicheren Betrieb. Ein Zugriff von extern aufs LAN sollte nie direkt möglich sein, sondern nur über einen "Mittler", den Du gesondert kontrollieren kannst. Ich favorisiere folgende Konfig: ~Internet~ | o [Drittanbieter-Firewall]o--(DMZ)--[iSA2004] o | (LAN) | [Exchange] Die Firewall lässt SSL nur zwischen Internet und DMZ sowie zwischen DMZ und LAN zu. Der direkte Zugriff WAN-->LAN ist verboten. Am ISA wird der SSL-Tunnel aus dem Internet terminiert, der darin übertragene Verkehr so gut es geht auf Layer 7 inspiziert (siehe der Link von GuentherH) und über einen gesonderten SSL-Tunnel zum Exchange übertragen. Hinweis: der ISA ist natürlich nicht Mitglied der Domäne, sondern dient bestenfalls einem intern stehenden (und die Clients erforderlichenfalls gegenüber AD authentifizierenden) Proxy als Upstreamproxy (siehe oben). Gruß Steffen

http://www.msisafaq.de/Anleitungen/2004/Firewallrichtlinien/OWA_FBA.htm oder http://www.isaserver.org/tutorials/Enabling-ISA-Firewall-Forms-based-Authentication-OWA-Connections-Internal-External-Clients-Part1.html http://www.isaserver.org/tutorials/Enabling-ISA-Firewall-Forms-based-Authentication-FBA-OWA-Connections-Internal-External-Clients-Part2.html Gruß Steffen

@eras: Noch eine Anleitung (diesmal Interneteinwahl über IPSecPassThrough-fähigen Router und Verwendung von Zertifikaten): http://europe-01.securepoint.de/IPSec_Konfiguration_mit_Windows_XP.pdf @Mods: Kann es sein, dass man seine Beiträge nur innerhalb eines gewissen Zeitfensters bearbeiten kann? Ich wollte mir eigentlich nicht selbst antworten... Gruß Steffen

Hallo eras, hier eine Anleitung: http://www.zyxel.ch/files/knowledgebase/w2kzywallvpn.pdf Die bezieht sich zwar auf ein IPSec-VPN mit einer Zywall, sollte aber mit der Gateprotect genauso funktionieren. Ich hab das selbst allerdings noch nie getestet - kann also auch keinen Support dazu leisten. Wenn Du es Dir einfach machen willst, rufst Du bei Gateprotect an und erkundigst Dich, welchen IPSec-Client sie empfehlen. Leider ist da ohne Extrakosten nicht mehr viel zu reißen. Im Windowsumfeld ist mir als Freeware nur noch die Securepoint-PF bekannt. Hatte die vor Ewigkeiten mal angetestet. Hat mir aber nicht gefallen... Gruß Steffen

Hallo CoolAce, Kannst Du bitte erläutern, inwiefern SMB Signing beim Imagen problematisch sein könnte. Ich bin bislang immer davon ausgegangen, dass dies nur die SMB-Kommunikation betrifft... Oder meinst Du das für den Fall, dass das Image direkt auf einen Share erstellt wird? Gruß Steffen

Dann gehört er hinter den ISA ins LAN. Also entweder die IP-Adresse dieses Servers (und ggf. die Bindungen der darauf laufenden Dienste) ändern oder die Netze zwischen intern und extern tauschen und den ISA nochmal anpassen. Sollte der Webserver nicht nur für den WSUS da sein, sondern auch öffentlich erreichbare Seiten servieren, dann würde man diese Seiten im Idealfall auf einen anderen Webserver tun und diesen in die DMZ stellen. Ich nehme mal an, dass es sich bei Deinem Netz um ein privates zu Übungszwecken handelt, oder? Dann mach den intern stehenden Webserver erforderlichenfalls über eine sog. Webserververöffentlichungsregel von extern erreichbar. Dafür müsste es einen Assistenten geben. Genaueres dazu kann ich Dir aus dem Kopf nicht sagen. Ich hatte ja schon erwähnt, dass der ISA2004 eigentlich nicht "meine Baustelle" ist. Bis auf einen 2004er (der aber für seine spezielle Aufgabe bereits fix und fertig konfiguriert ist und nicht mehr angefasst wird) betreue ich nur einige 2000er, welche aus Kompatibilitätsgründen mit einem 3rd-Party-Tool auch auf absehbare Zeit leider nicht umgestellt werden können. Gruß Steffen

1. Wenn Du ein Problem hast, dann überlege bitte zunächst selbst, woran es liegen könnte und mach Dich bei den einschlägigen Quellen und google schlau.2. Wenn Du etwas allein nicht hinbekommst, dann beschreibe bitte genau, was konkret nicht funktioniert und was Du versucht hast, um Dein Ziel zu erreichen. 3. Wenn Du ein Problem gelöst hast, dann verrate uns bitte, wie Du es gelöst hast. Das gehört zur Netikette. Ein Forum ist schließlich keine Einbahnstraße, welches nur dazu da ist, lediglich Deine konkreten Probleme zu lösen. Andere benutzen die Suchfunktion und erhoffen sich vielleicht aus diesem Thread Hilfe. Nicht zuletzt wollen auch diejenigen, die hier helfen, nicht in erster Linie ihr Wissen zur Schau stellen, sondern durch die GEMEINSAME Problemlösung ggf. auch etwas dazulernen. Verstehe mich bitte nicht falsch und nimm mir meinen Hinweis nicht krumm, aber das musste ich mal loswerden, denn _so_ macht das keinen Spass! :( Was "serviert" denn dieser Server? Wenn es z.B. ein Webserver ist, der aus dem Internet erreicht werden soll, dann steht er genau richtig: nämlich in der DMZ.Wenn es hingegen ein rein interner Server ist, dann musst Du umstellen. Gruß Steffen

Am ISA: - auf der "externen" NIC die IP-Adresse des Routers eintragen - auf der internen NIC kein Gateway eintragen Am Client hinter dem ISA: - als Gateway die IP-Adresse der internen NIC des ISA eintragen

Bei den Clients? Sinnvoller Weise die interne IP-Adresse des ISA-Servers. Im Übrigen: Siehe http://www.isafaq.de Gruß Steffen

Wenn sie Euch auf ihre internen DNS-Server lassen, dann ist es natürlich eleganter, dies mit DNS-Forwarding zu lösen. Die hosts-Datei-Lösung stößt ohnehin an ihre Grenzen, wenn Dir die Hosts nicht abschließend bekannt sind oder häufig weitere hinzu kommen. Den Zugriff Eurer Clients in Richtung des Remotenetzes oder den Zugriff aus dem Remotenetz in Eurer Netz? Dass aus dem Remotenetz nicht bei Euch zugegriffen werden kann, ist bereits über das Natten sichergestellt. Ich nehme doch mal an, es handelt sich nicht um ein 1:1-NAT, sondern um ein 1:n-NAT (per PAT)? In letzterem Fall wären Zugriffe von extern zu Euch nur dann möglich, wenn hierfür explizit ein Forwarding eingerichtet wurde. Anderenfalls wüsste der Router gar nicht, was er mit dem Verbindungsversuch anfangen soll und verwirft die Pakete. Gruß Steffen

Indem Du einfach mal mit den Admins der Gegenseite telefonierst? Beissen die...? :p Dann ist der Routingeintrag auf der Gegenseite tatsächlich nicht erforderlich. Also nur HTTP(S)? Dann müssen doch nur diese URLs in die richtige IP-Adresse aufgelöst werden. Greifen Deine Clients über einen Webproxy auf Webseiten zu (z.B. ISA-Server)? Dann wäre es das Einfachste, am Server, auf dem der Proxy läuft, in der Hosts-Datei die URLs einzupflegen. Voraussetzung ist natürlich, dass der Proxy selbst die Namensauflösung macht (kein Upstramproxy eingetragen). Gruß Steffen

kleine Ergänzung: Im Remotenetz muss selbstverständlich auch eine Route in das Netz 192.168.1.0/24 existieren. ;) Gruß Steffen

Mir ist (noch?) nicht bekannt, dass man den ISA 2004 im Bridgemodus betreiben könnte. Folglich bräuchtest Du 2 IP-Netze, damit der ISA Inside und Outside unterscheiden und hierzwischen routen kann. Das würde dann z.B. so aussehen: ~~~~~~~ ~Internet~ ~~~~~~~ | o WAN-Interface mit öff. IP-Adresse [Fritzbox] o "LAN"-Interface: 192.168.1.1/24 | o Outside-Interface: 192.168.1.2/24, GW: 192.168.1.1 [iSA-Server] o Inside-Interface: 192.168.0.1/24 | [switch] Der ISA benötigt also 2 NICs. Sofern der ISA ausgehenden Verkehr nur routet (nicht nattet), müsste auf der Fritzbox noch eine Route ins Netz 192.168.0.0/24 eingetragen werden. Sollte die Fritzbox über eine passable Firewall verfügen (ich kenne das Teil nicht), dann hast Du damit sogar eine Frontend-Backend-Konstellation implementiert. Ins Netz 192.168.1.0/24 könntest Du dann z.B. öffentlich erreichbare Server stellen. Eine Alternative hierzu wäre evtl. die Fritzbox (sofern dies möglich ist) als reines PPPoE-Modem zu betreiben. Dann bekäme das Outside-Interface des ISA die öffentliche IP-Adresse. Zu Deiner Fehlermeldung bei der Installation: Mehr Infos Deinerseits erforderlich (siehe oben), sonst geht's hier nicht voran! Gruß Steffen

Würde bedeuten, dass das VPN-Gateway lediglich über einen weiteren Router zu erreichen ist. Oder wie ist das gemeint? Ich dachte, es existieren nur 2 Router... Mach doch einfach mal eine kleine Skizze (einschließlich der brauchbaren Angabe der IP-Adressen/Netze)! Gruß Steffen