RootForum Community

Hallo!

Da mir vor einigen Wochen mein Rootserver geknackt wurde und ich dadurch unschön auf mein bis dato dilletantisch zusammengeschustertes Sicherheitskonzept aufmerksam gemacht wurde möchte ich jetzt, bevor der Server überhaupt wieder auch nur 1 Sekunde ans Netz geht ein durchdachtes Sicherheitskonzept erarbeiten. Dafür sollen folgende Rahmenbedingungen gelten:

1. Mit ist klar, dass ein Sicherheitskonzept kein Ziel sonden ein Prozess ist, der fortlaufend an die aktuellen Bedingungen angepasst werden muss und "lebt". Daher soll das hier kein statischer Entwurf sein, nach dem Motto: "Einmal drüber nachgedacht, wird in Zukunft schon nix mehr passieren!" Absolute Sicherheit ist eh ein trügerisches Terrain, auf dem ich mich nie wieder sehen möchte.

2. Alle im folgenden genannten Punkte haben sich jetzt durch intensive Recherche in diesem Forum, sowie umfangreiche Fachlektüre ergeben, ich hoffe, dass ich dabei einigermaßen sinnvolle Schritte erarbeiten konnte.

3. Ich hoffe dass ich mit einigen Punkten bei meinen Vorschlägen nicht all zu sehr in einige Fettnäpfchen dieses Forums trampel, es ei mir verziehen! Gleichzeitig bin ich an einer konstuktiven Kritik interessiert und weniger daran, aufgrund von Grlaubenskriegen (z.B. Firewall) gebasht zu werden.

Vorab vielleicht nich die Eckdaten des Servers:

Dedizierter Linux-Rootserver in einem Rechenzentrum. 256 MB RAM, 10 GB Platte. Auf dem Server werden folgende Dienste laufen: Im Ürinzip ein LAMP-Setup, da ich viel CMS-Systeme einsetze, die auf PHP/MySQL basieren, sowie ein TeamSpeak2-Server und ein UnrealTournament 2004-Server.

Hier also meine einzelnen Punkte die das erste Sicherheitskonzept verdeutlichen sollen. Ich verzichte an dieser Stelle bewust auf einzelne Punkte in dem jeweiligen Configs und möchte da später evtl. an anderer Stelle genauer eingehen.

-------------------------------------------------------------------------


I: Konsequente Verlegung der Administration auf eine Shell, Verzicht auf GUIs

Ich habe bin jetzt gelegentlich aus Faulheit und Unwissenheit die hauptsächliche Konfiguration einiger Dienste per Webmin erledigt. An sich eine nette Sache nur passier da viel "unter der Motorhaube". Aus diesem Grund möchte ich die Dienste die ich verwende ausschließlich über eine SSH-Konsole administrieren. Das bezieht sich z.B auch auf den MySQL-Server und soll gerade da auch einen Lerneffekt haben, da ich mich so zwangsläufig auf einer anderen Ebene mit SQL auseinander setzen muss ohne auf Admin-Tools wie Webmit oder phpMyAdmin angewiesen zu sein.

II: Absicherung von SSH

Die Autentifizierung mit dem SSH-Server erfolgt ausschließlich über Public Keys. Diese Keys sind auf einem USB-Stick gespeichert, der nur zu administrativen Zwecken an den PC angesteckt wird. Zusätlich möchte ich den Zugriff auf den Server (nur für SSH) auf den deutschen IP-Bereich eindämmen. Das schützt natürlich nicht davor wenn jemand in China einen deutschen Server knackt und damit meine Maschine DoS't aber es schränkt die möglichen Zugriffe stark ein. Ausserden grenze ich den Login auf einen einzigen nicht-root-user ein. Werde regelmäßig die Keys tauschen und allen anderen Usern auf meinem System die Shell-Rechte entziehen.

III. Einsatz einer Firewall

