Debian unsecure by Default?

[Misterzde]

Beim dhclient gab es wohl schon mal Patches, die es ermöglichten dbclient als non-root-user laufen zu lassen:

https://bugs.debian.org/cgi-bin/bugrepo ... bug=308833

Was ist daraus geworden?

P.S. Ich kann es mir mit dem Bug-Tracker selbst beantworten:

I dropped the client derooting patch in Ubuntu in the last release,
since it is imperfect ($PATH injection into client script) and too
complicated. This is better solved with AppArmor or something.

Thus I close this report now, too.

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)


Ubuntu, unsecure by default...

[NAB]

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.

Nur, dass so ein gehackter Router deinen gesamten Netzwerkverkehr ins WAN manipulieren kann, deine Rechner per DHCP eh so konfigurieren kann, wie es ihm beliebt, und deinen gesamten LAN-Verkehr belauschen kann.

[TomL]

[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.....

Zu diesem Punkt habe ich eine andere Meinung und teile da eher Uname's pragmatischere Haltung. Meines Erachtens ist der Aufwand für betriebenen Datenschutz dann eine echte Paranoia geworden, wenn die Paranoia es geschafft hat, aus mir selber den Gaul zu machen, auf dem sie durch Cyber-Village reitet.... und das will ich ganz sicher nicht. Wenn ich stattdessen mal nüchtern bilanziere und mich frage, für wen ich und mein Netzwerk überhaupt interessant sind, dann komm ich unweigerlich zu dem Schluss, dass alle Nachrichten- und Geheimdienste sehr schnell das Interesse aus Langeweile verlieren würden, die Kripo sowieso, und für Wirtschaftsspione gibs auch nix zu holen.
Mein Interesse an Datenschutz ist vor diesem Hintergrund deshalb ein wenig anders gelagert.... Schutz heisst für mich primär "Beschützen vor Beschädigung". Wenn die 3 vorgenannten Institutionen bei mir schnüffeln, dann tun sie das wohl eher unbemerkt, geräuschlos und ohne etwas zu zerstören. Ich kanns eh nicht verhindern, geht mir also am A...h vorbei. Aber wenn ich mir von irgendwo was "einfange", z.B. 'ne Schadsoftware im Web, oder wenn sich mit Hacktertools spielende Kids Zugang zu meinem Netz verschaffen, dann sieht das gaaaanz anders aus. Aus purer Schadenfreude werden vielleicht Daten unbemerkt zerstört, gelöscht, verändert .... und ich backup'e in der Folge maschinell automatisch und unbemerkt die kaputten Daten über die "heilen" Backup's. Oder es werden über offenene Schnittstellen unbemerkt Schnüffelprogramm installiert .... genau all davor habe ich Schiss. Und genau das möchte ich nach besten Möglichkeiten verhindern. Das Dilemma ist, dass ich selber nur eine Ahnung habe, was vielleicht möglich ist, aber ich habe keine wirklichen Kenntnisse... es reicht also nicht, um sich selber ein scharfes Bild von den potentiellen Gefahren zu machen... alles ist leider irgendwie vernebelt. Alleine kann ich das nicht, ich "lebe" und lerne von den Kenntnissen wohlwollender Fachleute, die sich die Zeit für ein bisschen Aufklärung nehmen.

Und zu dem vorgenannten Datenschutz habe ich noch das Interesse, diese Datenkraken wie Google, Facebook und diese ungezählten typischen Advertisement-Domains mit ihren Schnüffelscripten auszuschließen. Mit dem angekündigten Windows 10 ist für mich jetzt ja wohl auch MS in den Kreis der "Nicht mehr vertrauenswürdigen Unternehmen" aufgestiegen. Mit all denen mag ich meine Lebensgewohnheiten jedenfalls nicht mehr teilen. Aber dieser "Schutz" ist weniger systemisch zu lösen, sondern eigentlich allein verhaltensbedingt.

J.m.2.c.

[uname]

Eigentlich gibt es nur zwei Angriffsszenarien.

a.) von außen und dann nur direkt gegen die weltweite IP-Adresse des Routers, da nur diese Adresse überhaupt direkt erreichbar ist
b.) von innen auf dem Client z.B. per Malware und dann über einen Fernwartungs-Trojaner

a.) kommt eigentlich kaum vor und kann man bei entsprechender Hard- und Software fast ausschließen
(Ports von außen testen, aktuelle Firmware, guter Hersteller, ...)
b.) ist vor allem ein Windows-Problem aufgrund nicht vorhandener sicherer Paketquellen und der generellen Malware-Situation

