Weingeist

Das ist die Gretchenfrage. Was ist gut genug. Für meinen Geschmack ist die ganze Fernwarterei inklusive OS-Mangement "schwierig" für einen KMU und auch für den Dienstleister der die ganzen Hersteller im "Schach" halten soll. Objektiv gesehen ist das Risiko weder korrekt beurteilbar noch beherrschbar. Insbesondere bei x-Verschiedenen Ferwartungsvarianten und einem Sammelsurium an veralteten OS. Der Schlüsselschalter hilft wenig wenn der Hersteller etwas einschleppt. Ehrlich gesagt würde es mich sogar wundern, wenn die Hersteller von Fertigungsmaschinen nicht unterwandert sind. Früher habe ich die Kröten geschluckt, aber heute wo alles vernetzt ist, Datenaustausch stattfinden muss, die Software unausgereift daherkommt etc. hat das schlaflose-Nächte-Potential. Zumindest wenn einem nicht alles egal ist. Guacomole: Bis dato noch nicht damig beschäftigt. Halt wieder was mehr Danke für die Inputs!

@cj_berlin: Naja, eher Offline im Sinne von nicht permanent im Internet. Im Produktionsnetz hängt der Rechner schon, das hat kein Internet. Transfer von Dateien kann ich mich nicht mehr wehren, weil der Print/Rescan oft nicht mehr ausreicht und RAW-Messdaten zu den Kunden gehen müssen, diese das Messprogramm selber liefern etc. Also die USB-Sch** ist da auch unterwegs. Bei den Fernwartungen geht es normal um Anwendungssupport von Messmaschinen, CAD oder Maschinensteuerungen in Kleinfirmen ohne IT-Abteilung. Fand die Idee des Technikers auf Anhieb nicht verkehrt, nach näherem Nachdenken aber doch nicht so prickelnd. Die Old-School Vororttermine sind als KMU heute oft nur noch mit grosser Vorlaufzeit möglich. Fernwartung dagegen sofort. Diese ist zudem "inbegriffen" in den astronomischen Wartungsverträgen, der Vorort-Termin muss jeweils äusserst fürstlich zusätzlich bezahlt werden. Für Upgrades setze ich das durch, für minimalen Support ist das aber nicht zielführend. Objektiv betrachtet bin ich aber nicht in der Lage das irgendwie nach minimalen IT-Masstäben sicher zu halten. Maschinen die teilweisedie Neu bereits mit veraltetem OS kommen, wirft man aber auch nicht einfach so weg. Es ist mehr so ein Nicht-Immer-Internet = Risiko-Verkleinerung. IoT setzt sich zwar - sehr langsam - durch (bin immer am meckern), aber Pro mit abgedrehten Updates oft immer noch Standard. @teletubbieland: LTE Router, ja das gefällt mir besser als der WLAN-Stick. Habe ich teilweise so im Einsatz. Bis dato aber für stationäre Anwendungen mit Schlüsselschalter, nicht zum "wechseln". Ist nicht so extrem Anwenderfreundlich als mobile Variante, aber für jede Maschine ne eigenes Gerät ist auch aufwendig. Mich nervt der Wildwuchs von gefühlt 100 verschiedenen Fernwartungsanwendungen. Software, Hardware VPN und was es nicht alles so gibt.

Hallo Zusammen, Ein Hersteller möchte gerne WLAN-Sticks für temporäre Fernwartung auf Offline-Maschinen mit Windows-PC-Steuerung verwenden. Also sobald Fernwartung erwünscht ist, steckt man den Stick rein und baut z.B. über den Hotspot eines Mobilfunktelefons auf (wenn es sonst kein WLAN gibt). Was sollte man davon halten? So auf Anhieb finde ich es besser als eine permanente Verbindung. Aber WLAN deaktiviere ich normal aus Prinzip. Inklusive Dienste. Verschiedenste WLAN-Sticks bekeckern sich auch nicht unbedingt mit Ruhm, müssen zudem auch wieder aktuell gehalten werden. Auch die Firewall ist dann quasi "umgangen" auch wenn jeweils ebenso alles was möglich ist, abgedreht ist per Windows Firewall. Die Alternative wäre eine dedizierte Netzwerkkarte für den Internetzugang mit Schlüsselschalter. Das ist üblicherweise meine bevorzugte Variante. Grüsse und Danke

