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

Ok.

Aber eines ist mir an Deiner SQL-Konfiguration aufgefallen: "SQLDefaultUID" und "SQLDefaultGID"
überschreiben die Werte aus der Datenbank. Entweder die Werte aus der SQL-Tabelle, oder die Default-Werte.
Das kann man mischen und ausnutzen: wenn alle User in der selben Gruppe sein sollen (z.B. wegen Apache),
dann kann man mit "SQLDefaultGID" allen die selbe Gruppe zuweisen und bei "SQLUserInfo" den Feldnamen
für die Gruppe mit "NULL" definieren. Dann braucht man die GID in der SQL-Tabelle gar nicht mehr.
Erst recht gilt dies für den völlig unnötigen und nutzlosen Anachronismus des Shell-Wertes.

Mein Beispielszenario würde dann so aussehen:

    SQLUserInfo     ftp username password uid NULL homedir NULL
    SQLDefaultGID   65534

Die Tabellenfelder "gid" und "shell" könntest Du Dir dann schenken...

Einen hab' ich noch:
vergiß das "AuthOrder mod_sql.c" nicht, um die Authorisation alleine auf SQL zu begrenzen...

mfg.
  VolGas

Wieso auch?
Mit "HideNoAccess" wird alles ausgeblendet, auf das der User kein Zugriffsrecht hat - sonst nix.
Siehe auch ->hier.

Vorbeugend noch einmal zu den Symlinks: wenn ein User mit "DefaultRoot" in sein Verzeichnis
eingesperrt wird (chroot), dann hilft ein Symlink auch nicht als Notausgang nach "draußen".

Idealer weise hat jeder User in seinem Homeverzeichnis das, was ihm gehört und was er braucht.
Außerhalb seines Verzeichnisses hat er nichts zu suchen. So etwas wie ein Admin-Account ist mit
FTP auch nicht zu machen, es sei denn, man ist so verrückt und hebt die Sicherheitssperren des
ProFTPD auf und loggt sich per FTP als "root" ein.

Ich schreibe das deshalb, weil Deine Fragen in diese Richtung zielen...

mfg.
  VolGas

Das mag sein, aber wie man den ProFTPD in den Debugmode bringt, steht da schon.
Aber das brauchen wir vielleicht gar nicht: setze mal "DelayEngine off" ein, das könnte
es nämlich schon gewesen sein. Ein paar Postings weiter unten hatte schon jemand das
gleiche Problem und im Forum findest Du das über die Suchfunktion auch immer wieder.

mfg.
  VolGas

Ja, natürlich.

Das ist eigentlich ein Grundprinzip unter Linux/Unix, daß jeder User sein eigenes Homeverzeichnis hat.
Und dahin schickt man ihn dann mit "DefaultRoot ~" - und das sperrt ihn damit auch gleichzeitig ein.
(Das "~" als erstes Zeichen in einem Pfadnamen bedeutet das Homeverzeichnis des jeweils aktuellen Users)

Solltest Du ernsthaft Interesse an Linux haben, so kann ich Dir nur wärmstens z.B. das Standardwerk,
den "Kofler" empfehlen...

mfg.
  VolGas

Hi.

Benutze: "ShowSymlinks on"

BTW: was Du da beschrieben hast ist IMHO die blödsinnigste, nein, Schwachsinnigste Konfiguration,
von der ich je gelesen habe. Außerdem ist der Windows-Explorer kein FTP-Browser, er kann nur ein
klein wenig FTP - und das schlecht und falsch. Aber bei jemandem, der so das System vergewaltigt,
spielt das wohl auch keine Rolle mehr. Sorry, ich wollte Dich nicht angreifen, aber Du scheinst von
Unix null Ahnung zu haben, sonst würdest Du solchen Blödsinn nie verzapfen.

mfg.
  VolGas

Hallo!

Daher vermute ich einen Fehler in der Standardkonfiguration von Strato.

Dumme Frage: warum wendest Du Dich dann mit Deinem Problem nicht an Strato?
Nicht, daß ich (wir) Dir hier nicht helfen wollten...

Wenn das Thema schon mal diskutiert und gelöst wurde, bitte Link reinposten.

Ich und alle anderen müßten genauso suchen wie Du. Also...

Um Dir helfen zu können, brauchen wir schon ein bischen mehr als nur eine einfache Fehlerbeschreibung.
Poste hier Deine proftpd.conf und eine Debug-Ausgabe (siehe ->FAQ) eines Loginversuchs.
Von der Debug-Ausgabe bitte nur ab dem Loginversuch, die vorherige Ausgabe bitte verwerfen.

