Abo
  1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › IT-Sicherheit: Auch kleine Netze…

Was ein Käse...

  1. Thema

Neues Thema Ansicht wechseln


  1. Was ein Käse...

    Autor: mifritscher 10.10.19 - 13:14

    Wenn in Namen schon Zeug wie "Next Generation" auftaucht ist das ein klassischer Einstieg fur Bullshit-Bingo.

    Der Artikel ist aber aus vielen Gründen Rotz:
    * Die angesprochene Teilfunktionalität von SPI macht ein NAT-Router sehr wohl - muss es sogar, um zu funktionieren.
    * TFTP im Internet macht keiner. Am allerwenigstens Malware. Das Protokoll ist gut, um Rechner übers lokale Netz zu starten, aber auch schon da gibt man meist nur Bootloader, Kernel und ggf. initramdisk mit.
    * Heutzutage läuft 99% über HTTPS auf Port 443. Da kann eine Firewall nicht reinschauen. Und nein, SSL aufzubrechen (und dafür an den Clients rumzubasteln) ist ein absolutes No-GO. Das gilt übrigens auch für den Mailverkehr (wenn der auch auf anderen Ports läuft). Wenn will man da einen eigenen Mailserver - der aber nicht auf der Firewall zu laufen hat, schon aus Sicherheitsgründen.

  2. Re: Was ein Käse...

    Autor: megaseppl 10.10.19 - 14:42

    mifritscher schrieb:
    --------------------------------------------------------------------------------
    > * Heutzutage läuft 99% über HTTPS auf Port 443. Da kann eine Firewall
    > nicht reinschauen. Und nein, SSL aufzubrechen (und dafür an den Clients
    > rumzubasteln) ist ein absolutes No-GO.

    Selbst bei Golem wurde davor bereits gewarnt: https://www.golem.de/news/https-interception-sicherheitsprodukte-gefaehrden-https-1702-126098.html

  3. Re: Was ein Käse...

    Autor: HGH 10.10.19 - 15:56

    Ich gebe Dir Recht! Eine Ganze Horde von schlechten Systemadministratoren wird sich jetzt wieder bestätigt fühlen. Der Artikel führt aber am eigentlichen Problem vorbei. Ich arbeite in unserem System mit SSL-SNI. Darüber kann ich die eingehenden und ausgehenden TCP/IP-Anfragen über Port 443 gut managen ohne die Pakete groß aufbohren zu müssen. Wenn man jetzt ganz kritisch sein möchte, kann man bestimmte Services über zusätzliche Sicherheitszertifikate oder einen MAC-Adressen-Filter verwalten. Was verwendet ihr in euerem System?

  4. Re: Was ein Käse...

    Autor: MarcusK 10.10.19 - 16:09

    HGH schrieb:
    --------------------------------------------------------------------------------
    > Ich gebe Dir Recht! Eine Ganze Horde von schlechten Systemadministratoren
    > wird sich jetzt wieder bestätigt fühlen. Der Artikel führt aber am
    > eigentlichen Problem vorbei. Ich arbeite in unserem System mit SSL-SNI.
    > Darüber kann ich die eingehenden und ausgehenden TCP/IP-Anfragen über Port
    > 443 gut managen ohne die Pakete groß aufbohren zu müssen. Wenn man jetzt
    > ganz kritisch sein möchte, kann man bestimmte Services über zusätzliche
    > Sicherheitszertifikate oder einen MAC-Adressen-Filter verwalten. Was
    > verwendet ihr in euerem System?

    es wird bereits daran gearbeitet das SNI nicht mehr im Klartext zu übertragen.

  5. Re: Was ein Käse...

    Autor: HGH 10.10.19 - 17:21

    Wo ist das Problem wenn SNI nicht in Klartext übertragen wird?

  6. Re: Was ein Käse...

    Autor: delphi 11.10.19 - 06:20

    HGH schrieb:
    --------------------------------------------------------------------------------
    > Wo ist das Problem wenn SNI nicht in Klartext übertragen wird?

    Du kannst bei "eSNI" (encrypted SNI) von außen halt nicht mehr erkennen, zu welchem Hostname/VHost die TLS-Verbindung stattfindet (und das ist m.M.n auch gut so). Aus Firewall-Sicht wären theoretisch denkbare Ansätze für dieses Problem:

    - den Reverse-DNS-Namen des Servers, zu dem die Verbindung stattfindet, nehmen (Problem: in der Praxis hat bislang eigentlich nur Cloudflare eSNI implementiert, und bei denen wird der Reverse-DNS-Name so gut wie nie der Domain der angesurften Internetseite entsprechen)

    - versuchen, aus den DNS-Abfragen des Clients abzuleiten, welche Hostnamen potenziell in Frage kommen (ebenfalls nicht zuverlässig, da 1. der Client DNS-Antworten cached, d.h. nicht für jede TLS-Verbindung gibt es zwangsläufig vorher auch DNS-Abfragen, und 2. wird DNS im Browser, in Thunderbird und auf neuen Android-Geräten perspektivisch über HTTPS laufen, sodass du den DNS-Traffic ebenfalls nicht mehr inspizieren oder gar manipulieren kannst)

    - TLS per MITM-"Lösung" aufbrechen (schafft mehr Probleme, als es löst, was freilich unfähige "Enterprise"-Admins nicht davon abhält, es trotzdem zu tun)


    Wie man es auch dreht und wendet: Der Ansatz, Malwareinfektionen per DPI-Appliance zu verhindern (oder auch nur zuverlässig zu erkennen), ist (und war schon immer) zum Scheitern verurteilt - und in absehbarer Zeit wird dieser ganze DPI- und MITM-Nonsens durch das großflächige Ausrollen kryptografisch abgesicherter Netzwerkprotokolle endlich auch für den Traffic ganz normaler User technisch wirksam unterbunden (Malware konnten den ganzen DPI-Müll eh schon immer ohne nennenswerte Schwierigkeiten umgehen).

    Diese ganzen Bullshit-Appliances, die im Artikel so hoch gelobt werden, sind sicherheitstechnisch eigentlich selber eher ein großes Problem als ne Lösung. Da läuft auf irgendwelcher Embedded-Hardware, die sich im Gegensatz zu nem normalen Rechner bei Verdacht auf Malware-Befall nicht mal zuverlässig "neu installieren" lässt, schlecht gewartete Gammel-Firmware, die zum überwiegenden Teil zusammengewürfelt ist aus hoffnungslos veralteten Versionen genau derselben Software, die entweder auf den vorgeblich zu schützenden Servern im Regelfall in weniger veralteten Versionenständen installiert ist.

    Schlimmer noch: Weil die Firewall natürlich möglichst jedes noch so exotische Protokoll abdecken muss, um den Traffic "inspizieren" zu können, hat die Firewall im Regelfall schon inhärent eine sehr viel größere Angriffsfläche als die zu schützenden Rechner, völlig unabhängig von der Softwarequalität der Firmware. Und weil meist auch gleich ein Virenscanner eingebaut ist, vergrößert sich die ohnehin viel zu große Angriffsfläche nochmal zusätzlich, weil jetzt auch noch alle möglichen obskuren Dateiformate geparst werden müssen (im Regelfall passiert das auch wieder mit völlig veralteten Versionen bekannte OpenSource-Libraries), um darin vermeintliche "Anomalien" erkennen zu können.

    Und diesen Kernschrott lassen Leute jetzt in ihrem Firmennetz an zentraler/privilegierter Stelle, wo einmal jeder Traffic durch muss, laufen, und glauben dann ernsthaft, sie hätten irgendwas für die IT-Sicherheit im Unternehmen getan. In genau dieselbe Kategorie fällt übrigens auch die schlechte Idee "Virenscanner auf dem Mailserver laufen lassen" (oder alternativ "Virenscanner auf ner getrennten Maschine, die aber faktisch Zugriff auf alle Mails hat").

    Wenn man sich zum Beispiel mal die Firmware der durchaus verbreiteten UTM-Appliances von Sophos anschaut, dann sieht man, dass die als E-Mail-Proxyserver ne fünfeinhalb Jahre alte Version von Exim verwenden (4.82.1), die für den vorletzten RCE-CVE nur deswegen nicht verwundbar ist, weil sie den Traffic zufällig vorher noch durch ne andere Komponente durchleiten, die TLS-Header weglöscht, die sie nicht kennt. Und für den letzten CVE in Exim, der vor 1-2 Wochen veröffentlicht wurde, sind sie angeblich nicht verwundbar, weil der verwundbare Code erst mit dem Bugfix für nen anderen CVE vor nem Jahr in die Codebase von Exim eingeflossen ist.

    Auf den XG-Firewalls von Sophos läuft übrigens ebenfalls Exim für den "E-Mails analysieren"-Teil, allerdings ist die Exim-Version da wohl nur anderthalb Jahre alt.

    Sophos ist an der Stelle nur ein Beispiel - bei den andern Herstellern sieht es kein Stück besser aus. Und natürlich verwendet sowohl die Firmware auf diesen ganzen Appliances als auch das meiste Virenschutz-Software selber auch die ganzen Sicherheitsfeatures nicht, mit denen "normale" Software und moderne Betriebssysteme heutzutage üblicherweise daherkommen. Kein ASLR, kein PIC/PIE, keine Stack Canaries, kein RELRO (wundert auch nicht - wenn schon die Exim-Version über 5 Jahre alt ist, braucht es nicht viel Fantasie, um sich vorzustellen, wie alt wohl der Compiler ist, mit dem sie diese Exim-Version kompiliert haben).

    Aber wie gesagt, selbst wenn die systemischen Probleme mit gammeliger Firmware/AV-Software plötzlich auf magische Art gelöst wären, bliebe immer noch das Problem mit der inhärent viel zu großen Angriffsfläche dieser ganzen "Lösungen".

  7. Re: Was ein Käse...

    Autor: Iruwen 11.10.19 - 09:46

    Der ganze Artikel klingt wie vom Verband der UTM-Hersteller gesponsort.

  8. Re: Was ein Käse...

    Autor: spoink 12.10.19 - 13:09

    delphi schrieb:
    --------------------------------------------------------------------------------
    > -


    ist ja schön und gut, dann erklär doch mal, wie du ohne MITM Netzwerkverkehr scannen willst, um einen Webfilter durchzusetzen o.ä.
    zum rest: du sprichst hier beispielsweise ein emailfilter an. jetzt nimmst du da von mir aus eine anderes software die aktuellere versionen nutzt, irgendwie wirst du sie trotzdem analysieren wollen?
    und zB eine sophos ist in 15min wieder aufgesetzt, backup der config eingespielt (ggf noch die netzwerkadapterconfig anpassen, falls andre hardware) und läuft

    PS: was machst du beruflich und in welcher position, damit man deine aussagen einordnen kann?

  9. Re: Was ein Käse...

    Autor: quark2017 12.10.19 - 15:04

    @mifritscher
    @delphi

    Danke für eure Beiträge - die Aussagen kann man zu 100% unterstreichen!

    Leider sind im IT-Sicherheits-Management zu viele "Quereinsteiger" und BWLer mit gefährlichen eigenen Ansichten unterwegs. Dort gilt die Devise - wenn man zeigt, dass man "irgendwas plausibles" gemacht hat und anschließend mit dem Finger auf Jemand anderes zeigen kann, ist der Job erfüllt.

    Mit Sicherheit hat das Ganze dann leider nichts mehr zu tun :-(

  10. Re: Was ein Käse...

    Autor: SchrubbelDrubbel 12.10.19 - 20:16

    quark2017 schrieb:
    --------------------------------------------------------------------------------
    > @mifritscher
    > @delphi
    >
    > Danke für eure Beiträge - die Aussagen kann man zu 100% unterstreichen!
    >
    > Leider sind im IT-Sicherheits-Management zu viele "Quereinsteiger" und
    > BWLer mit gefährlichen eigenen Ansichten unterwegs.

    +1

  11. Re: Was ein Käse...

    Autor: delphi 16.10.19 - 19:39

    spoink schrieb:
    --------------------------------------------------------------------------------
    > ist ja schön und gut, dann erklär doch mal, wie du ohne MITM
    > Netzwerkverkehr scannen willst, um einen Webfilter durchzusetzen o.ä.

    Im Zweifelsfall gar nicht - wenn du als Admin gegen deine eigenen Nutzer arbeiten musst, dann hast du eh schon verloren.

    Wenn du aus irgendwelchen Gründen trotzdem unbedingt nen "Webfilter" haben zu müssen glaubst: Auf Netzwerkebene kann man den Traffic zu einzelnen Domains bislang noch vergleichsweise gut über nen eigenen DNS-Resolver, der die "verbotenen" Domains ausfiltert, unterbinden. Oder ansonsten ist z.B. eine Auswertung von SNI bei TLS-Verbindungen (bzw. bei unverschlüsseltem HTTP Auswertung des Host-Headers) denkbar (wobei sich das alles umgehen lässt - genauso wie sich auch bei MITM-Appliances in der Praxis *immer* Möglichkeiten ergeben, Traffic durchzutunneln, den die Appliance nicht erkennt und trotzdem durchlässt).

    > zum rest: du sprichst hier beispielsweise ein emailfilter an. jetzt nimmst
    > du da von mir aus eine anderes software die aktuellere versionen nutzt,
    > irgendwie wirst du sie trotzdem analysieren wollen?

    Nein. Ich halte den Ansatz "Virenscanner" für komplett gescheitert. Besonders bekloppt ist es aber natürlich, diesen Ansatz (Virenscanner, der alle möglichen exotischen Dateiformate "verstehen" können muss, um darin etwaige Malware finden zu können, und daher im Zweifelsfall eine größere Angriffsfläche aufweisen wird als die zu schützenden Rechner) auf einem Mailserver zu fahren, der prinzipbedingt 24/7 von jedem im Netz E-Mails entgegen nehmen muss (die dann auf einen Virenscanner mit absurd großer Angriffsfläche losgelassen werden).

    Mein Ansatz wäre es, die Mitarbeiter zu schulen, und z.B. unternehmensinterne Mails konsequent mit Signaturen (serverseitig mit DKIM, clientseitig mit S/MIME-Signaturen, optimalerweise mit Private Keys auf Smartcards) abzusichern, und darüber hinaus die Clientrechner und die ganze Netzwerkstruktur so auszulegen, dass die einzelnen Nutzer möglichst nur die wirklich nötigen, fein granulierten Zugriffsrechte haben (d.h. insbesondere mit Whitelisting von Installationspfaden arbeiten, wobei die normalen Nutzeraccounts natürlich für alle Pfade auf der Whitelist nur Lese und keine Schreibrechte haben dürfen), damit Malware möglichst wenig Schaden anrichten kann. Mit dem genannten Whitelisting-Ansatz lässt sich Schadcode im Optimalfall nur noch in Form von Exploits gegen bereits installierte Software auf der Whitelist ausführen - dagegen hilft, die installierte Software aktuell zu halten, und Sicherheitsupdates immer zügig (d.h. binnen weniger als 24h nach Erscheinen) zu installieren, und Sicherheitsupdates so weit wie möglich weg zu automatisieren.

    Dann gibt es noch Phishing. Die zuverlässigste Methode gegen Phishing ist meines Erachtens nicht, irgendwelche Voodoo-Scanner auf E-Mails oder den Browser-Traffic loszulassen, sondern dafür zu sorgen, dass es möglichst gar keine Passwörter mehr zu stehlen gibt - sowohl der Login am Betriebsystem, als auch am Mailserver, als auch bei Webapplikationen, als auch im WLAN oder Firmen-VPN, lässt sich seit Jahren problemlos mit X.509-Client-Zertifikaten anstatt Passworten abwickeln, und so gut wie immer kann man dabei dank PKCS#11 auch Smartcards verwenden.
    Bei Webanwendungen, wo das nicht geht, hilft es immer noch, nen Passwortmanager zu benutzen, der einem auf einer "fremden" Domain erst gar nicht anbietet, das gespeicherte Passwort ins Formular einzufüllen. Wenn man die Mitarbeiter entsprechend schult, dass sie in so einem Fall im Zweifel lieber erst jemanden aus der IT-Abteilung fragen, als zu riskieren, Logindaten an ne Phishing-Seite zu verlieren, hat man das Problem weitestgehend gelöst. Wem das nicht reicht, der sollte zusätzlich zu den Schulungen 1-2 mal pro Monat und Mitarbeiter mit Spearphishing-Mails nachprüfen, ob die Schulungen auch tatsächlich wirken, und Mitarbeiter, die solche Mails erkennen und sie an die IT-Abteilung melden, ggf. auch finanziell belohnen.

    > und zB eine sophos ist in 15min wieder aufgesetzt, backup der config
    > eingespielt (ggf noch die netzwerkadapterconfig anpassen, falls andre
    > hardware) und läuft

    Wenn ein normaler Rechner mit Malware infiziert ist, dann macht man ggf. die Festplatte platt und installiert das System neu. Bei ner Appliance mit irgend einem exotischen SoC und fest aufgelötetem NAND-Flash (den man als normalsterblicher weder auslesen noch zuverlässig löschen bzw. mit nem "known good"-Image überschreiben kann) geht das schlicht nicht. (Ja, theoretisch wäre auch Malware denkbar, die sich z.B. in der UEFI-Firmware eines Mainboards einnistet, aber in der Praxis ist sowas AFAIK bislang noch nicht vorgekommen). Daher: Wenn deine $Snakeoil-Appliance einmal von nem Angreifer kompromittiert ist, und du das auch wirklich rechtzeitig merkst (letzteres scheint mir sehr unwahrscheinlich), dann kannst du sie eigentlich nur noch wegschmeißen.


    > PS: was machst du beruflich und in welcher position, damit man deine
    > aussagen einordnen kann?

    Ich interessiere mich schlicht für das Thema.
    Ich arbeite zwar auch als Admin an ner großen Uni, und habe mir während meines abgebrochenen Studiums der IT-Sicherheit Kenntnisse zu kryptographischen Primitiven und Protokollen angeeignet, und habe im Rahmen meiner vor einigen Jahren erfolgreich abgeschlossenen Ausbildung zum FiSi auch mal die weitgehende fachliche Inkompetenz von Berufsschullehrern ertragen dürfen, aber letztlich sind formale Ausbildungen und Zertifikate im Bereich IT-Sicherheit IMHO nicht sonderlich viel wert. Den haarsträubendsten Unsinn höre ich da leider regelmäßig von den Leuten mit den tollsten Zertifizierungen und Studienabschlüssen - je enterprise, desto kaputter.

  12. Re: Was ein Käse...

    Autor: spoink 16.10.19 - 22:03

    Vorweg - man merkt durch und durch das, was du im letzten Absatz selbst beschreibst, aber dazu mehr. tl;dr: du hast theoretisch meist Recht!
    In der Praxis nicht.

    Auch soll das Folgende unter dem Aspekt KMU gesehen werden und nicht im Hochsicherheitsbereich.

    delphi schrieb:
    --------------------------------------------------------------------------------
    > spoink schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > ist ja schön und gut, dann erklär doch mal, wie du ohne MITM
    > > Netzwerkverkehr scannen willst, um einen Webfilter durchzusetzen o.ä.
    >
    > Im Zweifelsfall gar nicht - wenn du als Admin gegen deine eigenen Nutzer
    > arbeiten musst, dann hast du eh schon verloren.

    Theorie <-> Praxis. Und ich möchte hier gar nicht das GF-Argument bemühen, es reicht schon schlichte Unwissenheit. Oder auch nur das Argument Werbung blocken. Oder auch Streaming verhindern, da das enorm Leistung frisst.


    > Wenn du aus irgendwelchen Gründen trotzdem unbedingt nen "Webfilter" haben
    > zu müssen glaubst: Auf Netzwerkebene kann man den Traffic zu einzelnen
    > Domains bislang noch vergleichsweise gut über nen eigenen DNS-Resolver, der
    > die "verbotenen" Domains ausfiltert, unterbinden. Oder ansonsten ist z.B.
    > eine Auswertung von SNI bei TLS-Verbindungen (bzw. bei unverschlüsseltem
    > HTTP Auswertung des Host-Headers) denkbar (wobei sich das alles umgehen
    > lässt - genauso wie sich auch bei MITM-Appliances in der Praxis *immer*
    > Möglichkeiten ergeben, Traffic durchzutunneln, den die Appliance nicht
    > erkennt und trotzdem durchlässt).

    Wie du selbst sagst, sind das alles keine Lösungen, sondern wacklige Notbehelfe. Die harte Wahrheit ist leider: MITM auf der Firewall ist zwar vollkommen entgegen dem E2E Sinn, deswegen aber noch lange nicht unsicherer als ohne.


    > > zum rest: du sprichst hier beispielsweise ein emailfilter an. jetzt
    > nimmst
    > > du da von mir aus eine anderes software die aktuellere versionen nutzt,
    > > irgendwie wirst du sie trotzdem analysieren wollen?
    >
    > Nein. Ich halte den Ansatz "Virenscanner" für komplett gescheitert.
    > Besonders bekloppt ist es aber natürlich, diesen Ansatz (Virenscanner, der
    > alle möglichen exotischen Dateiformate "verstehen" können muss, um darin
    > etwaige Malware finden zu können, und daher im Zweifelsfall eine größere
    > Angriffsfläche aufweisen wird als die zu schützenden Rechner) auf einem
    > Mailserver zu fahren, der prinzipbedingt 24/7 von jedem im Netz E-Mails
    > entgegen nehmen muss (die dann auf einen Virenscanner mit absurd großer
    > Angriffsfläche losgelassen werden).

    Das ist deine persönliche Meinung, aber es ist eben genau das - eine Meinung (oder auch Unwissenheit oder aber Strohmannargument). Keine FW muss irgendwelche exotischen Anhänge kennen und analysieren, eine Whitelist genügt. Alles andere wird in die Quarantäne geworfen, fertig. Das funktioniert und wird auch so gehandhabt. Wie gut jetzt die internen Virtuellen Umgebungen sind, kann ich nicht beurteilen, aber die meisten aktuellen FWs machen das auf der eigenen Hardware bzw. in der eigenen Software (→ Cloud).

    > Mein Ansatz wäre es, die Mitarbeiter zu schulen, und z.B.
    > unternehmensinterne Mails konsequent mit Signaturen (serverseitig mit DKIM,
    > clientseitig mit S/MIME-Signaturen, optimalerweise mit Private Keys auf
    > Smartcards) abzusichern,

    Schulung ist nie ein absoluter Ansatz, sondern immer eine Zusatzmaßnahme (und ja, ich hab das jetzt bewusst umgedreht). Das Argument ist ebenfalls ganz einfach auszuhebeln: Selbst mir als extrem versierten IT Mensch kann ein Fehler unterlaufen und sei es im Stress oder sonstige Flüchtigkeitsfehler. Dagegen hilft keine Schulung. Signaturen helfen zudem nur gegen internes Phishing und den Aufwand von Smartcards, vor allem, wenn man nicht nur Fat Clients hat...
    Zudem: solang Lets Encrypt keine Mailzertifikate ausstellt, ist das ganze nach Extern sowieso zumeist witzlos.

    > und darüber hinaus die Clientrechner und die ganze
    > Netzwerkstruktur so auszulegen, dass die einzelnen Nutzer möglichst nur die
    > wirklich nötigen, fein granulierten Zugriffsrechte haben (d.h. insbesondere
    > mit Whitelisting von Installationspfaden arbeiten, wobei die normalen
    > Nutzeraccounts natürlich für alle Pfade auf der Whitelist nur Lese und
    > keine Schreibrechte haben dürfen), damit Malware möglichst wenig Schaden
    > anrichten kann. Mit dem genannten Whitelisting-Ansatz lässt sich Schadcode
    > im Optimalfall nur noch in Form von Exploits gegen bereits installierte
    > Software auf der Whitelist ausführen - dagegen hilft, die installierte
    > Software aktuell zu halten, und Sicherheitsupdates immer zügig (d.h. binnen
    > weniger als 24h nach Erscheinen) zu installieren, und Sicherheitsupdates so
    > weit wie möglich weg zu automatisieren.

    Ja, 802.11 und Applocker usw. sind tolle Sachen, die einen enormen Pflegeaufwand erfordern. Das gemeine an Applocker: wenn du mit ihm nicht wirklich 100% abdeckst, ist es schlussendlich trotzdem höchstens eine Verzögerung, keine Hinderung. Leider.
    Wobei das je nach Branche doch noch machbar ist und auch wirklich sinnvoll (ich möchte hier nicht das "keine Zeit" Argument strapazieren).

    > Dann gibt es noch Phishing. Die zuverlässigste Methode gegen Phishing ist
    > meines Erachtens nicht, irgendwelche Voodoo-Scanner auf E-Mails oder den
    > Browser-Traffic loszulassen, sondern dafür zu sorgen, dass es möglichst gar
    > keine Passwörter mehr zu stehlen gibt - sowohl der Login am Betriebsystem,
    > als auch am Mailserver, als auch bei Webapplikationen, als auch im WLAN
    > oder Firmen-VPN, lässt sich seit Jahren problemlos mit
    > X.509-Client-Zertifikaten anstatt Passworten abwickeln, und so gut wie
    > immer kann man dabei dank PKCS#11 auch Smartcards verwenden.
    > Bei Webanwendungen, wo das nicht geht, hilft es immer noch, nen
    > Passwortmanager zu benutzen, der einem auf einer "fremden" Domain erst gar
    > nicht anbietet, das gespeicherte Passwort ins Formular einzufüllen. Wenn
    > man die Mitarbeiter entsprechend schult, dass sie in so einem Fall im
    > Zweifel lieber erst jemanden aus der IT-Abteilung fragen, als zu riskieren,
    > Logindaten an ne Phishing-Seite zu verlieren, hat man das Problem
    > weitestgehend gelöst. Wem das nicht reicht, der sollte zusätzlich zu den
    > Schulungen 1-2 mal pro Monat und Mitarbeiter mit Spearphishing-Mails
    > nachprüfen, ob die Schulungen auch tatsächlich wirken, und Mitarbeiter, die
    > solche Mails erkennen und sie an die IT-Abteilung melden, ggf. auch
    > finanziell belohnen.

    Naja, es geht nicht nur um Passwortdiebstahl. Und auch hier wieder die in der Theorie extrem geschulten MA, die es in der Praxis nicht gibt. Stell dir als Beispiel vor, wie viel du von der letzten ISO Schulung oder Arbeitssicherheitsschulung noch weißt...

    > > und zB eine sophos ist in 15min wieder aufgesetzt, backup der config
    > > eingespielt (ggf noch die netzwerkadapterconfig anpassen, falls andre
    > > hardware) und läuft
    >
    > Wenn ein normaler Rechner mit Malware infiziert ist, dann macht man ggf.
    > die Festplatte platt und installiert das System neu. Bei ner Appliance mit
    > irgend einem exotischen SoC und fest aufgelötetem NAND-Flash (den man als
    > normalsterblicher weder auslesen noch zuverlässig löschen bzw. mit nem
    > "known good"-Image überschreiben kann) geht das schlicht nicht. (Ja,
    > theoretisch wäre auch Malware denkbar, die sich z.B. in der UEFI-Firmware
    > eines Mainboards einnistet, aber in der Praxis ist sowas AFAIK bislang noch
    > nicht vorgekommen). Daher: Wenn deine $Snakeoil-Appliance einmal von nem
    > Angreifer kompromittiert ist, und du das auch wirklich rechtzeitig merkst
    > (letzteres scheint mir sehr unwahrscheinlich), dann kannst du sie
    > eigentlich nur noch wegschmeißen.

    Wie gesagt, zum einen laufen die auf "normalen" Servern oder aber einfach virtuell auf deiner bestehenden Infrastruktur, da ist nix mit exotischem SoC und NAND Flash und Disketten. Wenn sich die Malware in das virtuelle BIOS rein frisst ist das beim Aufsetzen einer neuen VM egal.

    >
    > > PS: was machst du beruflich und in welcher position, damit man deine
    > > aussagen einordnen kann?
    >
    > Ich interessiere mich schlicht für das Thema.
    > Ich arbeite zwar auch als Admin an ner großen Uni, und habe mir während
    > meines abgebrochenen Studiums der IT-Sicherheit Kenntnisse zu
    > kryptographischen Primitiven und Protokollen angeeignet, und habe im Rahmen
    > meiner vor einigen Jahren erfolgreich abgeschlossenen Ausbildung zum FiSi
    > auch mal die weitgehende fachliche Inkompetenz von Berufsschullehrern
    > ertragen dürfen, aber letztlich sind formale Ausbildungen und Zertifikate
    > im Bereich IT-Sicherheit IMHO nicht sonderlich viel wert. Den
    > haarsträubendsten Unsinn höre ich da leider regelmäßig von den Leuten mit
    > den tollsten Zertifizierungen und Studienabschlüssen - je enterprise, desto
    > kaputter.

    Und um hier nochmal den Kreis zu schließen: das merkt man, nicht bös gemeint. Alles davon ist der Idealfall und jeder würde sich wünschen, so ein System zu haben, in der Praxis gibt es wahrscheinlich kein einziges. FiSi sagt mir leider nichts.
    Und wie gesagt, die Argumente Geschäftsführung, Budget, Manpower, Ressourcen habe ich noch außen vor gelassen!

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Höchstleistungsrechenzentrum Universität Stuttgart HLRS, Stuttgart
  2. Erwin Hymer Group SE, Bad Waldsee
  3. DATAGROUP Köln GmbH, Köln
  4. GELSENWASSER AG, Gelsenkirchen

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (-12%) 52,99€
  2. 3,99€
  3. 12,99€
  4. 17,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


iPad 7 im Test: Nicht nur für Einsteiger lohnenswert
iPad 7 im Test
Nicht nur für Einsteiger lohnenswert

Auch mit der siebten Version des klassischen iPads richtet sich Apple wieder an Nutzer im Einsteigersegment. Dennoch ist das Tablet sehr leistungsfähig und kommt mit Smart-Keyboard-Unterstützung. Wer ein gutes, lange unterstütztes Tablet sucht, kann sich freuen - ärgerlich sind die Preise fürs Zubehör.
Ein Test von Tobias Költzsch

  1. iPad Einschränkungen für Apples Sidecar-Funktion
  2. Apple Microsoft Office auf neuem iPad nicht mehr kostenlos nutzbar
  3. Tablet Apple bringt die 7. Generation des iPads

Rohstoffe: Lithium aus dem heißen Untergrund
Rohstoffe
Lithium aus dem heißen Untergrund

Liefern Geothermiekraftwerke in Südwestdeutschland bald nicht nur Strom und Wärme, sondern auch einen wichtigen Rohstoff für die Akkus von Smartphones, Tablets und Elektroautos? Das Thermalwasser hat einen so hohen Gehalt an Lithium, dass sich ein Abbau lohnen könnte. Doch es gibt auch Gegner.
Ein Bericht von Werner Pluta

  1. Wasserkraft Strom aus dem Strom
  2. Energie Wie Mikroben Methan mit Windstrom produzieren
  3. Erneuerbare Energien Die Energiewende braucht Wasserstoff

Mädchen und IT: Fehler im System
Mädchen und IT
Fehler im System

Bis zu einem gewissen Alter sind Jungen und Mädchen gleichermaßen an Technik interessiert. Wenn es dann aber um die Berufswahl geht, entscheiden sich immer noch viel mehr junge Männer als Frauen für die IT. Ein wichtiger Grund dafür ist in der Schule zu suchen.
Von Valerie Lux

  1. IT an Schulen Intelligenter Stift zeichnet Handschrift von Schülern auf
  2. 5G Milliardenlücke beim Digitalpakt Schule droht
  3. Medienkompetenz Was, Ihr Kind kann nicht programmieren?

  1. Proteste in Hongkong: Hochrangige US-Politiker schreiben an Activision und Apple
    Proteste in Hongkong
    Hochrangige US-Politiker schreiben an Activision und Apple

    Alexandria Ocasio-Cortez, Marco Rubio und weitere Politiker der großen US-Parteien haben offene Briefe an die Chefs von Activision Blizzard und Apple geschrieben. Sie fordern darin, dass die Firmen nicht mehr die chinesische Regierung in deren Kampf gegen die Proteste in Hongkong unterstützen.

  2. Wing Aviation: Kommerzielle Warenlieferung per Drohne in USA gestartet
    Wing Aviation
    Kommerzielle Warenlieferung per Drohne in USA gestartet

    In den USA hat das zu Alphabet gehörende Unternehmen Wing Aviation die ersten Bestellungen per Drohne an Kunden ausgeliefert - unter anderem Schnupfenmittelchen.

  3. Office und Windows: Microsoft klagt gegen Software-Billiganbieter Lizengo
    Office und Windows
    Microsoft klagt gegen Software-Billiganbieter Lizengo

    Auffallend günstige Keys für Office 365 und Windows 10 bei Anbietern wie Edeka sind möglicherweise nicht legal. Nun geht Microsoft gegen Lizengo vor, einen der größten Anbieter solcher Software.


  1. 14:43

  2. 13:45

  3. 12:49

  4. 11:35

  5. 18:18

  6. 18:00

  7. 17:26

  8. 17:07