Den Einsatz einer Firewall möchte ich darauf beschränken, dass alle nicht von Diensten genutzen Ports also (80/22/443 etc) von "innen" immer geblockt werden. Das soll Würmer und ähnliche Bedrohungen einschränken, da diese ja gerne auf Ports senden, die nicht für Standarddienste genutzt werden. (Mit Ausnahmen natürlich) Ich weiß, dass der Einsatz einer Firewall nach außen auch problematisch sein kann, daher möchte ich nur eindämmen, das jemand der Zugriff auf die Maschine bekommt erstmal nur erschwert Zugriff nach außen bekommt. (Stichwort "Nach Hause senden")

IV. Kompletter Verzicht auf FTP

Dieser Punkt erklärt sich von selber, nach der Logfileanalyse ergab sich, dass ein geknackter ProFTPd die Einsteigsluke zum Server war. Wenn überhaupt Daten hochgeladen werden dann ausschließlich über SCP.

V: HTTP nur über SSL

Da ich viele CMSe benutze die von Haus aus kein Login per SSL ermöglichen möchte ich gerne sämtlichen Webtraffic über SSL laufen lassen. Ich stelle mit das so vor das alle Zugriffe über Port 80 verschlüsselt stattfinden. Davon verspreche ich mir, dass Passwörter und Userdaten auf Webformualen (z.B. der Login in einem Forum) nicht mitgehört werden können.

VI: Regelmäßigere Audits

Ich möchte mich mit Nessus vertraut machen und damit mein System regelmäßig auf Sicherheitslücken "abklopfen" und diese natürlich so schnell es geht patchen oder vorrübergehend deaktivieren. Außerdem werde ich noch mehr als bisher rkhunter und chkrootkit einsetzen.

VII: Aktivere Informationsbeschaffung

Mein bisheriges Sicherheitskonzept bestand hauptsächlich darin, fast täglich ein apt-get update/upgrade laufen zu lassen und das System so aktuell wie möglich zu halten. Ich werde in Zukunft mehr in sicherheitsrelevanten Foren nach aktuellen Exploits etc. Ausschau halten, so dass sich meine Reaktionszeit auf solche Bedrohungen verkürzt und ich nicht das Handeln der jeweiligen Package-Maintainer abwarten muss. Das betrifft natürlich auch und ganz besonders die eingesetzten CMS-Systeme (phpBB, Yoomla, Clansphere etc.) Auch hier will ich deutlich mehr hinter den aktuellen Patches hinterher sein. Dazu gehört natürlich sich auch vor dem blinden installieren eine auf den ersten Blick tollen PHP/MySQL-basieren Website diese aktiver auf Sicherheitslecks zu prüfen und bei Bedenken komplett darauf zu verzichten.

VIII: chroot-ten nicht-sicherer Dienste

Der Unreal-Server sowie der TS2-Server sollen in einer chroot-Umgebung laufen um auch hier die Gefahr etwas einzudämmen. Ich weiß, dass chroot keine absoltute Sicherheit bietet (gibt es ja eh nicht...) aber ich möchte ein mehrschichtiges Sicherheitskonzept aufbauen und da gehört das absichern nicht-sicherer Anwendungen aus meiner Sicht dazu.

IX. Einsatz von bastille und/oder ähnlichen Tools.

Ich möchte den Server mit Einsatz von bastille härten und natürlich alles sinvolle manuell ändern, dass bastille nicht abdeckt. Dazu gehört nur als Beispiel, dass keinerlei Security-Tools (nmap, ping, traceroute etc.) auf dem Server zu finden sind, da diese quasi das Handwerkszeug für einen Angreifer sind, wenn er erst mal auf der Maschine ist. Dazu gehört auch der gänzliche Verzicht auf Compiler, wget und ähnliche Tools. Vorschläge was man hier noch machen könnte nehme ich dankend entgegen.

X: Aktive Logfile-Analyse

Bis jetzt habe ich alle Jubeljahre mal in die Logfiles geschaut. Das Problem bei dem letzten Einbruch war dass ich einfach erst dann die verdächtigen Einträge in den Files gesehen habe, als die Maschine schon kompromittiert war. Das ist eindeutig zu spät. An dieser Stelle hätte ich gerne einen Tip, für ein Tool dass die Logfile-Auswertung etwas übersichtlicher gestaltet (Sowas wie Code-Highlighting in vim. Stelle mir das so vor: Warnings weren rot hervorgehoben etc...)

