WEB- Proxy hängt mehrmals täglich

Squid? Gibt's auf der UTM schon ewig nicht mehr...

Ja votet ruhig, dafür ist das Feature Portal ja da! Aber ob sich das auch alles technisch so umsetzen lässt, muss man erstmal sehen. Und ganz ehrlich, Tricke-Bytes... dann kommt der Nächste um die Ecke und meckert wo denn der Download-Fortschritt einzusehen ist...

Wg. den Hintergrund-Programmen, die Updates ziehen die dann fehlschlagen: Ist es da dann nicht Sache der Anwendung, eine anständige Fehlermeldung zu schmeißen die den URL enthält? Der Proxy kann schlecht für jeden Request mehrere Zeilen (pre/post-request) loggen, das würde alles übelster Art aufblähen und wg. der Parallelität noch undurchsichtiger machen. *Eigentlich* macht der HTTP-Proxy hier schon alles richtig und zeigt die Downloder-Page in Abhängigkeit des User-Agent an (nur gängige, grafische Browser). Dass diverse Programme da halt gerne faken, da kann ja die UTM nix dafür.

Und was der Proxy tatsächlich gerade tut irgendwie im GUI sichtbar machen, das geht aus Performancegründen absolut nicht! Und jeder will doch gute Performance?

Wg. den Hintergrund-Programmen, die Updates ziehen die dann fehlschlagen: Ist es da dann nicht Sache der Anwendung, eine anständige Fehlermeldung zu schmeißen die den URL enthält?

Ja, wäre schön, nur welche Anwendung macht es in dieser Konstellation? Ich habe noch keine kennen gelernt. Aus Sicht des automatischen Update-Prozesses wird eine HTTP-Verbindung aufgebaut, es kommt aber nicht das gewünschte Ergebnis. Na und? Kann ja ne temporäre Störung sein, warum also dem Anwender melden? Wird der Versuch, das Update herunter zu laden, in Kürze wiederholt...mit dem geschilderten Ergebnis.

Natürlich ist es der Extremfall, dass der 1. Downloadversuch noch nicht mal komplett heruntergeladen wurde und nach einer Minute bereits der nächste Versuch unternommen wird und sich dann alles aufsummiert. Gibt aber auch fehlgeschlagene Versuche, wo mehrmals täglich immer wieder ein paar hundert MByte runtergeladen werden. Die Anwender am PC, die die eigentlichen Verursacher sind, merken davon ja nichts, wie auch. Internet ist dann halt mal wieder langsam.

Aber als Admin wäre eine Übersicht über die vergangenen Downloads Gold wert. Man sieht auf eine Blick, dass wieder ein Firefox- oder Thunderbird-Update von verschiedenen PCs herunter geladen wurde oder immer wieder vom gleichen PC. Man sieht, wer für große Downloads zuständig ist, was heruntergeladen wird, usw. Dann hat man wenigstens die Möglichkeit, zu erkennen, ob Exceptions am HTTP-Proxy nötig sind oder den Anwendern mal auf die Finger geklopft werden muss.

Der Proxy kann schlecht für jeden Request mehrere Zeilen (pre/post-request) loggen, das würde alles übelster Art aufblähen und wg. der Parallelität noch undurchsichtiger machen. *Eigentlich* macht der HTTP-Proxy hier schon alles richtig und zeigt die Downloder-Page in Abhängigkeit des User-Agent an (nur gängige, grafische Browser). Dass diverse Programme da halt gerne faken, da kann ja die UTM nix dafür.

Und was der Proxy tatsächlich gerade tut irgendwie im GUI sichtbar machen, das geht aus Performancegründen absolut nicht! Und jeder will doch gute Performance?

