DeathAndPain

Die Segmentlänge ist bei meiner Frage kein Problem, weil es ja um Switche und nicht um Hubs oder Repeater geht, die ich in Reihe schalten möchte. Gibt es eine Obergrenze für die Anzahl an Switches, die sich bei 1000BaseT (interessant auch bei 100BaseTX) zwischen zwei miteinander kommunizierenden Endgeräten befinden dürfen?

Ich könnte mir beispielsweise vorstellen, daß in dem einen Endgerät Timeouts ablaufen, wenn nicht innerhalb einer bestimmten Zeitspanne eine Antwort eintrifft. Nicht auf Schicht 1 - da geht die Verbindung nur bis zum nächsten Switch - aber vielleicht auf einer höheren Schicht.

Meine Frage zielt auf die technische Spezifikation, nicht auf das, was man real vielleicht noch hinkriegt.

Welchen Zweck soll das denn haben?

 

Ich meine, es muss ja ein Fenster geben, indem du die benötigten Daten für eine Verbindung einträgst! Oder hab ich dich falsch verstanden...?

Ich denke schon. :) Ich meine nicht das Fenster, in dem man angibt, welchen Laufwerksbuchstaben man mit welchem UNC-Pfad belegen möchte, sondern das zusätzliche Explorerfenster, das sofort mit dem neu eingerichteten Laufwerksbuchstaben aufgeht, wenn man OK geklickt hat und die Zuweisung hergestellt ist - und das man i.d.R. gleich wieder zuklickt, weil man in seinem bisherigen Explorerfenster weiterarbeiten möchte.

Nebenbei bemerkt gibt es auch noch einen Befehl für die Kommandozeile: net use

Ich weiß, aber das war nicht meine Frage. Erst eine Shell aufzumachen, wenn man im Explorer rasch ein Laufwerk verbinden möchte, wäre ja noch unbequemer als das Wegklicken des Nag-Screens.

Dazu fällt mir spontan ein, es mit einer Batch-Datei (auf dem Desktop) zu verbinden.

Dann müßte ich die Verbindung ja vorab in Stein gießen (fest in die Batchdatei reinhacken). Ich möchte aber einfach nur flexibel Verbindungen im Explorer herstellen können, ohne daß mir jedesmal ein zusätzliches Explorerfenster auf den Schirm knallt. Das ist das normale Systemverhalten unter NT 4.0; erst die nachfolgenden Versionen machen diesen Unsinn.

Beim klicken auf OK vorher die Shift taste gedrückt halten, dann gibts kein neues Exploerefenster.

Vielen Dank, das ist schon ein Ansatz. Muß ich ausprobieren, wenn ich wieder an der XP-Kiste bin. Wobei mich die Lösung an die Sache mit dem Autoplay bei CDs erinnert (das konnte man schon unter Win95 auf dieselbe Weise verhindern). Beim Autoplay konnte man freilich auch einen Registrierungseintrag setzen, der es gänzlich verhinderte. Ich fände es zumindest erstaunlich, wenn es den für mein Problem nicht gäbe - immerhin war das von mir gewünschte Systemverhalten Windows-Standard bis NT 4.0.

Dankeschön!

Die folgende Frage wurde 2003 schon zweimal gestellt (einmal davon von mir), aber es kam keine Antwort (bei mir) und eine unbrauchbare (falsche) Antwort (bei dem anderen), drum erlaube ich mir, die Frage noch mal zu stellen, in der Hoffnung, daß mittlerweile jemand Rat weiß:

Wie kann man unter XP (und/oder 2000) erreichen, daß beim Verbinden eines Netzlaufwerks im Explorer nicht automatisch ein neues Fenster mit dem verbundenen Laufwerk aufpoppt? NT 4.0 hat diesen Quatsch von Hause aus nicht gemacht, sondern einfach nur den neuen Laufwerksbuchstaben links in die Liste eingefügt (im bereits geöffneten Explorer-Fenster). Dasselbe Verhalten wünsche ich mir unter XP.

Soweit ich mich erinnern kann, ist es doch gerade ein Feature von NewSID, daß es die SIDs zweier Server angleichen kann, damit sie anschließend als DCs derselben Domäne fungieren können!?

Ich habe zwei Fragen zu FAT16 und FAT32:

• In den gängigen FAQs steht, FAT16 könne bis maximal 4 GB umgehen (NT 4.0 und höher). Ich meine aber mal, irgendwo gelesen zu haben, daß auch 8 GB möglich sind. Die Nachteile sind mir bekannt (Clustergröße). Dennoch würde ich gerne wissen, ob und ggf. wie sich solch Partition erzeugen läßt und ob XP damit umgehen kann.
   
  
• Microsoft hat die maximale Partitionsgröße bei der Erzeugung von FAT32-Partitionen in Windows 2000 und XP böswillig auf 32 GB beschränkt. Umgehen können diese Windows-Versionen allerdings sehr wohl mit größeren FAT32-Partitionen. Es ist mir aber seinerzeit auch mit einer Win98-Bootdiskette mit FDISK drauf nicht gelungen, hinter einer 4 GB FAT16-Startpartition (die ich natürlich mit solch Diskette nicht bearbeiten kann, aber ist ja egal) noch eine 76 GB FAT32-Partition anzulegen. Drum also die Frage: Wie ließe sich das machen? Ich habe CDs von allen Windows-Versionen ab 95 im Schrank, aber nur XP installiert und will natürlich keine komplette Windows-Installation durchziehen, bevor ich an meine Partition komme.

Hintergrund (nur lesen, falls interessiert. Für das Verständnis meiner Fragen ist der nachfolgende Text nicht erforderlich): Die zusätzlichen Features von NTFS braucht man auf einer heimischen Einzelplatzmaschine nicht. Aber diese Features sind nicht ohne Preis: Jedes vorhandene Dateiattribut muß auch gepflegt werden, was eine gewisse Systemlast bedeutet. Außerdem krankt NTFS noch immer an der alten Seuche der unnamed MFT table entries, für deren Reorganisation es nach meinem Kenntnisstand bis heute kein Tool gibt und die sogar der Ghost brav mitkopiert.

