WEB- Proxy hängt mehrmals täglich

Wer nano nutzt, installiert auch Ubuntu ...

Eher gentoo!

Eher gentoo!

Wenn wir schon mal OT sind...

*OT ON*

Na ja, nix gegen gentoo. Aber ich mag nicht von Null anfangen, habe weder Lust noch Zeit mich mit Partitionierung, Bootloadern, mounten und fstab, Paketen und blabli blablub rumschlagen...Ich lebe ja nicht auf der Konsole und bin kein Ober Linuxer. Nutze das aus Prinzip und Spass Zuhause, das wars dann schon.

Mit Mint oder ggf. auch mal ner anderen Distro hab ich in 10Minuten ein installiertes Desktop System das funktioniert, und als höchstes der Gefühle kommt vielleicht noch ein aktueller Mainline Kernel drauf anstelle der meist veralteten Kernel die bei den Distros dabei sind.

Gentoo oder Arch sind toll, wenn ich von Null auf ein ultra-customized System aufbauen will ohne den unnötigen Ballast, den die Desktop Distros halt so mit sich bringen.

Na ja. [:D]

*OT OFF*

*OT ON*
Ich erwähnte gentoo deshalb, weil im doch recht umfangreichen Installations-Howto ausschließlich nano zum Einsatz kommt :-)
*OT OFF*

BTW: Dies ist inzwischen ein ultimativer Hijack-Thread.

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

Gentoo? Die Gentoo Leute trauen sich doch nur net an LFS!
Und noch einer: Wer Ubuntu als Server nutzt, trinkt auch geschmolzene Cappucino Schokolade ...


Fazit: Die I/O Performance können wir nicht "erkundigen" und die "manuelle" exkursion wird weiterhin mangels Zeit in den meisten Fällen nicht erfolgen ...

Klinke mich hier auch mal ein:
Wir haben zwei 320er im HA A/P laufen. V8.309 - das ist die Version, die scheinbar am stabilsten läuft. Mit allen neuren 8er Versionen gabs Probleme.
Wir haben auch seit ca 1 Monat und seit 1 Woche verstärkt das Problem, dass wir auch mit mehreren Aussetzern, Freezes der Boxen kämpfen. Das sieht teilweise so aus, dass 
man nicht mal mehr auf den Webadmin kommt. Im Log sehe ich zu den Problemzeiten ebenfalls, die gleichen Meldungen wie der Themenstarter:
 sys="SecureWeb" sub="http" request="(nil)" function="sc_check_servers" file="scr_scanner.c

Seit dem wir die Maschinen im Cluster laufen lassen, hat sich die Problematik gefühlt verdreifacht. Wir machen dann einen Master/Slave Switch und dann gehts erstmal wieder.
Einmal mussten wir den hängenden Master sogar ausschalten, weil man nicht mal mehr mit SSH drauf kam.

Config:
Webfilter: Standardmodus, +HTTPS
AV: Dual 100mb
Streaming scan: off
Application Control (nur default Regeln)
Anzahl Anfragen pro Tag: ca 500.000, also schon etwas mehr.

Mailproxy
AV: dual
Mails die der pro Tag verarbeiten muss: 

Das Problem ist immer ein CPU Problem.
Gestern mussten wir wieder einen Clusterswitch machen. Danach bin ich per SSH drauf und hab TOP den ganzen Tag mitlaufen lassen. Später gab es wieder einen kurzen Hänger. TOP hat gezeigt, dass der postgres Prozess mit 100% CPU Last lief. Also nix mit Antivirus oder so. Die Maschine legt sich zumindest teilweise durch interne Verwaltung lahm - tagsüber!

Also ich würde, um es erst mal so schnell wie möglich als Ursache ausschließen zu können, das Reporting massiv zurück fahren (1 Tag) oder testweise ganz ausschalten.