Der HTTP-Proxy soll ja nicht alles loggen, übertreiben bringt uns hier nicht weiter. Schau Dir das aktuelle Logfile an. Da steht dermaßen viel drin, da wäre eine weitere Zeile pro Download, der über http://passthrough.fw-notify.net/ geleitet wird ja nun wirklich kein Problem. Und von der echten Reporting-Engine, die einmal täglich läuft, kann sowas auch hervorragend ausgewertet und visualisiert werden.

In dem ganzen Thread fordert niemand, das Logging des HTTP-Proxys aufzublasen. Die erwähnten und vorgeschlagene Änderungen sind doch in der Praxis, wenn man sich aktuellen Logfile-Größen anschaut,  verschwindend gering, nicht wahr?

MfG
Manuel

Wg. den Hintergrund-Programmen, die Updates ziehen die dann fehlschlagen: Ist es da dann nicht Sache der Anwendung, eine anständige Fehlermeldung zu schmeißen die den URL enthält?

Ja, wäre schön, nur welche Anwendung macht es in dieser Konstellation? Ich habe noch keine kennen gelernt. Aus Sicht des automatischen Update-Prozesses wird eine HTTP-Verbindung aufgebaut, es kommt aber nicht das gewünschte Ergebnis. Na und? Kann ja ne temporäre Störung sein, warum also dem Anwender melden? Wird der Versuch, das Update herunter zu laden, in Kürze wiederholt...mit dem geschilderten Ergebnis.

Natürlich ist es der Extremfall, dass der 1. Downloadversuch noch nicht mal komplett heruntergeladen wurde und nach einer Minute bereits der nächste Versuch unternommen wird und sich dann alles aufsummiert. Gibt aber auch fehlgeschlagene Versuche, wo mehrmals täglich immer wieder ein paar hundert MByte runtergeladen werden. Die Anwender am PC, die die eigentlichen Verursacher sind, merken davon ja nichts, wie auch. Internet ist dann halt mal wieder langsam.

Aber als Admin wäre eine Übersicht über die vergangenen Downloads Gold wert. Man sieht auf eine Blick, dass wieder ein Firefox- oder Thunderbird-Update von verschiedenen PCs herunter geladen wurde oder immer wieder vom gleichen PC. Man sieht, wer für große Downloads zuständig ist, was heruntergeladen wird, usw. Dann hat man wenigstens die Möglichkeit, zu erkennen, ob Exceptions am HTTP-Proxy nötig sind oder den Anwendern mal auf die Finger geklopft werden muss.

Der Proxy kann schlecht für jeden Request mehrere Zeilen (pre/post-request) loggen, das würde alles übelster Art aufblähen und wg. der Parallelität noch undurchsichtiger machen. *Eigentlich* macht der HTTP-Proxy hier schon alles richtig und zeigt die Downloder-Page in Abhängigkeit des User-Agent an (nur gängige, grafische Browser). Dass diverse Programme da halt gerne faken, da kann ja die UTM nix dafür.

Und was der Proxy tatsächlich gerade tut irgendwie im GUI sichtbar machen, das geht aus Performancegründen absolut nicht! Und jeder will doch gute Performance?

Der HTTP-Proxy soll ja nicht alles loggen, übertreiben bringt uns hier nicht weiter. Schau Dir das aktuelle Logfile an. Da steht dermaßen viel drin, da wäre eine weitere Zeile pro Download, der über http://passthrough.fw-notify.net/ geleitet wird ja nun wirklich kein Problem. Und von der echten Reporting-Engine, die einmal täglich läuft, kann sowas auch hervorragend ausgewertet und visualisiert werden.

In dem ganzen Thread fordert niemand, das Logging des HTTP-Proxys aufzublasen. Die erwähnten und vorgeschlagene Änderungen sind doch in der Praxis, wenn man sich aktuellen Logfile-Größen anschaut,  verschwindend gering, nicht wahr?

MfG
Manuel

Hi Kai

