www.ProFTPD.de
13. März 2007, 18:22:00 *
Willkommen Gast. Bitte einloggen oder registrieren.
Haben Sie Ihre Aktivierungs E-Mail übersehen?

Einloggen mit Benutzername, Passwort und Sitzungslänge
News: SMF - Neu installiert!
 
   Übersicht   Hilfe Suche Login Registrieren  
Seiten: 1 2 [3] 4 5 ... 10
 21 
 am: 09. März 2007, 21:08:52 
Begonnen von Illidan - Letzter Beitrag von VolGas
Jep, vieel besser! Zwinkernd

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

 22 
 am: 09. März 2007, 19:18:24 
Begonnen von Illidan - Letzter Beitrag von Illidan
Zitat
Am liebsten hätte ich alleine schon wegen Deiner elendigen und zusammenhangslosen Schreibe ohne Punkt
und Komma diesen Thread ignoriert.
Danke das du es trotzdem machst Zwinkernd.

Also, ich hab es jetzt geschafft ProFTPD 1.3.0a zu installieren. Ich habe für das kompilieren ausgeführt:
Zitat
./configure \
       ./configure \
        --with-modules=mod_sql:mod_sql_mysql \
        --with-includes=/usr/include/mysql \
        --with-libraries=/usr/lib \
\
--prefix=/usr/local/proftpd \
--sysconfdir=/etc --localstatedir=/var/run --mandir=/usr/local/man

make
make install

/usr/include/mysql und /usr/lib sind die richtigen Verzeichnisse, nur mal so nebenbei.

Es hat auch mit der Installation alles geklappt.

Naja, ich habe nun in die /etc/proftpd.conf die SQL Abfragen reingeschrieben. Wenn das aber drin steht verbindet er nicht.

Hab hier den proftpd-sql.log

Zitat
Mar 09 20:08:23 mod_sql/4.2.1[2414]: defaulting to 'mysql' backend
Mar 09 20:08:23 mod_sql/4.2.1[2414]: backend module 'mod_sql_mysql/4.05'
Mar 09 20:08:23 mod_sql/4.2.1[2414]: backend api    'mod_sql_api_v2'
Mar 09 20:08:23 mod_sql/4.2.1[2414]: >>> sql_sess_init
Mar 09 20:08:23 mod_sql/4.2.1[2414]: entering   mysql cmd_defineconnection
Mar 09 20:08:23 mod_sql/4.2.1[2414]:  name: 'default'
Mar 09 20:08:23 mod_sql/4.2.1[2414]:  user: 'syscp'
Mar 09 20:08:23 mod_sql/4.2.1[2414]:  host: 'localhost'
Mar 09 20:08:23 mod_sql/4.2.1[2414]:    db: 'syscp'
Mar 09 20:08:23 mod_sql/4.2.1[2414]:  port: '3306'
Mar 09 20:08:23 mod_sql/4.2.1[2414]:   ttl: '0'
Mar 09 20:08:23 mod_sql/4.2.1[2414]: exiting    mysql cmd_defineconnection
Mar 09 20:08:23 mod_sql/4.2.1[2414]: entering   mysql cmd_open
Mar 09 20:08:23 mod_sql/4.2.1[2414]: exiting    mysql cmd_open
Mar 09 20:08:23 mod_sql/4.2.1[2414]: unrecoverable backend error
Mar 09 20:08:23 mod_sql/4.2.1[2414]: error: '1251'
Mar 09 20:08:23 mod_sql/4.2.1[2414]: message: 'Client does not support authentication protocol requested by server; consider upgrading MySQL client'

und die proftpd.conf

Zitat
# This is a basic ProFTPD configuration file (rename it to
# 'proftpd.conf' for actual use.  It establishes a single server
# and a single anonymous login.  It assumes that you have a user/group
# "nobody" and "ftp" for normal operation and anon.

