PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Eierlegender Wollmilchserver - Sicher?



Skipper
16.11.02, 12:52
Hallo zusammen,
man liest ja oefters, dass man verschiedene Dienste auf unterschiedlichen Maschinen laufen lassen sollte, weil das sicherer sei, allerdings ohne naehere Erlaeuterung.

Nun ist mir klar, dass es besser ist, nicht alle Eier in einem Korb zu tragen, wenn doch mal ein Einbruch geschieht. Ausserdem steigt die Wahrscheinlichkeit potenzieller Sicherheitsluecken sicher auch mit der Anzahl der angebotenen Dienste, und die Konfiguration von allem zusammen auf einer Maschine erschwert es sicher auch noch mal, alles wasserdicht zu machen.

Nun kann ich mir leider keinen Serverschrank ins Wohnzimmer stellen, und so habe ich meinen Heimserver in vielen Wochen schweisstreibender Arbeit mit folgenden Funktionen ausgestattet:

LAMP, Mailserver, POP3 (nur fuer interne Mailverteilung), Iptables Firewall, Router, Gateway ueber DSL ins Internet, SSH, FTP-Proxy und Faxserver. Von Aussen erreichbar ist http, smtp und ssh, und natuerlich das Faxmodem ueber Waehlleitung. Das "interne Netzwerk" (=meine Workstation) stufe ich als 100% vertrauenswuerdig ein.

Habe ich da irgendetwas kombiniert, was man auf jeden Fall vermeiden sollte, oder laesst sich das mit entsprechender Sorgfalt (die ich hoffentlich aufgewendet habe) fuer den Heimbedarf angemessen sicher bekommen? Security HowTo's habe ich schon genug gelesen, die beschaeftigen sich aber in der Regel nur mit isolierten Themen, und nicht mit dem Zusammenspiel der Einzelteile.

Jinto
16.11.02, 13:03
Natürlich kann man alles auf eine Maschine packen, wie sinnig oder unsinnig das ist hängt allein vom Umfeld ab.

Klar ist auf jeden Fall: fällt ein Dienst fallen alle Dienste, zumindest wenn der Angreifer durch den kompromittierten Dienst Root-Rechte erlangt. Aber allein schon bei einem lokalen Zugang erhöht sich das entsprechende Risiko (da ja auf mehr Programme Zugriff besteht). Bei der Verteilung auf mehrere Maschinen, fällt diese Problematik natürlich ersteinmal weg.

Zu deiner Konfiguration: Warum muss ssh und smtp von aussen erreichbar sein?

Gruß

Skipper
16.11.02, 13:20
Original geschrieben von Jinto
Zu deiner Konfiguration: Warum muss ssh und smtp von aussen erreichbar sein?

Ssh ist doch klar, damit ich den Server fernwarten kann.
Zur zweiten Frage: Der Server ist unter einem festen dyndns-Domainnamen erreichbar. Da bietet es sich doch an, fuer verschiedene Verwendungszwecke eigene Mailaccounts einzurichten.

Jefferson
17.11.02, 08:35
Original geschrieben von Skipper
Ssh ist doch klar, damit ich den Server fernwarten kann.

Hmm.. wie klar ist das eigentlich?

Mal ne Frage : ist der Server nur für private oder geschäftliche Zwecke gedacht ?

Solang SSh , telnet und dergleichen laufen mußt Du dir grundsätzlich immer Gedanken um die Sicherheit machen !

Wenn Du die Kiste vom Wohnzimmer aus administrieren kannst , für was dann das fernwarten ?
(Darauf bezogen weil Dus ja so sicher wie möglich haben willst !)

JeFF :ugly:

Skipper
17.11.02, 10:26
Original geschrieben von Jefferson
Hmm.. wie klar ist das eigentlich?

Mal ne Frage : ist der Server nur für private oder geschäftliche Zwecke gedacht ?

Solang SSh , telnet und dergleichen laufen mußt Du dir grundsätzlich immer Gedanken um die Sicherheit machen !

Wenn Du die Kiste vom Wohnzimmer aus administrieren kannst , für was dann das fernwarten ?
(Darauf bezogen weil Dus ja so sicher wie möglich haben willst !)

JeFF :ugly:
Er ist ausschliesslich fuer private Zwecke gedacht. Alle Dienste, die ich anbiete, nutze ich aber auch. Schliesslich will ich mal bei mehrwoechiger Abwesenheit per ssh nach dem rechten sehen.

Meine Frage ging eher in die Richtung: Koennen Dienste, die einzeln problemlos sind, in Kombination zu einem Scheunentor werden, durch ungewollte Querbeeinflussung?

Jinto
17.11.02, 12:23
Koennen Dienste, die einzeln problemlos sind, in Kombination zu einem Scheunentor werden, durch ungewollte Querbeeinflussung? Ja, z. B. wenn in einem Produkt ein lokal-root exploit gefunden wird, und dieses Programm über einen anderen Dienst aufgerufen wird.

HTH

Jefferson
17.11.02, 14:00
:p Jinto ist mir zuvorgekommen!

Genau das wollte ich auch sagen !

Gruß,

Jeff ;)

