Server Absicherung, was fehlt?

D

Dayme

New Member
Hallo Leute, ich bin neu in der "Szene" und mache das zurzeit alles noch auf einer Lokalen VM.
So, jetzt zu meinem Anliegen, ich möchte wissen auf was ich achten muss und was ich noch "besser" machen sollte.
Also die Frage ist, ob der Server ins Netz kann, oder was ich noch verbessern muss.


- Port ist nicht 22
- Man wird nach 3 Versuchen IP-gesperrt (Fail2Ban)
- SSH-Keys, diese befinden sich auf einem USB-Stick.
Diese sind nochmal mit einem 8-12 langem Passwort abgesichert.
Dies wurde auf einer Homepage generiert.
- Root-Login verboten
- Dauerhafte aktuelle Serverversion
- Auth Log wird von mir "beobachtet"


Mit der Absicherung von FTP und MySQL müsste ich mich noch beschäftigen, oder ihr empfehlt mir was :)


So, das wars auch.
Was denkt ihr fehlt?


Grüße
Dayme
 
Last edited by a moderator:
- SSH-Keys, diese befinden sich auf einem USB-Stick.
Click to expand...
Das ist nicht so berauschend, USB-Sticks sind überhaupt nicht für Ihre Zuverlässigkeit bekannt. (siehe Talk vom 30C3)

Dies wurde auf einer Homepage generiert.
Click to expand...
W.T.F.?! Prima. Jetzt sind deine privaten SSH-Keys im Gulli-Board. :eek:

Viele Grüße,
Tobias
 
manawyrm said:
W.T.F.?! Prima. Jetzt sind deine privaten SSH-Keys im Gulli-Board. :eek:
Click to expand...

Ich hab es so verstanden, daß er nur die Passphrase und nicht den Key selber auf einer Webseite, die einen Paßwortgenerator anbietet, generiert hat.


Dayme said:
Was denkt ihr fehlt?
Click to expand...
Grundsätzlich ist die Art der Absicherung stark davon abhängig, was letztendlich auf dem Server an Diensten bereitgestellt werden soll, weshalb sich hier sicher keine pauschale Antwort geben lassen kann.
Auf jeden Fall sollte man sich nur auf die wirklich notwendigen Programme beschränken und auf jeglichen Schnick-Schnack verzichten, der nicht für den Serverbetrieb notwendig ist (zB. Klicki-Bunti Oberflächen wie Plesk oder Webmin). Jede zusätzliche Software bzw. jeder zusätzlich laufende Dienst erhöht die mögliche Angriffsfläche.
Weiterhin sind auf jeden Fall Grundkenntnisse über das verwendete OS und die eingesetzte Software sinnvoll und notwendig. Es bringt nix, wenn man diverse HowTo's abarbeitet und blind Copy/Paste betreibt, wenn man nicht verstanden hat, was da passiert.
Regelmäßige Updates von System und Software sind ebenso wichtig wie das Abonnieren der entsprechenden Mailinglisten, um schnell auf neu bekannt gewordene Sicherheitslücken reagieren zu können.
 
Auf dem Server würde ein Teamspeak 3 Server laufen, eins bis zwei Gameserver und eventuell ein Webspace :)

Natürlich wurde nur das "Passwort" von dem Key generiert :>
 
Dein SSH ist sicher, da gibts nichts zu meckern.
Aber zum Rest hast du dir scheinbar noch keine Gedanken gemacht.

Die wenigsten Angreifer kommen über SSH rein (wenn nich grad das Passwort Admin123 heißt).
Viel gefährlicher ist der Webserver. Hier werfe ich mal für Apache in den Raum: mod_security, php-fcgi, Rechtekonzept.
Auf FTP würde ich, wenn möglich, verzichten und SCP nutzen.
 
Jesaja said:
Auf FTP würde ich, wenn möglich, verzichten und SCP nutzen.
Click to expand...
Würde ich nicht sagen. FTP bietet m.E. bessere Möglichkeiten sich in das Rechtekonzept zu integrieren.

Wenn es um die verschlüsselte Verbindung geht kann SSL (FTPS, nicht SFTP) eingesetzt werden.

Wenn FTP dann ähnlich wie SSH abgesichert wird (fail2ban, anderer Port etc) sehe ich hier keine Probleme.
 