Wenn du jedoch einen Windows-Rechner in deinem LAN hast, dieser befallen ist und du dort Passwörter für deinen Server (z.B. per Putty) nutzt, hast du ein Problem. Die Malware verbindet sich ins Internet. Der Angreifer geht durch diesen Tunnel zurück auf das Windows-System und der Angreifer meldet sich einfach selbst per Putty auf deinem Linux-Server an.
Und wie man sieht. Eine Einschränkung des SSH-Servers auf dein LAN hätte auch hier nicht geholfen. Der Angreifer kommt im übrigen nur auf deinen Windows-Recher, da der Windows-Rechner selbst per NAT über den Router die Verbindung ins Internet zu einem C&C-Server aufgebaut hat. Der Router akzeptiert natürlich die Rückkehrpakete und leitet sie an den Windows-Rechner weiter. Der umgekehrte Aufbau der Verbindung ist nicht möglich.

[dufty2]

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

Für Geräte wie NAS, Drucker, Desktop vergibts Du einfach statische Adressen, ein Debian-PC bräuchte somit nicht mal den network-manager geschweige denn dhclient und man trägt die Daten direkt in die /etc/network/interfaces ein.

Für Laptop und ähnliches, die auch mal woanders eingesetzt werden, setzt Du für zu Hause im Network-Manager eine Connection mittels "manual" auf, dann wird - zuminderst dort - kein dhclient gebraucht.

[schwedenmann]

Hallo


@uname

Code: Alles auswählen

a.) von außen und dann nur direkt gegen die weltweite IP-Adresse des Routers, da nur diese Adresse überhaupt direkt erreichbar ist

a.) kommt eigentlich kaum vor und kann man bei entsprechender Hard- und Software fast ausschließen

Das ist m.M. nach huete nur so, das heutige Router, jede menge Dienste (ftp, smb, dnla, ntpd, etc) mitbringen, jeder dieser Dienste ist ein ein potenzielles Einfallstor, wenn eine Scherheitslücke dort vorhanden ist, je mehr Dienste direkt per IP des Routers zugänglich sind, destro größer ist doch die Gefahr, bei potentiellen Sicherheitslücken.

ist vor allem ein Windows-Problem aufgrund nicht vorhandener sicherer Paketquellen

Linuxpaketquellen sind im Grunde auch nicht sicherer, da unterliegen Linuxer der Selbsttäuschung, die sind auch manipulierbar, wenn mn das von closed source annimmt, weil man ev. paranoid ist, das muß man das bei opensource annehmen, eben weil man paranoid ist.
auch
mfg
schwedenmann

[NAB]

Eigentlich gibt es nur zwei Angriffsszenarien.

a.) von außen und dann nur direkt gegen die weltweite IP-Adresse des Routers, da nur diese Adresse überhaupt direkt erreichbar ist
b.) von innen auf dem Client z.B. per Malware und dann über einen Fernwartungs-Trojaner

Und dann kombinieren wir a und b und haben einen Angriff von Innen auf den Router, der dann nach außen seine Pforten öffnet (natürlich nur für bestimmte IP-Adressen, die du nie im Leben errätst). Dafür braucht's auch keine Malware, da reicht manchmal ein simpler URL-Aufruf, der an den Router geht, um dessen Fernwartungsfunktion zu aktivieren.

Ich halte das Misstrauen von Misterzde gegenüber diesen unwartbaren Stücken Wegwerfelektronik durchaus für berechtigt. Nur der Lösungsansatz, dann jeden Rechner mit einer Personal Firewall einzumauern, der kommt mir naiv und halbherzig vor.

[DeletedUserReAsG]

Es hält einen keiner davon ab, selbst einen Router aufzusetzen. Dort wäre dann auch ein sinnvoller Platz für eine Firewall. Den Plastikroutern traue ich auch nicht weiter, als ich sie werfen kann (ist vielleicht nicht der richtige Vergleich: die Speedport W7xx sind ziemlich aerodynamisch …).

[Misterzde]

So, ich habe noch ein wenig bezüglich dhclient geforscht.

Der dhclient scheint folgendes zu tun (was im Grunde auch logisch ist):

1. IP-Adresse per DHCP vom Server / Router holen
2. IP-Adresse per ifconfig an das Interface übergeben (hier eth1)
3. Bleibe aktiv auf Port 68 und erneuere in regelmässigen Abständen

