Automatisches Scaling bei Diagrammen...

[makki]

Ach so...Du bist also Webentwickler?! :-)

Im realen Leben bin ich eher der Spielverderber, also der sysadmin (siehe siriproxy/ruby, da bekommt man Magengeschwüre, wenn sich der nichtsahnende Anwender im Home-Verzeichnis mal ein komplettes ruby vom Source baut, nur weil er keine Ahnung hat, wie es richtig gemacht wäre..)

Ich habe an anderer Stelle etwas Anderes gebaut: Verbindung immer per SSL, das ist klar. Mittels eines Cookies im Browser wird der Zugriff gewährt (ohne VPN und schnick-schnack - mit Cookie funktioniert es einfach). Ist kein Cookie da, gibt es ein Fehler - kein Login Fenster um Bruteforce Angriffe zu verhindern.

Na dann erzähl doch mal im Detail, das klingt interessant (entspricht zwar dem Sicherheitsniveau von Hanni aber..)

und dafür sollten wir irgendwann mal ein globales config-file einführen...

Hmm den Punkt hast Du IMHO noch nicht ganz erfasst, das ist nicht Job der Visu sondern der Webserver-config. Das "globale config-file" gibt es schon, das heisst z.B. /etc/lighttpd/conf-enabled/05-auth.conf
Das bekomm ich halt nur nicht supported, weil man wissen muss was man tut. Und naja, das ist auch schon gut dokumentiert..
Mei das ist halt harter Stoff aber kannst du einem Anwender die Apache-config erklären ?
Sollte man auch nicht, weil entweder man weiss wirklich was man da tut oder es ist eben gefährlich.
Vermeintliche Sicherheit vorzugauckeln ("ist alles ganz easy") ist nicht meine Art, gescheit oder garnicht. Gescheit, auf Sicht von Jahren, geht nicht für 357.- EUR.. Security is a process, not a product (Bruce Schneier)

Warum so ein Cookie-Gebastel und nicht gleich Client-Zertifikat?

Weil man das in 100J keinem Endanwender erklärt bekommt.. Es gibt auf dieser Erde wissentlich >50 WG die einen Reverse-SSL Proxy mit Client-Auth per Zertifikat machen; das kann ich einrichten, aber mir nicht den Schuh anziehen, das für Hanni zu supporten oder zu erklären
Das geht technisch, problemlos, man muss aber dann halt wissen was man tut, was ein Zertifikat ist, warum es CRL's gibt - und all den Kram..

Das macht PHP bewusst anders. Und dafür gibt es auch den Strict Mode, um schlimmes zu verhindern.

Naja, das ist trotzdem Schrott.. Eigentlich.. Aber wir müssen die Kirche im Dorf lassen, deswegen ists so einfacher und praktisch richtig


-> Die einzige Möglichkeit, die ich einem Endanwender guten Gewissens an die Hand geben kann ist nunmal das VPN, es geht natürlich (technisch) auch anders, aber dann muss man wissen was man tut und das auch 24x7x365 verfolgen, pflegen, ...
Das im Nachtrag (wie lange?) in hunderten Varianten zu betreuen ist schlicht nicht drin..
Das geht mit einem OpenVPN, wo ich eh die devel-Liste mitlese aber nicht für hunderte veschiedene configs eines Webservers.
Gescheit oder garnicht, man weiss was man da tut oder betet, Security im Internet ist eben kein "Nebenjob"..
Und ich werde einen Teufel tun und das Gefühl vermitteln, das dem so wäre, indem man sich eine magische Box 1x reinstellt, weil das schlicht eine Lüge ist. In den letzten paar Monaten hat man "mal eben" ein paar gravierende Lücken im ewig alten SSL/TLS festgestellt.
Security per "Einmal-aktion" ist Augenwischerei, denn das kann schon morgen ganz anders aussehen.. Sorry, das ist nicht mein Versäumniss sondern die Realität, ich möchte nur so ehrlich sein, das auch zu sagen, das man im kleinen Umfeld eigentlich keine Chance hat, da überhaupt mitzukommen..

Für den VPN-Server können wir Updates gewährleisten.

Makki