Port 44442 bei Portmapper

22/12/2010 - 21:26 von Andreas Kohlbach | Report spam
Ich gebe hin und wieder Verzeichnisse für einen Freund via NFS (ist das
noch zeitgemàß?) frei. Der Portmapper lauscht auf Port 111, nimmt aber
keine Verbindungen an (hatte ich so konfiguriert). So weit so gut.

Neulich scannte ich meinen Rechner von der Ferne aus (mache ich hin und
wieder), da fiel mir zum ersten Mal auf dass RPC offenbar Port 44442 auf
macht, *und* auch Verbindungen (mit telnet getestet) angenommen
werden. Ich habe den Portmapper daher erstmal beendet.

Mir ist klar, dass ich Port 44442 filtern könnte. Aber gibt es keine
"saubere" Methode, dass der Port nicht lauscht, oder zumindest keine
Verbindungen annimmt?
Andreas
Linux: The choice of a GNU generation.
 

Lesen sie die antworten

#1 Juergen P. Meier
24/12/2010 - 09:04 | Warnen spam
Andreas Kohlbach :
Ich gebe hin und wieder Verzeichnisse für einen Freund via NFS (ist das
noch zeitgemàß?) frei. Der Portmapper lauscht auf Port 111, nimmt aber



NFS war nie und ist auch heute nicht dafuer geeignet ueber potentiell
unsichere Netzinfrastruktur sowie mit nicht vollstaendig
vertrauenswuerdigen Rechnern (ein NFS-Client und Server verbinden
ueber NFS ihr Sicherheitniveau und werden Sicherheitstechnisch zu
einem) verwendet zu werden.
Fuer NFS musst du gegenueber
- dem Uebertragungsmedium und der Netzinfrastruktur sowie
- dem Server und dem Client (Betriebsystem, Administrator)
*vollstenaidges* Vertrauen aufbringen koennen. Das kannst du bei
oeffentlichen Datennetzen (Internet) schon mal grundsaetzlich nicht.

Sofern du dem Client (deinem Freund) bezueglich System, Konfiguration
und Administration voll vertraust, kannst du ein Vertrauenswuerdiges
Netz mittels VPN Technologien (OpenVPN, IPSEC, SSH-Tunnel etc.)
schaffen. Andernfalls ist NFS nicht das passende technische Werkzeug.

keine Verbindungen an (hatte ich so konfiguriert). So weit so gut.

Neulich scannte ich meinen Rechner von der Ferne aus (mache ich hin und
wieder), da fiel mir zum ersten Mal auf dass RPC offenbar Port 44442 auf
macht, *und* auch Verbindungen (mit telnet getestet) angenommen
werden. Ich habe den Portmapper daher erstmal beendet.

Mir ist klar, dass ich Port 44442 filtern könnte. Aber gibt es keine
"saubere" Methode, dass der Port nicht lauscht, oder zumindest keine
Verbindungen annimmt?



Du weist schon, wie NFS funktoiniert?

Falls nicht, NFS funktoinert so:

Der Client fragt den Portmapper des Servers (TCP/111) nach dem Port
fuer die NFS-dienste "mountd", "nfsd", und optional "statd" sowie
"lockd".
Diese Ports sind prinzipiell dyanmisch (deswegen der Portmapper) -
auch wenn der nfsd aus historischen Gruenden idR. den Port 2049 beim
Portmapper registriert. Die anderen Ports sind jedoch Wahlfrei und
Zufaellig.
Sobald der Client die Portnummern der einschlaegigen Ports hat, macht
er Verbindungen zu den Diensten auf - ohne das funktionert NFS nicht.

Du kannst mit "rpcinfo -p" nachschauen, welcher Dienst sich hinter
Port 44442 verbirgt.

Fuer NFS zwingend Notwendig sind der "mountd" und "nfsd" Dienst.
Fuer zusaetzliche Funktionalitaet wie z.B. bei gemeinsamen Zugriff auf
die selben Dateien (paradebeispiel: zwei Mailclients auf das gleiche
Maildir/Mailbox via NFS) benoetigst du die optionalen Dienste (lockd in
diesem Fall) - bei read-only Zugriff kann man darauf aber auch meist
verzichten.

Grundsaeztlich ist das ungefilterte Bereitstellen des mountd und nfsd-
Dienstes gegenueber unsicheren Datennetzen (Uni-Netz, Hotel-LAN,
Internet) eine selten Daemliche Idee[tm]. Denn ungeachtet der
inhaerenten Sichehreitsprobleme von NFS (die bei aktuellen
Implementierungen mehr oder weniger gut abgesichert sind), bleiben die
prinzipiellen Probleme mit der Art und Weise, wie die exports(5)
Authentifizierung bei NFS (mountd) konzeptioniert und implementiert
ist. Wenn du in deiner /etc/exports Datei auch nur einen einzigen
Hostnamen stehen hast, oder gar einen Wildcard verwendest, hat ein
Angreifer ein sehr sehr leichtes Spiel.

Es gibt keine Netzwerkdateisysteme, die mehr als zwei der folgenden
drei Kriterien erfuellen:

* Bequem und Einfach in der Handhabe (Betrieb)
* Sicher ueber ungesicherte Datennetze (Authentizitaet & Integritaet)
* Schnell und Effizient (Betrieb wie Uebertragung)

Zum Ersten Punkt gehoert auch die Interoperabilitaet und
Compatibilitaet diverser Client- und Serverimplementierungen - daran
scheitert z.B. auch WebDAV.
Zum Punkt 2: ja, der beinhaltet keine Vertraulichkeit,
Verschluesselung ist nicht Aufgabe eines Netzwerkdateisystems.
Vertraulichkeit kann man sowohl ueber Datei- als auch ueber
Transportverschluesslungen erreichen - die beides erstmal nichts mit der
Netzwerkdateissystemtechnologie zu tun haben.

Juergen
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)

Ähnliche fragen