ServerName                      "illidan.dyndns.org Server"
ServerType                      standalone
DefaultServer                   on

# Port 21 is the standard FTP port.
Port                            21

# Umask 022 is a good standard umask to prevent new dirs and files
# from being group and world writable.
Umask                           022

# To prevent DoS attacks, set the maximum number of child processes
# to 30.  If you need to allow more than 30 concurrent connections
# at once, simply increase this value.  Note that this ONLY works
# in standalone mode, in inetd mode you should use an inetd server
# that allows you to limit maximum number of processes per service
# (such as xinetd).
MaxInstances                    30

# Set the user and group under which the server will run.
User                            nobody
Group                           nogroup

# To cause every FTP user to be "jailed" (chrooted) into their home
# directory, uncomment this line.
#DefaultRoot ~

# Normally, we want files to be overwriteable.
AllowOverwrite          on

# Bar use of SITE CHMOD by default
<Limit SITE_CHMOD>
  DenyAll
</Limit>

# A basic anonymous configuration, no upload directories.  If you do not
# want anonymous users, simply delete this entire <Anonymous> section.
<Anonymous ~ftp>
  User                          ftp
  Group                         ftp

  # We want clients to be able to login with "anonymous" as well as "ftp"
  UserAlias                     anonymous ftp

  # Limit the maximum number of anonymous logins
  MaxClients                    10

  # We want 'welcome.msg' displayed at login, and '.message' displayed
  # in each newly chdired directory.
  DisplayLogin                  welcome.msg
  DisplayFirstChdir             .message

  # Limit WRITE everywhere in the anonymous chroot
  <Limit WRITE>
    DenyAll
  </Limit>
</Anonymous>

DefaultRoot ~
RequireValidShell off
AuthOrder               mod_sql.c

SQLAuthTypes Crypt Plaintext
SQLAuthenticate users* groups*
SQLConnectInfo syscp@localhost syscp passwort
SQLUserInfo ftp_users username password uid gid homedir shell
SQLGroupInfo ftp_groups groupname gid members
SQLUserWhereClause "login_enabled = 'y'"

SQLLog PASS login
SQLNamedQuery login UPDATE "last_login=now(), login_count=login_count+1 WHERE username='%u'" ftp_users

SQLLog RETR download
SQLNamedQuery download UPDATE "down_count=down_count+1, down_bytes=down_bytes+%b WHERE username='%u'" ftp_users

SQLLog STOR upload
SQLNamedQuery upload UPDATE "up_count=up_count+1, up_bytes=up_bytes+%b WHERE username='%u'" ftp_users

SQLLogFile /var/log/proftpd-sql.log



Ich habe MySQL so installiert:

apt-get install mysql-server mysql-client php5-mysql

Somit sollte, stand zumindenst auf den Seiten mit dem Befehl, MySQL 5 installiert werden.

Ich frag mich jetzt woran es liegt das

Zitat
Mar 09 20:08:23 mod_sql/4.2.1[2414]: error: '1251'
Mar 09 20:08:23 mod_sql/4.2.1[2414]: message: 'Client does not support authentication protocol requested by server; consider upgrading MySQL client'

diese Fehlermeldung wieder kommt. Genau wegen diesem Problem hab ich proftpd nicht per apt-get installiert.

Und nun hab ich das selbe Problem wieder ... .

Ich werd da einfach nicht schlau.

Ich hoffe diesmal, kann man mein Text lesen.

MFG
Illidan


Beitrag auf Wunsch geändert - VolGas

 23 
 am: 09. März 2007, 10:39:42 
Begonnen von spacewolve - Letzter Beitrag von spacewolve
ich verstehe ja wenn du mein vorwissen ungenügend findest - finde ich ja auch-
 nur werde ich bei meinem praktikum nunmal ins kalte wasser geworfen... kann ich auch nichts für  Weinen
war bisher nur windoof nutzer -.-