Hie ein Plus für detailliert. Auf die granulare Freigabe auf einzelne IP's/DNS-Namen kam ich aber aus den Gründen die Evgenij bereits gennant hat auch wieder weg. Hat er schon öfter darauf hingewiesen und fand ich schlüssig. Ist auch viel zu pflegebedürftig. Weniger im Betrieb selbst - da ändert sich nicht so viel - aber wenn man z.B. Migrationen fährt. Da drehst ab. Was ich beibehalten habe ist die granulare Freigabe was überhaupt raus darf. Das gilt für MS als auch fremde Dienste. Ein paar Gründe für Detailierung man sieht im Security-Log was überhaupt alles raus kommunizieren will. Das ist bereits für Windows recht interessant (sofern man es aktiviert) aber auch jede unscheinbare Software. Die In-Logs sind relativ überschaubar und können recht easy ausgewertet werden, weil die ganzen Kontaktaufnahmen anderer Clients wegfallen, weil sie gar nicht erst raus gehen. Gerade für die Fehlersuche ist das extrem angenehm wenn das ganze Grundrauschen weg ist. Windows Updates auf Produktionsmaschinen können sehr effektiv verhindert bzw. geplant werden ohne die Updatedienste zu deaktivieren. Die werden von Windows sowieso gerne wieder aktiviert. So kann man Updates zwar intern freigeben, aber damit sie die Clients bekommen, muss mit einem einfach Script die Firewall-Regel aktiviert werden (das Gegenscript wird automatisch alle paar Stunden ausgeführt wenn man es mal vergisst). Dafür braucht es noch etwas mehr, da der Dienst maskiert ist. IPv6 wird in letzter Konsequenz blockiert (wenn sich ein Dienst nicht an die IPv4 Order hält, entdecken von Kofigurationsfehler oder irgend eine Management-Karte sich verselbstständigt). Ich mag keine zwei Dinge zu pflegen, keine Zeit.

Die RAM-Auslastung ist für einen Spooler der keine Druckaufträge haben soll, auch sehr hoch. Also irgendwas macht das Teil. Hast wie vorschgeschlagen mal die Firewall-Logs geprüft? Also von dem Terminalserver und diesem Server? Der Server scheint allerhand sonstige Aufgaben zu haben ausser Printserver zu sein. Beim Printserver ist das äusserst unvorteilhaft weil nicht so einfach Tests mit Rollback gemacht werden können. Vielleicht generiert ja eine der Aufgaben ne Menge PDF's, Reports oder ähnliches welche die Spooler Engine benötigt. Am ehesten tippe ich aber auf sehr viel falsche Verbindungen (nicht FQDN) oder grottige Treiber. Malware natürlich auch immer möglich.

Stolperte grad drüber. Das stimmt so nicht. Wichtig ist, wie genau das installiert wird bzw. was als Quelle genommen wird. Das XML wechselt selber gar nichts, das erstellt man selbst. Im XML muss einfach zusätzlich die Product ID von Access hinzugefügt werden. Und der Produktkey. Zusätzlich zur Product-ID von Office Standard. Wird das Produkt aber als Bestandteil einer Office Pro Plus Auswahl installiert, begeht man einen Lizenzverstoss, auch wenn man keine andere Komponenten von Pro Plus installiert. Einfacher ist es natürlich, gleich ProPlus zu erwerben. Notwendig aber nicht.

Häufigste Ärger-Ursache seit MS-Security-Hardening: Verbinden mit Printserver-Name statt Print-Server FQDN. Das prüfe ich immer als erstes da alles an Fehlerbilder möglich ist. Dann würde ich noch das NTLM-Logging sowie Firewall-Logging auf Droped Pakete aktivieren sofern nicht bereits gemacht. Wenn z.B. NTLM systemweit deaktiviert wird, dann versuchen die Drucker sich nach Ablauf des Kerberos Tickets des Users sich permanent per NTLM zu verbinden. Was dann so halb funktioniert (aber nicht sollte) oder eben auch nicht (random). Das ist vor allem bei den Protected Users nach ~3h der Fall. Wenn das viele machen, könnte ich mir schon einen Anstieg der CPU-Last vorstellen. Ansonsten der beste Tipp den ich Dir punkto Drucker geben kann: Ausschliesslich die teure(re)n Business-Geräte der grossen Hersteller verwenden. Da passt auch das Treiberpaket inkl. Updates über viele Jahre. Dann: Printserver immer isoliert betreiben ohne anderen Krams. (einfache Rollbacks).

