proftpd mysql sicher?

[lon]

Hallo.

Ist das authentifizieren von proftpd mit einer SQL Datenbank gegen SQL Injection sicher?

Werden die übertragenen Benutzernamen escaped, damit ein Angriff nicht möglich ist?

Selbiges gilt auch für andere Serverkomponenten die mit SQL arbeiten.

 

[Deleted member 14254]

Wie es bei ProFTPd aussieht, weiß ich nicht. Doch prinzipiell ist eine Injection beim Webserver schonmal weitestgehend ausgeschlossen, wenn Suchmaschinenfreundliche URL eingeschaltet sind, da hierbei URL´s generiert werden, bei dem die ID´s des Items in der Datenbank nicht mehr offensichtlich ist, somit keine Befehle untergeschoben werden können...

Auch interessant:

http://de.wikipedia.org/wiki/SQL-Injection

Der simplere und sicherere Weg ist jedoch, die Daten überhaupt vom SQL-Interpreter fernzuhalten. Dabei kann man auf das Kappen der Eingabe verzichten. Die Technik dazu sind gebundene Parameter in Prepared Statements. Dabei werden die Daten als Parameter an einen bereits kompilierten Befehl übergeben. Die Daten werden somit nicht interpretiert und eine SQL-Injection verhindert. Als positiven Nebeneffekt bekommt man bei bestimmten Datenbanken (z. B. Oracle) außerdem eine Steigerung der Performance. Stored Procedures bieten dagegen keinen generellen Schutz vor SQL-Injection, insbesondere dann nicht, wenn der SQL-Code der Funktion nicht bekannt ist.

 

[remote_mind]

Siehe dazu auch das (durchaus unterhaltsame)

http://bobby-tables.com/

Mit kurzen Code-Beispielen zu vielen Programmiersprachen. Dabei wird konsequent mit prepared statements gearbeitet, welches einem Escapen vorzuziehen ist.

Best-practice ist natürlich auch, dem ProFTPd nur die minimal nötigen Rechte auf dem MySQL einzuräumen.

beste Grüße,
Nils

 

[remote_mind]

Moin nochmal,

weil es mich jetzt selber interessiert hat habe ich das mal nachgesehen (use the force grep the source, luke).

Ich habe hier den Quelltext von proftpd-dfsg-1.3.4a (aus Ubuntu 12.04).

Leider verwendet proftpd keine prepared statements, die Inputs werden per mysql_real_escape_string() aus der C-API von MySQL escaped.

Wenigestens ist es keine eigene Implementierung sondern basiert auf der MySQL-API, damit vermeidet man zumindest die gröbsten Schnitzer

Ach ja, bin ja kein Programmierer, kann man sowas eigentlich in C wirklich nur mit #ifdef/#endif durchtränkt programmieren? Da rollen einem sich ja die Zehennägel hoch

schöne Grüße,
Nils

 

[Joe User]

Ach ja, bin ja kein Programmierer, kann man sowas eigentlich in C wirklich nur mit #ifdef/#endif durchtränkt programmieren? Da rollen einem sich ja die Zehennägel hoch

Man kann auch mit wenigen bis gar keinen auskommen, bläht aber den Source durch doppelt und x-fach vorhandenen Code unnötig auf.
Ist wie mit if/else/endif oder switch/case in PHP, es geht ohne, man will es aber nicht

 

[lon]

Danke für eure Antworten und besonderen Dank an remote_mind für die Analyse des Quellcodes.

Natürlich bekommt jede Anwendung ihre eigenen Rechte die nicht über die Notwendigkeit herausragen. Ich habe mich dies nur gefragt, da ich gelesen habe, dass proftpd schonmal so einen Bug hatte.

 

[Deleted member 14254]

ProFTPd einzusetzen war auch mal soeine Idee von mir für den Server. Lokal hatte ich ihn hier mal für unser Homenetzwerk laufen. Doch dabei gibts ja, selbst wenn ProFTPd einen dicken Bug aufweist, nicht die große Gefahr, da alles nur lokal abgeht (und vom Router geschützt). Da mir persönlich aber innerhalb von nur 1 Jahr 2mal schon gravierende Sicherheitslücken zu Augen kamen, habe ich auf das Einsetzen auf dem Server bisher verzichtet und mir lieber 2, per .htaccess passwortgeschützte VirtualHosts in Apache eingerichtet, die garkeine SQL-Anbindung haben. Praktisch wie die dl.domain.tld verschiedener Softwarehäuser, die geschützten Download von ihren Updateservern anbieten.

-> Kein User-Account, Kein SQL.

Mal sehen, ob ich ProFTPd (gefiel mir persönlich ganz gut) vielleicht irgendwann noch konfigurieren/zur verfügung stellen werde. Erstmal aber noch nicht. Wenn ich keinen zusätzlichen Port ins Inet aufzumachen gezwungen bin, bin ich darum sehr dankbar

 

[svenr]

Ich mag nur mal den vsftpd in den Raum werfen. Warum nehmt ihr den nicht. Der ist schlank, kann alles was man idr so braucht.

Gruß Sven

 

