Zugriffe auf definierte Zielnetzwerke protokollieren

Betreibt Ihr ein AD?
Die UTM bietet die Möglichkeit, Web-Proxy-Zugriffe mit den AD-Zugangsdaten zu authentifizieren. Für Details iehe hier.
Wenn man damit am PC angemeldet ist, geht das sogar völlig transparent, man muß nichts eingeben.
Bei den mitgebrachten Heimgeräten (wenn sie nicht ins AD aufgenommen werden) braucht man allerdings Zugangsdaten.
So sollte sich auch rechtssicher nachweisen lassen, daß nicht nur ein bestimmtes Gerät, sondern ein bestimmter Benutzer den Zugriff ausgeführt hat.
Natürlich sollten dann Kennwörter nicht weitergegeben werden und es sollten keine generischen Accounts wie "Gast" existieren.

Hi Alan,

danke für deinen Input. Ja, wir betreiben ein AD, VPN wird bereits dagegen authentifiziert.

Die Authentifizierung für den reinen Webproxy-Zugriff hat für uns 2 Haken:

1. Hat 2/3 der Firma OSX und iOS - ich fürchte, die müßten sich dann ständig anmelden

2. Läuft ein Großteil des traffics via https - und das wird nicht auf der UTM terminiert. Das haben wir nach ziemlich viel Problemen seinerzeit recht schnell abgeschaltet - ist das heutzutage einfacher zu betreiben?

Danke & VG - Chris 

Guten Morgen,

Danke für deine Nachricht.

Ich muss mir mal eine VM mit zum testen mit dem UTM Image erstellen und werde das mit dem Anmelden mal dort ausprobieren und mich erneut mit https via squid beschäftigen. 

Am Ende würde es wohl reichen, wenn ich dessen Logs und das Packetfilter log ab un und zu wegschreibe und nur auf konkrete Anforderung des Kunden per grep nach den entsprechenden Daten suche. 

DHCP für die Clients macht allerdings nicht die Sophos, sondern 2 Windows 2022 Server im LAN bzw. für ein spezielles WLAN meine aruba-Infrastruktur, natürlich mit Reservierungen, vlans, Berechtigungen, App Erkennung, DSCP-Header mod, usw.; zwischen LAN und UTM ist aber noch eine DMZ, deshalb interner DHCP. Nach innen arbeite ich mit einer OPNsense.

Edit: Jetzt weiß ich wieder, warum wir https-WebProxy seinerzeit wieder rausgeworfen haben:

Wir hatten keine einfache Möglichkeit gefunden, die Signierungs-CA auf allen Clients (OSX, Winx, Linux, iOS, Android) und dann noch für einen ganzen Affenzoo von Browsern zu verteilen. Leider müssen wir diesen tatsächlich immer wieder nutzen, da wir viel Webentwicklung machen und stets und ständig irgendwelche tickets von Kunden kommen, was mit Browser XYZ in Version ## nicht funktioniert.
Ich schätze, es gibt aber keine andere Möglichkeit, https-Verbindungen als solche, also ohne reingucken zu wollen, wenigstens zu loggen, oder?

Sowohl dem Microsoft IAS als auch dem in den meisten anderen Fällen vermutlich verwendeten ISC DHCP kann man das in entsprechenden Logs entnehmen.
Falls es wirklich nicht anders geht kann man auch ein Tools wie ArpWatch (das jede neu "gesehene" MAC-IP-Kombination protokolliert, für IPv6 gibt es NDPmon) auf einem Server mitlaufen lassen.
Von Vorteil für längerfristige Speicherung und Analyse ist es, die Logs auf einem zentralen Syslog-Host zu sammeln.

Alternativ könnt Ihr Euer Netz auch auf eine sichere Anmeldung (z.B. zertifikatsbasiertes 802.1X) umstellen, dann sind auch gespoofte MACs usw. kein Thema mehr. Kann Windows, Linux, MacOS, iOS und inzwischen jeder bessere Netzwerkdrucker.

Zum Edit: Das MitM-Zertifikat brauchst Du nur, wenn Du in den verschlüsselten Datenstrom hineinschauen willst (z.B. zum Virenscan oder Schlüsselwortfilterung), da mache ich heutzutage Dir wenig Hoffnung.

Logging geht natürlich ohne dieses Zertifikat. Der Datenstrom wird dann unverändert weitergegeben und Du loggst nur lokale/entfernte IP, Port, den Zeitpunkt und die Zahl der Bytes - wenn Euch das ausreicht.

