This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

WEB- Proxy hängt mehrmals täglich

Hallo,

ich habe das problem, das unser WEB- Proxy manchmal mehrmals täglich hängt. In den log's finde ich eine Menge von dem nachstehenden Eintrag:
2014:01:27-19:01:28 GATE-2 httpproxy[6630]: id="0003" severity="info" sys="SecureWeb" sub="http" request="(nil)" function="sc_check_servers" file="scr_scanner.c" line="818" message="server 'cffs07.astaro.com' access time: 268ms"

Was soll mir die Meldung sagen? Hat jemand eine idee wie ich das Problem beseitigen kann?

Viele Grüße
Kai


This thread was automatically locked due to age.
Parents

  • Was soll mir die Meldung sagen? Hat jemand eine idee wie ich das Problem beseitigen kann?


    Zwei Ideen habe ich dazu bzw. folgende Probleme treten hier regelmäßig auf:

    1.

    Meine erste Anfrage zu diesem Problem an den Support wurde dermaßen zögerlich bearbeitet, dass ich keine rechte Lust habe, das noch mal zu melden. Das Problem konnte auf anderen Firewalls bei Sophos nicht nachvollzogen werden, tritt hier aber auch nach einer vollständigen Neuinstallation mit den gleichen Downloads immer wieder reproduzierbar auf.

    Beliebter Kandidat sind Downloads, die weitere Archive beinhalten, bevorzugt Java-Entwicklungsumgebungen oder Linux-Downloads. Dabei ist es egal, ob die Dateien nur 100 MByte oder 1 GByte groß sind.

    Das Problem tritt während des Virenscans auf. Der Scan beginnt und nach ca. 5-10 Minuten bleibt plötzlich der HTTP-Proxy stehen, in dessen Kontext der Virenscan abläuft. Der HTTP-Proxy ist erst wieder ansprechbar, wenn der Virenscan dann nach 20-30 Minuten fertig ist.

    Ein Neustart des HTTP-Proxy hilft nur bedingt, weil der Download für den Mitarbeiter dann verloren ist und er den Download einfach neu anstößt, mit dem gleichen Ergebnis. Da das Problem mit dem hängenden HTTP-Proxy erst nach 5-10 Minuten nach Beginn des Virenscans auftritt, kann der Mitarbeiter das auch nur schwer miteinander in Zusammenhang bringen. Der Admin ist dann immer Schuld.

    2.

    Automatisierte Downloads, die im Hintergrund durch automatische Update-Prozesse angestoßen werden und über den Proxy und Virenscan laufen.

    Wenn man über den Browser einen Download macht, wird man ja auf die Fortschrittsseite weitergeleitet, wo man den Downloadfortschritt und den Virenscan beobachten kann.

    Wenn ein automatisches Update im Hintergrund (z.B. Chrome-Update) auf diese Proxy-Seite läuft, kann der Update-Prozess damit natürlich nichts anfangen und denkt, der Download ist schief gegangen. Also wird nach einer gewissen Wartezeit der Update-Download erneut versucht.

    So hat ein einziger Rechner hier mal fast 50 Chrome-Update-Downloads angestoßen. Noch bevor der 1. Download im Proxy erfolgt ist, wurde bereits der 2. Download angestoßen, weil der erste ja aus Sicht des Update-Prozesses irgendwie schief gegangen ist. Und so haben sich dann nach und nach etliche aktive Downloads und dutzende Virenscans in der Warteschlange gesammelt, woraufhin der HTTP-Proxy dann auch irgendwann quasi eingefroren ist.

    Hier hilft es nur, diese Update-Webseiten vom Virenscan über entsprechende Exceptions rauszunehmen.

    Die Suche nach diesen Downloads gestaltet sich extrem schwierig, weil von den internen Rechnern nur ein einziger kurzer Download-Request im Web-Log zu sehen ist, mehr nicht. Bei mehreren Dutzend gleichzeitig surfenden Mitarbeitern geht das völlig unter. Am WAN-Interface kann man dann den hohen Traffic des Downloads beobachten, man kann aber nicht herausfinden, wer der Verursacher ist, weil der Download ja nicht erfolgreich in ein internes Subnetz heruntergeladen wird. Verursacher ist immer nur der HTTP-Proxy selbst. Auf der SSH-Console sieht man im tmp-Verzeichnis vom HTTP-Proxy nur die Downloads, die sich immer weiter ansammeln. Aber auch da sieht man nicht, wer den Download ursprünglich angestoßen hat. Leider werden auch nicht die originalen Dateinamen verwendet, so dass man auch darüber keine Möglichkeit hat, den Download-Request im Web-Log zu finden.

    Eine Liste der aktuellen und vergangenen Datei-Downloads oder eine Liste der aktuell vom Virenscanner gescannten Dateien wird nirgendwo angezeigt. Beides wäre schon eine große Hilfe, um solche Probleme zu finden oder einzukreisen.

    MfG
    Manuel
