SELinux, AppAmor, GRSecurity, PaX

[CentY]

Hi zusammen,

nachdem ich heute mal wieder über eine Anpsielung zu SELinux gestolpert bin:

Me, quoting me from a private IRC conversation
14:29 =orc_orc> disabling selinux is like
having perms of 777
or no root password at all
or no wrappers
or no iptables
14:29 =orc_orc> only weak minds should still be doing these things

Quelle:
http://orcorc.blogspot.com/2010/08/what-not-to-wear.html

Und hier ja alle so sicherheitstechnisch angeblich immer auf dem besten Stand sind . Wollte ich mal fragen benutzt ihr sowas? Oder seid ihr zu faul das System zu warten und deaktiviert es lieber .

Ich weis die Frage ist provokant gestellt . Aber mir gehen in letzter Zeit die Beiträge zum Thema Sicherheit ziemlich auf die Nerven in denen immer relative Pseudosicherheit propagiert wird und keine wirklichen Absicherungen der Linuxsysteme diskutiert werden.

Na dann frohes diskutieren .

 

[daemotron]

Solange ich Server mit Linux in Betrieb hatte, war grsecurity immer mit von der Partie. Allerdings habe ich das Teil nie voll ausgefahren; MAC-Regeln für jedes Binary zu basteln war mir dann doch zu aufwändig. Es blieb also beim härten von chroot und einigen Limitierungen; als wichtigste sei hier TPE genannt. Im Gegenzug habe ich für kritische Anwendungen (Web- und Applikationsserver, MTA) dann die Brachiallösung gewählt und alle schön in separate chroot-Jails gesperrt - auch so kann man die Auswirkungen eines erfolgreichen Hacks auf das Gesamtsystem beschränken.

Mittlerweile bin ich auf FreeBSD umgestiegen. Dort gibt es ebenfalls ein MAC-Framework; auch hier gilt allerdings dasselbe wie unter Linux: hoher manueller Konfigurationsaufwand, insbesondere bei häufig wechselnden Anwendungen und Diensten. Auch hier bediene ich mich dann lieber der Holzhammer-Methode (Jails), und garniere das ganze mit ein bisschen sysctl-Voodoo (Sichtbarkeit von Prozessen, Deaktivierung von SHM für Jails etc.).

Damit mir gefährliche Übergriffe wenigstens nicht entgehen, wenn sie schon passieren, habe ich Accounting und Security Event Auditing aktiviert (und natürlich entsprechend konfiguriert, in der Default-Ausprägung ist der Nutzen den Plattenplatz nicht wert, den die Logs verschlingen).

 

[flugopa]

Oder seid ihr zu faul das System zu warten und deaktiviert es lieber.

Man kann immer weiter schimpfen, oder den Jungs zeigen wie es geht.
Schreib doch mal, wie Du die Systeme sicher machst.
Wenn Du ein alter "Hase" bist, hast Du sicherlich ein Skript, welches das Standard-Hardening übernimmt, oder?

Als Fallbeispiel kannst Du dir einen CentOS 5.5 Webserver (+ php, +mysql) im Internet vorstellen.

Step 1: Installation = Kickstart-Minimalinstallation (textmodus mit vielen Partitionen zb /var/www, /tmp /var/log)
Step 2: wechsel in den Runlevel 2
Step 3: weitere Dienste deaktivieren (z.B. cups)
Step 4: ssh bearbeiten (port umbiegen, leeres passwort nicht zulassen, deny root, allow root_vertretung....)
Step 5: yum -y update
Step 6: sysctl bearbeiten
Step 7: iptables bearbeiten (z.B. ungenutzte Ports schliessen)
Step 8: ntp bearbeiten (z.B. server 2.de.pool.ntp.org)
Step 9: echo "umount /boot" | at now + 30 minutes>>/etc/rc.d/rc.local
Step 10: useradd root_vertretung
Step 11: hosts.allow + hosts.deny bearbeiten
Step 12: fstab bearbeiten
u.s.w.
http://wiki.centos.org/HowTos/OS_Protection#head-c6bf533e4f6de1ff3e13d556053fc40bc121e5cc
http://people.redhat.com/sgrubb/files/hardening-rhel5.pdf
http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf

Die Aufzählung stellt nur einen kleinen Teil dar.
Evtl. kannst Du die Steps "verfeinern", oder hast eine bessere Methode?

Machmal habe ich auch einen schlechten Tag... und lese dann die neuste Meldung: Führerschein nur noch 15 Jahre gültig, aber Politiker haben kein Verfallsdatum... Klar wieder eine Abzocke!!!

 

[CentY]

Was ich zu deiner Anleitung noch dazu fügen würde (für ein Standardsystem kein Highsecurity):
- /tmp - mit noexec, nodev, nosuid mounten
- /home - mit nodev, nosuid mounten
- /var/log/ - mit nodev, nosuid, noexec mounten
- Je nach System SELinux auf targeted oder strict und die entsprechenden Regeln bauen.
- chroot jail für mindestens named, postfix
- Je nach System SSH nur noch per VPN
- Syslog richtig einstellen (ein Logfile pro Dienst)
- fail2ban
- auditd richtig einstellen (Konfiguration nur durch reboot änderbar und nicht während dem Lauf, loggen von allen Befehlen die als Root ausgeführt werden)

SSH Port würde ich nicht umbiegen, weil ich den Nutzen nicht sehe.

Ein automatisches Script habe ich nicht, da sich fast jedes System ein bisschen Unterscheidet und ich die Erfahrung gemacht habe dass die automatischen Sachen oft mehr Arbeit verursachen als es gleich von Hand zu machen. Wenn ein System exakt gleich ist wird es einfach geklont und dann braucht man auch kein Script.