Die Abschottung: Wie geht es nun weiter?

Ich hab mir das Buch wegen diesem Thread auch zugelegt und bin auch schon fast durch. Sehr zu empfehlen wenn man recht frisch an Linux rangeht.

Zu der Auflistung hätte ich eine Frage bzgl FTP.
Wir sind eine WebEntwickler Firma und stellen für eigene Projekte sowie Kunden Webseiten her. Diese werden bald auf dem Debian-Etch System gehostet, welches ich Administrieren soll. Der Zugriff beschränkt sich zu 99,9% aber nur auf uns selbst.

Ist es gefährlich einen FTPd zu benutzen, oder kann man, wenn man sich mit der Konfig auseinandersetzt, auch den FTP-Dienst ruhigen gewissens laufen lassen?

Diese doch recht harte Abschirmung oben verunsichert mich ein wenig :)

Gruß
Patrick
 
Naja, du musst dir vor Augen halten, dass FTP kein verschlüsselter Dienst ist. Man kann also den kompletten Datenverkehrt (austausch von Passwörtern, die verschickten Daten) mitlesen. Also ist es nicht unbedingt das sicherste System. Das ist ähnlich wie mit POP3 oder IMAP.

Jedoch kannst du das ganze sicherer machen, indem du einen FTP-Server aufsetzt, der mit SSL-Verschlüsselung arbeitet. Eben so geht das auch mit POP3 und auch IMAP. Sobald du mit SSL-Verschlüsselung arbeitest, kann niemand den Austausch von Daten mitlesen.

Und zu guter letzt, kommt es natürlich auf die Konfiguration des FTP-Server an. Hier sollte man auf jeden Fall anonyme Accounts verbieten, und den FTP-Server in einer CHROOT Umgebung laufen lassen. Dann hält man sich schon mal einen großen Teil des Ärgers vom Hals.

Gruß Mordor
 
Ja, gibt es. Beispielsweise mit einer Man in the Middle Attacke. Im Endeffekt kann jeder netzwerkverkehr, welcher nicht verschlüsselt ist abgehört werden, und ausgelesen werden.
 
Ich habe ja nun ein paar Monate Erfahrung auf dem Buckel und habe nichts wesentliches an meiner Konfig verändert, eher noch ausgebaut:

• Fail2Ban für die https-vHosts bzw. die htaccess Authentifizierung
• Apache: mod_evasive gegen DDoS, mod_cband als Traffic-Cop
• 24/7 Monitoring mit SMS Alerting über ein SMS Gateway via monit
• verschlüsselte Backups in 2 verschiedenen Rechenzentren
• die Log-Files werden jeden Tag zu mir nach Hause geschickt und landen damit im Intranet

Das Arbeiten über das SFTP Protokoll funktioniert blendend - man braucht also nicht zwangsläufig einen FTP Daemon. Die aktuellen FTP Klienten unterstützen ja meistens auch viele verschiedene Protokolle.

Bei meinen Maschinen 'verhindert' der Portknocker ja unkompliziertes Arbeiten: Ich hatte bei einem Projekt den Fall, dass ein Aussenstehender Daten hochladen wollte. Dem Herrn wollte ich den Portknocker nicht zumuten.

Habe das Ganze dann über WebDAV gelöst. Da es nur Bilder sind, ist die fehlende Verschlüsselung kein Nachteil und Zugriff gibt es auch nur auf ein Upload-Verzeichnis.

Nur so als Anregung jenseits von FTP-Daemons...
 
Last edited by a moderator:
Sehr Interessant. Danke für die Aufklärung.
Wobei mir dabei nicht in den Sinn will, warum Hoster nicht immer mehr auf sichere Alternativen umsteigen, was deren Entwicklung ja auch fördern würde.

Gibt es denn eine Möglichkeit das ganze abzusichern ohne auf den Komfort von schnellen und einfachen FTP-Programmen zu verzichten? Mir schwirrt da was von Port 22 statt 21 im Kopf rum, hab da mal was gelesen :confused:
 
