[Sammelthread] Sophos UTM-Sammelthread

[besterino]

...und Microsoft auch.

Aber klar, dass muss jeder für sich selbst entscheiden. Ich vertrau da halt lieber den Jungs und Mädels von MS/VMware die den Hypervisor coden, vertreiben, professionell supporten und den ganzen Tag nichts anderes machen, als sich um dessen Sicherheit, Performance und Zuverläsdigkeit zu kümmern.

Oder eben die NIC an eine Xpenology-VM durchreichen, weil das sicherer ist... (Achtung: Stilmittel der Übertreibung!)

 

[fdsonne]

Ein durchgereichtes PCIe Gerät ist eine offene Tür zum Host. VMware selbst rät vom Einsatz in kritischen Bereichen ab.

Das schon klar... Aber das Risiko über die durchgereichte VM "auszubrechen" ist aus meiner Sicht geringer, als sich am Stack des Hypervisors versuchen zu können!
Warum? Einfach aus dem Grund, bei MS aka Hyper-V hängt die Kiste im LAN, ist über die MAC mindestens mal ansprechbar, je nachdem, wo du her kommst und was für Möglichkeiten bestehen. Bei VMware und anderen (also nicht MS based) gilt das genau so, meist ist das System grundsätzlich aber als "Sicher" einzustufen. 100% Sicherheit gibts nicht, egal wie rum man das dreht und wendet.
-> ist die NIC aber durchgereicht, kommst du ausschließlich über den Networkstack der Guest-VM überhaupt angreifen... Das sollte dann nun nicht vllt ein MS Windows Server sein -> Linux mit aktuellem Patchlevel, eine NIC mit aktuellem Patchlevel bei den Treibern -> und die Tür ist im Rahmen der Möglichkeiten der reagierenden Fraktion einfach "zu"...


NIC Durchreichen selbst geht ja "nur" dort überhaupt auf, wo man die NIC nicht sharen will... Das sollte noch bedacht werden. Das man grundsätzlich seitens der Hersteller dagegen empfielt, halt also zwangsweise noch andere Gründe...

@besterino
nur kommt eigentlich kein normaler Mensch bei halbwegs Sachverstand auf die wahnwitzige Idee, einen MS Windows Server public ins Netz zu klemmen... Das ist halt das "Risiko" bei Hyper-V.
Wobei ich ehrlich gesagt so oder so kein "Fan" von Hyper-V bin. Ist irgendwie für mich nix... Ich bleib bei der Fraktion VMware...

 

[Killer Chris]

Leider kenne ich noch Firmen, die ein TMG an vorderster Front im Einsatz haben...
Zumindest keine normale Windows Firewall, aber immer noch MS Basis.

 

[Fr3@k]

Sacht mal, seit WANN muss man bei einer WAF Freigabe eines Webservers nach außen hin für die Kommunikation der UTM zum internen Webserver eine Firewall Regel auf der UTM schreiben???

Also das hatte ich bis jetzt noch nie - vermute eher einen BUG oder irgendetwas anderes als Ursache (Fehler in der Config, etc.)
Mir wäre auch nicht bekannt dass da etwa geändert wurde in diese Richtung.

 

[VirtuGuy]

Das schon klar... Aber das Risiko über die durchgereichte VM "auszubrechen" ist aus meiner Sicht geringer, als sich am Stack des Hypervisors versuchen zu können!

Bei korrekter Konfiguration bleibt keine Angriffsfläche übrig. Seit 5-6 Jahren hätte ich diesbezüglich bei den einschlägigen Veranstaltungen nichts mehr gehört, hier gibt es praktisch nur noch Vorträge/Demos von Angriffen von der VM auf den Host.

Warum? Einfach aus dem Grund, bei MS aka Hyper-V hängt die Kiste im LAN, ist über die MAC mindestens mal ansprechbar, je nachdem, wo du her kommst und was für Möglichkeiten bestehen. Bei VMware und anderen (also nicht MS based) gilt das genau so, meist ist das System grundsätzlich aber als "Sicher" einzustufen. 100% Sicherheit gibts nicht, egal wie rum man das dreht und wendet.

Aktuell schenken sich Microsoft und VMware diesbezüglich nicht viel. Rein von der Anzahl an Patchen die wir verteilen hat VMware doch deutlich mehr Baustellen.

Probleme entstehen bei beiden insbesondere bei schlechter Konfiguration oder nachlässigen Patchmanagement. Ein "paar" extreme Beispiele dazu findet man hier: https://www.shodan.io/search?query=path=/vsphere-client