In Hinblick der ganzen Ransomware und Hypervisor-Sicherheitslücken (Hostübernahme durch VM) der letzten Jahre, bin ich recht skeptisch geworden mit der Sicherung in eine Storage bzw. Backupserver VM rein. Hatte einige schlaflose Nächte deswegen, da ich oft genau solche Konzepte für die aktuellen Backups benutzt habe. Ein paar Gedanken zu Backups (Fokus KMU-Umfeld) Die Backups selbst sollten möglichst immutable, also nicht löschbar sein. Mindestens ein Ziel, besser zwei und unterschiedliche Technik (z.B. NAS und Server) über die LAN-Verbindung ins produktive Netz bzw. die Verwaltungsebene nur das erlauben was für Übertragung notwendig ist. Verwaltung wieder über eigene Anschlüsse. Agentless Sicherung und ohne Hypervisor-VM Kommunikation kann man z.B. bewerkstelligen indem Applikations-Daten auf eine separate Fesplatte der produktiven VM gesichert werden. Die sind dann immer Konsistent wenn der Backup eine Kopie zieht. Bei einem Restore ist halt ein zusätzlicher Schritt notwendig. Erst VM zurück, dann Applikations-DB. Backup in die Cloud ist je nach dem unglaublich Bandbreitenintensiv. Kommt drauf an wie viel gesichert werden muss und vor allem was. Nur Nutzdaten oder wirklich die ganze Umgebung. Externe Backups Inkrementell zu sichern finde ich auch immer etwas speziell. Restore-Geschwindigkeit ist heute erschwinglich geworden. Sowohl 10gbit als auch SSD's. Sprich das Primäre Backup kann auch HighSpeed sein oder sogar auf der gleichen Maschine wo man dann die Platten in den zweiten Server steckt wenn nötig. (Hardware-Ausfällen, Update-Ärger oder Aus-Versehen-Löschungen) Bei Ransomware oder Totalausfall wegen Brand etc. spielt die Zeit (in einem KMU) oft eh nur noch eine untergeordnete Rolle. Also ob das dann von der Cloud oder einem lahmeren Repo kommt ist dann grad auch egal weil der Rest sowieso schon viel Zeit in Anspruch nimmt Ich mag zum Beispiel Files und Datenbanken-Sicherheits-Kopien als Kopie auf einer unabhängigen eigenen Maschine für diesen Zweck. Also Server oder NAS nicht innerhalb der Domäne und über eigenes VLAN. Der Kopiervorgang direkt von Filesystem zu Filesystem. Grund: Wird die VM-Disc z.B. zwei Monate vorher verschlüsselt und erst dann die Keys gelöscht, hat man mit etwas Glück trotzdem aktuelle Nutz-Daten.

Moin, ok, falsch verstanden. Das bezog ich darauf. Also Kommunikation mit zentralem KDC und LocalKDC selber spielen. Der Punkt wo ich auf dem Schlauch stehe ist der, wo aus Sicht des Clients der Unterschied ist, ob er nun gegen einen zentralen oder einen lokalen KDC authentifziert. Der Ablauf müsste für Ihn ja identisch sein, da gleiche Technik aber andere Maschine. Daher auch meine Missinterpretation Deiner Aussage oben. Aber ja eine gewisse Illusion spielt da sicher mit, da gebe ich Dir vollkommen recht!

Kleine Anmerkung am Rande: An sich ein sehr cooles Gerät mit kleineren Schwächen. Habe selbst mal eines geordert. Die Herkunft ist zumindest "interessant". Es wird einem suggeriert, dass es ein europäisches Produkt ist, aber es kommt vollständig aus China. inkl. der Software und auch dem Cloud-Anbindung. Auch konkrete Anfragen ergeben mitunter interessante Antworten. Gesunde Skepsis dürfte nicht verkehrt sein.