Und so habe ich mein XP auf einer 4 GB FAT16-Bootpartition installiert. Die Größe der FAT ist bei FAT16 gerade mal 128k. Das hält Windows komplett im Hauptspeicher und erreicht dadurch eine abenteuerlich schnelle Dateiverwaltung. Auch die ganzen zusätzlichen NTFS-Dateiattribute müssen nicht gepflegt werden, weil es sie unter FAT16 nicht gibt. Die Folge: Trotz abgeschaltetem Prefetch bootet der Rechner so schnell, daß der animierte Balken im XP-Bootbildschirm nur einmal nach rechts wandert, dann ist XP schon oben. Das schaffen andere mir bekannte Rechner nicht mal mit aktiviertem Prefetch. Die paar Megs, die ich durch die großen Cluster verliere, sind bei heutigen Plattengrößen egal.

Allerdings paßt XP nur knirsch auf eine 4 GB-Bootpartition. Ich habe da schon etwas gezaubert und z.B. die Driver Cache DLLs (d.h. die Kopien aller DLLs, die XP im Hintergrund hält, falls eine Anwendung eine DLL mit einer älteren Version überschreibt) auf die zweite Partition gepackt. Das funktioniert natürlich nur nach Fuhrwerken in der Registrierung. Aber spätestens bei Longhorn werde ich so wohl nicht mehr zum Ziel kommen. Da wäre eine 8 GB FAT16-Partition schon sehr hilfreich.

Für die zweite Partition mit 76 GB habe ich in meiner Not NTFS genommen. FAT32 wäre mir aber aus den genannten Gründen lieber gewesen, und ich würde schon gerne wissen, wie ich es beim nächsten Mal hinkriegen kann, ohne nur dafür ein Partitionstool für € 50,- anzuschaffen. (Dagegen wäre ein Partitionstool, das 8 GB-FAT16-Partitionen hinkriegt, schon interessant.)

Den gibt es schon deswegen, weil ich BDCs habe. ;) Nach meinem Kenntnisstand haben alle DCs einer Domäne dieselbe SID.

Die gute Nachricht ist, daß der Eintrag mittlerweile verschwunden ist. Hat sich also erledigt. Schönen Dank.

Ich habe meinen NT 4.0-BDC umbenannt. Vorher hieß er SAPALT; der neue Name war BERLIN. Also habe ich ihn auf dem PDC aus der Domäne entfernt, dann umbenannt und anschließend wieder in die Domäne eingebracht. Zuguterletzt habe ich ihn zum PDC befördert.

Problem an der Sache: Im Server-Manager steht der Zombie-Eintrag SAPALT immer noch drin. Der neue Eintrag BERLIN ist auch drin, was ja ok ist. Wenn ich SAPALT anwähle und sage, daß ich diesen Rechner aus der Domäne entfernen möchte, so bekomme ich die Meldung, daß er in Wahrheit gar nicht mehr in der Domäne ist, auch wenn er noch in der Liste angezeigt wird. Innerhalb der nächsten 15 Minuten würde die Liste dann upgedatet werden.

Leider ist das nicht der Fall. Der Zombie verbleibt in der Liste (auf allen DCs). Die Synchronisation zwischen PDC und BDC klappt einwandfrei, und da BERLIN mittlerweile selber PDC ist, könnte er ja den Eintrag auch eigenständig entfernen.

Ich habe auch schon händisch die WINS-Einträge für SAPALT gelöscht (denn einen Rechner dieses Namens gibt es ja im Netz nicht mehr). In der Server-Manager-Liste verbleibt der Eintrag dennoch.

Wie kriege ich den weg?

Ich muß dazu allerdings anmerken, daß das in diesem Thread beschriebene Problem dadurch nicht gelöst wurde und weiterbesteht. Insofern wäre ich für Tipps dankbar.

Er ist Mitglied der Domäne, falls Du das meinst. Domänencontroller ist ein NT 4.0 Server SP6. Aber das war vor dem Auftreten des Fehlers auch schon so. Außerdem erfolgt der SUSadmin-Zugriff ja per HTML, also vorbei an dem ganzen Windows-Authentifizierungsgeraffel.

Was mir allerdings aufgefallen ist: Durch die Patches scheinen eine ganze Reihe von Dateizugriffsrechten verlorengegangen zu sein. Ich hatte eine Palette von Fehlermeldungen im Event Log, die darauf hindeuteten, daß der SUS-Server auf eigene Programmteile nicht mehr zugreifen konnte. Ich habe dies händisch durch großzügige Vergabe von Zugriffsrechten (mit Vererbung nach unten) korrigiert. Danach traten die Fehlermeldungen nicht mehr auf.

Hallo allerseits!