Normalerweise ist das Verbinden mit einem FTP-Server mit SSL nicht schwieriger als mit einem ohne.

Man wählt beim Client einfach aus, dass man sich mit SSL-Unterstützung verbinden will, und verbindet sich. Dann läuft alles so weiter, wie wenn man sich mit einem FTP-Server ohne SSL verbindet. Man wird höchstens noch mal gefragt, ob man das Zertifikat akzeptiert.

Über Port 22 läuft der SSH-Server. Auch hier gibt es die Möglichkeit Daten hcohzuladen. Wobei hier der User der sich einloggt auf das System mehr zugreifen kann. Ausser man chrootet den Account.
 
Mordort said:
Wobei hier der User der sich einloggt auf das System mehr zugreifen kann. Ausser man chrootet den Account.
Click to expand...

Chrooten geht ja erst mit einem OpenSSH ab 4.9 oder so. Auf jeden Fall zu neu für 'ne Standard Debian Installation bzw. die regulären Paketquellen.

Ich habe das mit MySecureShell - Index gelöst, das chrootet den User in sein Home-Dir. Lässt sich einfach installieren und konfigurieren und läuft super.
 
Patrick Bauer said:
Mir schwirrt da was von Port 22 statt 21 im Kopf rum, hab da mal was gelesen :confused:
Click to expand...

Jup, SFTP heisst das Stichwort. Die Datentransfers laufen verschlüsselt über den sshd ab.

Ich hatte mir damals gedacht, dass man damit 2 Fliegen mit einer Klappe schlägt: Den sshd braucht man eh, also kann man die Dateitransfers auch darüber abwickeln und spart sich damit einen Angriffsvektor (ftpd). Gleichzeitig ist alles so toll verschlüsselt :D
 
Das klingt doch mal gut, ich denke in die Richtung werde ich mich weiter informieren.

Ich bin derzeit nämlich an dem Punkt angelangt einen FTP-Deamon aufzusetzen, will aber ein unnötiges Risiko vermeiden. Heute kann man ja kaum noch sicher genug sein *g*

Danke für die Aufklärung ihr Beiden

Gruss
Patrick

Edit:
Kann es sein, dass man SFTP nicht mehr verwenden kann, sobald man nur noch die Anmeldung per RSA-Key erlaubt? Also PAM abgeschaltet hat?
 
Last edited by a moderator:
Sftp fkt. mit Key-Auth, aber nur für die jeweiligen Key-Paare. Bei mir am Mac müsste ich mir für jeden Login auf dem Server ein Analogon auf dem Mac anlegen und die Schlüssel in den ./ssh Ordnern vorhalten. Das ist nicht praktikabel.

Deswegen haben meine SFTP-Logins ein hartes Passwort und keine Shell. Wenn also mal ein Account dran glauben sollte, kann man sich per Shell eh nicht einloggen.
 
Eine weitere Möglichkeit zur Absicherung des Systems stellt SELinux dar. Gibt es irgendwo bei einem Dienst eine Schwachstelle (Bug, Lücke, Fehlkonfiguration..), hat es der Angreifer mit aktiviertem und richtig konfigurierten SELinux auf dem Server schwerer, in andere Bereiche vorzudringen.

Ansonsten gibt es natürlich noch die üblichen Verdächtigen für die Beobachtung eines Servers:
* Monitoring (Nagios, Icinga, Zabbix..)
* Konfigurationsmanagement (Cfengine, Puppet, Chef...)
* Log-Überwachung (Logcheck, Logtail...)
* Tripwire :D
 
Warum nicht? Der Thread ist hier im Unterforum sticky, womit er für mich schon sowas wie "zeitlos" ist.

Und ganz ehrlich - dein Beitrag ist nicht minder schlimm :P
 
