Neueste Beiträge

Na, ich weiß nicht, ob das mit den Abhänigkeiten so ganz stimmt.
Ein RPM ist bequem und man muß sich zumindest keine Gedanken um den Compilierungsvorgang mehr machen.
Aber wenn beim Compilieren etwas fehlen sollte, dann würdest Du das auf jeden Fall erfahren. :-)

Ich vertrete den Standpunkt: nur wenn man ein Programm selbst compiliert, weiß man, was man hat
und kann sich die Sache oft so maßschneidern, wie man es braucht oder man es haben möchte. Bei ausgereiften
Programmen sind i.d.R. beim Compilieren keine Schwierigkeiten zu erwarten, wenn alles erwartungsgemäß
vorhanden ist - das ist meistens auch der Fall. Falls dann doch einmal etwas fehlen sollte: dafür nehme ich
dann gerne wieder RPM's oder Sonstiges zu Hilfe...

mfg.
  VolGas

Stimmt. Ich habe auch wieder nicht ganz alles verstanden, aber das macht nichts.
Ich gebe Dir einfach ein paar Fakten und Du kannst dann selbst entscheiden.

* Per FTP wird alles im Klartext übertragen: Benutzername, Passwort, Daten - einfach alles.
Ein root-Account ist prinzipiell Gegenstand von sportlichen Anstrengungen gehackt zu werden,
was irgendwann gelingt's meist auch: die "Masse" macht's...

* Nur für "root" gelten keine Zugriffsrechte, alle anderen User sind diesen unterworfen.

* Per FTP kanst Du -meines Wissens- weder einen Eigentümer, noch eine Gruppe ändern.

* Rekursive Arbeiten (chown|chmod|rm -R ...) gehen per FTP überhaupt gar nicht und müssen
einzeln mühsam nachgebildet werden - das dauert und belegt unnötig Systemresourcen.

* Aber das allerwichtigste:
wenn der ProFTPD als "root" läuft und irgendwo eine Schwachstelle im System (Kernel) oder im Programm
selbst ist, hat ein potentieller Angreifer oder ein amok laufender Prozess keine "Hemmungen" mehr:
als root kann er schalten und walten wie er will...
Aus dem Grund hat der ProFTPD (und jeder andere "gescheit" programmierte Server) nur dann root-Rechte,
wenn dies unbedingt erforderlich ist. Den Rest der Zeit "fährt" er als nicht privilegierter Prozess.

Ich kann nicht verstehen, warum Du Dich so anstellst und warum eine Administration per FTP erstrebens-
werter als eine per SSH sein soll. Ich sehe keine Vorteile, nur Nachteile.
Wenn es nur um eine bequeme Benutzeroberfläche geht: es gibt z.B. den "midnight commander" (mc)...

Ich möchte mit Dir nicht über Sinn und Unsinn diskutieren und ob man nicht doch irgendwie und vielleicht...
Meine Meinung zu dem Thema und die Fakten, die mir im Moment gerade eingefallen sind, kennst Du nun.
Ich glaube, Dir fehlt im Moment einfach noch das Verständnis und der Überblick.

Wenn mein Rat und meine Erfahrung keinen Wert für Dich haben, dann ist das vollkommen ok.
Sammle Deine eigenen Erfahrungen, das ist gut.
Aber versuche nicht mit mir zu handeln.

mfg.
  VolGas

Also gegen brut-force-attacken kann ich dir pam und fail2bann empfehlen. fail2bann läuft auf meinen rechner seit nem jahr und haltet alle attacken auf . du kannst einstellen wie oft und wielange eine ip gesperrt ist.

da kann ich dir diesen rat geben.

Overloard

Danke für die Antwort.
ja ich interessiere mich sehr für linux und bin auch nicht unbedingt ein totaler Anfänger nur hab ich bis heute nur mit rpms was zu tun gehabt. da habe ich halt den vorteil, dass meine Abhängigkeiten kontrolliert werden und die benötigten packete gleich mit installiert werden.
Naja das wird aber auch ohne gehen. Vielen Dank nochmal für die Vielen tipps und die nette Antwort
Gruß

