Server sicher machen + PHP Performance Tips für PHP 5

[Joe]

Hallo.

Ich habe mir einen Server aufgesetzt mit Apache, php, postgresql und würde gerne wissen was gemacht werden muss, damit dieser sicher ist.

1. php.ini richtig konfigurieren
2. httpd.conf richtig konfigurieren
3. postgresql richtig konfigurieren
4. Die Skripte vor XSS und SQL Injections schützen

Das ist klar.
Aber muss ich auf meinem Server(Debian Lenny) auch noch andere wie Anti-Viren Schutz oder eine Firewall installieren?
Worauf muss ich noch achten?

2. Frage. Kennt ihr ein paar gute Links(am besten in Deutsch) zu PHP5-Performance-Tuning?
Vor allem halt was den Code angeht. Das ich ordentlich cachen und komprimieren muss ist klar.

Grüße, Joe

[Tom]

Hello,

Ich habe mir einen Server aufgesetzt mit Apache, php, postgresql und würde gerne wissen was gemacht werden muss, damit dieser sicher ist.

1. php.ini richtig konfigurieren
2. httpd.conf richtig konfigurieren
3. postgresql richtig konfigurieren
4. Die Skripte vor XSS und SQL Injections schützen

1.  Haben andere Zugriff auf den Server, außer über HTTP?
2.  Dürfen per Form oder auch per ftp use. Uploads auf den Server vorgenommen werden, z.B. Bilder?
3.  Wo liegen die Daten? -> Außerhalb der Document Root lagern!
4.  Wurden die Usernamen und Passworte vernünftig gewählt und überhaupt gesetzt?
5.  Wurde für den Zugriff auf die Datenbank per Scripten ein eigener User mit eingeschränkten
    Rechten angelegt?
6.  Wurden auf dem Host alle Dienste ausgeschaltet, die nicht benötigt werden?
7.  Findet der administrative Umgang mit dem Server über SSH statt?
8.  Sind eMail-Konten per SASL und SSL geschützt?
9.  Wurde kontrolliert, ob die verwendeten Softwareversionen auf irgendeiner Bugliste stehen?
    Bsp. war da bei einer Distribution (Debian) ein Fall mit kaputter Verschlüsselung,
    die Löcher ins Sicherheitskonzept gerissen hat.

10. ... fortzusetzen

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Joe]

Hi.

1.  Haben andere Zugriff auf den Server, außer über HTTP?

Nein.

2.  Dürfen per Form oder auch per ftp use. Uploads auf den Server vorgenommen werden, z.B. Bilder?

Ja.

3.  Wo liegen die Daten? -> Außerhalb der Document Root lagern!

/var/www

4.  Wurden die Usernamen und Passworte vernünftig gewählt und überhaupt gesetzt?

Ja, alle 8 stellig a-zA-Z0-9

5.  Wurde für den Zugriff auf die Datenbank per Scripten ein eigener User mit eingeschränkten
    Rechten angelegt?

hm nee, also es gibt den user www-data und postgres, beides Superuser aber mit dickem Passwort.

6.  Wurden auf dem Host alle Dienste ausgeschaltet, die nicht benötigt werden?

Wie überprüfe ich das bei Debian und wie stelle ich diese ggf. aus, woher weiß ich welche Dienste ich brauche??

7.  Findet der administrative Umgang mit dem Server über SSH statt?

Ja, FTP ist garnicht installiert. (SSH2)

8.  Sind eMail-Konten per SASL und SSL geschützt?

SMTP Server is noch keiner installiert. Wenn dann wären sie per SSl verschlüsselt weil ich nicht weiß was SASL ist (google ich gleich nach)

9.  Wurde kontrolliert, ob die verwendeten Softwareversionen auf irgendeiner Bugliste stehen?

Nein, wo kann ich das machen?

Bsp. war da bei einer Distribution (Debian) ein Fall mit kaputter Verschlüsselung,

Ich nutze Debian Lenny welches mir von Hetzner zur verfügung gestellt wurde,

die Löcher ins Sicherheitskonzept gerissen hat.

10. ... fortzusetzen

Sonst noch was?

Danke Tom.
Gruß, Joe

[Tom]

Hello,

Hi.

1.  Haben andere Zugriff auf den Server, außer über HTTP?
Nein.
2.  Dürfen per Form oder auch per ftp use. Uploads auf den Server vorgenommen werden, z.B. Bilder?
Ja.
3.  Wo liegen die Daten? -> Außerhalb der Document Root lagern!
/var/www

Möglichst außerhalb der Document Root ablegen. Wenn das nicht geht, weil die Biolder direkt per HTTP zugänglich sein sollen, für das entsprechende Verzeichnis die Engine Off schalten, damit nicht aus Versehen Scripte geparst werden. Beim Upload mittels getimagesize() prüfen, ob es wirklich  Bilder sind.

4.  Wurden die Usernamen und Passworte vernünftig gewählt und überhaupt gesetzt?
Ja, alle 8 stellig a-zA-Z0-9
5.  Wurde für den Zugriff auf die Datenbank per Scripten ein eigener User mit eingeschränkten
    Rechten angelegt?
hm nee, also es gibt den user www-data und postgres, beides Superuser aber mit dickem Passwort.
6.  Wurden auf dem Host alle Dienste ausgeschaltet, die nicht benötigt werden?
Wie überprüfe ich das bei Debian und wie stelle ich diese ggf. aus, woher weiß ich welche Dienste ich brauche??
7.  Findet der administrative Umgang mit dem Server über SSH statt?
Ja, FTP ist garnicht installiert. (SSH2)
8.  Sind eMail-Konten per SASL und SSL geschützt?
SMTP Server is noch keiner installiert. Wenn dann wären sie per SSl verschlüsselt weil ich nicht weiß was SASL ist (google ich gleich nach)
9.  Wurde kontrolliert, ob die verwendeten Softwareversionen auf irgendeiner Bugliste stehen?
Nein, wo kann ich das machen?
    Bsp. war da bei einer Distribution (Debian) ein Fall mit kaputter Verschlüsselung,
Ich nutze Debian Lenny welches mir von Hetzner zur verfügung gestellt wurde,
    die Löcher ins Sicherheitskonzept gerissen hat.

10. ... fortzusetzen
    Sonst noch was?

Da fehlt bestimmt noch die Hälfte

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Joe]

/var/www
Möglichst außerhalb der Document Root ablegen. Wenn das nicht geht, weil die Biolder direkt per HTTP zugänglich sein sollen, für das entsprechende Verzeichnis die Engine Off schalten, damit nicht aus Versehen Scripte geparst werden. Beim Upload mittels getimagesize() prüfen, ob es wirklich  Bilder sind.

Also z.B. /home/blabla/ oder wie meinst du? Wo?
Welche Engine auf Off? AllowOverride None?
Biolder? Na klar soll das ganze per HTTP erreichbar sein. Erkläre es bitte ein bisschen ausführlicher :)...

Da fehlt bestimmt noch die Hälfte

Ein paar Informationen mehr wären nicht schlecht. Können auch Links sein. Wenn ich diese selbt finden würde, dann würde ich nicht hier nachfragen.
Danke.

Gruß, Joe

[Joe]

Biolder? Na klar soll das ganze per HTTP erreichbar sein. Erkläre es bitte ein bisschen ausführlicher :)...

Achso, ich verstehe jetzt. Du meinst Bilder =D. Und diese sollen nicht per HTTP direkt erreichbar sein, sondern nur von der Seite ladbar sein. Also wenn die Seite geladen wird.

[Tom]

Hello,

Achso, ich verstehe jetzt. Du meinst Bilder =D. Und diese sollen nicht per HTTP direkt erreichbar sein, sondern nur von der Seite ladbar sein. Also wenn die Seite geladen wird.

Dann wären sie wieder direkt per HTTP zugänglich, wenn der Browser sie im <img>-Element als Source verwenden darf.

