Jump to content

Weingeist

Members
  • Gesamte Inhalte

    1.566
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von Weingeist

  1. Früher als es im Winter noch schneite - müssten an die 20 Jahre her sein - , war ich mit Ayumni PDF-Converter aus allen Programmen heraus erfolgreich. Sogar Excel, Access-Reports etc. konnte der fehlerfrei darstellen, feine Linien und allem Pipapo. Was damals nichtmal der Printer von Adobe selbst konnte. Den Dateipfad konnte man vor dem Druck vorlegen. Den Printer sogar direkt in VB ansprechen. Book- und Watermarks hinzufügen etc. Der lief von Windows 3.1 bis hin zu XP problemlos. War glaub nichtmal 1 MB gross das Ding (Müsste ich mal tief in der Kiste graben) Ob die Firma heute noch was taugt, kann ich nicht sagen. Wenn die gleichermassen Innovativ ist wie früher, tippe ich auf ein Ja Im Grunde kannst sowieso nur alles an Covertern durchtesten was der Markt so hergibt und wenn Du tatsächlich einen findest der den Output so generieren kann wie du willst, prüfen ob Du irgend in einer Form einen automatisierten Output generieren kannst. Bezüglich Windows XPS/PrintToPDF gibts auch Möglichkeiten: https://stackoverflow.com/questions/69169267/how-to-skip-choosing-folder-in-microsoft-pdf-printer CAD-Programme vermurksen gerne die PDF's. Unterschlagen z.B. Toleranzen, die Ziffern, nur den Text. Da gibts wirklich alles. Sprich auch wenn das mit "normalen" PDF's funktioniert, mit solchen tut es das meistens nicht. Was genau die vermurksen damit es im Reader dennoch korrekt dargestellt wird, weiss ich nicht. Auch die unsäglichen Haarlinien stellen alle welche PDF's korrekt interpretieren, quasi durchsichtig dar. Adobe verbiegt hier ihren eigenen Standard und stellt diese Linien dicker dar. Keine Ahnung auf welchem Mist das gewachsen ist.
  2. Geht wohl in die Richtung, dass die Regeln für Sicherheit, Updates und Compliance an den normalen Edge weitergereicht werden. Andere Dinge wie Browser-Features für den "normalen" Edge aber nicht (mehr?) abgedreht werden können sollen. Sie nennen das "Light-Managed". Sprich man kann wohl nicht mehr alle Bereiche des normalen Edge kontrollieren. Zumindest nicht per Policy. In den Kommentaren wurde sich darüber ausgelassen, MS-Mitarbeiter haben auch ein paar Statements abgegeben: https://techcommunity.microsoft.com/t5/microsoft-edge-insider/microsoft-edge-for-business-faq/ba-p/3891837 So richtig weiss ich noch nicht was ich davon halten soll... Sieht auf den ersten Blick wieder mal nach einer tollen Idee aus, welche durch zu viele Abteilungen gewandert ist anstatt in der technischen zu verbleiben.
  3. Salut zusammen, Es scheint seit ca. einem Monat eine Business-Version der Edge Version zu geben. Infos: https://blogs.windows.com/msedgedev/2023/08/22/microsoft-edge-for-business-now-available/ So ganz schlau wurde ich persönlich aus den Infos nicht. Vor allem nicht ob man Vorteile hat ohne die MS-Anmeldung. Sitzt wer an der Quelle? EDIT: Also so nach einiger Recherche, ist es möglich, dass die GPO's nur noch auf den Business Edge ziehen und für den normalen Edge Wirkungslos sein werden? Grüsse und Danke
  4. Und die nachfolgenden Empfehlungen lauten allesamt Import/Export. Wo ich mich nur anschliessen kann.
  5. Na er soll doch auch kein Inplace machen sondern export/import. Dann geht das. Habe ich in jeder Umgebung so gemacht. 2016/2019 allesamt übersprungen.
  6. Zwar schon etwas her, aber bezüglich Migration bin ich bei den anderen. Ich würde nur gleich 2022 nehmen. Hat man wieder 10 Jahre Ruhe. Vor allem ist die Version wirklich herausragend gut gelungen finden ich. Dann würde ich Dir empfehlen die Printer mit der FQDN des Printservers zu verbinden und nicht wie früher üblich (sogar nur möglich?) via dem Hostnamen/IP. Dann bin ich fast sicher, dass die meisten User welche selber verbinden, tendenziell eher mit dem Hostnamen verbinden. Bei meinen Umgebungen wars jedenfalls ausnahmslos so. Es gibt hier zwar Reg-Flags welche das entschärfen, aber es bleibt dennoch falsch. Mit den neuesten Sicherheitsupdates/Enforcements hat das auf alle Fälle mächtig Ärgerpotenzial. Spätestens wenn NTLM abgedreht wird, ist Ende Gelände Aber schon mit anderen Sicherheitsflags macht es mächtig Laune. Daher am besten per Scripts oder ähnlichem verbinden und vorgängig alle Netzwerkdrucker rauskicken (z.B. ein Clean Script laufen).
  7. Das ist normal schon so. Der DC zeigt sie aber auch nur an, wenn sie nicht vorher geblockt werden sondern die Auth-Anfrage eben an den DC weitergeleitet wird. Auf dem DC habe ich NTLM vollständig geblockt, so wie auf allen anderen Maschinen auch. Kommt also eine NTLM-Anfrage an eine bestimmte Maschine, dann erscheint kein Eintrag auf dem DC sondern nur auf der Maschine. Weil sie eben vermutlich gar nie ankommt. Wenn man nun auf einer Maschine NTLM freigibt, dann werden lokale Konten authentifiziert (bei Zugriff von Remote), und gegen Domain Konten verworfen. Da eine Weiterleitung der Anfrage an den DC staattfindet, wird auch da ein Block geloggt. Bei der CA scheint das irgendwie anders zu laufen. Als ob die CA selber die Authentifzierung für Domain-Konten vornehmen würde. Oder eben der Block vom DC von der CA nicht stattfindet obwohl NTLM geblockt wird. Sind noch etwas halbgare Beobachtungen, Netzwerkverkehr habe ich noch nicht analysiert. Die GPO's, der Ausführung und die Auswirkungen aber schon. Auf alle Fälle reicht es aus, wenn ich NTLM Anfragen auf der CA freigebe (was ich nicht toll finde). Nun, früher war es noch das Ding am Himmel welches einem zu schaffen gemacht hat... Wobei die macht das immer noch... Aber das Gewitter der virtuellen Cloud kommt bestimmt auch noch in die Realität. Nur eine Frage der Zeit. Aber ist doch wahr, eine solche extreme Zentralisierung ist doch völlig verblödet. Ich werde es nie begreifen wieso man nichts aus der Geschichte lernt. Es spielt keine Rolle ob die Konzentration nun auf wenige Menschen oder Maschinen ist, zu viel an einem zentralen Ort ist nie gesund wenn ganze Regionen oder Länder betroffen sind. Wie würde man sagen in der QM-Risiko-Analyse, Eintritt des Ereignisses zur Zeit unwahrscheinlich, Auswirkungen katastrophal. Massnahmen zur Zeit keine bzw. Vollgas in diese Richtung, die Wahrscheinlichkeit ist ja klein. Bis irgend ein Volldepp das Gefühl hat er müsse irgendwo Krieg "spielen". Dann wird die Wahrscheinlichkeit schlagartig erhöht, die notwendigen Massnahmen sind dann aber nicht mehr fristgerecht umzusetzen.
  8. Ich bin immer wieder erstaunt, dass man politisch eine solch hohe zentralisierte Abhängigkeit duldet. Bei einem Hackangriff oder sogar physischen Angriff auf ein einzelnes solches Zentrum sind gleich tausende Firmen auf einen Schlag handlungsunfähig. *kopfschüttel* Wird seinen Anteil am Untergang des Westens beitragen. Aber noch fast jede Hochkultur in der Geschichte hat sich irgendwann selbst zugrunde gerichtet.
  9. Die paar MB einer CA? Irgendwie beschämend, dass man die nicht minimal pflegen kann...
  10. Also ja die Abhängigkeit gibt es nach wie vor... Klingt nach einem schlechten Scherz. Oder übersehe ich etwas? Man soll NTLM deaktivieren wegen der Relay-Attacken, aber ist ja wenig zielführend wenn man dafür keine Zertifikate mehr ausrollen kann (ausser händischem Request). Ist das ein bewusst totgeschwiegenes "Detail" oder plappern einfach alle Blogger einander nach und keiner setzt es um (auch wenn meistens im Web-Kontext davon gesprochen wird, aber im LAN ist NTLM ja das selbe Probleme) *schultzeruck* Bin ja mal gespannt wann MS das ausrollen will... Wenn sie ihre eigene Timeline befolgen, soll man ja bis im November alles auf Kerberos umgestellt haben... Schwierig wenn die Möglichkeit scheinbar noch gar niemand kennt, gar nicht vorhanden ist geschweige den breitgefächert festgestellt wird (sonst würde es ja mehr Threads dazu geben oder? ) Kennt ihr eine Möglichkeit dafür Kerberos zu forcieren? Gibt es die überhaupt?
  11. Salut Zusammen, Kann mir jemand bestätigen oder klar verneinen, dass das 0815 Zertifikat-Enrollment z.B. für ein Computerzertifikat nach wie vor eine Abhängigkeit von NTLM hat oder eben nicht hat? (Betrifft den manuellen Bezug via certlm.msc/certreq.exe als auch das AutoEnrollment) Die Zertifikanforderung konnte nicht an die Zertifizierungsstelle übermittelt werden. URL: caFQDN\CA-DisplaynameMitDoofenLeerzeichen) Fehler: Die Anforderung wird nicht unterstützt. 0x80070032 (WIN32: 50 ERROR_NOT_SUPPORTED) - keine verworfene Pakete seitens Firewall - keine Kerberos Fehlermeldungen bis auf "KDC_ERR_PREAUTH_REQUIRED", gemäss MS-Webseite ist dieser Eintrag immer zu ignorieren?!? - keine sonstigen Log-Einträge auf dem Client Auf der CA wird ein NTLM-Block geworfen, heisst der Client möchte es mit NTLM versuchen. Entweder sofort oder nachdem Kerberos fehlgeschlagen ist. Noch ein Kuriosum: Freigabe von NTLM nur auf der CA nicht aber auf AD notwendig, normal ist für Domain Accounts auch eine Freigabe auf dem AD nötig. Ein Grund warum ich mir beim Scanner ein Relay bauen musste. Würde heissen entweder werden DC-Einstellungen umgangen (unschön), die Zertifikataustellung geschieht gegen ein Lokales Konto (was aber gemässs dem NTLM-Block nicht so ist. Targetserver ist unter LDAP der DC) oder die CA regelt das via ihrem Direktzugriff auf AD mit ihren eigenen Kerberos Credits, was auch wieder seltsam wäre ohne jegliche AD-Services. Wer möchte mich erleuchten? Hintergrundinfos, sofern von Belang: Rollen auf der Enterprise CA (zweistufig): - Active Directory-Zertifikatdienste>Zertifizierungstelle - Active Directory-Zertifikatdienste>Zertifizierungsstellen-Webregistrierung - IIS das mitinstalliert wir Die CA war ursprünglich auf einem 2012 R2 zu Hause, wurde gesichert und wieder eingespielt. Das Problem war auch auf dem 2012 vorhanden. Sofern das von belang ist (Konfigurationsaltlasten). Patchlevel ist aktuell. Auch wenn es die Webdienste betrifft die eigentlich nicht von der Party sein sollten (ausser ich verstehe da was falsch): IIS>CertEnroll>SSL erzwungen und es kann lesend auf die Dateien zugegriffen werden (Anonyme Authentifizierung) IIS>CertSrv>SSL erzwungen, Negotiate:Kerberos erzwungen, Keine Abfrage von Credentials in Firefox und somit Access Denied. Aktiviere ich NTLM, ist eine Authentifizierung möglich Idendität des App-Pools auf dem IIS habe ich sowhl mit User NetzwerkDienst als auch ApplicationPoolIdentity versucht. Das aber eigentlich mehr zum herausfinden ob Kerberos auf Firefox-Ebene funktionieren würde oder nicht. Scheinbar tut es das nicht. Einen separaten Benutzer habe ich mir erspart. Es läuft auf der CA zudem die gängigen Relay-Schutzmassnahmen wie die RPC-Filter für Remote-EFS, aber die blockieren ebenfalls nichts. Beim 2012R2 waren die Filter noch nicht aktiv und es ging auch nicht. Die Webdienste für die Zertifikate und Sperrlisten laufen auf ein Alias und nicht auf den internen Domain-Namen. Das wird auch per DNS aufgelöst. Grüsse und Danke für inputs
  12. Kosten sind immer relativ. Das Schadens-Szenario ist deutlich wahrscheinlicher geworden als noch vor 20 Jahren. Gleichzeitig ist die Abhängig von der IT aber massiv gestiegen. In jeder Branche. Das erfordert ein Umdenken. Es gibt keine Sicherheit zum 0-Tarif. Auch in der IT nicht. Also entweder die Abhängigkeit reduzieren/herunterfahren statt auszubauen oder aber entsprechend investieren. Bequemlichkeit wird immer teuer erkauft. Auf die eine oder andere Weise. Auch wenn ich mich wiederhole, es war noch nie so einfach Chefs von der Investitionsnotwendigkeit zu überzeugen, das macht die Presse. Aktuelle erntet man als Dienstleister nur die tief hängenden Früchte. Das hat mit Verkauf aktuell nicht mehr viel zu tun. Wenn es dann schon daran scheitert, dass verschiedene Admin-Konten für verschiedene Computergruppen/Dienste bereits aus Sicht des Dienstleister zu viel Aufwand ist, dann sollte dieser vielleicht die Branche wechseln. Definitiv hat der Kunde den falschen Dienstleister. Egal welche Grösse er hat.
  13. Auch wenn es aus dem Task von Testperson allenfalls herauslesbar ist. Ein Konto löschen geht nur, wenn man sich nach einem Neustart noch nicht angemeldet hat. Sprich frisch neu starten, mit einem anderen Account anmelden, unerwünschtes Konto löschen.
  14. Also wenn es um Arbeitsplätze und nicht Notebooks geht, wäre eventuell auch ein richtiger Blickschutz ein Option. Entweder der Arbeitsplatz selbst oder eine Art Shroud wie es bei professionellen Grafikdisplays anzutreffen ist um Umwelteinflüsse möglichst zu vermeiden. Ein Bekannter löst dieses Problem gerade indem er Betrieben mit Grossraumbüros fixfertige, halbmobile "Kleinbüros" und Sitzungsräume liefert und installiert. Der Kann sich kaum retten vor Aufträgen. Bin gespannt wie lange es dauert, bis man von den Grossraumbüros wieder weg kommt und z.B. auf eine flexible Raumaufteilung setzt.
  15. @MurdocX Sorry für die späte Antwort. Habe ich auch nicht so aufgefasst. Mir ist das ja auch ziemlich unlogisch und die Theorie und normale Praxis dazu ist mir ebenfalls bekannt, so ist es nicht. Aber erstellen musste ich auf dem Client nunmal Inbound und Outbound, sonst lief es nicht (mehr) und seither erstelle ich beide. Unsere Voraussetzungen sind in Deinem Test auf alle Fälle nicht identisch. Du greifst via IP zu und benutzt deshalb NTLM und kein Kerberos. Sprich NTLM ist gestattet wenn Du Zugriff bekommst. Ich erzwinge Kerberos. Wie sieht den Deine sonstige SMB-Konfiguration aus? Also Server und Client? Jeweils beides. Also SmbServer und SmbClient. RequireSecuritySignature, EnableStrictNameChecking, RejectUnencryptedAccess, SmbServerNameHardeningLevel auf 1, minium SMB-Level, ValidateTargetName und was ich allenfalls noch so vergessen habe das man setzen sollte und nicht Standard ist (Genaue Differenz zu Standard-Einstellungen müsste ich erst gegenprüfen). Ohne jetzt 100% sicher zu sein, aber meiner Meinung nach fing das Theater an, als ich alle diese Features gesetzt habe. Wobei ich einen Teil schon vorher hatte. Ob nun vor oder nach durchsetzen von Kerberos kann ich ebenfalls nicht mehr mit Sicherheit sagen. Schlicht zu lange her. Im Moment ist aber grad essig mit viel rumtesten. Am Feierabend bekomme ich bei diesem Wetter haue und am Tag grad keine Zeit
  16. Wartung: Da verlangen die grossen Hersteller etwas für Garantie, Updates etc. Je 'grösser' und leistungsfähiger (Bandbreite) die FW, desto teurer wird das bei den 'besseren' Hersteller. Doppelte Netzteile gibts eigentlich bei allen erst bei den grösseren. Es geht nicht per se um das sparen, es geht darum nicht unnötig Geld zu verpulvern für eine Leistung, die man nicht braucht. Ein zweites Netzteil ist z.B. nunmal keine 1000 Euro pro Jahr wert wenn man den rest nicht benötigt. Und jede zusätzliche Hardware die ich nicht einsetze, geht nicht kaputt. Der Vorteil bei Windows-Bordmitteln sehe ich immer in den zeitnahen Updates und der bereits integrierten Rechte-Verwaltung. Sprich Kopplung an AD möglich ohne irgendwelche Verrenkungen. Und eben keine zusätzliche Hardware. Ist Dir grad etwas gutes bekannt? Sollte +- einfach in der Konfig, Updates etc. sein und über vernünftige Logs verfügen. Primär geht es aber nicht darum nichts zu bezahlen, sondern tendenziell wenig laufende Kosten zu verursachen.
  17. @Admin666 Verweis auf Kosten gesehen? Von den grösseren Hersteller ist das richtig teuer. Ebenso die Wartung pro Jahr. Für Leistung die ich ausser den Netzteilen nie brauchen werde. Heute wo alles virtualisiert ist, sehe ich das unkritisch. Insbesondere für eine interne FW. Die Funktion ist eh die selbe. Unterschied ist bei den grossen Hersteller nur ob ein propritäres System oder eben Vmware/HyperV die Virtualisierung übernimmt. Wie dem auch sei, da niemand diesbzüglich mit Windows bzw. dessen Firewahl in Verbindung mit einer Bridge entsprechende Erfahrung zu haben scheint, werde ich die Tests selber machen. Sehe punkto Bridge zwar wenig Chancen aber schauen wir mal. Sonst gibt es eben eine Appliance.
  18. Dann würde ich mal von einer zweiten VM versuchen, die erste aufzulösen. So kannst Du ausschliessen, dass die erste VM sich selber kennt wenn Du eine fixe eingibtst. Das er dafür konfiguriert wurde, glaub ich Dir ja, aber hast Du es auch mit der Firewall geprüft? Sprich kommen die Pakete an auf den Ports? Resolve-DnsName gib hier mal explizit Deinen DNS-Server an und zwinge das cmdlet nur DNS zu verwenden und keine andere Art der Namensauflösung. Also Flags -Server und -dnsonly verwenden. Ich kann mir nicht vorstellen, dass die Auflösung mit einer Statischen IP von einem anderen Client her dann geht und mit einer DHCP-Adresse nicht. Wenn doch, müssen andere rann, mit den Eigenheiten von IPv6 kenne ich mich zu wenig aus. Ich deaktiviere das solange IPv4 funktioniert.
  19. @daabm Aufhängen.... Hmm, das wäre in der Tat unschön. Bis jetzt wusste ich nur, dass er etwas "grässlich" in der Konfig sein soll und nicht unbedingt das performanteste (wobei das bei einer >3GHZ CPU heute auch egal sein dürfte). Mein Link war halt folgender, MS macht mittlerweile viel auf Netzwerkebene mit HyperV, also sollte sie das mittlerweile auch zuverlässig können. Und auch der ISA/TMG konnte das problemlos zuverlässig vor über 10 Jahren. Also warum sollte das heute, über 15 Jahre nach dem ersten vernünftigen ISA, nicht auch mit Bordmittel gehen @Admin666 Ja klar ist es das klassische Produktions-Problem. Und gerade aus genannten Gründen, mag ich da keine LAN-Verbindungen. Daher sehe ich auch eher das Büro als Bedrohung für die Produktion als anderes rum, auch wenn in der Produktion die unsicheren Rechner sitzen. Ist ein Bürorechner befallen, hat er leichtes Spiel mit einem Rechner in der Produktion. Anders rum eher nicht und die Wahrscheinlichkeit ist deutlich tiefer ohne Internetzugriff. An die Nutzung der Firewall welche jeweils den Internet-Teil erledigt, habe ich durchaus auch schon gedacht. Aber ich möchte ja eben nicht ein Gerät ohne doppelte Netzteile etc. als wichtiges Bindeglied haben. Gibt nur wieder Potential für super dringende Einsätze vor Ort und genau die möchte ich möglichst verhindern. Dann lieber eine Appliance. Oder eben Windows Aber Windows schlage ich mir wohl wieder aus dem Kopf auch wenn mir die Filtermöglichkeiten der Firewall ausreichen würden bzw. teilweise sogar einfacher ist (koppeln mit AD-Konten z.B.) Natürlich nicht. Aber die Daten müssen ja dennoch ausgetausch werden (siehe Posts weiter oben). Mit verschiedensten unsicheren Protokollen und eben mittlerweile immer mehr Live-Daten. Und nur weil man eine Firewall hat, heisst das ja nicht, dass es deswegen sicher ist wenn man auf unsichere Weise kommunziert. Datenaustausch mit USB-Sticks.: Nope, das habe ich alles ausgemerzt. In jedem Betrieb gibt es ein absolutes Stick-Verbot. Egal ob Externe oder interne Mitarbeiter. Man muss immer bedenken, eine Machschin die 50k bis 1 mio kostet, mechanisch top ist, wird nicht komplett getauscht nur weil der Steuerrechner veraltet ist. Da muss man eine erträgliche, manchmal kreative Lösung suchen. Bei hochtintegrierten Maschinen/Produktionszellen wird das zunehmend schwieriger. Insbesondere weil das so mit XP/7 erst so richtig angefangen hat. Aber auch ein aktuelles Windows 10 hilft nichts, wenn der Hersteller sämtlichen Support verweigert wenn Updates eingespielt werden. Was ich sogar verstehen kann bei der Pro Version (Bei XP 7 habe ich dank getrennten Sicherheits/Featureupdates die reinen Sicherheitsupdates dennoch problmlos eingespielt). MS hätte ja Abhilfe geschaffen mit IoT/LTSC aber ich bin nicht sicher, dass ich das noch erlebe solange ich arbeite bis das in der Industrie durch ist und nicht mehr Pro verwendet wird. (Der Beschaffungsweg ist ja auch tendenziell beschissen). Im Messbereich gibt es schon löbliche Ausnahmen. :)
  20. 1. Frage prüfst Du mit nslookup vom gleichen Client wo Du auch die IP eigibst oder von einem anderen? Ohne das selber überrüft zu haben, sich selber könnte er dann möglicherweise durchaus kennen wenn Du die IP statisch hinterlegst. Auch kann die Adresse noch im Cache liegen. --> ipconfig /flushdns nach jeder Änderung 2. Frage: Ohne den Prozess bei der Vergabe von IPv6 Adressen und die nachfolgende Registrierung in DNS zu kennen, sicher dass Dein Windows-DHCP Server auch die IPv6 vergibt? Oder könnte das auch ein Router sein, wo der Haken nicht rausgenommen wurde? Dann gäbe es den Eintrag im DNS nicht wenn der. (Aber eben, ich weiss nicht wie das gelöst ist in IPv6, sprich ich habe keine Ahnung ob der Client oder der Server die Registrierung vornimmt) --> Du könntest z.B. mal das Auditing der Firewall aktivieren, dann erkennst von wem die DHCP-Pakete kommen (erkennbar an den Ports 67/68). Die Einträge erscheinen im Sicherheitslog. Am besten Neztwerkadapter deaktivieren, Ereignisfenster aufmachen und Netzadapter aktivieren. Oder ipconfig /renew. Englisches OS: auditpol.exe /set /category:"Object Access" /subcategory:"Filtering Platform packet drop" /success:enable /failure:enable Deutsches OS: auditpol.exe /set /category:"Objektzugriff" /subcategory:"Filterplattform: verworfene Pakete" /success:enable /failure:enable Sprachübergreifend: auditpol.exe /set /category:"{6997984A-797A-11D9-BED3-505054503030}" /subcategory:"{0CCE9225-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable
  21. Vielleicht habe ich das etwas missverständlich ausgedrückt. Ich versuche es mal anders. Wenn man eine Inbound-Regel erstellt, heisst das nicht, dass die Antwort auch tatsächlich zurück gehen kann. Dafür braucht es oft eine zusätzliche Outbound-Regel. Bei der Outbound-Regel muss aber so gut wie nie eine entsprechende Inbound-Regel erstellt werden um die Kommunikation zu ermöglichen. Die Rückantwort geht auch so durch die Firewall. Ausnahme ist z.B. SMB. Du kannst SMB für inbound nicht in der FW abdrehen ohne bescheidene Side-Effects. Die Kommunikation mit DC, CA, WSUS, Filer, Printer brauchen die Inbound-Regeln von SMB. Teilweise sogar zwei Rules (Local/Remote). Das einzige was ich nicht sicher bin, ob sie sie nur brauchen wenn die Verbindung gesichert/signed etc. ist, oder obe es auch für eine ungesicherte Verbindung ebenfalls notwendig ist. Das kann man feststellen, wenn man sämtliche Standardregeln deaktiviert und alle selber nachbaut aufgrund der fehlgeschlagener Kommunikation. Edit: Ja ich habe mir das mal angetan obwohl das kein Mensch macht. Sprich geschaut was alles an minimaler Kommunikation notwendig ist, damit das anmelden an eine Domäne, austausch von Zertifikation, File-Services, Printservices etc. schmerzfrei funktioniert. Macht kein Mensch, ich habs trotzdem mal gemacht. ;) Meine Vermutung geht dahin, dass das unterschiedliche Verhalten etwas mit der Sicherung der Kommunikation zu tun hat. Also das es nicht eine "richtige" Antwort ist, sondern teilweise ein Neuaufbau einer Verbindung für die Rücksendung ist bei SMB. Wenn Windows selber der Initiator ist, bleibt es wohl wie es ist. Ist aber reine Mutmassung. Dafür habe ich die Pakete an sich zu wenig analysiert sondern nur die geblockten Pakete auf den entsprechenden Ports/Protokoll/Dienst festgestellt. Block all heisst: eine Blockieregel gewinnt über eine Erlauben-Regel. Egal welche. Block standard heisst: eine Erlauben-Regel gewinnt über eine Blockier-Regel. Das ist eine "Krücke" der Windows Firewall. Vermutlich ist das dem Umstand geschuldet, dass die Windows-Firewall nicht wie eine "normale" Firewall Regeln der Reihe nach abarbeitet sondern eben alle zusammen. So kann man immerhin sagen, welche gewinnen soll. Je nach dem echt zum "werfen".
  22. Alles was Outbound erlaubt ist, ist bei der Windows-Firewall auch automatisch Inbound erlaubt. Sprich wenn die Port/Protokoll/Local/Remote-Paarung etc. identisch ist bewirkt eine Outbound-Regel, dass der Inbound-Part ebenfalls erlaubt ist. Deshalb muss man auch sehr selten Inbound-Regeln definieren. Umgekehrt gilt das nicht. Wenn Du Outbound auf Standard Offen lässt, kann jede Software problemlos überall hin und her kommunzieren. Der komplette Inbound-Traffic ist erlaubt, solange der Verbindungsaufbau durch den Client stattfindet. Wodurch der auch immer ausgelöst wird (Service, Mausklick, Task, installiertes Programm etc.). Dann gibt es noch diverse vordefinierte Regeln die für Basis-kommunikation grundsätzlich zwingend notwendig ist oder der Sicherheit dienen (Block). Die bekommst Du in der GUI und selbst command line nie zu Gesicht (Registry, Static Rules). Ein kleiner Teil der System-Rules sind Configurable, die sieht man zwar nicht in der GUI, dafür aber in der cmd. Dann gibts eine stark wachsende Anzahl von App-Rules. Die siehst (fast) nur in der Registry und sind auch nur da manipulierbar (die neuesten Updates bringen hier angeblich etwas Funktion in die GUI oder Cmd-Line, noch nicht getestet) Zu SMB: Du kannst nicht einfach SMB auf den Clients abdrehen. Da geht dann wirklich einiges nicht mehr. LanmanServer kann man theoretisch abdrehen. Irgendwo habe ich mal aufgeschrieben was nicht mehr geht (mir wars dann aufgrund einer Situation zu doof, weiss aber nicht mehr warum, müsste ich suchen). Findest aber sicher per google raus. LanManWorkstation kannst nicht wirklich abschalten, sonst geht nicht mehr viel weil z.B. Netlogon oder die Ausführung von GPO's etc. davon abhängig sind. Auch DFS oder Zugriff auf Fileshares geht nicht mehr. Was geht ist die Beschränkung des Traffics auf bestimmte Endgeräte oder sogar Benutzer/Gruppen. Was so wohin geht/herkommt kann man sehr schön erkennen wenn man das Firewall-Journaling aktiviert. Englisches OS: auditpol.exe /set /category:"Object Access" /subcategory:"Filtering Platform packet drop" /success:enable /failure:enable Deutsches OS: auditpol.exe /set /category:"Objektzugriff" /subcategory:"Filterplattform: verworfene Pakete" /success:enable /failure:enable Sprachübergreifend: auditpol.exe /set /category:"{6997984A-797A-11D9-BED3-505054503030}" /subcategory:"{0CCE9225-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable Die Einträge landen im Security Log. Musst die Grösse auf 256MB oder mehr hochstellen, sonst ist das rasch voll. Du wirst erstaunt sein, wieviel Kommunikation so ins weite Netz geht. Mühsam ist die Unterscheidung von Traffic der via der svchost.exe läuft. Da erkennt man zwar die Prozess-Nummer (wiederum mit tasklist.exe aufrufbar), aber die ist nicht zwingend aktuell, weil der Prozess schon wieder beendet sein kann. Da muss man sich dann damit behlefen den Services eigene Hardlinks zur svchost.exe zu spendieren. Dann werden die Verursacher sichtbar (z.B. svchost_servicename.exe) und man kann entsprechende Regeln aufsetzen. (Wobei es unzuverlässig ist auf Services Regeln zu erstellen weil manche von Windows aus Sicherheitsgründen maskiert werden, leider erkennt sie dann auch die Windows-Firewall nicht mehr *hmpf*) Da musst Du entweder tatsächlich mit den Hardlinks arbeiten oder tiefer rein und auf BFE-Ebene filtern via den zugehörigen Service-Protokollen (RPC).
  23. Danke euch! @mwiederkehr Zusätzliche 0815 Hardware will ich vermeiden wenn ausfallsichere Server vorhanden sind. Dann doch lieber eine VM-Appliance. Wenn es mit Bordmitteln von Windows sinnvoll klappt, ist das aber jeweils meine bevorzugte Variante (Kosten, KnowHow usw). @daabm Wieso meinst Gebastel? Weil es tendenziell mühsam in der Konfig/Konfigauswertung ist und nicht "Ressourcenschonend"? Eigentlich will ich ja kein Routing sondern eine simple Bridge mit Filterfunktion. Wenn der Verkehr über die Windows-Firewall/BFE läuft, kann ich da ran, sonst nicht. @cj_berlin ISA/TMG: Für alles brauchte man den Client nicht. Im Detail ist das per Schieberegister aus meinem Gedächnis raus, wann er es notwendig war und wann nicht. Konfig war halt sehr straight und imho einfach verständlich. Und selbst die GUI und die Logs waren gut. Beim TMG konnte man soweit ich mich erinnere die Patches über all die Jahre gesehen glaub an einer Hand abzählen. Muss also doch ziemlich gut programmiert worden sein. Und da sie in die BFE eingegliedert war, muss auch diese an sich ziemlich gut sein. Aber zurück zum Thema: Im Grunde bin ich gezwungen davon auszugehen, das die "unsicheren" Maschinen grundsätzlich safe sind da von extern möglichst abgeschottet. Sonst dürften keine Daten zwischen Maschinen/CAD/Büro ausgetauscht werden. Auf gar keine Weise. Das ist mir durchaus bewusst. Genau deshalb soll diese Maschine zwischen den Netzen ja eine Brücke mit Kontrollstelle/Beschränkung sein. Also im Grunde einfache Firewall-Funktionen übernehmen. Hauptziel ist es, einem allfällig infizierten Desktop die Möglichkeit zu nehmen/erschweren/Potential einzugrenzen, die unsicheren Clients der Produktion direkt mit unsicheren/anfälligen Protokollen zu erreichen/befallen und somit die Produktion lahmzulegen. Auch mit Kopien der Steuerung ist das äusserst mühsam (0-Punkte neu einlernen, neu kalibrieren, auslagern und neu einspielen von 800-1000 Werkzeuge pro Fräscenter, das gleiche mit Rohmaterial in den Roboter-Lager). Wenn jemand die Kontrolle über den Client hat, kann er die Schutz-Funktionen ja auch aushebeln. Wenn die Nutzung von der Brücke geblockt wird, hilft ihm das auf seinem Weg in die Produktion (hoffentlich) nicht weiter. Etwas mehr Hintergrundinfos falls von Belang: Client A aus Bereich "Büro" ist Up to Date, hat empfohlenen Einstellungen, hat Internetzugriff Client B aus Bereich "Maschinennetz" mit denen ich ins Büro kommuniziere möchte sind Up to Date, haben ein modernes OS. Möglicherweisegewisse sind aber unsichere Einstellungen notwendig, um die Kommunikation innerhalb Netz zu den "alten" zu ermöglichen. Vieles was nicht sicher ist, kann ich per Windows-Firewall auf die Maschinenziele beschränken. Aber halt nicht alles (SMB1 z.B. kann nicht auf bestimmte Endgeräte beschränkt werden sondern nur SMB an sich, NTLM ist auch an oder aus). Wenn der eigentlich sichere B mit Einstellungen unsicher gemacht werden muss, soll der Zugriff von A auf B über einen sicheren Brückenkopf/Relay erfolgen. Dieser stellt dann auschliesslich die Funktionen bereitstellt die zwischen A und B benötigt werden. Dieser Brückenkopf (C) hat keine unsicheren Einstellungen wie aktiviertes SMB1/FTP und ist Bestandteil des AD. Die Idee ist nun sicherzustellen, dass nur die C Server und die sicheren B von den Clients A erreicht werden können und umgekehrt. Auch wenn B und C sowie Uralt-Clients im gleichen Netz sind. Wenn ein C nicht mit verhältnissmässigem Aufwand zu bewerkstelligen ist obwohl B unsicher ist, soll die Bridge die Kommunikation mit dem proprietären Protokoll von A nach B direkt ermöglichen. Das soll dann auch möglichst nur auf Systemen sein, wo kein Usere mit Internetzugriff direkt darauf arbeitet. Da das alles irgendwie einfach handelbar bleiben soll, auch für die Fehlersuche, möchte ich eben möglichst kein Routing sondern eine Bridge die gewisse Kommunikationswege erlaubt und den Rest blockiert. Auch soll es möglich sein, dass ich die Bridge zur Fehler-Ausschliessung raus nehmen kann. Als letztes müssen noch Files hin und her. Messprotokolle, 3D-Zeichnungen, Überwachungsprotokolle usw. Das geht über Workarounds/Transfersystem, habe ich schon Jahr im Einsatz, ist aber etwas umständlich. Wenn ich die strikte physische Netztrennung eh aufgebe, wären synchronisierte Filer schöner und bequemer für die Mitarbeiter. Da wäre die Idee SMB zwischen den Bereichen ganz zu blockieren oder nur zwischen den Filern freizugeben (sofern DFSR überhaupt SMB benötigt, sind ja eigene Protokolle). Die Maschinen kommunzieren mit dem unsicheren Filer und authentifizieren sich mit Lokalen Service-Accounts/NTLM und erhalten Zugriff auf Files die sie betreffen. Die sicheren Clients gegen AD mittels Kerberos. DFSR übernimmt die Synchronisation. Bessere Vorschläge sind natürlich herzlich willkommen!
  24. Salut zusammen, Netzwerk-Segmentation bin ich nicht wirklich der Hirsch. Bis jetzt konnte ich mich immer mit physisch vollständig, virtuell mit VLANS und sonst mit Netmasken durchschlängeln. ;) Nun brauche ich eine Kommunikation zwischen zwei Netzen zwischen Rechner aus Bereich A (Maschinen, allenfalls CAD) zu bestimmten Rechnern aus Bereich B (Rest) die ich mit keinen Work-Arounds bewerkstelligen konnte die ich sonst so einsetze. Ein paar Endgeräte aus Bereich A sind SEHR fragwürdig oder werden es demnächst (XP, 7, 8.1 oder 10 ohne Updates), der Ersatz nicht ohne Einwurf zu grosse Noten möglich oder nicht möglich. Nun sollen nur bestimmte Clients/Server überhaupt miteinander sprechen können und das wiederum nur über definierte Protokolle/Ports (Überwachungstools, allenfalls Files, ERP-Anbindung). Kommunikation möglichst transparent zwischen zwei Netzbereichen im gleichen oder unterschiedlichen IP-Range die Kommunikation soll über eine Firewall, ich möchte also steuern über welche Ports und Protokolle von wo nach wo etwas gehen darf Ticket holen aus Bereich A für die sicheren Clients am DC in Bereich B soll aber gehen. Auch der WSUS soll erreicht werden können im Bereich B. Lösung auf Windows Basis ist tendenziell bevorzugt, Konfiguration möglichst einfach Alle Maschinen die von B nach A in Frage kommen - Ausser der DC (multihome) und vermutlich auch der Filer? - dürften eine zweiten Lan-Port haben für die zusätzliche physische Trennung. Aber ob das "hilft" für DNS? Was ist die sinnvollste Lösung für sowas? Eine Bridge ist ja eher schwierig zum effektiven filtern, aber gilt das auch für eine Bridge unter Windows? Läuft das alles über die Firewall-Rules oder nur Routen? Bevor ich jetzt gross stundenlang austeste kann mir ja vielleicht jemand nen Tipp geben ;) Der ISA/TMG hätte sowas easy peasy gemacht... Aber der ist EOL und möglicherweise auch etwas overkill. Vielen Dank!
  25. Einen gewissen Spielraum habt ihr ja. Wenn ihr es durchsetzen könnt, dass ein Naming-Schema eingehalten wird, dann könnte man doch für das Anlegen eines solchen Projekts (oder wie man so einen Unterordner nennen mag) doch ein kleines auf euch zugeschnittenes Powershell-Modul tippseln. Mit der Funktion im Modul erstellt ihr dann mittels der getätigten Angaben die AD-Gruppen, die entsprechenden Ordner und Unterordner und setzt auch gleich die entsprechenden Berechtigungen. Gerade für solche Fälle wo das ganze ständig wiederkehrend ist, spart das unglaublich Zeit. Wie immer steht und fällt eine solche Automatisierung aber mit dem einhalten eines Systems. Änderungen/Erweiterungen an der Struktur sollten dann auch wieder möglichst automatisiert gemacht bzw. möglichst vermieden werden. Sind Projekte zu unterschiedlich, hat es sich an anderer Stelle bewährt, eine Art Projektbeschriebdatei zu erstellen mit den Einstellungen. Also in diesem Fall ein Modul mit den Funktionen und eines welches die Struktur/den Tree und die Zugrifssrechte beschreibt und mit diesen Infos die entsprechenden Funktionen aufruft und wiederum die Ordner erstellt/Berechtigungen setzt. Das ganze kann man dann mit allerei Überprüfungen und Logs ausschmücken. Halt je nach dem was gefragt ist. Erfahrungsgemäss lohnt es sich, die Logs und Überprüfungen möglichst von Anfang und nicht erst im Nachhinein einzubauen. ;)
×
×
  • Neu erstellen...