So, jetzt bluten die Finger und ich habe auch erst mal keine weiteren Ideen und bin gespannt auf Eure Meinungen und Vorschläge. Vielleicht zum Schluss noch eine Anmerkung: Ich habe durch diesen Hack meines Server eine Menge Lehrgeld bezahlt. Selbsteinsicht ist ja bekanntermaßen der erste Schritt zur Besserung, daher wird der Server auch erst dann wieder online gehen, wenn alle Schritte die ich hier beschrieben habe, sowie Eure Verbesserungsvorschläge in die Tat umgesetzt wurden.

Viele Grüße

Nico

noiz wrote: ...Dieser Punkt erklärt sich von selber, nach der Logfileanalyse ergab sich, dass ein geknackter ProFTPd die Einsteigsluke zum Server war...

Bitte mal genauer beschreiben.

Hallo noiz,

erstmal begrüße ich deine Umsicht und habe doch gleich mal (wenn auch ein wenig aus Schreibfaulheit um diese Uhrzeit ;) ) dein Konzept "auseinander genommen" und nach besten Willen kommentiert. Ich hoffe, es hilft dir weiter.

noiz wrote:I: Konsequente Verlegung der Administration auf eine Shell, Verzicht auf GUIs

Ein phpMyAdmin das via SSL auf http://www.example.org/d41d8cd98f00b204 ... ef6688ba7/ erreichbar ist zu hacken ist auf Grund der URL nahezu unmöglich. Wenn du eh USB benutzt bzgl. des Private Keys, kannst du den Link direkt dort abspeichern. Eine Administrations per SSH kann bei MySQL manchmal einfach nur abartig sein, phpMyAdmin nimmt einem nicht unbedingt etwas ab, biete nur ein vielfaches mehr Komfort.

noiz wrote:II: Absicherung von SSH

Dem Punkt kann ich nur voll und ganz zustimmen.

noiz wrote:III. Einsatz einer Firewall

Lass eine Firewall weg. Wenn du eh was auf deiner Kiste hast, dann ist es eh zu spät. Ein halbwegs anständiges Skript macht einfach apt-get remove iptables und du sitzt da... Firewalls auf dem zu schützenden System ist Mist, das wurde bereits in einer anderen Diskussion geklärt ;)

Was von innen kommt ist per default gut, wenn nicht hast du eh ganz andere Probleme. Solange diese Filterung lokal ist, bringt es wie bereits erwähnt nichts. Nimm eine vorgeschaltete Hardware-basierende Firewall, die zieht auch nicht so viel Last, angesichts deines UT2k4-Vorhabens.

noiz wrote:IV. Kompletter Verzicht auf FTP

Das predige ich schon die ganze Zeit ;)

noiz wrote:V: HTTP nur über SSL

Leite einfach pauschal alles von HTTP auf HTTPS um, SSL auf Port 80 könnte seeeeeeeehr interessant werden, mit iptables zwar machbar, aber Port 80 ist ja eigentlich HTTP.

noiz wrote:VI: Regelmäßigere Audits

Sehr gute Idee, Prävention ist besser als Reaktion ;)

noiz wrote:VII: Aktivere Informationsbeschaffung

Das ist das A und O. Wie viel Wahrheit doch in der Aussage "Unwissenheit schützt vor Strafe nicht" steckt, musste bestimmt ein großer Anteil der "Sysadmins" von gehackten Rootservern in Erfahrung bringen... aber auf die harte Tour ;)

Informiere dich nicht nur über die eingesetzte Software, selbst die Security-Mailinglisten des Distributors bringen schon den einen oder anderen Vorsprung.

noiz wrote:VIII: chroot-ten nicht-sicherer Dienste

An sich eine gute Idee, solltest du jedoch nicht zum Exzess praktizieren. Was wirklich in eine chroot sollte, packst du da auch hin, den Rest belässt du da. Grund ist hierbei ein teilweise immenser Wartungsaufwand, wenn nach einem Softwareupgrade nichts mehr geht, weil die Abhänigkeiten in der chroot noch veraltet sind (soll es alles schon gegeben haben *g*). Man sollte immer abwägen, wann es sinnvoll ist und Nutzen bringt und wann nicht.

