Angriffsmethoden auf Rootserver

NemesisFS

Lt. Commander
Registriert
Sep. 2008
Beiträge
1.294
Hi,
ich werde mir bald einen Rootserver mieten. Ich habe mir schon einiges zum Thema durchgelsen, vorallem auch zum Thema sicherheit und außerdem bin ich schon eine Weile Linuxuser, sodass ich denke dass ich der Aufgabe gewachsen bin.
Nun möchte ich mich an dieser Stelle nochmal schlau machen, auf welche Weise ein Angreifer meinen Root als Ziel benutzen kann, evtl kommt ja etwas dabei raus, was mir so noch nicht bewusst war.

gruß,

nemesis

EDIT:
Was ich mit dem Server (debian) vorhabe ist so grob folgendes:
-ssh
-openvpn (authentifizierung über pgp)
-ftp (auf das openvpn netz beschränkt)
-evtl Webserver
-mailserver im Konten bei verschiedenen Providern zusannemzufassen
(-evtl gameserver)

alle dienste für weniger als 20 nutzer, auf ein configtool wird aus ressourcen gründen verzichtet
 
Zuletzt bearbeitet:
Hi,
das hängt natürlich auch gewaltig davon ab was du mit diesem Server denn anfangen willst. Ich bin kein Experte, aber was mir so spontan einfällt:

- Betriebssystemebene: Womit du rechnen musst, sind andauernde automatisierte Portscans und Bruteforce-Attacken, besonders gegen den ssh-port. Insbesondere wenn dieser auf seinem Standardport ist. Du kannst den port verlegen, z.B. >50000. Damit laufen schon mal die andauernden Attacken von Scriptkiddies mit irgendwelchen Toolkits ins Leere. Das ist aber security through obscurity und damit kein wirklicher Schutz, zumindest nicht gegen jemanden der es wirklich drauf anlegt. Was man vielleicht wirklich tun sollte, ist die interaktive Anmeldung als root zu verbieten, so dass man sich erst als normaler user anmelden muss und dann gegebenenfalls mit sudo und su arbeitet. Das kann ein zusätzliches Stück Sicherheit verschaffen. Passwörter sollten natürlich möglichst lang und komplex sein, oder besser gleich gar keine Anmeldung per Passwort, sondern vielleicht über public/private key. Was sich natürlich von selbst verstehen sollte, ist keine unsicheren daemons wie ftp und telnet zu starten, damit man da keine Angriffsfläche bietet. Stattdessen sftp/scp und ssh verwenden. Du kannst deine Firewall, also z.B. iptables so konfigurieren, dass Pakete gedroppt werden, statt sie zu rejecten, wie z.B. icmp von pings. Das kann auch gegen Portscans "schützen", da sind wir aber wieder bei security through obscurity.

- Mailserver: Wenn du auf der Kiste einen Mailserver betreibst, dann wird man versuchen den als relay zum spamversand zu missbrauchen. Stell auf jeden Fall sicher, dass du keinen open relay produzierst, dass dein Mailserver also nicht alles was reinkommt kommentarlos weiterleitet. Also über entsprechende Authentifizierung, besonders für smtp. Um die Spamflut auf eigene Postfächer einzudämmen würde ich Greylisting betreiben und Blacklists abonnieren. Ausserdem vielleicht Spamassassin und ähnliches einsetzen.

- Webserver: Wenn du Webseiten hostest bietest du zusätzliche Angriffsfläche. Das ist aber ein Kapitel für sich. Nur in Kürze mögliche Sachen die dir passieren können, besonders wenn im Hintergrund noch Datenbanken laufen (dynamischer content): Versuche die Webseite zu defacen, MySQL-Injection (Versuche z.B. über Formularfelder die Datenbank zu verändern, indem zum Beispiel mit einem Semikolon versucht wird einen zweiten SQL-Befehl anzuhängen), HTML-Injection (XSS, XSRF,...), Versuche cgi-skripte zweckzuentfremden, Versuche Fehlermeldungen zu produzieren um dadurch ein möglichst genaues Bild von der verwendeten software zu bekommen (OS, Apache, PHP,...) und dadurch evtl. ungefixte Exploits oder andere Schwachstellen auszunutzen. Worauf du achten musst: Aktuelle Versionen einsetzen, vorsichtig sein mit dateirechten und besonders mit cgi-scripten, bei Formularen und anderen Freitextfeldern alles sauber escapen uvm.

