Ich bin Anfänger und habe einen Server

fehlt wasgeht sogutsehr guthat geholfen (No Ratings Yet)
Loading ... Loading ...
Werbung




In vielen Foren gibt es folgenden Satz zu lesen:

“Ich habe einen Server und habe ein Problem mit diesem oder jenem. Ich bin Anfänger, also seid nett zu mir”.

Anfänger und Rootserver

Wenn eine Webpräsenz zu klein wird, muss ein Server her. Meistens kennt man sich dann doch nur mit HTML, PHP oder ein bischen MySQL aus. Man weiß, wie man eine Webseite baut, wie man Daten aus SQL holt, aber von Rootserver hat mein überhaupt keine Ahnung. So kommt meistens ein Anfänger zu einem eigenen Server.

Ist das schlimm?
Zunächst bestimmt nicht. Ein Server ist für jeden da, so lange er bezahlt wird. Aber ein angehender Root-Server Administrator muss sich trotzdem darüber im Klaren sein, dass er nun nicht nur seine Webseiten, sondern auch einen Server zu betreuen hat.
Und ein vServer oder Rootserver benötigt ebenfalls sorgfältige Aufmerksamkeit.

Aus einem Anfänger kann auch ein Server Administrator werden

Es ist in diesem Falle nicht damit getan, einen Rootserver anzumieten, ein Standard-Image a la Xampp zu installieren, seine Webseiten auf zu spielen und dann davon auszugehen, dass alles Gut ist.
Server im Internet stellen immer eine gewisse Gefaht für den Betreiber dar, zumal wenn er nichts über die Dienste weiß, die auf dem Server laufen.

Deswegen muss zunächst von jedem Server-Administrator geprüft werden, was läuft auf dem Server nach Auslieferung?

Für viele ist ein Apache Server sowie eine MySQL Datenbank notwendig.

Apache Webserver – auf was achten?

Der Apache-Server ist für die Auslieferung der Webseiten zuständig. Er dient also zur direkten Kommunikation mit dem Besucher der Webseiten. Deshalb ist er meist auch erste Anlaufstelle für Angriffe auf den Server.
Ein Server-Administrator sollte also ständig die Logfiles des Apache-Servers im Auge behalten. Diese findet man unter:

/var/log/apache2

Ungewöhnliche Zugriffe können so festgestellt werden.

Aber man kann mehr tun. Apache2 kann von sich aus auch etwas sicherer gemacht werden. Hierbei hilft das mod_security2 Modul.
Ebenfalls kann es sinnvoll sein, Webpräsenzen auf das jeweilige Verzeichnis, in dem sie laufen, einzusperren. Dies funktioniert mit open_basedir(). Somit erhält ein Angreifer, hat er ein PHP Shellscript erfolgreich hochgeladen, erstmal keinen Zugriff auf den Systembereich des Servers.

Desweiteren und auch bestimmt interessant für den Betreiber, sollte eine automatische Logfile-Auswertung vorgenommen werden. Hierzu bietet sich awstats hervorragend an. Jeder Zugriff aus dem Logfile wird ausgewertet und grafisch dargestellt. Erhöhte Zugriffe lassen sich so leicht feststellen.
Positiver Nebeneffekt, der Administrator erhält Informationen über die Zugriffe, Suchbegriffe und einiges mehr seiner Webseiten.

MySQL Server – auf was ist zu achten?

Der MySQL Server ist erstmal hinter dem Apache2 geschaltet, so dass er meist kein direkter Angriffspunkt ist. Jedoch kann das so sein, muss aber nicht. Das muss von jedem Server-Administrator geprüft werden.

Ein aktiver MySQL Server, der auf dem selben Server wie Apache läuft, sollte nur auf interne Anfragen reagieren, also Anfragen nur von localhost entgegen nehmen.

Dies stellt sicher, dass der MySQL Server von aussen nicht sichtbar ist und keinen offenen Port zur Verfügung stellt.
Ein offener Port nach aussen stellt die Möglichkeit dar, den MySQL durch Brut Force Angriffe zum einen lahm zu legen, des anderen aber auch zu hacken.

Was läuft noch so auf meinem Server, wie bekomme ich das heraus?

Kein Server läuft nur mit apache und mysql. Es sind weitere Dienste notwendig.
Eine Liste aller laufenden Dienste lässt sich mit dem Anwender “root” anzeigen:

# ps afx
PID TTY      STAT   TIME COMMAND
1 ?        Ss     0:18 init [2]
2 ?        S      0:00 [kthreadd/108]
3 ?        S      0:00  \_ [khelper/108]
85 ?        S      0:31 [init-logger]
331 ?        Ss     0:00 /sbin/portmap
407 ?        Sl     0:00 /usr/sbin/rsyslogd -c4
416 ?        Ss     0:00 /usr/sbin/atd
436 ?        Ss     0:03 /usr/sbin/cron
441 ?        Ss     0:00 /usr/bin/dbus-daemon --system
457 ?        Ss     0:08 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 104:109
545 ?        Ss     0:01 /usr/lib/postfix/master
551 ?        S      0:00  \_ qmgr -l -t fifo -u
3135 ?        S      0:00  \_ pickup -l -t fifo -u -c
553 ?        Ss     0:00 /usr/sbin/sshd
3292 ?        Ss     0:00  \_ sshd: root@pts/0
3295 pts/3    Ss     0:00      \_ -bash
3379 pts/3    R+     0:00          \_ ps afx[/code]

Und schon sieht man eine Menge Zahlen und eine Menge wirres Zeug.
Untersucht man die Liste, gibt sie einem eine Menge Informationen, beispielsweise die Zeile
1  545 ?        Ss     0:01 /usr/lib/postfix/master

In dieser Zeile steht, dass ein Dienst mit der Nummer (PID) 545 auf einem unbekannten TTY und einer STAT (?) Ss läuft, mit einer Zeit (TIME) von 0:01, der sich nennt "/usr/lib/postfix/master".

Das TTY stellt in diesem Falle eine Console, also eine aktive Benutzeroberfläche dar. Da aber dieser Dienst nicht von einer aktiven Oberfläche sondern von Linux selbst gestartet wurde, ist dies unbekannt.
Das STAT ist der Status des Dienstes. In diesem Falle steht S für Sleep.
Die Zeit bedeutet die CPU Zeit, die dieser Dienst in Anspruch nimmt. Je höher dieser Wert ausfällt, desto mehr wird die CPU beansprucht. Dienste die einen sehr hohen Wert haben, sollten genauer unter die Lupe genommen werden.
Nun der Dienst "/usr/lib/postfix/master" bezeichnet das Programm. In diesem Falle ist es "postfix", ein Mailprogramm.

Und schon wissen wir, dass wir das nächste Programm checken müssen, nämlich Postfix.

Postfix stellt ebenfalls eine direkte Verbindung in das Internet dar. Hier melden sich Mailserver, die Mails an Email-Empfänger abliefern wollen, ab und zu ist dieser Empfänger dem Server aber nicht bekannt. Ein falsch konfigurierter Server kann dann schnelll zu einem "Open-Relay-Server" werden.

Open Relay Server - auf was ist zu achten?

Ein Open-Relay-Server ist ein Email-Server, der erstmal einfach alles annimmt und dann weiter verteilt. Hierbei liefert ein unbekannter Server Emails ein und der eigene Server versucht dann, diese an den richtigen Server weiter zu verteilen. Was dabei dann heraus kommt, wird meist als "Spam-Schleuder" bezeichnet, denn das Internet besteht nicht nur aus netten Menschen, die echte Emails mal eben an einen Freund weiterleiten möchten.

Eine Vielzahl der im Internet verkehrenden Emails sind "Spam-Mails". Wenn ein Server zu einem Open Relay Server geworden ist, wird dieser missbraucht, diese Spam-Mails weiter zu leiten.

Erkennt ein Server-Administrator, dass er eine vielzahl von noch auszuliefernden Emails auf dem Server hat, oder bekommt sehr viele "nicht-zustellbar-Emails" zurück, so muss er seinen Server auf einem Open-Relay-Server prüfen.
Auch hier lohnt sich ein Blick in das Logfile

/var/log/mail.log

Ein solcher Test zeigt einem Administrator, ob der eigene Server bereit ist, fremde Emails weiter zu leiten. Ist er dies, kann das durchaus problematisch werden.

Die Folgen von versenden in Spam kann in Deutschland zu Abmahnungen führen.

SSH Server - auf was ist zu achten?