noiz wrote:IX. Einsatz von bastille und/oder ähnlichen Tools.

Wie gesagt, wenn er eh auf der Maschine ist, hast du ganz andere Sorgen. Klar speckst du damit dein System ab, aber kastrieren (*g*) solltest du es nicht.

noiz wrote:X: Aktive Logfile-Analyse

Mach das doch einfach von Hand, etwa ein kleines Perl/PHP-Skript sollte dies bereits beherrschen.


Insgesamt solltest du dir nicht zu viel vornehmen, weil irgendwann sitzt man stöhnend da, hat keine Lust mehr weil gerade erst Test 53 von 781 läuft und fängt an zu schlampen. Grenze dein Sicherheitskonzept auf das ein, was wirklich notwendig und entsprechen zumutbar ist.

Gruß
dtdesign

Dedizierter Linux-Rootserver in einem Rechenzentrum. 256 MB RAM, 10 GB Platte. Auf dem Server werden folgende Dienste laufen: Im Ürinzip ein LAMP-Setup, da ich viel CMS-Systeme einsetze, die auf PHP/MySQL basieren, sowie ein TeamSpeak2-Server und ein UnrealTournament 2004-Server.

Der spuckt Dir doch vor die Füsse!?

Davon abgesehen - ich habe nichts von grsecurity gelesen?

flo wrote: Davon abgesehen - ich habe nichts von grsecurity gelesen?

Wenn ich mir die technischen Daten (10GB Platte, 256MB RAM) ansehe, schaut es nach einem vserver aus!?

sledge0303 wrote: ... schaut es nach einem vserver aus!?

Dachte ich mir auch, daß gar kein Zugriff auf den Kernel besteht :-)

flo wrote:

sledge0303 wrote: ... schaut es nach einem vserver aus!?

Dachte ich mir auch, daß gar kein Zugriff auf den Kernel besteht :-)

Um alle Vermutungen aus dem Weg zu räumen: Es ist ein tatsächlich echt und real existierender Rootserver. Woraus schließt Du denn, dass kein Zugriff auf den Kernel besteht? ;-)

wegen der Leistungseckdaten und weil der Punkt "Kernel" nicht auftaucht!?

Hallo dtdesign!

Vielen Dank für Deine akribische Analyse, ich kann jetzt aus Zeitgründen leider nicht auf alle Deine Vorschläge eingehen, aber ich freue mich dass Du trotz der späten Uhrzeit so genau auf mein Konzept eingegangen bist!

Ich habe eben, auf Anregung der anderen Mit-Schreiber in diesem Thread mal nach grsecurity gegooglet und werde das vermutlich auch in mein Konzept mit einbeziehen.

Um den Hinweis wg. der Performance zu berücksichtigen: Der Server mit diesen Hardware-Specs. lief jetzt fast 1 Jahr in dieser Konfiguration, ohne dass ich nennenswerte Probleme mit der Performance hatte.

Grüße

Nico

dtdesign wrote:Ein halbwegs anständiges Skript macht einfach apt-get remove iptables und du sitzt da...

Huch, war mir gar nicht bewußt, dass jeder Zugriff auf einen rootserver gleich in root-rechte mündet :lol:

noiz wrote:VI: Regelmäßigere Audits

Sehr gute Idee, Prävention ist besser als Reaktion ;)

Wobei ein Audit nochmal was anderes ist, als das von ihm beschriebene ausführen von automatisierten Penetration-Tests. Nessus testet auf bekannte Fehler/Lücken und auf Fehlkonfigurationen. Wenn du das System aktuell hälst, und die Dienste welche du Laufen hast auch kennst und konfigurieren kannst, dann ist der Zeitaufwand für das durchführen und interpretieren der Ergebnisse von Penetration Tests genauso schlecht eingesetzte Zeit wie das Fiddeln mit komplexen iptables-Regeln auf dem Rootserver.

noiz wrote:VII: Aktivere Informationsbeschaffung