- IRC: IRC-Server werden gern gehighjackt, um da haufenweise Bots in Channel zu hocken, die man dann für den Austausch von Warez über DCC oder auch für DOS-Attacken benutzen kann.

Allgemein kannst du natürlich immer Opfer von DOS/DDOS und allen Abarten davon werden, da lässt sich aber wenig dagegen tun. So lang du nicht haufenweise Leute verärgerst oder ein sehr lohnendes Ziel für sowas bist wird das wohl aber nicht passieren.

Ohne zu wissen was du genau vorhast mit deinem Server, wird es schwierig da tiefergehende Hinweise zu geben ohne hier gleich eine komplette Doktorarbeit zu verfassen. Mehr fällt mir dazu jetzt auch nicht ein, ohne noch mehr ins Blaue raten zu müssen. Sei einfach vorsichtig und konfiguriere auf Sicherheit, geh möglichst immer nach dem Minimalprinzip (nur das läuft was auch wirklich gebraucht wird), halte deine Pakete aktuell, gib keinen Leuten Benutzeraccounts denen du nicht hundertprozentig vertraust, sorg dafür dass Apache seltsame Anfragen mit nem nichtssagenden 500er quittiert, sieh zu dass Webseiten und andere Sachen nicht zusätzliche Sicherheitslücken aufreissen, fang Exceptions ab damit nicht gleich immer für jeden Fehler ein kompletter Stacktrace angezeigt wird,...
Und, ganz wichtig: Sei dir sicher was du tust und konfigurierst. Ich würde von Konfigurations- und Hostingtools wie Plesk, Confixx usw. abraten. Erst mal hast du hier einen zusätzlichen Angriffspunkt und zweitens ist es besser selbst zu konfigurieren, statt das einer Oberfläche zu überlassen, die man nicht völlig überblickt.

Gruß
Tenthar
 
Zuletzt bearbeitet:
W: Angriffsmethoden auf Rootserver

erstmal vielen dank für die mühe, Tenthar, die du dir mit der Wall of Text gemacht hast.

Was ich mit dem Server (debian) vorhabe ist so grob folgendes:
-ssh
-openvpn (authentifizierung über pgp)
-ftp (auf das openvpn netz beschränkt)
-evtl Webserver
-mailserver im Konten bei verschiedenen Providern zusannemzufassen
(-evtl gameserver)

alle dienste für weniger als 20 nutzer, auf ein configtool wird aus ressourcen gründen verzichtet

(das obere wird in den ersten post hereingeeditet)

ich frage mich, ob es sinnvoll ist eine wirkliche firewall einzusetzen, da ungenutzte ports in einer sicheren config ja ohnehin geschlossen sind. kleinere tools um bruteforce zu unterbinden und die ips per blacklist zu sperren sollte es ja geben.

Außerdem habe ich von portknocking gehört, mit dem sollte sich der ssh server doch eigtl relativ gut absichern lassen, oder?

außerdem habe ich nicht verstanden was mysql defacen bedeutet und über google auf die schnelle nichts dazu gefunden...
 
sicherlich auch eine sinnvolle maßnahme : ssh und ftp ports nicht auf standard laufen lassen. wenn du openvpn benutzen moechtest, bietet es sich an kritische komponenten nur aus dem ovpn netz erreichbar zu machen.
 
ich hatte auch schon daran gedacht, ssh über pgp zu sichern oder nur über openvpn zuzulassen, allerdings möchte ich die möglichkeit haben auch an rechnern, die nicht mir gehören zB bei freunden auf die daten zugriff zu haben. deswegen hatte ich an portknocking gedacht, davon habe ich schonmal gehört.
 
Du kannst dir auch mal fail2ban oder denyhosts anschauen. Das sind Programme gegen Brutforce Attacken z.b. für ssh. Die Sperren dann IP-Adressen die zu viele fehlversuche gehabt haben anhhand von den Log Dateien. Ein guter Schutz, außer der Angreifer macht das über ein Bot-Netz ;)

Am besten ist wenn du dir auch mal die "Anleitung zum Absichern von Debian" durchliest.
 
