Box absichern / Hardening

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Box absichern / Hardening

      VTI image absichern...

      Shell-Script

      1. #root passwort setzen
      2. passwd
      3. #smb share nur mit login
      4. vi /etc/samba/smb.conf
      5. public = no
      6. guest ok = no
      7. /etc/init.d/samba restart
      8. #telnet aus
      9. vi /etc/inetd.conf
      10. #telnet stream tcp nowait root /usr/sbin/telnetd telnetd
      11. #ftp aus
      12. vi /etc/inetd.conf
      13. #ftp stream tcp nowait root /usr/sbin/vsftpd vsftpd
      14. #webshell aus
      15. update-rc.d -f shellinabox.sh remove
      16. #ssl only für openwebif??
      17. #ssh root nur mit key
      18. #key hinterlegen
      19. /etc/dropbear/authorized_keys
      20. #passwort login verbieten
      21. vi /etc/default/dropbear
      22. DROPBEAR_EXTRA_ARGS="-g -s"
      23. /etc/init.d/dropbear restart
      24. #checken mit
      25. netstat -anplute
      Alles anzeigen
      VTi 15.0.0 (2020-09-21-vti-master (8207afb95)) ohne Gewähr
      Skin: Fluid Next
      AEL
      eniglight
      Vodafone Kabel
    • Die Idee finde ich sehr gut, auch wenn hier einige Admins/Moderatoren immer dagegen schießen.
      Schön wäre auch zusätzlich eine kurze Anleitung für unbedarfe User, die die Auswirkungen der Befehle beschreibt. Vielleicht auch unterteilt in Standartsicherheit (wie sie leider nicht in VTI Standart ist) und Fort Knox.
    • Ansatz finde ich gut; nur zwei Anmerkungen dazu:
      - FTP ausschalten sorgt dafür, dass einiges an beliebten Plugins nicht mehr funktioniert (z.B. Remote-Channel-Einrichtung). Dann muss auch für diese Plugins eine Alternative geschaffen werden.
      - Der beste Schutz ist immer noch, keine offene Portweiterleitung auf dem Router einzurichten, die einem potenziellen Angreifer null Hindernis in den Weg legt. Immer mit einem abgesicherten VPN-Tunnel arbeiten. Immer.

      Ansonsten fällt mir noch ein:
      - Software aktuell halten. Leider passiert auf der Ebene im VTi nicht viel. OpenSSL z.B. ist - selbst wenn weiterhin die Version 1.0.2 benutzt werden soll, etliche Jahre mit Patches hinten dran. Wenn ich suche, finde ich mehr (man muss nur auf FTP, Samba schauen).

      Die große Krux ist, dass es keine öffentlich zugänglichen Sourcen für den SoC gibt, so dass man evtl. selber auf Basis von Debian wenigstens den Unterbau aktuell halten könnte.
      Diskutiere nie mit einem Idioten. Er zieht dich auf sein Niveau runter und schlägt dich mit seiner Erfahrung.
    • Astex schrieb:

      Die Idee finde ich sehr gut, auch wenn hier einige Admins/Moderatoren immer dagegen schießen.
      Wo denn? ?(
    • War zumindest früher so. Da kamen dann auch schon oft nicht hilfreiche Antworten wie Welche Maßnahmen kann man ergreifen um die Sicherheit ein Box zu erhöhen?“Hast du so böse Mitbewohner, dass du dir soviel Sorgen um die Sicherheit im LAN machen musst?“. Das kann natürlich auch bloß eine Floskel gewesen sein. Aber die Summe an solchen Antworten schreckt dann den Fragesteller(man sieht es auch an seinen Rechtfertigungen) und andere z.B. mich ab. Das Thread war nicht das einzige Mal, ist mir jetzt bei der Suche als erstes begegnet.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von hgdo () aus folgendem Grund: Link repariert

    • @hgdo,

      sowas wo Admin (s) dagegen geschoßen haben ist natürlich schwer zu finden, wenn sich ein Admin wie plnick ins Nirvana schießt und sich in removed umbenennt. Das erschwert die Suche nach solchen Beiträgen. ;)
      Gruß

      Jürgen

      _________

      DUO 4K
      DVB-S2x FBC Unicable IDLU-32UL40-UNBOO-OPP
      UNO 4K SE DVB-S2x FBC DUR-Line UK 124
      SOLO 4K DVB-S2 FBC Unicable IDLU-32UL40-UNBOO-OPP

      VTi 15.0.0

      AX61 HD OpenATV 7.1



    • Ich kann mich nicht daran erinnern, dass dagegen „geschossen“ wurde.

      Und das Beispiel oben ist jawohl völlig daneben. Das ist nicht mehr als meine persönliche Einstellung, dass ich das nicht brauche und auch nicht ganz verstehe, dass andere das brauchen.
    • Ich erinnere mich schon, aber ich weiß wie der Thread ausgeartet ist und deswegen lass ich es hiermit sein. ;)
      Gruß

      Jürgen

      _________

      DUO 4K
      DVB-S2x FBC Unicable IDLU-32UL40-UNBOO-OPP
      UNO 4K SE DVB-S2x FBC DUR-Line UK 124
      SOLO 4K DVB-S2 FBC Unicable IDLU-32UL40-UNBOO-OPP

      VTi 15.0.0

      AX61 HD OpenATV 7.1



    • rdamas schrieb:

      Ansonsten fällt mir noch ein:
      - Software aktuell halten. Leider passiert auf der Ebene im VTi nicht viel. OpenSSL z.B. ist - selbst wenn weiterhin die Version 1.0.2 benutzt werden soll, etliche Jahre mit Patches hinten dran.

      Ja. Aus diesem Grund hier nochmal der Hinweis:
      Unter dem nachfolgenden Link betreibe ich mein eigenes Repo, es besteht überwiegend aus Paketen, welche ich hier im Forum zusammengesucht und getestet habe:
      github.com/cfdisk/vti-banana-mipsel

      Da ich keine ARM Box habe, leider nur MIPSel :(

      Ein Großteil der Probleme mit VTi-Uralt-Paketen könnten wir als "Community" selber lösen.
    • Ich habe mir auf meiner Solo4k den GCC eingerichtet und übersetze damit eine ganze Reihe von Programmen selber, inzwischen mache ich daraus vor der Installation auch so gut immer ein Paket. ARM-Pakete kann ich beitragen.

      Spoiler anzeigen

      Ich baue regelmäßig folgende Pakete neu, falls es in deren Git-Repos neue Release-Tags gibt:
      acl, autoconf, automake, bash, binutils + gdb, bison, coreutils, cssselect, cython, e2fsprogs, gawk, gcc, git, gnuchess, grep, hostap, inotify-tools, iperf, less, lxml, lz4, make, openssh-portable, patch, patchelf, python-six, rsync, screen, sed, smartmontools, Stockfish, tcpdump, tmux, vim, xxHash, youtube-dl, zstd.

      Zu einer Reihe weiterer Programme habe ich keine Repository-Checkouts, aber trotzdem aktuelle(re) Pakete als das VTi, z.B.: joe, ncat + nmap, scrub, vsftpd
      Diskutiere nie mit einem Idioten. Er zieht dich auf sein Niveau runter und schlägt dich mit seiner Erfahrung.
    • Etwas OT:
      @rdamas
      Oha, das ist ja schon mal eine beeindruckende Paket-Liste! :thumbsup:

      Für mich schreit das förmlich nach einem Aufruf an alle, die sich ihre eigenen Pakte bauen; Solche Energien sollten wir irgendwie bündeln, und als Repository öffentlich machen. (Ich wünsche mir sowas schon seit Jahren)

      Was mir dabei allerdings etwas Bauchschmerzen bereitet; Wenn man sowas ernsthaft hochziehen möchte, braucht es "Men/Women-Power" in Form von Paket-Maintainern, Repo-Admins, Support(!), Tester(!!)... einfach Leute, die ihre Zeit und ihr Wissen investieren.
      Ich wäre da gerne bereit, mitzuwirken. Aber definitiv nicht als 2-3 Men-Show.

      Um noch etwas On-Topic beizutragen: Die Konfigurationen in Thread #1 lassen sich fast alle relativ einfach in ein Paket auslagern. Oder vielleicht noch besser: in ein Plugin, sofern da ein Python-Progger die Muse hat.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Banana Joe ()

    • @Banana Joe verstehe ich das richtig, Du kompilierst für die Mipsel Boxen Pakete/Libraries die im VTI verwendet werden und dort allerdings veraltet sind?
      Wie kompilierst Du die denn, bzw. ladest Du Dir die sourcen runter und kompilierst die dann unter einem virtuellen PC unter ubuntu 12.04 mit OpenVu 3.0?

      Über die viel größere Frage sich mir aufdrängt, wenn Du Dir diese Arbeit machst, diverse libraries aus Securitygründen upzudaten, warum finden die dann nicht den Weg in ein update zu VTI?

      Danke, jedenfalls für das Teilen :)
    • viebrix schrieb:

      verstehe ich das richtig, Du kompilierst für die Mipsel Boxen Pakete/Libraries die im VTI verwendet werden und dort allerdings veraltet sind?
      Nein, die Pakete stammen überwiegend hier aus dem VTi Forum. Ich habe nur irgendwann angefangen, diese zusammenzutragen.
      Ich habe auch eigentlich auch nicht vor, dafür alleine den Paket Maintainer zu spielen, dafür lohnt der Aufwand sicherlich nicht.

      viebrix schrieb:

      Über die viel größere Frage sich mir aufdrängt, wenn Du Dir diese Arbeit machst, diverse libraries aus Securitygründen upzudaten, warum finden die dann nicht den Weg in ein update zu VTI?

      VTi wird mit Sicherheit keine fertig kompilierte Pakete in ihren offiziellen Feed aufnehmen.


      Daher ist es ja bei Linux Distros üblich, einfach externe Repositories einzubinden, die unabhängig von dem Support/Garantie/Lizenzpolitik/Irgendwas des Basissystems sind.
    • hmm vielleicht verstehe ich es jetzt ganz falsch, aber eigentlich habe ich angenommen, dass VTI ein Image ist, welches zB openSSL mit der Image Installation mitliefert. Also als User würde ich dann davon ausgehen, dass wenn OpenSSL eine Sicherheitslücke hat, dann das Image (in dem Fall VTI) ein Update bringt, welches die Lücke schließt. So wie auch andere Linux Maintainer. hmm zumindest bei Linux Mint bin ich es gewohnt, dass hier die Updates automatisch geliefert werden. Ob diese jetzt von einem darunterliegendem Basissystem oder vom Distrohersteller selbst überarbeitet wurden. Aber ich bin da auch recht neu in Linux, hab das erst seit 1/2 Jahr.
      Jedenfalls soweit ich es verstanden habe dürfte nur ein relativ altes Ubuntu nämlich 12.04 die Grundlage sein (oder ein Debian ähnlichen Alters), zumindest konnte ich kein OpenVU unter neueren Ubuntu bauen...
      Für ein so altes Ubuntu gibt es aber garnicht mehr all die Pakete Updates... abgesehen dass für MIPSEL sind sie sowieso schwieriger zu finden... also müssten sie eher neu kompiliert werden?

      Sorry für all diese komischen Fragen, aber ich würde einfach gerne besser verstehen wie diese Dinge zusammenhängen um besser abschätzen zu können was machbar ist und wo man durch die Closed Source Politik des Herstellers eingeschränkt ist.

      Danke jedenfalls für die Infos!
    • Hast du (teilweise) falsch verstanden.

      Ob immer noch ein Ubuntu 12 für das bauen des Open VU Images nötig ist, weiss ich nicht. War es aber, das liegt aber daran, was die Rezepte einiger Pakete erwarten. So ein Rezept für BitBake holt sich in der Regel den Sourcecode für ein Paket von irgendwo aus dem Internet (die Adresse steht im Rezept) und übersetzt es dann mit einem Cross Compiler.

      Hat also gar nichts mit Ubuntu zu tun, ob ein Paket aktualisiert werden kann. Ubuntu ist dann Schuld, wenn das Rezept so aufgebaut ist, dass es vom OS abhängt, wo es ausgeführt wird.

      VTi hat sicher das Open Image als Grundlage, daneben aber auch eigene Rezepte.

      Die Rezepte liefert zum großen Teil OpenEmbedded, allerdings müssen die auch ins Image integriert werden. OpenEmbedded ist inzwischen Jahre voraus, und es kostet schon eine Menge Zeit, Pakete aktuell zu halten. Bei Debian z.B. ist ein Paket-Maintainer oft nur für ein einziges Paket verantwortlich.

      Du kannst bei einer One- oder Two-Man-Show daher nicht erwarten, dass auch noch auf jede gefundene Sicherheitslücke reagiert werden kann. Erst recht nicht, wenn das in der Freizeit passiert.
      Diskutiere nie mit einem Idioten. Er zieht dich auf sein Niveau runter und schlägt dich mit seiner Erfahrung.
    • Danke, jetzt verstehe ich es schon etwas besser. Mir ist auch klar, dass ein Team, dass hier in der Freizeit an einem Image arbeitet, nicht die Resourcen hat alles abzudecken und permanent neues zu bringen. Das finde ich auch nicht notwendig. Wie ich in einem anderen Betrag geschrieben habe, gibt es für die VU+ und in VTI sehr viele Möglichkeiten, die einfach viele gar nicht kennen und somit wird wohl nur von wenigen das Potential ausgeschöpft, dass einem schon jetzt zur Verfügung gestellt wird. (-> Welche 4kbox könnt ihr empfehlen )
      Was ich nicht verstanden hatte war, warum Updates die schon im Forum irgendwo existieren, wie zB eure Sicherheitsupdates, warum das nicht irgendwie integriert in generelle Updates wird. Ich hab das wohl naiv zu einfach gesehen, dass dann per Feed zur Verfügung zu stellen.
    • Auch das kostet natürlich alles Energie und Zeit, und ich akzeptiere, dass ein Entwickler auch einmal eine längere Auszeit braucht.

      Wir als Community können aus meiner Sicht zwei Sachen machen:
      - das Wiki aktuell halten und verbessern
      - einen Community-Feed aufsetzen, den jeder dann bei sich einbinden kann

      So ein Community-Feed bringt natürlich die Gefahr mit, dass sich evtl. Pakete nicht mit denen auf dem offiziellen Feed vertragen.

      Ich habe in #10 ja schon aufgezählt, was ich bei mir versuche als Paket aktuell zu halten (aktuell ist die glibc 2.32 dazugekommen, ich habe mir die Mühe gemacht, die Struktur der Pakete am Feed zu übernehmen; sind 1028 Pakete geworden), stelle ich gerne alles zur Verfügung.

      Auch auf einer Duo2 müsste sich der GCC installieren und danach auch bootstrappen lassen, erste Anlaufstelle sind wahrscheinlich etwas ältere Debian-Pakete für MIPSEL. Ich selber habe kein MIPS-Box, kann da nur mit Tipps aushelfen.
      Diskutiere nie mit einem Idioten. Er zieht dich auf sein Niveau runter und schlägt dich mit seiner Erfahrung.