In Zusammenhang damit dann wohl auch die Empfehlung so weit wie möglich die Pakete der Distribution zu verwenden, dann spart man sich das individuelle Tracking der einzelnen Softwarepakete.
(Es sei denn natürlich man hat die Ressourcen zur Hand, dass man immer schneller reagieren kann und wird als die Security-Teams der Distributionen...)

noiz wrote:VIII: chroot-ten nicht-sicherer Dienste

Nicht-sichere Dienste sollte man gar nicht erst laufen lassen. ;) Ansonsten bietet sich das v.a. wirklich da an, wo es um Pakete geht, welche ohnehin nicht über die Distribution gepflegt werden.

dtdesign wrote:Man sollte immer abwägen, wann es sinnvoll ist und Nutzen bringt und wann nicht.

Ack. Das gilt natürlich für alle Maßnahmen. *wink* ;)

noiz wrote:IX. Einsatz von bastille und/oder ähnlichen Tools.

Wie gesagt, wenn er eh auf der Maschine ist, hast du ganz andere Sorgen.

Diese Sichtweise ist sehr kurzsichtig. Ein gutes Sicherheitskonzept ist immer Mehrstufig. Es gibt kein 100% prozent sicheres System, d.h. überspitzt ausgedrückt: die Frage ist nicht ob man gehackt wird, wondern wann. Und wenn nach dem erfolgten lokalen Zugriff weitere Hürden den Hackern bestimmte Tätigkeiten verbieten, dann kann einem das genau die wertvolle Zeit verschaffen die man braucht um zu reagieren.
Ab einem gewissen Zeitpunkt (also wenn man schon viele gute Maßnahmen umgesetzt hat), ist der "ROI" für Investitionen in Schadenbegrenzungsmaßnahmen die nach einem Hack greifen einfach höher als die immer weitere Investitionen in das Verhindern von unauthorisiertem Zugriff. Wie gesagt: Immer Kosten und Nutzen abwägen.

Insgesamt solltest du dir nicht zu viel vornehmen, weil irgendwann sitzt man stöhnend da, hat keine Lust mehr weil gerade erst Test 53 von 781 läuft und fängt an zu schlampen. Grenze dein Sicherheitskonzept auf das ein, was wirklich notwendig und entsprechen zumutbar ist.

Full Ack. V.a. solltest du die Maßnahmen priorisieren, damit immer sicher gestellt ist, dass die wichtigeren Maßnahmen auch immer erledigt werden.

noiz wrote:IX. Einsatz von bastille und/oder ähnlichen Tools.

Wie gesagt, wenn er eh auf der Maschine ist, hast du ganz andere Sorgen.

Diese Sichtweise ist sehr kurzsichtig. Ein gutes Sicherheitskonzept ist immer Mehrstufig. Es gibt kein 100% prozent sicheres System, d.h. überspitzt ausgedrückt: die Frage ist nicht ob man gehackt wird, wondern wann. Und wenn nach dem erfolgten lokalen Zugriff weitere Hürden den Hackern bestimmte Tätigkeiten verbieten, dann kann einem das genau die wertvolle Zeit verschaffen die man braucht um zu reagieren.
Ab einem gewissen Zeitpunkt (also wenn man schon viele gute Maßnahmen umgesetzt hat), ist der "ROI" für Investitionen in Schadenbegrenzungsmaßnahmen die nach einem Hack greifen einfach höher als die immer weitere Investitionen in das Verhindern von unauthorisiertem Zugriff. Wie gesagt: Immer Kosten und Nutzen abwägen.

Insgesamt solltest du dir nicht zu viel vornehmen, weil irgendwann sitzt man stöhnend da, hat keine Lust mehr weil gerade erst Test 53 von 781 läuft und fängt an zu schlampen. Grenze dein Sicherheitskonzept auf das ein, was wirklich notwendig und entsprechen zumutbar ist.

Full Ack. V.a. solltest du die Maßnahmen priorisieren, damit immer sicher gestellt ist, dass die wichtigeren Maßnahmen auch immer erledigt werden.

