Rootserver geknackt?

[fun4teen]

Wenn ich mich auf dem vermeintlich gehackten Server der .biz Domain, so umschaue vorallem den Ordner IP's, dann würd ich hier nicht mehr von Script Kiddies reden...

Der Ordner IPs (http://buytraff.biz/dl/ips/) enthält ja abartig viele dateien.. was sind das genau für dateien? Jemand eine Ahnung?

[aubergine]

IP's von wohl weiteren gehackten Servern, geordnet nach RANGES...

[Joe User]

Wenn bei einer Datei dransteht wann sie zuletzt geändert wurde...lässt sich das irgendwie manipulieren?

Ja, oder wie soll die mtime sonst geändert werden können?

[fun4teen]

Wenn bei einer Datei dransteht wann sie zuletzt geändert wurde...lässt sich das irgendwie manipulieren?

Ja, oder wie soll die mtime sonst geändert werden können?

Also ich meinte... angenommen der Hacker hat eine datei geändert .. nun wird das Ã?nderungsdatum in der mtime ja auf die aktuelle Uhrzeit gesetzt .. lässt sich vielleicht durch ein Trick an dieser stelle eine andere mtime (in der vergangenheit) eintragen?

[Joe User]

lässt sich vielleicht durch ein Trick an dieser stelle eine andere mtime (in der vergangenheit) eintragen?

Zum 2ten Mal: Ja.

[captaincrunch]

Lord_Pinhead: Deine Mühen bzgl. Tips zum "bereinigen" von geknackten Systemen in allen Ehren, nur finde ich es besonders in diesem Fall grob fahrlässig, die Kiste nicht komplett neu aufzusetzen...was in den allermeisten Fällen auch von der Gerichtsbarkeit so gesehen werden wird.
Btw.: Schau dir vielleicht mal die aktuelle Beta vom SuckIT an, das ist mittlerweile (leider) als schon mehr als Scriptkiddie-tauglich anzusehen. :(

Sory, aber auch wenn ich mich mittlerweile seit ein paar Jahren mit ebensolchen Dingen auseinandersetze, würde ich eine solche Aktion ("alles neu dank erfolgreichem Angriff") als Lehrgeld sehen, und mit einem vollkommen frischen System anfangen. Umso mehr Zeit ist dann auch, das Sicherheitskonzept noch mal genau zu überdenken...sofern es in diesem Fall überhaupt vorhanden ist/war. :roll:

[outofbound]

100%iges ACK @ CC.

Noch schlimmer. Jeder unerfahrene "Admin" wird nur so weit lesen, wie für ihn "angenehm", deshalb sind solche Anleitungen doppelt gefährlich.
Erst sind die Tipps weit über dem Erfahrungslevel der meisten, und zweitens kommen sie auch noch halbherzig an. :(

Gruss,

Out

[manarak]

Noch schlimmer. Jeder unerfahrene "Admin" wird nur so weit lesen, wie für ihn "angenehm", deshalb sind solche Anleitungen doppelt gefährlich.
Erst sind die Tipps weit über dem Erfahrungslevel der meisten, und zweitens kommen sie auch noch halbherzig an.

¨

Richtig. Aber das ist auch teilweise darauf zurückzuführen, dass so wenige end-to-end und step-by-step Anleitungen existieren, wie man einen Server aufsetzt und absichert.
Die meisten Tipps und Beiträge sind für Anfänger völlig unbrauchbar weil auf Fachchinesisch verfasst (z.B. "mounte /bla-bla mit dingsbums").
Nachfragen nach präziserer Anleitung würden auf diesem Forum wahrscheinlich sogar gelöscht werden.

Eine sehr gute Anleitung wie man einen Webserver mit Plesk aufsetzt und absichert befindet sich z.B. hier:
http://www.pleskaddons.com/description. ... _Server/6/
Rund die Hälfte dieser Anleitung kann man auch gut auf andere Systeme anwenden.

[suntzu]

Die meisten Tipps und Beiträge sind für Anfänger völlig unbrauchbar weil auf Fachchinesisch verfasst (z.B. "mounte /bla-bla mit dingsbums").

Für wen DAS Fachchinesisch ist, der hat als root auf einem Server schlichtweg nix verloren! Punkt, Schluss, Aus!

Gruß,
Dominik,
nicht verstehend, warum hier immer noch so viele "noobies" frei rumlaufen... ;-)

[manarak]

Genau darum geht es SunTzu!

Ich weiss ja mittlerweile auch, was das bedeutet - dank Anleitungen wie die zu der ich den Link gepostet habe. Ã?bung macht eben den meister!

Wenn man sich das alles selber raussuchen muss, hat man praktisch keine Chance, min einem akzeptablen Zeitaufwand das System so aufzusetzen wie beabsichtigt, denn man muss 20 Mal von vorne anfangen, weil man nicht alles bedacht hat.

Bei der ersten praktischen Fahrstunde fährt man ja auch auf der Strasse, anstatt sich stundenlang den Motor anzuschauen.

Deshalb fordere ich mehr Praxisorientierte Tutorials. Das bringt dann am Ende auch viel mehr sichere Server.

[Joe User]

Aber das ist auch teilweise darauf zurückzuführen, dass so wenige end-to-end und step-by-step Anleitungen existieren, wie man einen Server aufsetzt und absichert.

Was würde es einem Debian-User nützen, wenn ich eine derartige step-by-step Anleitung für Gentoo-Hardened veröffentliche, oder umgekehrt? Richtig, nicht viel.

Die meisten Tipps und Beiträge sind für Anfänger völlig unbrauchbar weil auf Fachchinesisch verfasst (z.B. "mounte /bla-bla mit dingsbums").

Ohne Fachterminie geht es in diesem Bereich nunmal nicht. Selbst die "Personal Firewall" von SUSE lässt sich nicht ohne grundlegende Kenntniss der Fachbegriffe vernünftig konfigurieren.

Nachfragen nach präziserer Anleitung würden auf diesem Forum wahrscheinlich sogar gelöscht werden.

Das hängt von der Art und Weise der Fragestellung ab. Spätestens wenn der Fragesteller etwas Eigeninitiative zeigt, wird ihm auch geholfen.

Eine sehr gute Anleitung wie man einen Webserver mit Plesk aufsetzt und absichert befindet sich z.B. hier:
http://www.pleskaddons.com/description. ... _Server/6/
Rund die Hälfte dieser Anleitung kann man auch gut auf andere Systeme anwenden.

Hmm, nicht vetrauenswürdige 3rd-Party RPMs, joe/mc, notierte Passwörter, PermitRootLogin no mit USEPam yes, sinnfreie aliases in /etc/bashrc, von extern zugänglicher MySQLd mit fehlerhafter Config (set-variable), eine vorgefertigte "Firewall" ohne sinnvolle Aufgabe, sowie unterdrückte Softwareversionen haben mit einem abgesichertem Server wenig bis gar nichts zu tun, im Gegenteil...

[captaincrunch]

Aber das ist auch teilweise darauf zurückzuführen, dass so wenige end-to-end und step-by-step Anleitungen existieren, wie man einen Server aufsetzt und absichert.

Nun ja...Joe hat ja schon auf die Unterschiede hinsichtlich der diversen Distributionen hingewiesen. Ich würde dabei (mal wieder) noch einen Schritt weiter gehen und behaupten, dass sich für diese Dinge schlicht und ergreifend kein Patentrezept finden lassen wird. Die allermeisten Installationen sind nun einmal unterschiedlich.

Was würde es dir also nützen, wenn ich jetzt einen ellenlangen Text dazu schreibe, wie ich z.B. meinen lighttpd abgesichert habe? Mal ganz davon abgesehen, dass mir alleine hier im Forum einige einfallen würden, die so etwas ohnehin nur ohne jeglichen Sinn und Verstand abtippen würden. Sobald dann auch nur das kleinste Problem auftritt wird dann direkt wieder geschrien...

[manarak]

Hallo Mr. User

Ohne Fachterminie geht es in diesem Bereich nunmal nicht. Selbst die "Personal Firewall" von SUSE lässt sich nicht ohne grundlegende Kenntniss der Fachbegriffe vernünftig konfigurieren.

Mit dem stimme ich überein - es geht nicht ohne Fachterminologie, aber es sollte auch nicht NUR Fachterminologie verwendet werden, besonders in Tutorials. Das richtige ist aus meiner Sicht, das richtige Fachwort zu verwenden, gefolgt von dem, was man damit genau gemeint hat, sprich die zugehörigen Befehle.

Dann hätte ich zu Deiner Kritik zum Tutorial noch Bemerkungen, bzw. Fragen:

nicht vertrauenswürdige 3rd-Party RPMs:
persönlich vertraue ich Scot, bzw. ART - aber Du hast wohl recht, dass das nicht jedermanns Sache ist. Ich habe diese Entscheidung abgewägt und getroffen, da mir Scot vertrauenswürdig scheint.

joe/mc:
dazu möchte ich fragen, was damit nicht stimmt?

notierte Passwörter:
das Tutorial sagt, es in seinen Notizen zu notieren. Ich habe ein Buch zu hause mit meinen Serverpasswörtern. Ich könnte mir sonst die 15 Spezialzeichen und Zahlen nicht merken. Wie machst Du das?

PermitRootLogin no mit USEPam yes:
Da würde ich gerne mehr von verstehen - kannst Du erklären, warum das nicht gut ist?

sinnfreie aliases in /etc/bashrc:
Hackst Du da nicht auf Kleinigkeiten rum? Jeder Admin kann ja aliases anlegen wie er will, wenn er sagt es hilft ihm... Ist es denn nicht für den Neuling nützlich zu wissen, dass man das kann?

von extern zugänglicher MySQLd mit fehlerhafter Config (set-variable):
Das interessiert mich. Die Plesk-Firewall sperrt zwar den mysql-port, aber ich würde gerne wissen, was man in der Konfiguration angeben müsste, damit mysqld vor zugriff von aussen sicher ist. Welche set-variable ist denn fehlerhaft?

eine (vorgefertigte) "Firewall" ohne sinnvolle Aufgabe:
"vorgefertigt" ist ja grundsätzlich einmal gut, wenn Sie richtig vorgefertigt wurde, da man dadurch weniger arbeit hat. Aber warum sagst Du, dass sie keine sinnvolle Aufgabe hat?

(...) unterdrückte Softwareversionen haben mit einem abgesichertem Server wenig bis gar nichts zu tun, im Gegenteil:
Ich übersetze: "unterdrückte Softwareversionen erhöhen das Risiko gehackt zu werden" Wie das?

[manarak]

Hallo Captain

Nun ja...Joe hat ja schon auf die Unterschiede hinsichtlich der diversen Distributionen hingewiesen. Ich würde dabei (mal wieder) noch einen Schritt weiter gehen und behaupten, dass sich für diese Dinge schlicht und ergreifend kein Patentrezept finden lassen wird. Die allermeisten Installationen sind nun einmal unterschiedlich.

Was würde es dir also nützen, wenn ich jetzt einen ellenlangen Text dazu schreibe, wie ich z.B. meinen lighttpd abgesichert habe? Mal ganz davon abgesehen, dass mir alleine hier im Forum einige einfallen würden, die so etwas ohnehin nur ohne jeglichen Sinn und Verstand abtippen würden. Sobald dann auch nur das kleinste Problem auftritt wird dann direkt wieder geschrien...

Anmerkungen meiner Seite: diejenigen, die solche Tutorials benötigen, sind nicht wirklich in der Lage eine Distribution auszuwählen. Es schadet also nicht wirklich wenn nur Tutorials für die 3-4 meistgebrauchten Distributionen existieren würden.
Auch Dein Argument mit dem lighttpd trifft zu, und ich behaupte wie Du, dass das gar nicht interessiert.
Otto Normaluser will in den meisten Fällen nur einen funktionierenden Webwerver oder Gameserver mit Standard-Features. Das Spektrum der Erklärungen ist also begrenzt.

Mit einer sinnvollen Empfehlung zu einer Distribution und einer Adminhilfe (wie Plesk, Confixx etc.) sowie guten Tutorials zum Aufsetzen und Absichern des Servers (und zur periodischen Maintenance) könnte man sehr vielen planlosen Rootserver-Mietern zu einem Server verhelfen, der ein vielfaches sicherer ist, als das was heute so bei 1&1 und Co. läuft. Das würde das Internet aus meiner Sicht sehr viel sicherer machen.

[Joe User]

Das richtige ist aus meiner Sicht, das richtige Fachwort zu verwenden, gefolgt von dem, was man damit genau gemeint hat, sprich die zugehörigen Befehle.

Warum sollte ich einem HowTo die man-pages zu den verwendeten Befehlen wiederholen?

nicht vertrauenswürdige 3rd-Party RPMs:

persönlich vertraue ich Scot, bzw. ART - aber Du hast wohl recht, dass das nicht jedermanns Sache ist. Ich habe diese Entscheidung abgewägt und getroffen, da mir Scot vertrauenswürdig scheint.

Ah ja, nur weil der Autor des HowTo einer mir unbekannten Person blind vertraut, soll ich dies ebenfalls? Vertraust Du mir?

joe/mc:

dazu möchte ich fragen, was damit nicht stimmt?

Unnötige Software hat auf einem Server nichts verloren. vi(m) und/oder pico/nano gehören bei allen mir bekannten Distributionen zum Basissystem.

notierte Passwörter:

das Tutorial sagt, es in seinen Notizen zu notieren. Ich habe ein Buch zu hause mit meinen Serverpasswörtern. Ich könnte mir sonst die 15 Spezialzeichen und Zahlen nicht merken. Wie machst Du das?

Ich habe dafür einen kleinen exklusiv reservierten Bereich im Gehirn. Gekoppelt mit einfachsten assoziative Fähigkeiten reicht das völlig aus ;)
Ernsthaft: Wenn ich mir sensible Daten (beispielsweise Passworte) nicht merken kann, dann hinterlege ich diese an einem nur mir zugänglichem Ort (Safe).

PermitRootLogin no mit USEPam yes:

Da würde ich gerne mehr von verstehen - kannst Du erklären, warum das nicht gut ist?

USEPam hebelt PermitRootLogin aus: man sshd_config

sinnfreie aliases in /etc/bashrc:

Hackst Du da nicht auf Kleinigkeiten rum? Jeder Admin kann ja aliases anlegen wie er will, wenn er sagt es hilft ihm... Ist es denn nicht für den Neuling nützlich zu wissen, dass man das kann?

Wie willst Du mit einem alias den Server sicherer machen? Oder habe ich das Thema des HowTo falsch interpretiert?

von extern zugänglicher MySQLd mit fehlerhafter Config (set-variable):

Das interessiert mich. Die Plesk-Firewall sperrt zwar den mysql-port, aber ich würde gerne wissen, was man in der Konfiguration angeben müsste, damit mysqld vor zugriff von aussen sicher ist. Welche set-variable ist denn fehlerhaft?

set-variable = var_name=value

Set the program variable var_name to the given value. This is equivalent to --set-variable=var_name=value on the command line. Spaces are allowed around the first â??=â?? character but not around the second. This syntax is deprecated as of MySQL 4.0. See Section 4.3.4, â??Using Options to Set Program Variablesâ? for more information on setting program variables.

Zur sonstigen Config siehe: http://www.rootforum.org/forum/viewtopic.php?t=36343

eine (vorgefertigte) "Firewall" ohne sinnvolle Aufgabe:

"vorgefertigt" ist ja grundsätzlich einmal gut, wenn Sie richtig vorgefertigt wurde, da man dadurch weniger arbeit hat. Aber warum sagst Du, dass sie keine sinnvolle Aufgabe hat?

Weil eine Firewall vor das zu schützende System gehört und nicht darauf. Zudem sind bei einem Server per se nur gewollte Ports offen, insofern gibt es gar nichts zu schützen.

(...) unterdrückte Softwareversionen haben mit einem abgesichertem Server wenig bis gar nichts zu tun, im Gegenteil:

Ich übersetze: "unterdrückte Softwareversionen erhöhen das Risiko gehackt zu werden" Wie das?

Unterdrückte oder manipulierte Softwareversionen sind Security by Obscurity aka sinnlos, zudem erschweren sie das Debuggen. Der Teil ab "haben mit..." bezieht sich auf alle genannten Punkte, nicht nur den Letzten...

[Roger Wilco]

USEPam hebelt PermitRootLogin aus: man sshd_config

In dem Punkt muß ich dir widersprechen. Ich denke du verwechselst das mit PasswordAuthentication und/oder ChallengeResponseAuthentication. UsePam hat jedenfalls keinen Einfluß auf PermitRootLogin. Zumindest nicht bei "meinem" sshd. ;)

[mausgreck]

Also ich meinte... angenommen der Hacker hat eine datei geändert .. nun wird das Ã?nderungsdatum in der mtime ja auf die aktuelle Uhrzeit gesetzt .. lässt sich vielleicht durch ein Trick an dieser stelle eine andere mtime (in der vergangenheit) eintragen?

Code: Select all

man 2 utime

Oder:

Code: Select all

date -s vergangenheit
touch/chmod file
date -s jetzt

[Joe User]

In dem Punkt muß ich dir widersprechen.

Mift, hat er es doch bemerkt :roll:

[manarak]

Joe, alles in einem denke ich, dass die von Dir kritisierten Punkte für einen privaten Server hinnehmbar sind.

Ausserdem habe ich noch folgende Anmerkungen:

Warum sollte ich einem HowTo die man-pages zu den verwendeten Befehlen wiederholen?

Die manpages enthalten selten Befehle, die man direkt anwenden kann. Ausserdem fehlen die sinnvollen Optionen. Der Benutzer ist in diesem Stadium noch nicht soweit, dass er sich das alleine zusammenreimen kann.

Ah ja, nur weil der Autor des HowTo einer mir unbekannten Person blind vertraut, soll ich dies ebenfalls? Vertraust Du mir?

Nun, es sei jedem überlassen, sein Vertrauen demjenigen zu schenken den er will. Ich kenne Dich z.B. nicht, aber etliche andere Admins vertrauen (schwören auf) ART. Such Mal nach AtomicRocketturtle um Dich zu überzeugen. Für meinen Privaten Server reicht es. Klar ist, dass ich damit keinen Bankserver oder sonst was ernstes aufsetzen würde - halt - das würde ich gar nicht Mal selbst tun wollen.

Unnötige Software hat auf einem Server nichts verloren. vi(m) und/oder pico/nano gehören bei allen mir bekannten Distributionen zum Basissystem.

Ok, das ist wieder eine Kleinigkeit, die ich für einen privaten Server für hinnehmbar halte.

Wenn ich mir sensible Daten (beispielsweise Passworte) nicht merken kann, dann hinterlege ich diese an einem nur mir zugänglichem Ort (Safe).

Hmmm... OK. Wenn man bei privaten Servern das Buch zu hause liegen hat, ist das Risiko aus meiner Sicht ebenfalls hinnehmbar, da daneben auch meine Ordner mit Bankauszügen und auch meine Geburtsurkunde und andere wichtige Papiere stehen.

USEPam hebelt PermitRootLogin aus: man sshd_config

Das wurde bereits früher im Thread behandelt.

Wie willst Du mit einem alias den Server sicherer machen? Oder habe ich das Thema des HowTo falsch interpretiert?

Das How-To bezieht sich auf (1) einen Server aufsetzen (inkl. Administrationshilfen) UND (2) absichern, was unweigerlich zur Folge hat, dass gewisse Hinweise darin nur Punkt 1 und andere nur Punkt 2 betreffen. Es hat ja keiner behauptet, dass das einrichten von aliases den Server sicherer macht??

set-variable = var_name=value
This syntax is deprecated as of MySQL 4.0

OK, die erste Version des How-Tos wurde vor der Einführung von MySQL4 in Plesk geschrieben. Da die veraltete Syntax in MySQL4 aber keine Fehler verursacht, hat man übersehen, dass das How-To mit der neuen Syntax ergänzt werden muss. Hier auch: nicht kritisch.

Weil eine Firewall vor das zu schützende System gehört und nicht darauf. Zudem sind bei einem Server per se nur gewollte Ports offen, insofern gibt es gar nichts zu schützen.

Bei den 08-15 Rootservern gibt es keine vorgeschaltete Firewall.
Ich verwende selbst die Plesk Firewall - vielleicht tut die aber nichts anderes als IPtables zu steuern? Weiss ich nicht.

Unterdrückte oder manipulierte Softwareversionen sind Security by Obscurity aka sinnlos, zudem erschweren sie das Debuggen. Der Teil ab "haben mit..." bezieht sich auf alle genannten Punkte, nicht nur den Letzten...

Ok, stufe ich auch als nicht kritisch ein.

Fazit ist, dass es sich wohl um eine ganz gute Anleitung handelt, oder?

[Joe User]

Joe, alles in einem denke ich, dass die von Dir kritisierten Punkte für einen privaten Server hinnehmbar sind.

Wenn der "private Server" nicht an einem öffentlich zugänglichem Netzwerk angeschlossen ist, ja.

Der Benutzer ist in diesem Stadium noch nicht soweit, dass er sich das alleine zusammenreimen kann.

Dann soll er einem fähigen SysAdmin die Brötchen sichern, alles Andere ist und bleibt grob fahrlässig. Lies Dich mal durch das Security-Forum und unser Archiv, dort findest Du viele Beispiele für die möglichen Folgen Deiner "privaten Server"...

[chaosad]

Das Problem ist doch aber vielmehr, das sich die User nicht davon abhalten lassen sich einen Server zu holen obwohl sie sich nicht ausreichend mit der Materie beschäftigen möchten.

Ob diese User jetzt via copy und paste solche howtos einfach abtippen spielt doch keine Rolle. Das System ist nicht mehr ganz so offen als im standardmodus und das ist besser als als gar nichts.

Pauschal zu sagen der soll nen sysadmin nehmen ist falsch. Da viele die Gefahr einfach falsch einschätzen und die Kosten scheuen.

Oder was würdet ihr verlangen um einen Server regelmäßig up2date zu halten und einigermaßen sicher zu machen?

Vom Ansatz halte ich solche Howtos für gut.

[wgot]

Hallo,

Die manpages enthalten selten Befehle, die man direkt anwenden kann. Ausserdem fehlen die sinnvollen Optionen. Der Benutzer ist in diesem Stadium noch nicht soweit, dass er sich das alleine zusammenreimen kann.