Für das Öffnen des LIstening-Ports braucht es wohl root-rechte, den Problem mit ifconfig (braucht auch root-Rechte) könnte man per S-Bit lösen.

root@debian6:/sbin# dhclient -4 -p 50021 -v eth1
binding to user-specified port 50021
Internet Systems Consortium DHCP Client 4.1.1-P1
Copyright 2004-2010 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth1/d0:50:99:47:43:e4
Sending on LPF/eth1/d0:50:99:47:43:e4
Sending on Socket/fallback
DHCPREQUEST on eth1 to 255.255.255.255 port 50020
DHCPREQUEST on eth1 to 255.255.255.255 port 50020
DHCPDISCOVER on eth1 to 255.255.255.255 port 50020 interval 7
DHCPDISCOVER on eth1 to 255.255.255.255 port 50020 interval 7
DHCPDISCOVER on eth1 to 255.255.255.255 port 50020 interval 21

Dazu meine Meinung:

1. Für einen reinen Client-Betrieb müsste dhclient nicht ständig auf einem Port "lauschen". Das ist leider nicht konfigurierbar. Der dhclient könnte auch ohne "Listening-Port" in regelmässigen Abständen die IPs erneuern bzw. der/die/das "Lease" erneuern.

2. Streng genommen müsste in einem kleinen privaten Netzwerk überhaupt keine Erneuerung der DHCP-Adressen / Leases stattfinden, das könnte bei Desktop-Rechnern von Zeit-zu-Zeit per Reboot geschehen. Das Programm dhclient müsste also gar nicht dauerhaft aktiv sein.

3. Verfolgt man Punkt 2 weiter und beendet dhclient per "kill", so beendet sich dhclient normal und löscht dabei leider die IP-Adressen auf der Netzwerkkarte

4. Abhilfe für Punkt 3 schafft ein "kill -9" - dhclient wird "hart" beendet und die IP-Adresse bleibt auf der Netzwerkkarte stehen.

Kritik an Debian bzw. den Entwicklern von dhclient:

- dhclient öffnet einen Listening-Port, obwohl das technisch in den meisten Szenarien nicht notwendig ist. Kein Parameter dokumentiert / vorhanden
- dhclient benötigt zum Öffnen des Listening-Ports anscheinend zwangsweise root-rechte. Das kann ein Sicherheitsproblem darstellen (Problem gab es bereits in der Vergangenheit)
- dhclient bleibt aktiv und läuft im Hintergrund, obwohl dies meist nicht erforderlich ist.

Lösungsansatz:

Script suchen / entwickeln, dass die PID von dhclient ermittelt, dann nach boot per Aufruf in rc.local per "kill -9" beenden.

[uname]

Den Plastikroutern traue ich auch nicht weiter, als ich sie werfen kann

Wohl auch schon zu oft Wargames geschaut

[DeletedUserReAsG]

Lösungsansatz:

dhclient nicht als Daemon starten.

Ich hab isc-dhcp-client auf den mobilen Rechnern, um in ’nem Gast-LAN bequem die entsprechenden Daten zu bekommen. Als Daemon ist dhclient bei mir allerdings noch nie gelaufen – wusste bislang nicht mal, dass man es auch auf die Art nutzen könnte ….

uname, Wargames kenne ich nicht einmal.

[uname]

uname, Wargames kenne ich nicht einmal.

Was für eine Bildungslücke. Dann schau dir mindestens den Trailer an. Leider nur Englisch. Ich würde sagen der erste Film über einen Cyberangriff (80er-Jahre) überhaupt. Passt somit sogar zum Thema.
https://www.youtube.com/watch?v=hbqMuvnx5MU

[NAB]

Ich hab isc-dhcp-client auf den mobilen Rechnern, um in ’nem Gast-LAN bequem die entsprechenden Daten zu bekommen. Als Daemon ist dhclient bei mir allerdings noch nie gelaufen – wusste bislang nicht mal, dass man es auch auf die Art nutzen könnte ….

Das ist genau das Paket, das als "dhp3-client" installiert wird:
https://packages.debian.org/search?suit ... cp3-client
Wie man es als Daemon startet, weiß ich allerdings auch nicht.

Überhaupt wird der DHCP-Client meines Wissens nur Installiert, wenn der Installer einen DHCP-Server vorfindet (hat mich schon übel genervt) ... dessen Daten werden dann ja gleich zur Netzwerkkonfiguration genutzt, damit Debian seine Updates findet. Wenn man dem vermeintlich gehackten Router also von vornherein die Netzwerkkonfiguration überlässt, dann macht es natürlich total viel Sinn, sich zwischendurch mal ein klein wenig vor ihm zu schützen ^^