Ich betreibe einen SUS-Server unter Windows XP Prof. (doch, das geht, in der c't stand mal, wie man es hinkriegt, und er funktioniert auch seit vielen Monaten ganz wunderbar).

Nun hat Microsoft am 15.12. einen Packen neuer Sicherheitspatches für Windows XP herausgebracht. Die habe ich auch auf dem SUS-Server installiert. Seitdem habe ich nun folgendes Problem:

Ich kann wie bisher mit dem Internet Explorer eine Verbindung zu dem SUS-Server herstellen und mir anschauen, was es an neuen Patches gibt. Wenn ich aber im Synchronization Log oder Application Log auf "Clear Log" klicke, dann passiert gar nichts! Normalerweise müßte dann ein Fenster aufpoppen, ob ich wirklich löschen möchte, und wenn ich dann auf OK klicke, dann müßte er es machen.

Der Witz an der Sache: Wenn ich dasselbe direkt an der Konsole des SUS-Servers mache, dann funktioniert es.

Klingt nach XP-Firewall? Die ist auf dem SUS-Server aber komplett abgeschaltet! Auf dem Client, von dem aus ich das mache, läuft der Internet Explorer 6SP1 mit allen Patches (aber ohne Popup-Blocker, den gibt's erst ab IE SP2).

Hat jemand eine Idee?

Normalerweise kann der Internet Explorer 6.0 Word- und Excel-Dokumente direkt im Browserfenster anzeigen.

Bei einem unserer Mitarbeiter klappt das aber nicht mehr: Der Internet Explorer versucht, die Datei als Klartext anzuzeigen, wobei natürlich nur Grütze rauskommt. Word und Excel sind aber einwandfrei auf dem Rechner installiert.

Wo stellt man das ein, ob der Internet Explorer auf diese - nun ja - Plug-ins (oder wie man diese Funktionalität auch immer nennen mag) zurückgreifen soll?

Vielen Dank,

Jens

Ich bin an einem vielversprechenden Lösungsansatz dran. Was mir bisher nicht bekannt war: Neben dem Webmin gibt es auch noch einen "Usermin", der über den Webmin eingestellt wird und als graphisches Interface für Endanwender dient. Der Usermin bietet (neben reichlich anderem) die Möglichkeit, Umleitungen zu schalten (und dabei auf Wunsch auch eine Kopie zu behalten). Damit können sich die Anwender auf dem Mail-Server graphisch einloggen. Mit dem Webmin kann man die Optik des Usermin mit ein paar Klicks soweit herunterstricken, daß nur noch die Mailumleitungsoption verbleibt.

Momentan stehe ich allerdings noch vor dem Problem, daß der Usermin auf einen PERL-Fehler läuft, wenn der angemeldete Anwender keine Root-Rechte hat. Aber das muß ja lösbar sein, schließlich ist der Usermin für Endanwender gedacht. Mal schauen, was ich rauskriege.

lefg:

Nur Umleitung halte ich für problematisch. Der Urlauber erfährt nach Rückkehr eventuell nichts von Vorgängen. Die Vertretung sollte eine Kopie erhalten.

Berechtigter Einwand. Wobei der SENDMAIL das alles von Hause aus kann. Mit dem Webmin kann man einfach die Aliases konfigurieren und dort Umleitungen, Kopien und auch Autoreplies schalten. Aber das geht natürlich nur als Administrator.

Aber das mit den Kopien ist eine organisatorische Frage. Mir geht es um die technische Realisierung einer Möglichkeit, daß der Anwender das für sich selber (und niemand anderen) einstellen kann, mit einem Interface, das für Endanwender zumutbar ist.

frieda:

Unser Kollege hat ein Perl Tool geschrieben, das sich über das Intranet bedienen lässt. So kann der Support z.B. Mail Weiterleitungen auf dem Linux Server einrichten.

Der "Support" hat vermutlich auch Adminrechte. Das kriegt man auch mit dem Webmin hin. Aber mir geht es wie gesagt darum, daß der Anwender es selber machen kann. Sonst klingelt hier nur noch das Telefon.

Daß man theoretisch einen Dienst selber programmieren könnte, der das irgendwie realisiert, leuchtet mir durchaus ein. Aber ich finde das Problem so naheliegend, daß ich mir kaum vorstellen kann, daß es dafür nicht schon eine fertige Freeware-Lösung gibt. Wie gesagt, praktisch jedes Unternehmen ohne Exchange-Server (oder Vergleichbares) müßte doch dieses Problem haben.

Wir haben hier ein internes Netz mit einem Linux Mailserver (Sendmail). Die Anwender haben auf ihren Windows NT-Clients einen normales POP3/SMTP-EMail-Programm, mit dem sie Mail vom Server empfangen und versenden.

Die Frage ist nun, wie man es den Anwendern ermöglichen kann, ihre Mail an jemand anderen umzuleiten, wenn sie in Urlaub gehen. Als Administrator kann ich z.B. per Webmin auf den Mailserver gehen und in der Alias-Liste für den Anwender eine Umleitung eintragen. Aber das ist natürlich kein praktikabler Weg; die Anwender sollten das selber einstellen können (für ihr eigenes Account).

Auf dem Mail-Server existiert natürlich für jeden Anwender ein eigenes Benutzeraccount, unter dem ja auch die Mail aufläuft. Aber die Anwender arbeiten nur mit ihrem Windows und loggen sich nie beim Mail-Server ein (abgesehen vom POP3-Abruf). Sie wären auch überfordert, wenn man ihnen eine Linux-Shell hinstellen würde mit der Maßgabe, sich da einzuloggen, um mit irgendwelchen Befehlen ihre Mail umzuleiten.

Fällt jemandem ein Weg ein, wie man da rangehen kann? Gibt es z.B. ein HTTP-basiertes Tool (ähnlich webmin), mit dem man für den eigenen Linux-Login eine Mailumleitung schalten kann (ohne Adminrechte zu besitzen)?

Ich frage mich, wie andere Unternehmen mit diesem Problem umgehen - Urlauber gibt es schließlich überall. Und nur deswegen einen Exchange-Server aufbauen scheint mir doch mit Kanonen auf Spatzen (auch kostenmäßig).

zmans Frage ist berechtigt. Er geht davon aus, daß man nun wirklich die DNS-Einträge wie in obigem Beispiel geschaltet hat und möchte, daß http://www.xyz.com'>http://www.xyz.com auf dem zweiten Webserver landet, der auf 8080 läuft. Das wird es aber nicht von alleine: Der Endanwender-Browser wird bei Eingabe von http://www.xyz.com von sich aus auch Port 80 unterstellen. Port 8080 erreicht man nur, wenn man ihn ausdrücklich verlangt (durch Eingabe von http://www.xyz.com:8080) oder wenn man dorthin weitergeleitet/gelinkt wird. Wenn man vom Benutzer nicht erwarten möchte, den Port manuell anzugeben, wird man also doch die Browserzeichenkette softwaregesteuert auswerten und auf den richtigen Port weiterleiten müssen.

Auf diesem Hintergrund war mein Beispiel wohl nicht so glücklich. Richtig ist aber dennoch, daß man nur so eine Chance hat, mehrere voneinander softwaremäßig unabhängige Webserver auf einer Hardware mit einer IP zu betreiben. dongel hat jetzt die Frage aufgeworfen, zu welchem Zweck Stadtplandienst.de das machen könnte. Da es bei dem 8080 offenbar um die Werbebanner geht, vermute ich, daß sie ihre eigene Webseite (ihren Content) trennen wollen von einer Software, die zufallsgesteuert oder anhand von gesammelten Surferinformationen oben die Banner einblendet und möglicherweise auch die Abrechnung der Werbung (anhand der Anzahl der Mausklicks) mit erledigt. Das können innerhalb von Stadtplandienst.de völlig unterschiedliche Abteilungen sein: Die eine kümmert sich um den Stadtplan-Service auf dem einen Server, die andere verhandelt mit den Firmen, die die Werbung schalten, und administriert den Bannerwerbungsserver. Daß man das nicht in einer Software vermixen will, kann ich schon verstehen. Möglicherweise müssen sie auch für die Bannerwerbung eine definierte Fremdsoftware einsetzen (der Abrechnung wegen), die sich für ihren Stadtplandienst-Content gar nicht eignet.

Möglich wäre sogar, daß der Bannerwerbeserver von einer externen Werbefirma per telnet, ftp und ähnlichem administriert wird und Stadtplandienst dafür nur die Hardware bereitstellt. Logischerweise wollen sie dann jene externe Firma nicht in ihrem eigenen Content haben und betreiben daher softwareseitig separate Webserver (wenn auch auf derselben Hardware), wobei die externe Firma nur den 8080er administrieren kann.

dongel:

Und bin sehr gespannt, was beim support und vom webmaster zurückkommt!!!

Wenn Du meine ehrliche Meinung hören möchtest: Ich denke, daß da gar nichts zurückkommen wird.

Lian hat in der Tat gut beobachtet. Letztlich macht es allerdings keinen Unterschied, ob die Zielseite auf Port 80 einen Redirect auf 8080 macht (wie von mir vermutet) oder nur einen automatisch zu ladenden Bildlink auf 8080 enthält. In beiden Fällen wird der Browser des Endanwenders versuchen, den Zielserver auf Port 8080 anzusprechen, und darum geht es ja hier.

also , ich versteh dieses mapping trotzdem nich, warum wird das gemacht??

Ich kann mich erinnern, das mal in einer Portnummernerläuterung gelesen zu haben. Man macht es wirklich dann, wenn man mehrere HTTP-Server auf einer Maschine betreiben möchte.

Schau mal, gesetzt den Fall, Du willst die Webseiten http://www.abc.com'>http://www.abc.com und http://www.xyz.com'>http://www.xyz.com hosten. Die beiden Webseiten haben miteinander gar nichts zu tun. Du willst sie aber auf ein- und demselben Server betreiben, der auch nur eine externe IP hat. Nehmen wir an, diese IP sei "1.2.3.4".

Nun läßt Du zunächst einmal bei Deinem Provider DNS-Einträge schalten, und zwar "www.abc.com" = "1.2.3.4" und "www.xyz.com" = "1.2.3.4". Anders kannst Du es nicht machen, sonst kommen die Anfragen gar nicht bei Deinem Server an (es sei denn, Du leistest Dir eine weitere externe IP).

Wenn nun ein Anwender in seinen Browser "http://www.abc.com" eintippt, dann ist das 100% äquivalent zu der Zeichenkette "http://1.2.3.4". In beiden Fällen landet er auf Deinem Server, Port 80. Das würde er aber auch, wenn er "http://www.xyz.com" eintippen würde. Möglicherweise kannst Du mit einer hinreichend intelligenten Serversoftware noch Headerinformationen auswerten, die vom Browser mitgeliefert werden (Referrer etc.). Damit könntest Du vielleicht eine Chance haben herauszufinden, welche Zeichenkette der Surfer tatsächlich in seinen Browser eingetippt hatte. Aber wenn wir von einem ganz primitiven Dateiserver ausgehen, auf dem einfach Dateien im HTML-Format liegen, dann hast Du so keine Chance, zwischen http://www.abc.com und http://www.xyz.com zu unterscheiden.

Um dies zu umgehen, sucht man sich für zusätzliche Webserver auf derselben Maschine Ports ab 8080. 8080 ist dabei willkürlich gewählt, soll aber durch die doppelte 80 die Beziehung zum Port 80 verdeutlichen und ist daher für solche Zwecke üblich.

sieht eher so aus als stünde Müll im Code.

Ne, in diesem Fall (Stadtplandienst) sind es die Werbebanner, also gut verzichtbar. Da hängt auch ein bischen PHP-Code dran, um etwaige Klicks auszuwerten, deswegen mag das nicht planmäßig funktionieren, wenn Du versuchst, die Links direkt aufzurufen. Aber es kann natürlich auch mal eine nützliche Seite hinter solch einem Link sein.

Verhält sich denn die VW tatsächlich anders, wenn du aus dem drop ein reject machst??

Ja! Ich habe es gerade mal ausprobiert. Oben im Netscape steht dann statt der Werbebanner nur groß "Error" (was ja den Tatsachen entspricht, denn die Banner konnten nicht geladen werden). Im Log sieht man ein paar Rejects, (mehrere Banner mal ein paar Versuche des Browsers), aber dann ist Ruhe. Das wäre also ein Weg, wenn man bereit ist, auf Seiten zu verzichten, die auf nonstandard-Ports laufen.

Und mich würde wirklich mal interessieren was der support der VW dazu sagt, kann doch irgendwie nich sein, das be******ener Quellcode die Verbindung kappt, oder??

Na ja, TrendMicro hat ein Support-Webformular, das man ausfüllen und abschicken kann. Dadurch erhält man sofort automatisiert folgende Antwort:

For all technical queries, please contact your Trend Micro Distributor / Reseller , who will answer your query. These partners have shown a knowledge and understanding of Trend Micro products, which should provide you with high quality advice and services.

 

Wenden Sie sich bitte bei technischen Fragen an den TREND MICRO Händler , von dem Sie Ihr Produkt bezogen haben. Dieser kennt sowohl Ihre Systemumgebung, als auch alle TREND Produkte genau und wird daher Ihre Fragen schnell und effizient beantworten.

 

Pour toutes les questions techniques, merci de contacter votre Distributeurs/Revendeur qui repondra à votre demande. Ces partenaires disposent d’une base de connaissance des produits Trend Micro qui devraient vous fournir un conseil et des services de haute qualité.

 

Per qualsiasi informazione tecnica, contattate uno dei Rivenditori TREND MICRO, che risponderà alle Vostre domande. Questi rivenditori hanno ottenuto la certificazione TREND MICRO, pertanto sono in grado di offrirVi consigli e servizi di qualità.

 

Trend Micro proporciona diversas vías de soporte del software. Consulte la vía de soporte adecuada dependiendo de su situación: Si usted es cliente final, pulse http://es.trendmicro-europe.com/enterprise/support/support_final.php. Si usted es un distribuidor, pulse http://es.trendmicro-europe.com/enterprise/support/support_dist.php.

Ob da noch eine richtige Antwort hinterherkommen wird, bleibt abzuwarten. Ich tendiere allerdings dazu, daß diese Antwort als "Leck uns" zu interpretieren ist.

Unser TrendMicro-Händler ist die IBM. Der zuständige Mitarbeiter - ein durchaus kompetenter Mann - hat mir gesagt, daß er der Viruswall alles zu erlauben pflegt. Ich wollte halt hier mal fragen, ob das allgemein so gesehen wird.

Eine Mail an den Webseitenbetreiber habe ich auch geschickt mit Verweis auf diesen Thread. Mal schauen, ob er sich meldet.

dongel:

Und deine VW kenne ich leider auch nicht, vermutlich gibt es keine Möglichkeit dies auf der VW zu sperren, oder??

Nein, dafür ist die Firewall ja da. Was man vielleicht versuchen könnte, ist eine Regel in der Firewall, derzufolge sie mit VW-Paketen auf anderen Ports als 80 nicht "Drop", sondern "Reject" macht. Das heißt, daß sie die Pakete nicht kommentarlos verwerfen, sondern ein Verweigerungspaket als Antwort schicken würde. Dann wüßte die VW, daß ihre Pakete nicht verlorengegangen sind, sondern absichtlich geblockt wurden, und würde es möglicherweise nicht nochmal versuchen. Allerdings nur, wenn die VW und nicht der Client derjenige ist, der es immer wieder versucht. Außerdem wären derartige Webseiten dann natürlich nicht mehr nutzbar. Ein paar wenns und abers also, aber vielleicht probiere ich das mal aus.

dongel:

Die Seite läuft doch aber auf port80!!

Ich glaube, dieses Mißverständnis ist der springende Punkt. Richtig ist, daß eine Anfrage auf http://www.stadtplandienst.de eine Anfrage an den Server 62.50.40.190, Port 80 auslöst. Aber die Antwort, die man von dem Server erhält, enthält zunächst einmal einen Redirect auf 62.50.40.190, Port 8080. Dadurch wird der Browser auf dem Endanwender-PC veranlaßt, an diesen Port eine Anfrage rauszuschicken.

Zur Veranschaulichung hier ein Ausschnitt aus dem Trace der Firewall:

Mein Rechner ist hierbei "EDV2". Der Trace ist so gefiltert, daß nur Anfragen von meinem Rechner und der Firewall dargestellt werden. (Eingehende Antworten auf diese Anfragen sieht man im Trace leider nicht.) Man sieht im Trace sehr schön, wie ich initial die Stadtplandienst-Seite aufrufe: Source EDV2 and Destination viruswall mit Dienst HTTP (das ist in diesem Trace immer Port 80) (Zeilen 1 und 2). Danach reagiert die Viruswall sofort, indem sie selber HTTP-Anfragen an den Stadtplandienst-Server 62.50.40.190 rausschickt (Zeilen 3 und 4).

Der antwortet mit der Seite, die den Redirect auf Port 8080 befiehlt (diese Antwort sehen wir im Trace nicht). Also schickt mein Rechner sofort wieder Anfragen raus (Zeilen 5, 6, 7). Im Trace sieht man jedoch nicht, daß diese an Port 8080 gerichtet sind, weil die Proxy-Einstellungen des Browsers sie auf Viruswall, Port 80 umbiegen.

Die Viruswall hingegen schickt die Anfrage auf dem eigentlich gewünschten Port, nämlich 8080, weiter. Die Firewall verwirft diese Pakete (rote Einträge) (Zeilen 8, 9).

Velius:

Ich habe das 'mal so nachgestellt:

 

Mit IE, und mit Firefox http://www.mcseboard.de geöffnet (wahrscheinlich ginge es auch mit 2 IE Fenstern), und mir NETSTAT angeschaut.

Ja, aber Du greifst in Deinem Beispiel auf die gleiche Webseite zu, also nicht auf zwei verschiedene Webserver, die unter derselben IP und Portnummer segeln. Natürlich kann mehr als ein User gleichzeitig Verbindung mit einem Webserver aufnehmen (man überlege sich, was es bedeuten würde, wenn immer nur ein Mensch auf http://www.microsoft.com surfen könnte). Und natürlich verlangen alle Surfer, die einen Server ansprechen, dieselbe IP und Portnummer. Dein Rechner dividiert die beiden Verbindungen dann wieder auseinander und verteilt sie auf verschiedene Ports Deines Computers. Das entspricht dem, was erweitert auf mehrere PCs auch bei NAT passiert, hat aber mit dem Problem, um das es in diesem Thread geht, nichts zu tun. Denn hier geht es um verschiedene Ports auf dem Zielserver und Problemen mit Proxies und Firewalls dazwischen und nicht um verschiedene Ports auf dem Endanwender-PC, die auf denselben Port des Zielservers gemappt werden.

dongel:

ich fänds gut, wenn du uns mal auf dem Laufenden halten würdest

Man tut, was man kann. :)

dongel:

die Frage bleibt ja : wo und an welcher Stelle findet warum das portmapping statt???

Das dürfte nach obigem Trace nebst Erläuterung klar sein, oder?

Oh Mann, kommst Du Dir wichtig vor. Als ob es jemanden interessiert, wer auf Deiner ignore-Liste steht...

Velius:

Du könntest zum Beispiel eine Bridge nehmen? Wenn du weisst was ich meine.....

Eine Bridge in der Netzwerktechnik ist ein Gerät zur Verlängerung von Netzwerksegmenten, das ähnlich einem Repeater die Pakete auf der jeweils anderen Anschlußseite wiederholt, wobei sie aber anders als ein Repeater die Pakete logisch interpretiert und neu erzeugt und überdies in der Lage ist, eine Segmenttrennung zur Verminderung von Netzlast und Kollisionen durchzuführen.

Wie Du damit Internet-Traffic scannen möchtest, ist mir unklar. Sicher ist, daß der dafür allgemein übliche Weg der eines Proxyservers ist, der zwischen den Benutzer und das Internet geschaltet wird.

Velius:

2.: Im ersten Post hast du noch von geöffneten Verbindungen und später von Ports geredet......

Offen bleibt, worauf Du Dich mit dieser Aussage beziehst. Völlig unklar für mich, wovon Du jetzt redest.

Velius:

Na? Fällt dir was auf??

Ein typisches Log einer NAT-Verbindung. Dabei werden naheliegenderweise Ports umgesetzt, damit der NAT-Router die Verbindungen auseinanderhalten kann. Nach außen kommt jedoch stets nur Port 80 zum Einsatz, also gewöhnliche HTTP-Verbindungen. Hat mit dem in diesem Thread diskutierten Problem überhaupt nichts zu tun.

Velius:

Nicht frech werden ja

Ist es schlimm, wenn ich jetzt keine Angst habe?

Velius:

irgendwo beim lesen deiner Post hatte ich das komische Gefühl, dass du die Antwort auf deine Frage schon selber kennst,

Ich kannte einen möglichen Lösungsansatz und habe diesen im letzten Absatz des Threadanfangstextes auch dargelegt. Ich hatte allerdings Zweifel, daß dieser Ansatz erstens der bestmögliche und zweitens sicherheitstechnisch vertretbar ist und suchte daher Rat.

Velius:

falls nicht, dann dein Pech!!

Solche Sprüche Ratsuchenden gegenüber sind immer sehr hilfreich.

Jetzt sage ich mal, was ich denke: Du machst auf mich nicht den Eindruck, als ob Du das Problem hier überhaupt verstanden hast und überdies Bescheid über die üblichen - weil bewährten - Methoden wüßtest, wie man ein Mehrbenutzernetzwerk transparent gegen Viren durch HTTP und SMTP abschottet. Zu deutsch: Du weißt nicht, wovon Du redest. Die anderen, die auf diesen Thread geantwortet haben, wirkten in diesem Zusammenhang bedeutend kompetenter auf mich. Die haben verstanden, worum es geht und haben mir nicht meinen eigenen Lösungsansatz aus dem Ursprungstext als ihren genialen Einfall präsentiert, auf den ich mit ihrer Hilfe zum Schluß ja auch gekommen sei.

Velius:

In deinem Fall ist die VW also im eigentlichen Sinne Proxy Server mit Virus Scan Funktion.

Das gilt für alle mir bekannten Anti-Virus-Gateways. Wie willst Du es anders technisch realisieren, den gesamten Traffic (HTTP und SMTP), der in Dein Netz hineinfließt, nach Viren zu scannen? Bezüglich Email könnte man vielleicht noch was direkt auf dem Mail-Server machen. Aber wenn Du HTTP transparent scannen möchtest, ist doch ein Proxy-Server die naheliegendste Lösung. Insofern ist das, was ich hier geschildert habe (mit Viruswall in DMZ der Firewall), die branchenübliche Konfiguration.

Velius:

Meine Frage wäre gewesen: Wieso nicht Port 80 auf der FW für die VW nach aussen öffnen?

Der war schon immer offen. :) Du meinst sicherlich 8080.

Velius:

Aber scheinbar bist du jetzt selber darauf gekommen....

"Jetzt"? Hmm... Lies doch mal bitte den ersten Satz des letzten Absatzes des Anfangstextes, mit dem ich diesen Thread eröffnet habe...

Nix für ungut, Velius, ich weiß Deine Bemühungen wirklich zu schätzen, aber bitte erst mal genau lesen, worum es bei der Frage eigentlich geht.

Operator:

also bevor ich alle Ports öffnen würde, würde ich mir das Logfile schnappen und schauen welche Ports denn alle betroffen sind.

 

Wenn es nur 3 wenige sind, gibst Du halt die frei und auch nur zu bestimmten Zielen. Das wäre das sicherste.

Na ja, das Problem ist, daß ich damit nur an den Symptomen doktere. Jeden Tag könnte ein Server mit einem anderen Port auftauchen, und ich merke das dann daran, daß der Internetzugang der ganzen Firma plötzlich nicht mehr funktioniert. Ich würde das Problem aus naheliegenden Gründen gerne stoppen, bevor es soweit kommt...

Wobei ich anhand der Firewall-Logs den Eindruck habe, daß es nicht der Endanwender-Client, sondern die Viruswall ist, die bei Ausbleiben der Antwort immer wieder neue Anfragen ins Netz schickt - und damit sich selber und/oder die Firewall mit den offenen Verbindungen ausbremst. Möglicherweise müßte man damit mal an den Hersteller herantreten...

dongel:

Wenn wir hier um checkpoint und Viruswall reden, handelt es sich bei der Viruswall um eSafe??

Nein, um eine TrendMicro InterScan VirusWall.

dongel:

Komplett aufmachen, halte ich für einen fatalen Fehler, damit knockst du die Firewall ja komplett aus!!! und zumindest ein Server in der DMZ ist komplett offen------- geht nicht!!!

Komplett offen würde ich nicht sagen. Nur offen für ausgehende Verbindungen. Solange niemand die Viruswall übernimmt, sollte das egal sein. Und zum Übernehmen bräuchte man eine eingehende Verbindung.

dongel:

Und die andere Frage, ist diese Ziel denn so wichtig???

Ich meine, man sollte das genau abwägen, bloß wegen einer Webseite die Firewall aufzumachen!!!

Wie gesagt, wenn ich sicher wüßte, daß es für alle Zeit nur diese eine Seite sein wird, würde ich mir was einfallen lassen. Aber jeden Tag kann eine andere Seite mit einem anderen Port auftauchen, die von irgendeinem ahnungslosen Anwender angesurft wird, und wenn dann jedesmal der gesamte Internetzugang der Firma zusammenbricht, dann ist das sch****.

dongel:

Ist für den Website Betreiber sicherlich nur ne Kleinigkeit dies abzuändern.

Noch nicht mal da bin ich mir so sicher. 8080 für Web-Server nimmt man meistens dann, wenn man mehrere Webserver auf einer Maschine zu laufen hat. Den Port 80 gibt's halt nur einmal. Möglicherweise würde das für ihn bedeuten, daß er sich einen weiteren Server hinstellen muß, und das ist nicht ganz ohne Aufwand für ihn. Und für mich würde das wie gesagt das Problem nur für diese eine Seite lösen, aber nicht prinzipiell.

dongel:

Um welche Seite handelt es sich denn genau?? Kannst du mal die URL posten???

Die steht detailliert im Anfangstext dieses Threads. ;)