@cj_berlin Also jetzt stehe ich wirklich auf dem Schlauch bzw. verstehe nicht worauf Du hinaus willst. Wozu muss der Drucker ein LocalKDC haben? Er ist ja der "Client" und muss sich ein Ticket holen damit er etwas auf dem Fileserver ablegen kann. Andersum - also wenn ein Windows-Client etwas auf dem Drucker holen will - sieht das natürlich anders aus. Da sind es dann in der Regel Abteilungs-Pins die man eingeben muss. Sofern das überhaupt geht. Normal gibt man für ein Scan-Ziel einen User und einen Pfad pro Ziel an. Sprich man definiert worauf der Drucker zugreifen und mit welchem User/PW er sich anmelden soll. Das Ziel - der Fileserver - sagt ob das mit den User-Creds möglich ist. Wenn es zufällig der gleiche Computer ist, gut, wenn nicht, egal. Zumindest müste es ja so umgesetzt sein mit Kerberos. *hust* Schätze mit NTLM ist es wohl eher so, dass man auf die Ressource zugreifen möchte und die verlangt dann die User-Credentials. Den genauen Ablauf kenne ich nicht. Aber auch da kann man angeben ob es ein Lokales oder ein Domänen-Konto ist. Geht eigentlich immer beides egal ob der Filer in einer Domäne ist oder nicht. Einfach indem User@ComputerFQDN oder User@domäneFQDN angegeben wird. Aktuelle mache ich das so: Separater Scan-Fileserver der in der Domäne ist Lokales Dienst-Konto auf dem Fileserver welches im Drucker angegeben wird (ich mag für Dienskotos üblicherweise lieber lokale Konten, sofern möglich) NTLM für Domänenkonten AD-Weit gesperrt Ausnahme für NTLM auf diesem Fileserver Nur ein spezielles Admin-Konto das sonst nirgends verwendet wird, hat auf dem Filer Anmelderechte mit einem Domänenkonto, sonst niemand, also alle explizit verboten Heisst der Drucker greift mit einem Konto zu, dass nur auf dem Scan-Server existiert. Aktuell verwendet z.B. ein Canon Drucker NTLM um sich zu authentifizieren. Versucht sich jemand mit NTLM gegen ein Domänenkonto via dem Scan-Filer zu authentifzieren, schlägt es fehl obwohl der Filer selbst ein NTLM-Ausnahme hat. Verwendet er ein lokales Konto des Filers, ist es dagegen möglich. -->Schön wäre nun, wenn das ganze über den LocalKDC laufen würde und keine Ausnahme notwendig wäre. Inwiefern es tatsächlich ein Sicherheitsgewinn ist, keine Ahnung. Aber das NTLM nicht sicher ist, wurde bereits bewiesen. ;) Bei den Adresslisten die von einem Server gestellt werden, sieht das anders aus. Da geht oft Druckerweit nur eine Anmeldung an einem Verzeichnisdienst. Da können eigentlich auch alle Kerberos. Selbst Canon. Insofern wüssten die schon wie das geht.

@cj_berlin Sehe noch nicht ganz die Problematik. Entweder meldet man sich mit EINEM User an EIN Ziel und somit EINEN lokalen KDC an oder man verwendet EIN Domänenkonte wo die Authentifzierung gegen MEHRERE Ziele (DC's) möglich ist. In beiden Fällen liefert der DNS doch die entsprechenden IP's der bzw. des Anmeldeservers für einen externen Zugriff. Bedingt natürlich, dass der zugreifende User nicht einfach ein Username sondern eben der vollständige Anmeldename ist. Also "user@domänexy.xy" oder "user@computer.domäne.xy". Oder "User@computer.xy". Ist kein DNS vorhanden müsste man eben die IP händisch mit angeben. So wie auch für NTLM wo sie einfach via Broadcast oder auch mit DNS ermittelt wird. Mit der Ressource selbst hat das ja erstmal nichts zu tun, das ist ja immer eine separate Angabe. Oder stehe ich auf dem Schlauch? Wie die ganze Vortrauenssache aussieht damit überhaupt eine geschützte und sichere Authentifizierung vorgenommen werden kann, steht wieder auf einem anderen Blatt. Aber da wird ja MS schon eine Idee haben wenn sie das implementieren. Dazu habe ich mich noch zu wenig damit beschäftigt. Vielleicht weiss ja Du dazu mehr? Ansonsten bin ich mal gespannt wie lange es geht bis die Malware-Entwickler so kreativ werden und die integrierten KI-Funktionen gleich für den Angriff zu nutzen. Könnte "interessant" werden. Hat etwas von der Büchse der Pandora. Ich würde jedenfalls lieber die Lizenzgebühren für ein reines, stabiles, sicheres OS bezahlen. Vielleicht lässt es sich dann ja auch easy entfernen. MS hat ja mittlerweile eine sehr gute Kapselung der Komponenten.

Ja, sobald der geht, kannst im Grunde NTLM komplett in Rente schicken. Wie stark es tatsächlich ein Sicherheitsgewinn ist, kann ich nicht beurteilen, aber immerhin musst dann keine Ausnahmen mehr machen für NTLM. Zumindest solange andere Software-Hersteller zeitnah nachrüsten. Bis dahin kann bzw. sollte man es für Domänen-Konten deaktivieren und auf einzelnen Maschinen für lokale Konten zulassen.

Glatt überlesen: Nope, nochmals die Logik aktiviert: Die Binary vom halben OS austauschen geht nur, wenn Du in der Hälfte des Codes etwas nachrüstest und somit alle Files ersetzen musst. Denke so extrem viel neuer Code wirds wohl nicht sein aber ne Menge Datein denen was nachgerüstet wurde. Ich vermute es wird tendenziell nicht Local KDC sein, auch wenn das Cool wäre, könnte ich Canon mal wieder schreiben, dass es nun sogar mit "normalen" Computern geht... (die können immer noch kein Kerberos....)

mhua mhua.... in Grenzen mit 1.2 GB, der war gut. Das erste Update war schon grösser als alle Server 2022 bis Stand heute (May 2025: 392,6 MB)