WEB- Proxy hängt mehrmals täglich

Ich mag micht täuschen, aber das mit dem Trickle-Bytes war schon mal im Voting. Allerdings machen einige Hersteller, inkl. Sophos, öfters gern das Späßle und schiebens auf Squid.

Ebenso das Thema performance reporting: keine i/o Tools (iotop), keine Bandbreitentools (iptraf) ... das sind keine Extrawürste, das gehört auf so ein Gerät. Oder eine entsprechende Management API.

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

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...

Der war gut ... [:$]

top und die Logs liefern bei gleichzeitigen Scan von Archiven und Pattern exakt welche Aufklärung? Antwort: Keine! 

Auf der UTM fehlen die üblichen Standardtools aus den Distributionen, welche die I/O Last anzeigen. Übliche Kunden werden an Dienstleister verwiesen, da sie mit den Vorschlägen vom Support nichts anfangen können und ärgern sich dann über die Kosten, trotz Premiumsupport, denn bei einem Load > 15 arbeitet auch der Sophos Support nicht mehr!

Die Rückmeldungen an den Support bleiben wohl im QM Ordner kleben. Die FeatureRequests gehen unter oder werden abgelehnt.

Das liegt nur an einem: Das Konzept der UStM lässt es wohl nicht zu.

Perfekte und sehr informative Antwort! 
Ganz herzlichen Dank Sascha für diesen Post!

Das mit den neuen Hardware Revisionen war jetzt schon häufiger das Thema, aber da hat sich Sophos (verständlicherweise) etc. bis Dato sehr bedeckt gehalten und nichts zu gesagt, daher schon interessant.

Den Dual Scan mit 1GB großen ISOs, nutze ich nur, damit ich ich meine Home UTM mal ordentlich belaste um den Stromverbrauch bei Vollast zu messen [;)] [:D]

Nice greetings

Hallo K.N.

Der war gut ... [:$]

top und die Logs liefern bei gleichzeitigen Scan von Archiven und Pattern exakt welche Aufklärung? Antwort: Keine! 

Auf der UTM fehlen die üblichen Standardtools aus den Distributionen, welche die I/O Last anzeigen.

 

Relevante Tools wie tcpdump, espdump, vmstat, iftop. plus Linux Bordwerkzeuge wie top usw. sind drauf und helfen beim troubleshooting diverser issues meistens schon weiter. Die UTM ist nun mal kein Wunschkonzert, wo sich jeder mal seine Lieblingstools installiert kriegt, nur weil er sie so toll findet. Ich weiss auch, dass es noch einige weitere Tools gibt, oder z.Bsp. auch bessere Alternativen zu tcpdump und top etc. An sich ist die Konsole ausgelegt, dass der Support damit arbeiten kann, der Zugriff der Benutzer ist an sich - auch wenn möglich - theoretisch nicht vorgesehen, und ganz bestimmt nicht mit den convinience Tools der Linuxbenutzer ausgestattet. Ich finde einen nano als Editor auch einfacher wie vi, aber manchmal muss man mit den Gegebenheiten leben...

Übliche Kunden werden an Dienstleister verwiesen, da sie mit den Vorschlägen vom Support nichts anfangen können und ärgern sich dann über die Kosten, trotz Premiumsupport, denn bei einem Load > 15 arbeitet auch der Sophos Support nicht mehr!

Wenns nicht von nem Bug herrührt, ist bei einem Load >15 die Appliance schlichtwegs falsch dimensioniert. Da ist jede Liebesmüh vom Support nutzlos...mit einigen Tricks und Tweaks mag man den Load etwas runterbringen, aber damit zu arbeiten macht selbst danach keinen Spass. Richtige Appliancegrösse hinstellen, dann klappts auch mit dem Nachbarn ;o))

Die Rückmeldungen an den Support bleiben wohl im QM Ordner kleben. Die FeatureRequests gehen unter oder werden abgelehnt.
Das liegt nur an einem: Das Konzept der UStM lässt es wohl nicht zu.

Da sind wir wieder beim Wunschkonzert. Auch ich habe über die Jahre sowohl intern wie auch via Feature Request wahrscheinlich >100 Featurewünsche und Anpassungen abgegeben. Manche sind umgesetzt worden, manche dümpeln vor sich hin, weil es aus entweder PM Sicht keinen Sinn macht, oder weil kein Mensch im Feature Portal dafür voten will (siehe Link in meiner Signatur), oder weil bisher einfach keine Ressourcen dafür bereitgestellt werden konnten. Unter der schieren Anzahl Feature Requests >1000 sind einerseits mehrere hundert in den letzten Jahren umgesetzt worden, manche die Sinn machen sind noch nicht umgesetzt worden, und wieder andere Requests wie die Unterstützung für einen Regensensor oder anpassbare Farbe vom GUI sind zwar witzig, machen aber vermutlich wenig Sinn [[;)]]

Daher - ich bin manchmal zwar auch zynisch, aber ohne eine zugehörige gesunde Portion Humor wird man damit in der IT nicht glücklich [[;)]]

Wenns nicht von nem Bug herrührt, ist bei einem Load >15 die Appliance schlichtwegs falsch dimensioniert. Da ist jede Liebesmüh vom Support nutzlos...mit einigen Tricks und Tweaks mag man den Load etwas runterbringen, aber damit zu arbeiten macht selbst danach keinen Spass. Richtige Appliancegrösse hinstellen, dann klappts auch mit dem Nachbarn ;o))

Und hier haben wir wieder das klassische Thema des Sizings und ich reite mal wieder auf die aktuelle Sizing Guideline rum, mit der Bitte, analysiert was im Netz passiert und nicht "einfach" nur Benutzer zählen und gut ist. Denkt auch daran, dass die UTM für X Jahre genutzt werden soll und nicht schon mit dem nächsten Software Update und nutzen einer weiteren Funktion überfordert ist. Dieses Thema sehe ich täglich und ärgere mich häufig über falsches Sizing (am falschen Ende gespart).
Ich schweife von Thema ab...

Nice greetings

Mit was kann ich die I/O Last prüfen?

Was hat die Dimensionierung mit dem (Ausreißer-) Load zu tun? 

CPU idle, Maschine swapped nicht und bei 

CPU idle, Maschine swapped nicht und bei 

Nur ganz kurz, da es nicht zum Thema gehört, aber genau das ist das Problem. Was machen die User? Das ist viel wichtiger, als die Anzahl!
Ja, auch bei