Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 15 replies
  • Subscribers 2 subscribers
  • Views 15191 views
  • Users 0 members are here
Options
Suggested
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

Sfirm versionsinternes Update

DariusGarten

Hallo alle,

ich habe eine UTM recht frisch eingerichtet und jetzt funktioniert das versionsinterne Update von SFirm nicht mehr. Die Hotline von SFirm kann mir auch nicht mehr weiterhelfen, ausser ein paar IPs und Ports zu nennen. Der Server mit der SFirm-Installation ist jetzt von der HTTPS-Inception ausgeschlossen und die Firewall-Regel von Any, Any Ports zu SFirm-Server und andersherum aktiv. Jetzt sollte alles durchgelassen werden? Trotzdem öffnet sich nur das Fenster vom Update und es passiert nichts. Hat hier noch jemand eine Idee woran das liegen kann?

Danke und Gruß

Darius



This thread was automatically locked due to age.
Parents
  • 0

    Ich habe denke ich die Lösung...


    Unter Web Protection -> Filteroptionen -> Sonstiges

    Sind ja wie beschrieben Transparenzmodus-Ausnahmen gesetzt...Ist darunter die Option "HTTP-Verkehr für aufgeführte Hosts/Netze zulassen" aktiv?

    Vermutlich ja?!? Wenn der Haken drin ist, greifen lediglich keine Einschränkungen (URL-Filterung...) des Transparenten Webfilter!

    ABER der Verkehr geht trotzdem UNSICHTBAR!!! über den Webproxy-> Keine Einträge im Webfilter-Log dazu!


    Fazit: Der Haken muss raus und dann auf Firewallebene entsprechende Regeln dafür -> Auf Firewallebene sieht man dann auch die entsprechenden Log-Einträge.

    Gruß

  • 0 in reply to SWeissflog

    Sorry SWeissflog,

    aber das ist absoluter Unsinn. Wenn der Haken gesetzt wird, wird im Hintergrund eine automatisch Firewall Regel erstellt. Diese sieht man wenn man in der Firewall automatisch erstellte Regeln auswählt. Auch in einer solchen Regel kann man unter advanced den Log einschalten.

    Abgesehen davon würde ich das ganz anders lösen. Transparentmode Ausnahme für den Client nur als absolute Ausnahme. Ich würde hier mit kategorie - und/oder useragent basierten Ausnahmen arbeiten. Dann ist der Rest des anfragenden Clients wenigstens noch geschützt.


    vg

    mod

  • 0 in reply to mod2402

    Sorry aber Ihre Aussage ist absoluter Unsinn...Vielleicht mal explizit nachstellen mit einem Testobjekt ...

    Ich habe das gerade nochmal getan: Egal ob ich Transparenzproxy-Ausnahmen  für Quellhosts oder Zielhosts anlege und den Haken setze, es werden dafür KEINE automatischen Firewallregeln angelegt und man sieht im Firewall-Log dazu auch nichts (Was Anfragen von diesen Quellen / zu diesen Zielen auf den Webport betrifft)!

    Manchmal muß man den Webproxy explizit umgehen und folglich auf Firewallebene Ausnahmen definieren, weil kategorie - und/oder useragent basierten Ausnahmen im Webproxy bei manchen Problemen nichts bringen...

    Klar gilt: Nur das, was absolut nötig ist in eine Ausnahme...

    Gruß

  • 0 in reply to SWeissflog

    Naja was soll ich dazu sagen. In einem hatte ich mich vertan. Die automatische erstellte Firewallregel wird nur bei NAT und SSL VPN so im Regelwerk angezeigt. Ansonsten ist meine Aussage absolut korrekt. Warum diese automatisch erstellte Firewallregel nicht angezeigt wird weiß Sophos nur selber.

    Auszug aus der Onlinehilfe:

    Transparent Mode Skiplist

    Using this option is only meaningful if the Web Filter runs in transparent mode. Hosts and networks listed in the Skip transparent mode hosts/nets boxes will not be subject to the transparent interception of HTTP traffic. There is one box for source and one for destination hosts/networks. To allow HTTP traffic (without proxy) for these hosts and networks, select the Allow HTTP/S traffic for listed hosts/nets checkbox. If you do not select this checkbox, you must define specific firewall rules for the hosts and networks listed here.

    Im Firewalllog sieht man dann natürlich auch nicht die positiven Anfragen deser Regel weil standardmäßig der positiv Log für jede Regel ausgeschaltet ist. Um diese Anfragen zu sehen müsste man einen dump auf der Commandline starten.

    Da dieses Verhalten nicht unbedingt immer Vorteilhaft ist, lege ich normalerweise auch immer manuell eine Regel an. Das hat aber nichts damit zu tun das die Aussage falsch ist, das keine automatische Firewallregeln angelegt werden. Es sind nur nicht immer alle sichtbar. Vieleicht würde hier ein Featurerequest Sinn machen.

    Mit gesetztem Haken funktioniert das auf jeden Fall immer einwandfrei. Das brauche ich nicht extra nachzustellen. Wenn das nicht funktioniert stimmt etwas anderes nicht. Üblicherweise fehlt eine entsprechende Maskierungsregel. Kann aber auch ganz andere Ursachen haben.


    SFirm, Starmoney und Konsorten habe ich bei Kunden schon mehrfach frei geschaltet. Hier müssen bei eingeschalteter SSL Inspection auch Ausnahmen für die angesprochenen verschiedenen Banken gemacht werden. Mittlerweile mache ich hierfür eine Kategoriebasierte Ausnahme "Finance/banking" und schließe dort SSL Scanning und Zertifikatsüberprfung aus.

    Das funktioniert in der Regel immer. Transparentmode Ausnahmen mache ich nur wenn alles andere nicht funktioniert. Das kommt relativ selten vor. Die Quellen Ausnahme verwende ich nie, da hier alle Schutzmechanismen der Webprotection umgangen werden. Ein Trojaner freut sich wenn er so frei raus kommt ;)

    Soweit ich das im Kopf habe wird bei transparentem Zugriff der useragent nicht mitgeschickt. Useragent Ausnahmen funktionieren nur in der Standardproxy Konfiguration.  Den kann man aber eigentlich jeder Banking Software mitgeben.

    vg

  • 0 in reply to mod2402

    Genau so ist es :-)


    Warum Sophos diesen Traffic "unsichbar" über die Firewall jagt, ist mir auch schleierhaft und aus diesem Grund nehme ich standardmäßig den Haken raus und konfiguriere entsprechende Firewallregel um eine gewisse Kontrolle zu haben...den Rest sehe ich genauso...

    Der Unterschied im Standardproxymodus ist auch, dass ich dort auch andere Ports als 443 und 80 über den Proxy jagen kann (Im Transparentmodus nur 80 und 443!) 

    Der Transparentmodus hat auch noch eine weitere Einschränkung: Wird er in Verbindung mit Nutzerauthentifizierung (AD SSO) genutzt und nicht authentifizierte User geblockt, hat er ein Problem, dass wenn die erste Anfrage eines bisher nicht authentifizierten Clients auf dem https-Port die Firewall keine Authentifizierung hinbekommt...Die 1. Anfrage eines Users muss immer über Port 80 kommen, sonst kommt ein Authentifizierungsfenster im Browser...Da Sophos die Userauthentifizierung im Cache ablegt, funktionieren aber anschließend auch https-Anfragen mit Authentifizierung...


    Interessant wäre, ob das ursprüngliche SFirm Problem hier nun nachvollziehbar/gelöst ist?


    Gruß

