Das Modul "mod_ifsession" ist in den aktuellen ProFTPD-Sourcen enthalten und kann als Compile-Option
bei "configure" angegeben werden. Steht doch aber auch in der Doku:

This module is contained in the mod_ifsession.c file for ProFTPD 1.2, and is not compiled by default.
Installation instructions are discussed here.

Ein Posting mit Beispiel zum Compilieren des ProFTPD kannst Du auch ->hier im Forum finden,
kurze Erklärungen zu den dort genutzten Optionen: ->hier.

Du müßtest bei dem Beispiel nur noch ein ":mod_ifsession" ganz an das Ende der "--with-modules"-Option setzen.

Vielleicht gibt es aber auch das ein oder andere RPM-Paket (oder ähnliches) des ProFTPD, das dieses Modul
schon beinhaltet. Ob Dein ProFTPD das Modul vielleicht schon hat, kannst Du nachprüfen, indem Du ihn mit
dem Parameter "-l" (kleines "L") startest, also z.B. so (Pfad anpassen!): /usr/local/sbin/proftpd -l

Wie man ein Softwarepaket compiliert ist allerdings nicht Gegenstand dieses Forums - ich bitte daher dies-
bezüglich gleich von Fragen oder gar Diskussionen hier im Forum abzusehen. Das Thema ist zu komplex -
irgendwo muß man eine Grenze ziehen, sonst schreibt man sich nur die Finger an Fragen wund, die anderweitig
schon zig-tausend fach beantwortet wurden und immer nur weitere neue Fragen nach sich ziehen. Sorry...

mfg.
  VolGas

Ich muß mich revidieren: es könnte doch eine Möglichkeit geben: wenn Du den ProFTPD mit dem
Modul "mod_ifsession" als letztes Modul compilierst, könnte dieses Konstrukt vielleicht funktionieren:

   <IfGroup party>
      MaxClients 5 "Die Party ist komplett - Du kommst hier nicht rein!"
   </IfGroup>

   <IfGroup !party>
      MaxClients none
   </IfGroup>

Der erste Anweisungsblock beschränkt die Gruppe "party" auf fünf User und lehnt jeden weiteren mit der optionalen
Meldung ab. Der zweite Block bezieht sich durch das Ausrufezeichen vor dem Gruppennamen auf alle anderen User.
Von diesen können sich dann noch bis "MaxInstances" erreicht ist, einloggen. Den zweiten Block könnte man wahr-
scheinlich weglassen, er steht da nur der Vollständigkeit halber...

Ich empfehle Dir, die Doku des Entwicklers zu dem Modul ->mod_ifsession durchzulesen, dann siehst Du klarer.

mfg.
  VolGas

Nachdem es so aussah, als könnte und würde sich das Problem mal schnell mit einem Patch lösen lassen
(Zitat: "I suppose I could work on a patch, when I get a chance, later today") hat sich "castaglia" doch
nicht dazu entschießen können, das Problem anzupacken: kein Handlungsbedarf.

Sehe ich gänzlich anders, kann aber leider nichts machen...     

Ich brauche wohl nicht extra zu betonen, daß ich sehr enttäuscht bin.
Trotzdem noch einmal besten Dank an Stonki für seinen Einsatz.

mfg.
  VolGas

Genau - der ProFTPD läuft schon mit einer anderen Konfiguration.

Außerdem wurde der ProFTPD meiner Ansicht nach ein wenig unglücklich compiliert: er sucht sein Konfigurationsfile
in "/usr/local/etc/" und nicht in "/etc" wie normalerweise üblich. Wenn man das beachtet und nicht vergisst, dann ist
das ok. Sonst wundert man sich nur, weshalb die Konfiguration scheinbar nicht angenommen wird.

mfg.
  VolGas

Leider sind gerade oft die Dinge, die man meint schnell erledigen zu können, die größten Zeitfresser.
Und da hast Du Dich -wenn man es gut machen und auch verstehen möchte- an ein riesiges Gelage
mit vielen Gängen, das auch über mehrere Tage hinweggehen kann, herangewagt.

Guten Appetit!

mfg.
  VolGas

HiHo !?

Dir stehen als Begrenzung die folgenden Direktiven zur Verfügung:

• ->MaxClients
• ->MaxClientsPerHost
• ->MaxHostsPerUser
• ->MaxInstances
• ->MaxLoginAttempts
• ->MaxClientsPerUser
• ->MaxClientsPerClass

Dies sind die Mittel, die Dir zur Verfügung stehen - und das ist nicht wenig.
Wenn Du Deine Gruppe irgendwie als "Class" definieren kannst (z.B. gemeinsamer IP-Netz),
dann ist es möglich über das Modul "mod_ifsession" diesen Bereich separat zu händeln.