Velius:

Bin ich jetzt **** oder was, aber du sagst, dass die Viruswall, den Port 80 auf 8080 ummappt. Also im Prinzip machen alle Anfragen eine Schleiffe von FW/80 -> VW/8080 - > FW/8080

 

Ist das richtig?

Ja, aber nicht ganz vollständig. Die vollständige Kette sieht wie folgt aus:

Endanwender-Browser will haben: 8080 -> Proxy-Settings in Browser leiten die Anfrage auf Viruswall, Port 80 um -> FW/80 -> VW/8080 - > FW/8080 ->|| Stadtplandienst/8080

Wenn Du mal in die Proxy-Einstellungen Deines Browsers (egal ob Netscape oder IE) reinschaust, dann siehst Du, daß Du dort nicht nur eine IP, sondern auch einen Port für den Proxy eingeben kannst. Dahin werden alle Anfragen umgeleitet. Erst der Proxy (hier: VW) selber stellt die Anfrage dann wieder auf dem eigentlich gewünschten Port an den Zielserver.

Operator:

Aber damit bekommst Du die halboffenen Verbindungen bis zu einem gewissen Grad weg.

Ok, das wäre ein Workaround. Meine ursprüngliche Frage war allerdings, ob sicherheitstechnisch etwas dagegen spricht, der Viruswall alle Ports nach außen zu erlauben. Das wäre nach meinem gegenwärtigen Eindruck nur dann gefährlich, wenn die Viruswall selbst erfolgreich angegriffen werden würde. Die ist jedoch hinter NAT versteckt und von außen nur über SMTP erreichbar, wobei dabei die Firewall noch die Korrektheit des SMTP-Protokolls überprüft, bevor sie die Anfragen an die Viruswall weiterleitet.