Dir sollte außerdem klar sein, das Sicherheit ein fortwährender Prozess ist. Es gibt bei einem Server niemals den Punkt wo man sagen kann, ich habe fertig. Heißt im folgenden, das du in regelmäßigen Abständen auf dem Server nach dem rechten schauen mußt, logfiles auswerten usw...
Was es den SSH angeht, so sollte der zur Zeit sicher sein. Solange bis jemand wieder einen Weg findet und damit die Serverwelt unsicher macht. Die meisten Einbrüche sind aber auf irgendwelche schlecht abgesicherten Websites zurück zu führen oder verpfuschte Konfigurationen. Jeder Dienst der nach außen lauscht und schlecht oder unzureichend konfiguriert wurde, stellt ein gewisses Ziel da. Dann kommt noch ein gewisser Anteil dazu, wo sich mit Hilfe eine Trojaners/Virus zugriff auf dem Rechner des Admin verschafft wurde. Auch ein schlecht konfigurierter Gameserver kann gefährlich sein.
Sich in ein paar Mailinglisten eintragen, damit man keine wichtigen Updates verpaßt, ist bestimmt auch von Vorteil.
 
Dayme said:
Was würdet ihr mir den empfehlen, um den Webserver und den Mailserver abzusichern?
Click to expand...

Webspace mit entsprechenden Mail-Features anmieten (gibt es schon für kleines Geld), dann ersparst du dir den ganzen Verwaltungsaufwand dafür und kannst dich voll auf deine Gameserver konzentrieren.

Einen Mailserver richtig aufzusetzen, zu konfigurieren und im laufenden Betrieb zu warten ist schon eine relativ komplexe Angelegenheit (und für weniger erfahrene Admins nicht unbedingt zu empfehlen).
Ähnliches gilt für Webserver, nicht umsonst sind Webserver (und darauf laufende Scripte) beliebte Angriffsziele.

Wenn du es dir doch selber zutrauen willst, solltest du zuerst entscheiden, welche Software du für Mail-/Webserver einsetzen willst. Ich setze z.B. als Webserver u.a. Apache mit vorgelagertem nginx als Reverse Proxy ein. Als Mailserver rennt bei mir eine Postfix/Dovecot-Kombination.
Aber welche Programme du letztendlich für dich wählst, hängt vom Einsatzzweck (und sicher auch ein bissel vom persönlichen Geschmack) ab.

Als nächstes solltest du dich gründlich in die entsprechenden Dokumentationen einlesen, damit du auch verstehst, was die einzelnen Programme machen.
Dann die Theorie praktisch umsetzen, indem du in einer lokalen VM das von dir gewünschte Setup durchführst. Schauen, ob es fehlerfrei läuft und sich dann mit der Konfiguration der einzelnen Dienste auseinandersetzen. Bei der Konfiguration fängt man dann auch an, sich mit Absicherung zu beschäftigen.

Aber das Ganze braucht Zeit, Interesse und viel Motivation...weil eben nicht gleich alles am Anfang klappen wird.

P.S.: Ich weiß, daß es nicht das ist, was du jetzt hören wolltest...aber nur so wird es langfristig gut funktionieren und nur so wirst du auch Spaß an deiner Admin-Rolle haben :)
 
Last edited by a moderator:
Bei vielen Hostern wird ja FTP usw direkt mitinstalliert, da man es für das Webinterface braucht.
Somit möchte ich mich darauf vorbereiten, wie ich das absicher.
Weil wenn man das deinstalliert, geht ja vlt das Webinterface nicht mehr.
Also muss ich lernen alles abzusichern.
^^
Kann mir da jemand was empfehlen?
 
Deine Frage sind sehr allgemein. Zielführende Antworten kannst du darauf kaum erwarten.

Das Absichern eines Webservers an sich ist nicht so sehr das Problem, viel mehr das Absichern von Applikationen die darüber betrieben werden.

Wofür sollte ein Webinterface einen FTP-Server brauchen? Um die Konfigurationsdateien hochzuladen? :)

Da du dich mit der Materie erst beschäftigst rate ich dir vom Betrieb eines Email-Servers ab. Falls du es doch tun willst solltest du dich ausreichend mit den Schwachstellen vertraut machen und nicht blind einem Tutorial folgen.
 
Ich kann bestätigen, dass es extrem von der verwendeten Software, dessen Rechte, sowie weiteren Lücken abhängig ist.

Bsp. hatte ich meinen letzten kommerziellen an einen Kunden verkauften Windows 2008r2 derartig abgesichert gehabt:
- umbenennen Administrator zu admin + deaktivieren des Logins
- fake Administrator erstellen dessen Login deaktiviert war
- Nutzer mit Adminrechten erstellt welcher jedoch nur existierte
- Nutzer ohne Adminrechte aber mit RDP Rechten installiert
- RDP nur auf Localhost hören lassen
- openssh Server installiert welcher jedoch nur als Tunnel diente (login war erlaubt, shell sftp etc verboten)
- SSH Tunnel auf localhost RDP

Darauf lief dann ein IIS als Reverseproxy, sowie eine Atlassian Confluence Installation mit beigelegtem Tomcat. Java war aktuell.