Wenn das nicht geholfen hat, mal eine Web-Filter Exception definieren, dass das normale Logging im HTTP-Proxy abgeschaltet wird. Dann sieht man auch, ob sich da irgendein Festplatten-Performance-Problem eingeschlichen hat.

IDS wird verwendet? Wenn ja, wie viele Regeln sind aktiv? Wie sieht das Logfile aus, wird da auch vel geloggt oder passiert da nicht so viel?

MfG
Manuel

IDS - meinst du IPS / Angriffschutz? Haben wir nicht aktiv. Wir haben auch keine Firewallregeln aktiv.
Das das der Oberperformancekiller ist, habe ich auch schon oft gelesen.

Beim Reporting habe ich nun alles, was nicht benötigt wird, deaktiviert und alles andere von 6 Monaten auch 1 Woche reduziert.
Bedeutet das nun, dass ich diese Berichte hier nicht mehr auf einen Monat ausdehnen kann oder was konkret? In der Hilfe wird darauf nicht genauer eingegangen.

Hier ein aktueller TOP Bericht: postgres 99% CPU

top - 13:57:52 up 13 days, 26 min,  1 user,  load average: 0.91, 0.39, 0.37

Tasks: 157 total,   2 running, 154 sleeping,   0 stopped,   1 zombie

Cpu(s): 49.5%us,  2.0%sy,  0.3%ni, 47.8%id,  0.2%wa,  0.0%hi,  0.2%si,  0.0%st

Mem:   2023472k total,  1812332k used,   211140k free,    23820k buffers

Swap:  2100816k total,   943728k used,  1157088k free,   575112k cached



  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND

12290 postgres  20   0  121m  94m  29m R   99  4.8   0:08.72 postgres

 5092 root      20   0  2580 1000  616 S    1  0.0 129:28.81 lcd4linux

 6058 root      20   0 11392 3868 1404 S    1  0.2  51:38.35 selfmonng.plx

 7343 httpprox  20   0 1906m 599m 5964 S    1 30.3 226:37.82 httpproxy

10179 root      39  19 29780  23m 3812 S    1  1.2   0:00.57 gen_inline_repo

13863 postgres  20   0 49960  36m  35m S    1  1.9   4:56.41 postgres

  272 root      20   0     0    0    0 S    0  0.0   2:12.94 kswapd0

 6910 root      20   0  7832 3324  932 S    0  0.2   2:47.99 named

 7241 root      20   0 63188  31m  11m S    0  1.6  61:53.97 ctasd

 8217 afcd      19  -1 76228 8360 2484 S    0  0.4   5:19.64 afcd

11649 root      20   0 37316  15m 1772 S    0  0.8   3:39.13 smtpd.bin

und schon wieder:

top - 14:03:08 up 13 days, 31 min,  1 user,  load average: 0.74, 0.44, 0.38

Tasks: 158 total,   2 running, 155 sleeping,   0 stopped,   1 zombie

Cpu(s): 51.5%us,  3.5%sy,  0.0%ni, 40.4%id,  4.5%wa,  0.0%hi,  0.2%si,  0.0%st

Mem:   2023472k total,  1852452k used,   171020k free,    29888k buffers

Swap:  2100816k total,   943780k used,  1157036k free,   567912k cached



  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND

12817 postgres  20   0  149m 115m  29m R   99  5.8   0:08.88 postgres

12837 root      20   0 56460  22m 1472 D    3  1.1   0:00.09 confd.plx

12595 root      20   0 40976  22m 6192 S    1  1.1   0:01.16 smtpd.bin

 5092 root      20   0  2580 1000  616 S    1  0.0 129:31.23 lcd4linux

 7241 root      20   0 63188  31m  10m S    1  1.6  61:58.88 ctasd

 2415 root      20   0  2600 1104  796 R    0  0.1   0:11.69 top

 5924 postgres  20   0 46896  33m  33m S    0  1.7   2:01.64 postgres

und nocheinmal - diesmal cssd - was macht der denn?