Vielen Dank erstmal für eure engagierte Hilfe!

Blacky_24 wrote:

GRÜBELMODUS ON: Wenn das HTTP-Relay in der DMZ steht muss der Traffic doch mindestens 1x durch die Firewall? Wenn die den Traffic aber blockt dürfte der doch garnicht erst bis zum HTTP-Relay kommen?!?!

Dieses Detail scheint hier von mehreren mißverstanden worden zu sein, daher nochmal Schritt für Schritt:

• Browser will HTTP-Anfrage an Stadtplandienst, Port 8080, schicken
   
  
• Auf dem Endanwender-Client ist jedoch ein HTTP-Proxy eingestellt, und zwar die Viruswall mit Port 80. Also schickt der Endanwender-Client die Anfrage dorthin.
   
  
• Die Anfrage erreicht die Firewall. Es handelt sich um einen HTTP-Aufruf vom internen Netz an die Viruswall, Port 80. Das läßt die Firewall durch (normale Surfregel).
   
  
• Die Viruswall erhält die Anfrage. Hier (und nicht in der Firewall) erfolgt das Port-Mapping, d.h. die Viruswall erkennt, daß die Anfrage eigentlich auf Stadtplandienst, Port 8080 gehen soll. Also schickt sie die Anfrage mit diesen Parametern an ihren Default-Gateway (nämlich die Firewall) in der Hoffnung, eine Antwort zu kriegen, die sie scannen und anschließend weiterleiten kann
   
  
• Die Firewall erlaubt der Viruswall nur Anfragen nach außen auf Port 80. Daher verwirft sie das Paket. Die Viruswall erhält niemals die erwartete Antwort. Der Endanwender-PC natürlich auch nicht.

corc wrote:

sorry, ich kann dieses Problem nicht nachvollziehen -- bei mir kommt keine einzige Anfrage an Port 8080 zum Vorschein.

Könnte es sein, daß die Anfragen an Port 8080 clientseitig, z. B. durch ein JavaScript gesteuert werden?

Möglich, das habe ich nicht geprüft. Dieses Script wäre dann aber Bestandteil der o.g. Stadtplandienst-Seite. Damit würde sich an dem prinzipiellen Problem nichts ändern.

dongel wrote:

IMHO dürfte das portmapping auf 8080 gar nicht stattfinden und müsste an der FW hängen bleiben.

Genau das tut es auch. Darin liegt ja das Problem. Die erwartete Antwort bleibt aus, also gehen immer neue Anfragen raus.

dongel wrote:

Was für eine FW hast du denn im Einsatz?

CheckPoint Firewall NG FP3 HFA 325. :)

Operator wrote:

vielleicht gelingt es Dir hiermit die halboffenen Verbindungen rechtzeitig wieder zu schließen!

Sowohl die Viruswall als auch die Firewall laufen unter Linux. Damit scheiden Windows-Tipps aus.

versteh ich nich so ganz, steht die Viruswall vor der Firewall??

Nein, dahinter. :) Genauer gesagt, in einer DMZ (einer richtigen DMZ, also nicht das, was viele DSL-Router fälschlich als DMZ bezeichnen).