[dufty2]

https://packages.debian.org/search?suit ... cp3-client
Wie man es als Daemon startet, weiß ich allerdings auch nicht.

Mmmh, schon mal daran gedacht, dass das "D" bei "DHCP" für "dynamic" steht?

Man latscht im Büro herum, wechselt von wireless auf wired, geht ins Labernetz etc.
"leases" sind ein integraler Bestandteil vom DHCP-Konzept => es ist so gewollt, dass der (dhcp-)client kurz vor Ablauf seines leases den (dhcp-)server um eine weitere Verlängerung bittet und ergo ist auch ein daemon vonnöten.

Klar könnte man leases=unendlich einstellen, aber da kann ich gleich statisch konfigurieren.

Und das DHCP auf Port 68 bzw. 67 (und damit unter <1024) lauscht ist auch im Protocol seit gefühlten 20 Jahren so festgelegt ...

[NAB]

Mmmh, schon mal daran gedacht, dass das "D" bei "DHCP" für "dynamic" steht?

Ja, neee, echt jetzt? Man, sach nur! Ehm ... ja ... und?

Das verrät mir immer noch nicht, wie man den dhcp-client als Daemon betreibt. Bei mir ist das Paket "isc-dhcp-client" (manuell) installiert ... falls ich es mal brauche. Per ifdown/ifup klappt das auch manuell. Einen entsprechenden Dienst kann ich nicht entdecken, und finde in den Config-Dateien auch nichts, wie man ihn starten könnte. Da frag ich mich, wie Misterzde das "versehentlich" hinbekommen hat.

[dufty2]

Gestartet wird er z. B. per

Code: Alles auswählen

# dhclient eth0

Er daemonisiert sich von selbst, sprich man braucht kein "&" am Schluß der Zeile anfügen, damit er in den Hintergrund geht.

Er fungiert nur als "Hilfs-daemon", ist somit nicht als "/usr/sbin/service dhclient" bzw. nicht unter /etc/init.d/ zu finden und wird in der Regel vom NetworkManager (der als echter Service ein /etc/init.d/network-manager hat) bei Bedarf mit-gestartet.

Und so hat es auch Misterzde hinbekommen ...

[Misterzde]

So, ich habe mir in der Zwischenzeit (habe gerade Urlaub und Zeit) mal Windows 7 und Debian 6 mit nmap angeschaut (jeweils wechselseitig). Windows 7 mit aktiver Firewall hat per Default von aussen alle Ports "zu" und ist auch von nmap nicht als Windows-System erkennbar.

Bei Debian 6 ist es leider nicht so, die Ergebnisse sind interessant (IPTABLES nicht aktiv)

- Es werden hier z.B. die RPC-Daemons auf TCP gefunden
- Der DHCP-Client auf UDP-Port 68 wird nicht gefunden ("Stealth"), auch nicht auf localhost --> Strange
- UDP-Scan dauert sehr lange --> weil UDP nicht gefiltert wird.

Bei Aktivierung von IPTABLES (mit sehr restriktiven Einstellungen) können erwartungsgemäss auch keine offenen Ports gefunden werden. Der UDP-Scan ist auch wesentlich schneller als zuvor, da die UDP-Pakete zurückigewiesen werden.

Per Default ist also ein Debian (Ubuntu)-System netzwerkseitig weniger sicher als Windows 7.

Da die Konfiguration von iptables (manuelle Einträge in rc.local) auch recht kompliziert ist, halte ich Debian / Ubuntu für technisch wenig kundige Privatpersonen nicht für die erste Wahl bei bestehendem Zugriff auf das Internet. Hier fehlt eine einfach zu konfigurierende Firewall.

[Misterzde]

Mmmh, schon mal daran gedacht, dass das "D" bei "DHCP" für "dynamic" steht?

Man latscht im Büro herum, wechselt von wireless auf wired, geht ins Labernetz etc.
"leases" sind ein integraler Bestandteil vom DHCP-Konzept => es ist so gewollt, dass der (dhcp-)client kurz vor Ablauf seines leases den (dhcp-)server um eine weitere Verlängerung bittet und ergo ist auch ein daemon vonnöten.