Vielen Dank für Deine Anregungen, an diesem Punkt kann ich dir ausch zustimmen! Wie gesagt, mein bisheriges "Konzept" bestand daraus, über apt die Pakete auf dem Server so aktuell wie möglich zu halten. Das das nicht klappt, musste ich ja schmerzlich erfahren :-( Ist mir im Nachinein aber auch vollkommen klar, dass das nicht klappen konnte. Die Idee eines mehrstufigen Sicherheitskonzepts ist auch das, was ich mit meinen Vorschlägen erreichen wollte, bastille bspw. soll dabei nur eine Stufe darstellen.

Vielen Dank auch noch mal für den Hinweis, einzelne Schritte zu priorisieren. Meine Liste war bis jetzt ungeodnet (oder wenn überhaupt dann nur in der Reihenfolge, wie mir die Schritte eingefallen sind) wird aber mit Sicherheit noch eine Reihenfolge erhalten.

Du hast außerdem noch die Verkürzung der Reaktionszeit angesprochen. Mir missfällt irgendwie der Gedanke irgend welche Maildienste laufen zu lassen, wenn ich diese nur dazu benötige IDS-Meldungen abzusetzen, das Risiko, dass ich kürzester Zeit ein Spamschleuder aus meinem Server wird gefällt mir einfach nicht. Gibt es noch andere Wege Angriffe zu melden? Ich bin kein Fulltime-Admin (Sprich es ist nicht mein Beruf) kann also nicht den ganzen Tag vor einer Konsole sitzen und warten, dass was passiert. Trotzdem würde ich gerne so schnell wie möglich von einem Angriff erfahren. Gibt es da noch andere Möglichkeiten (Jabber bspw. oder einen sicheren Email-Kanal, der nicht auf das serverseitige Versenden von Emails angewiesen ist)?

Grüße

Nico

Ich würde mir die Logs einfach einmal kurz taren und gzippen, anschließend von Hand via HTTPS runterladen und wieder löschen. Anschließend lokal auswerten lassen, soetwas gar nicht erst auf dem Server machen, weil du dir mit irgendwelchen Log-Exploits maximal deinen eigenen PC shredderst, aber nicht den Server.

Ansonsten wäre es doch einfach, einen Mailserver aufzusetzen der NUR verschickt und NUR auf 127.0.0.1 horcht. Dann per dedizierter Firewall, notfalls auch iptables den Port von aussen komplett droppen. Dann will ich sehen, wie den jemand als bouncer missbrauchen will.

Im Grunsatz sollte der erste Ansatz lauten, alles was du nicht brauchst runterzuschmeissen. Je weniger potenzielle Einfallslöcher du hast, desto weniger musst du überwachen. inetd (aka. Internet Superserver) direkt deaktivieren (sprich keine Dienste über den anbieten) und anschließend alle Dienste die potenziell nach aussen gehen können aber nicht sollen direkt per Firewall dicht machen. Ein MySQL hat nach aussen hin nicht viel zu suchen, wenn du jetzt alles was vom oder an den MySQL-Port ankommt einfach droppst, hast du keine Sorgen mehr.

Um dir dies zu verdeutlichen, bei uns ist von aussen nur Port 22 (SSH), Port 80 (HTTP), Port 443 (HTTPS) erreichbar. Zudem gibt es noch einen weiteren Port, aber den brauch ich nicht zu erwähnen, wer den wissen will, weiss sich zu helfen :) Faktisch werden alle Ports per dedizierter Hardware-Firewall geblockt, sprich einfach alle Pakete gedroppt, ausser die erreichen einer der spezifizierten Ports. So gesehen arbeiten wir mit einer Default-Policy von disallow und einer Whitelist.

Gruß
dtdesign

Es geht einfach darum, die Firewall nur dazu einzusetzen, um bei einer versehentlichen Fehlkonfiguration zu verhindern, dass der MySQL-Server (als Beispiel) mit Dritten ins Gespräch kommt. Eine Firewall (dediziert und vorgeschaltet), die nur alles wegschmeisst, was auf nicht explizit freigegebenen Ports kommt, bietet dir einfach ein größes Zeitfenster um Lücken zu schließen.

