vServer gemietet: Sicherheit?

[Bachsau]

So, habe mir gerade einen vServer gemietet, erstmal nur für Webseiten. Andere Funktionen füge ich dann später hinzu.

Wenn man so einiges liest, wird man langsam paranoid. Ist ein Debian Squeeze mit LAMP Grundkonfiguration. Gibt es etwas, um dass ich mich sofort kümmern muss? Firewall, ipTables oder so? Oder kann ich davon ausgehen, dass die Grundausstattung so in Ordnung ist?

Dass die Einstellungen für Apache, MySQL & PHP angepasst werden müssen versteht sich natürlich von selbst.

Gruß,
Bachsau

 

[PapaBaer]

Das kommt darauf an, was du vor hast und wie gut die Qualität des vom Hoster eingesetzten vServer-Image ist.

Es sollte eher so laufen, dass du dir eine eigene Richtlinie überlegst, nach der die Sicherheit auf deinem Server ausgerichtet wird. Du passt dann ggf. die Software auf dem Server so an, dass diese Richtlinie erfüllt wird.

Zur Qualität des Images: Ich mache ein Image, welches über ein Debian Minimal hinaus geht bei einem neuen Server immer komplett platt, deinstalliere alle Dienste samt Configs und fange von Null an. Nur so weiß ich, was da wirklich läuft.

Wichtig Aufgabe zu Beginn: Update der Software, ssh absichern und sich überlegen, wie man das System sinnvoll monitort.

 

[JohnWart]

Hi,

wie PapaBaer empfiehlt würde auch ich mich auf keinen Fall auf ein vorgefertigtes Image verlassen. Am besten minimal anfangen, Firewall zu machen und dann nach und nach installieren und freigeben was du brauchst.

 

[Bachsau]

Also ich bin bei WebControl, und die bieten halt LAMP oder Minimal an. Ist das denn etwas anderes, wie wenn ich die Pakete von Hand installiere? Auf was muss ich beim Monitoring achten?

@PapaBaer: Wie meinst du das mit "Richtlinie"?

@JohnWart: Firewall "machen"? Worauf muss ich achten?

 

[Firewire2002]

Ist das denn etwas anderes, wie wenn ich die Pakete von Hand installiere?

In der Regel wird bei solchen Templates/Images mehr gemacht, als nur eine reine Installation via Paketmanager. Das kann Vorteilhaft sein oder eben auch nicht. Müsste man sich im Detail anschauen.
Auf eine Minimal-Installation aufzubauen oder direkt selbst zu installieren ist aber immer transparenter als irgendein fertiges Template/Image.

Auf was muss ich beim Monitoring achten?

Beim Monitoring kommt es drauf an, was du vom Monitoring erwartest. Überwachen kann man sämtlichen Müll. Ist die Frage brauch man das? Das definierst aber letztendlich wieder du.
Einigen reicht eine reine Überwachung ob der Dienst erreichbar ist, andere wollen auch Ressourcen überwacht haben und die nächsten achten auf die 5. Nachkommastelle der Temperatur der Gehäuseaussenwand.
Auch hier gibts keine pauschale Regelung. Bei einem einzelnen Server wird ein Erreichbarkeitsmonitoring aber eh ausgelagert werden müssen.
Entweder als Monitoring Service eines Anbieters oder in Form von mindestens einem 2. Server.

Wie meinst du das mit "Richtlinie"?

http://de.wikipedia.org/wiki/Sicherheitsrichtlinie
Ersatz "die Institution" durch "meinen Server" und lies den restlichen Allgemeinen Teil. Jeder Angestellter in irgendeinem Unternehmen hat sich an irgendeine Sicherheitsrichtlinie zu halten. Es wundert mich etwas, dass du so gar nichts damit anfangen kannst.

Firewall "machen"? Worauf muss ich achten?