Zuletzt bearbeitet:
Nummer eins sind SSH Skriptkiddies. Also wer eine über öffentliche IP SSH zugänge mit root login hat ist selbst schuld. Dann gibt es da Sicherheitsskripte die BruteForce machende IPs blacklistet. Evtl Iptables.. (Fireweall)und dazu http://de.wikipedia.org/wiki/Intrusion_Detection_System
Ping würde ich abstellen. Webserver mit PHP und DB Backends sind angreifbar. Generell gilt hier kein XAMPP, denn da sind die configs nur fürs Entwickeln angepasst. Die distris haben relativ sichere Configs und Versionen mit Sicherheitsupdates über den Baguettemanager. Schlecht Programmierte PHP Anwendungen und evtl veränderte Policies die PHP in wichtigen Verzeichnissen das Schreiben ermöglicht.

Mailserver kann komplex sein da die meisten IPs auf der Spamliste stehen. Kann sein das diese IP erst einmal entsperrt werden muss. Das Mailserver sollte kein sendmail sein, da zu komplex. Postfix und Exim4 (Debian Std. Exim4) sind super.

Generell eine sichere Distri wo nicht der Kernel schon Angriffsziel ist wie bei Ubuntu OpenSuse und Fedora. CentOS/RHHEL, Debian, SLES sind sicher, oder gelten als Sicher.
 
Zuletzt bearbeitet:
denyhosts und fail2ban sind notiert hatte auch schonmal davon gelesen...

ping abstellen heißt, pakete zu dropen, nicht wahr? das hiflt doch vor allem gegen portscans, nicht wahr?

ich hatte vor den server in etappen aufzubauen (und evtl einen blog drüber schreiben) und mir für jede soviel zeit zu nehmen, bis es vernünftig läuft, also zunächst server &ssh sichern, alle anwendungen die vorinstalliert sind wieder runternehmen, openvpn, user&gruppen erstellen, speicher via ftp freigeben, mailserver einrichten und danach auf zum webserver.

Die letzten beiden Punkte sind wahrscheinlich die schwierigsten, da ich denke, dass, abgesehen von scripts die ich vor habe ins leere laufen zu lassen, die gefahr durch angriff auf den AMP part des servers die größte gefahr droht, außerdem habe ich wenig erfahrung mit webservern. einen mailserver habe ich schon versucht lokal aufzusetzen und mich daher schon in die config eingelesen, ich werde zunächst postfix+cyrus (oder dovecot) installieren und dann mit spam/virenfiltern aufrüsten, ich denke die gefahr eines open relays kann ich unterbinden.

Wg. der Distris hatte ich eigentlich vor auf Debian zu setzen, da sehr beliebt in dem anwendungsgebiet, aber auch CentOS kann ich mir vorstellen. Ubuntu und OpenSuse fallen für mich flach, da ich die für Consumerdistris halte, und damit nicht so brauchbar wie die beiden oben genannten
 
naja ping abstellen: be diversen hostern wird darüber ermittelt, ob die kiste noch alive ist. wenn da nix mehr ankommt, rennt da immer n techniker zu dem entsprechenden rack, oder remote neustarts werden ausgelöst.

was die gezielte gefahr fuer einen server angeht: da wird auch viel übertrieben. wenn du nicht gerade ne mega grosse webseite betreibst, oder mega bekannt, kommt höchstens mal nen portscan vorbei und dann ein halbherziger versuch, dass passwort zu ermitteln. das zumindestet betreffend ftp / ssh. seit ich die ports weit nach hinten verlegt habe ist auch nie wieder was in den logs aufgetreten. vor ddos braucht man sich als kleiner privater betreiber nicht fürchten oder einem geszielten hackerangriff.
meiner meinung nach. mailserver ist freilich etwas anderes, denn da ist ja von der standardconfig schon alles offen. schnell landet man auf den RBL listen und dann kann man selbst auch nicht mehr mailen. ssh nur per openvpn sollte man ja auch nicht machen. fällt die verbindung aus, wars das mit der kontrolle. andere kritische dienster da eher kein problem.
 
Zuletzt bearbeitet:
Du kannst dich auch mal bei deinen Hoster informieren, was er dir raten würde bzw. für was er schon vorgesorgt hat!
Im gleichen Schritt könntest du das mit den Ping nachfragen! Wäre da genauso vorsichtig wie BasCom mit den Ping abschalten.

Verdammt wichtig ist auch das aktualisieren der Software, das nicht irgendwelche alte Versionen mit Bugs vorhanden sind!
 