@besterino
nur kommt eigentlich kein normaler Mensch bei halbwegs Sachverstand auf die wahnwitzige Idee, einen MS Windows Server public ins Netz zu klemmen... Das ist halt das "Risiko" bei Hyper-V.
Wobei ich ehrlich gesagt so oder so kein "Fan" von Hyper-V bin. Ist irgendwie für mich nix... Ich bleib bei der Fraktion VMware...

Wir haben ein ganze Datacenter mit HV/VMware/KVM im Netz, bei korrekter Konfiguration ist derartiges kein Problem.

 

[Olaf16]

Ja das ist immer so eine Frage. Eine Zeit lang hatte ich es so gehandhabt: Modem --> FW auf Baremetal --> 1x direkt in die DMZ, 1x an eine VM (Meist auch eine andere FW) die dann nochmal ins LAN absichert. Wer durch die 1. Firewall kam, den würde dann eine 2. FW meist auch nicht mehr aufhalten, egal ob VM oder nicht...
Selber würde ich nie Produktiv (Egal ob Geschäftlich oder Privat) eine VM als FW hernehmen direkt nach außen - AUßer davor ist eben ein normaler Router mit einigen Portweiterleitungen oder eben eine normale FW auf Baremtal.
Ich möchte der Sophos jedoch aus Testgründen das Zeug direkt weitergeben, da ich dadurch direkt Kontrolle über das Zeug in der Sophos habe und nicht noch die Hypervisor Schicht. Auf der neuen Spielkiste läuft das Zeug net richtig, wie ich im anderen Thread herausgefunden hab, da M$ das mit dem Passthrough anders regelt als ESXi z. B.

Naja... Dann eben doch wsl. nur vSwitche :/

 

[fdsonne]

Bei korrekter Konfiguration bleibt keine Angriffsfläche übrig. Seit 5-6 Jahren hätte ich diesbezüglich bei den einschlägigen Veranstaltungen nichts mehr gehört, hier gibt es praktisch nur noch Vorträge/Demos von Angriffen von der VM auf den Host.

Doch bleiben... Und das schlimme ist, die sind ja unbekannt. Sonst hätte man diese geschlossen...
Irgendwie hab ich das Gefühl, du willst mich nicht verstehen.
Es geht dabei nicht um Konfigurationsthemen (die kommen on top -> vieles ist aber einfach selten dämlich), es geht dabei um Angriffsfläche durch Security Bugs. Nur weil "keine" Patches kommen, heist das lange nicht, dass es nichts gibt. Nur weil nix bekannt ist, ebenso nicht. DAS ist das Problem.
Dem entgegen stellt man sich wiederum, wenn man versucht den Weg soweit zuzudrehen, dass sowas gar nicht passieren kann. Ein Übergriff "über" den Virtualisierungslayer auf den Host ist das gleiche, nur in anderer Ausführung. Geht man davon aus, dass das Safe ist -> so wie du ja oben offenbar für den anderen Ansatz, ist das Risiko zu 100% identisch gut/schlecht.

Unsinnig ist aber aus meiner Sicht sich da was vorzumachen... Bspw. indem man annimmt, dass man über den Virtualisierungslayer aus/einbrechen kann, über den anderen Weg aber nicht.

Wir haben ein ganze Datacenter mit HV/VMware/KVM im Netz, bei korrekter Konfiguration ist derartiges kein Problem.

Du/ihr habt bis jetzt nichts bemerkt und deswegen ist das "kein Problem" oder was macht dich/euch da so sicher??

Also das hatte ich bis jetzt noch nie - vermute eher einen BUG oder irgendetwas anderes als Ursache (Fehler in der Config, etc.)
Mir wäre auch nicht bekannt dass da etwa geändert wurde in diese Richtung.

Das dachte ich allerdings auch... Komisch ist halt, dass die eine WAF Rule geht, die anderen (neuen) eben nicht...
Und noch komischer ist auch, das eben der Telnet Test von der SSH Konsole genau so fehl schlägt -> für die neuen WAF Rules.

Ich denke auch, es ist ein Bug. Bis dato hab ich aber darüber noch nix gefunden im Netz. Und das Update von 9.405 auf die aktuelle Version brachte auch keine Abhilfe... Ist halt verwunderlich.
Sieht so aus, als greife die Firewall trotzdem (was ja nur logisch wäre) -> aber er scheint für die WAF Rules keine Ausnahmen zu schreiben, die er vllt vorher (unter der Decke) selbst geschrieben hat!?

 

[VirtuGuy]