Dennoch gelang es einem Bekannten meines Vaters über eine Lücke im Confluence an Daten des Tomcat zu gelangen um diesem dann Code unterzujubeln. Er schaffte es immerhin den IIS zu überzeugen Skripte mit Adminrechten auszuführen um die Firewall so zu ändern, dass RDP dann wieder von allen IP's aus erreichbar war. Hat zwar 4h gedauert jedoch für einiges Erstaunen bei der Präsentation geführt. Ich habe leider keinen direkten Kontakt zu ihm jedoch vermute ich, dass die entsprechenden Lücken noch immer existieren; er wird sie als allerletztes an die Hersteller melden denn mit Sicherheitsberatungen weltweit verdient er sein Geld.

Verbiete dem SSH noch Logins auf Protokoll 1 (sollte default sein) und arbeite mit Containern bei den Anwendungen (openVZ). Alternativ lies Dich in Solaris oder FreeBSD ein und benutze die Zones respektive Jails um alle Anwendungen voneinander abzukapseln. Ein chroot im Linux ist nicht zielführend.

Was ich auch noch empfehlen könnte wäre Knockknock für SSH sowie eine restriktiv gebaute iptables. Wer wirklich was von Deinem Server will lauscht und bekommt auch die Portknocks mit, aber 99,9% sind Skriptkiddy's welche offene Ports und dessen Anwendungen anhand der Ports erkennen.

Ausserdem empfehle ich unbedingt SELinux oder wenigstens AppArmor. Lass den Server eine Weile (ca 2-3 Wochen) im Permissive Mode laufen und analysiere jede Warnung und lege für jene entsprechende Regeln an. Benutze den Server dabei "normal" d.h. nutze Gameserver. Im Idealfall kannst Du den Server (virtualisiert/ auf einem Extrarechner @home) so erstmal laufen lassen und ihm das entsprechende Regelwerk angewöhnen. Dann setzt Du den Mode auf enforce und beobachtest akribisch die Log's. Wenn was nicht geht, schauen welche Logeinträge zu finden sind und entsprechend Regelwerk ergänzen. Most verbose way und sehr Nutzer-/Geduldsabhängig; für die meisten Bereiche völlig Overblowed. Für Kunden allerdings welche komplette Websites und Shops in Projekten im 5-6 stelligen Bereich aufsetzen lassen, wirds aber gemacht.

Mailinglisten abonieren vom Distrohersteller und jeder einzelnen Anwendung um rechtzeitig reagieren zu können.
 
Würde Plesk benutzen.
Damit denke ich wäre der Mailserver usw recht sicher.

Könnte ich den Server ins Netz stellen?
 
Nicht Plesk macht den Mailserver sicher, sondern wenn überhaupt die Einstellungen.
Ich denke ein Ok für das online nehmen wird dir keiner geben egal wie sicher alles zu sein scheint. Das bleibt deine Entscheidung und Verantwortung
 
nexus said:
Webspace mit entsprechenden Mail-Features anmieten (gibt es schon für kleines Geld), dann ersparst du dir den ganzen Verwaltungsaufwand dafür und kannst dich voll auf deine Gameserver konzentrieren.
Click to expand...
Ack!

Sortiere die Services, die du laufen lassen willst nach Wichtigkeit und Risiko und trenne die wichtigen von den riskanten.

Also z.B. eMail ist ein typischer wichtiger Dienst. Wenn der nicht geht, dann hast du ein ziemliches Problem.
Und Webserver ist ein ziemlich riskanter Dienst. Wieso wurde ja im Thread schon dargelegt.

Wichtig und riskant sollte nicht auf einem System gemischt werden. Wenn jemand deinen Webserver owned und du den dann neu aufsetzen musst, dann sollte in der Zeit wenigstens nicht deine Kommunikation unterbrochen sein.
 
Dayme said:
Würde Plesk benutzen.
Damit denke ich wäre der Mailserver usw recht sicher.

Könnte ich den Server ins Netz stellen?
Click to expand...
Du kannst den Server ins Netz stellen, wenn du es ohne Plesk einrichten kannst und dir sicher sein kannst, dass du keine Sicherheitslücke eingebaut hast.

Wenn du dann zusätzlich verstehst, was Plesk mit deinem Setup macht und du dir immer noch sicher sein kannst, dass alles passt, kannst du den Server auch mit Plesk ins Netz stellen.

So wird ein Schuh draus. In jedem anderen Fall: Nein, du kannst deinen Server noch nicht ins Netz stellen, weil du ihn nicht verstanden hast.
 
Hast du noch bisschen Verwaltung für bind, ftp-accounts, user-accounts...
Das kannst du auch über die Kosole machen.

PS: Du kannst noch Plesk aktualisieren und Dienste verwalten
 
Es gibt keine Liste von Dingen, die du machen musst. Du musst das System vollständig verstehen, also jede Config. Du musst dir selbst sicher sein können, dass du die Kiste ins Netz stellen kannst, weil du begreifst, was da warum und wie installiert ist.
 
You must log in or register to reply here.
Back
Top