Noch genauer erklärt läuft ein HTTP-Zugriff eines Endanwenders wie folgt ab:

Der Endanwender sitzt im internen Netz und stellt eine HTTP-Anfrage. Sein PC hat als Proxy für HTTP-Anfragen aller Art die Viruswall mit Port 80 eingetragen. Die Anfrage geht daher vom Endanwender-PC durch die Firewall in die DMZ und dort zur Viruswall. Die erzeugt eine eigene Anfrage gleichen Inhalts und schickt sie wieder durch die Firewall nach draußen ins Internet. Dabei setzt die Viruswall die Portnummer ggf. um: Während die Endanwender-PCs alle Anfragen auf Port 80 der Firewall schicken (weil das in den Proxy-Einstellungen des Netscape/IE/was auch immer so eingestellt ist), schickt die Viruswall die Anfrage auf dem eigentlich verlangten Port raus.

Die Antwort aus dem Internet geht dann durch die Firewall zur Viruswall, wird dort gescannt und bei Wohlgefallen zum Endanwender-PC weitergeleitet.

Normalerweise ist HTTP ja Port 80. Aber die o.g. Stadtplandienst-Seite leitet sofort auf eine andere Seite weiter, die zwar auch auf dem Stadtplandienst-Server liegt, aber dort auf Port 8080.