Ich denke, ich habe bereits klar gestellt, das eine Firewall kein Allheilmittel ist und man sein System so warten muss, als ob man keine hätte. Tatsächlich verfolgen wir mit diesem Ansatz einfach nur das Prinzip, dem Angreifer möglichst viele Steine in den Weg zu werfen, um uns im Falle einer entdeckten Sicherheitslücke die Zeit zu geben, zu reagieren.

Eine Schwachstelle in einem CMS lässt sich nur bedingt vermeiden, etwa filtere ich mit Hilfe einer kleinen selbstgeschriebenen Software generische PHP-Angriffe wie z.B.: UNION SELECT etc, mit beliebigen Schreibweisen (also nicht nur lesbar sondern à la Ó’ (weiss nicht, wie man diese Kodierungen nennt)) einfach sucht und Anfragen ggf. wegschmeisst (stillschweigend droppen).

Ich will mir halt so viel Zeit wie möglich beschaffen um auf Sicherheitslücken zu reagieren, je mehr Steine im Weg liegen, desto höher ist meine Chance rechtzeitig vor Ort zu sein. Zudem gehen wir den gemeinen Weg des droppens. Der Angreifer bekommt keine Rückmeldung, da Pakete bzw. Anfragen einfach stillschweigend verworfen werden. Es geht zum Beispiel keinen etwas an, was der Server so alles hat, also werden Signaturen dezimiert (statt Apache 1.33.7 mod/perl mod/php etc. steht einfach nur Apache da). Sicherheitstechnisch bringt es nur maginal etwas, z.B.: muss ein Angreifer Exploits durchprobieren, bis er einen passenden gefunden hat, statt gezielt etwas zu versuchen dank des Versionsstrings. Faktisch geht es ja auch keinen an, was du für eine Software einsetzt, ein versierter Angreifer hat keine Probleme das rauszubekommen.

