Kleine Hilfe für Angehende vServer Neulinge

[slade87]

Nachdem nun einige Freunde von mir ebenfalls auf die Schnapsidee gekommen sind das ein vServer die richtige Wahl ist und natürlich prompt Probleme auftraten möchte Ich hier mal ein paar Sachen zu etwas größerer Sicherheit zusammenfassen.
Ob die Wahl eines vServer nun richtig ist liegt bei euch und ist euer Risiko aber bitte bringt etwas Eigeninitiative und Lernbereitschaft mit. So ein Server ist eine tickende Zeitbombe bei laienhafter Benutzung. Seit Ihr euch darüber im Klaren könnt ihr weiterlesen. Falls euch das bereits langweilt lasst es einfach mit dem Server.

Mail Schleuder Risiko minimieren

Unglaublich aber wahr innerhalb von Sekunden könnt ihr als Spam Schleuder enden. Deshalb solltet ihr zuerst ein Mal einen Test auf Open Relay starten (http://www.mailradar.com/openrelay/). Open Relay bedeutet das jeder euren Mail Server selbst ohne Login nutzen kann. Sehr gerne für SPAM genutzt. Bekommt ihr dort einen Fehler schleunigst herunterfahren und erst einmal Recherchieren wie ein Open Relay wieder geschloßen werden kann.
Zweiter Punkt den Ich immer häufiger Beobachte die Attacken auf z.B. courier pop und imap. Dabei lässt sich die Anzahl der Attacken deutlich reduzieren in dem z.B. nur ssl genutzt wird. Dazu einfach /etc/courier/pop3d und /etc/courier/imap die Einträge : ..START=NO damit starten pop3 und imap schonmal nicht. Als nächstes einfach /etc/courier/pop3-ssl und imap-ssl öffnen .. START = YES und .._TLS_REQUIRED=1 damit werden schon die meisten Angriffe verhindert da seltener meiner Erfahrung nach SSL Angriffe gestartet werden. Natürlich auch keine Sicherheit aber zumindest nutzt ihr und eure Benutzer jetzt auch Verschlüsselung beim Mail Abrufen und damit schützt Ihr euch auch selbst vor Account Diebstahl ein wenig. Am Ende übernehmt ihr die Einstellungen mit service courier-imap restart. Ihr könnt auch die Standardports ändern und z.B. gen 1000 legen aber vergesst euer E-Mail Programm dabei nicht, das will auch eingestellt werden.

Apache ... Wordpress
Sehr gerne wird einfach der Apache der Standard (Plesk Konfiguration) genutzt und schon stehen Tür und Tor offen für die Scriptkiddies. Was wollen wir nun zuerst tun? Erst einmal sollte euch bewusst sein das Apache gerne mit mod_php läuft, das bedeutet das auch alle php Scripte als www-data Benutzer laufen. Schlechte Idee. Als stellt hier erst einmal auf Php als Fast-CGI um. Viele von euch Nutzen Plesk deshalb hier kurz die Erklärung -> Einloggen in Plesk -> Website&Domain -> Domain anklicken dann könnt ihr PHP unten als Fast-CGI auswählen. Damit läuft php dann auch als eigener User.
Als nächstes wäre eine Möglichkeit sich mit mod_security modul einzuarbeiten. Das ganze geht relativ simpel aber gerade die PHP Buden wie WordPress und phpBB3 haben gerne Probleme damit. Dafür schützt es schon einwenig vor XSS, SQL-Inj. und so weiter. Bitte googlet es, irgendwann seit Ihr dankbar es zu haben natürlich bietet das auch keine 100% Sicherheit aber viele Angriffe sind nunmal auf ungeschützte Ziele ausgelegt. Wer reinkommen will findet immer einen Weg.
Was nun noch? Wordpress ist ein mächtiges Tool aber auch hier gibt es gerne Angriffe auf die Admin Oberflächen oder SPAM in Kommentaren.
Gegen den SPAM habe ich gute Erfahrungen mit dem Plugin "MP Spam be Gone" gemacht es gibt aber sicherlich Alternativen. Als zweites solltet ihr mal eure wp-config.php öffnen und den Admin Bereich mit SSL laufen lassen.
Fügt die Zeile : define('FORCE_SSL_ADMIN', true);
gleich nach dem <?php hinzu. Dasselbe geht natürlich auch für andere CMS und sollte meiner Meinung nach immer gemacht werden.

Ich will Gameserver, TS3 .....
Auch hier gibt es einige Sachen zu beachten,
erstens immer einen eigenen Linux User dafür erstellen niemals mit root die Sachen laufen lassen. Sonst ist die Bude ganz schnell nich mehr eure. Wie man einen Linux user anlegt setze ich hier einmal vorraus.
Bei TS3 solltet ihr außerdem Passwörter aussreichender Länge für euren TS Server nutzen (z.B. Clan TS3) sinn und Zweck der Sache in der Regel wollt ihr ja nicht jeden auf dem TS3. Außerdem ist TS3 eine Schöne Fileschleuder und kann zum Filesharen missbraucht werden ohne das ihr es merkt.
GameServer allgemein auf vServern finde ich nur bei guten Ressourcen Garantien halbwegs sinnvoll. Aber das könnt ihr entscheiden.

DenyHosts
Tja kaum ist der Server online fliegen schon die ersten SSH Attacken ins Haus. Wie kann man zumindest die Wörterbuch Attacken etwas minimieren? Richtig mit einem Tool wie z.B. DenyHosts. Selbst in der Standard Installation ist DenyHosts schon halbwegs brauchbar. http://wiki.carrot-server.com/userdokus/denyhosts_einrichten
Hier mal ein Link. In der Regel sperrt man über ssh auch gleich den root User mit aus und legt sich stattdessen einen normalen Benutzer an und loggt sich dann im Terminal auf den Root wenn man ihn denn braucht.
in der /etc/ssh/sshd_config:
AllowUsers [username]
oder:
AllowGroups users
Damit kann man sshd Zugang nur für die genannten Benutzer/Gruppen zulassen. Ich empfehle dafür auch etwas andere Namen zunutzen die nicht in Wörterbüchern stehen anstelle von webmaster, gameserver oder sonstige Namen für Benutzer.

Passwörter
Eigentlich sollte es mit gesunden Menschverstand klar sein aber viele vergessen einfach ein Server ist keine E-Mail Adresse. Passwörter sind hier unglaublich wichtig. Im Notfall schreibt es euch an eurem Computer auf PAPIER und legt es neben euch. Sobald ihr es auswendig gelernt habt verbrennt das Papier . Aber mal im Ernst nutzt ordentliche Passwörter unter 12 Zeichen sowieso nicht und schon gar nicht normale Wörter wie MeineKatzeIstToll <-- Selbst wenn das ja sogar schon etwas länger dauert.
Am besten wären natürlich 20 Zeichen bestehend aus Zeichen, Zahlen und Sonderzeichen. Im Notfall lasst ihr euch über einen Passwortgenerator ein paar mit entsprechender Länge generieren und nutzt das wenn euch nix einfällt.
Das Gilt übringens auch eure Mail/FTP sonst was Accounts auf dem Server!

Updates, updates, updates
Die Updates eurer Distributionen sind keine Spaß an der Freunde updates hier geht es um Sicherheit selten um neue Funktionen. Deshalb nutzt sie. Wenn schon keine Security mailing Listen durchgeschaut werden haltet eurer System wenigstens aktuell. Die meisten ausgenutzten Sicherheitslücken kommen von alten Paketen.
Bei Debian z.b. reicht einfach: apt-get update && apt-get upgrade

Logs
Auch wenn ihr nicht alles versteht schaut öfters unter /var/log nach und sucht nach massenhaften Fehlermeldungen/E Mail versand/Login etc.
Habt ihr Bedenken postet es. Mit Logs kann euch immer geholfen werden bei Fragen. Mit der Zeit versteht ihr dann auch was da steht.

Ich glaube ich bin Opfer geworden
Fahr die Bude herrunter und fertig.
Es gibt kein Warten bei ich Glaube. Bis das Gegenteil bewiesen ist Bude unten lassen. Es macht keinen Sinn, Auch nicht für Backups hochfahren etc. Die Bude bleibt unten Basta. Auch wenn ihr denkt ihr bekommt es hin lasst es einfach. Lieber ein Kontakt zum Support falls es um wichtige Daten geht und eine Analyse durchführen lassen. Die kennen sich aus und schließen für euch auch Sicherheitslücken das wird auf jedenfall günstiger als eine Klage.

Aber mein Freund kennt sich damit aus ...
In der Regel kann man sagen euer Freund hat keine Ahnung. Ein Linux mal installiert zu haben qualifiziert hier in der Regel keinen. Ist es ein Ausgebildeter Informatiker/System Administrator kann man ihn natürlich zu Hilfe rufen aber bitte nix mit Freunden die mal einen Computer zusammen gebaut haben und sich als Experte darstellen das bringt euch im Endeffekt meistens sogar noch mehr Sicherheitslücken als vorher

Firewall einstellen
Lasst es. Beziehungsweise regelt vielleicht ein paar denys über euer Plesk oder cPanel. Die meisten Hoster haben bereits eine halbwegs ordentlich eingestellte Firewall für euch. Wenn ihr euch unsicher seit ladet euch einen Portscanner und testet euren Server auf offene Ports und schließt ungewünschte in Plesk (z.B. MySQL und Samba Windows File Sharing sind sehr oft offen ist mir aufgefallen). Lasst es mit der Shell bitte bleiben.



So Ich hoffe ich konnte ein bisschen Anregungen geben. Bitte fasst das hier nicht als umfassendes und 100% Sicherungskonzept auf. Es handelt sich um relativ einfach bewältigende Aufgaben um zumindest die Standard Attacken einwenig einzudämmen und das Risiko zu dämpfen. Also nocheinmal wer rein möchte schafft dies auch.

 

[TerraX]

Dein Beitrag hat ein wesentliches Problem. Die angesprochene Zielgruppe liest ihn nicht sondern schlägt hier auf, wenn die Kacke schon am Dampfen ist und/oder nix richtig läuft. Das sind dann Topics mit den Schlüsselwörtern: Hilfe! Ganz dringend! usw.

Punkt 2: Die Zielgruppe ist mit dem Text überfordert, weil sie nömlich zusätzliche Informationen beschaffen und solide Grundkenntnisse zum OS und der installierten Software haben müsste.

 

[d4f]

Dabei lässt sich die Anzahl der Attacken deutlich reduzieren in dem z.B. nur ssl genutzt wird.

Und was ist mit explizitem SSL durch 'starttls'?
Man sollte nicht erwarten dass alle Clients implizites SSL unterstuetzen oder verwenden wollen.

Erst einmal sollte euch bewusst sein das Apache gerne mit mod_php läuft, das bedeutet das auch alle php Scripte als www-data Benutzer laufen. Schlechte Idee.

Erklaere bitte.
Die Verwendung von mod_php bedeutet nicht dass alle Benutzer unter dem gleichen Unix-Account laufen; dafuer gibt es MPM's wie mpm_itk welche sogar die Angriffsflaeche weiter reduzieren da der gesamte Prozess unter dem User-Account rennt.
Wenn man nur einen einzigen Kunden auf einem Server hostet (sich selbst), wieso sollte man die ressourcenlastige fastcgi Methode verwenden?
www-data ist auch nur ein eingeschraenkter Benutzer...

Das ganze geht relativ simpel aber gerade die PHP Buden wie WordPress und phpBB3 haben gerne Probleme damit. Dafür schützt es schon einwenig vor XSS, SQL-Inj. und so weiter.

Dafuer gibt es (als 'delayed' kostenfreie) Regeln welche sehr wenige false-positives haben und auf bekannte und moegliche Luecken zugeschnitten sind.
Ein solches Beispiel sind Atomicorp's WAF rules (ehem. GotRoot)

Wordpress ist ein mächtiges Tool aber auch hier gibt es gerne Angriffe auf die Admin Oberflächen oder SPAM in Kommentaren.

Was hat das mit Server zu tun? Fast alle Wordpress- und Joomla-Angriffe sind auf Plugins und Extensions und nicht den (recht sicheren) Core gezielt.

Gegen den SPAM habe ich gute Erfahrungen mit dem Plugin "MP Spam be Gone" gemacht es gibt aber sicherlich Alternativen.

Akismet?

Wie kann man zumindest die Wörterbuch Attacken etwas minimieren? Richtig mit einem Tool wie z.B. DenyHosts.

Oder viel einfacher durch Verlegen des Ports. Unterm Strich genau so effektiv und viel einfacher, unkomplizierter und risikofreier.

In der Regel sperrt man über ssh auch gleich den root User mit aus und legt sich stattdessen einen normalen Benutzer an und loggt sich dann im Terminal auf den Root wenn man ihn denn braucht.

Nach welchem Prinzip? Wenn ich auf die Serverkonsole verbinde, dann in aller Regel um diesen zu warten. Ausser mit skriptbasierten Tools Probleme zu bereiten tut es nicht viel.
Man kann uebrigens 'root' umbenennen und somit die 'security by obscurity' genau so erreichen. (Achtung; meines Wissens gibt es zumindest unter RedHat-Derivaten damit teilweise Probleme).
Ein (meines Erachtens ebenfalls nicht wirklich helfender) Tipp waere die Verwendung von Keyfiles statt Passwort.

Im Notfall schreibt es euch an eurem Computer auf PAPIER und legt es neben euch. Sobald ihr es auswendig gelernt habt verbrennt das Papier

EEEEEEEK. Post-IT Notes mit Passwoerter sind der Alptraum eines jeden Sysadmins. Ein guter Vorschlag waere KeePass um die Passwoerter zu verwalten und generieren. KeePass-Datenbanken sind uebrigens ausreichend sicher um sie einem externen Anbieter - zB Dropbox - an zu vertrauen.

Lasst es mit der Shell bitte bleiben

 

[slade87]

Ich glaube du missverstehst den Post etwas. Es geht um die Leute die sich einen Server mieten wollen und keine besonders große Ahnung von Linux haben. Stattdessen mit ihrem Plesk rumklicken.

Und was ist mit explizitem SSL durch 'starttls'?
Man sollte nicht erwarten dass alle Clients implizites SSL unterstuetzen oder verwenden wollen.

Es heißt ja auch nur z.B. natürlich kann man alles einstellen wie man möchte. Nebenbei wäre auch ein Require_TLS möglich.

Erklaere bitte.
Die Verwendung von mod_php bedeutet nicht dass alle Benutzer unter dem gleichen Unix-Account laufen; dafuer gibt es MPM's wie mpm_itk welche sogar die Angriffsflaeche weiter reduzieren da der gesamte Prozess unter dem User-Account rennt.
Wenn man nur einen einzigen Kunden auf einem Server hostet (sich selbst), wieso sollte man die ressourcenlastige fastcgi Methode verwenden?
www-data ist auch nur ein eingeschraenkter Benutzer...

In erster Linie geht es mir darum www-data von php zu trennen. Wenn Berechtigungen sowieso mit 777 vergeben werden weil etwas nicht funktioniert dann hat das natürlich keinen Sinn. Nebenbei kann fast-cgi auch Ressourcensparend laufen.

Dafuer gibt es (als 'delayed' kostenfreie) Regeln welche sehr wenige false-positives haben und auf bekannte und moegliche Luecken zugeschnitten sind.
Ein solches Beispiel sind Atomicorp's WAF rules (ehem. GotRoot)

Guter Einwurf! Die sind auch einfach hand zu haben und funktionieren in der Regel problemlos mit CMS.

Was hat das mit Server zu tun? Fast alle Wordpress- und Joomla-Angriffe sind auf Plugins und Extensions und nicht den (recht sicheren) Core gezielt.

Das hat per se nichts mit Servern zu tun. Aber in der Regel werden diese CMS haufenweise ob nun für Blogs oder co von Neulingen eingesetzt.

Akismet?

Persönlich bin ich kein Fan.

Oder viel einfacher durch Verlegen des Ports. Unterm Strich genau so effektiv und viel einfacher, unkomplizierter und risikofreier.

Verlegen der Ports ist immer eine gute Idee. dagegen ist nichts einzuwenden aber wo liegt das Problem mit DenyHosts?

Nach welchem Prinzip? Wenn ich auf die Serverkonsole verbinde, dann in aller Regel um diesen zu warten. Ausser mit skriptbasierten Tools Probleme zu bereiten tut es nicht viel.
Man kann uebrigens 'root' umbenennen und somit die 'security by obscurity' genau so erreichen.

Natürlich ist root vollkommen in Ordnung, mit ordentlichem Passwort. Über einen normalen User auf die Shell und dann auf root sehe Ich kein Problem plus man hat eine doppelte Authentifizierung. Was hat das mit skriptbasierten Tools zu tun? Der root Zugriff über SSH ist einfach von außen gesperrt. without-password und KeyFile kann man natürlich auch nutzen.

Wenn Sie keine Ahnung von der Shell haben sollen Sie auch nicht mit IpTables rumhantieren. Das macht in der Regel mehr kaputt als es gut ist.

 

[TerraX]

Ich glaube du missverstehst den Post etwas. Es geht um die Leute die sich einen Server mieten wollen und keine besonders große Ahnung von Linux haben. Stattdessen mit ihrem Plesk rumklicken.

...

Wenn Sie keine Ahnung von der Shell haben sollen Sie auch nicht mit IpTables rumhantieren. Das macht in der Regel mehr kaputt als es gut ist.

Genau da liegt der Hase im Pfeffer. Genau diese Leute sollten sich eben nicht einen Server mieten, zumindest nicht ohne die fachmännische Betreuung sichergestellt zu haben.

Deine "Anleitung" beleuchtet nur kleine Detailpunkte, welche aber nichts nützen, wenn man das Gesamtbild nicht versteht.

FastCGI ist nicht per Definition sicherer als mod_php. Schlechte Scripte oder fehlende Updates und/oder unsichere php.ini-Einstellungen sind für jedes System der Tod. FastCGI ist IMHO deutlich aufwendiger zu konfigurieren und hat in einigen Situationen Stabilitätsprobleme, die mit mod_PHP nicht auftreten. Es gibt also nicht Schwarz und Weiß - und genau auch hier ist das wieder der Punkt: Ich sollte mich bewusst für das eine oder andere Konzept entsprechend dem Einsatzszenario entscheiden. Dafür braucht es Know-how.

Ebenso der Hinweis zu mod_security. Damit es sinnvoll eingesetzt werden kann, muss man verstehen wie es funktioniert und wie man Regeln selbst definiert - nur so kann man echt zeitnah auf Lücken reagieren, für die es noch keinen Patch gibt. Klar gibt es frei verfügbar schöne Muster-Sets aber da sie meist verzögert kommen, könnte eine evtl. Lücke schon ausgenutzt worden sein. Man muss sich mit den Rulesets auf explizit auseinandersetzen sonst kauft man sich mehr Probleme ein (Performance, Scripte funzen nicht mehr korrekt) als man damit löst.

Zu sshd: es spricht nichts dagegen sprechende Benutzernamen zu verwenden. Mit public-key-auth only sowie allow_users kann man wunderbar begrenzen, wer per ssh auf den Server zugreifen darf. Den Einsatz von automatischen IP-Ban-Tools sehe ich kritisch - bei gefälschten IP-Adressen und ähnlichen Scherzen sperrt man damit alles mögliche nur nicht das was man wollte.

 

[slade87]

Genau da liegt der Hase im Pfeffer. Genau diese Leute sollten sich eben nicht einen Server mieten, zumindest nicht ohne die fachmännische Betreuung sichergestellt zu haben.

Ich glaube da hast du leider Recht. Diese Leute werden wahrscheinlich nicht auf die Idee von selbst kommen sich weiterzubilden. Trotz allem wollte ich zumindest ein paar Detailpunkte vor Augen führen. Es sollte eigentlich auch zum selbstständigen Nachforschen anregen. Aber wenn ich einige Posts hier verfolge sehe ich ein das es bei vielen einfach keinen Sinn macht...

 

[Deleted member 14254]

Guten Morgen liebe Runde

Ich hätte da mal eine (vielleicht dumme) Frage zu:

1. User, unter dem Apache läuft
2. php.ini

Zu 1. Ich verwende gentoo, ohne jegliches Plesk/cPanel usw. In Linux wird nicht "geklickt" Dafür hab ich Windows auf der anderen Platte (im Home-PC natürlich) Im gentoo-Apache läuft ein sogenannter mpm-worker, der die Aktionen unter anderem Benutzernamen/Gruppe ausführt, also NICHT root. Dafür gibt es beispielsweise in gentoo die gruppe "apache". (Wie in Ubuntu und anderen Debian-Varianten sowie Debian selbst): "www-data". Im Ubuntu-apache HowTo wird jedoch drauf hingewiesen, BITTE die apache-relevanten Dinge NICHT unter user und gruppe "www-data" auszuführen, da, wenn es einen Angriff in Apache gibt, dadurch auch beispielsweise andere Websiten kompromittiert werden können - die ebenfalls unter - in dem besagten Fall "www-data" laufen.

Zu 2. In gentoo gibt es 3(!) php.ini. Eine "apache"-php.ini (/etc/php/apache-php/php.ini --- /etc/php/cgi-php --- /etc/php/cli-php...) Ich sitz grad nicht dran, deshalb weiss ich die genauen Ordnernamen nicht im Kopf (da dieser absolut im roten Recourcenbereich derzeit ist). Auf jeden Fall: apache-relevate php.ini /cli und cgi.
Ich habe bei mir nur den apachen mit php am laufen...
Nur: Wenn man die letzten Beiträge so liest... Ich glaub schon fast, "in dem Moment wo php läuft ist man ein offenes Scheunentor. Klar kann man php durch Abschaltung einiger Optionen (sage mal als Beispiel: fopen-wrapper) "sicherer machen"... Doch alleine schon DANN funktioniert Joomla nicht mehr (Joomla-Update). Dieser braucht "fopen-url". Diese Funktion ist auch standardmäßig ausgeschaltet gewesen in den Versionen bis Neujahr. Seit 2012 ist die Option aktiviert per standard...
Was man noch tun könnte: Save-Mode... Nur dann funktioniert wahrscheinlich "überhaupt nichts" mehr so wie es soll...

Abhilfe? OHNE php... Nur... Dann kann ich mir auch das Webpaket von 1&1 für 3,95€ mieten. Denn mehr als die "5-Klick-Homepage" wird meine Seite dann nicht können...

Entweder "ZU sicher" und der Komfort ist ohne Ende eingeschränkt.
ODER grosszügigere (aber trotzdem beherzte) Einstellungen - aber trotzdem ist der Server offen wie ein Scheunentor...

Wär schön, wenn es noch einen "Mittelweg" gebe... Aber es gibt nur Widersprüche. Einer sagt beispielsweise Failban=Schei**e. Anderer sagt "MUSTHAVE"... Einer sagt "HostDeny" sei IP-Tables vorzuziehen... IpTables seien der absolute "GAU"... Wenn ich es "SO" sehe, ist alles, was im Web ist (und mit Roots im RZ utun hat) der SuperGAU...

 

[danton]

Im Ubuntu-apache HowTo wird jedoch drauf hingewiesen, BITTE die apache-relevanten Dinge NICHT unter user und gruppe "www-data" auszuführen, da, wenn es einen Angriff in Apache gibt, dadurch auch beispielsweise andere Websiten kompromittiert werden können - die ebenfalls unter - in dem besagten Fall "www-data" laufen.

Bitte mal den Link zum Howto. Ich glaube aber, du hast da was falsch verstanden...

In gentoo gibt es 3(!) php.ini.

Es wird aber nur eine verwendet. Die im apache-Verzeichnis, wenn du mod-php nutzt, die im cgi-Verzeichnis, wenn du CGI/FastCGI nutzt und die im CLI-Verzeichnis, wenn du PHP auf der Kommandozeile nutzt. Da können je nach Einsatzgebiet andere Einstellungen sinnvoll sein.

Entweder "ZU sicher" und der Komfort ist ohne Ende eingeschränkt.
ODER grosszügigere (aber trotzdem beherzte) Einstellungen - aber trotzdem ist der Server offen wie ein Scheunentor...

Die Kunst ist es, die Gratwanderung zwischen Komfort und SIcherheit zu meistern.

 

[TerraX]

1. Teilzitat:
Ich verwende gentoo, ohne jegliches Plesk/cPanel usw. In Linux wird nicht "geklickt" Dafür hab ich Windows auf der anderen Platte (im Home-PC natürlich) ...

2. Teilzitat:
Im gentoo-Apache läuft ein sogenannter mpm-worker, der die Aktionen unter anderem Benutzernamen/Gruppe ausführt, also NICHT root. Dafür gibt es beispielsweise in gentoo die gruppe "apache". (Wie in Ubuntu und anderen Debian-Varianten sowie Debian selbst): "www-data". ...

3. Teilzitat:
Abhilfe? OHNE php... Nur... Dann kann ich mir auch das Webpaket von 1&1 für 3,95€ mieten. Denn mehr als die "5-Klick-Homepage" wird meine Seite dann nicht können...

4. Teilzitat:
Entweder "ZU sicher" und der Komfort ist ohne Ende eingeschränkt.
ODER grosszügigere (aber trotzdem beherzte) Einstellungen - aber trotzdem ist der Server offen wie ein Scheunentor...

Wär schön, wenn es noch einen "Mittelweg" gebe... Aber es gibt nur Widersprüche. Einer sagt beispielsweise Failban=Schei**e. Anderer sagt "MUSTHAVE"... Einer sagt "HostDeny" sei IP-Tables vorzuziehen... IpTables seien der absolute "GAU"...

Zu 1: Selbstverständlich braucht man auch an der SSH-Konsole nicht auf gewissen "Bedienungscomfort" zu verzichten. Ich verwende z.B. sehr gern mc (midnight commander), der dem alten Norton Commander unter DOS damals sehr ähnlich ist, für die meisten Dateiverwaltungstätigkeiten und das Editieren, weil ich es bequemer finde ... nur mal so als Tip für einen Mittelweg, es gibt da auch ne etwas zwischen shell/vi und grafischer Oberfläche

Zu 2:
Deine Ausführungen zeigen das du die Webserver-Installation noch nicht richtig verstanden hast. Der Einsatz des Apache mit mpm-worker-Modul weist mit ziemlicher Sicherheit auf den Einsatz von PHP als FastCGI hin. Zu diesem Konstrukt gehört suexec. Letztlich kann PHP dann für jeden vHost unter anderer user/group ausgeführt werden. Der User unter dem der Apache läuft ist bei PHP von etwas untergeordneter Bedeutung (solange hinreichend eingeschränkt), da die eigentlichen interessanten/"gefährlichen" Aktivitäten/Operationen vom PHP-Interpreter ausgeführt werden. Der Apache selbst läuft aber noch unter der in der main-config festgelegten user/group-Kombi.

Der Vorteil von mpm-worker ist ein geringerer Speicherverbrauch des Apachen im Gegensatz zu mpm-prefork, da nicht bei jeder Anfrage ein eigener Prozess gestartet wird. Nachteil, mpm-worker ist nicht threadsafe (Prozesse haben im Gegensatz zu Threads einen eigenen Speicherbereich). Das bedeutet beim Einsatz von PHP ein paar Einschränkungen, weil u.a. PHP threadsafe nämlich genau voraussetzt und die Config ist deutlich aufwendiger. Damit ist CGI/FastCGI potentiell gegen Buffer Overflows anfälliger - genau das ist hier auch der Tradeoff zwischen Performance und Sicherheit.

mpm-prefork hat dagegen das Problem, das alle Scripte unter dem Webserver-User/Group ausgeführt werden und damit auch vHost-übergreifend ggf. agieren können. Aber auch hier gibt es eine Lösung, welche mpm-itk heißt. Damit kannst Du auch jeden vHost unter einem seperaten user/group laufen lassen und php weiterhin ganz normal als Modul (mod_php) laufen lassen. mpm-itk ist also ein mpm-prefork-per-user sozusagen. Damit entfallen dann auch safe-Mode-Restriktionen falls gewünscht. Die Config ist ähnlich einfach wie Standard mpm-prefork/mod_php.

Was ich mit dem Exkurs zeigen will: Es genügt nicht, ein How-to und die damit verbundenen Begriffe zu verstehen sondern man muss sich verschiedene Szenarien ansehen und dann beginnt man zu verstehen und kann eine fundierte Entscheidung treffen.

Zu 3.
Das ganze Leben ist ein Risiko. Auch Perl und andere Interpreter hatten in der Vergangenheit Schwachstellen. Risikomanagement heißt das Zauberwort - einfach formuliert Eintrittswahrscheinlichkeit * Schadenshöhe. Setzen wir mal die Kompromittierung des Servers (als Schaden) als eine feste Größe X ist also nur noch die Eintrittwahrscheinlichkeit relevant.

Wofür gibt es die meisten Hacks und Probleme bei PHP? Bei den Webanwendungen selbst. Ursache? Updates nicht zeitnah durchgeführt, unsichere Addons installiert, Sicherheitsmeldungen nicht zeitnah beachtet.

Beachtet man das und hat das System im Hintergrund darauf getrimmt, dass wirklich nur das zugelassen, installiert und ausgeführt wird, was auch tatsächlich notwendig ist - dann ist man schonmal auf der ziemlich sicheren Seite. Dabei sollte das System natürlich auch zum Einsatzszenario passen.

Zu 4.
Es gibt nicht DIE allgemein perfekte Lösung. Das ist ja auch das, was ich beim TE kritisiert habe. Alles hat sein Für und Wider. Die Kunst besteht nun darin, sich alle Argumente anzuhören, selbst zu recherieren und mit der eigenen Situation abzugleichen, um sich letztlich eine eigene Meinung zu bilden. Dann heißt es umsetzen und Erfolg beobachten. Dabei gilt in der IT oftmals - für eine einmal gefundene Lösung gibt es keine Status Quo. Anpassung heißt die Devise, d.h. regelmäßige Überprüfung der veränderten Rahmenbedingungen sowie Stand der Technik und Abgleich mit den eigenen Sollanforderungen und Ist-Zustand -> Bewertung -> Umsetzung von ggf. Handlungsbedarf.

Wie hier schon oft erwähnt - IT-Sicherheit ist kein Zustand sondern ein ständiger ablaufender Prozess. Der Umfang der notwendigen Tätigkeiten bemisst sich natürlich am jeweilgen Einsatzszenario (RZ, Shopbetreiber, private Homepage ...).

 

[Joe User]

Nachteil, mpm-worker ist nicht threadsafe (Prozesse haben im Gegensatz zu Threads einen eigenen Speicherbereich). Das bedeutet beim Einsatz von PHP ein paar Einschränkungen, weil u.a. PHP threadsafe nämlich genau voraussetzt und die Config ist deutlich aufwendiger. Damit ist CGI/FastCGI potentiell gegen Buffer Overflows anfälliger - genau das ist hier auch der Tradeoff zwischen Performance und Sicherheit.

Das ist nicht ganz korrekt
Apache ist threadsafe, einige PHP-Extensions hingegen sind nicht threadsafe und sorgen somit für (teils erhebliche) Stabilitätsprobleme in Verbindung mit MPM-Worker und vergleichbaren Konstrukten.
PHPs FastCGI-Implementation ist übrigens dermassen kaputt, dass man es nichtmal reparieren kann, weshalb irgendwann ein paar genervte externe Entwickler PHP-FPM gebastelt haben und dieses mitlerweile so gar in PHPs Core aufgenommen wurde.

 

[TerraX]

Ah oki, danke - stimmt. Da habe ich etwas durcheinander gehauen. Yepp, ist logisch, bei mpm-prefork tritt das Prob nicht auf, da alles in eigenen Prozessen abgewickelt wird im Gegensatz zu mpm-worker.

 

[Deleted member 14254]

Hallo zusammen

Bitte mal den Link zum Howto. Ich glaube aber, du hast da was falsch verstanden...

Hier ist der Link, danton:

http://wiki.ubuntuusers.de/Apache

Das was ich meine befindet sich zwischem ersten und 2ten Drittel des besagten wikis:

Rechte

Falls in einem Mehrbenutzer System Personen Schreibrechte für die html Dateien gegeben werden soll, sollte dafür eine Gruppe angelegt werden. Dies ist nicht notwendig, wenn dort nur ein Mitglied der „admin” Gruppe Inhalte platzieren soll. Diese können mit sudo Dateien dort hin kopieren.

Soll nicht Admins Schreibzugriff gewährt werden, muss dafür eine Gruppe angelegt werden. Dies ist in dem Beispiel die Gruppe www. Dieser Name kann aber frei vergeben werden. Dieser Gruppe Schreibrechte auf den /var/www/ Ordner gegeben werden und die Nutzer hinzufügt werden. [5]

sudo groupadd www
sudo adduser <benutzername> www
sudo chgrp www /var/www
sudo chmod g+w /var/www 

Damit die neuen Rechte greifen, muss man sich einmal ab- und neu anmelden.
Hinweis:

[B]Es sollte nicht die „www-data“ Gruppe genutzt werden. Unter dieser Gruppe läuft der Apache Webserver und sollte ein Angreifer eine Lücke in dem Apache finden, so erhält er unnötiger weise Schreibrechte auf den /var/www/ Ordner.[/B]

Deine Ausführungen zeigen das du die Webserver-Installation noch nicht richtig verstanden hast. Der Einsatz des Apache mit mpm-worker-Modul weist mit ziemlicher Sicherheit auf den Einsatz von PHP als FastCGI hin.

Das ist möglich, das ich das noch nicht zu 100% "inne" habe. Das gebe ich gerne zu. Ich schildere einmal genauer wie es bei mir ist. Nur "reißt mir nicht den Kopf ab, wenn meine derzeitige Konstellation derzeit ein riesiges Loch darstellen sollte..." Vielleicht können wir es gemeinsam verbessern, wofür ich Euch sehr dankbar wäre

Also:

Auszug aus /etc/conf.d/apache2

APACHE2_OPTS="-D DEFAULT_VHOST -D INFO -D SSL -D SSL_DEFAULT_VHOST -D LANGUAGE -D PHP5"

Auszug aus /etc/apache2/httpd.conf

# If you wish httpd to run as a different user or group, you must run
# httpd as root initially and it will switch.
#
# User/Group: The name (or #number) of the user/group to run httpd as.
# It is usually good practice to create a dedicated user and group for
# running httpd, as with most system services.
User apache
Group apache

Habe bei mir gesehen, das bei mir die Ordner wie /var/www/(hier befindet sich der DocRoot für die websites)
und der "eigentliche DocumentRoot" /var/www/localhost/htdocs/(hier liegen die webpanel basierten Webapplicationen wie phpmyadmin postfixadmin)
unter "root:root" laufen.
Bevor aber jetzt jemand in Ohnmacht fällt: Dies ist nur deshalb, weil in der httpd.conf beschrieben steht, das httpd als apache-user und apache-group läuft.
Ich bin selbst bei gentoo darüber überrascht... Das war ich auch von Anfang an.
Nur wie ich schon sagte: Sieh/seht Euch "HowTo1" an... und dann HowTo2 und HowTo3. Und dann gibts schonmal zu jedem HowTo, das als verstanden geglaubt wurde - 2 Widersprüche.

Derzeit sind bei mir keine Websites on. Da der Server noch nicht fertig ist. Ich möchte den Mailserver noch mit ssl konfigurieren. Dann möchte ich desweiteren ein Greylisting einsetzen. Eigentlich wollte ich, hatte ich geplant, ebenfalls einen Viren-Scanner mit einzubauen. Nur... sehr mir auch dies nicht nach: Virenscanner habe ich mein ganzes Leben lang niemals leiden können. Virenscanner - egal wie "tollkühn" oder wie "restriktiv" sie bei mir auch konfiguriert waren...
Ausser schwerwiegende Systemstörungen haben sie bei mir nichts in Erinnerung belassen.

Auch hierzu habe ich einen Link: http://de.wikipedia.org/wiki/Antivirenprogramm

Dazu ein Auszug:

Kritik an Virenscannern

Die Zuverlässigkeit und Wirksamkeit von Virenscannern wird oft angezweifelt. So vertrauen nach einer Studie drei Viertel der befragten Systemadministratoren (Admins) oder Netzwerkbetreuer den Virenscannern nicht. 40 Prozent der befragten Administratoren hatten bereits darüber nachgedacht, die Virenscanner zu entfernen, weil diese die Performance des Systems negativ beeinflussen. Vielfach werden Virenscanner eingesetzt, weil die Firmenrichtlinien dieses forderten, so die Umfrage. Hauptgrund sei die tägliche Flut neuester unterschiedlichster Varianten von Schädlingen, die das Erstellen und Verteilen von Signaturen immer unpraktikabler machten.[32] Es sei anzumerken, dass diese Studie von einer Firma erstellt wurde, die eine Software vertreibt, die anhand von Positivlisten das Ausführen von Programmen erlaubt. Dieser „Whitelisting“-Ansatz hat je nach Einsatzgebiet ebenso Vor- und Nachteile.

Es entspricht exakt meiner Meinung über AV-Scanning-Programme.

 

[danton]

Du hast das Howto nicht ganz verstanden. Der Apache-User www-data braucht natürlich erst mal nur lesenden Zugriff auf die Dateien im Doc-Root und seinen Unterverzeichnissen, zumindest, solange es sich um statische Inhalte wie HTML-Dateien und Bilder geht.
Jetzt kommt aber das große Aber: Scripte (ob PHP, Perl etc. ist dabei unerheblich) brauchen für einige Funktionen Schreibzugriffe, beispielsweise Bildergalerien oder auch nur einfache Update-Funktionen in einem Forum zur einfache Installation von eben den Updates.
Dann kommt noch dazu, wenn man auf einem System mehrere Webseiten von unterschiedlichen Personen (z.B. Kunden beim Webhoster) betreibt, dann sollten diese Webseiten von einander abgeschottet sein. Ein Ansatz ist suexec, es gibt aber auch andere. Damit laufen die Scripte dann nicht mehr unter dem Apache-User www-data (Ubuntu und Debian), sondern unter dem jeweiligen User, der auf für den FTP-Upload verwendet wird.
Das Howto beschreibt übrigens eher den Fall, daß mehrere User das gleiche Web bearbeiten können sollen.

Habe bei mir gesehen, das bei mir die Ordner wie /var/www/(hier befindet sich der DocRoot für die websites)
und der "eigentliche DocumentRoot" /var/www/localhost/htdocs/(hier liegen die webpanel basierten Webapplicationen wie phpmyadmin postfixadmin)
unter "root:root" laufen.

Du verwechselst gerade den User und Gruppe der Datei/Verzeichnis mit dem User unter dem es ausgeführt wird. Bei mod_php werden Scripte i.d.R. unter dem Apache-User ausgeführt, dieser braucht dazu nur Leserechte auf die Datei. Wem sie gehört, ist dabei relativ egal. Mit suexec und CGI kann man dafür einen speziellen User konfigurieren (und der muß IIRC aus Eigentürmer der Datei sein).

 

[Deleted member 14254]

Hallo danton

Dies hier:

Damit laufen die Scripte dann nicht mehr unter dem Apache-User www-data (Ubuntu und Debian), sondern unter dem jeweiligen User, der auf für den FTP-Upload verwendet wird.

Darüber habe ich mal gelesen, (in Verbindung mit FTP/scp). Das in dem Moment, wenn jemand per FTP die zu installierenden Programme hochläd, die Dateien und Ordner die FTP-Gruppe besitzen, während, wenn per scp, dann laufen sie unter dem Benutzer, der sie erstellt - wahrscheinlich root. Ich weiß aber da nicht mehr, wo ich das gelesen habe. Wahrscheinlich im Joomlaforum, wenn ich nicht irre. Da ging es drum, warum wenn man per scp und root die Dateien auf den Server lädt, man später in den Verzeichnissen keinen Schreibzugriff hat, da apache dann (aufgrunddessen, das Schreibrechte nur ftp:ftp hat) apache beispielsweise keine config.inc.php schreiben kann.

Was mich aber jetzt doch sehr bekümmert, ist die php.ini. Also die für mich relevante php.ini ist die unter apache. Nur, ich weiss nicht wie oft ich sie schon (auch während meiner Übungszeit am lokalen Server) rauf und runtergelesen und angepasst und noch mehr angepasst habe. Ich wüsste absolut jetzt nicht, ob sie so bleiben kann wie sie jetzt ist, oder ob ich sie noch mehr entschärfen muss. Wird mir dann wohl der erste "Angriff" bestätigen

 

[TerraX]

Hmm, kleine bitte an die Mods - maybe den Part wo wir in Richtung Apache-config zu 100% abdriften abtrennen und in einen neuen Thread verschieben?

Und Neutrino, zum Thema Mailserver - maybe den Thread benutzen, den Du bzgl. der Mailserver-Howtos aufgemacht hast? Das wird sonst unübersichtlich und too much.

 

[TerraX]

...
Dann kommt noch dazu, wenn man auf einem System mehrere Webseiten von unterschiedlichen Personen (z.B. Kunden beim Webhoster) betreibt, dann sollten diese Webseiten von einander abgeschottet sein. Ein Ansatz ist suexec, es gibt aber auch andere. Damit laufen die Scripte dann nicht mehr unter dem Apache-User www-data (Ubuntu und Debian), sondern unter dem jeweiligen User, der auf für den FTP-Upload verwendet wird.
...

Nein. Bei Einsatz von suexec läuft der PHP-Interpreter unter dem User/Group, die im vHost definiert wurde. Suexec ist normalerweise so gepolt, das User und Group mit der Vorgabe aus der vHost-Config beide übereinstimmen müssen.

So zu FTP - machen wir's mal am Beispiel von vsFTP:

Nehmen wir an, user1 und user2 gehören beide zur Gruppe mydomain und sollen beide Änderungen an Dateien im docroot des vHost vornehmen können. Weiterhin gibt es auch einen systemaccount mydomain, der nur für den vHost benutzt wird. Die Vorgabe im vHost lautet also: SuexecUserGroup mydomain mydomain

Dann gibt es per default ein Problem, wenn z.B. ausführbare Scripte (PHP) von user1 und user2 hochgeladen werden, weil die nämlich owner=user/group user1/mydomain sind. Das mag suexec nicht und zaubert dir einen 500er Error auf den Bildschirm.

Eine mögliche Lösung bei vsFTP ist z.B. dass man pro-User-Configs festlegen kann und in diesen dann ein chown auf mydomain/mydomain vorgibt. Zusätzlich wäre die umask zu beachten, die auf 002 gesetzt werden müsste, IMHO.

So zum Ausgangspunkt zurück: Die Dateien im docroot haben also alle owner/group = mydomain/mydomain mit mind. 644 bzw. 755 (dirs) - bei der umask 002 beim Upload dann 664 bzw. 775. Wenn ein PHP-Script also seine config verändern will, ist das kein Problem.

Bei klassischem mpm-prefork mit mod_php gehören alle Dateien z.B. www-data/www-data. mod_PHP interessiert diese Eigenschaft grundsätzlich erstmal nicht, Hauptsache die Dateien können gelesen werden, dann werden sie auch ausgeführt. Auch in diesem Falle muss man die FTP-Config anpassen - so das die FTP-User auch www-data-Dateien editieren können (müssen zur Gruppe www-data gehören) bzw. beim Upload ein chown durchgeführt wird. Das ist zwar einfacher zu konfigurieren, da global gültig aber sicherheitstechnisch in der Kategorie: "naja, da darf nichts schiefgehen ..."

 

[Deleted member 14254]

Hello TerraX

I don't think, that I've talked about Mailservers in this Thread My issue was about the php.ini and it's Security-relations

Or did you mean this short:

Ich möchte den Mailserver noch mit ssl konfigurieren. Dann möchte ich desweiteren ein Greylisting einsetzen. Eigentlich wollte ich, hatte ich geplant, ebenfalls einen Viren-Scanner mit einzubauen.

It was an example only... Didnt want to change the theme in this thread However, sorry

 

[TerraX]

yepp, diesen Abschnitt meinte ich. Der passte irgendwie nicht in den übrigen Kontext.