proftpd auf Subnet beschränken

[mgolbs]

Hallo,

ich möchte für Entwicklungszwecke meinen lokalen proftpd-Server auf ein Subnet am Rechner beschränken, er soll z.B. nur im Bereich 10.2.178.xxx erreichbar sein und auf der "Standardnetzwerkschnittstelle nicht. Geht soetwas mit vertretbarem Aufwand?

Gruß und Dank Markus

[DeletedUserReAsG]

Es gibt ’ne Art „AllowFrom“ – einfach mal in der Doku schauen.

[heisenberg]

Den TCP-Wrapper tcpd(Siehe [1]) kannst Du auch dafür verwenden. Dazu muss ProFTPD aber über inet bzw. xinetd gestartet werden(Siehe [1]/[2])

Links
[1] Grundlagen Sicherheit: TCP-Wrapper
[2] Ubuntu-Wiki: ProFTPD

P. S.: Aufgrund des wesentlich besseren Sicherheitshistorie empfehle ich mal vsftpd statt proftpd, falls da keine speziellen Features von ProFTD benötigt werden:

Sicherheitslücken: ProFTPD
Sicherheitslücken: vsftpd

[DeletedUserReAsG]

http://proftpd.org/docs/directives/link ... Allow.html um das zugreifende Subnetz einzugrenzen, http://proftpd.org/docs/directives/link ... dress.html um die benutzte IP und damit das Subnetz festzulegen.

… ich würde nicht noch Drittkram á la tcpwrapper ins Spiel bringen, wenn die Software die Funktion von sich aus mitbringt. Und über (x)inetd würde ich heutzutage sowieso nix mehr starten.

[heisenberg]

Und über (x)inetd würde ich heutzutage sowieso nix mehr starten

Warum?

[DeletedUserReAsG]

Weil systemd die Funktionalität übernimmt, wenn ich’s wirklich on demand gestartet haben will. Einen ftpd würde ich sowieso standalone laufen lassen – KISS, jede Zwischenschicht birgt Raum für Fehler.

[heisenberg]

Ich habe gerade etwas recherchiert und bin noch nicht fündig geworden, was eine tcpd-Alternative in systemd sein könnte.

Habe nur ein Thread gefunden, wo es darum geht, tcpwrap mit minimaler Ankündigungszeit zu entsorgen.

Davon abgesehen setze ich bei all meinen systemen xinetd ein. systemd ist noch längst nicht auf all meinen Plattformen verfügbar. Nachinstallation: Vergiß es! xinetd ist überall verfügbar.

Was den Thread hier betrifft: Nein, (x)inetd ist nicht das, was der TE hier wohl will. Ich habe den hier nur eingeworfen, da es wohl die einzige Möglichkeit ist, proftpd mit tcpd zu verwenden, da proftpd das nicht von sich selbst aus unterstützt, wie z. B. sshd.

[DeletedUserReAsG]

Was unterstützt es nicht? Die Anforderung des Threadstarters lässt sich bei beiden Arten, sie zu interpretieren, mit Bordmitteln realisieren. Wie das Dingens bei systemd heißt, weiß ich gerade nicht mehr – ich weiß nur, dass es z.B. meinen dovecot handhabt – an dem betreffenden Port lauscht ein Prozess namens init, der dann bei Bedarf die Verbindung weiterreicht. Funktionierte so ootb, sah ich noch keinen Grund, mich näher damit zu beschäftigen.

[heisenberg]

Das was Du meinst ist das, was bei systemd socket-based-activation heisst, also die klassische inetd Aufgabe für Dienste die nur selten benötigt werden.

Das was ich meine ist tcpd, der TCP-Wrapper. Siehe Link oben. Das macht das gleiche wie dass hier:

http://proftpd.org/docs/directives/link ... Allow.html um das zugreifende Subnetz einzugrenzen, http://proftpd.org/docs/directives/link ... dress.html um die benutzte IP und damit das Subnetz festzulegen.

...mit dem Vorteil, dass tcpd der Software(ftpd) vorgeschaltet ist. tcpd funktioniert auch anwendungsunabhängig. D. h. ein potentieller Angreifer kommt nur bis zum tcpd und nicht bis zur FTP-Software selbst. Da tcpd ein relativ kleines Stück Software ist ist die Angriffsfläche eher gering.

[DeletedUserReAsG]

D. h. ein potentieller Angreifer kommt nur bis zum tcpd und nicht bis zur FTP-Software selbst

Dieses verstehe ich nicht. Angenommen, der ftpd wäre durch ein entsprechend präpariertes Paket angreifbar (so schlecht ist die Sicherheitshistorie beim proftpd übrigens auch nicht, btw.), würde das einen Unterschied machen, ob er es direkt bekommt, oder vom tcpd? Und wie läuft das mit dem Datenkanal (also die zweite Verbindung über unprivilegierte Ports), wird der auch über den tcpd aufgebaut, oder ist‘s dann doch wieder direkt?

[heisenberg]

Dieses verstehe ich nicht. Angenommen, der ftpd wäre durch ein entsprechend präpariertes Paket angreifbar, würde das einen Unterschied machen, ob er es direkt bekommt, oder vom tcpd?

Wenn der Angreifer per Quell-IP geblockt ist dann bekommt es der ftpd gar nicht(Quasi so ähnlich wie iptables).

Und wie läuft das mit dem Datenkanal (also die zweite Verbindung über unprivilegierte Ports), wird der auch über den tcpd aufgebaut, oder ist‘s dann doch wieder direkt?

Wenn er eine Datenverbindung aufmacht, dann muss er bereits über Port 21 Kontakt aufgenommen haben, da darüber immer die Verbindungsaufnahme stattfindet. Er muss also per tcpd berechtigt sein um dort überhaupt hinzukommen.

[DeletedUserReAsG]

Na gut, dann sehe ich den Sinn dieses tcpd nicht so wirklich – ich würde dann schlicht zu iptables greifen. Da habe ich die Syntax im Kopf, außerdem ist sowas einer der Haupteinsatzzwecke davon.

[heisenberg]

tcpd ist halt so'n Urgestein, dass es schon recht lange gibt.

Es gibt da auch kein richtig und falsch. Es ist auch immer eine Frage der Sicherheitsstrategie die man wählt und des Sicherheitsanspruches, den man fordert. Ein Gedanke könnte da sein:

Wenn man zwei Sicherheitsmassnahmen umsetzt, dann ist die Wahrscheinlichkeit, dass beide gleichzeitig ein schwerwiegendes Sicherheitsproblem haben doch wesentlich geringer, als wenn es nur eine Sperre eingebaut ist, die ein Sicherheitsproblem bekommen könnte.

[DeletedUserReAsG]

Ich halt’s da lieber so schlank wie möglich: Je mehr Software im Spiel, desto höheres Fehlerpotential insgesamt. Aber kann ja jeder machen, wie er mag – ist auch irgendwie OT. Es sind ja nun drei Möglichkeiten genannt worden (via proftpd-Konfiguration selbst, via tcpd und via iptables) – da kann sich Markus ja nun die für ihn passende Lösung raussuchen.