Zum Edit zuerst: Genau das habe ich auch gerade eingeschaltet - das ist es! Ich danke Dir.

Zum DHCP: Klar kann ich MAC <=> Ip Adresszuordnungen "von Hand" betreiben, aber 1. hasse ich es, in atemberaubendem Tempo neue Geräte in MAc Adressedatenbanken aufzunehmen und: ich habe immer wieder komplett unbekannte BYOD Geräte im WLAN (Ist von der GF auch ausdrücklich so gewünscht), deren MAC ich nicht kenne, die aber jederzeit 24/7 sich ins WLAN einbuchen können sollen.

Mein Traum wäre es, wenn ich das auf dem aruba-master hinbekäme, denn dort authentifizieren sich die user und ich sehe 1:1 welche Person was für ein Gerät gerade im WLAN hat und auf welchem AP es hängt. (Aber das ist hier das Sophos und nicht das aruba-Forum, schon klar)

Jetzt hast Du mir aber mit IAS + DHCP ein schönes Stichwort gegeben.

Der NAP dient derzeit nur als RADIUS für den aruba und für die Sophos-VPN-Zugriffe von Windows-Clients (L2tp wegen der Beschränkung der SG auf IKE v1 und dem bewußten Verzicht auf den Sophos VPN client), plain IPSEC der anderen Clients geht direkt gegen das AD und braucht keinen RADIUS.

Muss ich mir mal anschauen, was die Umstellung des DHCP mit Pre-Auth bedeuten würde. Müssen nichts MS-Clients sich dann bei jedem Re-Lease authentifizieren? Was mache ich mit dem Zoo von IoT-Geräten, die können sowas doch i.d.R. gar nicht?

Die Sophos muß nicht DHCP-Server sein. Richte sie doch als DHCP-Forwarder auf entweder Deinen Aruba-Controller oder den NAP ein. Wenn Du dort entsprechende Pools für das WLAN anlegst, hast Du dann alle Informationen an einer Stelle.

Je nachdem welche Switche Ihr habt (Aruba hat ja die recht gute ProCurve-Baureihe von HP übernommen) funktioniert das auch mit verkabelten Geräten - dem RADIUS ist erst mal egal woher das Zertifikat kommt welches er prüft.

Im Idealfall gibt der Radius dann eine SSID (im WLAN) oder VLAN-ID zurück, in welche der Client dann bewegt wird. Zusätzlich ein Fallback-VLAN für nicht authentifizierungsfähige Clienten, dann kann man auch die IoT-Geräte dort sammeln.

Re-Authentifizierung ist übrigens unabhängig vom DHCP renew, hier kann man ein langes Intervall (z.B. 1 Tag) oder auch unendlich einstellen (dann wird der Client nur neu authentifiziert, wenn er sich getrennt hat).

Wenn man das Ausrollen von Zerifikaten noch mit SCEP automatisiert (der Nutzer meldet sich auf dem unbekannten Gerät mit seinen AD-Credentials an und erhält en Zertifikat von der Winows-CA) mußt Du Dich um gar nichts mehr kümmern.

Hi Alan,

danke für deinen weiteren Input.
Ja, wir haben die ProCurve Switches und ja, ich könnte DHCP forwarden - allerdings fliegt mir dann das Lizensierungsmodell der SG um die Ohren, wir haben keine Appliance, sondern die Softwarelizenz, die als aktiv/passiv Cluster auf eigener Hardware läuft. Die ist clientbasiert und wenn ich jeden DHCP-Request die UTM passieren lasse, zählt diese jeden Zugriff als "Client" und dann liege ich in wenigen Stunden weit jenseits der Lizenzen.

Ich mache es wahrscheinlich zweistufig:

IP/MAC-Adressliste mit OPNWatch (=ArpWatch für die OPNSense) auf einen Syslogserver rausgeschrieben und

IP - http(s) Zugriff nach extern dann über den WebProxy. 

Leider musste ich den transparenten https Proxy wieder ausschalten, da dieser sich dann sofort auch traffic greift, der durch IPSec-Tunnel zu gehen hat. Soweit ich das Konzept verstanden habe, kommt der WebProxy halt immer "zuerst" und dann erst routing und NATing - kann ich das irgendwie für bestimmt Adressen verhindern? Die Ausnahmen in den Filterregeln helfen da leider nicht weiter. 

Dann habe ich Deine Netzwerkstruktur noch nicht verstanden. Geht der Traffic hunderter Mitarbeiter durch die Sophos oder nur ein paar IoT-Geräte und Besucher?