[Deleted member 14254]

Hallo Sven,

Der vsftp, von dem Du sprichst, kann man diesen auch per MySQL authen? Vielleicht eine blöde Frage, da ich bisher nur den proftpd als DB-Auth gesehen habe. Ist immer so "die Qual der Wahl" - Entweder Systembenutzer anlegen, oder gegen DB authen... Mag mich nie richtig für etwas entscheiden...

 

[svenr]

Servus,

ja das authen via mysql kann er auch der vsftpd.
Wenn Du dich nicht entscheiden magst spare ich mir es mal lieber dir noch ne Latte an ftp Servern um die Ohren zu hauen die auch alle per mysql authen können.
Doch vsftpd ist meiner Ansicht nach eine gute Wahl.
Nicht zu überladen, wenig Ärger mit *bugs*, saubere Configs.
Bissl einlesen und der rennt wie Sahne

Gruß Sven

 

[Deleted member 14254]

vsftpd == verysecure ftpd... Das stimmt schon. Auf ProFTPd kam ich damals beim Lernen am Home-Linux-Rechner, da ich zu proftpd mehr HowTo´s finden konnte. Daher kannte ich den vsftpd auch "nur" als gegen System-User authenden. Ok... wie schon erwähnt, blöde Frage gewesen.

Als ich mit den Servern anfing gab mir jemand den guten Rat "Jeder weitere offene Port kann eine Faust mehr bedeuten, die "Dir" entgegenschnellt..."

Das hab ich wohl nicht vergessen

Trotzdem: vsftpd werd ich mir in Ruhe mal anschauen, die HowTo´s durchlesen und mir paar Gedanken machen... Mit den vhosts läuft bis jetzt aber ganz passabel.

 

[danton]

Doch prinzipiell ist eine Injection beim Webserver schonmal weitestgehend ausgeschlossen, wenn Suchmaschinenfreundliche URL eingeschaltet sind, da hierbei URL´s generiert werden, bei dem die ID´s des Items in der Datenbank nicht mehr offensichtlich ist, somit keine Befehle untergeschoben werden können...

Da muß ich noch mal eingreifen, denn das stimmt so nicht. Auch wenn man suchmaschinenfreundliche URLs einschaltet, funktionieren der Aufruf der PHP-Datei mit Parametern weiterhin. Das Problem sind i.d.R. ja nicht die URLs, die vom CMS generiert werden. Vielmehr geht ein Hacker ja hin und probiert den Aufruf mit seinen manipulierten Parametern.
Und wenn eine Lücke bekannt ist, werden oft Scripte auf die Server losgelassen, die automatisiert testen, ob ein verwundbares Script vorhanden ist - die interessieren die suchmaschinenfreundlichen URLs nicht.
Bestes Beispiel ist das PHPMyAdmin: Schau mal in die Logs von deinem Webserver, da werden früher oder später Zugriffe auf PHPMyAdmin-Verzeichnisse auftauchen, selbst wenn diese nie installiert war.

 

[d4f]

Proftpd und Apache2 haben eins gemeinsam:
es sind beide sehr mächtige (und von den meisten Leute auf ihre simpelsten Funktionen abgestumpfte) Pakete welche durch die Modularität und eingebaute Funktionen weit über den Alternativen stehen.
Natürlich kostet dies aber wieder Rechenleistung und gleichzeitig durch die Codezeilen-Zahl und Grösse potentielle Sicherheitslöcher.

Da mir persönlich aber innerhalb von nur 1 Jahr 2mal schon gravierende Sicherheitslücken zu Augen kamen, habe ich auf das Einsetzen auf dem Server bisher verzichtet und mir lieber 2, per .htaccess passwortgeschützte VirtualHosts in Apache eingerichtet, die garkeine SQL-Anbindung haben.

Was genau hat Proftpd mit Apache vHosts und SQL-Anbindung von darauf laufenden Skripten zu tun?

 

[tomasini]

Wozu brauche ich auf einem Server überhaupt FTP, wenn ich dort bereits SSH mit eingebauten SFTP laufen habe?

*Hint*: http://winscp.net

 

[TerraX]

Wozu brauche ich auf einem Server überhaupt FTP, wenn ich dort bereits SSH mit eingebauten SFTP laufen habe?...

Weil man evtl. nicht unbedingt System-User herausgeben will, für reine Upload-/Downloadgeschichten. AFAIK bedingt SSH Systemuser.

 

[Deleted member 14254]

Da muß ich noch mal eingreifen, denn das stimmt so nicht. Auch wenn man suchmaschinenfreundliche URLs einschaltet, funktionieren der Aufruf der PHP-Datei mit Parametern weiterhin...

Das hatte ich aus einer Contao-How-To, die besagt, das die Gefahr von SQL-Injections bei Verwendung von "Suchmaschinenfreundlichen-URL's" drastisch gesenkt würde...
Wenn dem nicht so ist, dann bin ich Dir echt dankbar, das Du mich aufgeklärt hast jetzt, danton! Ich dachte, SQL-Injections können lediglich dann Erfolg haben, wenn in der AdressZeile des Browsers Informationen über ID's und wie wo was in der DB benannt ist, zu sehen sei.

