Vor ein paar Tagen fiel mir bei einer Aktualisierung meines Servers der Hinweis auf Ubuntu Pro auf

Dazu muss man wissen, dass Canonical zwischen den Repositories Main und Universe unterscheidet. Um die Aktualisierung von Main kümmert sich Canonical und um Universe die Community. Main wird also von Menschen aktuell gehalten, die sich beruflich darum kümmern können. Universe hingegen wird von Freiwilligen betreut, die die natürlich nicht immer all die Upstream-Projekte im Auge behalten können und ist daher nicht immer auf aktuellstem Stand. Es ist also vergleichbar mit Debian.

Während Ubuntu also mit Main die wichtigsten Bestandteile einer Distribution wie den Kernel und Serverkomponenten wie apache oder php stets aktuell hält, bleiben viele andere Komponenten auf einem älteren Stand. Mit Ubuntu Pro lässt sich das ändern. Damit werden auch Pakete wie ffmpeg auf neuesten Stand gehalten. Das geht über das hinaus, was Freiwillige leisten können und Canonical lässt sich das auch bezahlen. Zielgruppe für den Service zusammen mit einigen anderen Goodies sind Firmen.

Aber netterweise darf man als Privatmensch diesen Service auf bis zu fünf Maschinen kostenfrei nutzen. Ich habe meinen alten Ubuntu-Account reaktiviert und auf diesem Server die Registrierung durchgeführt.

War trivial. Und es gab eine Menge zu patchen.

Es ist wirklich doof, wenn man von seinem Webhoster (in meinem Fall netcup) eine Mail vom CERT Bund weitergeleitet bekommt, in dem die Rede von einem möglichen Sicherheitsrisiko auf dem eigenen Server ist. Genauer gesagt ging es um diesen Scan:

Log:
"asn","ip","timestamp","rpc_response"
[...]
​
"197540","46.38.233.137","2018-08-06 04:21:33","100000 4 111/udp; 100000 3 111/udp; 100000 2 111/udp; 100000 4 111/udp; 100000 3 111/udp; 100000 2 111/udp;"
​
[...]

Er zeigt, dass rcpbind offen nach außen ist. Damit könnte mein Rechner für DDoS-Reflection-Angriffe missbraucht werden.

Also erst mal schnell auf der Maschine gescannt:

root@somesystem:~# netstat -anp | grep LISTEN 
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      31653/mysqld        
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      653/rpcbind         
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      6169/systemd-resolv 
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      832/sshd            
tcp6       0      0 :::111                  :::*                    LISTEN      653/rpcbind         
tcp6       0      0 :::80                   :::*                    LISTEN      899/apache2         
tcp6       0      0 :::22                   :::*                    LISTEN      832/sshd            
tcp6       0      0 :::443                  :::*                    LISTEN      899/apache2 

Und tatsächlich: da ist ein rcpbind, der da nichts zu suchen hat. Er ist da reingeraten, als ich vor ein paar Wochen meinen Server neu installiert habe und die Daten auf einem externen NFS-Mount zwischenlagerte. Dazu hatte ich nur nfs-common installiert, also nur den NFS-Client, nicht den Server. Und nur letzterer braucht rpcbind. Aber durch die Abhängigkeitsstuktur von nfs-common hatte ich da plötzlich ein Sicherheitsproblem durch ein rpcbind, das ich gar nicht bemerkt hatte.

In meinem Fall war die Lösung simpel.

apt remove nfs-common

Das deinstallierte automatisch libnfsidmap2, libtirpc1 und rpcbind.

Der nächste Scan sah besser aus

root@somesystem:~# netstat -anp | grep LISTEN
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      31653/mysqld        
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      6169/systemd-resolv 
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      832/sshd            
tcp6       0      0 :::80                   :::*                    LISTEN      899/apache2         
tcp6       0      0 :::22                   :::*                    LISTEN      832/sshd            
tcp6       0      0 :::443                  :::*                    LISTEN      899/apache2         
​

Fazit: als Abschluss nach einer Neuinstallation immer netstat -anp | grep LISTEN durchführen