35801
02.02.2009, aktualisiert um 20:22:33 Uhr
8498
8
0
OpenSolaris 2008.11 als Kunden-FTP-Server
Ich müsste einen FTP Server einrichten, auf den User Daten NUR UPLOADEN und nicht downloaden oder löschen können...
Erlaubt sollte sein: Ordner anlegen + Upload aber sonst nichts...
Gibts dazu ein Tutorial oder eine Anleitung?
Oder kann mir wer in groben Zügen sagen worauf ich achten sollte... Das Ding sollte zumindest halbwegs sicher sin...
Erlaubt sollte sein: Ordner anlegen + Upload aber sonst nichts...
Gibts dazu ein Tutorial oder eine Anleitung?
Oder kann mir wer in groben Zügen sagen worauf ich achten sollte... Das Ding sollte zumindest halbwegs sicher sin...
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 107857
Url: https://administrator.de/contentid/107857
Ausgedruckt am: 22.11.2024 um 17:11 Uhr
8 Kommentare
Neuester Kommentar
Zu beachten ist eigentlich nur, dass die FTP-User eine passende Umask beim Anlegen von Dateien verwenden (nur Schreibrechte, aber keine Leserechte). FTP sicher ist aber schonmal ein Widerspruch. In dem Fall solltest du SFTP verwenden. Bei FTP werden Passwörter im Klartext übertragen usw. Ansonsten als Doku:
man ftpaccess
man ftpusers
man ftpgroups
man ftpconversions
Mit den ftpconversions-Einstellungen sollte es sogar möglich sein einfach jede RECV-Anfrage auf eine Dummy-Datei umzuleiten.
man ftpaccess
man ftpusers
man ftpgroups
man ftpconversions
Mit den ftpconversions-Einstellungen sollte es sogar möglich sein einfach jede RECV-Anfrage auf eine Dummy-Datei umzuleiten.
SSH ist in der Standard-Konfig recht sicher. Noch besser absichern kann man es, indem man die Passwort-Authentifizierung abschaltet und nur Zugang via Key zulässt, den root-Zugang deaktiviert und den Standard-Port ändert. Wenn Key-Auth zu umständlich ist (weil z.B. Laien via SFTP drauf zugreifen können müssen o.ä.), dann sollte zumindest in der Konfiguration PermitRootLogin auf 'no' gesetzt werden. Root-Rechte kann man sich ja jederzeit via pfexec oder su verschaffen.
Auch der FTP-Server von OpenSolaris ist relativ sicher, solange man immer die aktuellsten Updates einspielt. Den Rechner darüber zu kapern ist jedenfalls nicht so einfach bzw. solange keine neue Lücke bekannt wird vermutlich unmöglich, selbst wenn er als root läuft, solange root nicht zu den ftpadm gehört und der Schreibzugriff auf ftpadm-User beschränkt wird.
Ein einfaches FTP-Server-Howto für Solaris kann ich leider nicht empfehlen. Im Normalfall nutze ich die Manpages, die sehr umfangreich sind und grossteils selbst für Konfigurationsdateien existieren. Ansonsten hilft die Solaris 10 System Administrator Collection unter http://docs.sun.com/app/docs/coll/47.16 zumeist weiter und natürlich der BigAdmin-Bereich von Sun unter http://www.sun.com/bigadmin/home/index.jsp Dokus lesen wirst du also vermutlich kaum umgehen können.
Auch der FTP-Server von OpenSolaris ist relativ sicher, solange man immer die aktuellsten Updates einspielt. Den Rechner darüber zu kapern ist jedenfalls nicht so einfach bzw. solange keine neue Lücke bekannt wird vermutlich unmöglich, selbst wenn er als root läuft, solange root nicht zu den ftpadm gehört und der Schreibzugriff auf ftpadm-User beschränkt wird.
Ein einfaches FTP-Server-Howto für Solaris kann ich leider nicht empfehlen. Im Normalfall nutze ich die Manpages, die sehr umfangreich sind und grossteils selbst für Konfigurationsdateien existieren. Ansonsten hilft die Solaris 10 System Administrator Collection unter http://docs.sun.com/app/docs/coll/47.16 zumeist weiter und natürlich der BigAdmin-Bereich von Sun unter http://www.sun.com/bigadmin/home/index.jsp Dokus lesen wirst du also vermutlich kaum umgehen können.
ipfilter sind die Firewall von OpenSolaris und insofern schon vergleichbar mit iptables. Diese hier zu erläutern würde aber den Rahmen des Forums sprengen. Ein Howto findet sich unter http://www.pir.net/pir/ipf/ipf-howto.html Zum Bruteforce-Schutz kann man Denyhosts oder fail2ban einsetzen. Beides muss allerdings nachinstalliert werden. Bei SSH reicht es aber normalerweise die Timeouts zwischen fehlgeschlagenen Logins entsprechend hoch zu setzen.