CW

Hallo VolGas, du hast wohl den Link zu diseser Support Seite Vergessen oder?
Meinst du etwa die hier?

Root muss sich natürlich nicht einlogen können. Nicht wenn ich einem anderen User, zusätzlich noch diese Verzeichnis zuweisen kann.

Und VolGas tut mir leid wenn du so viel schreiben "musstest" über dinge nach denen ich nicht gefragt / gebeten haben. Denn alles was ich brauch ist der zuriff auf das von mit gewähle Verzeichniss. Und eine Lösung gegen Brute-Force-Attacken.

Ich habe mein ganzes Vorhaben jetzt mal durchdacht:
Das mit dem Superuser habe ich mir egtl so vergestellt:
Ich Chroote den SU (im folgenden mit <su> abgekürzt) nicht, aber verbiete ihm mit
<Directory />
  <Limit ALL>
    DenyUser <su>
  </Limit>
<Directory>
den Zugriff aufs komplette Filesystem (entsprechende Ordner werden dann explizit erlaubt)

Was ist jetzt sinnvoller? (Auch wenn beides die Sicherheit einschränkt)
Den entsprechenden Ordnern chmod xx7 zu geben
   oder
dafür sorgen, dass <su> in der entsprechenden Ownergroup ist und dann chmod x7x zu vergeben. Denke der Weg wäre sicherer, obwohl alles beide aus selbe rauskommt, wenn jmd Zugriff auf den <su> bekommt.

Bei der zweiten Methode habe ich ein Problem:
Ich möchte PAM deaktivieren, also alles über "virtuelle" User/Groups regeln, aber wie kann ich mir chown/chgrp den User/Group auf einen Namen ändern, der nicht in der passwd/group existiert. Muss ich diese dann wirklich erstellen?

Wenn ich mit GroupOwner die Gruppe eines Files auf den des virtuellen <su> ändere, hat <su> dann wirlich die GroupRechte? Also wenn <su> nicht wirklich zu der Group gehört, die im Filesystem eingetragen ist.
Also an einem Beispiel:
<su> ist in der Group "sugrp"
Der Ordner "Folder1" hat als Owner "user1" und als Group "group1" und chmod 775
Mit "GroupOwner sugrp" ändere ich die Group von "Folder1" auf "sugrp" (zumindest für ProFTPd)
Hätte <su> jetzt rwx-Rechte? Ich denke ja, weil du hast ja gemeint ich solle mir das wie eine Shell vorstellen.

Sorry, meine Fragen sind glaube ich sehr verwirrend 

Hallo!

Das hatte hier jemand im Board compiliert und privat zur Verfügung gestellt.
Ich selbst kenne keine Adresse, wo man den ProFTPD als relativ aktuelle Version fertig als RPM ziehen kann.

Versuche doch einmal selbst den ProFTPD zu compilieren - das ist nicht sonderlich schwer und Du hast eine
auf Dich maßgeschneiderte Version und keine, die möchlichst alles für alle beinhaltet.

Ein Posting mit Beispiel zum Compilieren des ProFTPD: ->hier,
Erklärungen zu den dort genutzten Optionen: ->hier.

Konfiguration:
Eine gut funktionierende proftpd.conf, die die wichtigsten und meist benötigten Anforderungen abdeckt,
kann man bei den ->Beispiel Konfigurationen finden: die ->proftpd.conf Standard Deluxe...

Noch ein Lesetipp: solltest Du ernsthaft Interesse an Linux haben, so kann ich Dir nur wärmstens z.B.
das Standardwerk, den "Kofler" empfehlen - aber auch im Internet kann man vieles finden -
wenn man nur danach sucht...

mfg.
  VolGas

Hallo!

Als erstes empfehle ich Dir zunächst einmal die Support-Seiten von Stonki (diese Site hier) durchzulesen,
damit Du ein bischen Grundwissen bekommst.