Ob eine Firewall überhaupt benötigt wird, kann dir hier keiner pauschal sagen. Mal davon abgesehen, dass es hier dazu bereits sehr kontroverse Ansichten diesbezüglich gab, bleibt letztendlich die eingesetzte Software, deine Sicherheitsrichtlinie und dein selbstdefinierter Funktionsumfang ausschlaggebend ob und wie eine Firewall vorhanden/konfiguriert werden muss.

 

[its]

Die Überlegung ist vielleicht, ob ein Managed-Server nicht die richtige Lösung für dich ist. Da du dich bei der Managed-Server Lösung, rein auf deine Webseiten und Webdesign konzentrieren kannst.

Solltest du dich dennoch für den aktuellen Server entscheiden, hier ein paar Tipps:

• fail2ban (Security) + Anmeldung bei Blocklist.de für die Weitergabe der Angriffe.
• rkhunter (Security)
• logwatch ("Security")
• Munin (Monitoring)
• Monit (Monitoring für Prozesse)
• IPTables (alles dicht machen was du nicht benötigst)
• Backup-System (muss man individuell erstellen)
• SSH root Zugriff unterbinden (Basis Sicherheits-Einstellungen)
• PHP Skripte, dazu zählen auch Content Management Systeme immer aktuell halten und gegen Angriffe schützen. (Basis Sicherheits-Einstellungen)

Das ist nur eine Liste von Tools die du anwenden könntest, je nachdem, was du brauchst und was du absichern möchtest.

 

[Bachsau]

Danke für die ausführliche Liste, its. Nein, eine Managed-Lösung kommt für mich nicht in Frage. Ganz davon abgesehen, dass es mir zu teuer ist, will ich ja letztlich von den Webpacks weg, damit ich eben selbst basteln kann. Ich wähle den vServer um mehr technische Freiheit bei kleinen Projekten zu haben, nicht wegen der Resourcen für ein Großprojekt.

In der Regel wird bei solchen Templates/Images mehr gemacht, als nur eine reine Installation via Paketmanager. Das kann Vorteilhaft sein oder eben auch nicht.

Kann ich das irgendwie evaluieren? Wenn ich mir die laufenden Prozesse angucke, sehe ich doch wortwörtlich "was läuft", oder?

Beim Monitoring kommt es drauf an, was du vom Monitoring erwartest. Überwachen kann man sämtlichen Müll. Ist die Frage brauch man das?

Naja, wichtig ist, dass das ganze online ist. Zugriffe auf sämliche Dienste sollte ich überwachen können, und wichtige Änderungen würde ich natürlich schon gerne mitkriegen. Falls es jemand gelingt, ins System einzubrechen, oder es offensichtlich versucht. Sicher auch wichtig ist die Systemlast (RAM/CPU), um Lastspitzen zu erkennen, und falls nötig die Konfiguration optimieren zu können.

Jeder Angestellter in irgendeinem Unternehmen hat sich an irgendeine Sicherheitsrichtlinie zu halten. Es wundert mich etwas, dass du so gar nichts damit anfangen kannst.

Stand irgendwie auf'm Schlauch vorhin. Also gewisse Anforderungen würde ich natürlich schon an mich stellen. Falls es jemand gelingt, Datenbanken oder Mailboxen zu klauen, ist das natürlich höchst uncool. Sowas darf auf keinen Fall passieren.

 

[Firewire2002]

Die Prozessliste zeigt dir, was läuft, aber nicht wie es läuft. Bis du alle eventuellen Änderungen durch den Hoster gefunden hast, vergeht etliche Zeit.
Den Aufwand betreibt man, wenn man Hoster testen will oder eben eine kritische Analyse des Systems durchführt. In deinem Fall würd ich mir diesen Aufwand sparen. Entweder auf die Templates des Hosters vertrauen oder eben selbst installieren.

