Archiv verlassen und diese Seite im Standarddesign anzeigen : vServer absichern - Grundlegende Überlegungen
Hallo zusammen,
Ich nutze für mein Kleinunternehmen eine webbasierte ERP-Lösung und betreibe diese auf Webspace, der extern verwaltet wird. Weiterhin habe ich Typo3-Webseiten (ebenfalls gehostet) und einige Domains.
Bezüglich Linux Know-How habe ich die LPI-101 Prüfung bestanden und bereite mich derzeit auf die 102-Prüfung vor. Ich überlege derzeit, auf einen vServer umzusatteln um die einzelnen Konten zusammenzufassen und dabei evtl. auch etwas an Geld und Verwaltung zu sparen.
Während der Vorbereitung auf LPI-102 konnte ich mich auch etwas in den Bereich Serverdienste (Ports, Sicherung über Schlüssel etc.) einlesen. Weiterhin lese ich auch in mehreren Linuxforen mit und auf der Webseite
http://root-und-kein-plan.ath.cx/
wird von einem "offenen Mail-Relay" gesprochen. Ich möchte natürlich nicht, dass mein Server als Spamschleuder missbraucht wird, da ich ja für die Sicherheit verantwortlich bin. Mailserver wollte ich auch nicht als Dienst darauf laufen lassen, aber mir graust es schon bei dem Gedanken, dass jemand meinen Server kapert und dann Dienste darauf laufen lässt.
Kann man zu einem Server mit Schlüsselauthentifizierung mit ggf. verlegten SSH-Port, automatischen Updates Vertrauen haben, dass genug "gesichert wurde"? Ansonsten wurde in unserer LUG auch Portknocking und Fail2Ban angesprochen. Ist das auch zu empfehlen?
Vielen Dank für Tipps. Es sind halt generelle Überlegungen, die ich mache bevor ich so etwas anmiete.
Thanks,
Mkd75
Rain_maker
08.06.13, 10:15
Nur ganz kurz
wird von einem "offenen Mail-Relay" gesprochen. Ich möchte natürlich nicht, dass mein Server als Spamschleuder missbraucht wird, da ich ja für die Sicherheit verantwortlich bin. Mailserver wollte ich auch nicht als Dienst darauf laufen lassen, aber mir graust es schon bei dem Gedanken, dass jemand meinen Server kapert und dann Dienste darauf laufen lässt.
ein klein wenig Senf von mir.
Wenn kein Mailserver läuft, kann er natürlich auch nicht als Angriffspunkt selbst dienen, aber das kann Dich nicht davor schützen, daß jemand anderes nach erfolgreichem Einbruch (z.B. über den Webserver) und Erlangung der entsprechenden Privilegien genau das tut (= SMTP-Server mit eingebautem SPAMversand), damit wirst Du leben müssen, es sei denn Du nimmst den Server gar nicht in Betrieb.
Zum Thema fail2ban bzw. portknocking sollte man allgemein anmerken, daß sie für die eigentliche Sicherheit _niemals_ eine wichtige Stütze sein sollten, sondern maximal ein kleines Zusatzfeature darstellen, das einem den gröbsten Dreck vor allem aus den Logs hält.
Bei Portknocking finde ich mittlerweile die Implementation von Moxie Marlinspike einen zweiten Blick wert, nennt sich "knockknock" (allwissende Müllhalde hilft weiter). Allerdings sollte man aufpassen, daß man sich mit solchen netten Zusatztools nicht selbst aussperrt.
Greetz,
RM
Danke für die schnelle Rückmeldung Rain_maker,
Wenn kein Mailserver läuft, kann er natürlich auch nicht als Angriffspunkt selbst dienen, aber das kann Dich nicht davor schützen, daß jemand anderes nach erfolgreichem Einbruch und Erlangung der entsprechenden Privilegien genau das tut, damit wirst Du leben müssen, es sei denn Du nimmst den Server gar nicht in Betrieb.
Ja das sind halt die Überlegungen die mir so durch den Kopf schwirren. Auf Passwort-Authentifizierung bei einem root-Konto wollte ich mich halt nicht verlassen und dann halt einen starken Schlüssel verwenden. Ich habe auch einen etwas älteren heise-Artikel namens "Offene Festung":
[1] Andreas Neue, Dr. Harald Leinders, Offene Festung, Linux-Rootserver einrichten und absichern, c't 6/06, S. 244
Werde mir den auch nochmal zu Gemüte führen.
Rain_maker
08.06.13, 10:52
Die Sache mit dem "Vertrauen" war beim Lesen der springende Punkt, weshalb ich geantwortet habe.
Deine Überlegungen sind ja nicht falsch, aber leider ist z.B diese Frage hier
Kann man zu einem Server mit Schlüsselauthentifizierung mit ggf. verlegten SSH-Port, automatischen Updates Vertrauen haben, dass genug "gesichert wurde"?-ob es einem nun gefällt oder nicht- mit einem klaren "Nein" zu beantworten.
Das gilt prinzipiell so, denn auch wenn man keinen offensichtlichen "Anfängerfehler" gemacht hat, kann die "Festung" immer noch wie ein Kartenhaus zusammenstürzen, wenn der Angreifer über eine Lücke in $DIENST_DER_LAUFEN_SOLL reinkommt und sich per privilege escalation eine root-shell holt.
Das wird man nie ausschließen können, egal wie viele Überlegungen man vorher getroffen hat, soll heissen "Vertrauen ist gut", aber man muss sich auch im Klaren sein, wo man nicht mehr weiter vertrauen kann.
Du kannst -und musst!- z.B. Deinem Distributor vertrauen, daß er seine Pakete ordentlich baut und dann auch ordentlich signiert, Deine Aufgabe ist es allerdings dafür zu sorgen, daß auch nur vertrauenswürdige Softwarequellen eingerichtet sind. Du kannst aber nie darauf vertrauen, daß selbst bei regelmässigen Updates nur aus den Quellen vertrauenswürdiger Anbieter, der Server "gut genug gesichert" ist, denn der kann nur Fehler beheben, die schon bekannt sind.
Soll heissen, neben möglichst guter "Absicherung mit Hausmitteln" (die Du grösstenteils genannt hast) ist ständige Kontrolle des Systems genau so wichtig, auch wenn es durchaus sein kann, daß ein entsprechend geschulter Angreifer sich auch dagegen wehren kann.
Das soll hier keine Haarspalterei werden, vor allem, weil ich mir schon denken kann, daß Dir das - im Gegensatz zu einigen anderen Usern, die derartige Threads starten- schon klar ist, aber diese User lesen vielleicht solche Threads auch ab und zu mal, bevor sie posten, und dann will ich auf keinen Fall, daß jemand aus solchen Aussagen die falschen Schlüsse zieht.
Was mir aber noch einfällt, da es meiner Meinung nach nicht explizit von Dir erwähnt wurde, aber SSH per pubkey ist gut, SSH nur für einen nicht privilegierten User über pubkey und root-login über SSH ganz verbieten ist besser (su/sudo sollen ja auch etwas zu tun bekommen).
Die Sache mit den "automatischen Updates" ist zwiespältig, denn sollte "automatisch" so viel wie "unbeaufsichtigt" bedeuten, dann muss man da sehr vorsichtig sein, ein Update kann auch mal selbst fehlerhaft sein bzw. dem User Rückmeldung geben wollen und das sieht man dann eben nicht, manchmal mit ungewollten Folgen, also auch hier zumindest kontrollieren, was da bei den Updates ausgegeben wurde oder gleich regelmässig selbst ausführen.
Greetz,
RM
Danke nochmals Rain_maker,
Ich hatte halt von verschiedenen Brute-Force-Attacken hier gelesen, dass Angreifer zahlreiche Varianten für die Passwörter ausprobieren und bin mir jetzt auch nicht mehr ganz sicher, ob ich die Serveradministration wirklich in die eigene Hand nehmen möchte. Das mit dem nicht-privilegierten Benutzer anmelden und dann die Privilegien über su/sudo nach dem Login zu holen ist jedenfalls ein guter Tipp. Die Attacken kommen wahrscheinlich aus aller Welt und sind durch zahlreiche Proxyserver verdeckt. Das macht eine Ermittlung des Täters wahrscheinlich sehr schwer.
Ein anderes Thema wäre auch: "Entwicklerversionen" z.B. openSUSE oder Fedora auf einem vServer laufen zu lassen? Die Firma Hetzner bietet so etwas an. Oder sollte man eher etwas in der Richtung Enterprise (CentOS, Ubuntu LTS) nehmen? Ich mag halt den Planungshorizont von mehreren Jahren, obwohl ich nur ein Kleinunternehmen habe. Ich habe auf dem Desktop einiges ausprobiert aber mittlerweile bin ich auch etwas verwirrt, z.B. dass die Konfigurationsdateien (z.B. für Apache) anders heissen oder sich an einem anderen Ort befinden.
Rain_maker
08.06.13, 12:15
Der Sache mit der "Entwicklerversion" muss ich (als Nutzer einer solchen) natürlich widersprechen, aber Du meinst natürlich etwas anderes, namentlich Supportzeitraum der jeweiligen Releases.
Auch hier -tja, ich wiederhole mich irgendwie dauernd- gilt "choose your poison", denn ich halte es z.B. für mindestens genau so wichtig, daß man ein System verwendet, welches einem vertraut ist und wenn man z.B. seit Jahren Fedora verwendet, dann ist es nicht unbedingt ein Fehler es auch auf einem Server einzusetzen, wenn man damit leben kann, daß dann eben auch öfters ein Upgrade fällig ist. Ist auf jeden Fall sicher nicht schlimmer als sich auf Gedeih und Verderb mit einer Distro auf kritischer Infrastruktur beschäftigen zu müssen, die einem (zumindest noch) fremd ist.
Wenn man allerdings meint "mir ist langer Support sehr viel wichtiger als aktuelle Pakete und CentOS ist von Fedora nun wirklich nicht weit weg", dann nimmt man eben die "Langzeitdistro", muss aber damit leben, daß sich eventuell neu hinzugekommene und gewünschte Features in $SOFTWARE für die nächsten Jahre nicht realisieren lassen, weil der Distributor keine neue Version der Software anbietet und sich auch an diese Vorgabe halten.
Was ich damit meine?
Nun, kleiner Seitenhieb für zwischendurch:
Ich persönlich (sic!) finde es zum Bleistift ausgesprochen befremdlich, wenn besonders Spezis aus der Debianfraktion von der ach so gut abgehangenen "by-design" Stabilität von Debian rumfaseln, sich dann aus Featuritis massig backports ins System ballern und immer noch der Meinung sind, sie hätten etwas anderes als alle anderen Distros mit kürzerem Releasezyklus (wobei, ja haben sie, massenweise alte/veraltete Software und ein Repo mehr als nötig), aber das nur am Rande.
Nachtrag:
Netter Zufall, das passt einfach so wunderbar zu obiger Aussage, das muss ich jetzt einfach hier verlinken.
http://www.linuxforen.de/forums/showthread.php?t=275235
Wobei in dem Fall nicht einmal die Distro des Drittanbieters passt, aber hey, ist ja sowas von stable, was kann da schon schief gehen?
Greetz,
RM
Der Sache mit der "Entwicklerversion" muss ich (als Nutzer einer solchen) natürlich widersprechen, aber Du meinst natürlich etwas anderes, namentlich Supportzeitraum der jeweiligen Releases.
Also ich selbst bin halt ein großer Fan von "YaST" bei Suse aber soweit ich weiss gibt es noch keinen Suse Linux Enterprise-Klon, wie beispielsweise CentOS (für RHEL). Entwicklerversion ist auch nicht irgendwie böse gemeint, mehr in die Richtung, dass daraus die Enterpriseprodukte entstehen.
Rain_maker
08.06.13, 13:36
Also ich selbst bin halt ein großer Fan von "YaST" bei Suse aber soweit ich weiss gibt es noch keinen Suse Linux Enterprise-Klon, wie beispielsweise CentOS (für RHEL).
Wäre mir ehrlicherweise auch neu, Anregungen/Diskussionen gab es da schon (bin nur gerade zu faul zum Suchen), aber in die Tat wurde das bisher nicht umgesetzt.
Und für alle, die jetzt "Evergreen" schreien wollen, lasst die Kirche mal im Dorf, zwischen dem, was CentOS als Alternative zu RHEL bietet und dem, was Evergreen für openSUSE werden soll, liegen (zumindest noch) Welten.
Bei openSUSE sieht es zur Zeit in etwa so aus:
a) Wenn man jeden Sprung auf eine neue Version mitmacht, dann heisst das alle 8-9 Monate ein Systemupgrade fahren, dafür ist dies aber ein Weg, der offiziell von zypper/YaST unterstüzt wird und in meiner Erfahrung auch sehr zuverlässig funktioniert, die meisten Probleme entstehen -welche Überraschung- aus Drittabieterpaketen/-repos.
b) Reizt man den Supportzeitraum einer Version aus, dann wären wir bei zur Zeit etwa 18 Monaten, dann aber verbunden mit der Gefahr, daß man beim Versuch das Upgrade mit Überspringen von den dazwischen liegenden Versionen gegen die Wand läuft. Das Risiko von Problemen bzw. der Notwendigkeit von Hand ein wenig nachzuarbeiten steigt dabei -nächste Überraschung- mit der Anzahl an zu überspringenden Versionen.
Bisher hat das bei mir auch auf Desktopsystemen (die i.d.R. deutliche mehr Software installiert haben und wo auch eher Drittanbieterrepos drin sind) immer ordentlich geklappt, aber eine Garantie gibt es da eben nicht.
Auf jeden Fall wäre es bei einer Serverinstallation sicher keine dumme Idee sich z.B. eine VM mit den selben Paketen wie auf dem echten Eisen anzulegen und dort die Upgrades vorher zu testen, da findet man die potentiellen Probleme meist genau so schnell und es hat zunächste keine Konsequenzen für das "echte Eisen".
Entwicklerversion ist auch nicht irgendwie böse gemeint, mehr in die Richtung, dass daraus die Enterpriseprodukte entstehen.
Ja, wobei das dann auch nicht bei jeder Version von openSUSE oder Fedora der Fall ist, auch da werden bestimme Versionen heraus gepickt und diese dienen dann als Basis für die Enterprisevariante, bei so unterschiedlichen Releasezyklen geht das auch nicht sinnvoll anders. Letztlich sind openSUSE/Fedora eigenständig und dienen "nur" als Basis für SLES/RHEL, also eigentlich so wie Debian für die ganzen *Buntus&Co. (und ich stelle mir gerade ehrlicherweise auch vor meinem geistigen Auge den riesigen Spaß vor, den man haben könnte, wenn man Debian als "Entwicklerversion" für *Buntu bezeichnet ... Popcorn anyone? :ugly:).
.. in der Diskussion vermisse ich noch den Punkt "wer kontrolliert die Logs deines Servers während du in Urlaub / wenn du mal krank bist ?
Solltest du für dich auch klären bevor du dir einen anschaffst...
Rain_maker
15.06.13, 21:15
.. in der Diskussion vermisse ich noch den Punkt "wer kontrolliert die Logs deines Servers während du in Urlaub / wenn du mal krank bist ?
Naja, wenn schon solch eine Anregung kommt, dann machen wir doch mal Nägel mit Köpfen und bringen in diesem Thread mal etwas ein, was man in derartigen Diskussionen selten bzw. erst dann findet, wenn das Kind schon in den Brunnen gefallen ist (bzw. um beim Vergleich zu bleiben schon wieder mit Gesicht nach unten auf der Wasseroberfläche treibt).
Um mal einen bekannten Hacker aus einem mittlerweile ein paar Jahre alten Vortrag zu zitieren (Dan Kaminsky in einem seiner Vorträge zu dem fetten DNS Bug in 2008).
It's not about how the network* works, when things are going right, it's about how the network* works, when things are going wrong.
*Man ersetze "the network" im Geiste mit "my Server" und dann passt es auch auf diese Situation.
In a nutshell, wie sieht der Notfallplan aus?
- Wie sieht die Backupstrategie aus?
- Wer untersucht die Kiste auf das Einfallstor, wenn sie mal gekapert wurde?
- Wie schnell kann man die Kiste im Notfall wieder verfügbar machen (und zwar mit einer Wahrscheinlichkeit > 0, daß sie gleich wieder ge0wned wird ....)?
etc. pp.
Greetz,
RM
Dann werfe ich mal wieder die gute alte Anleitung zum Absichern von Debian (http://www.debian.org/doc/manuals/securing-debian-howto/index.de.html) in den Raum, auch wenn kein Debian verwendet wird, lohnt es sich die zu lesen, da die kritischen Stellen grundsätzlich diskutiert werden und die sind nicht Distributions spezifisch.
Nachtrag, wenn eine Web-Anwendung (also zB eine Web-Seite) angeboten wird, sollte man auch einen gründlichen Blick auf https://www.owasp.org/index.php/Main_Page werfen, da die sich mit "Real World Attacks" beschäftigen.
Newbie314 spricht einen wichtigen Punkt an. Bislang nutze ich halt mehrere Shared-Hosting Webkonten und bin an sich auch ganz zufrieden nur ist es etwas teurer (Gesamtkosten) und man hat halt "mehrere Baustellen".
Ich war jetzt vier Wochen im Urlaub und hätte ggf. über SSH und UMTS auf den Server zugreifen können aber letztendlich ist es ja auch eine Frage, ob man Urlaub machen oder Arbeiten will.
Bezüglich der Backupstrategie dachte ich an die Sicherungswerkzeuge, die die einzelnen Hoster anbieten also, dass man verschiedene Slots hat, wo man eine Datensicherung durchführen kann. Ansonsten dachte ich an regelmäßige Dumps der MySQL/PostgreSQL-Datenbanken.
Bezüglich "Forensik" müsste ich höchstwahrscheinlich einen externen Dienstleister beauftragen. Kontakte zur lokalen Linux User Group und Linuxsystemhäusern bestehen. Ich gehe aber mal davon aus, dass ich dann zahlen müsste und billig wird das wahrscheinlich nicht.
Danke auch an "nopes" für den Hinweis mit Debian. Ich habe auch ein eBook über den eigenen Rootserver. Müsste ich bei Zeiten vorher lesen.
Je nach Anwendungsfall wäre es vielleicht eine Möglichkeit den Server im Urlaubsfalle "einfach" vom Netz zu nehmen. Ob das bei dir ginge weiß ich natürlich nicht.
Ja, das habe ich mir auch überlegt. Die wichtigsten Sachen wären halt TYPO3 wegen der Webseite (Werbezwecke) und die Warenwirtschaft für die administrativen Sachen (Rechnungen schreiben etc.). Ich dachte an eine Amazon-EC2 Microinstanz, die man ggf. herunterfahren kann. Ich habe für mein Warenwirtschaftshosting allerdings für drei Jahre im Voraus bezahlt. Es gab 30% Rabatt.
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.