Ist die FW sauber konfiguriert??

Ich hoffe doch. :) Wobei "sauber" Ansichssache sein mag. Hier ist ja gerade die Frage, ob man der Viruswall erlauben sollte, auch andere Ports als 80 durch die Firewall hindurch anzufragen.

Wir haben folgendes Problem:

Ein Anwender hat ohne bösen Willen an mehreren Tagen unsere Viruswall (Proxy-Server, der den gesamten HTTP-Datenverkehr nach Viren scannt) vorübergehend lahmgelegt und damit den HTTP-Internetzugang der Firma unbrauchbar gemacht.

Er hat einfach nur die Seite http://www.stadtplandienst.de/home.asp aufgerufen. Dies führt zunächst erwartungsgemäß zu einem HTTP-Zugriff (Port 80) auf den Server mit der IP 62.50.40.190.

Nun leitet dieser Server den Benutzer aber auf den Port 8080 um. Es kommt in der Folge also zu HTTP-Zugriffen auf 62.50.40.190, Port 8080. Dieser Port ist in unserer Firewall jedoch nicht geöffnet; die Zugriffe werden daher verworfen.

Offenbar ist nun die Stadtplandienstseite so programmiert, daß bei Ausbleiben der erwarteten Antwort immer neue Zugriffe auf 62.50.40.190, Port 8080 ausgelöst werden. Dies kann man sehr schön im Trace der Firewall verfolgen. Auf der Viruswall entstehen auf diese Weise immer mehr offene Verbindungen, bis sie irgendwann am Anschlag ankommt und keine Verbindungen mehr öffnen kann. Ist dieser Punkt erreicht, so lassen sich aus der gesamten Firma keine HTTP-Seiten mehr aufrufen. (Diese Erklärung für das Phänomen ist meine Theorie; wenn Sie eine andere Erklärung haben, die mit dem Symptomen konform geht, wäre das natürlich interessant.) Effektiv entspricht meine Theorie in der Auswirkung einem erfolgreichen DoS-Angriff auf unsere Viruswall, nur daß der Angriff unabsichtlich und von innen erfolgt (nämlich von dem Endanwender-PC, der immer wieder nach der HTTP-Seite auf Port 8080 verlangt).

Kurzfristig läßt sich Abhilfe schaffen, indem man sich auf der Viruswall einloggt und den HTTP-Dienst kurz aus- und wieder einschaltet. Die Frage ist natürlich, wie wir dies in Zukunft verhindern können. Für den Stadtplandienst könnten wir natürlich eine Regel definieren, die entweder Zugriffe auf diese IP ganz verbietet oder den Port 8080 für diese IP aufmacht. Aber das erscheint mir nur wie Kurieren am Symptom, denn es kann ja jederzeit eine andere Webseite geben, bei der dasselbe Phänomen auftritt.

An dieser Stelle stellt sich mir die Frage, ob es sicherheitstechnisch bedenklich wäre, der Viruswall generell Zugriffe auf Port 8080 zu erlauben. Wenn nein, wäre das ausreichend? Oder könnte das gleiche Problem jederzeit auch mit einem anderen Port auftreten? Wie geht man da am geschicktesten ran?