Was Monitoring betrifft, würd ich hier zu Munin oder ähnlichem + externes Dienste Monitoring tendieren.
Btw, Monitoring kann man auch wunderbar im Freundeskreis austauschen.

 

[PapaBaer]

logwatch und tripwire mit täglichen Statusmails zeigen dir, ob jemand am System gefummelt hat.

 

[Bachsau]

Da läuft nicht viel. Ich glaub das krieg ich in den Griff.

MOD: Bilder bitte immer als Anhang. Danke!

Für das brauch ich auch kein Image, hab daher jetzt auf Minimal umgestellt.

 

[Bachsau]

Habe gerade herausgefunden, dass die auf dem Hostsystem CentOS mit Kernel 2.6.18 laufen lassen, angeblich vollgestopft mit Backports. Ist soetwas normal? Der Kernel ist von 2006!

Nachdem mir ein paar wirklich unpassende devs aufgefallen sind, wollte ich sehen was passiert, wenn man udev startet. Aber udev mahnt die Kernel-Version an. Braucht man sowas in einer OpenVZ Maschine wirklich nicht? Hab eine relativ bescheidene Anzahl Standard-Devices vorgefunden, von denen es manche sicher gar nicht gibt, z.B. Soundkarten.

 

[PapaBaer]

Jep, das passt so.

Zum einen hast du durch OpenVZ mit der eigentlichen Hardware eh nix zu tun, also auch keine dev-Einträge. Zum anderen läuft OpenVZ nur auf ausgewählten Kernel-Versionen und dein Provider wird eher auf einem als stabil erachteten und bekannten Kernel bleiben, als mit neueren Versionen Side-Effects zu riskieren.

 

[Bachsau]

Alles klar.

Vom Provider habe ich einen SSH-Zugang gesetzt bekommen, wo ich mich mit "root" und Passwort einloggen konnte. Den hab ich erst mal dicht gemacht.

• Port geändert
• Auf Keyfiles umgestellt
• root-Login verboten

Es gibt zwar einen seriellen Konsolen-Zugang, den man nutzen kann, wenn man etwas komplett vermurkst hat, der liegt aber auf einer anderen IP.

 

[Bachsau]

Guten Morgen!

Offenbar erlebe ich gerade die Grenzen von OpenVZ.

IPtables, SELinux, AppArmor gehen alle in den Kernel-Bereich, und das mag er gar nicht. Damit hat sich das Thema Firewall & co wohl erstmal erledigt, hab ich Recht?

 

[danton]

Beim Anbieter nachfragen, ob er dir diese Funktionalität zur Verfügung stellen kann. Manchmal kann man das sogar einfach im Kunden-Webinterface aktivieren.

 

[Bachsau]

Okay, also SELinux ist wohl mit dem OpenVZ Kernel inkompatibel. Ist auch glaube ich nicht so wichtig. IPtables funktionieren aber. Nach Installation des Pakets lassen sich Regeln einrichten.

Logins über die serielle Konsole werden zwar nicht geloggt, allerdings ist nach drei Verbindungsversuchen für einige Minuten dicht, hab ich rausgefunden.

Ich werde jetzt mal versuchen, das Hostsystem in einer VM bei mir nachzubauen. Mit CentOS und OpenVZ, um zu sehen, was Sache ist.

Edit: Habe gerade mal nmap drüber laufen lassen:

Starting Nmap 5.00 ( http://nmap.org ) at 2011-04-29 19:29 CEST
NSE: Loaded 0 scripts for scanning.
Initiating Ping Scan at 19:29
Scanning xxx.xxx.xxx.xxx [2 ports]
Completed Ping Scan at 19:29, 0.14s elapsed (1 total hosts)
Initiating Connect Scan at 19:29
Scanning vps.test (xxx.xxx.xxx.xxx) [1000 ports]
Completed Connect Scan at 19:30, 28.69s elapsed (1000 total ports)
Host vps.test (xxx.xxx.xxx.xxx) is up (0.14s latency).
Interesting ports on vps.test (xxx.xxx.xxx.xxx):
Not shown: 981 closed ports
PORT     STATE    SERVICE
23/tcp   filtered telnet
135/tcp  filtered msrpc
139/tcp  filtered netbios-ssn
445/tcp  filtered microsoft-ds
6667/tcp filtered irc
6668/tcp filtered irc
6669/tcp filtered irc
6689/tcp filtered unknown
6692/tcp filtered unknown
6699/tcp filtered napster
6779/tcp filtered unknown
6788/tcp filtered unknown
6789/tcp filtered ibm-db2-admin
6792/tcp filtered unknown
6839/tcp filtered unknown
6881/tcp filtered bittorrent-tracker
6901/tcp filtered unknown
6969/tcp filtered acmsoda
7000/tcp filtered afs3-fileserver

Read data files from: /usr/share/nmap
Nmap done: 1 IP address (1 host up) scanned in 28.94 seconds

Heißt dann wohl, dass es sich dabei um Ports handelt, die der Provider geblockt hat, oder?

 

[PapaBaer]

Nein, das heißt nur, dass auf diesen Ports kein Dienst läuft, der antworten könnte.

iptables auf einem Server zu installieren, um dann die Ports freizugeben, auf denen Dienste laufen, ist also reichlich sinnlos. Es zeigt vielmehr, dass Sicherheit eben mehr ist, als ein paar Schlagworte wie "Virenscanner, Firewall & Co." abzuarbeiten.

Ich z.B. habe auf keinem meiner Server einen Portfilter a la iptables laufen. Warum auch?

Edit: in deinem Fall blockt dein Provider tatsächlich die angegebenen Ports. Macht aber in der Praxis keinen Unterschied, außer dass nmap statt filtered closed ausgeben würde.

 

[Bachsau]

Das ist jetzt mir z.B. nicht klar, wofür ich auf einem Server einen Virenscanner brauchen soll. Wenn da nicht wahllos Programme ausgeführt werden, gibt's auch keine Viren, oder?

iptables auf einem Server zu installieren, um dann die Ports freizugeben, auf denen Dienste laufen, ist also reichlich sinnlos.

Ja ist schon klar. Ich hab ja auch erstmal nur abgefrühstückt, was überhaupt machbar ist. Kann iptables nicht noch mehr, als Ports und IPs zu blocken? Muss ich mal nachlesen.

Ein schönes Netzfundstück von heute heißt "AIDE". Das Ding stellt wohl fest, wenn Dateien geändert worden sind. Klingt nützlich. Klar soll besser erst gar keiner rein kommen, aber wenn doch, will ich wissen, was er angestellt hat.

 

[wstuermer]

Das ist jetzt mir z.B. nicht klar, wofür ich auf einem Server einen Virenscanner brauchen soll. Wenn da nicht wahllos Programme ausgeführt werden, gibt's auch keine Viren, oder?

Emails?

Kann iptables nicht noch mehr, als Ports und IPs zu blocken? Muss ich mal nachlesen.

Gute Idee. Und dann nicht jedem gelesenen blind vertrauen sondern hinterfragen, verstehen, testen und reproduzieren.

Klar soll besser erst gar keiner rein kommen, aber wenn doch, will ich wissen, was er angestellt hat.

Sobald einer dein System erobert hat, kannst du dem System (und keinem dort laufenden Programm) mehr trauen.

 

[PapaBaer]

Sobald einer dein System erobert hat, kannst du dem System (und keinem dort laufenden Programm) mehr trauen.

Absolut richtig. Aber wie erkennst du, dass jemand dein System erobert hat? Dafür sind Programme wie tripwire und aide äußerst sinnvoll. Obendrein kann man im Nachhinein besser nachvollziehen, was auf dem Server passiert ist und hat so mehr Informationen, um die ausgenutzte Sicherheitslücke zu finden.