Doch bleiben... Und das schlimme ist, die sind ja unbekannt. Sonst hätte man diese geschlossen...
Irgendwie hab ich das Gefühl, du willst mich nicht verstehen.

Ich verstehe durchaus deinen Gedankengang, auf die Idee sind auch schon diverse Firmen gekommen und diese wurde in allen mir bekannten Fällen wieder verworfen. In der x86 Welt ist dies halt immer noch ein Risiko welches man besser vermeiden sollte.

Es geht dabei nicht um Konfigurationsthemen (die kommen on top -> vieles ist aber einfach selten dämlich), es geht dabei um Angriffsfläche durch Security Bugs. Nur weil "keine" Patches kommen, heist das lange nicht, dass es nichts gibt. Nur weil nix bekannt ist, ebenso nicht. DAS ist das Problem.
Dem entgegen stellt man sich wiederum, wenn man versucht den Weg soweit zuzudrehen, dass sowas gar nicht passieren kann. Ein Übergriff "über" den Virtualisierungslayer auf den Host ist das gleiche, nur in anderer Ausführung. Geht man davon aus, dass das Safe ist -> so wie du ja oben offenbar für den anderen Ansatz, ist das Risiko zu 100% identisch gut/schlecht.

Wie du schon sagst, es geht um Angriffsfläche. Bei einem durch den Hypervisor verwalteten Port gibt es keine große Angriffsfläche. Der Hypervisor bietet bei entsprechender Konfiguration nach "außen" nun mal keine Services an. Deine VM hingegen bietet ggf eine ganze Reihe von Services an und hat damit auch mehr Angriffsfläche. Von daher ist es keine gute Idee dem System mit größeren Risiko eine Tür zum Host zu öffnen.

Unsinnig ist aber aus meiner Sicht sich da was vorzumachen... Bspw. indem man annimmt, dass man über den Virtualisierungslayer aus/einbrechen kann, über den anderen Weg aber nicht.

Du/ihr habt bis jetzt nichts bemerkt und deswegen ist das "kein Problem" oder was macht dich/euch da so sicher??

Keine Sorge, ich/wir machen uns da nichts vor. Wir versuchen unser Risiko anhand der bekannten Fakten, einschlägigen Veranstaltungen und Empfehlungen der Hersteller soweit als möglich zu reduzieren.

 

[fdsonne]

Wie du schon sagst, es geht um Angriffsfläche. Bei einem durch den Hypervisor verwalteten Port gibt es keine große Angriffsfläche. Der Hypervisor bietet bei entsprechender Konfiguration nach "außen" nun mal keine Services an. Deine VM hingegen bietet ggf eine ganze Reihe von Services an und hat damit auch mehr Angriffsfläche. Von daher ist es keine gute Idee dem System mit größeren Risiko eine Tür zum Host zu öffnen.

Ich stimme dir dahingehend soweit ja zu, aber es hört doch nicht damit auf, die "Strippe" bis zur NIC zu connecten. Sondern du hast doch egal ob NIC via PT direkt an/in VM oder über den vSwitch mit Hypervisor Verwaltung, in beiden Fällen den Wunsch, eine VM mit einer IP zu betreiben... Das heist, der Angriffsvektor der sich aus dem Betreiben von Services auf dem Networkstack der VM ergibt, ist in beiden Fällen exakt identisch...
Layer 2 gehst du in beiden Fällen an die NIC, Layer 3 und drüber hast du in beiden Fällen eine public erreichbare IP mit exakt den selben Services (und Angriffsflächen)
-> der Unterschied, wenn auch recht "klein", ist einfach der, dass ohne NIC PT zur/in die VM da noch ein virtueller Switch, also ein in Software gelöstes Stück "Netzwerk" davor hängt und bei der PT Methode eben nicht... Rein vom logischen her ist das perse also ein Angriffsvektor unbekannter Höhe.

Verständnisfrage: welchen Unterschied macht das nun? Für mich ist da kein Unterschied... Wenn ich über die Services der VM IN die VM einbrechen kann und mich dort dann am Virtualisierungslayer versuche, dann ist das in beiden Fällen mit dem selben Ergebnis verbunden. Gibts Bugs (und die scheint es ja zu geben), dann komme ich da rein.
Aus meiner Sicht ist das Argument dahingehend also wenig valide... Zumindest nicht im Vergleich, ob nun NIC PT oder Hypervisor Verwaltung "sicherer" ist, denn es spielt für diese Frage schlicht keine Rolle.

Keine Sorge, ich/wir machen uns da nichts vor. Wir versuchen unser Risiko anhand der bekannten Fakten, einschlägigen Veranstaltungen und Empfehlungen der Hersteller soweit als möglich zu reduzieren.

