Page 1 of 1
sinn von grsecurity
Posted: 2007-12-19 14:35
by royal1177
..hallo !
macht es eures Erachtens, GRSecurity überhaupt Sinn auf einem Server auf dem nur Apache+PHP läuft (kein Mysql, kein Mail, kein ......), der auch einzig und allein von uns betrieben wird (sprich keine weiteren kunden / shared hosting) ???
Re: sinn von grsecurity
Posted: 2007-12-19 17:10
by Roger Wilco
Ja, allein schon wegen der zusätzlichen Loggingmechanismen.
Re: sinn von grsecurity
Posted: 2007-12-19 17:27
by royal1177
aber in bezug auf die sicherungen habe ich keinen vorteil, wenn ich das richtig sehe ?!
Re: sinn von grsecurity
Posted: 2007-12-19 17:32
by flo
Wie schon geschrieben - dafür musst Du die erst einmal "einschalten". Die Protokollfunktionen sind relativ gut, aber auch nur dann, wenn die Logs auch gelesen werden.
Re: sinn von grsecurity
Posted: 2007-12-19 17:53
by Joe User
Gresec und SSP/PaX sind proaktive Hilfsmittel, d. h. sie greifen, sofern passend eingesetzt, bevor die eigentlichen Angriffe stattfinden. Allerdings gilt auch hier, dass nicht alle Angriffsmöglichkeiten abdecken können, siehe Dokumentation. Auch in unserem Archiv sind ein paar passssende Threads zu finden...
Re: sinn von grsecurity
Posted: 2007-12-19 17:57
by royal1177
aber meine frage ist dahingehend, dass, wenn wirklich nur apache und php läuft, grsec doch in meinen augen sinnlos ist! weil - was soll grsec tun ? Den Apachen schützen vorm apachen selbst ?
Geht ja nicht. Wenn ein loch in der PHP Software drin ist, bringt GRSec doch vermutlich auch nix.
Bitte korrigiert mich, wenn ich irre - ich will einfach nur wissen ob GRSec sich bei meiner Config überhaupt lohnt , oder ob ich die gleiche ausgangssituation hätte, wie ohn grsec.
gruß
Re: sinn von grsecurity
Posted: 2007-12-19 18:01
by Roger Wilco
royal1177 wrote:aber meine frage ist dahingehend, dass, wenn wirklich nur apache und php läuft, grsec doch in meinen augen sinnlos ist!
Dann benutze es einfach nicht, wenn du es für sinnlos hältst. Ich halte es für sinnvoll (Stichwort mehrstufige Sicherheit).
Re: sinn von grsecurity
Posted: 2007-12-19 18:13
by royal1177
"in meinen augen"
"Bitte korrigiert mich, wenn ich irre"
daher meine Frage an euch, in der Hoffnung eine konstruktive Antwort zu bekommen !
Das grsec sinn macht wenn mehrere sachen auf ner kiste laufen wie z.b. samba, mail, web etc. bzw. bei shared hosting - ist klar !
meine frage ist einfach ob er mir überhaupt was bringt wenn nur apache&php laufen ...
Re: sinn von grsecurity
Posted: 2007-12-19 20:50
by oxygen
royal1177 wrote:aber meine frage ist dahingehend, dass, wenn wirklich nur apache und php läuft, grsec doch in meinen augen sinnlos ist! weil - was soll grsec tun ? Den Apachen schützen vorm apachen selbst ?
Geht ja nicht. Wenn ein loch in der PHP Software drin ist, bringt GRSec doch vermutlich auch nix.
Möglicherweise schon. z.B. kannst das ausbrechen aus chroot oder potenzielle root exploits mit grsecurity verhindern.
Re: sinn von grsecurity
Posted: 2007-12-19 21:57
by royal1177
auf chrooten habe ich verzichtet, aufgrund der tatsache das nur apache und php läuft auf der kiste
hat ein angreifer überhaupt eine möglichkeit mittels root exploit anzugreifen, wenn die einzigste möglichkeit, anzugreifen, der port 80 bzw. die webanwendungen sind ?
gruß
Re: sinn von grsecurity
Posted: 2007-12-19 22:01
by Roger Wilco
royal1177 wrote:hat ein angreifer überhaupt eine möglichkeit mittels root exploit anzugreifen, wenn die einzigste möglichkeit, anzugreifen, der port 80 bzw. die webanwendungen sind ?
Ja.
Re: sinn von grsecurity
Posted: 2007-12-19 22:14
by flo
PHP ist nicht unbedingt für umfangreiche Audits bekannt. Die richtigen Applikationen dabei und man kann mit dem Scheunentor winken.
Mir ist mal passiert, daß ich eine aktuelle Version von Horde installiert habe, dann pausiert habe - wegen Schlafens - und schon am nächsten Tag eine Mail vom Hostmaster hatte.
Re: sinn von grsecurity
Posted: 2007-12-19 22:19
by royal1177
also schlagt ihr vor, den apache zu chrooten und grsec einzusetzen?
Re: sinn von grsecurity
Posted: 2007-12-19 22:44
by Joe User
Alles, womit der User theoretisch in Kontakt kommen könnte, sollte auf einem möglichst sicherem System in einem eigenem Chroot/Jail sitzen. Diese Chroots/Jails müssen dann noch durch weitere Sicherheitsmechanismen beispielsweise Gresec abgeschottet werden. Somit solltest Du nicht Apache+PHP in das gleiche, sondern in getrennte Chroots/Jails stecken (php-fcgi). Gleiches gilt auch für alle anderen Diensten, Scriptsprachen und und und...
Re: sinn von grsecurity
Posted: 2007-12-19 22:49
by oxygen
royal1177 wrote:also schlagt ihr vor, den apache zu chrooten und grsec einzusetzen?
Ohne die genaue Situation zu kennen, ist es schwierig passende Empfehlungen abzugeben. Betrachte das ganze eher als das Aufzeigen von Möglichkeiten. Sowohl Chancen als auch Risiken.
Re: sinn von grsecurity
Posted: 2007-12-19 23:11
by royal1177
- @oxygen.
genau deswegen hab ich mich ja an euch gewendet :) - und versucht es ausreichend zu schildern (nur "mein projekt" auf der kiste, keine weiteren kunden, nur apache&php etc)
welche infos benötigst du, damit du eine konstruktive entscheidung abgeben kannst ?
gruß
Re: sinn von grsecurity
Posted: 2007-12-19 23:21
by Roger Wilco
Also mal ehrlich. Du hast hier schon einige Meinungen gehört. Den Rest musst du selbst machen...
Re: sinn von grsecurity
Posted: 2007-12-19 23:29
by royal1177
aber meiner Meinung nach leider noch keine die wirklich "on Point" ist..
Re: sinn von grsecurity
Posted: 2007-12-19 23:33
by flo
Wir sind seit ca. 32x1.5 Posts on Point - aber ein Allheilmittel für Systemsicherheit per Ferndiagnose gibts nicht.
Du möchtest ein Netzwerk aufbauen, das ist bis jetzt klar - aber sieh doch bitte ein, daß eine umfangreiche Systembewertung anhand oberflächlicher Beschreibungen nicht wirklich möglich ist.
Re: sinn von grsecurity
Posted: 2007-12-19 23:37
by Joe User
Meinungen können nicht "on point" sein, deswegen sind es ja Meinungen und Jeder hat eine Andere, sofern er selbstständig Denken kann.
Und nein, Standards gibt es in diesem Bereich glücklicherweise auch nicht, nur individuelle Anforerungen...