Beim Wechsel der Netzwerkverbindung von Kabel auf Wireless geht der DHCP-Request vom Client aus. Für ausgehende Verbindungsanfragen wird kein "Listening-Port" benötigt. Dieser dient zur Annahme von Verbindungsanfragen aus dem Netz. Dies ist aber bei Standardszenarien im Heimnetz nicht erforderlich.

[Misterzde]

Und das DHCP auf Port 68 bzw. 67 (und damit unter <1024) lauscht ist auch im Protocol seit gefühlten 20 Jahren so festgelegt ...

Habe gerade Wikipedia gelesen, das stimmt. Es ist tatsächlich so, dass der DHCP-Client auf Port 68 lauscht. Da es UDP ist, muss wohl auch gelauscht werden. Da der DHCP-Server nicht bekannt ist erfolgt ein UDP-Broadcast und der DHCP-Server antwortet auch mit UDP-Broadcast.

Zumindest temporär muss der DHCP-Client also wohl auf Port 68 lauschen...

[sys_op]

.....
Per Default ist also ein Debian (Ubuntu)-System netzwerkseitig weniger sicher als Windows 7.
.....

Nimm es nicht persönlich, aber deine unumstösslichen Rückschlüsse, basierend auf Bruchteil-Wissen, sind langsam etwas nervig zu lesen.

Du schliesst aus ein paar offenen Ports, von denen du nicht genau weisst, was die Programme, die dahinter stecken tun und deren Funktion du in 10 Minuten ergoogled hast, auf die Sicherheit eines Systems und stellst Wahrheiten fest, die 1000 Tonnen wiegen und die kein Mensch mehr weg-heben, geschweige denn umgehen kann.

Du diskutierst nicht und hörst nicht zu!

[Misterzde]

.....
Per Default ist also ein Debian (Ubuntu)-System netzwerkseitig weniger sicher als Windows 7.
.....

Nimm es nicht persönlich, aber deine unumstösslichen Rückschlüsse, basierend auf Bruchteil-Wissen, sind langsam etwas nervig zu lesen.

Du schliesst aus ein paar offenen Ports, von denen du nicht genau weisst, was die Programme, die dahinter stecken tun und deren Funktion du in 10 Minuten ergoogled hast, auf die Sicherheit eines Systems und stellst Wahrheiten fest, die 1000 Tonnen wiegen und die kein Mensch mehr weg-heben, geschweige denn umgehen kann.

Du diskutierst nicht und hörst nicht zu!

Ich kann immer nur einen Teilaspekt beleuchten. Übrigens lauscht Windows 7 nicht dauerhaft auf Port 68 bei aktiviertem DHCP, zumindest zeigt es netstat -a dort nicht an.

Dafür viele andere offene Ports

Bezüglich Firewall stellt sich doch wirklich die Frage, warum es das für Debian und Ubuntu nicht gibt. Bei Suse Linux gibt es das.....

Ich kann das also auch ohne den Vergleich zu Windows formulieren, mir wurde ja vorgeworfen, dass ich die Windows-Brille aufhätte.

[WPSchulz]

Windows 7 mit aktiver Firewall hat per Default von aussen alle Ports "zu" und ist auch von nmap nicht als Windows-System erkennbar.

Was heißt jetzt bei Dir "aussen"?

[uname]

Von außen meint bestimt aus dem eigenen LAN. Wobei ich mal denke, dass ein Windows mindestens auf ICMP-Requests anwortet. Leider habe ich kein Windows und kann es somit nicht ausprobieren. Vielleicht kann mal jemand kurz von seinem StandardDebian-Desktop Gnome/KDE/... folgendes posten:

Code: Alles auswählen

netstat -tulpen (Teilbereich LISTEN reicht)

damit wir mal die Anwendungen abschließend diskutieren können, die per 0.0.0.0 erlaubt werden. "dhclient" wurde ja schon angesprochen. Danke.

Irgendwo habe ich geschrieben, dass man Rechner gar nicht von außen angreift. Der Angriff erfolgt heute per Malware vom Rechner selbst.

[NAB]

Ah, danke dufty2 für die Erklärung. Die Ursache dürfte dann der Network Manager sein ... um den mache ich gerne einen Bogen.

Misterzde, mit deinen ausgeprägten Google-Fähigkeiten hättest du auch diese Seite finden können:
http://wiki.ubuntuusers.de/Personal_Firewalls

[WPSchulz]

Wobei ich mal denke, dass ein Windows mindestens auf ICMP-Requests anwortet.

Nee, da hat er doch

..schon mal was an den ICMP-Pings gedreht....