EC2 Server absichern

J

Jeanne dArk

0
Hallo zusammen,

und zwar haben wir (im geschäftlichen Umfeld) uns einen EC2 Server bei Amazon bestellt. Jetzt wollte ich fragen, wie dieser am besten abzusichern ist. Auf Wikipedia sind auch schon ein paar Sicherheitsmaßnahmen von Seiten Amazons beschrieben. Jetzt stellt sich die Frage, was man zusätzlich beachten und einrichten sollte.

In diesem Thread werden ein paar Tipps aufgelistet:
http://www.hackerboard.de/webmaster-security/47374-linux-server-sicherheitskonzept.html

Inwieweit treffen diese auch auf einen EC2 Server zu?

Auf dem Server soll später Ubuntu laufen mit einem Application Server (Glassfish wahrscheinlich 3.1.2.2), auf dem eine Jave EE Anwendung über REST und SOAP laufen soll, zusätzlich noch eine PostgreSQL Datenbank.

Nachtrag:
Auf den REST-Dienst kann man nur über Basic-Authentication kommunizieren, außerdem wird https verwendet.

Danke schon im Voraus :)
 
Zuletzt bearbeitet:
Da es sich bei EC2-Instanzen um voll-virtualisierte Systeme handelt, kann man sie so absichern wie jeden anderen Linux-Server auch.

Zusätzlich gibt es noch ein paar Dinge zu beachten, wenn man sein AMI nicht from scratch selbst baut. Ganz besonders wichtig ist dabei vor allem, dass man prüft welche Benutzer existieren und ob diese evtl. über eine authorized_keys-Datei verfügen. Findet man sowas, sollte man das verwendete AMI verwerfen, da evtl. Backdoors eingebaut wurden. Natürlich auch sicherstellen, dass nur die Nutzer, die es brauchen, eine Shell in der passwd haben. Ausserdem natürlich schauen welche Dienste per Default laufen und wie diese konfiguriert sind. Da ich recht viel mit EC2 zu tun habe, empfehle ich mittlerweile sich entweder auf die AMIs von Amazon zu beschränken oder sich selbst welche zu bauen.

Weiterhin empfehle ich für den Versand von System-Mails Amazons SES zu verwenden, wenn man mehr als 3 Empfänger oder mehr als 20 Mails pro Tag hat. Gibt sonst böse Mails vom Support.
 
Solltest du noexec-Temp-Verzeichnisse haben wollen, könntest du evtl. an die Grenzen von EBS stossen. ;) Ich hab das bisher als Workaround immer mittels eines lokalen NFS-Shares gelöst (d.h. NFS-Kernel-Server installieren, lokale Freigabe z.B. für /home/tmp einrichten, Verzeichnis natürlich anlegen) und das dann als /tmp über's Loopback mounten. In dem Fall nicht vergessen, dass mittels IPTables nur alle benötigten Ports nach aussen freigegeben werden und der Rest geblockt.
 
Aber jetzt bräuchte ich noch einen Rat... Ich habe mich, glaube ich, selbst ausgeschlossen. Ich wollte ein root Passwort setzen, da es keines gab und ich immer "sudo" ohne Passwortabfrage ausführen konnte. Also bin ich dieser Anleitung gefolgt:
No password prompt at sudo command - Ask Ubuntu

Also habe ich folgende Zeile auskommentiert:

ALL ALL=(ALL) NOPASSWD=ALL

(eine Zeile mit root gab es nicht)

Davor habe ich das Passwort mit "sudo su" "passwd" gesetzt. Wenn ich jetzt allerdings "sudo" ausführen will, wird ein Passwort abgefragt, wenn ich das eigentlich gesetzte Passwort eingebe, ist es falsch.

(Das sicherheitstechnische mache ich auch mehr, um mich in Systemadministration und Linux-Umgebungen einzuarbeiten.)
 
Sich auf einer EC2-Instanz einzuarbeiten ist alles andere als ein guter Plan. Im übrigen verlangt sudo das User-Passwort und nicht das von root. Wäre ja sonst ziemlich sinnlos. However... Als Admin eines Servers sollte man eigentlich die Basis-Werkzeuge eines Linux kennen und dadurch wissen, dass man mittels su und dem Root-Passwort auch dann zu root werden kann, wenn man sein sudo zerschossen hat.
 
Nachtrag: Im übrigen würde ich mir an deiner Stelle gut überlegen, ob du wirklich allen Usern sudo-Rechte geben willst oder ob du dir nicht vielleicht doch besser einen echten Admin in's Boot holst.
 
Problem behoben.

Ich wollte mich auch nur mit der Thematik vertraut machen. Nachdem die Serverumgebung (Glassfish, PostgreSQL, etc.) eingerichtet ist, wird das sowieso an die Technik weitergeleitet, die das administrieren wird. Trotzdem danke.
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben