Sicherheitsvorkehrungen Online-Banking: neue AGB's

Sollte es, auf einem non-windows system, zu einem Schadensfall kommen der sich auf einen Trojaner und/oder Viren zurückführen lässt muss der Anwender nachweisen das er die ihm zumutbaren Vorkehrungen getroffen hat.
Zumutbar bedeutet auch: technisch möglich, einem durchschnittlichen Anwender bekannt, ....
Mit einem aktuellen linux System wirst du als Kunde, nach meiner Einschätzung, gute Aussichten haben dich nicht gruseln zu müssen.

Wozu? Mit "Firewall" ist i.d.R. ein Paketfilter gemeint, der Connects auf Ports (jetz mal egal, ob es sich um TCP, UDP, ICMP, usw. handelt) sperrt, falls die konfigurierte Policy dies nicht zulaesst. Auf Linux-Systemen wird das "unter der Haube" nahezu ausnahmslos mit IPTables umgesetzt - egal, in welcher GUI man die Filter-Einstellungen zusammengeklickt hat.

Den Connect-Versuch auf einen Port zu sperren, macht natuerlich nur Sinn, wenn auf diesem Port auch ein Dienst laeuft. Wird der Zugriff auf diesen Dienst durch den Paketfilter gesperrt, stellt sich zwangsweise die Frage, wozu der Dienst dann ueberhaupt gut ist, wenn er nicht genutzt werden kann? Hier ergeben sich 3 Moeglichkeiten:

a) Der Dienst wird benoetigt und soll auch erreichbar sein. Dann muss der Port nicht gefiltert werden.
-> Firewall nicht noetig.

b) Der Dienst wird zwar benoetigt, soll aber nur lokal erreichbar sein. Dann sollte der Dienst so konfiguriert werden, dass er nur auf localhost bzw. dem benoetigten internen Interface lauscht (der hierfuer noetige Parameter in der Config-Datei des Daemons heisst oft "bind address" o.ae.). Unterstuetzt der Dienst einen solchen Parameter nicht, sollte er gegen eine andere Software ersetzt werden, die das kann.
-> Firewall nicht noetig

c) Der Dienst wird nicht benoetigt und kann komplett deaktiviert werden.
-> Firewall nicht noetig

Ich bring mal einen hinkenden Vergleich: Was nützen Türen in einem Haus, die permanent verschlossen sind, weil ich nicht will, dass sie jemand aufmacht? Dann kann ich die Türen auch gleich weg lassen.


Interessant ist in dem Zusammenhang die de.comp.security.firewall FAQ
http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#PF


OK, das war jetzt weit ausgeholt, betrifft aber nur eine moegliche Umsetzung einer Security-Policy, da "Firewall" im allgemeinen Sprachgebrauch haeufig mit "Paketfilter" bzw. "Personal Firewall" gleichgesetzt wird.

Also zum einen gilt das nur fuer PIN/TAN (bei Chipkarte und Schluesseldiskette wird i.d.R Port 3000 verwendet). Zum anderen muss der Port (outgoing) sowieso offen sein, da das der Default-Port fuer HTTPS ist. Der User koennte andernfalls keine HTTPS-Seiten mehr besuchen.

Unabhaengig davon macht ein Angriff direkt auf TCP hier ueberhaupt keinen Sinn, da die Uebertragung verschluesselt ist. Viel geeigneter sind hier beispiels DNS-Spoofing oder ein Angriff auf die Banking-Anwendung selbst. Da schuetzt auch kein Paketfilter.



Sicher. Obwohl auch hier nicht unbedingt ein Virenscanner noetig ist. Mit einer MAC-Loesung wie SELinux oder AppArmor und den ueblichen "Paranoia"-Grundsaetzen (Software nur aus vertraulichen Quellen, nur wenn der Quellcode verfuegbar ist, nur signiert, etc) kann man auch so hinreichend sicherstellen, dass das System nicht mit lohnenswertem Aufwand kompromittiert werden kann.

BTW: Ich muss aber nochmal dazu sagen, dass sich meine Aussage nicht auf Linux-User allgemein sondern ganz konkret auf mich bezog. Daher schrieb ich auch "...inwiefern ich ... meine Sorgfaltspflicht .... wenn ich auf meinem ....".

Und ich weiss sehr genau, was meine Banking-Anwendung macht - auch ohne Virenscanner ;)

Ja, vermutlich

Waere aber ein recht konstruiertes Szenario. Denn man braeuchte ja einen kompromittierten HBCI-Server, zu dem sich die Banking-Anwendung auch noch verbindet.

Fall a) Es ist wirklich der HBCI-Server der Bank, der kompromittiert ist. Dieses Szenario will ich mir lieber nicht ausmalen ;-D

Fall b) Die Verbindung wird auf einen anderen HBCI-Server umgebogen (z.Bsp. via DNS-Spoofing). In dem Fall kann man davon ausgehen, dass der lokale Rechner ohnehin bereits kompromittiert wurde und das System des Users schon komplett manipuliert ist. Der Angriff ist dann schon gar nicht mehr noetig, da er laengst geschehen ist.

Von fundamentaler Wichtigkeit ist also, dass die Daten und Programme auf dem eigenen Rechner vertrauenswuerdig sind. Das ist die Basis. Und dort sollte man ansetzen. Das geht mit Virenscannern (bedingt), SELinux, AppArmor, ReadOnly-Partitionen, etc. Leider ist TPM wegen DRM in Veruf geraten. Dabei waere genau das aus meiner Sicht der richtige Ansatz. Wenn sichergestellt ist, dass der eigene Rechner nur mit unverhaeltnismaessigem Aufwand manipulierbar ist, kann einem eigentlich egal sein, wenn irgendwelche Angriffsversuche uebers Netz kommen.

Ich hab auf meinem Mainboard ein TPM Modul nachgerüstet. Bis heute suche ich nach der Anwendung dafür... Die mitgeleiferte Kryptosoftware ist "billig", Bitlocker auf Windows mag ich nicht, TrueCrypt als mein Favorit unterstützt kein TPM.

Ich hab jetzt mal bei der deutschen Bank danach gesucht. In den AGB unter http://www.deutsche-bank.de/pb…gb_pgk.pdf finde ich nichts.

In den Bedingungen fuers Online-Banking unter http://www.deutsche-bank.de/pb…en_pgk.pdf

steht in Punkt 7.2, Satz (2), letzter Anstrich:



Diese "Beispiele" finde ich jetzt nirgends.

Insbesondere mit dem Begriff "handelsübliche Sicherheitsvorkehrungen" kann ich jetzt nicht so viel anfangen.