PS: Irgendwie stinkt der Post nach Redunanz :(

noiz wrote:Du hast außerdem noch die Verkürzung der Reaktionszeit angesprochen. Mir missfällt irgendwie der Gedanke irgend welche Maildienste laufen zu lassen, wenn ich diese nur dazu benötige IDS-Meldungen abzusetzen, das Risiko, dass ich kürzester Zeit ein Spamschleuder aus meinem Server wird gefällt mir einfach nicht. Gibt es noch andere Wege Angriffe zu melden? Ich bin kein Fulltime-Admin (Sprich es ist nicht mein Beruf) kann also nicht den ganzen Tag vor einer Konsole sitzen und warten, dass was passiert. Trotzdem würde ich gerne so schnell wie möglich von einem Angriff erfahren. Gibt es da noch andere Möglichkeiten (Jabber bspw. oder einen sicheren Email-Kanal, der nicht auf das serverseitige Versenden von Emails angewiesen ist)?

Du kannst E-Mails von Deinem Server aus versenden, ohne dafür einen MTA laufen zu haben (Stichwort: esmtp, ssmtp). Damit ist die Gefahr eines Open Relay schon mal so gut wie ausgeschlossen, da kein Dienst auf Port 25 lauscht. Wenn der Webserver schön chrooted läuft und der Kernel grsecurity-gehärtet ist, wird auch ein undichtes Webskript nicht dazu taugen, Mails zu versenden, da ein Zugriff auf ssmtp oder esmtp aus dem Chroot heraus nicht möglich ist.

matzewe01 wrote:Und redundant frage Ich geziehlt nach:
Wer wie und womit prüft Ihr ob solche Fälle vorliegen?
Welcher Dienst oder Service sagt euch, Hey, der Mysql Server ist auf Deinem System erreichbar geworden oder "falsch konfiguriert"? Ups, die Firewall ist herunter gefallen und was nun? Da Du es nicht bemerkst, hast Du keinen Zeitvorsprung.

Dafür gibt es Tools wie nmap.

Redunanz bei der Überwachnung eines Server ist wichtig, einerseits sollte sich der Server selber überwachen, andererseits - wie bereits von dir erwähnt - sollte ein drittes System mit ins Spiel kommen, um von aussen eine Überwachnung zu ermöglichen inklusive der Protokollierung von Logins et cetera.

Trotzdem muss immer das Aufwand-Nutzen Verhältnis stimmen. Server kann man mit nahezu unendlich vielen Dingen absichern, aber manches macht nicht immer Sinn. Beispielsweise setzen wir keine public keys für SSH ein, da die Benutzernamen und Passwörter einen so hohen Komplexitätsgrad besitzen, dass dies zu erraten nicht in endlicher Zeit erfolgen kann.

Daraus folgt, dass eine Portverlegung von SSH bzw. public key Authenifizierung in diesem konkreten Fall keinen Sinn macht.

Das Beispiel ist auf jeden Dienst übertragbar, es kommt einfach darauf an, was Sinn macht. Deine Vorschläge - so schön und gut sie auch sind - halte ich für den "normalen" Menschen einfach zu überdimensioniert. Absolute Sicherheit gibt es nicht und es ist nicht falsch sich so weit wie möglich dessen anzunähern, aber man sollte nicht mit Kanonen auf Spatzen schießen und das tust du meiner Meinung nach.

Gruß
dtdesign

Monitoring gehört leider bei den meisten Anbietern nicht zum Lieferumfang und 10 Euro mehr im Monat können doch durchaus störend sein. Das Problem des einrichtens sehe ich nicht, sondern eher die damit steigende Komplexität des Systemes. Je mehr man hat, desto leichter übersieht man Fehlkonfigurationen etc.

Ausserdem, wer sich Passwörter etc aufschreibt, hat eh verloren. Es ist mit selbst gebastelten Eselsbrücken durchaus möglich sich Passwörter und Benutzernamen mit einer gerade ekelhaften Zeichenbestückung und Länge zu merken. Alles eine Frage der Übung.

Gruß
dtdesign

dtdesign wrote:Ausserdem, wer sich Passwörter etc aufschreibt, hat eh verloren.

So ein Unsinn. Wenn ich in meinen Passwortmanager reinschaue, dann sehe ich da > 60 Einträge, wovon mehr als die Hälfte regelmäßig genutzt werden. Wenn man sich die Sachen nicht irgendwo aufschreibt, dann neigt man dazu entweder zu einfache Passwörter zu benutzen, oder das gleiche Passwort an zahlreichen verschiedenen Stellen.
Der Passwortmanager legt alle Daten verschlüsselt ab. Zusätzich dazu nutze ich noch herkömmliche Verschlüselung der Filesysteme. Da ist der Aufwand mir die Passwörter zu entwenden ja noch höher als "einfach" einen keylogger auf meinen System unterzubringen.

Es ist mit selbst gebastelten Eselsbrücken durchaus möglich sich Passwörter und Benutzernamen mit einer gerade ekelhaften Zeichenbestückung und Länge zu merken. Alles eine Frage der Übung.

Ack. Ich finde den Ansatz von http://www.diceware.com ganz gut. Allerdings lassen sich auch mit den besten Tricks nicht beliebig viele Passwörter merken.

was ich in deiner Liste vermisse, ist, wie du deine verschiedenen Webräsenzen voreinander schützt, falls eines der cmse ne Sicherheitslücke hat, damit daraus nicht auf den ganzen Server zugegriffen kann.
z.B.
safemode
chroot
apache-itk
openbasedir
u.s.w.

PHP.net wrote:Safe Mode was removed in PHP 6.0.0.

Nachdem lange Zeit nur da stand:

PHP.net wrote:Safe Mode is considered as a broken feature (oder äquivalent)

Lass safe_mode Weg, bringt nur maginale Sicherheit und lässt sich leicht aushebeln. Zum Beispiel hilft bei einem system()-Aufruf (den z.B.: Mambo/Joomla! benötigen zwecks GD) kein safe_mode, da hilft nur ein Wrapper wie suPHP/suexec bzw. ein chroot

Finger weg von safe_mode, es stellt nur eine trügerische Sicherheit dar imho.

Edit:

Month of PHP Bugs wrote:Notes

Safemode and open_basedir are flawed by design and will always have security holes [...] The security of your server setup should therefore NEVER rely on these directives.

Gruß
dtdesign