# Web-Server: hardened-kernel-sources oder muss SELinux sein?

## donatz

Hallo!

Ich bin die Tage dabei nen Server hochzuziehen, wird ein Webserver auf dem Apache läuft, 24h/d. Später kommt vielleicht nochmal ein ftp-Server hinzu. Nach meinen bisherigen sehr positiven Erfahrungen mit Gentoo im Desktop-Bereich, solls natürlich auch auf dem Server Gentoo werden.

Als Profil habe ich das Server-Profil unter ../usr/portage/profiles/default-linux/x86/2007/ nach /etc/make.profile verlinkt. Hab den genauen Pfad jetzt nicht im Kopf, war aber kein hardened-Profil. Das es ein hardened-Profil überhaupt gibt, habe ich erst jetzt beim Googeln bemerkt.

Nun könnte ich noch (meine ich jedenfalls  :Wink:  ) auf das hardened-Profil umstellen? Bringt mir das irgendeinen Vorteil in Sachen Sicherheit, oder muss ich dann auch noch z.B. SELinux einsetzen um das hardened-Profil überhaupt sinnvoll zu nutzen?

Lohnt sich der Aufwand , oder ist bereits durch die hardened-kernel-sources ein Schutz in vernünftigem Verhältnis zum Aufwand erreicht?

Beim emergen von Software bekomme ich durch mein jetziges einfaches, nicht hardened-Server-Profil zudem ständig die Meldung das dieses Server-Profil wohl auch nicht ausreichend getestet wurde? (Ich habe in meine USE-Flags hardened mitaufgenommen)

Vielleicht hat ja der eine oder andere nen Tipp/Meinung parat wie ich o.g. lösen könnte/sollte?

Vielen Dank!

cu,

donatz   :Wink: 

----------

## papahuhn

SELinux brauchste da nicht. Ich benutze auch das hardened-profil. Bereits die reinen GrSecurity Features ohne PaX sind ganz interessant. Zum Beispiel kann man damit verhindern, dass ein Prozess andere Prozesse fremder uids sehen kann. Weiterhin wurde die Sicherheit in chroot-Jails verbessert. Wenn du deinen Apache in eine solche steckst, sollte die Kiste bereits recht sicher sein.

----------

## Keruskerfuerst

Es gibt ein stage-Archiv für das Profil "hardened".

Eine Umstellung vom "normalen" Profil auf "hardened" ist nicht möglich (z.B.: Downgrade von glibc).

Eine Absicherung des Servers durch IP-Tables.

FTP-Server: vsftp.

Den Rest: siehe auch http://www.gentoo.org/doc/en/index.xml?catid=projectLast edited by Keruskerfuerst on Fri Sep 21, 2007 8:58 am; edited 1 time in total

----------

## Daimos

hi,

ich hab auch nen hardened-profil laufen, Einbußen oder nennenswerter Mehraufwand war keiner, außer der Installation, die aufgrund von älteren gcc und glibc per stage1 stattfand. 

Der gcc 3.4.6 läuft mit spp und pie, was bei den installierten Paketen schon einige Vorteile in Punkto Sicherheit bringt (so ist es schwerer, Pufferüberläufe zu erzeugen oder gar auszunutzen). Auch die Kernel Features sind nett. In Punkto Performance sind die Einbußen nicht tragisch.

Es macht weiterhin Sinn, den Kernel monolithisch zu bauen - wo keine Module da sind, kann auch kein rootkit eingeschmuggelt werden.

Dein System aber auf hardened umzustellen - da sehe ich allerdings schwarz - das gcc downgrade mag laufen, bei der glibc klappt das aber nicht.

----------

## Anarcho

 *Keruskerfuerst wrote:*   

> Eine Absicherung des Servers durch IP-Tables.

 

Ein richtig eingerichteter Server braucht keinen Paketfilter. Wenn alle Anwendungen nur auf den Ports lauschen auif denen sie eh erreichbar sein sollen kann man mit iptables nicht mehr einstellen. Allein die Möglichkeit Bruceforce-Attacken ein wenig zu mildern macht den einsatz eines Paketfilters nützlich auf dem Server.

Denn die Dienste die ein Server anbietet sollen ja in aller Regel eh von allen IP-Adressen aus erreichbar sein, was also möchte ich dann filtern? Und wenn ich einen Dienst nach aussen blockieren muss habe ich die Anwendung falsch konfiguriert (z.b. MySQL, dort skip-networking vergessen).