top - 14:23:04 up 13 days, 51 min,  1 user,  load average: 2.94, 0.92, 0.48

Tasks: 158 total,   3 running, 151 sleeping,   0 stopped,   4 zombie

Cpu(s): 75.2%us, 11.8%sy,  0.0%ni,  0.0%id, 11.6%wa,  0.0%hi,  1.3%si,  0.0%st

Mem:   2023472k total,  1967356k used,    56116k free,    15392k buffers

Swap:  2100816k total,   581164k used,  1519652k free,   540332k cached



  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND

15233 root      20   0  294m 228m 1584 R   98 11.6   0:08.05 cssd

 7343 httpprox  20   0 1887m 746m 5148 S   67 37.8 227:54.08 httpproxy

 5092 root      20   0  2580 1000  616 R    1  0.0 129:40.22 lcd4linux

 7241 root      20   0 63188  31m  10m S    1  1.6  62:08.45 ctasd

    8 root      20   0     0    0    0 S    0  0.0   4:07.60 events/1

  272 root      20   0     0    0    0 S    0  0.0   2:13.16 kswapd0

 6058 root      20   0 11392 3896 1404 S    0  0.2  51:43.25 selfmonng.plx

 8199 root      39  19  8572 2392 1272 S    0  0.1   7:54.01 snmpd

11674 root      20   0 39152  10m 1356 S    0  0.5   0:40.36 smtpd.bin

IDS - meinst du IPS / Angriffschutz? Haben wir nicht aktiv. Wir haben auch keine Firewallregeln aktiv.
Das das der Oberperformancekiller ist, habe ich auch schon oft gelesen

Ja, sorry, IDS/IPS ist für mich inzwischen immer das gleiche. Sophos nennt es halt "Intrusion Prevention".

Es kann bei falscher Konfiguration ein ordentlicher Performance-Fresser sein, aber wenn man damit etwas vorsichtig umgeht, sinnvolle Regeln auswählt und nötige Exceptions erstellt, läuft es auch auch auf einer UTM 220 mit mehreren Internetleitungen und ein paar Dutzend internen Interfaces (per VLAN getrennt) erstaunlich gut. Es ist allerdings auch immer mal wieder eine interessante Quelle ansonsten eher ominöser Fehler, weil man nicht über alle erkannten Angriffsmuster per E-Mail informiert wird. Manches findet sich nur direkt im Logfile, wo man eben immer wieder mal nachschauen muss.

Beim Reporting habe ich nun alles, was nicht benötigt wird, deaktiviert und alles andere von 6 Monaten auch 1 Woche reduziert.
Bedeutet das nun, dass ich diese Berichte hier nicht mehr auf einen Monat ausdehnen kann oder was konkret? In der Hilfe wird darauf nicht genauer eingegangen.

Wie gesagt, zum schnellen Test mal komplett ausschalten und für einen Tag beobachten. Eigentlich wirkt sich das dann nur auf alle erweiterten Such- und Analysemöglichkeiten unter "Logging & Reporting" aus. Da kann man bei kürzeren Haltezeiten eben weniger ausführlich, dafür aber schneller suchen. Die Aufbereitung dieser Daten unter der Haube ist aber eben auch aufwendig.

Das tägliche, wöchentliche, monatliche Reporting ist davon nicht betroffen. Das basiert auf den eigentlichen Logfiles und wird meines Wissens nicht so oft angestoßen.

MfG
Manuel

Gerade habe ich wieder einen der klassischen Hänger gehabt. "Nichts geht mehr". Webadmin nicht erreichbar.
Irgendwann kam er dann und zeigt 80% CPU Load an. Dieser Wert hat sich auch die nächste Minute auf einem hohen Niveau gehalten.
Mein parallel laufendes TOP hat aber nichts der gleichen gemeldet! Wie kann es sein, dass der Webadmin CPU Last sieht, von der TOP nichts sieht?