DB sperren über TCPIP

[pippo]

hallo leute,
habe folgendes problem:
es gibt eine notesdb mit anonymous - leser; über browser soll man nun diese db lesen können aber nur jene user mit einer bestimmten ip-adresse;
ist das möglich?

schönen tag, pippo

[Rob Green]

aslo zumindest die korrekte CGI Varibale lautet "Remote_addr".

Dazu ein Beispiel aus dem Notes Net 4/5er Forum:
!@Begins(Remote_addr ; "172.17.128") & !@Begins(Remote_addr ; "172.17.129") & !@Begins(Remote_addr ; "172.17.130") & !@Begins(Remote_addr ; "172.17.131") & !@Begins(Remote_addr ; "172.17.132")

Du könntest zB das über JavaScript im OnLoad Event abfragen und den User abweisen. Nur was, wenn der User eine komplette URL eingibt, um in eine Form oder dedizierte View zu gelangen? Dann ebenso mit JS Onload im Header arbeiten. Was wenn der User JS ausgeschaltet hat? Hm...dann wirds schwierig. Blöde Frage: funktioniert im Web auch das Database Script "PostOpen"? Wenn man dort die IP abfragen würde und dann den User abweist, zB über eine Umleitung per Print...nur so ne Idee.

[adminnaddel]

@all,

das event postopen nicht, aber webquerryopen

adios

[Till_21]

@naddel:
leider gibt es kein databasescript "webqueryopen" !!

[adminnaddel]

  UPPS  

[jofa]

Hi,


schaue mal unter:

http://www.atnotes.de/index.php?board=7;action=display;threadid=2059;start=0

Gruss JoFa

[wflamme]

Leute,
ich rate, auf solche Tricks zu verzichten.
Redirects taugen als Sicherheitsmaßnahme nicht!

[Rob Green]

jep, aber auch diese Lösung erscheint mir (in diesem Link meine ich zu dem alten Beitrag) nicht ganz koscher, da ich so ziemlich  bei jedem Browser ein autom. Redirect über Meta Refresh ausknippsen kann. Hm..irgendwie sind alle Lösungen doof.

Wie wär denn das, wenn man den User dazu zwingt JavaScript zu verwenden. Ist JavaScript ausgeschaltet, wird die Page erst garnicht angezeigt. Ist JS an, kann man damit die Überprüfung machen und dazu die aufgerufenen Seite mit Inhalt anzeigen.

Aber dolle finde ich alle Lösungen wirklich nicht, da man immer die IP spoofen kann.

[wflamme]

jep, aber auch diese Lösung erscheint mir (in diesem Link meine ich zu dem alten Beitrag) nicht ganz koscher, da ich so ziemlich  bei jedem Browser ein autom. Redirect über Meta Refresh ausknippsen kann. Hm..irgendwie sind alle Lösungen doof.

Wie wär denn das, wenn man den User dazu zwingt JavaScript zu verwenden. Ist JavaScript ausgeschaltet, wird die Page erst garnicht angezeigt. Ist JS an, kann man damit die Überprüfung machen und dazu die aufgerufenen Seite mit Inhalt anzeigen.

Aber dolle finde ich alle Lösungen wirklich nicht, da man immer die IP spoofen kann.

Das Problem ist, daß das JS erst auf den Browser muß. Damit breitet man die ganze Prüfungszeremonie einschl. der neuen Targets vor einem potentiellen Angreifer aus - einschl. des Links, wie's nun im Erfolgsfall mit aktiviertem JS weitergeht. Das ist das Problem mit HTTP: sessionless, stateless..
Und nun denk' mal an eine Suchmaschine, die schert sich einen Dreck um JS - genauso wie jeder WebRetriever...

IP spoofen macht in diesem Fall allerdings keinen Sinn, denn dann verschwinden die Antwortpakete im Nirvana an die simulierte IP. Es sei natürlich, ein Angreifer hat die Router in der Hand und schafft es, daß er die Pakete zu sich geroutet bekommt. Aber wer das so gut kann, der ist wohl auch fähig, gleich das BeSy des Servers zu hacken.

[Rob Green]

Vorschlag zur Lösung wenn man es unbedingt mit IP machen möchte? Ausser eine solche DB so webfähig zu machen, daß JSP Tags die HTML Pages erstellen, fällt mir echt nix mehr Besseres ein.

flamme?

[wflamme]

Rob + Mitleser,

weiß nicht genau. Ich würd's einfach nicht machen sondern mich für Standard-Authentifizierung/-autorisierung entscheiden.

Als Tour-de-Force ev. dynamisch generierte Seiten per Agent (Heidenaufwand, wenn RT im Spiel ist), ev. könnte man aber auch mit Formularumschaltung arbeiten? Dann müßte das Form-Item aber immer auf ein Blindformular zeigen, das bei 'korrekter' IP dynamisch aufs Anzeigeformular umgebogen wird.

Wie gesagt, nur so'n Brainstorming.
Ach ja, Sicherung gg Notes-Clients ist auch noch ein Thema.

[Rob Green]

wflamme, da Du mir im Thema Sicherheit Dich gut auszukennen scheinst (auch wenn Dein Frust manchmal aus Dir dazu herausbricht..versteh Dich ja...letztens habe ich ne Umfrage gelesen, daß bei 70% befragter Unternehmen das Thema Sicherheit nicht zu den Top3 gehört im IT Bereich....aber immerhinbei 30% ..think positive), gestatte mir eine andere Frage:

wie sicher ist in Deinen Augen Notes über Web i.A.s? Sind Deines Erachtens größere Lücken erkennbar, die im praktischen Umfeld aus mangelnder Kenntnis der Admins resultieren oder wo würdest Du Sicherheitsproblemzonen sehen?

[wflamme]