Ich kann mich noch nicht ganz entscheiden ob der Einsatz von fail2ban Sinn macht. Einerseits ist es praktisch automatisch IP Adressen sperren zu lassen, andereseits braucht das fail2ban dafür System-Ressourcen. Außerdem hat man damit einen zusätzlichen Script-Interpreter (Python) auf der Maschine.

Was chkrootkit betrifft frage ich mich ob es noch aktiv weiter entwickelt wird.

Und wie haltet ihr es mit PHP und Suhosin? Ich beziehe meine Pakete für PHP und NGINX von dotdeb.org. Suhosin wird seit PHP Version 5.4 nicht weiter unterstützt, oder habe ich da etwas verpasst?

In meinem konkreten Fall verwende ich nginx-naxsi als Webserver und php5-fpm. Naxsi hat bereits nach kurzer Zeit einen erschreckenden Request geblockt. Ich bin froh mich dafür entschieden zu haben. Dazu werden Anfragen von unerwünschten Useragents über NGINX mit einem Beenden der Verbindung (return 444) beantwortet.

Dieser Thread ist auf jeden Fall immer noch ein guter Ansatzpunkt für Anfänger. Zum größten Teil habe ich es auch genau so umgesetzt, bis auf Port Knocking, da nutze ich im Moment lieber TCP Wrapper.
 
Last edited by a moderator:
Ich kann mich noch nicht ganz entscheiden ob der Einsatz von fail2ban Sinn macht. Einerseits ist es praktisch automatisch IP Adressen sperren zu lassen, andereseits braucht das fail2ban dafür System-Ressourcen. Außerdem hat man damit einen zusätzlichen Script-Interpreter (Python) auf der Maschine.
Click to expand...

Ich kann nur aus eigener Erfahrung sprechen:
* Fail2Ban verursacht meiner Erfahrung nach kaum spürbar Last, selbst auf "hoch frequentierten Systemen", die direkt übers Internet erreichbar sind, nicht
* Python war bisher auf allen Systemen, die ich in den letzten drei Jahren angefasst habe, vorhanden (ca. 300-400 Linux-Server, darunter Ubuntu, Debian, CentOS, Red Hat)

Ich persönlich sehe das nicht so eng. War ist daran so schlimm, Python als Interpreter auf dem System zu haben? Schon konkret negative Erfahrungen gemacht?
 
Valentin said:
* Python war bisher auf allen Systemen, die ich in den letzten drei Jahren angefasst habe, vorhanden (ca. 300-400 Linux-Server, darunter Ubuntu, Debian, CentOS, Red Hat)
Click to expand...
Srsly? Auf einem Frisch installiertem minimalen Debian Wheezy vServer in einem OpenVZ-Container (Template kann ich dir gerne schicken) ist bisher Python immer nachinstalliert worden. Und das weiß ich, weil ich nicht Fail2ban verwende, sondern Node.JS sehr gerne selbst kompiliere.

Und bitte: Braucht man heutzutage auf einem sehr gut eingerichteten Server noch Fail2ban?
 
Srsly? Auf einem Frisch installiertem minimalen Debian Wheezy vServer in einem OpenVZ-Container
Click to expand...
Die Server in den mittelständischen Unternehmen, die ich (mit) betreue, bieten schon etwas mehr als ein "minimal" System. Ich bin nicht in der Hoster-Branche tätig, wovon du womöglich gerade ausgehst.

Die Systeme erledigen u.a. Groupware-, Fileserver, Clustering-, Backup-, Virtualisierungs-, Monitoring- und Directory-Aufgaben. Einige von denen sind tatsächlich von außen via SSH erreichbar - und wenn da (aus welchen Gründen auch immer) der Standardport für SSH und Passwort-Auth genutzt werden _muss_, hat Fail2Ban sicherlich seine Daseinsberechtigung.

Manchmal musst du damit leben, dass irgendwer seinen Server mit SSH-Port 22 und Passwort-Auth. betreibt ;)
 
You must log in or register to reply here.
Back
Top