Ich vermute mal, daß Du nicht hinbekommen wirst, was Du vor hast.

mfg.
  VolGas

Hallo,

Deine Schreibe ohne Punkt und Komma kann man kaum lesen - grausam.
Nun aber habe ich mich durchgekämpf und glaube verstanden zu haben.

Ich vermute, daß Dein Problem in den falschen Zugriffsrechten bzw. in einer falschen User-/Gruppenzuordnung
bedründet sind. 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.

Bei einem so komplexen System wie Plesk und Konsorten sind die einzelnen Elemente sehr stark aufeinander
abgestimmt. In diese empfindlichen Abhängigkeiten einzugreifen erfordert schon eine recht gut Kenntnis der
Hosting-Software. Ich bin daher auch der Meinung, daß sich jeder, der ein fertiges Paket eingekauft hat, auch
an denjenigen wenden sollte, der ihm das Paket zusammengeschnürt und "verkauft" hat.
Wenn Dir eine Leberwurst nicht schmeckt, dann beschwerst Du Dich ja auch beim Metzger - und nicht beim
Landwirt, der das Schwein großgezogen hat. Der Vergleich mag hinken, aber Du verstehst was ich meine.

Tut mir leid, daß ich/wir Dir hier nicht weiterhefen können und es mag alles arrogant und hart kingen,
ist aber nur ehrlich. Wer sich irgendwo ohne eigene Kenntnisse etwas fertiges "einkauft", limiiert
sich auch gleichzeitig auf diesen Level.

mfg.
  VolGas

Doppelpost? Wo?

Freut mich, daß es jetzt bei Dir funktioniert.
Hast Du nun letztendlich mySQL 4 oder 5 am Laufen?

Die Information über den mySQL-Server ist mir zwar nicht neu, sehr wohl aber daß diese obsukre Fehlermeldung
von den Passworten abhängt und darüber auch beseitigt werden kann. Die Fehlermeldung führt einem ja auch ein
wenig an der Nase herum und ist voll irreführend.

Vielen Dank für die wertvolle Information und den Link dorthin, das hat auch mir weitergeholfen.

mfg.
  VolGas

Jep, vieel besser!

Ich weiß, warum es nicht geht und wenn Du ein bischen suchst, siehst Du es auch.
Wir sind aber nicht beim Rätselraten - in dem proftpd-sql.log steht am Anfang: "backend module 'mod_sql_mysql/4.05"
Das ist der mySQL-Client 4.05, aber Du hast ein 5er mySQL-Server installiert - das passt nicht zusammen!
message: 'Client does not support authentication protocol requested by server; consider upgrading MySQL client'

Es gibt zwei Möglichkeiten: Du installierst ein 4er mySQL-Server und gut ist.
Oder Du holst den Client und die ...-dev-Pakete für den 5er Server und compilierst damit den ProFTPD neu.

IMHO reicht ein 4er mySQL-Server heutzutage für Webanwendungen immer noch aus - nicht zu gierig sein...!

Nun hast Du den Ball wieder.

mfg.
  VolGas

Mann-o-mann!
Am liebsten hätte ich alleine schon wegen Deiner elendigen und zusammenhangslosen Schreibe ohne Punkt
und Komma diesen Thread ignoriert. Du wärst auch besser bei der "apt"-Methode geblieben oder hättest Dich,
wenn Du schon keine Ahnung hast, zumindest vorher vernünftig informiert, bevor Du angefangen hast, dieses
Durcheinander anzurühren. Sorry, aber Du hast Mist gebaut.