wflamme, da Du mir im Thema Sicherheit Dich gut auszukennen scheinst (auch wenn Dein Frust manchmal aus Dir dazu herausbricht..versteh Dich ja...letztens habe ich ne Umfrage gelesen, daß bei 70% befragter Unternehmen das Thema Sicherheit nicht zu den Top3 gehört im IT Bereich....aber immerhinbei 30% ..think positive),

Mein Frust kommt nicht von ungefähr, angegangen bin ich die Sache nämlich sehr positiv. Überhaupt liegt mir eine solch defätistische Einstellung gar nicht bzw nur bei 2 Sachen: Politik und IT-Sicherheit; ansonsten würde ich mich sogar als Optimisten bezeichnen

Ich gebe halt nochmal zu bedenken, wie einfach es ist, auf einem Fragebogen "sehr wichtig" anzukreuzen und wenn 70% noch nichtmal das tun, dann bleibt *reell* noch ein weitaus geringerer Prozentsatz übrig....

wie sicher ist in Deinen Augen Notes über Web i.A.s? Sind Deines Erachtens größere Lücken erkennbar, die im praktischen Umfeld aus mangelnder Kenntnis der Admins resultieren oder wo würdest Du Sicherheitsproblemzonen sehen?

Notes als System hat mE überdurchschnittlich hohe Sicherheit. Es fällt ziemlich leicht, über die handvoll bekannter Problemen die Übersicht zu behalten. Probleme gibt's überwiegend auf der menschlichen Seite.
Ein paar Punkte, die allerdings noch ausgearbeitet und bewertet/in Reihenfolge gebracht werden müßten:

1) Arbeitsteilung zwischen Admins und Entwicklern läßt Löcher
2) Rapid Design Umgebung
3 hohe Standardisierung beim WebZugriff
4) Produkt *erzwingt* keine Sicherheit
5) wenig/keine integrierte Sicherheitsunterstützung (zB integrierter Button 'Wer kann dieses Dokument lesen?' etc.
6) Schwerpunkt Groupware noch unterentwickelt, viele Firmen nutzen Notes iw als Mailplattform, Admins focussieren darauf
7) Entwicklung daher vorwiegend Web, Rapid Design-Anspruch, Weppdisain-Anspruch (zB "mache alles, auch Notes")

[wflamme]

Sorry, ich vergaß:

Ganz oben auf der Liste steht eben die Prioritätensetzung. Und da hat das Management das Sagen.

[Rob Green]

danke für Deine Meinung dazu. Dazu interessant und auch treffend finde ich die "Checkliste", wo die Security Schwächen liegen und wo man das Augenmerk darauf legen sollte. Nicht umsonst heißt es "keep it stupid simple" statt 1000 Seiten Beratungsblabla mit letztlich der gleichen Essenz  

[wflamme]

Danke für's Lob.
Einige Punkte habe ich noch nachzutragen:

1) DB-übergreifende Unterstützung ist bei R5 produktbedingt schwach (zB Mischen von Dokumenten aus anderen DBs in einer Ansicht), das zwingt Entwickler, alles in eine DB zu stopfen und kompliziert das Design, auch was Zugriffssicherheit betrifft.

2) dokumentorientierte Arbeitsweise des Produkts wird nicht richtig verstanden, zB daß Leserfelder auf Ansichten eben nur das Designelement schützen, nicht die Dokumente, die sie anzeigen.

3) Konzept von Leser/Autorenfeldern wird nicht komplett verstanden

4) Mächtigkeit der Domino-URL-Syntax wird unterschätzt

5) Keine klare Trennung zwischen 'Innen-' und 'Außen'ansicht beim DB-Design

HTH

[Rob Green]

ergänzen wir mal die Liste:

- Mißbrauch des Domino Servers als Internet Wide Open Mail Relay, wenn man nicht aufpasst als Admin
- prinzipiell ist das mehrtsufige Sicherheitsmodell vielen Developern und Admin nicht bekannt. Auch wer von den erfahreneren Notes´lern traut sich auf seinem Gebiet zu, alle Stellschrauben zu kennen?

Frage:
was meinst Du mit "'Innen-' und 'Außen'ansicht" beim Design?

[wflamme]

ergänzen wir mal die Liste:

- Mißbrauch des Domino Servers als Internet Wide Open Mail Relay, wenn man nicht aufpasst als Admin
- prinzipiell ist das mehrtsufige Sicherheitsmodell vielen Developern und Admin nicht bekannt. Auch wer von den erfahreneren Notes´lern traut sich auf seinem Gebiet zu, alle Stellschrauben zu kennen?

Das ist - denke ich - nicht wirklich wichtig. Das Problem muß 'auf die Liste' und es muß sich jemand drum kümmern, es recherchieren/nachschlagen.
Besser ein Problem langsamer lösen als es sofort nicht lösen.

was meinst Du mit "'Innen-' und 'Außen'ansicht" beim Design?

NotesDBen im Web sind ja sehr häufig keine Präsentations- sondern eben auch Abwicklungssysteme. Newsletter und Infomaterial abonnieren und versenden, Supportfragen entgegennehmen und beantworten, Stellen ausschreiben und Bewerbungen einholen, Registrierungen u.s.w. sind fast schon Standard in Webauftritten. Gelegentlich sind auch noch Shopsysteme integriert.
Ich bezeichne die Repräsentation aus Kundensicht als die Außenansicht, die unternehmensinterne Pflege und Abwicklung als Innenansicht dieser gemeinsamen Datenbasis.

Einzig und allein die Domino-Security trennt das eine vom anderen!

Der Rest der Antwort berührt die Entstehungsgeschichte von DominoDarkSide und ist nachzulesen auf http://www.sns1.de/partner/flamme/wflamme.nsf/Shortcut/Innenansicht