Ansonsten lieber: SSH nur über Zertifikate (dann hat es sich mit Bruteforcen) und statt FTP dann halt SFTP/SCP ebenfalls nur per Zertifikat.

Weiterer Nachteil eines Paketfilters: Auch dieser kann Fehler enthalten die zum Einbruch ins System genutzt werden kann. Also sollte man sich den Einsatz gut überlegen, iptables ist kein Allheilmittel.

----------

## mv

 *papahuhn wrote:*   

> SELinux brauchste da nicht. Ich benutze auch das hardened-profil. Bereits die reinen GrSecurity Features ohne PaX sind ganz interessant. Zum Beispiel kann man damit verhindern, dass ein Prozess andere Prozesse fremder uids sehen kann. Weiterhin wurde die Sicherheit in chroot-Jails verbessert. Wenn du deinen Apache in eine solche steckst, sollte die Kiste bereits recht sicher sein.

 

Für all diese GrSecurity Features braucht man das hardend-profil nicht. Es genügt dazu vollkommen, hardened-sources statt gentoo-sources zu emergen und den Kernel entsprechend zu konfigurieren.

----------

## Daimos

Also IPtables find ich schon wichtig auf der Kiste zu haben. Zum einen kann man damit SYN Flood Geschichten und sowas eindämmen, zum anderen lassen sich einzelne Adressen oder Netze aussperren. Bei mir haben es ein paar Holländer mit ihrem w00tw00t.at.ISC.SANS.DFind Greaffel übertrieben, die sehen meine Schüssel jetzt gar nicht mehr.

Ansonsten find ich es noch sinnvoll, den SSH Port von 22 auf irgendwas anderes zu legen (z.B. 2280), dann müllen einem die Scriptkiddies nicht immer die Logs voll.

Klar kann man die Grsecurity Features auch mit jedem anderen Profil per hardened sources nutzen, aber spp wird mit gcc 4 fürs erste nicht gehen.

----------

## Anarcho

 *Daimos wrote:*   

> Ansonsten find ich es noch sinnvoll, den SSH Port von 22 auf irgendwas anderes zu legen (z.B. 2280), dann müllen einem die Scriptkiddies nicht immer die Logs voll.

 

Dann doch lieber beim Standard bleiben und das Teil richtig konfigurieren: Only PublicKey erlauben. Dann können die Scriptkiddies versuchen bis sie blöd werden. Sie kommen ja garnicht erst soweit ein Passwort zu probieren. Wirkt auch wunder bei den Logs.

Und wie gesagt, auch ein Paketfilter kann ein Sicherheitsrisiko darstellen.

----------

## Daimos

 *Quote:*   

> Only PublicKey erlauben. Dann können die Scriptkiddies versuchen bis sie blöd werden. Sie kommen ja garnicht erst soweit ein Passwort zu probieren. Wirkt auch wunder bei den Logs.

 

Gute Sache, werd ich in die Tat umsetzen. 

Klar ist ein falsch konfigurierter Paketfilter schlechter, als gar keiner. Trotzdem find ich iptables ganz praktisch, um kurzfristig auf bestimmte Leute oder Situationen reagieren zu können.

*Nachdenk*

Ob wir vom Thema abschweifen (ich schließe mich da durchaus selbst ein)?   :Rolling Eyes: 

----------

## mv

 *Daimos wrote:*   

> aber spp wird mit gcc 4 fürs erste nicht gehen.

 

spp? Du meinst sicher ssp.

Ist zwar vielleicht OT, aber kann man das nicht durch -fstack-protector in den CFLAGS erreichen, wenn man will?

----------

## Daimos

ssp - klar   :Embarassed: 

afaik geht das bei einzelnen Paketen sehr wohl, die Toolchain streikt da aber. Ich hab das natürlich ausprobiert, ging aber net.

----------

## mv

 *Daimos wrote:*   

> ssp [... vs -fstack-protector]
> 
> afaik geht das bei einzelnen Paketen sehr wohl, die Toolchain streikt da aber. Ich hab das natürlich ausprobiert, ging aber net.

 

Verstehe ich die Aussage richtig, dass der einzige "Nachteil" von -fstackprotector gegenüber ssp vom hardened profile ist, dass die toolchain selbst nicht geschützt werden kann? Also mit anderen Worten (da die Toolchain ja kein suid-Teil enthält): Nur vor stack-overflows in der glibc selbst oder in in den Laufzeit-Bibliotheken des gcc ist man mit -fstack-protector nicht geschützt? Das klingt für mich nicht so kritisch, als dass dies das hardened profile rechtfertigen würde...

----------