habbom
17.11.02, 14:26
Hi,
ssh von außen halte ich aufgrund der immerwieder auftauchenden Sicherheitslücken für bedenklich, ich wähle mich auf meinen Server im internen Netz auf und gehe von dort per ssh auf meinen Router.
Mit einer zusaätzlichen ISDN-Karte im Router würde es auch gehen.

Gruß
Michael

RapidMax
17.11.02, 15:30
Folgende Überlegung: Wie interessant ist dein Server? Für potentielle Angreifer währe er als DDoS client, Datenablage für Illegale Daten und als anonymisierender Proxy für illegale Aktivitäten interessant. Diese "Anwendungen" richten sich nicht spezielle gegen dich; jeder Server ist dazu nützlich.

Aus diesem Grund wir sich niemand die Zähne an deinem Server ausbeissen, sich die Mühe machen, um jeden Preis einzudringen.

Dein Server ist also hauptsächlich gegen bekannte Sicherheitslücken anfällig, spezielle solche, für die es "Scriptkiddies-Tools" gibt. Daneben dürfen natürlich keine konzeptionellen Schwachstellen vorhanden sein.

Wenn du die eingesetzten Dienste sorgfältig konfigurierst, gute Passwörter wählst und regelmässig Updates gegen bekannte Sicherheitslöcher einspielst, kannst du dich recht gut gegen mögliche Attacken wehren.

Natürlich ist es immer möglich, trotzdem "erwischt" zu werden. Hier stellt sich die Frage, wie sich der Server weiter absichern lässt. Wie du bereits erkannt hast, sind viele Dienste auch ein grösseres Risiko. z.B. wäre es möglich einzelne Dienste erst auf Verlangen einzuschalten: Wenn du z.B. SMTP benötigst, fährst du den Dienst über ssh hoch.
Um Einbruchsversuche zu erkennen, kannst du ein Tool wie TripWire installieren.

Falls du dich bezüglich der möglichen Sicherheitsmassnamen weiter und tiefer informieren willst, empfehle ich entsprechende Literatur. Ein gutes Buch ist z.B.:
Linux Sicherheit - Security mit Open-Source-Software, Grundlagen und Praxis / Tobias Klein / dpunkt Verlag, iX edition. ISBN 3-932588-04-5 (am besten über den Linuxforen-Banner).

Gruss, Andy

Skipper
17.11.02, 19:08
Original geschrieben von Jinto
Ja, z. B. wenn in einem Produkt ein lokal-root exploit gefunden wird, und dieses Programm über einen anderen Dienst aufgerufen wird.

Ah, das ist ein interessanter Aspekt.


Original geschrieben von habbom
ssh von außen halte ich aufgrund der immerwieder auftauchenden Sicherheitslücken für bedenklich, ich wähle mich auf meinen Server im internen Netz auf und gehe von dort per ssh auf meinen Router.

Gute Idee. Es ist schon seltsam, dass ein Programm, das den Begriff "Secure" im Namen traegt, in der Hinsicht so negativ auffaellt. Ist es nur schlampig programmiert, oder ist die Sache wirklich so schwierig?

Ansonsten habe ich mich schon sehr um sichere Dienstekonfiguration bemueht, und bei Debian sind Security-Updates ja auch ein Kinderspiel.

Ist es eigentlich empfehlenswert, apt-get update && apt-get upgrade per Cronjob durchfuehren zu lassen? Laut manpage sollen dabei ja in keinem Fall Configdateien ueberschrieben werden, und upgedatete Dienste werden, wie ich bisher beobachten konnte, automatisch neu gestartet. Aber ich noch nicht lange genug bei Debian, um zu beurteilen, ob das wirklich auf Dauer sicher und zuverlaessig funktioniert.

Jinto
17.11.02, 19:27
Naja, so schlimm wie sich das mit ssh anhört ist es nicht ganz. OpenBSD hat 6 Jahre lang erfolgreich durchgehalten, trotz ssh.

ssh unterstützt allerdings 2 Protokollversionen, v1 hat den Ruf ein Design-Fehler zu sein :). Deswegen wird generell empfohlen wenn die Kompatibilität nicht zwingend benötigt wird, ausschließlich Version 2 einzusetzen.

HTH

RapidMax
17.11.02, 21:27
@Jinto: ACK


Ist es eigentlich empfehlenswert, apt-get update && apt-get upgrade per Cronjob durchfuehren zu lassen?Aus Sicherheits-Technischer Sicht ist jeder "automatische" download aus dem Netz ein Risiko. Im letzten Jahr wurden min. 3 Pakete auf dem FTP-Server mit einem Trojaner verseucht. Dabei hat es sich zwar immer um Tarballs gehandelt, bei denen das configure-Script verändert wurde, jedoch ist es auch mit Packeten möglich.

Um dem entgegenzuwirken hilft nur die Überprüfung mittels md5-Summen, wobei diese natürlich ebenfalls mittels eines Public-Key-Verfahren signiert werden müssen.

Soweit ich weiss verwendet apt die md5-Summen immer, aber eine Überprüfung der Signatur muss zusätzlich Konfiguriert werden. Kennt sich hier jemand damit aus?

Gruss, Andy