DAS habe ich zumindest erwartet
-> wir betreiben die public Systeme auf dedizierten Public Clustern... Da läuft halt auch nix anderes, als public Stuff drauf.

 

[VirtuGuy]

Ich stimme dir dahingehend soweit ja zu, aber es hört doch nicht damit auf, die "Strippe" bis zur NIC zu connecten. Sondern du hast doch egal ob NIC via PT direkt an/in VM oder über den vSwitch mit Hypervisor Verwaltung, in beiden Fällen den Wunsch, eine VM mit einer IP zu betreiben... Das heist, der Angriffsvektor der sich aus dem Betreiben von Services auf dem Networkstack der VM ergibt, ist in beiden Fällen exakt identisch...

Layer 2 gehst du in beiden Fällen an die NIC, Layer 3 und drüber hast du in beiden Fällen eine public erreichbare IP mit exakt den selben Services (und Angriffsflächen)
-> der Unterschied, wenn auch recht "klein", ist einfach der, dass ohne NIC PT zur/in die VM da noch ein virtueller Switch, also ein in Software gelöstes Stück "Netzwerk" davor hängt und bei der PT Methode eben nicht... Rein vom logischen her ist das perse also ein Angriffsvektor unbekannter Höhe.

Wir sprechen hier von x86 Hardware wo es keine saubere Lösung für isolierten Zugriff gibt. Es ist halt einer der vielen Kompromisse die man mit dem Kram eingehen muss, man könnte es auch "broken by compatibility" nennen. Wir vergleichen also ein Problem von einem hoch optimierten Stück Software welches je nach Hersteller sogar als OSS vorliegt und einer Implementierung wo jeder Hersteller davon abrät und wo es neben den bekannten natürlich auch unbekannte Risiken gib

Verständnisfrage: welchen Unterschied macht das nun? Für mich ist da kein Unterschied... Wenn ich über die Services der VM IN die VM einbrechen kann und mich dort dann am Virtualisierungslayer versuche, dann ist das in beiden Fällen mit dem selben Ergebnis verbunden. Gibts Bugs (und die scheint es ja zu geben), dann komme ich da rein.
Aus meiner Sicht ist das Argument dahingehend also wenig valide... Zumindest nicht im Vergleich, ob nun NIC PT oder Hypervisor Verwaltung "sicherer" ist, denn es spielt für diese Frage schlicht keine Rolle.

Die VM ist in beiden Fällen direkt von außen erreichbar und das Ziel wo am wahrscheinlichsten ein Angriff funktionieren wird. Da sind wir uns ja durchaus einig.

Jetzt kommt halt die Frage - wo hat unser "Hacker" nach einem erfolgreichen Angriff auf die VM einfacher? Wenn ich alle Möglichkeiten der Isolierung ausnutze oder wenn ich der VM direkten Zugriff auf die Hardware ermögliche?

 

[fdsonne]

Jetzt kommt halt die Frage - wo hat unser "Hacker" nach einem erfolgreichen Angriff auf die VM einfacher? Wenn ich alle Möglichkeiten der Isolierung ausnutze oder wenn ich der VM direkten Zugriff auf die Hardware ermögliche?

Ja eben, das lässt sich so nur schwer beantworten bzw. definieren... Dennoch bleibe ich dabei, das allein der Zusatz der Netzwerkvirtualisierung potentiell zu einer Angriffsfläche führen kann und muss, als wenn es diese nicht geben würde. Denn nimmt man es genau, die Angriffsfläche, die die Implementation zwischen physische NIC und vSwitch bietet, unterscheidet sich dort auch nur im Details zu der von physisch (durchgereichte) NIC und Networkstack IN der VM. Bleibt also die vSwitchkonfig und dessen Angriffsfläche in unbekannter Höhe als zumindest potentieller Nachteil.

Auch stellt sich mir natürlich die Frage, ob der "Einbruch" in den Host ausgehend einer gehackten VM (über dessen angebotene Services) nun über den Networkstack erfolgt oder nicht vllt direkt über den Virtualisierungslayer... Bspw. durch irgendwelches umbiegen von Speicheradressen oder weis der Teufel was -> also völlig unabhängig, wie das auf der Netzwerkseite gelöst ist.