Bist Du Dir mit IPSec sicher? Normalerweise lauscht die Sophos nur auf Port 80 und 443, was eher für SSL-VPNs (oder eine Kapselung von IPSec in SSL) sprechen würde. Verhindern kann man das durch Anlegen mehrerer Filterprofile, die nach entsprechenden Netzwerkdefinitionen (IP, Subnetz, Schnitstelle...) ausgewählt werden.

Wir machen es so, daß die Switche und WLAN-Controller über ein getrenntes Managementnetz mit dem RADIUS kommunizieren und für jeden WLAN-Clienten bzw. LAN-Port je nach Authentifizierungsergebnis getrennte VLANs zuweisen - DHCP kommt erst dort.

"Bekannte" Mitarbeiter landen in ihren jeweiligen Subnetzen (z.B. Entwicklung, Vertrieb, Buchhaltung), Gäste in einem getrennten Netzsegment. Dort können sie sich dann z.B. mit einem Hotspot-Ticket (wird am Empfang ausgegeben und in der Besucherliste vermerkt) den Zugriff aufs Internet freischalten oder als Mitarbeiter authentifizieren - dann erhalten sie auch Zugriff aufs interne Netz.

Wenn's nur ums Protokollieren (ohne Kategoriefilterung, Virenscan usw.) geht kannst Du auch einen kleinen Squid o.ä. aufsetzen und entsprechende Analysetools für die Logs verwenden.

RADIUS-Requests lassen sich übrigens auch relayen, so daß etwa Euer Aruba-Controller je nach Realm Domainnutzer über den NAP authentifiziert oder alternativ der NAP WLAN-Nutzer am Aruba.

Guten Morgen Alan,

Die kurze Version:

Es gibt LAN2Lan-Kopplungen über IPSEC (ja, ich bin mir da ganz sicher, denn ich muss die regelmäßig gegen die IT von Großunternehmen zusammenbasteln) zu Kundennetzwerken via UTM.

Aus dem (W)LAN und den VPNs heraus erfolgen die https- und ssh-Clientzugriffe dorthin völlig transparent.

Indem Moment, wo ich den Webproxy für https-logging auf der UTM einschalte, hat dieser Priorität vor dem Routing und die Kundennetzwerke sind nach wie vor per ssh & Co. zu erreichen, aber nicht mehr via https.

Mir ist eben keine Möglichkeit bekannt, der SG das für bestimmte Zielnetze abzugewöhnen.

Die etwas längere Version:

Es existiert bei uns ein Zielkonflikt zwischen Wünschen der Großkunden auf der einen (Alles muss protokolliert werden, Kameras vor den Serverracks, Zugangskontrollen, Prozeduren, Auditings, usw. - und dann arbeiten die per Slack, M365 und Googledrive mit uns, kein Kommentar dazu!)  und maximales "laissez fair" des Vorstandes auf der anderen Seite: Gastnetzwerk ohne nennenswerte Authentifizierung, möglichst keine Beschränkungen in den Zugriffen nach draußen, jeder ist auf seinen Geräten Admin und kann dort machen, was er will, jedes blöde IoT-Gerät kann sich per UPNP ausbreiten, usw.

Und dazwischen sitze seit 25 Jahren ich, der nach der Devise "Nichts wird so heiss gegessen, wie es gekocht wird." versucht, da ein einigermassen gangbaren Weg zu gehen. 

Und jetzt kommt eine Phase des großen "Mergens" hinzu, es passiert ein Zusammenschluss von mehreren Firmen mit jeweils eigener (Nicht-)IT, eigenen Kunden und Anforderungen einem Zoo von benutzten Tools. Das reicht von "komplett M365-Domain" über "Hybrid-Domain" bis "gar keine Domain" und auch kein zentrales Benutzerverzeichnis. Gleichzeitig muss ich DATEV und Serralla ausrollen und das alles bis gestern.

Tja, und da würde es mir reichen, wenn ich erst mal den Bestand loggen und wegschreiben kann. Wen irgendwann mal jemand kommt uns fragt "Wer hat am xx.x.2023 auf IP x.y.z.v. zugegeriffen", gibt es dann eben eine kleine "grep"-Session...

