Windows 2003 R2 Enterprise IIS 6.0 weist ein ASP Delay beim First Run einer Homepage auf

Hallo Wiesi200

Ich habe die zweite Anfrage eingestellt, weil sich die zuerst vermutete Ursache, ASP / DB-Verbindungs Problem, als falsch herausgestellt hat und es eigentlich ein IIS 6.0 / Windows Server 2003 Enterprise Problem ist.

Ja nur das dies unter dem angegebenen Link bei einem Windows Server 2008 IIS 7.5 angewendet wird.
Bei mir jedoch ist immer noch IIS 6.0 gegeben.
Bei mir tritt auch kein Delay von 30 Sekunden auf, wie dies im Artikel bei Stackoverflow erwähnt wird, sondern
nur ca. 5-6 Sekunden Verzögerung. Diese ist Browser-Session abhängig. Bedeutet, wenn ich den Browser
schliesse und wieder öffne, besteht das gleiche Problem. Auch wenn parallel ein Zweitbrowser geöffnet wird, können im Erstfenster Unterseiten normal geöffnet werden.

Da die einte Session noch besteht und die Sub-Seite auch problemlos läuft, zeitgleich im zweiten Browserfenster jedoch der gleiche Effekt auftritt, glaube ich kaum, dass ein Script auf dem Server, welches den Web Application Pool und alle anderen Dienste global auf dem Server starten soll, die Lösung sein kann, da ja die Processe bereits durch das erste Fenster am Laufen sind. Die Homepage wird nebst den eigenen Tests auch recht gut besucht. Es kann daher gut sein, dass wärend meines Tests ein weiterer User aus dem Internet auf der Homepage war.

Das Script öffnet im Grunde lediglich einen Browser im Hintergrund, mit einer Website. Das löst jedoch das Problem nicht, den es ist keine globale Ursache, sondern im Rahmen jeder neuen Session, die geöffnet wird. Ist diese mal offen, läuft alles wie geschmiert.
Ich hoffe, ich habe das jetzt plausibel genug beschrieben.

Gruss, René

Hallo zusammen

Ich habe den Tip mit dem Warmup Script ausprobiert.
Den Scheduler so konfiguriert, dass dieser alle 5 Minuten feuert.
Im Eventlog geprüft, ob das Eventlog einen Fehler enthält, um sicher zu gehen, dass dieser mit dem Script richtig funktioniert.
Dieses Script löst jedoch das Problem nicht. Es wird zwar ausgeführt ohne Fehlermeldung, generiert aber, wie mit einem normalen Browseraufruf eine gewöhnliche Session. Jeder Browser Client, der auf die Homepage zugreift, bekommt einen eigene Session zugewiesen, wie das auch sein muss. Wie schon erwähnt, kann das Phänomen sehr gut mit 2 untercshiedlichen Browsern reproduziert werden. Initialaufruf der Homepage im ersten Browser, ca. 6 Sekunden warten, danach funktionieren Unterseiten normal. Parallel im zweiten Browser Initialaufruf der Homepage, gleiches Verhalten, obwohl im ersten Browser alles wie es eigentlich sollte, funktioniert. Es muss also in erster Linie mit der Session zusammenhängen.

Eine Browserclient basierte Lösung über ein Script-Aufruf nützt da wenig, wenn das Speichermanagement des Application Pools auf globaler Ebene die Ursache ist. Es müsste wenn schon auf Registry Ebene oder gelöst werden können, bzw. eine Lösung geben, oder durch ein ehemaliges Patch von Microsoft. Ich bin mir auch nicht wirklich sicher, ob der Application Pool das Problem ist. Den auch ohne diesen tritt das Problem auf. (Kann im IIS Manager eingestellt werden.) Möglicherweise ist einfach der gesammte IIS Dienst mit allen Prozessen bei dieser Windows Version 2003 R2 Enterprise Server ein Scheiss Produkt von Microschrott.

Kennt wirklich niemand eine Lösung für das Problem?

Das würde ich schon tun, bin jedoch mit sehr hohen Alimentszahlungen belastet. (Pro Monat 4200 CHF)
Da der Server Privat betrieben wird, muss ich mit diesem Risiko zurecht kommen. Das Ganze ist mit Vollbackup gesichert.
Ich glaube nicht, dass es sich lohnen würde, einen unbedeutenden Server zu hacken, der mit Backups innert Minuten auf den letzten Stand zurückversetzt werden kann.

Dennoch ist das Problem weiterhin vorhanden und zurzeit bringen mir derartige Ratschläge, aus Kostengründen, nicht gerade viel.
Windows 2000 Server war zwar noch älter und noch weniger sicher, doch dort funktionierte zumindest alles zuverlässig über mehr als 8 Jahre hinweg, auch mit produktiven Homepages.

Bei der Firewall sind nur die Ports offen, welche für den Betrieb notwendig sind. Ausserdem sind unterschiedliche Regeln definiert, welche kurzzeitige Mehrfachzugriffe (max 2000 Sessions) unterbindet und alles dicht macht. (Ich weis, ist keine optimale Lösung.)

Ein Online Penetration Test ergibt folgendes Resultat.

PORT STATE SERVICE VERSION
22/tcp closed ssh
23/tcp closed telnet
25/tcp open smtp?
53/tcp open domain?
80/tcp open http? Scan with Web Server Scanner
199/tcp closed smux
587/tcp closed submission
993/tcp closed imaps
995/tcp closed pop3s
1025/tcp closed NFS-or-IIS
1723/tcp closed pptp
5900/tcp closed vnc
8888/tcp closed sun-answerbook
OS fingerprint not ideal because: Didn't receive UDP response. Please try again with -sSU
No OS matches for host
Network Distance: 12 hops

Jetzt frag ich mich, wie ein Hacker Online über Port 80, welcher als einziger für einen Angriff in Frage kommt, den IIS Hacken können soll?

Über die Port 80 TCP Packete können keine lauffähigen Programme übermittelt und ausgeführt werden. Dies lassen auch lokale Verzeichnis-Berechtigungen nicht zu. Der HTML Header Response/Request der Homepage liefert wiedersprüchliche Angaben für ein Session Hijacking.
Dürfte also auch über diesen Weg schwierig werden. SQL-Server Script Injection ist nicht möglich, da kein Login. Auch die URL-Parameter liefern bei falschen Werten eine Fehlermeldung zurück.

Ich sehe keinen Grund, beunruigt zu sein. Dennoch ist es vermutlich so, dass mein eigentliches Problem offensichtlich nicht gelöst werden kann, weil diese Windows Server Version, bzw. der IIS 6.0 im Zusammenhang mit dem Application Pool einfach Bullshit ist.

Hat vielleicht jemand eine nächsthöhere günstige Windows Server 2008 Enterprise Version abzugeben, insofern dort nicht das gleiche Problem ebenfalls vorhanden ist?

Gruss, René

Danke für den Hinweis.
Linux kommt nicht in Frage.
Ich programmiere und entwickle Software-Lösungen im Microsoft Bereich, darum will ich nicht auf eine neue Plattform wechseln.

Gruss, René