ubuntuusers.de

BillMaier schrieb:

Ist das ernst gemeint? Dann sollten wir da als community auch reagieren und genau das tun. Den Artikel anpassen wäre auch wichtig, allerdings eben nicht unbedingt stillschweigend. Auf keinen Fall würde ich die Falschaussage stehen lassen, denn

$ netstat -tulpen | grep -v '127.0.0' 
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode      PID/Program name    
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      0          3045       568/rpcbind                
tcp6       0      0 :::6600                 :::*                    LISTEN      0          21545      1/init              
tcp6       0      0 :::111                  :::*                    LISTEN      0          3048       568/rpcbind         
tcp6       0      0 :::1716                 :::*                    LISTEN      1000       1136859    28185/kdeconnectd           
tcp6       0      0 ::1:631                 :::*                    LISTEN      0          881617     21453/cupsd         
udp     7168      0 0.0.0.0:5353            0.0.0.0:*                           114        21403      681/avahi-daemon: r 
udp        0      0 0.0.0.0:46856           0.0.0.0:*                           114        21405      681/avahi-daemon: r 
udp        0      0 0.0.0.0:68              0.0.0.0:*                           0          1143381    28845/dhclient      
udp        0      0 0.0.0.0:111             0.0.0.0:*                           0          3043       568/rpcbind         
udp        0      0 0.0.0.0:631             0.0.0.0:*                           0          881624     21454/cups-browsed  
udp        0      0 0.0.0.0:744             0.0.0.0:*                           0          3044       568/rpcbind         
udp6       0      0 :::36291                :::*                                114        21406      681/avahi-daemon: r 
udp6   45056      0 :::5353                 :::*                                114        21404      681/avahi-daemon: r 
udp6       0      0 :::111                  :::*                                0          3046       568/rpcbind         
udp6       0      0 :::744                  :::*                                0          3047       568/rpcbind         
udp6    6912      0 :::1716                 :::*                                1000       1136858    28185/kdeconnectd

ist definitiv nicht "kein einziger Port"

Keine Ahnung, wo die bei dir herkommen:

# netstat -tulpen
Active Internet connections (only servers)
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          17150       853/cupsd       
tcp        0      0 127.0.1.1:53            0.0.0.0:*               LISTEN      0          19240       1104/dnsmasq    
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          18208       1051/sshd       
tcp6       0      0 ::1:631                 :::*                    LISTEN      0          17149       853/cupsd       
tcp6       0      0 :::1714                 :::*                    LISTEN      1000       23372       1933/kdeconnectd
tcp6       0      0 :::22                   :::*                    LISTEN      0          18210       1051/sshd       
udp        0      0 0.0.0.0:631             0.0.0.0:*                           0          16131       922/cups-browsed
udp        0      0 0.0.0.0:39785           0.0.0.0:*                           65534      19271       1104/dnsmasq    
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           110        15904       851/avahi-daemon: r
udp        0      0 0.0.0.0:51130           0.0.0.0:*                           110        15906       851/avahi-daemon: r
udp        0      0 127.0.1.1:53            0.0.0.0:*                           0          19239       1104/dnsmasq    
udp        0      0 0.0.0.0:68              0.0.0.0:*                           0          17605       1072/dhclient   
udp6       0      0 :::5353                 :::*                                110        15905       851/avahi-daemon: r
udp6       0      0 :::54573                :::*                                1000       23373       1933/kdeconnectd
udp6       0      0 :::1714                 :::*                                1000       23371       1933/kdeconnectd
udp6       0      0 :::57122                :::*                                110        15907       851/avahi-daemon: r

SSH ist kein Standard. Bleiben Cups, Avahi und KDEconnect in meinem Fall... Also nicht die Welt und der selbe Stand wie vor Jahren. dnsmasq lauscht nur auf 127.0.0.1, gilt also nicht 😉

Der Punkt ist doch: Man kann überhaupt keine Aussage treffen, wie kritisch ist, einen Port durch eine Applikation geöffnet zu haben oder nicht, wenn man die Umgebung nicht kennt: Wenn ich nur zu Hause und im Firmennetz hinter NAT und Router (und "richtiger" Firewall) unterwegs bin, dann ist das ggf. wurst.

man kann auf grund eines Ports überhaupt keine Aussage treffen, das ist das Problem. jede beliebeige Software kann Port XYZ (größer 1024) öffnen. An Hand Port XYZ allein lassen sich keine handlungsempfehlungen ableiten, die Umgebung ist da nur ein zusätzlicher faktor.

Grundsätzlich gilt für mich aber: Dienste sollten nur dann Ports nach außen öffnen, wenns unbedingt gebraucht wird (Ubuntu hält sich wohl nicht mehr dran?)

