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 

1. Man kann das Kennwort auch hinterlegen, wenn das Gerät kein NTLM (sollte auch Samba hinkriegen) kann oder man mit einem "fremden" Account angemeldet ist.

2. Welche Probleme? Das "Aufbrechen" von Verschlüsselung ist heutzutage mit den ganzen Sicherheitsmechanismen wie Cert Pinning oder HSTS kaum noch möglich, wenn ich Dich richtig verstehe, willst Du aber nur die Verbindung an sich protokollieren (Metadaten). Das ist weiterhin möglich.

Welches Gerät welche IP bekommen hat (ich gehe an der Stelle mal nicht von Böswilligkeit wie gefälschte MAC aus) sollte sich übrigens aus den Logs der Sophos (des DHCP-Servers) rekonstruieren lassen.
Falls es ein fester Kreis "zulässiger" Geräte ist, kann man denen auch statische Reservierungen im DHCP und "sprechende" Namen zuweisen, die dann auch so in den Statistiken auftauchen.
Auch kann man dann Firewallregeln so anlegen, daß eben nur diese Geräte bestimmte Kundensysteme erreichen können.

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.