Wenn Du also Bilder hast, die hochgeladen werden dürfen, dann musst Du dafür sorgen:

• prüfen, ob es wirklich Bilder sind
• verhindern, dass jemand eine .htaccess-Datei hochladen kann
• verhindern, dass in dem Bilderverzeichnis PHP-Scripte geparst und ausgeführt werden,
    egal, wie die heißen.

das kannst Du in der Serverkonfiguration mit

engine off

erreichen.

• verhindern, dass Bider unter ihrem (vollständigen) Client-Namen als Datei angelegt werden.
    Dann könnte es nämlich auch passieren, dass sie einen Pfad enthalten im Namen und
    irgendwelche Dateien auf dem Server überschrieben werden oder sie irgendwo abgespeichert
    werden auf dem Server

Wenn die magic-quotes aus PHP verschwinden, wird es bei Upload-Scripten noch viele hässliche Überraschungen geben

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Joe]

Danke.

Und was meinst du jetzt wo ich das Verzeichnis hinlegen soll?

Atm: /var/www

wo soll es besser hin?

gruß, joe

[Tom]

Hello,

Und was meinst du jetzt wo ich das Verzeichnis hinlegen soll?

Atm: /var/www

wo soll es besser hin?

Na, kommt doch darauf an, wo der Webserver seine Document Root hat.
Du solltest Upload-Final-Dirs eben möglichst außerhalb der Dokument Root plazieren.

Wenn Du Deine Bilder aber dann anschließend direkt per HTTP erreichen willst, musst Du eben die anderen Maßnahmen ergreifen, die ich Dir genannt habe.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Ulli1956]

Danke.

[...]

gruß, joe

gib doch mal eine Domain, damit man schon mal weiss was man auf seine Blacklist setzen muss!

Ich hab ja auch mal klein angefangen, aber ließ doch erstmal, bevor Du mit Deinen Fragen andere nervst! Das Netz ist voll mit den Fragen und die Suchmaschine deiner Wahl stört es nicht wenn Du x-mal das gleiche fragst!

bis dann

Ulli

[Tom]

Hello Joe,

gib doch mal eine Domain, damit man schon mal weiss was man auf seine Blacklist setzen muss!

Ich hab ja auch mal klein angefangen, aber ließ doch erstmal, bevor Du mit Deinen Fragen andere nervst! Das Netz ist voll mit den Fragen und die Suchmaschine deiner Wahl stört es nicht wenn Du x-mal das gleiche fragst!

ich antworte hier unter Ullis Posting, weil der das auch lesen soll!

Mich darfst Du gerne wieder fragen. Solange erkennbar ist, dass Du die Antworten auchn liest und versuchst, sie umzusetzen, sehe ich da kein Problem. Ich fühle mich auch nicht genervt und denke, dass das viele andere hier genauso sehen.

Und wenn eine Antwort nicht gleich einleuchtet, dann frage nochmals gezielt nach. Aber Du solltest dann auch immer mitleifern, was Du versucht hast, was Du Dir dabei gedacht hast und was dabei schiefgegangen ist. Fehlermeldungen sind einzuschalten und mitzuliefern, denn sie geben wertvollen Aufschluss über das Geschehen.

Dass es darüberhinaus vorausgesetzt wird, dass Du die erreichbaren Dokumentationen ebenfalls liest, wusstest Du ja sicherlich. Manchmal weiß man einfach nur nicht, wo man da anfangen soll. Diese Tipps (Links) bekommst Du hier meistens recht schnell.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Ulli1956]

Hallo Tom,

ich antworte hier unter Ullis Posting, weil der das auch lesen soll!

Na klar lese ich das !!!!

Dass es darüberhinaus vorausgesetzt wird, dass Du die erreichbaren Dokumentationen ebenfalls liest, wusstest Du ja sicherlich. Manchmal weiß man einfach nur nicht, wo man da anfangen soll. Diese Tipps (Links) bekommst Du hier meistens recht schnell.