Zuletzt bearbeitet:
Das meiste wurde mittlerweile schon gesagt. Debian ist eine sehr gute Wahl für einen Server, von Ubuntu oder Suse würde ich die Finger lassen. Der Tradeoff dafür ist, dass du bei Debian nie die neuesten Pakete zur Verfügung hast, sondern stattdessen ältere spezielle Debian-Versionen. Solltest du also mal partout eine neuere Version brauchen als im Repository verfügbar musst du selbst Hand anlegen.

Für den Mailserver habe ich gute Erfahrungen mit Postfix in Verbindung mit Dovecot gemacht. Ich habs jetzt nicht bis zum Ende durchgelesen, aber diese Anleitung wirkt ganz gut auf mich: http://holl.co.at/howto-email/

Denyhosts und fail2ban sind ein guter Hinweis, fail2ban habe ich auch schon testweise benutzt.

Eine wirkliche Firewall ist ja bereits mitgeliefert, iptables ist völlig ausreichend.

Portknocking ist eine gute Sache, für Debian gibt es da normal das knockd Paket. Zumindest hieß das früher mal so. Wenn du das sauber konfigurierst und die Firewall auch, dann bist du schon ein gutes Stück weiter.

Das defacen hab ich missverständlich ausgedrückt, das bezog sich nicht zwingend auf SQL. Eine Webseite defacen ist eigentlich nur ein anderer Ausdruck dafür das Aussehen der Webseite unberechtigterweise zu verändern. Die Gefahr besteht wirklich nur wenn deine Webseite ein lohnendes Ziel ist.
http://en.wikipedia.org/wiki/Website_defacement

Sobald du Apache, PHP, Datenbanken etc. laufen hast wirds interessant. Ich würde mir auf jeden Fall einige HowTos zum Hardening von Apache durchlesen, d.h. welche Module man nicht laden sollte und was für Einstellungen man auf jeden Fall vornehmen sollte. Da gibts einiges zu wissen. Grundsätzlich ist der Apache aus dem Debian-Paket aber schon mal einigermaßen konfiguriert. Was du dir noch anschaun kannst:
Der Hardening PHP Patch: http://www.hardened-php.net/hphp/
Oder zumindest Suhosin: http://www.hardened-php.net/suhosin/index.html (binärkompatibel zu Standard-PHP)
Ich bin mir spontan nicht mehr sicher, da es schon länger her ist dass ich einen Debian-Server "from scratch" aufgesetzt habe, aber ich glaube Suhosin könnte sogar schon im PHP-Paket von Debian enthalten sein.
 
also ich wuerde dir statt dem apache2 den lighttpd and herz legen. ist ein wenig schlanker und wird durch module ergänzt. ich selber habe auch gewechselt. aber das mag ja dein geschmack sein. ist von den konfig dateien aufjedenfall ein wenig anders einzurichten.
 
okay, vielen dank für die vielen tipps, ich melde mich hier, wenn weitere probleme auftauchen
 
Tenthar schrieb:
Das meiste wurde mittlerweile schon gesagt. Debian ist eine sehr gute Wahl für einen Server, von Ubuntu oder Suse würde ich die Finger lassen.

dummes geschwätz.. debian ist nicht per-se sicherer als ubuntu. sobald was öffentlich wird fixed ubuntu das sehr flott. nur weil neuere paketversionen verwendet werden macht es das auch nicht unsicherer. "alt, getestet und ausgereift" in debian bezieht sich in erster linie auf funktionen, und nicht auf sicherheit!

worauf du in jedem fall achten solltest ist dass die dienste korrekt konfiguriert sind. alles was nicht extern sichtbar sein sollte ist durch eine firewall zu schützen.
kritisch für angriffe auf rootserver sind häufig unsichere passwörter. achte darauf, dass du ne sichere passwort policy vorgibst (dafür gibts extra module die unsichere passwörter ablehnen!).

außerdem finden angriffe sehr häufig über webapplications statt. also wenn du ein php cms oder sowas laufen hast solltest du immer drauf achten da die aktuelle version laufen zu haben. ist ein angreifer erstmal lokal auf dem system ist es meistens kein zu großes problem mehr sich lokal root-berechtigung zu holen.

generell gilt: nur soviele dienste wie unbedingt nötig. jeder dienst vergrößert die angriffsfläche.
 