Ich muss da vorerst mal Mario recht geben - mit einer UTM220 alles scannen zu wollen bis einer scansize von 1GB is - ehm - eher unüblich, und kann ggf. - je nach Nutzung der verfügbaren Bandbreite und Anzahl Benutzer - schon mal zu Problemen führen.

Dennoch anbei mal ein paar Tipps aus der Praxis:
Wenn die Box mal grad lahm oder ausgelastet scheint, log dich per SSH auf die Konsole ein, gib den Befehl "top" ein und drücke die 1 (damit er beide CPU's anzeigt). Du kannst im top dann oben die %wa Anzeige beobachten. Unter Minimallast/Leerlauf sollte das 0 sein. Wenn der Load auf der Box steigt, kann das schon mal eine Weile etwas darüber liegen. Wenn %wa dauernd >10...20% liegt, dürftest Du bereits eine Verlangsamung spüren, weil Prozesse auf Disk I/O warten (was z.Bsp, eben passieren kann, während ein 1GB File auf Viren gescannt wird, und das meinetwegen ein Linux .iso mit hunderten oder tausenden von Archiven ist...) oder extrem viel geloggt wird. Liegt %wa im top über mehrere Minuten >50%, dann ist die von Dir eingestellte Konfiguration (z.Bsp. Dual AV scan, IDS/IPS, Logging, Reporting etc.) für die Appliance Hardware zuviel, und Du solltest darüber nachdenken I/O lastige Dinge wie Logging, Reporting, Anzahl AV Scanner und Scansize herunterzusetzen, das Disk Caching vom Proxy zu deaktivieren, oder eine grössere Appliance zu verwenden.

Bei den Appliances beobachte ich heutzutage oft, dass CPU praktisch nie das Problem ist, Arbeitsspeicher hat sich auch beruhigt, man kann sogar mit den 2GB bestückten UTM's wieder arbeiten, selbstwenn etwas geswappt wird, aber die Disks scheinen oft zu Bottleneck zu werden. Die UTM schreibt und liest soviel dank reporting, logging, caching, AV scans etc., dass selbst die verbauten SATA Disks gelegentlich nicht mehr nachkommen. Da ist dann eine grössere Appliance mit einem RAID System, oder Software auf eigener Hardware mit RAID System mit Cache oder SSD's extrem performant, so dass %wa praktisch kaum mehr über 0 hinauskommt [[:D]][[:D]]

(Anmerkung am Rande: Sophos bringt soweit ich weiss voraussichtlich Ende Q1/Anfang Q2 übrigens neue Hardware Revisionen heraus. Da sollen dann auch bei den 1xx, 2xx und 3xx wesentlich performantere Modelle verfügbar sein sein mit mehr Memory, schnelleren Disks (ggf. sogar SSD's) usw. Konkrete Details habe ich aber auch noch keine zu dem Thema). Lass Dich da überraschen - ggf. gibts dann in 2-3 Monaten mal ein interessantes Trade-In Angebot auf ne neue, pfeilschnelle Appliance. 

Betr.:"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."

==> Höre da auf den Supoprt...ältere Versionen hatte verschiedentlich performancerelevante Bugs drin - insbesondere die Version 9.1 konnte anfangs leider nicht durch Ressourcennutzung, Stabilität und Performance glänzen, was sich mit den aktuelleren Versionen glücklicherweise nun normalisiert hat. Beim Support gilt am besten "nicht fragen - machen...". Die Jungs und Mädels lösen dort tagtäglich nur Probleme - dafür sind Sie schliesslich da...die werden schon einen Grund haben, wenn die Zugriff benötigen oder aktuelle Firmwares empfehlen [;)]

Betr.:"In dem ganzen Thread fordert niemand, das Logging des HTTP-Proxys aufzublasen. Die erwähnten und vorgeschlagene Änderungen sind doch in der Praxis, wenn man sich aktuellen Logfile-Größen anschaut, verschwindend gering, nicht wahr*

==> Am Besten ist natürlich, wenn man einen Problemclient zur Hand hat, weil man da live mitloggen kann
In der 9.2 wird das Logging übrigens ausführlicher. Ich finde insbesondere den SNI Support interessant, weil nun in den Logs auch ohne aktiven SSL scanning nicht nur IP Adressen, sondern die Hostnamen aus dem Zertifikat angezeigt werden. Das vereinfacht insbesondere bei HTTPS exceptions die Arbeit. Zudem kann man nun im transparenten Modus auch oft die SSL exceptions anstelle der "transparent skiplist" nutzen, was ich persönlich cool finde.

Übliche sonstige verdächtige bei den erwähnten Updatern gibt es viele. Mir wären jetzt die erwähnten Firefox oder Chrome updates, oder auch die Linux Updates (Ich nutze Mint mit .deb Paketen) nie negativ aufgefallen.

Problemkinder sind irgendwie:
- HP und Dell Client Software Updater auf Rechnern sowie z.T. deren "Downloader" auf deren Webseites können Dir auch die Haare aufstellen.
- Sun JAVA
- Adobe Updater (die Leute können echt NICHT programmieren...)
- z.T. Updater von AV Produkten wie Kaspersky, Norman, McAffee etc.
- Netzwerkfähige Geräte die Firmwares o.ä. downloaden können wie SMartTV's, NAS etc. Bei mir ist in der Verganenheit mal ein Synology Update Amok gelaufen, weil die IDS/IPS den Download irgendwo um 60...80% abgeschossen hat.

Und meine ganz besonderen "Freunde" sind Produkte wie Skype, Dropbox oder Evernote - insbesondere mit aktiviertem SSL Scanning, weil die ohne Extrawürste auch Amok laufen. Skype via Socks Proxy, Evernote und Dropbox benötigen Einträge in der transparent skiplist, wo grössere Amazon AWS Netzwerkblöcke ausgeschlossen werden müssen, damit die überhaupt laufen. 

Da muss man dann ggf. Ausnahmen erstellen

Um die konkreten "Schuldigen" aufzudecken bleibt Dir nicht viel übrig ausser die Logfiles zu durchsuchen. 

Am Besten ist natürlich, wenn man einen Problemclient zur Hand hat, weil man da live mitloggen kann

Die ganzen
"Connection timed out"
"web request blocked" ohne gescheiten Grund
und die SSL Warnmeldungen wie "Failed to verify server certificate" oder "SSL_ERROR_SYSCALL" etc.

sind gute Anlaufstellen um mit der Suche anfangen...

Ich muss da vorerst mal Mario recht geben - mit einer UTM220 alles scannen zu wollen bis einer scansize von 1GB is - ehm - eher unüblich, und kann ggf. - je nach Nutzung der verfügbaren Bandbreite und Anzahl Benutzer - schon mal zu Problemen führen.

Bei ca. 20 Anwendern, einer durchschnittlichen CPU-Auslastung tagsüber unter 40% (eher 20-30%), aktivierem HTTPS-Proxy, IDS, VPN, E-Mail-Proxy, Verschlüsselung, RED, WLAN reicht ein UTM 220-Cluster völlig aus.

Wenn alle paar Stunden mal ein großer Download gemacht wird (500 MByte- 1GByte eher alle paar Tage), dann muss ich die Firewall nicht auf diese Extrem-Situationen auslegen sondern bei Hochlast eben entsprechende Wartezeiten in Kauf nehmen. Das verkraftet eine UTM 220 hier schon seit ca. 3 Jahren völlig problemlos.

Schwierig wird es erst durch die beschriebenen Problemfälle, die sich aber durch entsprechend saubere Verteilung auf verschiedene Threads mit entsprechenden Nice-Leveln alle lösen lassen. Selbst wenn mehrere iso-Images gleichzeitig gezogen werden kann man auf einer UTM 220 gut arbeiten. Ja, der Virenscan dauert dann halt länger, aber im Normalfall sind selbst diese Extremsituationen überhaupt nicht zu bemerken! Im schlimmsten Normalfall ist der HTTP-Proxy etwas langsamer, der Paketfilter arbeitet währenddessen aber mit max. Geschwindigkeit weiter.

Nur ich als Admin sehe im WebAdmin die hohe Auslastung der Internet-Leitungen sowie die daran anschließende hohe CPU-Belastung. So what? Wenn wir diese Downloads hier stündlich machen wollen und Scan-Zeiten im Sekundenbereich bräuchten, ja, dann wäre eine UTM 220 tatsächlich etwas unterdimensioniert. Aber zeitkritisch ist hier nichts. Nicht akzeptabel ist nur bei bestimmten Downloads, dass der HTTP-Proxy nach ca. 5-10 Minuten nach Beginn des AV-Scanns plötzlich keine Anfragen mehr beantwortet.

Dennoch anbei mal ein paar Tipps aus der Praxis:
Wenn die Box mal grad lahm oder ausgelastet scheint, log dich per SSH auf die Konsole ein, gib den Befehl "top" ein und drücke die 1 (damit er beide CPU's anzeigt). Du kannst im top dann oben die %wa Anzeige beobachten. Unter Minimallast/Leerlauf sollte das 0 sein. Wenn der Load auf der Box steigt, kann das schon mal eine Weile etwas darüber liegen. Wenn %wa dauernd >10...20% liegt, dürftest Du bereits eine Verlangsamung spüren, weil Prozesse auf Disk I/O warten (was z.Bsp, eben passieren kann, während ein 1GB File auf Viren gescannt wird, und das meinetwegen ein Linux .iso mit hunderten oder tausenden von Archiven ist...) oder extrem viel geloggt wird.

Diese Möglichkeiten kenne ich alle, die helfen aber bei den beiden beschriebenen Problemfällen genau *gar nichts*.

Ich habe über mehrere Jahre Active/Active-Cluster aus bis zu vier ASG 425a, Active/Active-Cluster mit zwei ASG 625, mehrere Active/Standby-Cluster mit je zwei ASG 320, zwei ASG 220 bis hin zu ASG 120 bzw. dann schon UTM 120 als Admin betreut. Ich bin Astaro ASG Certified Architect und betreute heute noch mehrere Stand-Alone-UTMs (physikalisch und virtuelle Maschinen) und UTM-Cluster.

Mit Troubleshooting und Performance-Optimierungen unter der Haube kenne ich mich zu genüge aus. Mit den Sizing-Guides habe ich mich intensiv beschäftigt und damals sogar Astaro sehr intensiv mit ins Boot geholt, weil ca. 10-15.000 surfende Anwender doch sehr spezielle Anforderungen haben. Astaro hat bei uns im Haus einiges gelernt, was für uns nicht immer sehr erfreulich war weil es schlicht zu lange gedauert hat.

Manche Fehler wurden von uns eindeutig identifiziert, von Astaro bestätigt und sind bis heute nicht gefixt (Stichwort "Concurrent Connction"-Verteilung in einer Active/Active-Cluster-Umgebung). Inzwischen wird an diesen Stellen nicht mehr auf Sophos gesetzt, leider.

Soviel zum Hintergrund.

Betr.:"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."

==> Höre da auf den Supoprt...ältere Versionen hatte verschiedentlich performancerelevante Bugs drin - insbesondere die Version 9.1 konnte anfangs leider nicht durch Ressourcennutzung, Stabilität und Performance glänzen, was sich mit den aktuelleren Versionen glücklicherweise nun normalisiert hat. Beim Support gilt am besten "nicht fragen - machen...". Die Jungs und Mädels lösen dort tagtäglich nur Probleme - dafür sind Sie schliesslich da...die werden schon einen Grund haben, wenn die Zugriff benötigen oder aktuelle Firmwares empfehlen [;)]

Wenn neue Firmware-Versionen bestätigte Fehler haben, die sich auf unsere Umgebung, Konfiguration und Mitarbeiter auswirken, dann ist mir ehrlich gesagt völlig egal, was der Support-Mitarbeiter zu neuen Firmware-Versionen sagt. Ich kann sie dann nun mal nicht einspielen. Ansonsten weiß ich selber aus jahrelanger Astaro- bzw. Sophos-Praxis-Erfahrung und als IT-Sicherheits-Fachmann, warum man so schnell wie möglich neue Updates einspielen sollte...

Betr.:"In dem ganzen Thread fordert niemand, das Logging des HTTP-Proxys aufzublasen. Die erwähnten und vorgeschlagene Änderungen sind doch in der Praxis, wenn man sich aktuellen Logfile-Größen anschaut, verschwindend gering, nicht wahr*

==> Am Besten ist natürlich, wenn man einen Problemclient zur Hand hat, weil man da live mitloggen kann
In der 9.2 wird das Logging übrigens ausführlicher. Ich finde insbesondere den SNI Support interessant, weil nun in den Logs auch ohne aktiven SSL scanning nicht nur IP Adressen, sondern die Hostnamen aus dem Zertifikat angezeigt werden. Das vereinfacht insbesondere bei HTTPS exceptions die Arbeit. Zudem kann man nun im transparenten Modus auch oft die SSL exceptions anstelle der "transparent skiplist" nutzen, was ich persönlich cool finde.

Hört sich interessant an, ich lasse mich überraschen. Zeitlich schaffe ich es leider nicht, am aktuellen Betatest teilzunehmen, insofern kommt da einiges auf mich zu. Die Feature-Liste für die 9.200 klingt jedenfalls spannend, leider habe ich noch nichts gefunden, was meine beschriebenen Probleme im Ansatz löst. Aber ich lasse mich überraschen.

Und meine ganz besonderen "Freunde" sind Produkte wie Skype, Dropbox oder Evernote - insbesondere mit aktiviertem SSL Scanning, weil die ohne Extrawürste auch Amok laufen. Skype via Socks Proxy, Evernote und Dropbox benötigen Einträge in der transparent skiplist, wo grössere Amazon AWS Netzwerkblöcke ausgeschlossen werden müssen, damit die überhaupt laufen.

Oh ja, da hast Du ein paar interessante Kandidaten erwähnt. Leider muss ich aus Sicherheitsgründen fast alles über die Proxys prügeln, die passende Konfiguration zu finden dauert manchmal etwas. Aber meistens habe ich es geschafft. Skype bleibt aber ein Problemkandidat.

Um die konkreten "Schuldigen" aufzudecken bleibt Dir nicht viel übrig ausser die Logfiles zu durchsuchen.

Ja, leider, und genau das gestaltet sich im Moment so schwierig, weil in den Logfiles zu wenig zu schwer zu finden ist.

Am Besten ist natürlich, wenn man einen Problemclient zur Hand hat, weil man da live mitloggen kann

Und da liegt ja das Problem, diese Problemkandidaten erstmal zu identifizieren. Da kommt in kleiner HTTP-Download-Request, gefolgt von hunderten anderen Log-Einträgen. Am externen Interface sieht man den Traffic reinkommen. Verursacher ist immer die IP der Firewall selbst, wer den Download ursprünglich ausgelöst hat, bleibt im HTTP-Log verborgen und muss in mühseliger Kleinarbeit per Hand gesucht werden.

Nur wenn der Download erfolgreich gelaufen ist und vom ursprünglichen Clients heruntergeladen wird, sehe ich am jeweiligen internen Interface den Traffic und im Reporting den Traffic sauber zugeordnet. In meinen beiden beschriebenen Problemfällen kommt es dazu aber gar nicht mehr, deswegen ist die Quelle ja so schwierig zu finden.

MfG
Manuel