Siehst Du, genau da habe ich meine Zweifel!
wer sich "etwas" im Netz bewegen kann findet (Forum)Seiten die sich mit Root Servern befassen und fragt dort.
Hier frage ich, wenn etwas im Browser nicht so klappt wie ich das gerne haette --> css,java-script,html
Aber okay... belassen wir es dabei!

Gruesse mir bitte mal Bad Harzburg!

bis dann

Ulli

[Joe]

Hi Ulli,

ich frage so ziemlich alles hier was auch nur annähernd mit Webwentwicklung zu tun hat. Ich bin mit dem Board praktisch "groß" geworden und ich schenke ihm und der hier vorhandenen Kompetenzen all mein Vertrauen.

Zu mienem Lesezeichen gehören aber auch meine wichtigsten Dokumentationen: Apache, PHP und PostGreSQL.

Gruß, Joe

[Alexander (HH)]

Moin Moin!

Hier frage ich, wenn etwas im Browser nicht so klappt wie ich das gerne haette --> css,java-script,html

Der Scope vom SelfHTML-Forum ist aber viel größer, auch wenn Du das hier nur als Browser-Debugging-Veranstaltung ansiehst. Natürlich darf und soll es hier auch um Server, Design, Hosting, Recht und Design gehen. Wenn es Dir nicht paßt, dass Leute zu diesen Themen fragen stellen, solltest Du vielleicht vorschlagen, die entsprechenden Themenbereiche aus dem Forum zu entfernen - auch auf die Gefahr hin, Dich noch lächerlicher zu machen.

Ob es wirklich clever ist, dass ein Anfänger sich einen Root-Server zulegt und darauf herumbastelt, ohne wirklich einen Plan zu haben, ist eine andere Geschichte. Aber irgendwann hat man nun einmal den ersten Root-Server, und dann versucht man eben alles richtig zu machen und sich nicht in den Fuß zu schießen.

Ganz in der Luft hängt so ein Root-Server ja auch nicht. Klar, ein fertiges Hosting-Paket hat ein größeres und dichteres Sicherheitsnetz als ein Root-Server. Aber kaum ein Provider wird einen Rootserver am Netz lassen, der sich im Netz nicht "benimmt".

Mir ist das mit "meinem" ersten Root-Server passiert: Irgendwelche Scripte auf Servern in Fernost haben routinemäßig versucht, den SSH-Zugang zu knacken. Der Server hat sie alle stumpf abgelehnt, weil sie nicht das passende Zertifikat vorweisen konnten. Aber eines Tages kamen dermaßen viele Anfragen, die der Server brav mit "Du kummst hier net rein!" beantwortet hat, dass die Sicherung des Providers zugeschlagen hat und der Server automatisch vom Netz getrennt wurde. Die Lösung war recht einfach, nach kurzer Rücksprache mit dem Provider wurde der Server wieder ans Netz gehängt und läuft seitdem ungestört. Wenn innerhalb eines kurzen Zeitraums zu viele SSH-Zugriffe von einer IP-Adresse kommen, wird die IP-Adresse für SSH für eine Weile gesperrt und alle Connect-Versuche stumpf ignoriert. Rein technisch wäre das auf diesem Server gar nicht nötig, aber die Netzüberwachung des Providers fühlt sich wohler, wenn der Server auf Angriffe überhaupt nicht antwortet.

Meine anderen öffentlich erreichbaren Server haben diese Sperre drin oder haben SSH nicht auf dem Standard-Port laufen.

Alexander

[Ulli1956]

Ich nutze Debian Lenny welches mir von Hetzner zur verfügung gestellt wurde,

???
und warum fragst Du nicht dort im Forum?

siehe hier

Tippe mal das Du dort in der Form zerrissen wirst, miete Dir keinen Root, Root das mal zuhauszu hause>
weil wer " man BEFEHL " nicht kennt... gute Nacht!

Macht hoch die Tuer dTueror macht weit!

bis dann

Ulli
Ulli