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
  • Zu 1): Hast Du evtl. am Default der max-scanning-size gedreht?

    Zu 2): gibt es eine ganz offensichtliche Lösung: Proxy nicht im transparent Mode betreiben.
  • Zu 1): Hast Du evtl. am Default der max-scanning-size gedreht?


    Ja, natürlich.

    Max. Download und max. Scanning sind jetzt beide bei 1 GByte, normalerweise läuft unsere UTM 220 damit ganz gut. Im Rahmen der Fehlersuche standen sie aber auch mal bei 200 MByte oder sogar kleiner, weiß ich nicht mehr genau.

    Da das Problem aber auch bei Downloads zwischen 50-150 MByte auftritt, war das alles keine Lösung sondern nur das Rumdoktern an Symptomen. Es sind einfach bestimmte Archiv-Downloads, die selbst bei der Einstellung "Single Scan" bei Antivirus den HTTP-Proxy nach einer Weile scheinbar dermaßen in die Knie zwingen, dass nicht nur der Scan-Thread bei 100% läuft sondern der HTTP-Proxy ebenfalls und damit alles, was über den HTTP-Proxy geht komplett hängt.

    Zu 2): gibt es eine ganz offensichtliche Lösung: Proxy nicht im transparent Mode betreiben.


    Den Zusammenhang verstehe ich nicht, kannst Du das näher erklären?

    Bei uns läuft der Proxy im Default-Modus im Transparenten Modus und unter den Proxy-Profilen im Standard Modus.

    Programme, die mit der WPAD-Geschichte nicht klar kommen oder wo man keinen Proxy konfigurieren kann, gehen trotzdem im Transparenten Modus durch den Proxy und alle anderen Clients über den Standard-Proxy auf Port 8080.

    In beiden Varianten (Proxy im Transparent- und Proxy im Standard-Modus) schaltet sich bei Downloads, die groß genug sind, der 2-stufige Download-Mechanismuss per http://passthrough.fw-notify.net/ dazuwischen, der zuerst den Downloadfortschritt anzeigt und danach die Virenprüfung.

    Automatische Update-Prozesse, egal ob sie die Proxy-Einstellungen von Windows oder selbst den WPAD-Mechanismus verwenden, haben beim Standard-Proxy doch das gleiche Problem, da für sie erkennbar irgendwas nicht funktioniert (statt des Downloads kommt die Webseite http://passthrough.fw-notify.net/, das hilft den Update-Prozessen nicht wirklich).

    Im Transparenten Modus sind die Exceptions zur Umgehung des Problems unter Umständen etwas komplizierter, aber sonst sehe ich im Transparenten Modus doch das gleiche Problem, was schon im Standard-Modus die Downloads scheinbar verhindert.

    MfG
    Manuel
  • Ja, natürlich.

    Max. Download und max. Scanning sind jetzt beide bei 1 GByte, normalerweise läuft unsere UTM 220 damit ganz gut. Im Rahmen der Fehlersuche standen sie aber auch mal bei 200 MByte oder sogar kleiner, weiß ich nicht mehr genau.

    Da das Problem aber auch bei Downloads zwischen 50-150 MByte auftritt, war das alles keine Lösung sondern nur das Rumdoktern an Symptomen. Es sind einfach bestimmte Archiv-Downloads, die selbst bei der Einstellung "Single Scan" bei Antivirus den HTTP-Proxy nach einer Weile scheinbar dermaßen in die Knie zwingen, dass nicht nur der Scan-Thread bei 100% läuft sondern der HTTP-Proxy ebenfalls und damit alles, was über den HTTP-Proxy geht komplett hängt.
    Okay. Und welches System nochmal arbeitet dank Fehlkonfiguration unter Volllast ganz normal und uneingeschränkt weiter? Jetzt bin ich aber gespannt!

    Den Zusammenhang verstehe ich nicht, kannst Du das näher erklären?

    Bei uns läuft der Proxy im Default-Modus im Transparenten Modus und unter den Proxy-Profilen im Standard Modus.

    Programme, die mit der WPAD-Geschichte nicht klar kommen oder wo man keinen Proxy konfigurieren kann, gehen trotzdem im Transparenten Modus durch den Proxy und alle anderen Clients über den Standard-Proxy auf Port 8080.

    In beiden Varianten (Proxy im Transparent- und Proxy im Standard-Modus) schaltet sich bei Downloads, die groß genug sind, der 2-stufige Download-Mechanismuss per http://passthrough.fw-notify.net/ dazuwischen, der zuerst den Downloadfortschritt anzeigt und danach die Virenprüfung.

    Automatische Update-Prozesse, egal ob sie die Proxy-Einstellungen von Windows oder selbst den WPAD-Mechanismus verwenden, haben beim Standard-Proxy doch das gleiche Problem, da für sie erkennbar irgendwas nicht funktioniert (statt des Downloads kommt die Webseite http://passthrough.fw-notify.net/, das hilft den Update-Prozessen nicht wirklich).

    Im Transparenten Modus sind die Exceptions zur Umgehung des Problems unter Umständen etwas komplizierter, aber sonst sehe ich im Transparenten Modus doch das gleiche Problem, was schon im Standard-Modus die Downloads scheinbar verhindert.


    Ganz einfach: Transparent Mode bedeutet, dass jeglicher HTTP-Verkehr durch den Proxy muss. D.h. auch HTTP von Hintergrundanwendungen etc., was dann die von Dir beschriebenen Probleme beim Updaten mit sich bringt. Für den Admin mag das verlockend einfach klingen, schön alles durchjagen. Technisch hat das aber eben genau diese (und weitere) Nachteile.

    Jetzt ist natürlich die Frage: Sollte der Admin nicht die Anwendungen kennen, die zum Einsatz kommen? Dann könnte er Exceptions anlegen. Kennt er sie nicht, könnte er sie ganz aussperren. Oder er erlaubt jeglichen HTTP-Traffic und jagt nur die User-Browser durch einen Proxy im Standard Mode... Es gibt mehrere Optionen/Lösungen/Sichtweisen.

    Was erwartest Du da dieser Stelle von der UTM?
Reply
  • Ja, natürlich.

    Max. Download und max. Scanning sind jetzt beide bei 1 GByte, normalerweise läuft unsere UTM 220 damit ganz gut. Im Rahmen der Fehlersuche standen sie aber auch mal bei 200 MByte oder sogar kleiner, weiß ich nicht mehr genau.

    Da das Problem aber auch bei Downloads zwischen 50-150 MByte auftritt, war das alles keine Lösung sondern nur das Rumdoktern an Symptomen. Es sind einfach bestimmte Archiv-Downloads, die selbst bei der Einstellung "Single Scan" bei Antivirus den HTTP-Proxy nach einer Weile scheinbar dermaßen in die Knie zwingen, dass nicht nur der Scan-Thread bei 100% läuft sondern der HTTP-Proxy ebenfalls und damit alles, was über den HTTP-Proxy geht komplett hängt.
    Okay. Und welches System nochmal arbeitet dank Fehlkonfiguration unter Volllast ganz normal und uneingeschränkt weiter? Jetzt bin ich aber gespannt!

    Den Zusammenhang verstehe ich nicht, kannst Du das näher erklären?

    Bei uns läuft der Proxy im Default-Modus im Transparenten Modus und unter den Proxy-Profilen im Standard Modus.

    Programme, die mit der WPAD-Geschichte nicht klar kommen oder wo man keinen Proxy konfigurieren kann, gehen trotzdem im Transparenten Modus durch den Proxy und alle anderen Clients über den Standard-Proxy auf Port 8080.

    In beiden Varianten (Proxy im Transparent- und Proxy im Standard-Modus) schaltet sich bei Downloads, die groß genug sind, der 2-stufige Download-Mechanismuss per http://passthrough.fw-notify.net/ dazuwischen, der zuerst den Downloadfortschritt anzeigt und danach die Virenprüfung.

    Automatische Update-Prozesse, egal ob sie die Proxy-Einstellungen von Windows oder selbst den WPAD-Mechanismus verwenden, haben beim Standard-Proxy doch das gleiche Problem, da für sie erkennbar irgendwas nicht funktioniert (statt des Downloads kommt die Webseite http://passthrough.fw-notify.net/, das hilft den Update-Prozessen nicht wirklich).

    Im Transparenten Modus sind die Exceptions zur Umgehung des Problems unter Umständen etwas komplizierter, aber sonst sehe ich im Transparenten Modus doch das gleiche Problem, was schon im Standard-Modus die Downloads scheinbar verhindert.


    Ganz einfach: Transparent Mode bedeutet, dass jeglicher HTTP-Verkehr durch den Proxy muss. D.h. auch HTTP von Hintergrundanwendungen etc., was dann die von Dir beschriebenen Probleme beim Updaten mit sich bringt. Für den Admin mag das verlockend einfach klingen, schön alles durchjagen. Technisch hat das aber eben genau diese (und weitere) Nachteile.

    Jetzt ist natürlich die Frage: Sollte der Admin nicht die Anwendungen kennen, die zum Einsatz kommen? Dann könnte er Exceptions anlegen. Kennt er sie nicht, könnte er sie ganz aussperren. Oder er erlaubt jeglichen HTTP-Traffic und jagt nur die User-Browser durch einen Proxy im Standard Mode... Es gibt mehrere Optionen/Lösungen/Sichtweisen.

    Was erwartest Du da dieser Stelle von der UTM?
Children
  • Okay. Und welches System nochmal arbeitet dank Fehlkonfiguration unter Volllast ganz normal und uneingeschränkt weiter? Jetzt bin ich aber gespannt!


    Was soll das denn jetzt? Wir wollen doch auf einem ernsthaften Niveau bleiben, die Frage ist in der gestellten Form doch überflüssig. Wollen wir das Problem einkreisen und lösen oder auf ein anderes Niveau abgleiten?


    Fehlkonfiguration meinerseits ist noch überhaupt nicht geklärt und warum sollte in einer Multithreaded-Umgebung der Virenscan-Thread gleich alle anderen Threads mit anhalten? Der HTTP-Proxy läuft doch auch mit mehreren Threads. Dann dauert der Virenscan-Thread bei ein paar "unglücklich" aufgebauten Downloads halt länger, aber ein Grund den HTTP-Proxy komplett zum Stehen zu bringen ist das ja wohl nicht.



    Ganz einfach: Transparent Mode bedeutet, dass jeglicher HTTP-Verkehr durch den Proxy muss. D.h. auch HTTP von Hintergrundanwendungen etc., was dann die von Dir beschriebenen Probleme beim Updaten mit sich bringt. Für den Admin mag das verlockend einfach klingen, schön alles durchjagen. Technisch hat das aber eben genau diese (und weitere) Nachteile.


    Genau das ist der Sinn eines transparenten Proxys, dass alles auf den üblichen HTTP-Port da durchgeht. Wie soll ich das Problem denn lösen? Proxy nur im Standard-Modus laufen lassen und alle Browser, die entsprechend konfiguriert sind, nutzen den und Port 80 über Paketfilter komplett öffnen, damit alle anderen Geräte ungeprüft Downloads machen können? 

    Jetzt ist natürlich die Frage: Sollte der Admin nicht die Anwendungen kennen, die zum Einsatz kommen? Dann könnte er Exceptions anlegen. Kennt er sie nicht, könnte er sie ganz aussperren. Oder er erlaubt jeglichen HTTP-Traffic und jagt nur die User-Browser durch einen Proxy im Standard Mode... Es gibt mehrere Optionen/Lösungen/Sichtweisen.


    Aus bestimmten Gründen funktioniert das hier in unserer Umgebung nicht. Näheres dazu per PM, wenn Interesse besteht.

    Zum Problem mit automatischen Downloads: Das Problem, was ich letztens hatte, die Chrome-Updates, liefen sogar über den Standard-Proxy. Trotzdem ist das Problem aufgetreten, der Chrome-Autoupdater bekommt die zweistufige-Webseite zu sehen, bricht das Update ab, wartet eine Minute und startet es erneut. Das ging so lange, bis ich die Ursache gefunden habe und für das Chrome-Update eine Ausnahme vom Virenscan definiert habe.

    Was erwartest Du da dieser Stelle von der UTM?


    Habe ich doch schon geschrieben:

    1. Eine Liste der Downloads, die über den Proxy angestoßen wurden (vergangene und aktuelle)

    2. Zweistufige Weiterleitung über http://passthrough.fw-notify.net/ weglassen, statt dessen mit Trickle-Bytes arbeiten und den Download für den jeweiligen Download-Prozeß komplett transparent (damit ist nicht der Proxy-Modus gemeint) anbieten.

    3. Laufende Downloads abbrechen, denn das Browser-Fenster http://passthrough.fw-notify.net/ geschlossen wird(oder eben der Update-Prozeß beendet wird) . Im Moment läuft der Download bis zum Ende weiter, wird geprüft und erst dann irgendwann wieder verworfen.

    4. Aktuell laufen Virenscans irgendwo sichtbar machen, um wenigstens herauszufinden, welcher Download das System hängen lässt.

    Gibt wahrscheinlich noch mehr Ideen, oder nicht?

    MfG
    Manuel
  • Also ich werde jetzt mal nicht in die Tiefe gehen, aber zuerst einmal:

     Habe ich doch schon geschrieben:

    1. Eine Liste der Downloads, die über den Proxy angestoßen wurden (vergangene und aktuelle)

    2. Zweistufige Weiterleitung über http://passthrough.fw-notify.net/ weglassen, statt dessen mit Trickle-Bytes arbeiten und den Download für den jeweiligen Download-Prozeß komplett transparent (damit ist nicht der Proxy-Modus gemeint) anbieten.

    3. Laufende Downloads abbrechen, denn das Browser-Fenster http://passthrough.fw-notify.net/ geschlossen wird(oder eben der Update-Prozeß beendet wird) . Im Moment läuft der Download bis zum Ende weiter, wird geprüft und erst dann irgendwann wieder verworfen.

    4. Aktuell laufen Virenscans irgendwo sichtbar machen, um wenigstens herauszufinden, welcher Download das System hängen lässt.

    Gibt wahrscheinlich noch mehr Ideen, oder nicht?

    MfG
    Manuel


    Diese Ideen finde ich persönlich sehr gut! Feature Requests und du hast meine Votes (wenn ich noch welche habe).


     Okay. Und welches System nochmal arbeitet dank Fehlkonfiguration unter Volllast ganz normal und uneingeschränkt weiter?


    Trollvottel hat schon Recht, denn 1 GB große Dateien auspacken, scannen etc. dafür ist die UTM nicht ausgelegt. Das war schon einmal gefordert und das nehme ich auch immer als Beispiel, da wird eine 220er nicht ausreichen. Schaut auch mal auf die Sizing Guideline, allein was mit den Durchsätzen passiert.
    Fragen dazu, warum sollen so große Dateien gescannt werden, Schadprogramme wollen schnell verbreitet werden und sind möglichst klein und wegen dieser Tatsache wird nicht alles gescannt.


     Der HTTP-Proxy läuft doch auch mit mehreren Threads. Dann dauert der Virenscan-Thread bei ein paar "unglücklich" aufgebauten Downloads halt länger, aber ein Grund den HTTP-Proxy komplett zum Stehen zu bringen ist das ja wohl nicht. 


    Wenn so große Dateien gescannt werden, wird Performance benötigt, Prozesse warten auf Ressourcen, dann kann das sicherlich auch vorkommen, dass es abstürzt, auch wenn es definitiv nicht wünschenswert ist! Warum der jetzt hängt, kann ich natürlich letztendlich nicht beantworten, vielleicht wäre dies ein Ticket wehrt [;)]


    Ich tippe eher auf Pattern-Updates, die die UTM während der "Hänger" installiert. Falls es zu störend ist, kannst Du mal versuchen ein höheres Pattern-Up2Date Intervall im WebAdmin einzustellen, z.B. nur alle 12h.


    Ja, das glaube ich auch, vor allem, wenn gerade Scans laufen.
    Schau doch mal ins Log, ob es während den Problemen, Signaturupdates installiert wurden.

    Ich habe aber mit der Version aus dem Grunde gefragt, da es ein Issue (Prefered Master) gibt, der auch mit der Installation von Updates (Signaturen) zu tun hat. Glaube auch nicht, dass es der Grund ist, aber auf Grund der Erfahrungen, haben wir häufig seltsame Probleme feststellen können.
    Habe es mal hier beschrieben: http://www.astaro.org/254656-post11.html
    Hat auch etwas gedauert, bis wir das bei vielen Umgebungen geändert haben und festgestellt haben, dass diverse Probleme danach weg waren (auch wenn es ne Neuinstallation des Slaves zur Folge hatte).

    Nice greetings
  • Also ich werde jetzt mal nicht in die Tiefe gehen, aber zuerst einmal:

    Diese Ideen finde ich persönlich sehr gut! Feature Requests und du hast meine Votes (wenn ich noch welche habe).


    Mache ich demnächst mal!


    Trollvottel hat schon Recht, denn 1 GB große Dateien auspacken, scannen etc. dafür ist die UTM nicht ausgelegt. Das war schon einmal gefordert und das nehme ich auch immer als Beispiel, da wird eine 220er nicht ausreichen.


    Doch, doch, die UTM 220 reicht aus. Hier werden öfters diverse iso-Images gezogen, läuft völlig problemlos. Auch andere Downloads, die zwischen 500 MByte und 1 GByte liegen, werden ohne den HTTP-Proxy anzuhalten gescannt. Manchmal dauert es natürlich ein bisschen, aber die Sachen liegen intern doch eh auf der Festplatte und werden langsam abgearbeitet. Die durchschnittliche CPU-Belastung liegt tagsüber unter 40%. Natürlich gibt es immer mal kurze Spitzen, aber schlimm wird es nur, wenn man wieder einer der speziellen Downloads dabei ist oder eben ein automatischer Update-Download dutzende Male angestossen wird, weil er mit der zweistufigen Download/Virenprüfung nicht klar kommt und ich die dafür nötige Exception noch nicht eingetragen habe. Ist aber zum Glück nicht täglich, aber die Suche nach der Ursache, wenn es mal wieder soweit ist, gestaltet sich im Moment halt extrem schwierig.

    Das beschriebene Problem ist auch nur sekundär von der Dateigröße abhängig. Es gibt auch Downloads, die nur 50 MByte groß sind und dieses spezielle Problem triggern. Und ich kann die max. Downloadgröße ja schlecht auf weniger als 50 MByte setzen!


    Wenn so große Dateien gescannt werden, wird Performance benötigt, Prozesse warten auf Ressourcen, dann kann das sicherlich auch vorkommen, dass es abstürzt, auch wenn es definitiv nicht wünschenswert ist! Warum der jetzt hängt, kann ich natürlich letztendlich nicht beantworten, vielleicht wäre dies ein Ticket wehrt [;)]


    Ich werde mit einer Handvoll Download-Beispiele auch wieder ein Ticket öffnen, bin nur vom letzten Mal noch genervt, weil sich das ewig in die Länge gezogen hat und Terminabsprachen mehrmals nicht eingehalten wurden (Sophos muss auf unsere Firewall rauf) und dann abgebrochen wurde, weil ich noch nicht die aktuellste Firmware drauf hatte.


    Ich habe aber mit der Version aus dem Grunde gefragt, da es ein Issue (Prefered Master) gibt, der auch mit der Installation von Updates (Signaturen) zu tun hat. Glaube auch nicht, dass es der Grund ist, aber auf Grund der Erfahrungen, haben wir häufig seltsame Probleme feststellen können.
    Habe es mal hier beschrieben: http://www.astaro.org/254656-post11.html
    Hat auch etwas gedauert, bis wir das bei vielen Umgebungen geändert haben und festgestellt haben, dass diverse Probleme danach weg waren (auch wenn es ne Neuinstallation des Slaves zur Folge hatte).


    Hatte die Installation von Pattern-Updates auch mal im Verdacht und die schließlich auf einmal täglich eingestellt, das Download-Problem ist davon aber unabhängig immer noch aufgetreten. Ich schau mir den Link morgen noch mal an, muss jetzt Feierabend machen.

    MfG und auch einen schönen Feierabend
    Manuel