CUPS und Avahi haben ihre Berechtigung: Drucken kdeconnect kann ich nicht einschätzen auf die Schnelle, aber sonst ist nix da

noisefloor schrieb:

Ich lasse mich aber gerne vom Gegenteil überzeugen, wenn einer ein paar Real-Life Usecases hat, warum der Ubuntu Desktop in der Standardinstallation mit einer Firewall geschützt werden soll.

Mit fällt dazu nur ein, wenn ich mit meinem Laptop auf Reise durch EU bin und irgendwelche offenen Gäste-AccessPoints verwende. Man kennt weder den Charakter des AP, nicht seine Absichten, nicht ob er vielleicht selber kompromittiert ist. Eine Firewall brauchts da allerdings nicht, aber einen kompromissloser Paketfilter mit einigen wenigen Regeln. Das und OpenVPN ist unterwegs für mich obligatorisch.

Hallo,

Mit fällt dazu nur ein, wenn ich mit meinem Laptop auf Reise durch EU bin und irgendwelche offenen Gäste-AccessPoints verwende.

Gut, aber das wäre den IMHO ein Fall für ein Howto / einen eigenen Artikel und nicht für einen Grundlagen-Artikel (wie diesen).

Gruß noisefloor

redknight schrieb:

CUPS und Avahi haben ihre Berechtigung: Drucken kdeconnect kann ich nicht einschätzen auf die Schnelle

Kann man so und so sehen. Wer sagt, dass ich übers Netzwerk drucken oder irgendwas frei geben will? Wenn ich das nicht brauche, hat das aus meiner Sicht keine Berechtigung - also dass es ungefragt lauscht, egal auf welchen Ports. Und zur CUPS-Verwaltung reicht localhost:631 .

(Dass das schon seit Jahren so ist ändert nichts an der Tatsache - und auch nicht daran, dass der Artikel und die Fakten auseinander laufen)

Gruß BillMaier

Die Listeningports von cups sind doch auf localhost gepinnt. Lediglich der discover (udp) ist offen...

von mir aus bräuchte es den auch nicht.

Aber ich muss auch zugeben, ich habe hier

tcp6       0      0 ::1:631                 :::*                    LISTEN      0          881617     21453/cupsd

die 1 übersehen.

Gruß BillMaier

Als Beispiel für die Gefahren offener Ports in der Standard-Installation von Ubuntu-Desktop: Bei cups-browsed gab es in älteren Ubuntu-Versionen mal Probleme.

https://usn.ubuntu.com/2210-1/

Sebastian Krahmer discovered that cups-browsed incorrectly filtered remote printer names and strings. A remote attacker could use this issue to possibly execute arbitrary commands. (CVE-2014-2707)

Viele Grüße, Roland

Es gab auch schon Probleme mit Apache. Das ist kein Grund, da einen Paketfilter davorzusetzen. 😉

Warum nicht, wenn man den nur im internen Netz oder für localhost braucht?

Wenn ich einen Apache nur auf localhost brauche, binde ich den vhost an localhost...

Spricht ja nichts dagegen. Es ist schließlich Linux und da führen oft viele Wege zum Ziel.

Es spricht eben auch nichts dagegen, wenn man mit dem Notebook viel unterwegs (öffentliche WLANs) ist, einen Paketfilter einzurichten der alle Ports dicht macht.

Nicht, dass ich das mache (ich bin nicht in öffentlichen WLANs unterwegs), aber ich sehe da durchaus einen Vorteil.

(Wer natürlich behauptet, dass man damit auch Angriffe auf den Browser abfängt, ist auf dem Holzweg.)

Gruß BillMaier

Hallo,

der Punkt ist doch: Bugs in einer Software / Schwachstellen der Implementierung - wie das von rolands11 genannte Beispiel - sind _kein_ Grund, per se immer den Einsatz einer PFW zu empfehlen. Ebenso wenig die Fehlnutzung, wie z.B: Apache an 0.0.0.0 zu binden, obwohl man den Server nur im internen Netzwerk braucht.

Gruß, noisefloor

Wie noisefloor sagt 😉

kein Widerspruch.

Vielleicht ist das Problem die Lösung → Sprich: Der Artikel behandelt die verschiedenen Seiten und erklärt außerdem, was die PersonalFirewall nicht abdeckt. Nur mal so als Idee.

Hallo,

Der Artikel behandelt die verschiedenen Seiten und erklärt außerdem, was die PersonalFirewall nicht abdeckt.

+1

Und, wie oben schon sagt, ist ein Beispiel für eine FW-Konfig für ein öffentliches WLAN (Flughafen, Hotel, was auch immer) sicherlich auch gut. Ob im Artikel selbst oder als eigener Artikel hinge vom Umfang ab.

Gruß, noisefloor