mfg.
  VolGas

Hallo!

Ich würde darauf tippen, daß Dein System ein Update/Upgrade "erlitten" hat und nun der ProFTPD
Probleme mit einer neuen, geänderten Library hat.

Mein erster Tipp: compiliere/installiere den ProFTPD neu und behalte dabei die alte proftpd.conf bei -
dann sollte es wieder wie zuvor funktionieren.

mfg.
  VolGas

Hallo!

Zuerst einmal möchte ich folgendes loswerden: wenn Du Dich schon auf eine Fremd-Installation einläßt,
warum fragst Du dann bei Problemen damit nicht denjenigen, der das Ganze "verzapft" hat?

Nicht, daß ich (wir) Dir nicht helfen möchten, doch wenn jemand ein fertiges Paket anbietet, dann sollte
er auch selbst dafür sorgen, daß alles funktioniert und ggf. einen adäquaten Support dafür anbieten.
Zum Paket/System und dessen Verstrickungen mit dem ProFTPD selbst kann ich nichts sagen -
nur isoliert über den ProFTPD selbst.

Nun denn:
Ich habe mir Deine Konfigurationsdatei nicht ganz angesehen, denn schon bei der zweiten Zeile bin ich
hängen geblieben: "DefaultAddress 127.0.0.1".

Dir ist schon bewußt, daß mit dieser Adresse der "localhost" gemeint ist?
Das heißt: Du kannst den FTP-Server nur lokal auf der Maschine selbst ansprechen.

Es wurde zwar auch noch "DefaultServer on" angegeben, aber dadurch, daß nur drei relativ unbedeutende
Direktiven im "<Global>"-Kontext deklariert wurden, beziehen sich fast alle anderen Direktiven auf den
Default-Server.

Versuche es zuerst einmal mit der Korrektur von "DefaultAddress" - vielleicht reicht alleine schon das.
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...
Die funktioniert auch mit mehreren IP's richtig und wäre nur noch entsprechend anzupassen.

Ob die Fehlermeldung nicht nur irreführend ist, kann ich so nicht sagen.
Welche Version von ProFTPD hast Du auf Deiner Maschine?
Und ist die jetzt -wie Du geschrieben hast- von dem VHCS2-Paket oder via "apt-get" von Debian oder...?

mfg.
  VolGas

Nein, nicht so ohne weiteres.
Aber Du könntest z.B. bei einem virtuellem User in einer SQL-Datenbank einiges mit dem SQL-Query zaubern.

Zu dem ursprünglichen Problem:
Versuch's mal mit: PathAllowFilter "^bild\.jpg$" bzw. PathAllowFilter "^020\.jpg$"

Wenn Du mit regular expressions nicht zurechtkommst, solltest Du mal im Internet danach suchen.
Zu dem Thema gibt es einge Tutorials und HowTo's - hier würde das den Rahmen bei weitem sprengen
und ist auch nicht Gegenstand dieses Forums.

mfg.
  VolGas

Herzlichsten Dank!

Bleibt abzuwarten, ob und wann es einen Patch dafür gibt.
Ich hoffe "castaglia" lässt sich (möglichst bald!) darauf ein, denn nun brennt mir das Problem
unter den Fingernägeln und ich muß eine endgültige Entscheidung treffen.

mfg.
  VolGas

Exakt, stimmt genau.

Du kannst nur zwei Systeme mit gleicher Konfiguration vergleichen, sonst ist das wie mit Äpfel und Birnen.

mfg.
  VolGas

Hallo,

nein, nicht ohne weitere Informationen.
Poste bitte Deine proftpd.conf und ein Debug (siehe ->FAQ) eines Logins
Was vorher ausgegeben wurde, bitte verwerfen!

mfg.
  VolGas

Hallo,

das kannst Du -meines Wissens- nicht verhindern.
Wenn es Dich gar zu arg stört kannst Du vielleicht mit ->SyslogLevel die Empfindlichkeit des Logs ein wenig verringern,
aber das wäre dann global. Mein Tipp: wie so manch anderes in anderen Logs einfach ignorieren.

Zwei Dinge, die ich noch erwähnen möchte:

• nach Deinem SmartFTP-Log hast Du Dich ganz normal und nicht per FTPS eingeloggt.
• Ich empfehle Dir, "TLSProtocol" auf "SSLv23" zu stellen, manche FTP-Browser kommen mit "TLSv1" nicht klar

mfg.
  VolGas