Reply
  • 0 in reply to mod2402

    Genau so ist es :-)


    Warum Sophos diesen Traffic "unsichbar" über die Firewall jagt, ist mir auch schleierhaft und aus diesem Grund nehme ich standardmäßig den Haken raus und konfiguriere entsprechende Firewallregel um eine gewisse Kontrolle zu haben...den Rest sehe ich genauso...

    Der Unterschied im Standardproxymodus ist auch, dass ich dort auch andere Ports als 443 und 80 über den Proxy jagen kann (Im Transparentmodus nur 80 und 443!) 

    Der Transparentmodus hat auch noch eine weitere Einschränkung: Wird er in Verbindung mit Nutzerauthentifizierung (AD SSO) genutzt und nicht authentifizierte User geblockt, hat er ein Problem, dass wenn die erste Anfrage eines bisher nicht authentifizierten Clients auf dem https-Port die Firewall keine Authentifizierung hinbekommt...Die 1. Anfrage eines Users muss immer über Port 80 kommen, sonst kommt ein Authentifizierungsfenster im Browser...Da Sophos die Userauthentifizierung im Cache ablegt, funktionieren aber anschließend auch https-Anfragen mit Authentifizierung...


    Interessant wäre, ob das ursprüngliche SFirm Problem hier nun nachvollziehbar/gelöst ist?


    Gruß