Als nächstes muß ich Dir einfach sagen, daß ich es für eine -Entschuldigung!- absolut blödsinnige und dumme
Idee halte, sich per FTP als root einloggen zu wollen. Das FTP-Protokoll ist dafür in keinster Weise dafür geeignet!
Als root sollte man sich prinzipiell nur über ssh einloggen und selbst das nicht direkt, sondern über einen
"Dummy-User". Überlege Dir das Thema ruhig noch zwei/drei Dutzend mal, ob Du wirklich das Risiko eingehen
möchtest.

Deine Konfiguration ist extrem sparsam und bevor wir jetzt anfangen, an Konfigurationsdateien herumzuschrauben
und alles von Pontius bis Pilatus durchexerzieren müssen, möchte ich Dir vorschlagen, daß Du Dir zunächst die
Beispielkonfigurationen ansiehst. Eine gut funktionierende proftpd.conf, die die wichtigsten und meist benötigten
Anforderungen abdeckt, kann man bei den ->Beispiel Konfigurationen finden: die ->proftpd.conf Standard Deluxe...

Versuche es doch einmal damit, Du mußt sie nur ein ganz klein wenig Deinen Beürfnissen anpassen.

Zu "MaxLoginAttempts":
Nach der maximal erlaubten Anzahl von Versuchen wird man vom Server getrennt. Aber das hindert nichts und
niemanden, es gleich sofort wieder erneut zu versuchen. Wenn Du da mehr Sicherheit brauchst, dann solltest Du
Dich mit dem Thema FireWall oder IP-Tables befassen. Wer sich allerdings per FTP als root einloggen möchte,
der dürfte keine Sicherheitsporbleme haben...

Überlege Dir das mit dem root-Zugriff per FTP wirklich noch einmal sehr, sehr gut!

mfg.
  VolGas

Ich habe Deine Frage schon richtig gelesen, ich konnte nur nicht verstehen, warum Du das gefragt hattest,
wo Du die Antwort doch schon kanntest. Deswegen war ich wohl auch ein wenig genervt, sorry.
Aber nun ist klar, denn an die Beschränkung von FTP-Befehlen per "<Limit>..." hatte ich nicht gedacht.
Das Wörtchen "HideNoAccess" würde ich unbedingt wörtlich nehmen - kein Zugriff, keine Anzeige.

Adminaccount:
Es stimmt schon: ohne eingeschaltetes "DefaultRoot" gibt es auch kein chroot-Gefängnis.
Aber das ist ja nur die halbe Miete: es greifen doch auch und gerade noch die Rechte des Filesystems!
Wenn ein User nicht zumindest die selbe Gruppe wie den "Admin" reinläßt, oder gar explizit die Rechte nur
sich selbst einräumt, dann hat ein sogenannter Admin absolut verloren - er kommt nicht ran, wenn er keine
root-Rechte hat.

Der ProFTPD ist wie eine Usershell zu betrachten: nach dem Einloggen hat der neu gestartete, individuelle
Prozess die selbe User- und Group-ID wie der eingeloggte User - alle Root-Rechte wurden aufgegeben.
Damit hat der ProFTPD nur noch die selben Zugriffsrechte wie der User. Das kann nicht ausgehebelt oder
umgangen, sondern nur weiter ausgebaut werden!

Also: der ProFTPD nutzt im vollen Umfang die Zugriffsrechte des Filesystems, nein, er ist ihnen sogar völlig
unterworfen. Alles, was man in der Konfiguration mit "<Limit>" zusätzlich einschränkt, sind nur FTP-Befehle,
keine eigentlichen Zugriffsrechte. Daher ist man gut beraten, wenn man mit Limitierungen in der proftpd.conf
möglichst sparsam umgeht oder besser gar nicht verwendet.

Von daher ist der Wunsch eines Admins oder Superusers nicht realisierbar - das kann (sollte!!!) man aus gutem
Grund nur als "root" über die SSH und man sollte es unbedingt vermeiden, dies per FTP tun zu wollen.
(das geht zwar, ist aber per default -zum Glück!- deaktiviert)

mfg.
  VolGas

Hallo ftpler

ich suche ein rpm von proftpd für suse 10.2 alle links hier im board zu diesen rpms funktionieren nicht. Hat das vieleicht noch jemand für mich?


Gruß CW