Unter diesen Gesichtspunkt hat aber auch Linux nichts auf einen produktiven Server verloren. Ganze drei Kernel Updates gab es allein im Dezember:
http://lists.debian.org/debian-secur.../msg00209.html
http://lists.debian.org/debian-secur.../msg00213.html
http://lists.debian.org/debian-secur.../msg00218.html

Also so ungeschützt ist ein Server im Rechenzentrum auch wieder nicht. Einige bieten sogar eine zuschaltbare Anti-DDoS Lösung :-)

Oh doch. Ein größer Server langweilt sich auch bei Hochlast ziemlich, während ein kleiner Server allein schon beim Filtern meiner knapp 10000 Spam Emails/Tag in die Knie gehen würde.

ich würde mal empfehlen, die haarspaltereien um prinzip <-> verwendbarkeit sein zu lassen. schliesslich kann es sein, daß er auf seiner site auch mit fail2ban nix zu schützen hat (was sind schon 50 versuchte logins pro tag ?)...

...oder er hat ein massives problem mit login attempts und malformed urls- diese problemchen wird aber ER erkennen und lösen müssen. "one size fits all" gibt es in der it schon lange nicht mehr, sorry.

das thema der performance ist weiters so eine sache - technisch gesehen könnte ich mir als privater etwa nagios, munin, statusmails, loadbalancing am webserver und weitere locker sparen. andererseits - es hat seine gründe, warum es rennt...


@schichtleiter: bei einem VPS konto wirst du kaum ein /xx netz bekommen, in das du NATen kannst. ist ja doch eher die sache eines eigenen standortes oder einer colocation, da kann man sowas recht leicht machen.


vielleicht noch eine gschicht aus dem realen leben: wir verwenden die WRTs zur anbindung von gebäudeteilen mit einer thibor firmware und außenantennen... im Rechenzentrum haben wir watchguard fireboxen (meist 750er) und parallel ASA oder PIX - klassische 2-vendor-policy.

was genau soll denn eine "hardware" firewall auf der erst wieder ne software läuft denn bringen? die notwendigen dienste sind auch mit einer "hardware" firewall weiterhin erreichbar und somit angreifbar.

eine vm bringt hier übrigens keine zusätzliche sicherheit, sondern eine zusätzliche gefahr durch lücken in der vm software.

wer unbedingt eine firewall "braucht", sollte zu einer integrierten lösung greifen. hierfür gibt es entsprechende pci lösungen, die "hardware" firewall wird sozusagen im server eingebaut. je nach geldbeutel kann man die firwall durch ein ids/ips system durchaus noch nützlich machen.

eine trivial frage hätt ich noch:
wenn ich eine neue gruppe anlege mit einem user, dann hat der user ausser auf sein home verzeichnis keine schreibrechte im system, oder? zb wenn apache den user apache in der gruppe apache kreiert dann kann der nur in seine programmverzeichnisse schreiben?

prinzipiell - ja. mit ausnahme von /tmp, halt. :)

aso, und wenn ich als root apache isntallier und der sich selbst einen user apache kreiert dann is der so gscheit in die verzeichnisse die gruppe apache mitzunehmen bevor er sich vom root zum apache degradiert? oder versteh ich da was falsch, die verzeichnisse gehörhen ja root, apache müsst also gar keinen zugriff haben?

ferndiagnose is ein bissl hart, weisst... :D

also, 1: bei meinem internen webserver gehört /var/www sowohl dem user als auch der gruppe www-data (zugriffsrechte oktal 775). die weltweiten rechte könnte ich auch runterschrauben, aber egal. das sollte entsprechend deinen vorgaben, vorlieben und applikationsanforderungen gesetzt sein.

2, es gibt einen user und gruppe www-data, wurde bei der installation von apache angelegt. login für den user ist nicht möglich.

3, wenn du SELINUX fährst, muss noch der security context passen.bspw.:

[www]# ls -alFZ
drwxrwxrwx apache apache system_u:object_r:httpd_sys_content_t gallery/
drwxr-xr-x apache apache system_u:object_r:httpd_sys_content_t html/
drwxr-xr-x apache apache system_u:object_r:httpd_sys_content_t icons/
drwxr-xr-x apache apache system_u:object_r:httpd_sys_content_t usage/


ad hoc fällt mir auch nicht wesentlich mehr ein, im zweifelsfall würde ich solche sachen immer restriktiver gestalten, bis probleme auftauchen. oder alternativ zuerst zumachen, und dann schrittweise bis zum gewünschten ergebnis öffnen. wie machts der colo ?

hallo!
so, nach 1000 tutorials und knapp am nervenkollaps etc hab ich postfix mit dovecot und auth über tls endlich am laufen, uff.

nur können jetzt alle user inklusive root über den sals-tls-smtp connecten.. wie berbiet ich root den smtp login? von der konfig her hab ichs ungefähr so wie hier, keine mysql db, keine login-files, ich hab keine ahnung von wo er sich die logindaten holt..

http://www.howtoforge.com/fedora-8-s...p-ispconfig-p5

sicher, daß du als root connecten kannst ?

mail versenden geht, aber dovecot...

siehe auch folgendes output von meiner maschine (RHEL5.1)

# Valid UID range for users, defaults to 500 and above. This is mostly
# to make sure that users can't log in as daemons or other system users.
# Note that denying root logins is hardcoded to dovecot binary and can't
# be done even if first_valid_uid is set to 0.
#first_valid_uid = 500
#last_valid_uid = 0
# Valid GID range for users, defaults to non-root/wheel. Users having
# non-valid GID as primary group ID aren't allowed to log in. If user
# belongs to supplementary groups with non-valid GIDs, those groups are
# not set.
#first_valid_gid = 1
#last_valid_gid = 0


-> damit lässt sich sicher was basteln, sag ich mal... :)