danke dennoch für die hilfe

 24 
 am: 09. März 2007, 09:23:43 
Begonnen von Illidan - Letzter Beitrag von 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

 25 
 am: 09. März 2007, 08:32:15 
Begonnen von borderlinedancer - Letzter Beitrag von 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

 26 
 am: 09. März 2007, 05:40:22 
Begonnen von borderlinedancer - Letzter Beitrag von borderlinedancer
Wie gesagt ich kann mir nicht vorstellen das ich -um "brut-force-attacken" zu vermeiden- an der Firewall rumschrauben soll, da ja das grösste Problem die Loginversuche sind.
Also hab ich mal meine Conf etwas modifiziert. Die Globalen Einstellunge sehen jezt so aus:
Code:
<Global>
DefaultTransferMode binary
RootLogin off
# Login
TimeoutLogin 60
MaxLoginAttempts 5
MaxClientsPerHost 3
</Global>
Was mich im Moment aber noch etwas stört ist, das sich nach 5 falschen login versuchen, die Zeit der Sperre (falls sie so überhaupt funktioniern sollte) nicht steuern lässt.

Habt ihr da irgend etwas das mir helfen könnte?

 27 
 am: 08. März 2007, 23:23:08 
Begonnen von Manne - Letzter Beitrag von Manne
Sorry ich gebe mir mal beim Nähsten mal mehr mühe mit meinem Deutsch.

Ich habe das ganze jetzt hinbekommen, habe nämlich die FAQ nochmal genau durchgelesen und proftpd so gestartet wie du es gesagt hast. Da habe ich festgestellt das irgendein anderer Prozess auf dem Port 21 lauschte, den hab ich dann wie dort angegeben gekickt und proftpd gestartet und es lief sofort alles wie es sollte.

Der Rest sollte nun kein Problem mehr darstellen, ich werde mich dann noch demnähst ans TLS probieren aber da kann man ja nicht viel falsch machen. ^^ Scheint mir so.


 28 
 am: 08. März 2007, 21:28:56 
Begonnen von Illidan - Letzter Beitrag von Illidan
Also ich hab es jetzt hingekriegt mit der installation nur hab ich bei ./configure \ noch prefix=/etc hin gemacht und ich glaub das war ein fehler.

ich kann jetzt auf den server connecten, die proftpd.conf liegt in /etc/etc/proftpd.conf

dann hab ich da noch etwas bei der installation gesehen mit /etc/sbin/proftpd

und noch /etc/sbin/in.proftpd


Nunja das Problem ist ich will den Server neustarten also proftpd aber ich weiß nicht wie ich das machen soll da es ja net automatisch in /etc/init.d/ ist(hab das script benutzt was es da unter tools gab aber geht auch net es kommt auch keine fehlermeldung wenn ich das ausführe, glaub aber es liegt daran das keine proftpd.pid datei gibt).

Hab auch das

UseReverseDNS off

IdentLookups off

reingeschrieben in die conf und dann mit /etc/init.d/proftpd restart neugestartet aber das login ist genau so langsam wie vorher und ich glaub das zeigt nun auch das der server _nicht_ neugestartet wurde.

Hoffe mir kann da jemand weiter helfen, wenn es geht kann ich auhc proftpd löschen und neu installiern und prefix weglassen (wüsste dann nur mit welchem befehl ich das lösche Zwinkernd )

 29 
 am: 08. März 2007, 21:22:22 
Begonnen von Manne - Letzter Beitrag von 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

 30 
 am: 08. März 2007, 21:02:28 
Begonnen von Illidan - Letzter Beitrag von 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

Seiten: 1 2 [3] 4 5 ... 10
Powered by MySQL Powered by PHP Powered by SMF 1.1.2 | SMF © 2006-2007, Simple Machines LLC Prüfe XHTML 1.0 Prüfe CSS
Seite erstellt in 0.067 Sekunden mit 12 Zugriffen.