Ist das denn schon sinnvoll? nftables scheint mir noch recht jung zu sein. In Jessie gibt's das nur über Backports. Der Kernel muss mindestens 3.13 sein, besser 4.2 und auf Jessie läuft noch 3.16. Scheint mir ein bisschen riskant für einen Produktivserver. Gibt es denn einen guten Grund ausser "ist halt neuer und technisch überlegen"? Die Kehrseite davon ist ja bekanntlich "nicht so gut supported, Kinderkrankheiten und nicht stabil".
Beiträge von sseeland
-
-
Schick, vielen Dank!
jetzt ist tatsächlich nur noch SSH offen!
So stell ich mir das vor. Jetzt kann ich ganz gemütlich anfangen die eigentliche Serversoftware zu installieren (nachdem ich iptables eingerichtet habe
) -
Die Dienste werden anscheinend bei Debian standardmäßig installiert. Ich habe das Debian Jessie 64 bit minmal Image von netcup aufspielen lassen und da war der Dienst schon installiert und im Autostart eingetragen. Den vorinstallierten exim4 habe ich schon runtergeschmissen (werde ich zu gegebener Zeit durch ein Postfix ersetzen). Das scheint aber nicht der Fehler von Netcup zu sein. Ich habe auch zu hause schon mal ein Debian Jessie in einer VM installiert und da lief das auch von vornherein mit. Keine Ahnung warum Debian das per default installiert und startet.
Und wo wir schon mal dabei sind: ein dhcp client läuft da anscheinend auch:
Code
Alles anzeigensudo 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 0.0.0.0:51065 0.0.0.0:* LISTEN 106 2000 413/rpc.statd tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 0 9828 404/rpcbind tcp6 0 0 :::111 :::* LISTEN 0 9831 404/rpcbind tcp6 0 0 :::42356 :::* LISTEN 106 2006 413/rpc.statd udp 0 0 0.0.0.0:1003 0.0.0.0:* 0 9827 404/rpcbind udp 0 0 127.0.0.1:1013 0.0.0.0:* 0 9915 413/rpc.statd udp 0 0 0.0.0.0:27302 0.0.0.0:* 0 9712 375/dhclient udp 0 0 0.0.0.0:53191 0.0.0.0:* 106 1997 413/rpc.statd udp 0 0 0.0.0.0:68 0.0.0.0:* 0 1950 375/dhclient udp 0 0 0.0.0.0:111 0.0.0.0:* 0 9824 404/rpcbind udp6 0 0 :::1003 :::* 0 9830 404/rpcbind udp6 0 0 :::4002 :::* 0 9713 375/dhclient udp6 0 0 :::111 :::* 0 9829 404/rpcbind udp6 0 0 :::45185 :::* 106 2003 413/rpc.statdbraucht man den? Bzw wo kommt der eigentlich her? Im systemd finde ich den nicht...
-
Hallo!
Seit heute bin ich auch stolzer Besitzer/Mieter eines vServers bei netcup. Jetzt bin ich dabei das System einzurichten und abzusichern. Ich bin - zugegebenermaßen - noch ein bisschen unerfahren was Serveradministration angeht. Nicht hauen! Irgendwann muss man sich ja mal in's Netz wagen. Ich habe durchaus Erfahrungen mit Linux (nutze Arch als mein Hauptbetriebsystem auf meinem Heim-PC) und habe auch schon einige Homepages betrieben, allerdings nur auf Shared Hosting Tarifen.
Also, in dem Versuch, alle unnötigen Serverdienste zu deaktivieren bin ich per netstat auf diverse RPC-Ports gestoßen:
Code
Alles anzeigensudo netstat -tlpn Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:51065 0.0.0.0:* LISTEN 413/rpc.statd tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 404/rpcbind tcp6 0 0 :::111 :::* LISTEN 404/rpcbind tcp6 0 0 :::42356 :::* LISTEN 413/rpc.statdDie Infos die ich im Netz dazu finde sind recht schwammig. Manche sagen, das kann man einfach rausschmeißen. Irgendwo habe ich gelesen, dass man das für NFS braucht. NFS habe ich zu hause nie benutzt, deswegen habe ich rpcbind immer gnadenlos entfernt, aber ich glaube bei euch wird der Storagespace per NFS eingebunden, oder? Irgendwo stand noch, dass man den rpcbind service nur braucht, wenn man NFS hosted, aber nicht als client. Das war aber nicht sehr vertrauenserweckend.
Also, die Frage kurz und bündig:
Kann ich rpcbind deactivieren oder krieg ich dann irgendwie Probleme mit meinem Storagespace / vServer? Gibt es Mittel und Wege das ganze auf das netcup-interne Netzwerk zu beschränken, so dass wenigstens von außen keiner ran kommt? Muss ich sonst irgendwas bedenken um diese Ports abzusichern?Vielen Dank schon mal!
