@feltel: Schon klar. Echte Paranoia sind was für den Psychiater, nicht für die Firewall
Patrick
Apache version verstecken
-
pdreker
- Beiträge: 8298
- Registriert: 29.07.2002 21:53:30
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Nürnberg
Oops, da wollte ich noch ein paar Smilies streuen
@feltel: Schon klar. Echte Paranoia sind was für den Psychiater, nicht für die Firewall
Patrick
@feltel: Schon klar. Echte Paranoia sind was für den Psychiater, nicht für die Firewall
Patrick
Definitely not a bot...
Jabber: pdreker@debianforum.de
Jabber: pdreker@debianforum.de
-
Frankenstein
- Beiträge: 145
- Registriert: 28.01.2002 14:51:14
- Lizenz eigener Beiträge: GNU Free Documentation License
-
Kontaktdaten:
Ich wollete nicht sagen ,dass ich grundsärzlich nur auf Zeit spielen würde.
1. Es gibst Manche Apps die Webbasierend sind. Für Firmeninternes Netz.
2. Es gibts auch Unzufriedene Mitarbeiter, die vielleicht Datendiebstahl betreiben wollen, oder andere Daten Ausspienieren.
3. Wenn man alles So verändert, dass er länger braucht. Und in der selber Zeit die logs analysiert (Dank Logcheck,snort,cron-apt etc.). Kann Schandensbegrenzung betreiben werden und zu dokumentieren damit man einen Angrief später beweisen kann. ( Im schliemsten Fall vor Gericht )
4. Wenn die Firma mit DSL im Internet und dass über langere Zeit ist, denk an VPN. Hat man genug Zeit um viel Information / Analyse des Netzes zu sameln.
5. Und wenn du dieser Firma auch noch deine FW verkauft hast und sich selber nicht genug abgesicht hast. Dann bist du der Schuldege für andere (Weil deine FW nicht sicher genug ist etc..........)
6. Wobei die größeren Firmen eingene Admins hat. Und du der jenige bist und somit deine Arbeit nicht gut genug machst. Hast du deinen Job nicht mehr. Und bei dem nächsten Bewebunsgespräch auf Frage : " Wieso wurden Sie gekündigt ? " Wielst du dann sagen das due dei Job nicht richtigt gemachst hast ? sihe Punkt 5. Falls du in der Firma dazu zuständig warst.
1. Es gibst Manche Apps die Webbasierend sind. Für Firmeninternes Netz.
2. Es gibts auch Unzufriedene Mitarbeiter, die vielleicht Datendiebstahl betreiben wollen, oder andere Daten Ausspienieren.
3. Wenn man alles So verändert, dass er länger braucht. Und in der selber Zeit die logs analysiert (Dank Logcheck,snort,cron-apt etc.). Kann Schandensbegrenzung betreiben werden und zu dokumentieren damit man einen Angrief später beweisen kann. ( Im schliemsten Fall vor Gericht )
4. Wenn die Firma mit DSL im Internet und dass über langere Zeit ist, denk an VPN. Hat man genug Zeit um viel Information / Analyse des Netzes zu sameln.
5. Und wenn du dieser Firma auch noch deine FW verkauft hast und sich selber nicht genug abgesicht hast. Dann bist du der Schuldege für andere (Weil deine FW nicht sicher genug ist etc..........)
6. Wobei die größeren Firmen eingene Admins hat. Und du der jenige bist und somit deine Arbeit nicht gut genug machst. Hast du deinen Job nicht mehr. Und bei dem nächsten Bewebunsgespräch auf Frage : " Wieso wurden Sie gekündigt ? " Wielst du dann sagen das due dei Job nicht richtigt gemachst hast ? sihe Punkt 5. Falls du in der Firma dazu zuständig warst.
-
pdreker
- Beiträge: 8298
- Registriert: 29.07.2002 21:53:30
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Nürnberg
Dann erklär mir doch einfach 'mal, wie Du Dich sicher vor einer internen Attacke eines motivierten Saboteurs schützen willst? Genauso, wie vor einer externen Attacke? Richtig: alles absichern, richtig konfigurieren und so dicht wie möglich und so offen wie nötig. Dabei muss man zwingend Kompromisse machen, und diese dokumentieren.
Beispiel
Mitarbeiter, die Daten in eine Datenbank eingeben müssen, haben halt Zugriffsrechte auf diese DB. Wenn Du ihnen die Löschrechte nimmst, so dass sie nur neue Einträge machen können, oder bestehende ändern, hast Du nichts gewonnen, weil sie alles überschreiben können. Nimmst Du ihnen auch noch die Update Rechte, können sie die DB mit sinnlosen Einträgen fluten. Entfernst Du jetzt das Recht neue Einträge zu machen, kannst Du alle nach Hause schicken, weil keiner mehr die DB nutzen kann (ausser nachschlagen). Wenn Du Datenlecks vermeiden willst, musst Du die Leserechte einschränken. Irgendwer muss den Kram aber lesen können, das ist der Sinn einer DB.
Worauf ich hinaus will: Die Nebelkerzen Taktik hilft gegen interne Angreifer so gut wie gar nix, weil die normalerweise anders herausfinden können was abgeht. Solange man nicht aufgefallen ist, verwickelt man den Admin in ein nettes Kantinengespäch über den Server. Warum sollte der auch nicht ein bisschen aus dem Nähkästchen plaudern? Natürlich passt er auf, dass er nichts problematisches raussickern lässt, aber wenn er dem Mitarbeiter sagt, dass letztens das neueste ServicePack eingespielt wurde? Wo soll die Grenze gezogen werden? Admin einmauern, keinem Mitarbeiter irgendwas sagen? Irgendwo müssen die Leute irgendeine Form von Zugriff haben, und dieser Zugriff lässt sich missbrauchen. Genauso, wie sich der Zugriff auf die Portokasse missbrauchen lässt. An irgendeiner Stelle hast Du eine Schnittstelle zu einem User. Diese Schnittstelle sollte man sich sorgfältig ansehen und sich überlegen, was soll der User machen können, was darf er maximal machen und wie kann man diese Rechte durchsetzen, ohne dass die Funktionalität darunter leidet.
Wenn Du alles loggst (was ja default sein sollte), dann hast Du im Notfall auch immer ausreichende Beweismittel für eventuelle juristische Konsequenzen. Dass es natürlich am Besten gar nicht erst soweit kommen sollte ist klar, aber Verschleierungstaktiken helfen da wenig.
Die Security Branche hat da sogar einen Ausdruck für: "Security through Obscurity". Damit ist gemeint, dass man versucht, das eigentliche System komplizierter oder anders wirken zu lassen als es wirklich ist. Das Problem dabei ist, dass wenn die Obscurity (also die "Geheimhaltung") durchbrochen wird, diese Sicherheit vollständig weg ist. Das Wissen über die Funktionsweise des Mechanismus macht den Mechanismus unwirksam. Dem gegenüber steht die "echte" Security. Wenn man weiss, dass ich auf meinem Router ein Firewall habe, und alle Programme mit Zugriffsbeschränkungen versehen habe und ausserdem alles logge, dann hilft Dir das gar nichts, ausser dass Du weisst, das es kompliziert werden könnte. Selbst wenn Du weisst, dass meine FW auf iptables basiert, bringt Dich das nicht viel weiter, es sei denn Du kennst eine Sicherheitslücke in iptables. Wenn das eine allgemein bekannte Lücke ist, kannst Du davon ausgehen, dass der Fehler gepatched ist... Und so weiter...
Ein bekanntes Beispiel für Security through Obscurity ist die sogenannte Cäsar Verschlüsselung. Man nimmt einen leicht konischen Holzstab, wickelt ein Lederband spiralförmig um den Stab, und schreibt die Nachricht der Länge nach zeilenweise auf das aufgwickelte Band. Wenn man das Band jetzt abwickelt hat man nur noch Buchstabensalat. Das Problem: Wenn ich weiss, wie Du den Salat erzeugt hast, kann ich die Nachricht entschlüsseln. Die genaue Form des Stabes ist praktisch unerheblich, weil man die durch ausprobieren schnell herausfinden kann.
Dem gegenüber stehen moderne Crytoverfahren. Als Beispiel diene hier 'mal RC4 (Arcfour). Das ist ein symmetrisches Verschlüsselungsverfahren (der gleiche Schlüssel wird für Ver- und Entschlüsselung benutzt). Wenn man weiss, wie der Algorhythmus funktioniert, hilft einem das nicht bei der Entschlüsselung einer Nachricht. Man muss den Schlüssel besitzen. Wenn der Schlüssel kompromittiert wird, ändert man ihn halt. Das Verfahren bleibt das Gleiche.
Patrick
Beispiel
Mitarbeiter, die Daten in eine Datenbank eingeben müssen, haben halt Zugriffsrechte auf diese DB. Wenn Du ihnen die Löschrechte nimmst, so dass sie nur neue Einträge machen können, oder bestehende ändern, hast Du nichts gewonnen, weil sie alles überschreiben können. Nimmst Du ihnen auch noch die Update Rechte, können sie die DB mit sinnlosen Einträgen fluten. Entfernst Du jetzt das Recht neue Einträge zu machen, kannst Du alle nach Hause schicken, weil keiner mehr die DB nutzen kann (ausser nachschlagen). Wenn Du Datenlecks vermeiden willst, musst Du die Leserechte einschränken. Irgendwer muss den Kram aber lesen können, das ist der Sinn einer DB.
Worauf ich hinaus will: Die Nebelkerzen Taktik hilft gegen interne Angreifer so gut wie gar nix, weil die normalerweise anders herausfinden können was abgeht. Solange man nicht aufgefallen ist, verwickelt man den Admin in ein nettes Kantinengespäch über den Server. Warum sollte der auch nicht ein bisschen aus dem Nähkästchen plaudern? Natürlich passt er auf, dass er nichts problematisches raussickern lässt, aber wenn er dem Mitarbeiter sagt, dass letztens das neueste ServicePack eingespielt wurde? Wo soll die Grenze gezogen werden? Admin einmauern, keinem Mitarbeiter irgendwas sagen? Irgendwo müssen die Leute irgendeine Form von Zugriff haben, und dieser Zugriff lässt sich missbrauchen. Genauso, wie sich der Zugriff auf die Portokasse missbrauchen lässt. An irgendeiner Stelle hast Du eine Schnittstelle zu einem User. Diese Schnittstelle sollte man sich sorgfältig ansehen und sich überlegen, was soll der User machen können, was darf er maximal machen und wie kann man diese Rechte durchsetzen, ohne dass die Funktionalität darunter leidet.
Wenn Du alles loggst (was ja default sein sollte), dann hast Du im Notfall auch immer ausreichende Beweismittel für eventuelle juristische Konsequenzen. Dass es natürlich am Besten gar nicht erst soweit kommen sollte ist klar, aber Verschleierungstaktiken helfen da wenig.
Die Security Branche hat da sogar einen Ausdruck für: "Security through Obscurity". Damit ist gemeint, dass man versucht, das eigentliche System komplizierter oder anders wirken zu lassen als es wirklich ist. Das Problem dabei ist, dass wenn die Obscurity (also die "Geheimhaltung") durchbrochen wird, diese Sicherheit vollständig weg ist. Das Wissen über die Funktionsweise des Mechanismus macht den Mechanismus unwirksam. Dem gegenüber steht die "echte" Security. Wenn man weiss, dass ich auf meinem Router ein Firewall habe, und alle Programme mit Zugriffsbeschränkungen versehen habe und ausserdem alles logge, dann hilft Dir das gar nichts, ausser dass Du weisst, das es kompliziert werden könnte. Selbst wenn Du weisst, dass meine FW auf iptables basiert, bringt Dich das nicht viel weiter, es sei denn Du kennst eine Sicherheitslücke in iptables. Wenn das eine allgemein bekannte Lücke ist, kannst Du davon ausgehen, dass der Fehler gepatched ist... Und so weiter...
Ein bekanntes Beispiel für Security through Obscurity ist die sogenannte Cäsar Verschlüsselung. Man nimmt einen leicht konischen Holzstab, wickelt ein Lederband spiralförmig um den Stab, und schreibt die Nachricht der Länge nach zeilenweise auf das aufgwickelte Band. Wenn man das Band jetzt abwickelt hat man nur noch Buchstabensalat. Das Problem: Wenn ich weiss, wie Du den Salat erzeugt hast, kann ich die Nachricht entschlüsseln. Die genaue Form des Stabes ist praktisch unerheblich, weil man die durch ausprobieren schnell herausfinden kann.
Dem gegenüber stehen moderne Crytoverfahren. Als Beispiel diene hier 'mal RC4 (Arcfour). Das ist ein symmetrisches Verschlüsselungsverfahren (der gleiche Schlüssel wird für Ver- und Entschlüsselung benutzt). Wenn man weiss, wie der Algorhythmus funktioniert, hilft einem das nicht bei der Entschlüsselung einer Nachricht. Man muss den Schlüssel besitzen. Wenn der Schlüssel kompromittiert wird, ändert man ihn halt. Das Verfahren bleibt das Gleiche.
Patrick
Definitely not a bot...
Jabber: pdreker@debianforum.de
Jabber: pdreker@debianforum.de
200 % ACKfeltel hat geschrieben:100% ACK. Ein bischen Paranoia schadet nie, aber man sollte es nicht übertreiben.pdreker hat geschrieben:Jetzt möge mir bitte jemand erklären, warum ein hochbegabter Cracker, seine Zeit darein investieren sollte, mit riesigem Aufwand in ein DialUp System einzubrechen???
-
Frankenstein
- Beiträge: 145
- Registriert: 28.01.2002 14:51:14
- Lizenz eigener Beiträge: GNU Free Documentation License
-
Kontaktdaten:
Genau das wollte ich auch sagen, aber nur in wenigen Sätzen. Und alles sollte einen Konzept haben. Das Problem ist doch, dass die wenigen Admins machen. Es sei dem das sind Professionelle Admins. Die den Angreifern ihre Daten unteressan zu machen. Es sei dem man mochte ein paar jahre auf Ergebnisse wareten. Wenn man die Schlüßellängen etc. so hoch wie möglich macht. So das wenn man jemand die Daten klaut, aber die Daten nicht lesen kann. Und Enschlüsselungszeit braucht zut großen Aufwand für Angreifer. Werden die Daten für einen Angreifer uninteresant.