Hallo Liste! Da ich einen neuen Server unter Suse Linux 9 unter die "Fitiche" bekomme wollte ich mal so in die Runde fragen wie ihr eure Server absichert. Der Server steht bei einem Hoster d.h. ich habe keinen direkten Zugang zur Hardware. Eine externe Firewall soll vorgeschalten werden, ist derzeit aber noch nicht vorhanden. Hauptaufgaben sind Web/Mail/FTP. Ein Confixx 3.0 ist ebenfalls installiert. Wie würdet ihr vorgehen? Auf viele spannende Anworten gespannt, mfg. Mike -- Michael Hirst - mike@agildev.com agildev - Softwareentwicklung - Projektentwicklung - Projektmanagement http://www.agildev.com Rosentalgasse 10/5 1140 Wien Tel.: +43/1/9909182
Zitat von "M. Hirst" <suse@agildev.com>:
Da ich einen neuen Server unter Suse Linux 9 unter die "Fitiche" bekomme wollte ich mal so in die Runde fragen wie ihr eure Server absichert.
Der Server steht bei einem Hoster d.h. ich habe keinen direkten Zugang zur Hardware. Eine externe Firewall soll vorgeschalten werden, ist derzeit aber noch nicht vorhanden.
Hauptaufgaben sind Web/Mail/FTP. Ein Confixx 3.0 ist ebenfalls installiert.
Wie würdet ihr vorgehen?
Zuerst mal Confixx oder ähnliche Tools entsorgen. Wenns um Sicherheit geht, will man genau sehen, was wo wie konfiguriert ist und kein Tool, das einem an allen Ecken irgendwie ins Handwerk pfuscht. Jedes Stück Code ist ein potentielles Einfallstor. Daher als nächstes alle unnötige Software entfernen und alle Dienste rausnehmen, die nicht auch wirklich gebraucht werden (Achtung: das gilt neben den rc.d-Links auch für /etc/inittab, die inetd-Config!). Bei den Kernelmodulen aufräumen, evtl. einen statischen, auf das Notwendige reduzierten Kernel bauen. Danach sämtliche verbliebene Software auf aktuellen Sicherheits-Patchstand bringen. Komplette Konfiguration durchgehen und alle nicht wirklich benötigten Funktionen abschalten. Dienste, die lediglich lokal benötigt werden, ausschließlich an lo binden (nicht an eht0) oder über Unix Domain Sockets kommunizieren lassen. Darauf achten, daß Dienste möglichst in chroot-Jails laufen oder doch zumindest nicht als root. Noch einen Schritt weiter kann man für bestimmte Dienste auch eine UML-Instanz ins Auge fassen, das schottet noch besser ab. Telnet und rlogin auf jeden Fall entsorgen, dafür SSH verwenden. Wenn möglich, auch auf FTP verzichten (sftp existiert, oder wenigstens TLS einsetzen). Direkte root-Logins verbieten, stattdessen normalen User-Account und su benutzen. Starke Passwort-Richtlinien aufsetzen und für alle Authentifizierungsmechanismen verankern, bei SSH zusätzlich über Publickey authentifizieren. Rechte im Filesystem checken, es sollte z.B. so gut wie keine world readable Files geben. Evtl. darüber nachdenken, /usr read-only zu mounten (da sollte normalerweise eh nicht reingeschrieben werden - zu diesem Zweck ist /var da). Anschließend über ein gründliches Backup-Konzept mit mehreren Generationen nachdenken. Das ist bei vielen root-Server-Anbietern leider ein Problem, weil man viel zu wenig Backup-Space kriegt (alles unter 100 GB ist da IMHO ein Witz, wie soll man da 4-5 Generationen einer Vollsicherung plus Historie unterbringen?) oder ggf. den Traffic zahlen muß, und natürlich weil der Backup-Space nach der Sicherung nicht auf externen, physikalisch nicht erreichbaren Medien liegt (und somit von einem Angreifer manipuliert werden könnte). Hat man mehrere Maschinen, sollte man außerdem den syslogd remote jeweils auf einen anderen Rechner auslagern, damit ein erfolgreicher Angreifer nicht einfach seine Spuren aus den Logs tilgen kann. -- Erhard Schwenk Akkordeonjugend Baden-Württemberg - http://www.akkordeonjugend.de k-itx it-dienstleistungen - http://www.k-itx.net
Hallo! Confixx runterschmeissen geht leider nicht. Würde es Sinn machen ein IDS oder ähnliches zu installieren? Wenn ja, welches? Snort?
Zitat von "M. Hirst" <suse@agildev.com>:
Da ich einen neuen Server unter Suse Linux 9 unter die "Fitiche" bekomme wollte ich mal so in die Runde fragen wie ihr eure Server absichert.
Der Server steht bei einem Hoster d.h. ich habe keinen direkten Zugang zur Hardware. Eine externe Firewall soll vorgeschalten werden, ist derzeit aber noch nicht vorhanden.
Hauptaufgaben sind Web/Mail/FTP. Ein Confixx 3.0 ist ebenfalls installiert.
Wie würdet ihr vorgehen?
Zuerst mal Confixx oder ähnliche Tools entsorgen. Wenns um Sicherheit geht, will man genau sehen, was wo wie konfiguriert ist und kein Tool, das einem an allen Ecken irgendwie ins Handwerk pfuscht.
Jedes Stück Code ist ein potentielles Einfallstor. Daher als nächstes alle unnötige Software entfernen und alle Dienste rausnehmen, die nicht auch wirklich gebraucht werden (Achtung: das gilt neben den rc.d-Links auch für /etc/inittab, die inetd-Config!). Bei den Kernelmodulen aufräumen, evtl. einen statischen, auf das Notwendige reduzierten Kernel bauen.
Danach sämtliche verbliebene Software auf aktuellen Sicherheits-Patchstand bringen. Komplette Konfiguration durchgehen und alle nicht wirklich benötigten Funktionen abschalten. Dienste, die lediglich lokal benötigt werden, ausschließlich an lo binden (nicht an eht0) oder über Unix Domain Sockets kommunizieren lassen. Darauf achten, daß Dienste möglichst in chroot-Jails laufen oder doch zumindest nicht als root. Noch einen Schritt weiter kann man für bestimmte Dienste auch eine UML-Instanz ins Auge fassen, das schottet noch besser ab.
Telnet und rlogin auf jeden Fall entsorgen, dafür SSH verwenden. Wenn möglich, auch auf FTP verzichten (sftp existiert, oder wenigstens TLS einsetzen). Direkte root-Logins verbieten, stattdessen normalen User-Account und su benutzen. Starke Passwort-Richtlinien aufsetzen und für alle Authentifizierungsmechanismen verankern, bei SSH zusätzlich über Publickey authentifizieren.
Rechte im Filesystem checken, es sollte z.B. so gut wie keine world readable Files geben. Evtl. darüber nachdenken, /usr read-only zu mounten (da sollte normalerweise eh nicht reingeschrieben werden - zu diesem Zweck ist /var da).
Anschließend über ein gründliches Backup-Konzept mit mehreren Generationen nachdenken. Das ist bei vielen root-Server-Anbietern leider ein Problem, weil man viel zu wenig Backup-Space kriegt (alles unter 100 GB ist da IMHO ein Witz, wie soll man da 4-5 Generationen einer Vollsicherung plus Historie unterbringen?) oder ggf. den Traffic zahlen muß, und natürlich weil der Backup-Space nach der Sicherung nicht auf externen, physikalisch nicht erreichbaren Medien liegt (und somit von einem Angreifer manipuliert werden könnte).
Hat man mehrere Maschinen, sollte man außerdem den syslogd remote jeweils auf einen anderen Rechner auslagern, damit ein erfolgreicher Angreifer nicht einfach seine Spuren aus den Logs tilgen kann.
-- Erhard Schwenk
Akkordeonjugend Baden-Württemberg - http://www.akkordeonjugend.de k-itx it-dienstleistungen - http://www.k-itx.net
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
-- Michael Hirst - mike@agildev.com agildev - Softwareentwicklung - Projektentwicklung - Projektmanagement http://www.agildev.com Rosentalgasse 10/5 1140 Wien Tel.: +43/1/9909182
Hallo Michael, hallo Leute, Am Freitag, 27. Mai 2005 14:07 schrieb M. Hirst:
Confixx runterschmeissen geht leider nicht.
Überleg Dir das lieber nochmal ;-) Falls es wirklich nicht ohne Confixx geht, sorge zumindest dafür, dass Du die neueste Version installiert hast. Meine Meinung zu Confixx ist übrigens "wenig positiv". Es gab einen Bug, der erlaube, mit Backup/Restore fremde Dateien in die Finger zu bekommen und sogar zu überschreiben. Grund war, dass Backup und Restore als root und nicht als der jeweilige User liefen. Naja, Sicherheitslücken können immer mal vorkommen - das allein wäre also nicht so schlimm. Wenn der Fix aber mehrere Wochen oder gar Monate auf sich warten lässt, macht das keinen guten Eindruck. (Mein Hotfix, einfach Backup und Restore im Webinterface zu sperren, ging übrigens ganz schnell ;-) Dazu kommt, dass ich (aufgrund der Release Notes für die Bugfix-Version, ansonsten ungetestet) gewisse Zweifel habe, ob wirklich alles abgedichtet ist. In der 2.0.14 wurde das Backup weiterhin als Root gemacht, Hardlink-Attacken dürften also in dieser Version weiterhin möglich sein. (Wie es bei 3.x aussieht, weiß ich nicht. Bei "Backup als root" hätte ich aber Bedenken...) Das schlimmste: Eine diesbezügliche Nachfrage per Mail an SWsoft (im Nov. 2004) ist bis heute unbeantwortet! Soviel zum Thema Sicherheitsbewusstsein... [ TOFU gelöscht - bitte http://learn.to/quote ] Gruß Christian Boltz PS: Wenn Du eine grafische Admin-Oberfläche brauchst: Zu WebMin & Co hätte ich mehr Vertrauen ;-) --
Was soll mir diese Frage eigentlich sagen? Wenn es dir etwas hätte sagen sollte, wäre es eine Sage und keine Frage. ;-) [> Christian Boltz und Ratti]
Erhard Schwenk wrote:
[...] Rechte im Filesystem checken, es sollte z.B. so gut wie keine world readable Files geben. [...]
Ich hoffe mal, das sollte world-writeable heissen - ansonsten halte ich Dein Sicherheitskonzept fuer ein wenig schraeg, wenn User nicht mal mehr Dateien lesen duerfen... Cheers, Th.
participants (4)
-
Christian Boltz -
Erhard Schwenk -
M. Hirst -
Thomas Hertweck