Nur als Tipp, man sollte es auch nicht immer übertreiben und sich so mit Arbeit/Umständen überhäufen, denn die Gefahr das ein privater Root nun von jemandem der sich wirklich auskennt exzessiv angegriffen wird ist wohl denkbar gering .... Daher genügt es m.M.n den Server gegen Scriptkiddies bzw das ganze Randomzeugs abzusichern.
.
 
Stimme Pandora zu.

Ich bin der Meinung bei einen privaten Server braucht man keine Firewall, da reicht fail2ban.
Dazu noch ssh-Port ändern + root Login bei ssh deaktivieren + sichere Passwörter reicht für das erste.

Wenn du dann lustig bist, kannst du immernoch ne Firewall konfigurieren.
 

Eine Firewall sollte man immer verwenden.. oder zumindest die Dienste so einrichten, dass sie nur auf 127.0.0.0/8 abhören. Sonst "vergisst" man mal eben dass z.B. der MySQL nach außen offen ist oder ähnliches. Da brauchst du kein Profi zu sein um sowas zu finden.
 
Zuletzt bearbeitet von einem Moderator:
NemesisFS schrieb:
ich frage mich, ob es sinnvoll ist eine wirkliche firewall einzusetzen, da ungenutzte ports in einer sicheren config ja ohnehin geschlossen sind.
Brauchste nicht. Sobald dir ein Grund einfällt, kannst du sie ja jederzeit nachrüsten.

NemesisFS schrieb:
Außerdem habe ich von portknocking gehört, mit dem sollte sich der ssh server doch eigtl relativ gut absichern lassen, oder?
Gegen was denn? Brute Force auf Passwörter? Da muß man schon irre doofe Passwörter wählen, da ein Angreifer nicht schnell viele durchprobieren kann. Per
social engineering' gewonnene Passworte? Dann hast du sowieso verloren. Wenn du den Nutzern nicht zutraust, ordentliche Passwörter zu wählen, läßt du niemanden per Passwort rein sondern ausschließlich per ssh mit PubkeyAuthentication. Vor eine aktuelle OpenSSH in Standardkonfiguration (also ganz ohne Frickelei) brauchst du nicht noch irgendwelche künstlichen Hürden davorbauen.

NemesisFS schrieb:
ping abstellen heißt, pakete zu dropen, nicht wahr? das hiflt doch vor allem gegen portscans, nicht wahr?
Hilft gegen gar nichts. Kannst ein rate limit dafür (oder für sämtlichen ICMP-Verkehr) festlegen, wenn dein Spieltrieb so ungemein stark ist.

Ich habe den Eindruck, du zerbrichst dir über die falschen Sachen den Kopf, was die Absicherung betrifft. Kümmere dich lieber um eine vernünftige Konfiguration der angebotenen Dienste (ssh, mail, vpn, ...) statt vor jeden Dienst noch irgendwelchen obskuren Kram zu schalten und das ganze Ding unnötig komplex zu machen. Weniger ist mehr.

Ich vermute mal, dass dein Rechner nicht so interessant ist, dass sich massenhaft professionelle Cracker wochenlang mit ihm auseinandersetzen werden. Hast du zu Hause am Eingang deiner Wohnung eine 30cm dicke Stahltür verbaut und einen breiten Wassergraben davor? Nein? Warum nicht? Weil es grober Unfug wäre? Eben! Überleg dir bei dem Rechner, was zu dessen Absicherung notwendig und sinnvoll ist, nicht was durch erhöhte Komplexität maximal möglich ist.
 
das wäre völlig übertrieben... ich mähe meinen rasen nicht, sodass vor meinem haus jede menge gefährliche pokemon rumlaufen! das hält alle einbrecher fern...

inzwischen denke ich mir auch dass ich übertriebene sorge hatte, aber wenn man in ein paar anderen foren eine serverfrage stellt kriegt man sofort antworten der marke "wenn du keine ahnung hast, lass es" oder "nicht noch ein zombie" an den kopf geworfen, daher meine vorsicht :D
 
Hat da jemand vielleicht eine Buchempfehlung was Sicherheit für Root Server mit Debian angeht? Also für "Normal-Sterbliche" Benutzer, die wirklich nicht mehr machen als hier im Thread beschrieben. Ein Buch für Sicherheit auf Geheimdienstebene brauche ich dann doch nicht :D
 
Zurück
Oben