dann soll er sich hinsetzen und das Defizit beheben. Was spricht dagegen, daß der User sich die Details selbst erarbeitet wenn ihm der grundsätzliche Weg gezeigt wurde?

Bei den 08-15 Rootservern gibt es keine vorgeschaltete Firewall.

Dann muß man sich bewußt sein daß man ohne Firewall am Netz hängt und dies (außer durch Providerwechsel und höhere Ausgaben) nicht ändern kann. Ein falsches Sicherheitsgefühl durch eine Alibifirewall ist keine Lösung und gehört nicht in ein seriöses HowTo. Sie ist das Gegenteil einer Lösung weil sie dem Abtipp-Admin einredet sein Server wäre gesichert.

Ich verwende selbst die Plesk Firewall - vielleicht tut die aber nichts anderes als IPtables zu steuern? Weiss ich nicht.

Du hast keine Ahnung was das Ding macht, welche Nachteile und Sicherheitsrisiken es möglicherweise für Dich mitbringt, aber Du verwendest es und fühlst Dich sicherer, nur weil "Firewall" draufsteht. Genau das ist das Problem an solchen Standard-Schutzsystemen mit One-Click-Aktivierung.

Unterdrückte oder manipulierte Softwareversionen sind Security by Obscurity aka sinnlos

Ok, stufe ich auch als nicht kritisch ein.

Genau das gleiche Problem: der Abtipp-Admin fühlt sich sicherer obwohl er es nicht ist, im Gegenteil - jeder Möchtegernhacker erkennt an den unterdrückten Softwareversionen daß hier ein Möchtegern-Admin an der Arbeit ist.

Das Problem ist doch aber vielmehr, das sich die User nicht davon abhalten lassen sich einen Server zu holen obwohl sie sich nicht ausreichend mit der Materie beschäftigen möchten.

Das Problem besteht, wird aber durch "Sicherheit zum Abtippen" nicht gelöst sondern vergrößert.

Oder was würdet ihr verlangen um einen Server regelmäßig up2date zu halten und einigermaßen sicher zu machen?

Sicher mehr als der providerübliche Aufpreis für managed Server.

Gruß, Wolfgang

[manarak]

Danke.

Ich glaube, die Herren User und Wgot kämpfen mit extremen Ansichten auf verlorenem Posten.
Sie müssten eigentlich probieren, 1&1 und die restlichen Anbieter von Rootservern in Deutschland und der ganzen Welt zu uberzeugen, dieses Geschäft aufzugeben, und nur "geprüften" (was das auch immer sein mag) Server-Admins zu gestatten, Rootserver zu betreiben. Das wird ja kaum passieren.