Children
  • 0 in reply to SWeissflog

    Nachvollziehen konnte ich es, aber es hilft bei dem Problem nicht weiter. Der Updater bleibt in der ersten Zeile stehen. Bis auf SFirm funktioniert auch alles andere.

    Masquerading habe ich Internal (Network) -> DSL (primary address) eingestellt. Den Haken bei dem transparenten Host raus und als Firewall-Regel, dass alles von und nach SFirm darf. Log eingeschaltet und es passiert nichts in den Log-Einträgen. Wenn ich auf https://services.starfinanz.de mit dem SFirm-Server(Inet Explorer) gehe, wird auch das richtige Zertifikat angezeigt. Vielleicht gibt es bei SFirm einen Zertifikats-Cache, wo das von der Sophos gefälschte Zertifikat zwischenliegt und damit den Updater blockiert?

  • 0 in reply to DariusGarten

    Hallo Darius,

    wenn du eine Transparentmode Ausnahme eingerichtet hast läuft der Traffic nicht mehr über den Proxy. Deswegen wird für diese Kommunukation auch kein Zertifikat mehr generiert. Die Anfrage gehtr direkt über die Firewall raus. Die Maskierung sollte richtig sein.

    Eine Firewallregel von und nach SFirm macht aber auch keinen Sinn. Die Regel sollte lauet von SFIRM Host, Protokoll http/https und Ziel Internet IPV4. Wenn die drei Punkte stimmen muss es eigentlich funktionieren. Mach ddoch mal Screenshots von deiner Konfiguration ( Transparentmode Ausnahme, FirewallRegel und Maskierungsregel.

    Falls alles richtig ist schau mal mit "netstat -n" auf dem SFIRM Server nach auf welche Adressen / Ports der Server sich verbinden möchte wenn das Update gestartet wird.


    vg

    mod

  • 0 in reply to mod2402

    Hallo mod,

    bei netstat -n kann ich keine Unterschiede feststellen. Hier mal die Screenshots: 

    Gruß Darius

  • 0 in reply to DariusGarten

    Hallo Darius,

    wenn du mit "netstat -n" keinen Versuch eines Verbindungsaufbaus zum SFirm Update Server siehst bedeutet das, dass dein Server oder SFirm selber ein Problem hat. Dann kann auch nichts auf der UTM ankommen. Du müsstest mindestens einen Versuch sehen mit dem Status "time wait".

    Bitte lösche die Regel 31, die ist nicht nur überflüssig sondern grob fahrlässig.

    vg

    mod

  • 0 in reply to mod2402

    Hallo, nachdem der Server nun ein paar Mal neugestartet wurde, funktioniert es plötzlich wieder. 

    Danke für die Hilfe, ich denke es lag an dem Webfilter.