Für mich gilt also weiterhin, egal wie rum man es dreht und wendet. Die NIC PT "Methode", so sinnig oder unsinnig das auch ist, hat mindestens einen Teil weniger Angriffsfläche. Da sich über die potentielle Höhe der Fläche bzw. die Warscheinlichkeit des Einbrucherfolgs nur gestritten werden kann ohne das Jemand das belegen könnte (aufgrund der unbekannten Anzahl an Lücken in jeglicher Hinsicht), bleibt die Ausgangslage aus meiner Sicht wie von mir beschrieben.

PS: versteh mich nicht falsch, ich möchte bei weitem nicht behaupten, dass man NIC PT überwiegend empfehlen sollte... Allein durch die fehlende shared Möglichkeit der physischen NIC ist das für die Masse der Fälle wohl schon "raus" aus dem Fokus...
-> was mich übrigens noch interessieren würde, was ist dir über den Unterschied zwischen vSwitch und vDS bekannt? -> Hintergrund ist eigentlich, ich nutze im Moment quasi ausschließlich vSwitches. vDS kommen effektiv gar nicht zum Einsatz... Möglicherweise wird sich das aber demnächst ändern, wenn ein paar neue Hosts bei mir ankommen. Bin mir aber noch nicht so 100% sicher, ob das für mich überhaupt "lohnt". E-Plus Lizenzen samt aktiver Subscription habe ich in ausreichender Menge, "Geld" ist an der Stelle also nicht Thema...

 

[konfetti]

Ist am Ende nicht alles irgendwie ein Stück Software?
Ich hatte mir mal die Cisco Nexxus 1000V im ESXi angeschaut, an sich ganz nett, statt dem "normalen unmanaged vswitch" eben eines mit ner Cisco CLI, aber ob das am Ende sicherer ist?

Das Problem ist doch eher, das die Angreifer am Ende Zeit haben. - d.h. wenn der Angriff nicht auffällt, weil die "bad Passwords" oder was auch immer so selten kommen, das nicht als Angriff gewertet wird, wird es nicht auffallen.
Haben unsere Pentester damals auch immer gesagt, man kann nur eine Momentaufnahme mit dem aktuellen Wissen machen, was langfristig ist kann heute keiner sehen. Und die wenigsten Kunden haben die Zeit oder das Geld einen solchen langfristigen Pentest durchzuführen...

 

[fdsonne]

Das geht schon in die Richtung, wohin ich auch argumentiere... Denn das Problem sind wie gesagt die unbekannten Lücken... Und da ist es aus meiner Sicht grundsätzlich eben so, wenn mehr "Angriffsfläche" vorhanden ist, dann ist die Warscheinlichkeit zumindest potentiell höher, dass dort was durchdringt. -> deswegen so wenig wie möglich Angriffsfläche bieten. Für mich ist der vSwitch mehr Angriffsfläche (zumindest potentiell) als eine NIC via PT in die VM gereicht. Denn es kommt einfach oben drauf, dass über den vSwitch, so unwarscheinlich das auch sein mag, da was eindringen KANN... Während beim NIC PT einfach kein vSwitch vorhanden ist...
Möglicherweise auch nur über eine Kombination aus/mit anderen Angriffsvektoren oder ähnlichem.

 

[konfetti]

Naja, aber beim Einfallstor gilt ja auch - so wenig offene Türen (Ports) wie möglich ^^
kommt natürlich immer auf die Dienste an.

Ja, schade is wirklich, das man nicht dediziert einzelne Interfaces in eine VM direkt mounten kann, so das der Host sonst nix davon sieht...
Ansonsten ist es ja so, das zumindest bei pfsense eine PT-NIC weniger Last und mehr Durchsatz erzeugt, als wenn da die Virtualisierungsschicht noch dazwischen ist.

 

[TCM]

Solange in dem Switchsegment keine IP-Adresse mit irgendwelchen Diensten konfiguriert ist, beschränkt sich die Angriffsfläche auf Layer2-Frames. Wann gabs zuletzt eine Lücke in irgendwas unterhalb von IP?

 

[VirtuGuy]

Auch stellt sich mir natürlich die Frage, ob der "Einbruch" in den Host ausgehend einer gehackten VM (über dessen angebotene Services) nun über den Networkstack erfolgt oder nicht vllt direkt über den Virtualisierungslayer... Bspw. durch irgendwelches umbiegen von Speicheradressen oder weis der Teufel was -> also völlig unabhängig, wie das auf der Netzwerkseite gelöst ist.
...