Ja, das klingt alles sehr vertraut. Insbesondere technikaffine Firmen (auch große) mit nie abgelegter "Startup-Kultur" oder öffentliche Einrichtungen sind da bisweilen gruselig. Oft denken die Mitarbeiter "das kriege ich schon selber hin" und basteln etwas halbgewalktes - die IT-Abteilung wir dann eher als "Arbeitsverhinderung" gesehen. Führt dann schnell zu einer "Schatten-IT".

Positiv habe ich es z.B. bei Siemens erlebt. Das fängt schon damit an, daß der Mitarbeiterausweis gleichzeitig Smartcard ist, über die man sich authentifiziert - ohne geht nichts. Auch ansonsten ist da vieles durchdacht und stringent umgesetzt.

Extremfall sind z.B. unsere externen Wirtschaftsprüfer, die können nicht mal einen Datev-Export direkt in den Laptop einlesen, der muß erst zu deren zentralen IT, die ihn dann importiert und den Mitarbeitern wieder übers VPN zur Verfügung stellt. Ansonsten kann man mit dem Laptop nicht viel mehr machen als arbeiten - alles andere ist gesperrt :-)
Netterweise brachten sie letztes Jahr eine Sophos RED mit, als sie sich für einen Monat hier einnisteten.

Wahrscheinlich ist es das Beste, erst mal nur soviel wie möglich Informationen zu sammeln und wegzuschreiben, sollte es dann mal zu einem gravierenden (meldepflichtigen) Vorfall kommen wird meistens sowieso ein externer Forensiker beauftragt, dem man das dann alles vor die Füße werfen kann zur Aufklärung. Weitere Empfehlungen kommen dann automatisch - direkt an die Geschäftsleitung. :-)

Aufpassen muß man dabei ein wenig mit Datenschutz, das sollte von der Geschäftsleitung (und ggf. Betriebsrat) abgesegnet sein. Bei uns ist es z.B. so, daß ein Mitglied der GL, ein Betriebsrat und die IT gemeinsam dabei sein müssen, wenn Logs ausgewertet werden.

Das mit dem IPSec hatte ich falsch verstanden - der Tunnelaufbau selbst wird nicht vom Proxy geblockt, nur der "hinten" 'rauskommende SSL-Datenverkehr abgefangen. Das ist ja auch so gewollt, man muß dann im Log schauen, warum es nicht weitergeht (z.B. fehlende Authentifizierung, Firewallregel oder Routing). Wie gesagt wird ja nur Port 80 und 443 transparent gefiltert, andere (z.B.22) nicht.

Wir haben leider keine Arbeitnehmervertretung, aber das ist ein ganz anderes Feld. Ansonsten genau so, wie du es beschreibst.
Nur mit dem IPSEC glaube ich, konnte ich dir noch nicht vermitteln, was das Problem ist:

Das Problem ist, dass die UTM den Squid bei der Abarbeitung aller Regeln priorisiert, also WENN http(s) Anforderung "nach draußen"  auf der SG ankommt, DANN gehe über Squid direkt nach draussen. In diesem Moment sind die ansonsten für alle anderen Protokolle geltenden Routen leider obsolet.

Das Benutzen der  von der UTM aufgebauten (nicht: vom Client initiierten!) IPSEC-Tunnel in Kundenzielsysteme (u.a. lustigerweise auch zum einem Siemens-Teil, Siemens healthineers :-) ) ist dann für http (das ist Wurst, da depricated) und https (das ist leider entscheidend) unmöglich, da sich eben die UTM den traffic schnappt und via squid direkt raus schickt - da ist aber natürlich das entsprechende System nicht zu finden.

Wir haben leider keine Arbeitnehmervertretung, aber das ist ein ganz anderes Feld. Ansonsten genau so, wie du es beschreibst.
Nur mit dem IPSEC glaube ich, konnte ich dir noch nicht vermitteln, was das Problem ist:

Das Problem ist, dass die UTM den Squid bei der Abarbeitung aller Regeln priorisiert, also WENN http(s) Anforderung "nach draußen"  auf der SG ankommt, DANN gehe über Squid direkt nach draussen. In diesem Moment sind die ansonsten für alle anderen Protokolle geltenden Routen leider obsolet.

Das Benutzen der  von der UTM aufgebauten (nicht: vom Client initiierten!) IPSEC-Tunnel in Kundenzielsysteme (u.a. lustigerweise auch zum einem Siemens-Teil, Siemens healthineers :-) ) ist dann für http (das ist Wurst, da depricated) und https (das ist leider entscheidend) unmöglich, da sich eben die UTM den traffic schnappt und via squid direkt raus schickt - da ist aber natürlich das entsprechende System nicht zu finden.