Reply

  • Was soll mir die Meldung sagen? Hat jemand eine idee wie ich das Problem beseitigen kann?


    Zwei Ideen habe ich dazu bzw. folgende Probleme treten hier regelmäßig auf:

    1.

    Meine erste Anfrage zu diesem Problem an den Support wurde dermaßen zögerlich bearbeitet, dass ich keine rechte Lust habe, das noch mal zu melden. Das Problem konnte auf anderen Firewalls bei Sophos nicht nachvollzogen werden, tritt hier aber auch nach einer vollständigen Neuinstallation mit den gleichen Downloads immer wieder reproduzierbar auf.

    Beliebter Kandidat sind Downloads, die weitere Archive beinhalten, bevorzugt Java-Entwicklungsumgebungen oder Linux-Downloads. Dabei ist es egal, ob die Dateien nur 100 MByte oder 1 GByte groß sind.

    Das Problem tritt während des Virenscans auf. Der Scan beginnt und nach ca. 5-10 Minuten bleibt plötzlich der HTTP-Proxy stehen, in dessen Kontext der Virenscan abläuft. Der HTTP-Proxy ist erst wieder ansprechbar, wenn der Virenscan dann nach 20-30 Minuten fertig ist.

    Ein Neustart des HTTP-Proxy hilft nur bedingt, weil der Download für den Mitarbeiter dann verloren ist und er den Download einfach neu anstößt, mit dem gleichen Ergebnis. Da das Problem mit dem hängenden HTTP-Proxy erst nach 5-10 Minuten nach Beginn des Virenscans auftritt, kann der Mitarbeiter das auch nur schwer miteinander in Zusammenhang bringen. Der Admin ist dann immer Schuld.

    2.

    Automatisierte Downloads, die im Hintergrund durch automatische Update-Prozesse angestoßen werden und über den Proxy und Virenscan laufen.

    Wenn man über den Browser einen Download macht, wird man ja auf die Fortschrittsseite weitergeleitet, wo man den Downloadfortschritt und den Virenscan beobachten kann.

    Wenn ein automatisches Update im Hintergrund (z.B. Chrome-Update) auf diese Proxy-Seite läuft, kann der Update-Prozess damit natürlich nichts anfangen und denkt, der Download ist schief gegangen. Also wird nach einer gewissen Wartezeit der Update-Download erneut versucht.

    So hat ein einziger Rechner hier mal fast 50 Chrome-Update-Downloads angestoßen. Noch bevor der 1. Download im Proxy erfolgt ist, wurde bereits der 2. Download angestoßen, weil der erste ja aus Sicht des Update-Prozesses irgendwie schief gegangen ist. Und so haben sich dann nach und nach etliche aktive Downloads und dutzende Virenscans in der Warteschlange gesammelt, woraufhin der HTTP-Proxy dann auch irgendwann quasi eingefroren ist.

    Hier hilft es nur, diese Update-Webseiten vom Virenscan über entsprechende Exceptions rauszunehmen.

    Die Suche nach diesen Downloads gestaltet sich extrem schwierig, weil von den internen Rechnern nur ein einziger kurzer Download-Request im Web-Log zu sehen ist, mehr nicht. Bei mehreren Dutzend gleichzeitig surfenden Mitarbeitern geht das völlig unter. Am WAN-Interface kann man dann den hohen Traffic des Downloads beobachten, man kann aber nicht herausfinden, wer der Verursacher ist, weil der Download ja nicht erfolgreich in ein internes Subnetz heruntergeladen wird. Verursacher ist immer nur der HTTP-Proxy selbst. Auf der SSH-Console sieht man im tmp-Verzeichnis vom HTTP-Proxy nur die Downloads, die sich immer weiter ansammeln. Aber auch da sieht man nicht, wer den Download ursprünglich angestoßen hat. Leider werden auch nicht die originalen Dateinamen verwendet, so dass man auch darüber keine Möglichkeit hat, den Download-Request im Web-Log zu finden.

    Eine Liste der aktuellen und vergangenen Datei-Downloads oder eine Liste der aktuell vom Virenscanner gescannten Dateien wird nirgendwo angezeigt. Beides wäre schon eine große Hilfe, um solche Probleme zu finden oder einzukreisen.

    MfG
    Manuel
Children
No Data