Der Angreifer muss sich dazu keine Lücke mehr suchen. Mit dem durchreichen der Hardware erlaubst du ja dem Angreifer bereits gezielt den Zugriff. Genau hier liegt ja das Problem an der Implementierung von vt-d o.ä. Lösungen in der x86 Welt. Natürlich gibt es Mechanismen wie IOMMU, in der Praxis wird dem aber per Default oft schon die Basis entzogen (Secureboot,..) und auch hier gibt es diverse Ansätze um den Schutz zu umgehen. Verglichen mit einem simplen vSwitch ist die ganze Implementierung ungleich komplexer und damit gibt es auch deutlich mehr von deinen vermeintlich unbekannten Lücken.

- - - Updated - - -

Sprichst du jetzt von einem netzseitigen Angreifer oder einem, der aus der VM raus auf den Host will? Wenn er von außen auf die VM will, hat er doch erstmal nur TCP, UDP und IP und vielleicht noch Ethernet-Frames zur Verfügung. An der Stelle spielt es gar keine Rolle, wie die NIC an der VM hängt. VT-d ist so weit unten, das ist doch auf IP-Ebene gar nicht relevant.

Ausgehend von einer VM, siehe auch den zitierten Text.

 

[TCM]

Ausgehend von einer VM, siehe auch den zitierten Text.

Ja, da war ich zu schnell mit Zitieren und hab dann nur noch im Zitat gelesen, wo das andere Zitat nicht mehr drin war.

 

[fdsonne]

@TCM
ursprünglich ging es ja um die Frage, durchgereichte NIC vs. VM am vSwitch (vs. VM am vDS -> wenn man es komplettiert) -> was ist warscheinlich sicherer?
-> das der Angreifer schon IN der VM ist, war erst der zweite Gedankengang... Auf die Aussage seitens VirtuGuy bezogen, dass er ja IN der VM mehr Möglichkeiten hat.


@VirtuGuy
kennst du Lesestoff über die Thematik, WIE der Angreifer aus der gekaperten VM herraus über die PT-Implementation weiter agiert!? Das würde mich zumindest rein informativ her interessieren... Bzw. ob und in welchem Maße derartige Vektoren schon ausgenutzt wurden!?

 

[Luckysh0t]

Gibt es eigentlich ein Szenario in dem man von einem vSwitch in einen anderen vSwitch "ausbrechen" kann ?

Bsp.

WAN---NIC0--vSwitch0---vNIC0--Firewall--vNIC1---vSwitch1--NIC1----andere VM/LAN

Von vSwitch0 zu vSwitch1 und dann ins LAN/andere VM

 

[Biernot]

Hallo,
ich habe aktuell einige Komponenten von Unifi bei mir verbaut und möchte dahinter auf einem Dell T20 als VM die Sophos UTM instalieren.
Kann ich die Sophos hinter dem Unifi USG betreiben als VM betreiben oder ist es besser die Unifi USG auszubauen?
Mein Netzaufbau:
- Draytek 130 (Modem)
- Unifi USG (macht die Einwahl)
- Unifi 16 port Switch
- 3 AP
- 1 QNAP 465 pro
- 1 Office Rechner
- 1 Dell T20 (aktuell mit Server 2016 und Hyper-V)

 

[bratwurstbraeter]

Hallo Leute,

ich habe ein Problem mit den 50 IP Lizenzen in der UTM Home. Ich habe 48 Geräte(VM´s/IOT/Tabletts usw.) und komme immer wieder wenn Besuch da ist, in den Bereicht dass die Lizenzen nicht ausreichen.
Habt ihr da eine Lösung(Lizenz kaufen, ist keine Lösung!)?

Ich habe schon mal überlegt auf die XG zu wechseln. Diese hat doch die Beschränkung auf 50 IP´s nicht mehr....
Aber es gibt mir noch zu wenig Info´s zu dem Teil im Netz. Scheint noch nicht so gut anzukommen...

Die UTM Essentials Lizenz habe ich auch mal überlegt, bin mir aber nicht sicher was die alles kann, bzw. nicht kann...

Was würdet Ihr empfehlen?

 

[paulianer]

Hallo,
ich habe aktuell einige Komponenten von Unifi bei mir verbaut und möchte dahinter auf einem Dell T20 als VM die Sophos UTM instalieren.
Kann ich die Sophos hinter dem Unifi USG betreiben als VM betreiben oder ist es besser die Unifi USG auszubauen?

Ja du kannst die Sophos hinter der Unifi USG betreiben. Ob es besser oder schlechter ist musst du selbst entscheiden. Wenn die UTM den kompletten Traffic des Internets filtern sollte musst du mit doppeltem NAT arbeiten. Das ist soweit kein Problem, wird jedoch schnell fummelig wenn du Dienste (wie z.B. einen Webserver) im Internet bereitstellen willst.