Weil man evtl. nicht unbedingt System-User herausgeben will, für reine Upload-/Downloadgeschichten. AFAIK bedingt SSH Systemuser.

Was wieder deutlich für die DB-Auth-Methode spricht In Bezug Systemuser bekannt zu geben, sehe ich mich auch als ziemlich empfindlich an...

Was genau hat Proftpd mit Apache vHosts und SQL-Anbindung von darauf laufenden Skripten zu tun?

Die Alternative zu einem FTP. Einen FTP-User müsste ich entweder gegen DB authen, oder einen System-user für FTP verwenden. Bei Apache kann ich einen Vhost einrichten, ihn zugangseinschränken und verhindere so:

• Notwendigkeit DB-Auth
  Notwendigkeit zusätzlicher offener Ports (Apache ist mit Port 80/443 immer offen)
  Zusätzlicher System-user fällt weg, wenn ich nicht gegen DB authen mag...

Das Apache angreifbar ist, streite ich nicht ab. Das Hauptaugenmerk liegt bei mir darin, das ich nicht gerne zusätzliche Ports öffnen möchte.

Bin für Kritik offen!

 

[d4f]

Die Alternative zu einem FTP.

Schön und gut, aber wie genau willst du per Apache Dateien hoch- und runterladen? Über Webdav etwa? *eek*

MIndestens SSH hast du noch immer (hoffentlich...), also wäre das bereits genannte SFTP sehr nützlich. Authentifizieren musst ud aber trozdem, könntest du aber in quick&dirty gegen einen gleichen User unter dem du Apache auch laufen lässt.

 

[tomasini]

Weil man evtl. nicht unbedingt System-User herausgeben will, für reine Upload-/Downloadgeschichten. AFAIK bedingt SSH Systemuser.

Wo liegt denn jetzt genau das Problem bei einem minderpriviligierten System-User? Und Chroot gäbe es dann ja auch noch.

Aber gut, mit dem hier beschriebenen "Rumgefrickel" geht's natürlich auch. Habe ich das jetzt richtig verstanden? Weil FTP einem zu unsicher ist, baut man sich lieber einen vermeintlich sichereren "FTP-Ersatz" aus Apache, MySQL und WebDAV?

Ok, das mit dem Fachkräftemangel habe ich bisher wohl stark unterschätzt.

 

[Deleted member 14254]

Bei der Apache ala FTP-Lösung, wenn man das so nennen darf geht es ohnehin nur um den Download. Es wird hinter einer Passwortgeschützten Seite eine Download-Section geben, wo man dann an Freeware-Tools und dgl. kommen kann. Das heißt nicht, das sie schon steht, beladen ist und auf User wartet! Das ist nur eine Vorüberlegung, da ich über einen Download-Host evtl. Treiber usw. und kleine "Helferlein in der Not" anbieten möchte.

Versteht sich natürlich erst mit den Firmen die Lizenzfragen abzuklären

Die Upload-Geschichte, die Natürlich per Apache nicht geht:

Uploaden tu ich die Dinge, die auf den Server müssen generell per 'scp'. Ich mache mir einen Ordner, der alles enthält, was ich auf dem Server brauche, habe dort einen entsprechend wie auf meinem lokalen System benannten Ordner angelegt, und dort wird erstmal alles "Vorbereitet", BEVOR es auf die Reise zum Server geht. Dann per scp hoch und von dort aus werden dann die Daten normal per "cp -$Parameter" dorthin verschoben, wo es gebraucht wird.

Weil FTP einem zu unsicher ist, baut man sich lieber einen vermeintlich sichereren "FTP-Ersatz" aus Apache, MySQL und WebDAV?

Ohne MySQL/WebDAV. Dann könnte ich ja gleich, wie auch vom TE gefragt, einen $FTPd nehmen, der dann über den DB-Server authentifiziert, bzw. wäre schon drauf gekommen, das das 'Rumgestricke' auf das selbe hinausläuft

 

[d4f]

Bei der Apache ala FTP-Lösung, wenn man das so nennen darf geht es ohnehin nur um den Download. Es wird hinter einer Passwortgeschützten Seite eine Download-Section geben, wo man dann an Freeware-Tools und dgl. kommen kann.

In die Download-Richtung für einzelne Dateien ist HTTP doch eh das Mittel der Wahl da bedeutend mehr Firewalls, Clients und -am wichtigsten- Besucher damit klar kommen.
Nur wenn man Ordner oder ganze Dateisammlungen runterladen will muss man auf FTP ausweichen.

Dann per scp hoch und von dort aus werden dann die Daten normal per "cp -$Parameter" dorthin verschoben, wo es gebraucht wird.

Entsprechende Tools wie rsync würden dir das leben erleichtern. Da es über SSH läuft würde es deine Port-Paranoia nicht stören

Versteht sich natürlich erst mit den Firmen die Lizenzfragen abzuklären

Viel Spass und Glück. Übrigens haben viele Hersteller bereits in der EULA der Weiterverteilung zugestimmt.