SSH? nie gehört!
Kommt man frisch von Windows, wird einem SSH kein Begriff sein. Unter Windows hatte man seine Maus und konnte auf Bildchen klicken. Unter Linux ist dies anders (mal abgesehen von Unbuntu - wobei die grafische Oberfläche nicht sehr sinnvoll auf einem Server ist, der seine Ressourcen für andere Zwecke einsetzen sollte).

Unter Linux gibt es eine Kommando-Shell. Diese Shell wird normalerweise per Telnet oder eben per SSH angesprochen - ähnlich wie DOS.

Ein SSH Zugriff ist das erste, was auf einem frisch installierten Server vom Provider zur Verfügung gestellt wird und womit man Gewalt über seinen Server erhält.
Es gibt verschiedene SSH Terminal-Programme, das beliebteste wird allerdings "Putty" sein. Man läd also Putty aus dem Internet, trägt bei Hostname seinen Servername ein, wählt SSH und "Open". Schon wird das Fenster schwarz und es blinkt nach einer Begrüßung nach Eingabe von Username und Passwort (stand doch in der Email vom Provider) der Cursor.

Das war ja einfach! Jetzt weiß ich auch, was SSH ist.
Was SSH macht, ist nun bekannt. Allerdings hat dies auch Auswirkungen. Jeder, der das Passwort hat, kann sich auf den Server einloggen und hat somit volle Kontrolle über den Server.
Und viele, die das Passwort nicht haben, werden es versuchen!
Hier liegt das Problem. Es gibt automatische Programme, die Server ausfindig machen, prüfen, ob hier ein SSH Server auf Port 22 liegt und anfangen, sich mit verschiedenen Usernamen und Passwörten auf den Server zu verbinden.
Diese sogenannte "Brut-Force-Attacke" wird so lange wiederholt, bis der Hacker eine Kommandoeingabeaufforderung erhält - somit ist er Herr über den Server.

Was kann man dagegen tun?
Zunächst auch hier wieder die Logfiles prüfen

/var/log/syslog

Man kann aber den SSH schon von vornherein mit bestimmten Techniken sicherer machen.
Die eine Technik liegt darin, den Port des SSH Dämons zu ändern

/etc/ssh/sshd_config

Hier kann man den Port beispielsweise auf 35353 setzen

Port 35353

und den Server neu starten

# /etc/init.d/sshd restart

Man sollte die aktuelle Konsole nicht beenden, sondern eine neue Putty Sitzung öffnen.
Der neue Port muss in Putty natürlich auch geändert werden (statt 22 muss man 35353 eintragen).

Auch kann man den SSH verbieten, überhaupt nach einem Passwort zu fragen, sondern nur Zugriffe mit einem vorher definierten RSA-Key zulassen. Somit erhält keiner mehr Zugriff auf den Server, der diese Key-Datei nicht besitzt.

Möchte man den Port nicht ändern oder keine Key einsetzen, so gibt es noch Programme, die zu häufige Zugriffe auf den SSH Port bemerken und diese dann sperren, beispielsweise denyhost.

Es gibt noch viele weitere Sachen zu bedenken. Ein Server-Administrator muss ich mit jedem aktiv auf seinem Server laufenden Prozess auseinander setzen.
Die sichersten Prozesse sind immer diese, die nicht laufen - unnötiges muss also abgeschaltet werden.

Folgen - mein Server wurde gehackt, was kommt auf mich zu?

Bestenfalls garnichts.
Jedoch, jeder Server-Administrator ist für das, was sein Server macht, verantwortlich. Es können Schadensersatzansprüche folgen, Abmahnungen und wenn illegale Sachen mit dem Server angestellt wurden, weit aus mehr. Stellt man fest, dass der Server gehackt wurde, sollten zunächst alle Dienste beendet werden und Beweise gesichert werden. Hier sollte man, sofern man nicht fit darin ist, überlegen, professionelle Hilfe in Anspruch zu nehmen.

Nachdem die Beweise gesichert wurden, sollte ein Reinstall gemacht werden und geprüft werden, wie es zur Serverübernahme gekommen ist. Dann kann das Sicherheitsloch gestoft werden und der Server wieder in Betrieb genommen werden.

bisherige Suchbegriffe:

  • server einrichten anfänger
  • root server für dummies
  • Datenbank auf eigenem Sever für anfänger
  • server administration für anfänger
  • ssh angriff abmahnung an domaininhaber
  • was für ein server habe ich


Werbung


Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *


*

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>