Versuchen wir aufzuräumen: beende zuerst alle evtl. noch laufenden ProFTPD-Prozesse (frag' nicht wie!).
In "/etc" gibt es normalerweise kein "bin", "sbin" oder "etc": sieh' hinein und wenn nur Teile des ProFTPD
drinnen sein sollten: Löschen!

Jetzt kommt es darauf an: willst Du eine Version mit "apt-get" oder eine selbst compilierte?

Wenn Du Deine Version selbst compilieren möchtest, dann entferne zuerst auch die mit "apt-get" Installierte.
Gib beim Compilieren bei "configure" als Prefix z.B. "/usr/local/proftpd" an: die ganze Installation wird dann in
dieses ggf. neu zu erstellende Verzeichnis vorgenommen und nicht über das System verteilt. Man kann (sollte)
aber eine Installation nicht komplett auf ein Verzeichnis beschränken, sondern etwas differenzieren.

Ein Beispiel, wie man den ProFTPD compilieren kann(!) findest Du ->hier, Erklärungen zu den Optionen ->hier.
In der letzten Zeile hatte ich dort definiert, daß die Konfigurationsdatei proftpd.conf in "/etc" und die Manual-Files
entsprechend in einer anderen Default-Position installiert werden.

Wenn das Compilieren geklappt hat, dann passe noch das Script in "/etc/init.d" an, dort muß nämlich der Pfad
zu dem ausführbaren ProFTPD-Binary angegeben sein, sonst kann es nicht funktionieren. Um dann den ProFTPD
zu starten oder zu beenden benutzt Du nur noch dieses Script. (z.B. Starten: "/etc/init.d/proftpd start")

Eigentlich ist dieses ganze Geschreibsel von mir off-topic, denn es wird in diesem Forum erwartet, daß zumindest
die Linux-Grundkentnisse vorhanden sind. Eine Anleitung, wie Du Dein System konfigurierst, hat nicht wirklich
etwas mit dem ProFTPD (und damit auch nichts mit diesem Forum) zu tun. Sorry, das klingt bestimmt hochgradig
arrogant, aber irgendwo muß man eine Grenze ziehen, sonst schreibt man sich nur die Finger an Fragen wund,
die anderweitig schon zig-tausend fach beantwortet wurden und nur immer weitere neue Fragen nach sich ziehen.
Ich werde mich daher auch nicht weiter über Compiler-Probleme, Start-Scripte o.ä. äußern: weitere Informationen
darüber findest Du teileweise hier im Forum über die Suchfunktion, auf dieser Website oder anderweitig im
Internet. Sehr gute Anlaufstelle: http://www.debianhowto.de/

Ebenso möchte ich Dir für den Anfang dringend z.B. das Standardwerk, den ->"Kofler" empfehlen.

mfg.
  VolGas

Ich muß Dich leider enttäuschen: es gibt keine Sperrzeiten.

Das liegt z.T. auch am Konzept des ProFTPD: wenn sich jemand neu einloggen möchte wird von der ersten Instanz
des ProFTPD ein neuer "Kind-Prozess" von sich selbst gestartet. Dieser eigenständige Prozess beendet sich dann
wieder nach erfolglosen "MaxLoginAttempts" Login-Versuchen - fertig: neues Spiel, neues Glück, nächster bitte...

Alleine das macht eine BFA schon erfolgreich: der Server wird bis zum Anschlag zur maximal erlaubten Anzahl
von Prozessen gezwungen, es bleibt keine Kapazität mehr für andere User übrig. Jedes starten eines neuen
Prozesses erzeugt schon alleine eine deutliche Prozesslast und wenn die maximale Prozesszahl nicht gut gewählt
bzw. errechnet wurde oder es schlimmstenfalls gar kein Limit gibt (initd!) - um so besser: das System kommt in
Speichernot und beginnt zu "swappen". Die Maschine sackt endgültig in die Knie, neue Anfragen (Requests)
werden intern in eine Warteschleife legt, bis auch diese irgendwann voll ist und "überläuft"...

Nun könnte man behaupten, daß das Konzept des ProFTPD sch...lecht sei, aber es funktionieren fast alle Server
auf ähnliche oder gleiche Weise. Daher muß man eine Brute-Force-Attack schon im Ansatz abwehren, bevor sie
an der eigentlichen Serversoftware ankommt. Der Angriff findet nämlich schon auf Protokollebene statt, indem
man die Maschine einfach mit Anfragen überflutet und oft gar nicht mehr auf Antwort wartet. Damit sind wir
dann schon beim sog. "Flooding"...

Was macht man also am besten dagegen?
Ebenfalls auf Protokoll- und Systemebene reagieren!

Hier kommt z.B. IPtables/Netfilter als Teil des Betriebssystems (Kernel) ins Spiel. Versucht z.B. eine IP in einem
definierten Zeitabstand immer wieder eine neue Verbindung aufzubauen, dürfte mit hoher Wahrscheinlichkeit eine
BFA vorliegen und nach x Versuchen ignoriert das System einfach für eine voreingestellte Zeit alle Anfragen dieser
IP auf diesem Port...

Auch ein weniger "brutales" Vorgehen, bei dem nur ganz "gemächlich" und ohne dabei die Serverlast hochtreiben zu
wollen, versucht wird, ein Passwort zu knacken, wird extrem in die Länge gezogen und damit zumindest massiv
behindert. Zwischenzeitlich sollte dieser Angriff in den Logfiles deutlich auffallen...

Vielleicht kannst Du nun verstehen, warum Brute-Force-Attacken am besten schon vom System abgefangen werden
müssen und dies eigentlich nichts mehr mit der jeweiligen Serversoftware zu tun hat.

mfg.
  VolGas

Meine Güte, Dein Deutsch ist grauenhaft - man muß sich ja schon anstrengen, zu verstehen was Du
eigentlich schreiben willst. Und alleine mit der Aussage "Und dann lief der Server aufeinmal ned mehr"
kann niemand etwas anfangen, da mußt Du schon konkreter werden.

Die Maschine mehrfach neu starten mag bei einem µ$-Beschäftigungssystem funktionieren, bei Linux ist das
i.d.R. aber völlig sinn- und nutzlos. Überprüfe, ob die Zugriffsrechte für das Verzeichnis, in dem der User
landen würde, auch passend sind - der User muß zumindest das Verzeichnis lesen dürfen (r-x).

Wenn das gewährleistet ist und es immer noch nicht geht: poste hier eine Debug-Ausgabe (ProFTPD stoppen
und mit Parameter -nd5 neu starten, siehe auch FAQ) ab dem Zeitpunkt eines Loginversuchs.
Die Ausgaben von zuvor verwerfen.

Aber zuerst ändere Deine proftpd.conf wie schon in diesem Thread besprochen und versuche es noch einmal.

mfg.
  VolGas

Hi!

Lasse mit "SQLLogFile ..." alle SQL-Befehle und -Ausgaben mitloggen und
sieh' dort nach einem Loginversuch nach, welche Meldungen im Logfile stehen.
Damit kommst Du allen SQL-Fehlern auf die Schliche.

Wenn das nicht die Lösung bringt, poste hier Deine proftpd.conf und eine Debug-Ausgabe
(ProFTPD stoppen und mit Parameter -nd5 neu starten, siehe auch FAQ) ab dem Zeitpunkt
eines Loginversuchs (die Ausgaben von zuvor verwerfen).

Dann sehen wir weiter.

mfg.
  VolGas

Hallo!

Na das ist wirklich einfach, Du hättest nur auf dieser Website die Auflistung der Direktiven ansehen müssen.
Die Direktive ->Port ist das, was Du gesucht hast.

Aber wenn auf einem anderen PC ein FTP-Server läuft, wie kann dann Konflikt bei den Ports auftreten - es
sind doch unterschiedliche Maschinen mit unterschiedlicher IP? Auf ein und dem selben Server könntest Du
mit dem ProFTPD über die Definition von virtual Hosts mehrere Server gleichzeitig laufen lassen...

mfg.
  VolGas

Gern geschehen.

Den ProFTPD mußt Du aus dem (x)inetd herausnehmen und diesen dann neu starten.
Dein Server soll im standalone-Modus laufen.

Da habe ich nicht ganz aufgepasst: "/etc/ftpusers" ist mir bekannt und es steht ja auch in der ersten Zeile drin,
wozu das gut ist. Der ProFTPD kann dieses File selbst auswerten -wenn erwünscht- und braucht dazu kein PAM.
Für den ProFTPD braucht man PAM überhaupt nicht, das ist nur unnötiger Overhead.

Laß den User "nobody" ruhig mal in der proftpd.conf stehen: das ist der User, unter dessen Zugriffsrechte der
ProFTPD laufen soll, wenn er nicht kurzfristig(st) als "root" einen neuen Prozess von sich "forkt".

Noch ´n Textbaustein, zum Verständnis:
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. [ENDE]

Die "proftpd.conf Standard Deluxe" funktioniert schon ganz gut, muß aber immer geringfügig angepasst werden.
Allerdings ist "mod_auth-file" nicht darin vorgesehen, die zwei/drei Zeilen dafür kann man ja hinzufügen.

Mit mySQL wird das Ganze natürlich super-bequem und einfach, wenn man sich z.B. noch "phpMyAdmin" installiert.
Dazu kannst Du Dir mit Debian recht einfach den mySQL-Server installieren lassen. Man kann dabei sogar die auto-
matischen Abhängigkeiten ausnutzen: "apt-get install proftpd-mysql" sollte reichen, das erzwingt alles weitere...
Nicht unbedingt optimal, aber...

Verkrafte erst mal alle Informationen oder vergiß' alles und bleibe bei dem letzten Vorschlag.
Mond und Erdstrahlen lassen wir mal weg, das Leben kann auch schon so kompliziert genug sein.

Noch viel Erfolg und Spaß bei dem Ganzen!

mfg.
  VolGas


Nachtrag: vor einem "apt-get install" vorher immer zuerst (einmal am Tag) ein "apt-get update" durchführen lassen!