Was würdet Ihr empfehlen?

Um das Problem zu entschärfen habe ich damals ein weiteres NAT im WLAN Netz eingerichtet. Zwischen UTM und WLAN Access Point lief ein kleiner IPFire und maskierte die WLAN Geräte.
Das ist leider nur praktikabel in den Netzen, in welchen du die einzelnen Geräte nicht erkennen musst. Bei mir war es das WLAN für mobile Geräte und das brachte eine Ersparnis von über 15 IPs.

 

[[SoD]r4z0r]

Moin, kennt sich einer näher mit dem VPN der Sophos aus? Bekomme im Logfile beim Verbindungsversuch folgende Fehlermeldung:

Thu Jan 12 08:51:59 2017 MANAGEMENT: >STATE:1484207519,RESOLVE,,,,,,
Thu Jan 12 08:51:59 2017 MANAGEMENT: >STATE:1484207519,TCP_CONNECT,,,,,,
Thu Jan 12 08:52:09 2017 TCP: connect to [AF_INET]192.168.xxx.xxx:443 failed, will try again in 5 seconds: Das System hat versucht, einem Verzeichnis, das sich auf einem mit JOIN zugeordneten Laufwerk befindet, ein Laufwerk mit SUBST zuzuordnen.

Hab die genaue Konfig nicht im Kopf, aber ein paar Tipps wo ich heute Abend schauen kann wären cool.

Edit sagt:
Hinsichtlich dem Netzaufbau: Die Sophos hängt hinter ner Fritze und ist dort als Exposed Host eingetragen. In der Fritze hab ich nen DynDNS konfiguriert und den entsprechenden Hostnamen im Feld Override Hostname bei der Sophos eingetragen.
Handelt sich übrigens um das SSL VPN der Sophos.

 

[DanFu]

Moin, kennt sich einer näher mit dem VPN der Sophos aus? Bekomme im Logfile beim Verbindungsversuch folgende Fehlermeldung:

Thu Jan 12 08:51:59 2017 MANAGEMENT: >STATE:1484207519,RESOLVE,,,,,,
Thu Jan 12 08:51:59 2017 MANAGEMENT: >STATE:1484207519,TCP_CONNECT,,,,,,
Thu Jan 12 08:52:09 2017 TCP: connect to [AF_INET]192.168.xxx.xxx:443 failed, will try again in 5 seconds: Das System hat versucht, einem Verzeichnis, das sich auf einem mit JOIN zugeordneten Laufwerk befindet, ein Laufwerk mit SUBST zuzuordnen.

Hab die genaue Konfig nicht im Kopf, aber ein paar Tipps wo ich heute Abend schauen kann wären cool.

Edit sagt:
Hinsichtlich dem Netzaufbau: Die Sophos hängt hinter ner Fritze und ist dort als Exposed Host eingetragen. In der Fritze hab ich nen DynDNS konfiguriert und den entsprechenden Hostnamen im Feld Override Hostname bei der Sophos eingetragen.
Handelt sich übrigens um das SSL VPN der Sophos.

Hast den Client als lokalen Admin gestartet?

 

[Vape]

Moin moin,

Is hier jemand dabei der sich gut mit der sophos utm 9 auskennt? Bräuchte dringend etwas Hilfe.

 

[paulianer]

[...]Hab die genaue Konfig nicht im Kopf, aber ein paar Tipps wo ich heute Abend schauen kann wären cool.[...]

Erreichst du die Sophos aus dem Internet problemlos? Also z.b. das Benutzerportal kannst du aufrufen?
Und der Eintrag im Log verwundert mich etwas: [AF_INET]192.168.xxx.xxx:443
Ist das die IP-Adresse welches dein WAN-Interface and er Sophos hat? Von welchem Punkt im Netzwerk versucht du auf die Sophos zuzugreifen?

Moin moin,

Is hier jemand dabei der sich gut mit der sophos utm 9 auskennt? Bräuchte dringend etwas Hilfe.

Moin!

Da das hier der Sophos Thread ist würde ich mal stark auf "Ja" tippen . Ich glaube hier schauen immer mal wieder Leute rein, welche täglich mit den Systemen arbeiten und die entsprechenden Schulungen haben.
Allerdings ist das ohne deine Fragestellung zu kennen natürlich nur geraten.

 

[Vape]

Ich hab 2 sophos am laufen. Eine extern bei nem hoster und eine daheim. Beide sind mit red verbunden. Zudem soll die externe sophos über red und bridge Modus eine weitere ip an meine home sophos weiterleiten. Hatte bisher wunderbar geklappt.
Auf einmal bekomm ich nen fehler beim link und die ip wird nicht mehr weitergeleitet.

