Debian unsecure by Default?

[dufty2]

Meiner Meinung nach macht ihr euch das zu einfach mit "der ist auf Windows konditioniert". Technisch gesehen kann auch Linux angegriffen werden.

Yo, so ist es, auch bei Debian könnte noch viel getan werden, z. B. grsecurity-kernel.

Was ich Dir empfehlen kannn
* kein Zugriff vom Internet ins eigene LAN erlauben (weiss nicht, warum das bei manchen Leute so beliebt ist, nachschauen, ob der Toaster nicht geklaut wurde?
* das Paket shorewall als "private firewall" installieren.
* JonDoFox aut simile für iceweasel
* ssh(d) für 'ne Kiste, die zwei Meter neben mir steht, brauch ich nicht
* Festplattenverschlüsselung + wichtige Daten eigens verschlüsseln
* sensible Daten (Steuer, Familien-Photos) evtl. auf Rechner ohne jegliches Netz (auch nicht LAN) ablegen.
* "Hirn einschalten" nicht vergessen

Perfekte Sicherheit gibt es wohl nicht.

[WPSchulz]

Debian hat per Default einige Dienste offen, kann man mit netstat -anp gut sehen, avahi, diverse rpc-daemons, cups, "dhclient",...

Vielleicht erst mal ein wenig Grundlagenwissen aneigen:
http://www.rvs.uni-bielefeld.de/~heiko/ ... p_2_4.html

Dann sich ernsthaft fragen, was ist ein Dienst, wird er serverseitig angeboten, wenn ja, von wem, oder wird er clientseitig genutzt, wenn ja vom wem. Ist der Dienst nur lokal auf den aktuellen Rechner beschränkt, ist er auch im lokalen Heimnetz verfügbar oder ist er weltweit erreichbar?

Als Beispielfrage: bist Du Client, der weltweit httpd-Server abfragt, oder bietest Du httpd-Serverdienst nur für Deinen Rechner, nur für das lokale Heimnetz oder weltweit an? Es ist also völliger Unsinn, wenn Du dich einfach auf die Aussage beschränkst: "Huch da ist ja ein Port offen!"

[TRex]

><((((*>

[Misterzde]

Hmm, jetzt wirds ja richtig sachlich. Also macht doch mal einen Portscan auf Eure Debian-Kisten aus dem internen Netzwerk. Problem wären auch Ports, die ggf. gar nicht auf Standardsequenzen antworten. Deswegen ja meine Meinung. Was nicht da ist, kann auch kein Sicherheitsproblem sein.

Die Denkweise greift zu kurz...

[NAB]

Du hast ja durchaus recht ... überflüssige offene Ports sollte man vermeiden. Aber wenn die Dienste überflüssig sind, warum beendest du sie dann nicht einfach, statt sie erst zu starten, um sie danach mit einer Firewall am Funktionieren hindern zu wollen? Das ist der Punkt, den ich nicht verstehe.

[DeletedUserReAsG]

Hmm, jetzt wirds ja richtig sachlich. Also macht doch mal einen Portscan auf Eure Debian-Kisten aus dem internen Netzwerk. Problem wären auch Ports, die ggf. gar nicht auf Standardsequenzen antworten. Deswegen ja meine Meinung. Was nicht da ist, kann auch kein Sicherheitsproblem sein.

Die Denkweise greift zu kurz...

Habe ich gemacht. Sind genau die Ports offen, die offen sein sollen. Die mit iptables dichtzumachen, wäre kontraproduktiv – dann wären sie ja nicht mehr offen. Die anderen, geschlossenen, Ports mit iptables dichtmachen zu wollen, wäre sinnfrei – warum etwas dichtmachen, das gar nicht offen ist?

[WPSchulz]

Also macht doch mal einen Portscan auf Eure Debian-Kisten aus dem internen Netzwerk.

Ein Scan auf Deinen speziellen Arbeitsrechner hin von einem anderen Rechner innerhalb Deines LAN aus ist von geringer Bedeutung. Du mußt einen Scan von einem Rechner außerhalb deines LAN, also vom WAN aus machen, und sehen, wieweit und ob überhaupt Dein spezieller Arbeitsrechner erreichbar ist.

[Misterzde]

Ich habe in der Tat die Default-Dienste beendet, die ich nicht benötige. Übrig geblieben ist CUPS. Dort habe ich allerdings den Zugriff über IPTABLES eingeschränkt, der ist dann nur noch vom lokalen Rechner aus möglich. Das ist ja auch sinnvoll.

Aber leider bietet Debian keine einfach zu konfiguriernde "Firewall" --> Frontend für IPTABLES, die das auch einem weniger versierten User ermöglichen würde. Die auf Debian basierenden Produkte (i.e.. Ubuntu) bieten das meines Wissens auch nicht. Und das kann z.B. Windows im Moment noch besser.

Die Meinung "LAN ist irrelevant, Du musst WAN messen" halte ich für fahrlässig. Es sind in letzter Zeit sehr viele Sicherheitslücken in Routern bekannt geworden, von daher sollte man durchaus auch den einzelnen Rechner betrachten.

Und über die grundsätzliche Sicherheitsthematik des Kernels (was nicht da ist, kann auch kein Sicherheitsproblem darstellen) will bei Debian wohl auch keiner diskutieren...

[TRex]

Ich habe in der Tat die Default-Dienste beendet, die ich nicht benötige. Übrig geblieben ist CUPS. Dort habe ich allerdings den Zugriff über IPTABLES eingeschränkt, der ist dann nur noch vom lokalen Rechner aus möglich. Das ist ja auch sinnvoll.

Auch cups lässt sich in der Richtung konfiguieren, sodass man ohne Firewall auskommt. Eine Firewall brauchst du (besonders in einem NAT-Szenario ohne uPNP) nur, um unbekannte ausgehende Verbindungen zu verbieten.. und die Mühe dafür machst dir selbst du nicht.

[WPSchulz]

Übrig geblieben ist CUPS. Dort habe ich allerdings den Zugriff über IPTABLES eingeschränkt, der ist dann nur noch vom lokalen Rechner aus möglich. Das ist ja auch sinnvoll.

Man sieht, daß Du dich noch nie durch die Konfigurationsdateien von Linux durchgearbeitet hast, hier speziell die unter '/etc/cups/'.

[Radfahrer]

Man sieht, daß Du dich noch nie durch die Konfigurationsdateien von Linux durchgearbeitet hast, hier speziell die unter '/etc/cups/'.

Das ist genau das, was ich weiter oben mit Windows-Konditionierung gemeint habe.
Da lernt man halt, das man einfach irgendwelche Programme aus dubiosen Quellen installiert, von denen man nicht weiß, was sie so alles machen. Und um die ganzen "pösen Dinge", die diese Programme dann so machen zu stoppen, installiert man sich halt so eine "Firewall". Klingt ja auch total cool. Und man kann sich einbilden, dass das was nützt und fühlt sich dann gleich viel sicherer.
Daran, installierte Programme so zu konfigurieren, dass sie nur das machen, was sie sollen, denkt unter Windows anscheinend niemand. OK, in den meisten Fällen geht das ja auch gar nicht. Man kauft da halt oft die Katze im Sack und muss dann zusehen, wie man klar kommt.

[letzter3]

Ich verstehe wirklich nicht, warum hier soviele Leute bei jeder Gelegenheit immer und immer wieder darauf rumhacken das jemand von Windows kommen könnte(!) und dieser jemand sich doch bitte eintrichtern soll, dass Firewalls unnötig sind. Und leider wird dabei überhaupt nicht bedacht, dass TO von einer Quell-/Source-/Protokollfirewall spricht. Im Gegenteil, es wird immer auf die ach so tolle anwendungsbasierte FW eingegangen.

Mit solchen Gehabe verliert das debianforum an Qualität, und das leider Tag für Tag ein bischen mehr.

Das Ursprungspost hier nochmal zur Verdeutlichung:

Hallo zusammen,

ich beschäftige mich gerade ein wenig mit der Sicherheit von Debian (in diesem Fall Version 6).

Leider muss ich feststellen, dass Debian "ab Werk" relativ unsicher ist.

- Keine "Firewall" aktiv - bzw. keine Absicherung des Computers per iptables (habe ich dann selbst getan)
- Der Default-Kernel scheint sehr viele aktive Netzwerkprotokolle zu enthalten, die im Normalfall vom Benutzer nicht benötigt werden (DEC-NET, IPV6, IPX). Dies stellt meiner Meinung nach ein unnötiges Sicherheitsrisiko dar. Ich habe diese Protokolle in einem selbst erstellten Kernel entfernt.

Wäre es nicht interessant für das Debian-Projekt, neben dem Standard-Kernel mit sehr vielen Funktionen auch einen "Secure-Kernel" mit möglichst wenigen aktiven Netzwerk-Protokollen auszuliefern? 99% der Anwender dürften ausschliesslich IPV4 benötigen.

Danke für Euer Feedback.

VG

Felix

Ja, es wäre sicher interessant, verschiedene Grundkonfigurationen auszuliefern. Andere Distris bieten sowas schon lange an.
- Software, die eine Serverfunktion anbietet, lauscht standardmäßig nur auf localhost.
- Firewall wird installiert und erstmal alles verboten. Benötigte ports/Protokolle müssen explizit freigegeben werden.
- Passwörter müssen einem bestimmten Mindeststandard genügen.
- Sicherheitschecks werden durchgeführt
- die Zuweisung von usern zu bestimmten Gruppen sowie der Zugriff auf Verzeichnisse wird eingeschränkt.
- Verzeichnisse werden ro eingehängt
-u.s.w
- Ob der angebotene Serverkernel nur im Bezug auf Scheduler und RAM angepasst ist oder ob auch etliche Module entfernt (bzw. aktiviert) wurden, entzieht sich momentan meiner Kenntnis.

Und das alles mit einem Klick bei der Installation auf "paranoid".

Und für die bereits formulierte Standardantwort: "Der user muss sein Gehirn einschalten". Ja, das muss er. Es wurde auch niemals was anderes behauptet. Aber da nicht alle user Zimmermann oder Rusty Russell heissen, wäre es sinnvoll Erleichterungen "ab Werk" anzubieten.

In diesem Sinne wünsche ich noch eine fruchtbare, unterstellungs- und windowsfreie Diskussion.

Michael

[uname]

Anwender wollen arbeiten. Eine immer installierte Firewall die alles blockt nutzt wenig. Natürlich kannst du eine Firewall installieren, die alles blockiert. Natürlich dann gleich inkl. Paketinstallation bzw. Sicherheitsupdates. Sehr praktisch.
Die Default-Konfiguration ist nicht unsicher. Anwender glauben nur sie sei unsicher. Schauen wir uns z.B. die für alle Benutzer lesbare Datei /etc/passwd an. Das geht doch nicht, oder? Aber es ist notwendig, da Debian ein Mehrbenutzersystem ist und somit man andere Anwender kennen muss. Und Passwörter stehen natürlich in /etc/shadow, welche durch root bzw. per SETUID-root-Programme wie "passwd" erreichbar sind. Auch ist es normal Teile von /etc oder /var oder sonstwas für alle zu lesen sind. Und wenn doch irgendwas unsicher wäre soll man mal ein echtes Beispiel anführen.

[Misterzde]

Übrig geblieben ist CUPS. Dort habe ich allerdings den Zugriff über IPTABLES eingeschränkt, der ist dann nur noch vom lokalen Rechner aus möglich. Das ist ja auch sinnvoll.

Man sieht, daß Du dich noch nie durch die Konfigurationsdateien von Linux durchgearbeitet hast, hier speziell die unter '/etc/cups/'.

Bei Debian / Ubuntu kaufe ich da aber genauso die Katze im Sack, es fragt mich niemand, ob ich CUPS laufen haben möchte und ob es nur lokal oder im Netzwerk lauschen soll. Daher kann eine zentrale Firewall hier sehr nützlich sein. Ist für den Endanwender (bei vorhandenem GUI) wesentlich einfacher zu "managen" als jedes von Debian per Default installierte Programm (das ändert sich ja auch) erst einmal analysieren zu müssen.

Aber danke, ich werde mir jetzt notgedrungen noch die Standardkonfiguration von CUPS anschauen müssen und ggf. anpassen. Obwohl das mit der Firewall (IPTABLES) nicht nötig sein sollte...

P.S.

Hier mal die Ausgabe von netstat:

tcp 0 0 0.0.0.0:57460 0.0.0.0:* LISTEN 747/rpc.statd
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 1342/cupsd
udp 0 0 0.0.0.0:51083 0.0.0.0:* 747/rpc.statd
udp 0 0 0.0.0.0:923 0.0.0.0:* 747/rpc.statd
udp 0 0 0.0.0.0:68 0.0.0.0:* 1577/dhclient
udp 0 0 0.0.0.0:631 0.0.0.0:* 1342/cupsd

Auf TCP lauscht jetzt nur noch ein mir unbekanntes Programm rpc.statd (CUPS nur auf localhost) , auf UDP allerdings noch mehr CUPS, dhclient und mehrfach rpc.statd
Und der Witz ist, dass CUPS gemäss cupsd.conf nur auf TCP:631 lauschen sollte, von UDP steht in der Konfigurationsdatei nichts...

Only listen for connections from the local machine.
Listen localhost:631
Listen /var/run/cups/cups.sock

[DeletedUserReAsG]

Bei Debian / Ubuntu kaufe ich da aber genauso die Katze im Sack, es fragt mich niemand, ob ich CUPS laufen haben möchte […]

Ich habe dich nicht gefragt. Dein Installer aber (ich kann hier nur von Debian reden, Ubuntu kenne ich nicht). Dort hast du die Option angewählt – du wurdest nicht gezwungen.

Ich persönlich finde die Herangehensweise, dass ein Admin wissen sollte, was er installiert, ganz okay. Imho ist es durchaus legitim, davon auszugehen, dass z.B. ein httpd am Interface lauscht, nachdem er installiert worden ist. Eine Firewall auf der gleichen Maschine ist irgendwie sinnlos (erwähnte ich das schon?) – statt Ressourcen zu verbraten um einen Port am Interface dichtzumachen, kann man den betreffenden Daemon auch direkt passend konfigurieren. Auch kann’s schnell mal ’n trügerisches Sicherheitsgefühl á la „Ich hab’ den Apachen ja nur im LAN zugelassen und nach außen hin geblockt, nun brauche ich ja keine Absicherung für mein $admininterface …“ – und dann kommt $böserCräcker, macht die Windowsdose im LAN auf (deren Snakeoilantivierenpersonalfirewall halt auch nicht das Wahre ist) und greift von da aus lustig auf das $admininterface auf dem via iptables „gesicherten“ Server zu …

Abgesehen davon: selbst, wenn man alle Sternchen im Installer setzt, ist das System nach der Installation nicht in dem Sinne „Jemand kommt ohne das Ausnutzen eines Bugs auf das System oder kann gar direkt Rootrechte erlangen“ unsicher. Wenn ein offener Port eine Sicherheitslücke wäre, müsste man wohl das ganze Internetz runterfahren – das kommt ohne offene Ports nunmal nicht aus.

[WPSchulz]

.. oder im Netzwerk lauschen soll

Du differenzierst immer noch nicht, ob Netzwerk lokal oder weltweit!

[Lord_Carlos]

.. oder im Netzwerk lauschen soll

Du differenzierst immer noch nicht, ob Netzwerk lokal oder weltweit!

Ist manchmal das gleiche.
Ich hatte fuer ein paar Jahre 100/100mbit direkt via ethernet ohne firewall in meine Wohnung. Jeder rechner hat ne eigene Internet IP bekommen.

[TomL]

Moin

Ich hoffe, Ihr habe trotz der schwierigen Diskussion zwischendurch auch mal ein paar Sekunden Zeit für die DAU's, die nicht immer sofort alles umsetzen können. Mit "netstat -tuapen" habe ich mir gerade mal meinen Server angesehen.... und leider habe ich hier zuhause niemanden, mit dem ich diese Ausgabe mal diskutieren könnte, was das überhaupt bedeutet.

Auffallend sind 3 (zufällig) fast gleichgroße "Zeilen-Pakete", eins mit Status "Listen", eines mit Status "Verbunden", eines ohne Angabe. Die verbundenen kann ich anhand der Angaben alle einordnen und verstehen. Die mit Status "Listen" horchen anscheinend auf ankommende Nachrichten. Ok, aber wie erkenne/unterscheide ich, wie weit sie horchen...?... nur lokal, nur im LAN, auch im WAN? Die Foreign-Adresse ist bei allen gleichermaßen 0.0.0.0, bedeutet das, dass sie alle auch auf "draußen" warten? Und was ist mit den Zeilen ohne Status? Bei diesem letzten Paket befindet sich beispielsweise mein OpenVPN-Daemon und ntpd. Welche Bewandtnis haben diese? Was ist beispielsweise bei OpenVPN anders, als bei Cups, das sich oben im Paket "Listen" befindet...?.... die warten doch beide, dass sie angesprochen werden

Es ist echt total schwer irgendwas zu machen, wenn man nix im Web findet, was die notwendigen Erklärungen ein bisschen aufs wesentliche reduziert und das auch noch verständlich erklärt....

[TRex]

0.0.0.0 bedeutet "auf allen interfaces". Kommt auf das Netzwerksetup an. Wirklich einschränkend ist in der Regel nur 127.0.0.1 (und ::1).

[TomL]

0.0.0.0 bedeutet "auf allen interfaces". Kommt auf das Netzwerksetup an. Wirklich einschränkend ist in der Regel nur 127.0.0.1 (und ::1).

Danke, das war schon sehr hilfreich. Jetzt gibts ja 3 Ebenen: Lokal, LAN und WAN. Wenn 127.0.0.1 "Lokal" bedeutet, heisst das auch gleichzeitig , dass diese Dienste innerhalb meines LAN nicht mehr erreichbar sind? Das würde ja dann z.b. meinen Cups-Drucker am Server betreffen, der dann von anderen LAN-Clients nicht mehr erreichbar ist. Wie erlaube ich Lokal und LAN, und verbiete WAN? Wird das im Customizing des Dienstes eingestellt oder über IPTables?

[uname]

Wie erlaube ich Lokal und LAN, und verbiete WAN? Wird das im Customizing des Dienstes eingestellt oder über IPTables?

In deinem lokalen Netzwerk (z.B. 192.168.0.0/24) erlaubst du immer den Zugriff per 0.0.0.0 . Das ist auch kein Sicherheitsrisiko, da aus dem Internet sowieso nicht geroutet werden kann. Maximal wenn du auf dem DSL-Router Port-Forwarding für einige Dienste aktivierst. Es ist dann problematisch wenn deine Rechner weltweite IP-Adressen hätten. Diese agieren dann ähnlich wie VServer im Internet. Da bleibt dann nur die korrekte Konfiguration der Dienste, Einschränkung der erlaubten Dienste (z.B. innerhalb vom SSH-Server) und der Einsatz von 127.0.0.1 und der indirekte Zugriff (Beispiele wären MySQL über Webserver, Webmin durch SSH-Tunnel).

[Misterzde]

Wie erlaube ich Lokal und LAN, und verbiete WAN? Wird das im Customizing des Dienstes eingestellt oder über IPTables?

In deinem lokalen Netzwerk (z.B. 192.168.0.0/24) erlaubst du immer den Zugriff per 0.0.0.0 . Das ist auch kein Sicherheitsrisiko, da aus dem Internet sowieso nicht geroutet werden kann. .

Diese Einstellung ist meiner Meinung nach naiv. Der typische Privathaushalt hängt per Router am Internet. In letzter Zeit wurden dort extrem viele Sicherheitslücken bekannt. Von daher ist es naiv anzunehmen, dass das lokale Netz geschützt sei.

Ini Firmen und grösseren Organisationen kann auch nur ein einzelner Rechner gekapert sein - oder man hat ein faules Ei in der Organisation....

[Misterzde]

Inzwischen konnte ich die Dienste, die aktiv im Netzwerk lauschen weiter reduzieren.

CUPS lässt sich beispielsweise so konfigurieren, dass es nicht auf UDP "lauscht" --> "Browsing = Off". Was bleibt ist der DHCP-Client --> dhclient.

Den DHCP-Client benötige ich wegen der IP, die vom Router/Modem kommt. Der Port 68 lässt sich wohl auch nicht deaktivieren, oder doch?

Was allerdings auffällt ist, dass der dhlcient als root läuft. Wäre es technisch nicht möglich, dass der dhclient ohne root-rechte läuft?

root@debian6:~# netstat -tulpen
Aktive Internetverbindungen (Nur Server)
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 0 3620 1095/cupsd
udp 0 0 0.0.0.0:68 0.0.0.0:* 0 4576 1582/dhclient

root@debian6:/etc/cups# ps -ef |grep 1582
root 1582 1133 0 10:26 ? 00:00:00 /sbin/dhclient -d -4 -sf /usr/lib/NetworkManager/nm-dhcp-client.action -pf /var/run/dhclient-eth1.pid -lf /var/lib/dhcp/dhclient-ad9c6947-1e96-4839-a90c-354c319481e9-eth1.lease -cf /var/run/nm-dhclient-eth1.conf eth1

Sichheritslücken im dhclient gab es schon:

http://www.golem.de/1104/82659.html


P.S. Der dhclient wid vom Network-Manager aufgerufen:

root 1133 1 0 10:26 ? 00:00:00 /usr/sbin/NetworkManager
root 1582 1133 0 10:26 ? 00:00:00 /sbin/dhclient -d -4 -sf /usr/lib/NetworkManager/nm-dhcp-client.action -pf /var/run/dhclient-eth1.pid -lf /var/lib/dhcp/dhclient-ad9c6947-1e96-4839-a90c-354c319481e9-eth1.lease -cf /var/run/nm-dhclient-eth1.conf eth1

Könnte hier nicht mit Sticky-Bit beim dhclient gearbeiter werden? Also Benutzer mit eingeschränkten Rechten für dhclient erzeugen und Aufruf über Sticky-Bit?

[WPSchulz]

Daher kann eine zentrale Firewall hier sehr nützlich sein. Ist für den Endanwender (bei vorhandenem GUI) wesentlich einfacher zu "managen" als jedes von Debian per Default installierte Programm (das ändert sich ja auch) erst einmal analysieren zu müssen.

Hast Du dir einmal die eingebaute Firewall (mit GUI) von Windows genauer angeschaut und versucht, da mal eben einfach etwas an der default Konfiguration zu ändern? Da brauchst Du schon viel Wissen, um Dir nicht selber ins Knie zu schiessen.

[Misterzde]

Daher kann eine zentrale Firewall hier sehr nützlich sein. Ist für den Endanwender (bei vorhandenem GUI) wesentlich einfacher zu "managen" als jedes von Debian per Default installierte Programm (das ändert sich ja auch) erst einmal analysieren zu müssen.

Hast Du dir einmal die eingebaute Firewall (mit GUI) von Windows genauer angeschaut und versucht, da mal eben einfach etwas an der default Konfiguration zu ändern? Da brauchst Du schon viel Wissen, um Dir nicht selber ins Knie zu schiessen.

Jo, habe da z.B. schon mal was an den ICMP-Pings gedreht....