Das längste Thema

  • Reicht es denn nicht schon aus, wenn entweder während der Installation oder nach der Installation des Betriebssystems auf dem Betriebssystem die primäre Schnittstelle deaktiviert wird?

    was man per Software deaktiviert, kann auch durch ein Trojanisches Pferd wieder aktiviert werden;

    hat aber der KVM-Guest keine Ahnung von dieser Schnittstelle, ist es für ein Trojanisches Pferd schon schwierig, hier ran zu kommen ;)

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

    Edited 2 times, last by mainziman ().

  • :?:

    Naja, den letzten angepassten Kernel habe ich vor Jahren kompiliert und mit BSD gehe ich auch nicht regelmäßig um, daher finde ich schon krass, dass eine KI mir effektiv einen Arm64-Kernel unter BSD zusammenbaut.


    Allerdings auch irgendwie beängstigend was diese KIs können.

  • Machen wir in der Schule mal einen Test:


    BSD

    Wählen Sie eine BSD:

    • OpenBSD
    • FreeBSD
    • NetBSD
    • DragonflyBSD
    • 4.4BSD


    Um die ganzen Parameter zu finden

    Welche Parameter haben Sie genutzt, welche haben Ihnen Schwierigkeiten bereitet?



    Allerdings auch irgendwie beängstigend was diese KIs können.

    POSIX-Shell können die Dinger tatsächlich ganz gut, sofern die richtig konfiguriert sind.

    Warum findest du das beängstigend?

  • WH 8000 SE BF22, Mikro G11s, VPS 500G11s BW24, VPS1000 G11 JA24, RS1000 G11, RS2000 G11 EM24


    Ich lebe im Netzwerk, ihr findet mich unter der IP-Adresse: 127.0.0.1

  • Ist ein FreeBSD. Die ehrliche Antwort lautet: Alle, weil ich normal Standard-Kernel verwende und keinen Kernel selbst baue. Das hat die KI sehr schön rausgesucht. Das Problem vor dem ich derzeit noch stehe ist die richtige Ed2k-Datei für das Image zu finden. Aber wenn ich das richtig verstehe, gibt es da nichts, das für die Ampere Altra Amd64 angepasst wurde und deshalb benutzen alle generische Ovmf-Dateien aus dem Tianocore-Projekt für UEFI. Da das Richtige zu finden, stellt sich selbst mit KI als etwas schwierig heraus.


    Nunja, wenn die KIs das praktisch so zusammenbasteln, hat das ja schon recht weitreichende Implikationen. Das geht ja dann doch weit über "Bau mir mal ein Bild" oder "Schreib mal einen Aufsatz zu..." hinaus. Finde ich schon beeindruckend. Und auch nicht ungefährlich in der Richtung.

  • Da würde ich mich jetzt nicht darauf verlassen.

    Warum nicht? Ich mache das exakt so. Das Interface mit der öffentlchen IP ist bei mir abgeschaltet, während die andere NIC mit dem VLAN aktiv ist. Gab noch nie Probleme damit.


    Und wenn man wirklich Angst davor hat, dass ein Bug das Interface wieder aktiv schaltet, dann könnte man immer noch den DHCP Client vollständig deaktivieren oder einfach das Interface statisch mit einer RFC1918 Adresse austatten. Abgesehen davon ändert sich ja auch am Routing nichts. Selbst wenn die NIC wieder aktiv wird und bei der NIC die öffentliche IP Adresse eingerichtet ist, dann wird ja trotzdem alles über die VLAN NIC geroutet (falls das Default Gateway korrekt gesetzt ist). Und wenn man ganz paranoid ist, dann kann man notfalls das Interface mit iptables zusätzlich blacklisten.


    Da müssten schon ganz schön viele Bugs auf einmal auftreten, damit da was blödes passiert. Natürlich wäre es am schönsten, wenn man die öffentliche NIC abschalten bwz. löschen kann. Einen Vorteil sehe ich allerdings nur darin, dass man sich die öffentliche IP sparen könnte.

  • Warum nicht? Ich mache das exakt so. Das Interface mit der öffentlchen IP ist bei mir abgeschaltet, während die andere NIC mit dem VLAN aktiv ist. Gab noch nie Probleme damit.


    Und wenn man wirklich Angst davor hat, dass ein Bug das Interface wieder aktiv schaltet, dann könnte man immer noch den DHCP Client vollständig deaktivieren oder einfach das Interface statisch mit einer RFC1918 Adresse austatten. Abgesehen davon ändert sich ja auch am Routing nichts. Selbst wenn die NIC wieder aktiv wird und bei der NIC die öffentliche IP Adresse eingerichtet ist, dann wird ja trotzdem alles über die VLAN NIC geroutet (falls das Default Gateway korrekt gesetzt ist). Und wenn man ganz paranoid ist, dann kann man notfalls das Interface mit iptables zusätzlich blacklisten.


    Da müssten schon ganz schön viele Bugs auf einmal auftreten, damit da was blödes passiert. Natürlich wäre es am schönsten, wenn man die öffentliche NIC abschalten bwz. löschen kann. Einen Vorteil sehe ich allerdings nur darin, dass man sich die öffentliche IP sparen könnte.

    Schön wäre es, wenn man die IPv4 dann nicht unbenutzt lassen müsste, sondern an eine andere Maschine vergeben könnte. Damit ließen sich ja schöne Dinge basteln. Das wäre dann auch eine gute Lösung um diese Befürchtungen auszuräumen. Allerdings habe ich solche nicht, obwohl ich vermutlich selbst in die Rubrik latent paranoid falle, was Sicherheitsaspekte angeht. ^^

  • Warum nicht? Ich mache das exakt so. Das Interface mit der öffentlchen IP ist bei mir abgeschaltet, während die andere NIC mit dem VLAN aktiv ist. Gab noch nie Probleme damit.


    Und wenn man wirklich Angst davor hat, dass ein Bug das Interface wieder aktiv schaltet, dann könnte man immer noch den DHCP Client vollständig deaktivieren oder einfach das Interface statisch mit einer RFC1918 Adresse austatten. Abgesehen davon ändert sich ja auch am Routing nichts. Selbst wenn die NIC wieder aktiv wird und bei der NIC die öffentliche IP Adresse eingerichtet ist, dann wird ja trotzdem alles über die VLAN NIC geroutet (falls das Default Gateway korrekt gesetzt ist). Und wenn man ganz paranoid ist, dann kann man notfalls das Interface mit iptables zusätzlich blacklisten.


    Da müssten schon ganz schön viele Bugs auf einmal auftreten, damit da was blödes passiert. Natürlich wäre es am schönsten, wenn man die öffentliche NIC abschalten bwz. löschen kann. Einen Vorteil sehe ich allerdings nur darin, dass man sich die öffentliche IP sparen könnte.

    Wie gesagt, alles was du deaktivierst, kann auch wieder aktiviert / umgeschrieben werden. Diverse Cloud-Anbieter geben eben deshalb die Möglichkeit VMs ohne Public IP zu erstellen um dann eben mittels VLANs und eigener Firewall sich abzusichern oder bieten ein NAT Gateway an. Wenn du da z.B. dann Tailscale nutzt, ist per se von aussen nach innen nichts direkt erreichbar.

  • Durch Bugs / Windows / Schadsoftware kann jederzeit das Interface wieder hochgefahren werden und dank DHCP ist es auch direkt im Netz.


    Da würde ich mich jetzt nicht darauf verlassen.

    Solche oder ähnliche Probleme kann man auch bekommen, wenn vom Server die WAN-Schnittstelle weggenommen wurde. Denn irgendwann müssen auf dem Server auch mal wieder Updates eingespielt werden, die entweder gleich über das WAN bezogen werden oder vom WAN auf irgendeinen Server zwischengeparkt und dann erst auf dem Zielserver eingespielt werden.

  • Du hast in weniger als 24h eine Antwort und eine Lösung vom Support erhalten?

    External Content www.youtube.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.


    Duck und weg.

  • Wie gesagt, alles was du deaktivierst, kann auch wieder aktiviert / umgeschrieben werden.

    Natürlich kann das wieder aktiviert werden. Aber sicherlich nicht durch ein Bug im System bzw. es müssten dann schon mehrere kritische Bugs sein die gleichzeitig auftreten. In solch einem Fall würde ich grundsätzlich das verwendete Betriebsystem in Frage stellen. Und sollte Schadsoftware auf dem Server sein, dann hast du grundsätzlich verloren. Dann ist es ohnehin egal, ob der Server direkt oder über eine Firewall seine Verbindung ins Internet nimmt.


    Ansonsten hast du natürlich Recht. Viel schöner und "richtiger" wäre es, wenn man die Server auch nur mit dem VLAN NIC betreiben könnte. Dann kann der Kunde (und auch Netcup) die öffentliche IPv4 Adresse sparen. Mir ging es aber nur um den Sicherheitsaspekt, dass man die Server trotz der abgeschalteten NIC mit der öffentlichen IP sicher und ohne jegliche Bedenken betreiben kann.

  • Natürlich kann das wieder aktiviert werden. Aber sicherlich nicht durch ein Bug im System bzw. es müssten dann schon mehrere kritische Bugs sein die gleichzeitig auftreten. In solch einem Fall würde ich grundsätzlich das verwendete Betriebsystem in Frage stellen. Und sollte Schadsoftware auf dem Server sein, dann hast du grundsätzlich verloren. Dann ist es ohnehin egal, ob der Server direkt oder über eine Firewall seine Verbindung ins Internet nimmt.


    Ansonsten hast du natürlich Recht. Viel schöner und "richtiger" wäre es, wenn man die Server auch nur mit dem VLAN NIC betreiben könnte. Dann kann der Kunde (und auch Netcup) die öffentliche IPv4 Adresse sparen. Mir ging es aber nur um den Sicherheitsaspekt, dass man die Server trotz der abgeschalteten NIC mit der öffentlichen IP sicher und ohne jegliche Bedenken betreiben kann.

    Ich sage nur Firewalls. Wir setzen in der Bude lauter Fortigates ein. Ich hab aufgehört die RCEs zu zählen, die es gab in den letzten Monaten, die eine feindliche Übernahme ermöglicht hätten. Jetzt kann man natürlich Fefe spielen und jeden von uns Idiot nennen, weil man sowas einsetzt (was wäre denn die Alternative anyway, jeder Vendor hat Bugs), aber ich kann dir auch sagen, dass man im KRITIS Bereich oft sogar 2 Firewalls hintereinander einsetzt von unterschiedlichen Herstellern, um genau das zu mitigieren. Aber ich traue mich selbst als ITler nie etwas aus unwahrscheinlich zu bezeichnen, weil heute einfach viel zu viel von allem abhängig ist (Libraries etc)

  • Ich sage nur Firewalls.

    Genau das mache ich auch. Auch hier bei Netcup. Ich habe zwei Server. Auf dem einen läuft ein Mikrotik CHR. Und dann habe ich einen Backend Server. Beim Backend Server ist die NIC mit der öffentlichen IP abgeschaltet. Bei der VLAN NIC gibt es eine statische RFC1918 Adresse und das Default Gateway zeigt auf die interne IP des Mikrotiks.


    Dadurch ist mein Backend Server nicht mehr für die Ausenwelt erreichbar. Somit sind auch keine Angriffe von extern möglich.


    Damit mein Server wieder öffentlich erreichbar ist, müssten es drei Bugs geben:


    - Ein Bug müsste die öffentliche NIC wieder aktivieren

    - Ein Bug müsste den DHCP Client aktivieren

    - Der letzte Bug müsste dann die administrative Distanz im Netzwerk Stack manipulieren damit man die statische Route umgeht. Denn statisches Routing hat eine höhere Wichtung als Dynamisches bzw. DHCP.


    Oder übersehe ich was?


    Edit: Kleiner Nachtrag noch. Du musst mir nicht erklären, was eine Firewall ist und warum diese eigentlich Standard in jedem Netzwerk sein sollte. Mir ging es wirklich nur um den einen Kommentar, warum man eine softwareseitig abgeschaltete NIC nicht vertrauen kann. Das halte ich nach wie vor für falsch. Wenn ihr das anders seht, dann freue ich mich über euer Feedback. Denn aktuell betreibe ich das so wie beschrieben und ich hatte nie Probleme damit (und ich sehe damit auch weiterhin keine Probleme). Deshalb wäre mir Feedback umso wichtiger, falls das jemand anders sieht. Aber bitte mit Begründung. :)

  • Ich hatte gar nicht versucht eine Firewall zu erklären oder zu sagen, dass dein Setup schlecht ist ;) Ich wollte nur sagen, dass eine öffentliche NIC halt öffentlich bleibt, solange sie nicht am Hypervisor auf der VM deaktiviert wird.

  • weil da schon so seltsames diskutiert wird;


    nur mal eine Verschwörungstheorie ...

    da ja beklannt ist, was ACME wirklich heißt, mal folgendes in den Raum geworfen,

    wäre es denkbar, dass bereits die längste Zeit ein nicht öffentliches Protokoll - nennen wir es einfach IPvX - zum Einsatz kommt,

    mit welchem die NSA, CIA, und sonstige Saftläden ohnehin bereits sämtiche Daten zu sich holen/geholt haben,

    und das durch 10 Firewalls - es ein Fortknox nur im Traum gibt - ...


    der Headquarter der Chip-Hersteller sitzt in den USA

    der Headquarter der Speicher und Festspeicher (SSD, HDD) sitzt ebenfalls in den USA

    der Headquarter der Netzwerkinterfaces/-technologie sitzt auch in den USA

    oder anders - alles hat Teile mit Verbindung zur USA;


    jetzt wird jeder meinen - ich hab doch z.B. 200 MBit/s Bandbreite und die zeigen mir auch diverse Programme an,

    wenn ich was downloade, iperf od. sonstiges veranstalte ...

    klar, dass das aber vlt. 250 MBit/s und eben weil alles mit den USA verbündet ist,. diese 50 MBit/s

    dazu verwendet werden Daten zur NSA zu 'backupen' ...


    Wie kann das Gegenteil davon bewiesen werden?


    VW war beim Dieselgate nur dumm; dass des was hinten bei den Kisten rauskommt offensichtlich ist,

    hätten sie sich denken können, dass des auffliegt;

    aber bei Daten im Kabel? sieht ma ja nichts;

    nicht jetzt mit Oszilloskop od. so kommen, des Zeug ist auch mit den USA verbündet;

    Wireshark - ist nur Software - da ist des a paar Schichten darunter weggefiltert, also sieht ma auch dort nichts;

    (würdeste bei uns alles ins All schießen, des mit den USA in Verbindung steht, bleiben bis auf a paar alte Säcke nicht viel übrig)


    nachdem was es in den USA an "Datencentern" gibt, und da sind ja nicht a paar TBytes, sondern a bissi mehr ...

    und in Summe sind des doch a gewaltige Menge an Daten;

    gibt es verläßliche Zahlen darüber - nur welche Datenmenge - alleine bei Google,

    bei Facebook, bei Apple, bei Microsoft, ... parken?

    manches vielleicht sogar völlig offline auf Bändern irgendwo in einem Berg;


    Google bietet jeder Android-Heizflosse 15 GByte an Backupspeicher an, und davon gibts auch a gewaltige Menge ...

    wenn jeder den Speicher nutzt, dann haste da ja alleine Zig.-Mrd.en von GBytes;

    und das sind nur die Backups ...

    --------------------------

    Vielleicht sollten halt doch die Verantwortliches daran denken, dass es bei gewissen Dingen

    einfach nur kompletter Schwachsinn ist, des ins Netz zu stellen, und IoT damit nur krank ist;


    dass der Pfarrer seine Kirchenglocken per Smartphone bedienen kann ist ja nett, aber der Faule Sack kann ruhig a paar Meter gehen

    und einen Schalter betätigen, weil dann würde ich aus ökologischen Gründen folgendes empfehlen:

    a schwarzer Pyjama, a schwarze Bettwäsche und der Gottesdienst kann gleich vom Bett des Faulen Sacks per

    Video-Konferenz stattfinden; dann braucht es überhaupt keinen Betschuppen mehr, und das Gejammere

    die alten Buden kosten unsummen an Kohle sie zu erhalten ist dann auch Geschichte :D

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

    Edited once, last by mainziman ().