Mir hat das mal jemand eingerichtet. Leider kenne ich mich garnicht aus und bin daher auf hilfe abgewiesen. Für jemand der sich auskennt wahrscheinlich 2 klicks

 

[Opticum]

Vape: Das Problem ist, dass die Sophos UTM nicht mit der Kabelmodem IP zurechtkommt, der Link auf einen Error läuft. Ich hatte mir das ja schon angeschaut, damals wo ich es eingerichtet hatte funktionierte es. Leider habe ich derzeit nicht die Zeit mir das weiter anzuschauen (und auch nicht mit der Art von "Druckaufbau" von dir), daher würde ich dich bitten, von weiteren Kontaktversuchen über Skype abzusehen. Vielen Dank für dein Verständnis.

Vielleicht hat hier ja auch jemand einen Kabelanschluss mit fester IPv4 und eine Sophos im Zusammenspiel und kann dir da weiterhelfen, ansonsten nochmal der Tip direkt in der Sophos Community zu fragen ob sich da jemand mit auskennt: https://community.sophos.com/

 

[Vape]

Du das war ja nicht böse gemeint. Wusste nicht das du so sensibel bist. Sry das mir da eben ein paar leute im Nacken sitzen die eben drauf warten weiter machen zu können. Das du es gleich als "Druckaufbau" siehst tut mir leid. Das war nie meine Absicht. Es kam eher so an als ob du eher dein neues system an mir testen wolltest und keiner lust hast an dem alten was zu machen... immerhin hab ich dafür bezahlt und mich zusätzlich noch von dir werben lassen das du geld bei vultr bekommst. Natürlich war das keine Zahlung für life time Support aber deine aussage "meld dich wenn was sein sollte" hat mich eben dazu bewegt mich eben zu melden...

Zudem müsstest du wissen wie "kunden" die kein plan haben reagieren wenn was nicht funktioniert. Da bitte ich dich auch um Verständnis das es nicht böse gemeint war.

- - - Updated - - -

Vape: Das Problem ist, dass die Sophos UTM nicht mit der Kabelmodem IP zurechtkommt, der Link auf einen Error läuft. Ich hatte mir das ja schon angeschaut, damals wo ich es eingerichtet hatte funktionierte es. Leider habe ich derzeit nicht die Zeit mir das weiter anzuschauen (und auch nicht mit der Art von "Druckaufbau" von dir), daher würde ich dich bitten, von weiteren Kontaktversuchen über Skype abzusehen. Vielen Dank für dein Verständnis.

Vielleicht hat hier ja auch jemand einen Kabelanschluss mit fester IPv4 und eine Sophos im Zusammenspiel und kann dir da weiterhelfen, ansonsten nochmal der Tip direkt in der Sophos Community zu fragen ob sich da jemand mit auskennt: https://community.sophos.com/

Zudem kommt ja die ip irgendwie an meiner home sophos an aber eben nicht da wo sie hin soll. Ich gehe mal davon aus das wenn der ping <1ms ist das die ip irgendwo bei mir Zuhause steckt.

 

[DanFu]

Du das war ja nicht böse gemeint. Wusste nicht das du so sensibel bist. Sry das mir da eben ein paar leute im Nacken sitzen die eben drauf warten weiter machen zu können. Das du es gleich als "Druckaufbau" siehst tut mir leid. Das war nie meine Absicht. Es kam eher so an als ob du eher dein neues system an mir testen wolltest und keiner lust hast an dem alten was zu machen... immerhin hab ich dafür bezahlt und mich zusätzlich noch von dir werben lassen das du geld bei vultr bekommst. Natürlich war das keine Zahlung für life time Support aber deine aussage "meld dich wenn was sein sollte" hat mich eben dazu bewegt mich eben zu melden...

Zudem müsstest du wissen wie "kunden" die kein plan haben reagieren wenn was nicht funktioniert. Da bitte ich dich auch um Verständnis das es nicht böse gemeint war.

- - - Updated - - -



Zudem kommt ja die ip irgendwie an meiner home sophos an aber eben nicht da wo sie hin soll. Ich gehe mal davon aus das wenn der ping <1ms ist das die ip irgendwo bei mir Zuhause steckt.

Warum gehst du nicht zu einen professionellen Anbieter?
Ich kann da die Com-sys empfehlen. Die haben mehrere Leute auf Sophos sitzen und sind recht fix!

Bedenke immer eins -> you'll get what you give