Realistischer finde ich den Ansatz, mit leicht verständlichen How-Tos den durchschnittlichen Sicherheitsstand auf dem Internet zu erhöhen - wenn das konzequenter gemacht würde, wäre man einen guten Teil der pubertären Scriptkiddies los.
Meiner Ansicht nach sollten Anbieter von Rootservern die Option anbieten, das alles vorzuinstallieren, samt Anleitung wie man es danach pflegt.

Ein andere Lösung wäre freilich aus dem öffentlichem Netz ein Privates zu machen.

[manarak]

Ausserdem:

jeder Möchtegernhacker erkennt an den unterdrückten Softwareversionen daß hier ein Möchtegern-Admin an der Arbeit ist.

Das gilt nur, wenn man bereits im Visier des Hackers ist.
Das trifft aber bei Möchtegern-Hackern nicht zu, denn die suchen sich nicht extra schwierige Ziele aus, sondern suchen z.B. in Google nach einer verwundbaren Software-Version. Diese Möglichkeit ist dann zumindest nicht gegeben.

Ein falsches Sicherheitsgefühl durch eine Alibifirewall ist keine Lösung und gehört nicht in ein seriöses HowTo. Sie ist das Gegenteil einer Lösung weil sie dem Abtipp-Admin einredet sein Server wäre gesichert.

Zitat:
Ich verwende selbst die Plesk Firewall - vielleicht tut die aber nichts anderes als IPtables zu steuern? Weiss ich nicht.

Du hast keine Ahnung was das Ding macht, welche Nachteile und Sicherheitsrisiken es möglicherweise für Dich mitbringt, aber Du verwendest es und fühlst Dich sicherer, nur weil "Firewall" draufsteht. Genau das ist das Problem an solchen Standard-Schutzsystemen mit One-Click-Aktivierung.

Halt - geht es hier um Psychologie?
Ã?ber die Plesk-Firewall weiss ich nur folgendes: es ist nicht bekannt, dass sie Sicherheitsmängel aufweist (danach habe ich gesucht) und wenn ich auf der sog. Firewall einen Port schliesse, dann ist der zu, und wenn ich ihn öffne ist er offen.
Ich bekomme dabei keinen Ego-Schub oder ein bestimmtes Sicherheitsgefühl, das ist Quatsch. Mit der Firewall mache ich Ports auf und zu, that's it. Ist noch nicht Mal eine richtige "Firewall" mit NAT und stateful inspection wie ich zuhause eine habe - ist aber trotzdem besser als gar nichts!

chaosad hat Folgendes geschrieben:
Das Problem ist doch aber vielmehr, das sich die User nicht davon abhalten lassen sich einen Server zu holen obwohl sie sich nicht ausreichend mit der Materie beschäftigen möchten.

Das Problem besteht, wird aber durch "Sicherheit zum Abtippen" nicht gelöst sondern vergrößert.

Mit dem stimme ich nicht überein. Denn alle, die einen Rootserver wollen haben heute auch einen - die sind ja so günstig, und sorgen sich nicht viel um Sicherheit.
Ich denke ein Paar How-Tos zum abtippen würden nicht die Anzahl der unwissenden Rootserver-Kunden vergrössern.

[wgot]

Hallo,

Ich glaube, die Herren User und Wgot kämpfen mit extremen Ansichten auf verlorenem Posten.

wühl Dich mal durch das Forum, dann wirst Du sehen, daß Du die Namensliste noch ein paar Mal verlängern mußt. :oops:

... Anbieter von Rootservern ...

Daß deren Handeln umsatzorientiert ist brauchen wir wohl nicht zu diskutieren.

Meiner Ansicht nach sollten Anbieter von Rootservern die Option anbieten, das alles vorzuinstallieren, samt Anleitung wie man es danach pflegt.

Was vorinstallieren? Tools und Einstellungen die nur das Sicherheitsgefühl aber nicht die Sicherheit erhöhen? Wo siehst Du da einen Vorteil (außer für den Umsatz)?

Gruß, Wolfgang