# KDE trieb mich zur Verzweiflung, ab 01.01.09 BKA-Gesetz

## UTgamer

Vor langer Zeit und zwar zur Zeit von KDE 3.5.6 verweigerte ich mal alle Update und blieb lange lange Zeit bei KDE-V3.5.5.

So vor ein paar Monaten wollte ich dann doch mal KDE 4.0.5 ausprobieren und mußte dazu das von mir verwünschte mdnsresponder Paket dann doch mit installieren. Obwohl ich es als USE-Flag überall auskommentiert hatte.

Seit Jahren nutze ich eine ARP-Poisoning (http://de.wikipedia.org/wiki/ARP-Spoofing) Abwehr oder auch Spoofingschutz genannte Lösung; also ich setzte die MAC-Adressen meiner Netzwerschnitstellen fest mit den IP-Adressen verknüpft ein. Nun wird mein Spoofing-Schutz aber durch mdnsresponder add-adsurdum geführt.

Ich war überrascht das nach frischen KDE-Updates mein spoofing-Schutz erstmal weiter funktionierte. Doch vor wenigen Wochen (2-4) wurde bei irgend einem Systemupdate etwas geändert, auf der Bootkonsole TTY1 erschien urplötzlich eine mir bis dahin unbekannte Fehlermeldung:

 *Quote:*   

> SIOCSARP: Das Netzwerk ist nicht verfügbar

  Das schreckte mich auf, denn danach gab es auf einmal überall seltsame Fehler, sie häuften und häuften sich. KDE-Programme fingen an sich seltsam langsam zu benehmen und gar mein Mozilla Browser wurde manchmal unerklärlich langsam.

Als mußte der Sache auf den Grund gegangen werden.

Wo fängt man mit der Suche an?

Also das neueste auf meinem Gentoo waren die beiden KDEs 3.5.9 und 4.0.5.

KDE-Konsole hatte ebenfalls seltsame Verlangsamungen.

Als erstes erstellte ich ein neues User-Profile, half nicht.

Dann deinstallierte ich KDM und meldete mit über die TTY-Konsolen am Desktop an mit startx oder startx -- :1, startx -- :2 ...

Dabei fiel mir ein weiterer Fehler auf. Wenn der erste X Server lief war es egal mit welcher Zahl ich den X-Server anwies ein spezielles TTY zu verwenden, also früher startete "startx -- :3" einen X-Server auf "TTY 9/F9" jetzt auf den ersten freien nach 6. Also willkür beim X-Server.

Nächster Fehler KIOSLAVE Fehlermeldungen und KIO Cache Fehlermeldungen ohne Ende spülten sich über die TTYs über die ich startx gestartet hatte. Um der Sache auf den Grund zu gehen startete ich KDM von einem Root-Terminal aus, die Fehlermeldungen unterblieben.

Eine erste Erkenntniss: Über KDM KDE zu starten blieb also ohne Fehlermeldungen auf den TTYs. Auch war es möglich über den Parameter StaticServers=:3 mit der Änderung ReserveServers=:0,:1,:3 genau auf "F9" einen X-Server zu starten und nicht auf "F7" beginnen zu lassen, jedoch ein startx -- :3 nicht mehr dem gewünschten Effekt gleich kam. Was machte also KDM4 mit meinem X-Server?

Über die Fehlermeldungen kam ich in den Suchmachinen immer nur zu den Quellcodes von KDE-Komponenten nie aber zu einer Lösung. Teils gab es gar xauth Fehlermeldungen ohne Ende, traten aber seltener auf.

Mein Entschluß war nur mehr ganz wenige KDE Komponeten zu verwenden wie z.B. kpat das KDE-Kartenspiel Patience welche ich gerne während emerge-Aufgaben zockte um die emerge Zeiten zu überbrücken. 

Gestern Abend war es dann soweit nachdem ich bereits letzte Woche mdnsresponder deinstalliert hatte behaupte KDE3.5.9 -KPAT aufeinmal grundlos es benötige die /usr/lib64/libdns_sd.so.1 rofl, ein Spiel was die ganze Zeit über ohne diesen Netzwerkzugriff funktionierte brauchte aufeinmal Netzwerkzugriff? Das reichte mir vollkommen aus und brachte das Faß zum Überlaufen. 

Ich habe KDE heute morgen deinstalliert und werde es die nächsten Jahre weder verwenden noch empfehlen. Da ist mir ja glatt Gnome mit seinen Mono-Neigungen lieber.

Ich habe fertig mit KDE!

----------------------------

Jetzt brauche ich noch eine Hilfe von euch, wie starte ich von der Konsole aus einen X-Server statt auf "tty7/F7" auch wie ich es früher konnte auf z.B. "tty9/F9"?

Früher verwendete ich dazu dieses Kommando:

startx -- :3 doch das funktioniert seit kurzem nicht mehr.

Meinen SIOCSARP Fehler beim Booten habe ich jetzt beseitigt bekommen durch eine weitere neue Startabhängigkeit zum Netzwerk. Bis vor rund einem Monat reichte es seit Jahren aus als Abhängigkeit need localmount zu werden, und wurde jetzt um need net erweitert.

, meinen Arp-Poisoning/Spoofing Schutz der so aussieht (vielleicht mag ihn ja noch jemand nutzen):

/etc/init.d/arp-setzen

 *Quote:*   

> #!/sbin/runscript
> 
> # Distributed under the terms of the GNU General Public License v2
> 
> depend() {
> ...

 

Man braucht nur seine eigenen IPs und MAC-Adressen dort einsetzen wenn man an/hinter einem Router sitzt; und dann noch mit rc-update add arp-setzen default dem Bootprozess hinzufügen.  :Wink: 

Kleine Anti-Spoofing-Anleitung für Interressierte:

 *Quote:*   

> Mit:
> 
> arp -e
> 
> frage ich meine bekannten Netzwerkadressen ab. IP und MAC-Adresen finde ich dortdrin auch über ifconfig eth(x) finde ich die Angaben.
> ...

 

PS:

Ältere Mitglieder kennen mich ja, das ich immer in Probleme renne die andere nicht haben. *g*

Aber wenn mich etwas interressiert wie z.B. die neuen Abhörgesetze von BKA und LKA die ab Morgen Rechtsgültigkeit haben bin ich einfach nicht mehr zu halten. Mein Privatleben gehört mir und nicht einer Gestapo/Stasi vergleichbaren Geheimpolizei die keiner parlamentarischen Kontrolinstanz untersteht. Ja Richtig, das BKA wird nur von einer einzigen Person geleitet und ist sonst niemandem Rechenschaft schuldig nur dem Bundesinnenminister Schäuble. Niemand anderes kann deren Geheimpolizeiarbeit überprüfen. Einfaches billiges Spoofing kommt denen nur recht. 95% aller Provider haben ja bereits die Geheimpolizeischnittstellen integriert und bekommen von der Polizeiinfiltration fast nichts mehr mit, die anderen 5% der Provider müßen ab Morgen eben Bußgelder bezahlen.

----------

## mv

Dass KDE ohne den mDNSResponder-Dreck nicht will, liegt ausnahmsweise mal nicht an KDE, sondern an den Gentoo-Maintainern von KDE, die diese Abhängigkeit nicht-optional haben wollten, weil sonst möglicherweise irgendwann irgendwas nicht gehen könnte.

Ich habe bei mir net-misc/mDNSResponder-107.6-r5 und www-misc/htdig-3.2.0_beta6-r3 in die package.provided eingetragen. Zusammen mit USE='-amazon -hal -kontact -libnotify -pam -nepomuk -semantic-desktop -session -spl -zeroconf' (und nur Installieren der gewünschten Programme) kommt dann ein nicht mehr ganz so aufdringliches KDE raus, wobei kde-4 natürlich trotzdem bei weitem schlechter als kde-3 abschneidet (von den Bugs, die es derzeit ohnehin unbrauchbar machen, rede ich jetzt gar nicht). Jedenfalls zeigt das Funktionieren dieses Hacks mit package.provided, dass kde auch ohne den mDNSResponder- und zeroconf-Sondermüll kompilieren kann.

----------

## Max Steel

kde-4.1.3 läuft hier Problemlos  :Wink: 

Allerdings muss sich mein Rechner nicht um die Sicherheit sorgen, dafür ist der Server zuständig.

(firewall, anti-spoofing, ssh-Zugriff nur per private Key über einen User der keinerlei Rechte besitzt, keine Anfragen von außen, augenommen port 80 (html) unvm.

----------

## forrestfunk81

hmm.. also mac adressen kann man ohne probleme fälschen. wenns also jemand schafft dein netz abzuhören nimmt er halt einfach deine mac adressen.. is denk ich nicht viel mehr aufwand als gleich eine vom dhcp router zu bekommen. und mit tempest attaken die im geheimdienstlichen umfeld wahrscheinlich schon standard sind ist es sicherlich möglich dein (kabel-)netz abzuhören. 

ot: was mir beim bka gesetz viel mehr aufstößt ist die optische wohnraum überwachung. ich bin kein jurist und hab den gesetzes text nicht im kopf.. aber ich denke da zählen mikrowellen scanner sicherlich auch dazu. diese microwellen scanner (auch bekannt als nackt scanner am flughafen) nutzen wie radar die unterschiedlichen reflektierwerte verschiedener materialien und können je nach stärke und frequenz auch mauern durchdringen. hier z.b. ein kleines handliches produkt.

was das allerdings mit kde zu tun hat versteh ich nicht. denkst du etwa das bka hat dein kde gehackt?  :Wink: 

----------

## UTgamer

 *mv wrote:*   

> Dass KDE ohne den mDNSResponder-Dreck nicht will, liegt ausnahmsweise mal nicht an KDE, sondern an den Gentoo-Maintainern von KDE, die diese Abhängigkeit nicht-optional haben wollten, weil sonst möglicherweise irgendwann irgendwas nicht gehen könnte.
> 
> Ich habe bei mir net-misc/mDNSResponder-107.6-r5 und www-misc/htdig-3.2.0_beta6-r3 in die package.provided eingetragen. Zusammen mit USE='-amazon -hal -kontact -libnotify -pam -nepomuk -semantic-desktop -session -spl -zeroconf' (und nur Installieren der gewünschten Programme) kommt dann ein nicht mehr ganz so aufdringliches KDE raus, wobei kde-4 natürlich trotzdem bei weitem schlechter als kde-3 abschneidet (von den Bugs, die es derzeit ohnehin unbrauchbar machen, rede ich jetzt gar nicht). Jedenfalls zeigt das Funktionieren dieses Hacks mit package.provided, dass kde auch ohne den mDNSResponder- und zeroconf-Sondermüll kompilieren kann.

 

Danke dir, wenn ich nochmal soviel Zeit aufwenden möchte KDE neu zu bauen weil ich doch das ein oder andere KDE-Progrämmchen vermissen sollte werde ich deinen Weg auch noch ausprobieren.  :Very Happy: 

Nun aber auch nochmal meine Frage wie starte ich neuerdings einen X-Server auf tty9/F9, der alte Weg mit "startx -- :3" funktioniert nicht mehr.

[Edit]

@forrestfunk81, ich informiere mich über deine Einwande, die Microwellenüberwachungen oder teils auch Terrahertz gennant kenne ich auch, dagegen hilft ein engmaschiges Metallgitter an den Wänden das Wasserdampf durchläßt wie bei der Küchenmicrowelle, ist aber nicht einfach zu verlegen und kostet auch Geld.

Nein sie haben mein KDE nicht gehackt, sie nutzen einfach die "Man in the middle attack" über mDNSresponder.  :Wink:  Die Tools kann sich jeder installieren, daher fallen sie ja auch unter die Hackerparagraphen, es dürfen ja bei uns nur noch die Geheimpolizisten hacken.  :Wink: 

----------

## mv

 *Max Steel wrote:*   

> kde-4.1.3 läuft hier Problemlos 

 

Aufzählen der ganzen Bugs würde wohl zu weit führen. Hier nur ein paar Beispiele: khotkeys funktioniert schon mal gleich gar nicht - was den Entwicklern auch bekannt ist, aber keine Priorität hat. Konqueror zeigt viele Seiten unbrauchbar gerendert an. Beispielsweise im Gentoo-Forum kann man öfters mit weißem Text auf weißem Grund editieren (manchmal geht es, meistens nicht). Abstellen des Automatischen Nachladens von Bildern ist zwar noch vorhanden, aber kein Knopf, mit dem man die Bilder nachladen kann, wenn man es doch will. Es gibt zwar einen Toolbar, auf dem man diesen Knopf einrichten kann, aber der wird beim Nachladen bei (im Schnitt) jeder zweiten Seite wieder ausgeblendet. Manchmal verschwinden auch schon mal gerne alle Desktop-Settings, so dass man bei einem neuen Start vor einem ganz leeren Bildschirm ohne Kicker-ähnlicher Leiste sitzt - tatsächlich sind die zugehörigen Einträge in ~/.kde/wasweissich dann auch geleert (mit diff -r herausgefunden); wer sich also nicht regelmäßig (nach jedem Login) ein Backup von ~/.kde4 gemacht hat, hat verloren.

Das waren so die Bugs, auf die ich nach den ersten 30-45 Minuten gestoßen bin - es war ein reines Durchimprovisieren durch Probleme. Als "mal sehen, wie weit die Entwicklung steht" mag das angehen - zum Arbeiten ist es indiskutabel (und ja: Die getestete Version - bevor ich sie wegen Unbrauchbarkeit wieder entfernte - war die 4.1.3).

Aber es ging in dem Thread ja eigentlich nicht um kde sondern um die mdnsresponder/zeroconf-Sicherheitslücke, die man sich unter Gentoo damit einhandelt.

----------

## mv

 *forrestfunk81 wrote:*   

> was das allerdings mit kde zu tun hat versteh ich nicht.

 

Das schrieb er doch: kde unter gentoo besteht auf mdnsresponder/zeroconf. In einem fest konfigurierten Netzwerk (in das sich sich nicht ständig neue Laptops neuer unbekannter Benutzer einwählen sollen) hat so etwas einfach auf keinem Rechner des Netzwerks etwas verloren.

----------

## kernelOfTruth

@UTgamer:

also wenn du schon so paranoid bist, dann würd ich die Mac-Adressen bittschön auch nicht posten   :Idea: 

denn sonst gibt es irgendwann auch ein böses Erwachen  :Wink: 

----------

## UTgamer

 *kernelOfTruth wrote:*   

> @UTgamer:
> 
> also wenn du schon so paranoid bist, dann würd ich die Mac-Adressen bittschön auch nicht posten  
> 
> denn sonst gibt es irgendwann auch ein böses Erwachen 

 

 :Smile:  Sind weder meine genutzen IP-Adressen noch meine echten MAC-Adressen, den Tip hatte ich schon vorher beherzigt, die oben geposteten können die gerne verwenden, damit bleiben sie kalt liegen, hehe. Die ersten 2-3 Stellen markieren den Hersteller 00:04:E2(:79:4B:25) "00:50:8B:68:4B:28" "00:50:8B:68:4B:53" (3* :4B: << niemals)  danach gehts zu Modellen und Einzeladressen über, naja die Hersteller stimmen soweit. Die Werte danach sind fiktiv von mir ersetzt worden. *muhaha freuh*. Aber du hast ebenfalls gut aufgepaßt.  :Wink: 

----------

## dirk_salewski

 *UTgamer wrote:*   

> #!/sbin/runscript
> 
> # Distributed under the terms of the GNU General Public License v2
> 
> depend() {
> ...

 

Eins vorneweg - ich bin kein Experte für diese Themen, aber ich denke, daß Du mit diesem Vorgehen Dein eigentliches Ziel verfehlen wirst. Das Problem beim ARP-Spoofing ist ja nicht, daß Deine eigene IP in Deinem eigenen Rechner falsch geroutet wird. So wie ich das sehe hast Du jetzt ein vergleichsweise unkomfortables LAN (Deine Freunde können dank abgeknipstem Zeroconf eben nicht mit Laptop mal eben hereinschneien und schnell was ausdrucken) und keinerlei zusätzlichen Schutz gegen ARP Cache Poisoning von außen. Du müßtest die Kollegen bei Google anrufen und die obige Übung für sämtliche Ethernetkarten von denen machen, wolltest Du nur halbwegs sicher sein, daß Deine Anfrage nach "Gericht Kürbis Thai" nicht über den Schreibtisch von Horst Herolds Nachfolger geht. Oder? Und dann könntest Du die Rückgabe von Google noch nicht anklicken - Du müßtest erst bei den Rezepteanbietern anrufen und nach deren MAC-Adressen fragen. Ich weiß nicht - da hab ich lieber ein bißchen zuviel Curry in der Soße.

Noch was: ich gehe mal davon aus, daß Du Dich hinter einem Router befindest. Jetzt stellst Du von Deinem Rechner ...4 eine Anfrage an ...1 (vielleicht ist 4 'ne Windowskiste, und Du willst die auf 1 entwickelten Webseiten sehen). Das läuft komplett in Deinem eigenen Subnetz. Selbst der schlechteste Router der Wält käme wohl nicht auf die Idee, die Anfrage für das eigene Subnetz über das Interface für das externe Netzwerk zu routen, ARP Poison hin oder her (zugegeben - ich hab's nicht ausprobiert). Und wenn - wie sollten denn die BKAler feststellen, was sie von Deinem Rechner 1 zurückliefern müssen, damit Dir das auf Rechner 4 nicht auffällt? 

Versteh mich bitte nicht falsch - ich finde Sicherheit sehr interessant und wichtig - ich denke eben nur, daß die Methode, den lokalen ARP-Cache zu schützen, einfach nicht weiterhilft. Eine verteilte Datenbank mit ARP-Zuordnungen im TOR-Netzwerk, die auf vielen Rechnern auto-repliziert wird und die man zur Kontrolle anzapfen kann mittels Firefox-Plugin - das wär's. Das wäre auch nutzbar. 

Oder liege ich voll daneben?

Dirk

----------

## Anarcho

 *dirk_salewski wrote:*   

>  *UTgamer wrote:*   #!/sbin/runscript
> 
> # Distributed under the terms of the GNU General Public License v2
> 
> depend() {
> ...

 

Das ist so nicht ganz richtig. Im ARP Cache befinden sich ausschliesslich lokal/direkt erreichbare Rechner. Daher ist die "am weitesten entfernte" MAC Adresse die des nächsten Routers deines Providers. Alles andere interessiert deinen Rechner sowieso nicht. Denn die Rechner hinterm Router kann dein Rechner sowieso nicht per Ethernetprotokoll, also sprich per MAC, erreichen. Dazu ist schon das IP Protokoll eine Stufe höher nötig.

Beispiel: Dein Rechner will www.google.de erreichen. Er sieht das die IP nicht im lokalen Netz ist und schickt daher das Paket über den Router ins Internet -> im Paket steht die MAC deines Routers. Dieser nimmt das Paket, kann es selber nicht direkt ausliefern und schickt es also an seinen nächsten Router -> die MAC des ersten Routers deines Providers steht im Paket. Was dieser mit dem Paket macht und welche MAC er als nächstes einträgt kannst du nicht mehr beeinflussen.

Der einzige Angriff kommt hier also von Intern. Es schaltet jemand einen weiteren Rechner an den Switch und betreibt ARP-Poisening sodass dein lokaler Rechner die Anfrage nicht mehr direkt an den eigenen Default Router sondern über den Man-in-the-Middle schickt. Das bedeutet aber das ein Angreife physischen Zugang zum Netz haben muss. Das ist bei grossen Firmen wirklich ein Problem da dort Besucher ihren Laptop mitbringen und auch relativ problemlos ans Firmennetz anschliessen können. Bei einem LAN daheim bedeutet das aber in der Regel das sich jemand ohne dein Wissen Zugang zu deiner Wohnung verschafft hat. Und da sehe ich persönlich viel grössere Probleme als ARP-Poisening...

----------

## think4urs11

 *dirk_salewski wrote:*   

> Oder liege ich voll daneben?

 

Ja, siehe Anarchos Erklärung.

Was mir auffällt sind die arp -s auf .004/.005 - mindestens ältere Windowsversionen hatten mal die unangenehme Eigenart IP-Adressen mit führenden Nullen als oktal zu interpretieren, d.h. damit konnte/(kann?) man sich wunderbar ins Knie schießen.

----------

## Max Steel

Aaaber, er hatt auch gesagt das er IPs und MACs gefälscht hat.

Also kann es sein das er nicht 192.168.004 sondern 192.168.114 nutzt, oder so.

----------

## think4urs11

ist ein Argument, das hatte ich überlesen.

Echte Paranoiker halten sich sowieso nicht mit statischen ARP-Einträgen auf sondern benutzen auch intern alles nur via zertifikatsbasiertem VPN, protokollieren jede Statusänderung an Switchports (setzt managebare Switches voraus) die natürlich entsprechend gehärtete Config haben, nach außen sowieso nur überTor+privoxy und/oder I2P, ....

Das blöde dabei ist das es je nach Netzgröße früher oder später einfach nicht mehr handhabbar ist. Was ich hier zuhause in meinem <10PC-Netz problemlos machen kann würde in der Firma mit >>500PC am Standort ein ganzes Adminteam erfordern.

----------

## dirk_salewski

 *Think4UrS11 wrote:*   

>  *dirk_salewski wrote:*   Oder liege ich voll daneben? 
> 
> Ja, siehe Anarchos Erklärung.

 

Hey, ich würde nach Durchlesen der Erklärung wenigstens für ein gnädiges "Jein" plädieren. Immerhin war der Teil mit dem lokalen Subnetz vom beschriebenen Effekt her richtig. Zufällig zwar, aber richtig   :Very Happy: 

----------

## think4urs11

Nö, denn theoretisch könnten die Jungs vom BKA dem Router ein wenig Bridging beibringen und so durchaus (unter Zuhilfenahme von ARP-Poisoning, DNS-Spoofing usw.) auch 'von außen' so tun als wären sie ein interner Rechner. Und wenn sies richtig machen sogar so das sie z.B. nur Teile der angefragten Webseite des Servers auf .1 gegen eigene Inhalte austauschen - z.B. das login.php durch eines das die Passworte direkt nach Wiesbaden schickt.

Wenn man vorher lange genug mitlesen und rumschnüffeln kann fällt das kaum auf (außer bei wahren Paranoikern)

Selbst intern genutztes https müßte man ausbremsen können - man müßte ja nur statt des self-signed Certs. ein offiziell signiertes Zertifikat dazwischenklinken das vom Browser ebenfalls akzeptiert wird - und wer weiß schon ob das BKA nicht bei irgendeiner CA die Finger mit drin hat um sich entsprechende Certs. zu generieren. Das zusammen mit einem Proxy der in diesem https-Strom dann mitlesen kann ...

Der Paranokier prüft natürlich bei jedem Seitenaufruf ob das Zertifikat a)gültig und b) das eigene ist.

/paranoia off

----------

## Max Steel

Hört besser auf xD Sonst holt sich der Staat hier noch Eindrücke wie er in der Linux-Welt reinkommt.

----------

## mattes

 *mv wrote:*   

> 
> 
> Ich habe bei mir net-misc/mDNSResponder-107.6-r5 und www-misc/htdig-3.2.0_beta6-r3 in die package.provided eingetragen. 

 

Hallo,

hab das gerade auch probiert, aber Portage will mdnsresponser trotzdem mergen !?

habe  *Quote:*   

> =net-misc/mDNSResponder-107.6-r5

  in /etc/portage/package.provided eingetragen.

Was mache ich falsch?

Gruß

Mattes

----------

## mv

Erstens ist der Path falsch: /etc/portage/profile/package.provided ist der korrekte. Zweitens ist in dem File kein "=" am Anfang vorgesehen. Drittens sollte ich aber wohl besser ausdrücklich darauf hinweisen, dass das Vorgehen nicht offiziell von Gentoo supported ist: Also wenn es Bugs gibt, die möglicherweise darauf zurückzuführen sein könnten, bitte vor einem Bugreport zuerst mDNSResponder emergen und danach kdelibs sowie die betroffenen Pakete neu bauen.

----------

## mattes

Danke. 

Das mit dem = hatte ich erst nachher ausprobiert...  Auf den Pfad bin ich nicht gekommen.

Ich finde das Vorgehen der KDE Maintainer in diesem Fall nicht richtig. Es ist überhaupt nicht Linux-like dem Anwender vorzuschreiben, eine Technik einzusetzen, die er nicht braucht und nicht will und die darüber hinaus auch noch mit Sicherheitsrisiken verbunden ist.  Diese Abhängigkeit sollte doch an das zeroconf-USE-Flag gebunden sein, oder?

----------

## mv

 *mattes wrote:*   

> Ich finde das Vorgehen der KDE Maintainer in diesem Fall nicht richtig. Es ist überhaupt nicht Linux-like dem Anwender vorzuschreiben, eine Technik einzusetzen, die er nicht braucht und nicht will und die darüber hinaus auch noch mit Sicherheitsrisiken verbunden ist.  Diese Abhängigkeit sollte doch an das zeroconf-USE-Flag gebunden sein, oder?

 

War es ursprünglich auch. Dann hat jemand in einem Bugreport KDE-Pakete mit +ssl und -ssl vermengt, was für die Maintainer Grund genug war, die Option trotz mehrerer Proteste anderer Benutzer zu entfernen. Der dümmste Benutzer bestimmt bei den KDE-Maintainern offensichtlich jeweils die verfügbaren Optionen. Deshalb warne ich auch davor, Bugreports mit meinem kleinen Hack abzugeben: Sonst werden sich die Maintainer nur überlegen, wie sie den Benutzern auch diesen Hack erschweren können.

----------

## UTgamer

Think4UrS11, hat alles genau richtig beschrieben, und danke mit dem Tip für ältere Windowse hatte das glatt vergessen, habe den ganz alten Rechner jedoch den so etwas betreffen könnte wirklich nur selten am Netz.

Bezüglich ins lokale Netz von remote extern einbrechen ist für die Profis vom BKA wirklich ein Kinderspiel, genau darum nutze ich ja den Effekt der festen MAC-Zuweisung, denn die lokalen Pakete haben ja Anweisung die Route 1 zu nehmen, andernfalls sollten sie hoffentlich verworfen werden (ich hoffe an dieser Stelle jetzt nichts verwürfelt zu haben).

Wie Think4UrS11 das Bridging erwähnte hat er damit auch recht, denn Polizeidienstellen stehen die Backdoor-(Defaultremote-)Passwörter oder Bugs aller Hersteller zur Verfügung. Und wenn sie diese eingebauten Funktionen nutzen flooden sie einfach nur innerhalb ~ 1 Minute den Switchcache und haben somit Zugriff auf alle internen Geräte hinter dem Router.

Zitat aus: http://www.bsi.de/gshb/deutsch/g/g05112.htm

 *Quote:*   

> MAC-Flooding ist eine Angriffsmethode, die die Funktionsweise eines Switches beeinflusst. Switches erlernen angeschlossene MAC-Adressen dynamisch. Die MAC-Adressen werden in der Switching-Tabelle gespeichert. Der Switch weiß dadurch, an welchen Ports die entsprechenden MAC-Adressen angeschlossen sind.
> 
> Wenn nun eine angeschlossene Station mit Hilfe eines geeigneten Tools eine Vielzahl von Paketen mit unterschiedlichen Quell-MAC-Adressen sendet, speichert der Switch diese MAC-Adressen in seiner Switching-Tabelle. Sobald der Speicherplatz für die Switching-Tabelle gefüllt ist, sendet ein Switch sämtliche Pakete an alle Switch-Ports. Durch dieses "Fluten" der Switching-Tabelle mit sinnlosen MAC-Adressen kann ein Switch nicht mehr feststellen, an welche Ports tatsächliche Ziel-MAC-Adressen angeschlossen sind. Diese Angriffsmethode wird verwendet, um das Mitlesen von Paketen in geswitchten Netzen zu ermöglichen. Es sind frei verfügbare Tools auf einschlägigen Seiten im Internet verfügbar, die auf einem Switch über 155.000 MAC-Adress-Einträge innerhalb einer Minute erzeugen können. 

 

Geht also ruck zuck wenn der Router gebridged wurde. Die haben die Möglichkeiten, und da außer Schäuble (der aktl. Innenminister) persönlich niemand Einwände dagegen machen kann machen die das auch, richterliche Anordnungen brauchen die nur wenn die damit nach außerhalb der Behörden gehen wollen. Es wird einfach so spioniert, hindert sie ja keiner daran.

Eben die gleichen Rechte wie die damalige Gestapo="Geheime Staatspolizei".

----------

## Anarcho

 *UTgamer wrote:*   

> Think4UrS11, hat alles genau richtig beschrieben, und danke mit dem Tip für ältere Windowse hatte das glatt vergessen, habe den ganz alten Rechner jedoch den so etwas betreffen könnte wirklich nur selten am Netz.
> 
> Bezüglich ins lokale Netz von remote extern einbrechen ist für die Profis vom BKA wirklich ein Kinderspiel, genau darum nutze ich ja den Effekt der festen MAC-Zuweisung, denn die lokalen Pakete haben ja Anweisung die Route 1 zu nehmen, andernfalls sollten sie hoffentlich verworfen werden (ich hoffe an dieser Stelle jetzt nichts verwürfelt zu haben).
> 
> Wie Think4UrS11 das Bridging erwähnte hat er damit auch recht, denn Polizeidienstellen stehen die Backdoor-(Defaultremote-)Passwörter oder Bugs aller Hersteller zur Verfügung. Und wenn sie diese eingebauten Funktionen nutzen flooden sie einfach nur innerhalb ~ 1 Minute den Switchcache und haben somit Zugriff auf alle internen Geräte hinter dem Router.
> ...

 

Du machst dir also sorgen das sie ein bisschen Man-in-the-Middle spielen könnten, aber gleichzeitig machst du dir keine Hoffnung das dein Router nicht gekapert und mit einer Bridge versehen werden kann? Was bringt dir denn bitte die fest MAC Zuweisung wenn der Weg der Pakete völlig korrekt über den Router läuft, dieser aber gekapert ist? Wie wäre es denn einfach das Tor dort zuzumachen wo es wirklich wichtig ist, nämlich am Router selber. Wenn dort keiner von aussen vorbei kann, dann kannst du intern auch machen was du willst. Wenn du dort allerdings weiter den T-COM Router mit Defaulteinstellungen betreibst, dann frage ich mich ernsthaft warum du dir bei dem restlichen Netz die Mühe überhaupt machst?

Mein Router ist ein Linuxsystem. Dort sollen sie mal versuchen beim Hersteller das Defaultpasswort zu bekommen um dort eine Bridge einzurichten...

Solange ich bei mir keine unerwarteten und vor allem unbeaufsichtigen Besucher im Haus erwarte ist mir persönlich in meinem Netz ARP Poisening ziemlich egal. Und sollten sie wirklich einbrechen sehe ich auch da die Gefahr bei Hardware-Keyloggern usw. deutlich höher.

----------

## UTgamer

 *Anarcho wrote:*   

> ...
> 
> Du machst dir also sorgen das sie ein bisschen Man-in-the-Middle spielen könnten, aber gleichzeitig machst du dir keine Hoffnung das dein Router nicht gekapert und mit einer Bridge versehen werden kann? Was bringt dir denn bitte die fest MAC Zuweisung wenn der Weg der Pakete völlig korrekt über den Router läuft, dieser aber gekapert ist? Wie wäre es denn einfach das Tor dort zuzumachen wo es wirklich wichtig ist, nämlich am Router selber. Wenn dort keiner von aussen vorbei kann, dann kannst du intern auch machen was du willst. Wenn du dort allerdings weiter den T-COM Router mit Defaulteinstellungen betreibst, dann frage ich mich ernsthaft warum du dir bei dem restlichen Netz die Mühe überhaupt machst?
> 
> Mein Router ist ein Linuxsystem. Dort sollen sie mal versuchen beim Hersteller das Defaultpasswort zu bekommen um dort eine Bridge einzurichten...
> ...

 

Sagen wir es mal so für mein pers. Umfeld, ich hatte mir vor ~7-Jahren einen eigenen Router für hinter das Modem gekauft als das alles noch kein Thema war und war lange Jahre zufrieden mit ihm, bis ich eines Tages ~ 2,5 Jahre her einen Netcologne-Adresseneintrag (=auch mein Provider) ziemlich versteckt in der abgeschalteten DMZ-Zone fand welchem es mir selbst mit einem Firmwareupdate nicht gelang zu entfernen, ich ihn aber jetzt mit einem Trick doch entfernen konnte. Aber seit der Zeit beschäftige ich mich tiefergehend mit dem Thema.

Ich wollte schon seit längerem einen Fli4l aufsetzen, was an dieversen Punkten scheiterte.

PS: 

Die LAN-Route ist fast immer und überall auf 1-Route gesetzt, d.h. die Pakete die weitere Hops entferntliegen sollten eigentlich verworfen werden, zusammen mit Arp-Masken ist dies schon ein erhebliches Hinderniss. Also wenn nicht Softwarebugs auf der TCP- oder IP- Seite auf dem Linux-Desktop herschen sollte dieser kombinierte Weg gleich sicher sein wie ein Linux-Router, oder sind die Softwarequellen nicht etwa gleich auf den Routern.

Ist dem Desktop-Host eine lokale Adresse mit lokaler Route 1 bekannt sollte doch der angebliche "Man-in-the-middle"-Host bei möglicher gleicher MAC einen Hopseintrag oberhalb von 1 sein und dessen Pakete verworfen werden weil die Route nicht stimmt, natürlich nur solange diese Implementierung korrekt umgesetzt wird. Sollte er eine andere MAC haben sind selbst bei geflutetem Router die Pakte nicht für ihn addressiert. Soll heissen, die würden wenn der lokale Zielrechner nicht zu 100% ausgelastet ist dieser die Acc-Pakete schneller bestätigt (unter 0,1ms) als der über mehrere Router entfernte Angreifer, so das der Angreifer kaum alles mitbekommen kann. Es ist ja zumindest noch 1 weiterer Router zwischen dem Lokalen zuhause und dem Vermittlungspunkt sowie dem Providerknotenpunkt, sollten alle geflutet sein, gäbe es zuviele Kollisionen auf dem dann breiten Netz. Soweit die Theorie, kann aber auch sein das ich an dieser Stelle nicht weit genug gedacht habe.

----------

## think4urs11

 *Max Steel wrote:*   

> Hört besser auf xD Sonst holt sich der Staat hier noch Eindrücke

 

 :Twisted Evil:   :Cool: 

 *UTgamer wrote:*   

> ....Aber seit der Zeit beschäftige ich mich tiefergehend mit dem Thema.

 

Ist im Prinzip mit jedem Gerät so das man nicht vollständig selbst aufgesetzt hat.

Nur hat nicht jeder das Wissen/Material/Zeit dazu sich selbst einen Router aufzubauen. Genaugenommen darf man dafür auch nur ein extra gehärtetes OpenBSD Marke 'Thinki paranoia-proofed' nehmen (das u.a. exakt gar keinen Service im Netz anbietet, nur pf)  :Wink: 

Einem Angreifer mit Ahnung genügt ein einziges Loch, den Rest macht die Zeit, genau wie Karies.

Und wenn ich deine Infrastruktur nicht direkt von außen angreifen kann dann eben via Javascript auf Webseiten, ActiveX, PDF-Files, diverse sonstige Dateiformate, Flash, Silver, XSS, CSRF, clickjacking, ....

Jede Wette mindestens ein Loch hast du übersehen.

Bei einem halbwegs kompetenten Admin mit ein bischen Paranoia der OOS einsetzt sieht das BKA aber (von außen) schnell ziemlich alt aus.

Gegen MAC-Flooding hilft u.a. ein managebarer Switch; den kann man dann z.B. schlicht so vernageln das 1Port=1Mac - ändert sich da was: port shutdown.

 *UTgamer wrote:*   

> Die LAN-Route ist fast immer und überall auf 1-Route gesetzt, d.h. die Pakete die weitere Hops entferntliegen sollten eigentlich verworfen werden, 

 

sofern sie nicht gebridged werden, dann ist das schnuppe - oder das Gateway schlicht die Header umschreibt. Dann merkst du das bestenfalls an den längeren Antwortzeiten.

 *UTgamer wrote:*   

> zusammen mit Arp-Masken ist dies schon ein erhebliches Hinderniss.

 

Zugegeben, der Aufwand mehrere kombinierte Maßnahmen so zu brechen das es nicht auffällt steigt sehr schnell in Bereiche wo die gute alte Beugehaft+Daumenschraube+rickrolling effektiver ist  :Very Happy: 

Aber wen statisches Arp ernsthaft eine relevante Zeit aufhält der hat (in dieser BKA-Abteilung) exakt nichts verloren.

 *UTgamer wrote:*   

> Sollte er eine andere MAC haben sind selbst bei geflutetem Router die Pakte nicht für ihn addressiert. 

 

ProxyARP

 *UTgamer wrote:*   

> ...weiterer Router zwischen dem Lokalen zuhause und dem Vermittlungspunkt sowie dem Providerknotenpunkt, sollten alle geflutet sein, gäbe es zuviele Kollisionen auf dem dann breiten Netz.

 

häh?

ich muß nichts fluten wenn ich lediglich auf Routinglevel angreife außer der MAC-table deiner Switches/Endgeräte.

----------

## UTgamer

@Think4UrS11 ich lade dich gern mal zu einem WE zur Fun-Installparty bei mir ein, ich habe da noch einen 650MHz 512MB Rechner, für den ich jetzt auch endl. wieder nach längerer Zeit eine DIN-Tastur neu beschaffen konnte und damit demnächst endlich als Routerversuchskaninchen arbeiten kann. Er hat eine DUAL-Intel-Servernetzwerkkarte die frei programmierbar ist. Sehr sehr nettes Teil. Ist zur Zeit noch ein Uralt-Suse und ein Win2K drauf, kann alles runter. *g*

Offizielle Einladung für OpenBSD Marke 'Thinki paranoia-proofed' Fun-Abend   :Mr. Green: 

Wenn ich selbst alles machen muß wirds nur ein http://www.fli4l.de/ werden.

http://de.wikipedia.org/wiki/Fli4l

http://fli4l.ksware.de/

http://www.fli4l.de/fileadmin/doc/deutsch/html/fli4l-3.2.0/index.html

----------

## ChrisJumper

Also, eigentlich bin ich immer davon ausgegangen das ich mich im Bereich der Netzwerke und den bekannten und möglichen Zugriffsmethoden auf/als Netzteilnehmer auskenne. Doch deine Angst vor dem mDNSResponder bzw. der Verwendung von mDNS kann ich nicht so ganz nachvollziehen, auch was dies mit KDE zu tun haben soll erschließt sich mir nicht wirklich.

Edit: Ohne utgamer und mv im folgenden Absatz etwas unterstellen zu wollen, ich glaub ich hab euch/diesen Thread zuerst falsch verstanden und jetzt hab ich das auch schon alles geschrieben und bin zu faul zum umschreiben, also werfe ich das einfach mal in den Raum... -_-

Ohne das ihr sowas gesagt oder behauptet habt... liest einfach weiter *g*

Das man dadurch deinen ganzen (also auch den über 127.0.0.1) IP-Verkehr abhören kann ist einfach falsch. 

Es ist auch nicht so das KDE im Rahmen der Interprozesskommunikation hier ungepflegt alles ausplaudert. Zudem gehe ich davon aus das ein solches Programm, in einem gewissen Rahmen mit den sichersten default Einstellungen installiert wird. Und eben nicht im Plauderton alles preisgeben.

Wenn ich das (mit der Funktionsweise von mDNS) jetzt auch nicht falsch verstanden habe wird dies auch nur von einigen Diensten/Anwendungen genutzt. Ich vermute hier sowas wie ein Remote-Service, Streaming von Audio oder Video-Daten usw. das ganze Verhalten ist  aber an Programme und deren Einstellungen von und in KDE gebunden. Benutzt man diese Programme nicht hat man nichts zu befürchten.

Ohne mich jetzt tiefer mit der Funktionsweise von mDNS zu beschäftigen, klingt es für mich wie eine spezielle Anfrage über die Multicast-Adressen, welche dann vom Client/mDNS-Dienst bearbeitet werden und dieser Antwortet dann irgendwie darauf. Er plaudert aber nicht irgendwelche gefährlichen Dinge aus oder fungiert als Ersatz für die bekannte Namensauflösung im Internet.

Wenn du doch noch Angst haben solltest, mach einfach das was am sichersten ist und halte deine Ports geschlossen. Stört es dich dennoch, finde heraus wie die "mDNS-Pakete" aussehen und verwerfe diese.

Was das jetzt alles mit Routern zu tun hat will sich mir noch nicht so direkt erschließen, es scheint dir auch mehr um MiM-Attacken zu gehen als um KDE, deine Überschrift ist hier nicht gut gewählt.

Zum Sorgenkind Router:

Diese Firewall-Router-Internetzugangsboxen, halte ich auch nicht für sonderlich Vertrauenswürdig. Allerdings ist mir die Sicherheit diesbezüglich auch nicht so wichtig. Zwar vertraue ich diesen kleinen Boxen aus Stromverbrauch-Gründen noch meine ISP-Zugangsdaten an, aber das wars dann auch schon. DNS oder DHCP-Service wird deaktiviert, auch dessen Firewall. Die Firmware wird regelmäßig Aktualisiert und ein sicheres Passwort verwendet. Das wars dann auch schon. Wichtige Verbindungen von meinen Rechnern im LAN gehen nur verschlüsselt über diese Leitung. Der Rest ist internet typisch (wie diese Browser Meldung das dritte die Daten mitlesen können.) unsicher. Und mir auch egal.

Zum Thema Sicherheit:

Ich halte hier (bekannte) Lücken im DNS gebrauch für gefährlicher. Irgendwann werde ich als alternative einen DNSSEC-Server verwenden oder einfach ein Programm/Plugin schreiben das mich auf die Änderungen der IP-Adressen von wichtigen Adressen aufmerksam macht.

Kritische Lücken sehe ich nicht direkt im Netzwerk sondern auf Applikationsebene. Browser und dessen Plugins, wie Think4UrS11 bemerkte. Es ist einfach leichter u. bequemer sich vom client-system aus im internen Netzwerk umzusehen als sich den Stress mit dem man in the middle zu machen.

Auch eine schlechte (ungepflegte, Standard) IPV6-Konfiguration ist hier bedenklicher. Solltest du auch noch Windows-Rechner im Netzwerk haben dann gib dort besonders acht auf die Einstellungen. Ich bin letzt zum Beispiel über Teredo_tunneling gestolpert und diverse, nennen wir es "Designfehler" die es erlauben von außen (internet) sich im LAN "umzusehen". Glücklicherweise ist dieses Protokoll(/Dienst) in WinXP (noch) nicht enthalten und in Vista zwar vorhanden aber (noch) nicht per default aktiviert. 

Ach ja und zu deinen Problemen...

 *Quote:*   

>   denn danach gab es auf einmal überall seltsame Fehler, sie häuften und häuften sich. KDE-Programme fingen an sich seltsam langsam zu benehmen und gar mein Mozilla Browser wurde manchmal unerklärlich langsam. 

 

...ich vermute das Problem liegt irgendwo anders.

Ich würde mich freuen wenn ihr (utgamer u. mv) mir nochmal erklärt was euch an mDNS so stört und genau welche Bedenken ihr da habt..

Grüße, 

Chris

----------

## mv

 *ChrisJumper wrote:*   

> Das man dadurch deinen ganzen (also auch den über 127.0.0.1) IP-Verkehr abhören kann ist einfach falsch.

 

Wie Du selbst bemerktest, hat das ja niemand behauptet. Ohne weiteres Spoofing geht das natürlich nicht.

 *Quote:*   

> Es ist auch nicht so das KDE im Rahmen der Interprozesskommunikation hier ungepflegt alles ausplaudert.

 

Es ist auch nicht so, dass z.B. Apache ungepflegt alles ausplaudert. Trotzdem installiert man ihn sich vernünftigerweise nicht einfach so und macht ihn im Internet zugänglich (wenn man nicht wirklich etwas darauf anbieten will): Wieso soll man einen Angriffsvektor schaffen, für dessen Dienste man nicht den geringsten Bedarf hat?

 *Quote:*   

> Zudem gehe ich davon aus das ein solches Programm, in einem gewissen Rahmen mit den sichersten default Einstellungen installiert wird.

 

Das weiß ich nicht, und es spielt auch keine Rolle: Einen Netzwerkdienst, den ich nicht anbieten will, installiere ich auch nicht. Programme haben immer wieder Bugs, und es werden immer wieder neue Angriffsmethoden gefunden.

 *Quote:*   

> Ich vermute hier sowas wie ein Remote-Service, Streaming von Audio oder Video-Daten usw. das ganze Verhalten ist  aber an Programme und deren Einstellungen von und in KDE gebunden.

 

Nein; es geht um so eine Art "dynamisches" dhcp, also dem automatischen Zuweisen lokaler Netzadressen aufgrund der MAC-Gerätekennung (der Punkt liegt auf automatisch; inwiefern man das einschränken kann, habe ich mir nicht angeschaut, und es interessiert mich auch nicht, weil ich es gar nicht anbieten möchte: In einem statisch konfigurierten Netzwerk ist das grober Unfug [wie ich schrieb, sieht die Sache natürlich anders aus, wenn man ein Service-Netz betreibt, in das sich laufend neue Rechner einloggen sollen]).

 *Quote:*   

> Benutzt man diese Programme nicht hat man nichts zu befürchten.

 

Doch: zeroconf hat ja nichts mit KDE zu tun. Das ist ja das Perverse, dass die KDE-Ebuilds trotzdem dessen Installation verlangen, nur weil einige KDE-Programme es benutzen könnten. Ganz abgesehen davon, dass KDE selbst in der Minimalinstallation schon genug Plattenspeicher frisst.

 *Quote:*   

> Wenn du doch noch Angst haben solltest, mach einfach das was am sichersten ist und halte deine Ports geschlossen.

 

Viele Ports möchte man aber zumindest dem lokalen Netz offenhalten. Das geht dann aber nicht mehr sicher: Der Clou an zeroconf ist ja, dass sich damit ein Fremdrechner u.U. (durch ARP-Poisoning) als lokaler Rechner "einschmuggeln" kann.

Und niemals zu vergessen: Bugs in zeroconf selbst (oder Schwächen in dessen Protokoll, die bislang vielleicht nur noch nicht bekannt sind), erlauben möglicherweise sogar noch viel leichtere Angriffe. Wie lange hat es gedauert, bis der IP-Stack des Kernels keine solchen Bugs mehr hatte?

----------

## think4urs11

 *ChrisJumper wrote:*   

> Ich bin letzt zum Beispiel über Teredo_tunneling gestolpert und diverse, nennen wir es "Designfehler" die es erlauben von außen (internet) sich im LAN "umzusehen".

 

Mal abgesehen davon das derzeit noch nicht allzuviel mit IPv6 los ist wird das ganze nur dann zum Problem wenn man internen Hosts direkte Verbindungen ins Internet aufbauen läßt. Das Risiko ist also (fast) identisch zu jedem beliebigen anderen Dienst/Anwendung der das darf. Ähnliches kann ich auch mit einem DNS/ICMP/HTTP/foobar-Tunnel machen.

----------

## UTgamer

@ChrisJumper, du möchtest etwas zum Thema mDNSresponder oder auch zur so genannten Zeroconf-Technik von Apple erfahren?

Dann les dir diesen Artikel einmal ganz genau durch, gut er ist zwar von 2006, aber die heutige Implementierung funktiniert immer noch genau so wie dort beschrieben, es wurde nur an den erkannten Diensten weiter gefeilt.  :Wink: 

http://www.linux-magazin.de/heft_abo/ausgaben/2006/03/null_arbeit

Auf Seite 2 ist eine Box mit dem Titel: Sicherheit von MDNS 

Hier der Auszug für dich:

 *Quote:*   

> Ähnlich wie DHCP ist MDNS ausschließlich für lokale Netzwerke gedacht und explizit nicht fürs Internet. Es besitzt keinerlei Sicherheitsvorkehrungen, alle MDNS-Teilnehmer müssen sich gegenseitig vertrauen. Sie verwalten den Namensraum ».local.« gemeinsam und kooperativ. Erweist sich eine Station als Störenfried oder dringen Angreifer ins lokale Netz ein, ist es für sie einfach, MDNS zu missbrauchen. Sie könnten bereits registrierte Dienste durch eigene unter dem gleichen Namen ersetzen und so etwa den Druckverkehr auf einen Server im Internet umlenken. Auch die bloße Kenntnis der internen Infrastruktur ist schon gefährlich.
> 
> Um das Risiko zu vermindern, sendet Avahi auf Netzwerkschnittstellen, die ins Internet führen könnten, keinen MDNS-Verkehr. Trotzdem ist es zu empfehlen, zentrale Firewalls so zu konfigurieren, dass sie den UDP-Port 5353 in beiden Richtungen sperren.
> 
> Die Avahi-Entwickler arbeiten daran, die vom klassischen DNS bekannte DNSSEC-Technik auch für MDNS zu implementieren. Die erlaubt es, MDNS-Verkehr, der nicht mit einem vorgegebenen kryptographischen Schlüssel kodiert ist, zu ignorieren. Somit können nur Computer, die diesen Key kennen, an der ».local.«-Domain teilnehmen. Leider widerspricht dies der Zeroconf-Idee, weil es nötig ist, vorab für jeden Teilnehmer im Netz den Schlüssel zu konfigurieren. 

 

Bis Heute sind noch keine kryptographischen Schlüssel implementiert.

Also bist du über Arp-Poisioning/Spoofing hinter den Router gelangt steht dir die LAN-Welt des Angegriffenen völlig offen. 

Tja und da KDE unter Gentoo nicht ohne mDNSresponder zu haben ist ist dein LAN offen für jeden echten Profi, jetzt kommtst eben nur noch auf die Dienste an die im LAN angeboten werden, wie CIFS/NFS-Shares, Drucker, ext. USB-Platten-Server, Webserver ... also alles was im LAN läuft und sei dir sicher mDNSresponder bietet alle diese Dienste freiwillig und umlenkbar an. Das ist der Präsentierteller persönlich, denn es vertraut dem Man-in-the-middle-Angreifer voll und ganz.  :Wink: 

PS:

Microsoft mit Windows ab XP und Apple verwenden ebenfalls diese Technik heist dort dann Zeroconf oder abgewandelt Avahi.

Sollte ein/dein Windows mal eine IP-Adresse haben die mit 169.xxx.xxx.xxx anfängt dann ist diese von Zeroconf vergeben worden.

Gruß

----------

## firefly

 *UTgamer wrote:*   

> 
> 
> Tja und da KDE unter Gentoo nicht ohne mDNSresponder zu haben ist ist dein LAN offen für jeden echten Profi, jetzt kommtst eben nur noch auf die Dienste an die im LAN angeboten werden, wie CIFS/NFS-Shares, Drucker, ext. USB-Platten-Server, Webserver ... also alles was im LAN läuft und sei dir sicher mDNSresponder bietet alle diese Dienste freiwillig und umlenkbar an. Das ist der Präsentierteller persönlich, denn es vertraut dem Man-in-the-middle-Angreifer voll und ganz. 
> 
> 

 

öhm das stimmt nicht, soweit ich das weis. mDNSResponder bietet keinen Dienste an, solange du den dienst nicht gestartet hast  :Wink: . KDE verwendet nur die client libs um MDNS anfragen zu senden und angebotene Dienste festzustellen.

----------

## think4urs11

 *firefly wrote:*   

> KDE verwendet nur die client libs um MDNS anfragen zu senden und angebotene Dienste festzustellen.

 

selbst dann muß es mir nur gelingen einen mdns-Server in deinem Netz an den Start zu bringen und du hast ein Problem bei jeder Ressource die darüber angefragt und später benutzt wird da du nicht sicher sagen kannst ob die Adresse der Ressource nun die richtige oder die gefakte ist. (außer durch manuelle Kontrolle)

----------

## firefly

 *Think4UrS11 wrote:*   

>  *firefly wrote:*   KDE verwendet nur die client libs um MDNS anfragen zu senden und angebotene Dienste festzustellen. 
> 
> selbst dann muß es mir nur gelingen einen mdns-Server in deinem Netz an den Start zu bringen und du hast ein Problem bei jeder Ressource die darüber angefragt und später benutzt wird da du nicht sicher sagen kannst ob die Adresse der Ressource nun die richtige oder die gefakte ist. (außer durch manuelle Kontrolle)

 

Das bestreite ich auch nicht. Es ging mir nur um die Aussage, dass nur durch die Installation von mDNSResponder, dieser schon Dienste anbieten würde, obwohl der mDNSResponder Dienst nicht gestartet und konfiguriert ist. Und diese Aussage ist falsch.

----------

## think4urs11

Schon klar aber im aktuellen Kontext hätte der Eindruck entstehen können das die client-libs alleine nichts böses sein können.

Lieber einmal zuviel darauf hinweisen als einmal dumm gekuckt  :Wink: 

----------

## firefly

 *Think4UrS11 wrote:*   

> Schon klar aber im aktuellen Kontext hätte der Eindruck entstehen können das die client-libs alleine nichts böses sein können.
> 
> Lieber einmal zuviel darauf hinweisen als einmal dumm gekuckt 

 

jo  :Smile: 

Naja eine client lib an sich können nicht böse sein, ausser sie ist schlecht programmiert. Nur im Zusammenhang mit einem kompromittierten Service, welche von der client lib verwendet wird, kann ein schaden angerichtet werden.

Und dies gilt nicht nur für mdns, sonder das kann man auch auf DNS und DHCP ausweiten.

So langsam sollte der Titel des Threads angepasst werden, denn die Diskussion hat nicht mehr viel mit KDE an sich zu tun. Und KDE ist auch hier nicht das Problem sondern eher das gentoo ebuild von kdelibs. Wobei dies nur für die version 3.5.x gilt. Die ebuilds von kdelibs 4.x haben diesen Fehler nicht, da kann man die kdelibs, ohne hacks, auch ohne mDNSResponder installieren.

----------

## UTgamer

 *firefly wrote:*   

> Naja eine client lib an sich können nicht böse sein, ausser sie ist schlecht programmiert. Nur im Zusammenhang mit einem kompromittierten Service, welche von der client lib verwendet wird, kann ein schaden angerichtet werden.

 

 *UTgamer wrote:*   

>  *Quote:*   ... Erweist sich eine Station als Störenfried oder dringen Angreifer ins lokale Netz ein, ist es für sie einfach, MDNS zu missbrauchen. Sie könnten bereits registrierte Dienste durch eigene unter dem gleichen Namen ersetzen und so etwa den Druckverkehr auf einen Server im Internet umlenken. Auch die bloße Kenntnis der internen Infrastruktur ist schon gefährlich. ...  

 

Na wenn dies (^ dicke Schrift) kein von mDNS angerichterer Schaden ist weiß ich nicht was bei dir sonst ein Schaden sein soll.   :Rolling Eyes: 

Macht dir also nichts aus wenn du eine Kündigung, Ausschreibung, Bestellung, etc auf einen fremden Rechner im Internet ausdruckst? Oder deine Dateien statt auf ein lokales Netzwerkshare auf ein Internetnetzwerkshare abspeicherst? 

Mir und weiteren macht es aber etwas aus.

mDNSresponder/Avahi kannst du z.B.nicht mal auf einer LAN-Party ohne INet-Anschluß einsetzen bei welcher es nur um Spiele geht, denn auch dort sind Bösewichte die dir Trojaner unterjubeln wollen, z.B. beim laden von Mods/Addons, etc. Vergiss diese Technik einfach komplett, sie ist es nicht Wert so halb ausgegoren überhaupt bei Endanwendern mit INetanschluß verbreitet zu werden. Und ja unter Gentoo ist KDE einfach das Problem, es sorgt dafür da ich gezwungen bin diese Technik mitzuinstallieren und ich möglicherweise dadurch auf fremde DNS-Server, Drucker, Shares etc ausgebe/zugreife als auf meine eigenen.

----------

## firefly

 *UTgamer wrote:*   

>  *firefly wrote:*   Naja eine client lib an sich können nicht böse sein, ausser sie ist schlecht programmiert. Nur im Zusammenhang mit einem kompromittierten Service, welche von der client lib verwendet wird, kann ein schaden angerichtet werden. 
> 
>  *UTgamer wrote:*    *Quote:*   ... Erweist sich eine Station als Störenfried oder dringen Angreifer ins lokale Netz ein, ist es für sie einfach, MDNS zu missbrauchen. Sie könnten bereits registrierte Dienste durch eigene unter dem gleichen Namen ersetzen und so etwa den Druckverkehr auf einen Server im Internet umlenken. Auch die bloße Kenntnis der internen Infrastruktur ist schon gefährlich. ...   
> 
> Na wenn dies (^ dicke Schrift) kein von mDNS angerichterer Schaden ist weiß ich nicht was bei dir sonst ein Schaden sein soll.  
> ...

 

Das meinte ich doch. Ein "Angreifer" ist in dein Netz eingedrungen, z.b. durch Kapern eines Rechners. Und verwendet die mDNS implementation auf diesem Rechner um einen anderen Dienst durch seinen eigenen zu ersetzen. Was anderes habe ich nicht behauptet. Ich habe nur behauptet, das eine client lib an sich nicht bösartig ist, solange diese nicht schlecht programmiert ist. Nur wenn ein Angreifer den Service, welche durch die client lib angesprochen wird, kompromittiert, kann ein schaden entstehen. Aber nicht alleine durch die client lib.

----------

## UTgamer

Du beachtest nicht das der Angreifer keinen einzigen deiner LAN-Rechner selbst kompromitiert haben muß.

Der Router wird geflutet und fungiert nur noch als Bridge jetzt kann der Angreifer auf der WAN-/Internet- Seite liegen und liest deine vorhandene mDNS-Konfiguration einfach aus und bietet ebenfalls einen Service unter gleichem Namen an wie bereits einer in deinem Netz vorhanden ist. 

Bleibe ich mal am Beispiel eines Remote-Druckers, du druckst eine Bestellung mit Kontendaten aus und sendest sie an den Host/Rechner der deine Druckerqueue hält oder einem Netzwerkdrucker, jetzt druckst du natürlich deine Bestellung samt Adresse und Kontodaten auch beim Angreifer aus. Deine eigenen Rechner müssen nicht einmal eine einzige Lücke besitzen. Oder du hast eine SMB/Cifs Freigabe auf einem deiner Rechner und möchtest dort etwas abspeichern, z.B. deine Konfigdateien um bei Rechner-/Festplatten- Crash Backups zu haben. Du speicherst sie nicht nur auf deinem Rechner ab sondern auch auf dem Angreiferrechner im Internet, genausogut kannst die die dann möglicherweise bewußt kompromitierten Konfigdateien wieder vom falschen Anbieter aus dem Internet herunterladen, obwohl auf deiner eigenen Netzwerkfreigabe die Echten liegen.

Jetzt verstanden das mDNSresponder oder Avahi als von dir sogenannte "Clientlibs" selbst das Problem der Lücke sind?

[Edit]

PS: Unter Windows und Apples sind diese "Features" standardmäßig eingeschaltet. Man will ja Linuxdistries dem anpassen, kann ja nicht angehen das Linuxer an dem supertollen "Feature" nicht teilhaben können.

Man nennt es auch "broken by design"

----------

## firefly

 *UTgamer wrote:*   

> Du beachtest nicht das der Angreifer keinen einzigen deiner LAN-Rechner selbst kompromitiert haben muß.

 

Aber sie sind in dein lokales Netz eingedrungen bzw. haben es um ihre Rechner erweitert.

 *UTgamer wrote:*   

> Jetzt verstanden das mDNSresponder oder Avahi als von dir sogenannte "Clientlibs" selbst das Problem der Lücke sind?

 

Ähm dann dürftest du auch kein DHCP oder DNS verwenden, bzw. clients davon installiert haben. Denn über DNS könnte man dein Beispiel, mit dem umleiten von anfragen an einen Netzwerkdrucker, auch bewerkstelligen.

Die client libs werden erst ein Teil der Lücke, wenn zusätzliche Faktoren dazukommen. Zum einen muss dein Netzwerk kompromittiert werden. Und zum anderen musst du mDNS in irgend einer Form verwenden.

Solange du nicht den mDNS Service auf deinem Rechner gestartet hast, bzw. kein Programm verwendest, welche die mDNS Unterstützung verwendet, kann da auch nichts passieren.

Nur weil die kdelibs mit mDNS support übersetzt wurden, heißt es noch lange nicht, das mDNS verwendet wird. Denn solange kein Programm eine Funktion der kdelibs verwendet, welche zusätzlich mDNS für die Auflösung von Netzwerknamen verwendet, sind die client libs von mDNS ungefährlich.

Und soweit ich weis, wird mDNS nur verwendet wenn versucht wird einen Netzwerknamen zu erreichen/ ein Netzwerkservice zu verwenden, welche im Netzwerknamen das postfix .local haben. Alle anderen werden versucht über DNS aufzulösen.

Also sind nicht die clientlibs, hier mDNSResponder, alleinig für das Problem der Lücke verantwortlich.

Es ist natürlich besser, wenn man für ein Funktion/Protokoll, welches man nicht verwendet/verwenden möchte erst gar nicht Programme und oder libs installiert, welche die Funktion bzw. das Protokoll unterstützen.

----------

## firefly

 *UTgamer wrote:*   

> PS: Unter Windows und Apples sind diese "Features" standardmäßig eingeschaltet. Man will ja Linuxdistries dem anpassen, kann ja nicht angehen das Linuxer an dem supertollen "Feature" nicht teilhaben können.
> 
> Man nennt es auch "broken by design"

 

Naja mDNS würde ich nicht unbedingt broken by design nennen. Es ist halt eine Möglichkeit, dass sich Rechner über einen Namen in einem Netzwerk finden, ohne das eine Zentrale Stelle dafür notwendig ist, wie bei DNS.

Und jetzt komm nicht mit "das kann man auch dadurch erreichen, wenn man IP-Adressen direkt verwendet". Ein Mensch kann sich leichter Namen merken als Nummernfolgen. Und spätestens mit IPv6 ist das merken von mehreren IP-Addressen für einen Menschen nahezu unmöglich. Auch mit IPv4 hast du das Problem, wenn das Netzwerk größer wird.

Zusätzlich hast du Probleme, wenn du IP-Adressen direkt verwendest, wenn sich für ein Dienst sich die IP ändert (z.b. der Dienst läuft zukünftig auf einem anderen Rechner). Dann müsstest du jedem Client, welcher auf diesen Dienst zugreift, auf die neue IP-Adresse um konfigurieren.

----------

## UTgamer

 *firefly wrote:*   

> Und jetzt komm nicht mit "das kann man auch dadurch erreichen, wenn man IP-Adressen direkt verwendet".

 Doch es gibt Menschen wie z.B. mv und mich sowie weitere die genau diesen Weg gehen wollen.

 *firefly wrote:*   

>  Ein Mensch kann sich leichter Namen merken als Nummernfolgen. Und spätestens mit IPv6 ist das merken von mehreren IP-Addressen für einen Menschen nahezu unmöglich. 

 Da gebe ich dir ganz recht. 

Man merkt aber auch das du selten bis nie auf einer mittelgroßen LAN-Partie (50-200) Spieler bist. Dort wird ebenfalls über IP-Listen als sauberste Implementierung gespielt. Eine Tischreihe enthält eine IP-Reihenfolge die strickt einzuhalten ist, somit können die Admins überprüfen wenn/wann ein Clientrechner etwas verbotenes macht. Dort sind ebenfalls Organisatoren die  Neulinge erklären wie sie ihr Netzwerk einrichten müssen, und da ich in meiner Umgebung bereits recht bekannt bin gehöre ich auch zu den Helfern sowohl für Windows als auch Linux.

Oberhalb von 100 Personen haben die Organisatoren Probleme Angreifer auszumachen. nichts ist wertvoller als feste IP-Adressen in solch einem Netz von unsicheren hochgetunten Spielerechnern.

----------

## mv

 *firefly wrote:*   

> Denn über DNS könnte man dein Beispiel, mit dem umleiten von anfragen an einen Netzwerkdrucker, auch bewerkstelligen.

 

Deswegen wird man auch z.B. in seinem Heim-Netz den Drucker nicht per Namen ansprechen sondern per IP. Und nein, die IP muss man sich nicht merken: Man trägt sie einmalig in einer geeigneten Config-Datei ein. Oder wenn man doch Namen will, benutzt man die /etc/hosts.

Und richtig: dhcp hat man normalerweise ebenfalls nicht installiert, außer man benötigt diesen Dienst tatsächlich.

----------

## firefly

 *UTgamer wrote:*   

> Man merkt aber auch das du selten bis nie auf einer mittelgroßen LAN-Partie 50-200 Spieler bist. Dort wird ebenfalls über IP-Listen als sauberste Implementierung gespielt. Eine Tischreihe enthält eine IP-Reihenfolge die strickt einzuhalten ist, somit können die Admins überprüfen wenn/wann ein Clientrechner etwas verbotenes macht. Dort sind ebenfalls Organisatoren die  Neulinge erklären wie sie ihr Netzwerk einrichten müssen, und da ich in meiner Umgebung bereits recht bekannt bin gehöre ich auch zu den Helfern sowohl für Windows als auch Linux.
> 
> Oberhalb von 100 Personen haben die Organisatoren Probleme Angreifer auszumachen. nichts ist wertvoller als feste IP-Adressen in solch einem Netz von unsicheren hochgetunten Spielerechnern.

 

Das stimmt ich bin sehr selten auf LANs. Aber auf einer LAN ist das zum Teil auch recht einfach nur mit IP-Adressen zu arbeiten. Ihr z.b. macht eine Zuordnung IP-Adresse = Netzwerkanschluss am Hub/Switch bzw. IP-Adressbereich = Tischreihe. Und zusätzlich muss sich jeder Teilnehmer bei euch melden um zu erfahren welche IP-Adresse er verwenden kann. Dadurch hat man es leicht einen Überblick zu erhalten.

Nur bei Netzwerken, wo Dienste über den selben Pfad erreichbar sein sollte, dann ist eine reine IP-Adressen basierende Lösung nur schwer durch zu führen. Denn was ist, wenn der Dienst, aufgrund von Last Problemen des Rechners, auf dem der Dienst läuft, auf einen anderen Rechner umziehen muss. Dann hast du mit einer reinen IP-basierende Lösung ein Problem. Denn dann musst du, wie ich schon schrieb, die Änderung der IP-Adresse jedem Client, welcher den Dienst verwendet, irgendwie mitteilen. Und hierfür ist einen Namensbasierende Lösung besser. Denn hierdurch muss der Client nur den Namen kennen unter dem der Dienst erreichbar ist. Wie du sicher schon weist, wird ein zusätzlicher Mechanismus benötigt um einen Name in eine IP-Adresse aufzulösen. Hierfür gibt es den DNS Dienst. Bei der bisherigen Implementation von DNS wird aber eine Zentrale stelle benötigt, welche die Namensauflösung durchführt.

mDNS ist, soweit ich das weis, ist eine andere Implementation von DNS bei der die Zentrale stelle nicht benötigt wird. Bei mDNS wird die Zuordnung von Namen zu einer IP-Adresse gemeinschaftlich gemacht. Ein Rechner kann nicht nur erfahren welche IP-Adresse hinter einem Namen steckt sondern er kann zusätzlich herausfinden welche Dienste im Netzwerk angeboten werden.

Dieses Verfahren der gemeinschaftlichen Verwaltung eines Netzwerk ohne Zentrale stelle beruht aber auf einem gegenseitigen Vertrauen. Sobald mindestens ein Rechner im Netzwerk nicht mehr vertraut wird dann ist dieses Verfahren des dezentralen Netzwerkmanagements nicht mehr sicher.

Meiner Meinung nach ist mDNS nicht für große Netzwerke geeignet, da durch die dezentrale Natur des IP-Adress vergabe und auflösen von Namen zu IP-Adressen es fast unmöglich macht so ein Netzwerk ab zusichern (wenn es rein mDNS oder eine andere implementation von zeroconf verwendet). Aber in kleinen (was bedeutet klein  :Wink: ) Netzwerken, bei denen die Nutzer sich überhaupt nicht ums Netzwerkmanagement kümmern möchte, kann mDNS eine gute Lösung sein. Auch der Zugriff aufs Internet ist da meist unproblematisch solange ein Router verwendet wird, welche das lokale Netz vom Internet abschottet.

Und hier sind wir wieder bei deinem Anfangs Argument gegen mDNS: was passiert wenn der Router kompromittiert wird.

Gegen eine Kompromittierung eines Gerätes im Netzwerk ist momentan fast keine Netzwerktechnik gesichert. Der Angreifer erhält dann einen Einblick in deine Netzwerkstruktur. Einen Angriff auf einen Rechner/Dienst wird zugegeben durch mDNS erleichtert (Aufgrund der dezentralen Netzwerkverwaltung) aber das ist kein alleiniges Problem einer installierten client lib (hier mDNSResponder). Du aber nennst das vorhanden sein von mDNSResponder auf deinem System als einzige Quelle des Problems. Nur damit die Installation von mDNSResponder zum Problem wird müssen zusätzliche Faktoren vorhanden sein. Welche das sind werde ich an dieser Stelle nicht nochmal wiederholen.

 *UTgamer wrote:*   

>  *firefly wrote:*   Und jetzt komm nicht mit "das kann man auch dadurch erreichen, wenn man IP-Adressen direkt verwendet". Doch es gibt Menschen wie z.B. mv und mich sowie weitere die genau diesen Weg gehen wollen.
> 
> 

 

Das ist aber kein Argument, Techniken wie mDNS komplett zu verteufeln. Zu mindestens kommt es mir so, vor als würdest du das machen.

----------

## firefly

 *mv wrote:*   

>  *firefly wrote:*   Denn über DNS könnte man dein Beispiel, mit dem umleiten von anfragen an einen Netzwerkdrucker, auch bewerkstelligen. 
> 
> Deswegen wird man auch z.B. in seinem Heim-Netz den Drucker nicht per Namen ansprechen sondern per IP. Und nein, die IP muss man sich nicht merken: Man trägt sie einmalig in einer geeigneten Config-Datei ein. Oder wenn man doch Namen will, benutzt man die /etc/hosts.

 

Bei kleinen Netzwerken ist das auch durchführbar. Vorausgesetzt der Betreiber des Netzwerks will sich mit der Materie etwas beschäftigen. Nur es gibt halt auch Leute, welche sich um Dinge wie IP-Adresse und Co. kümmern wollen. Und hierfür ist mDNS eine gute Möglichkeit. Ein Neuer Rechner braucht sich nur ins Netzwerk einklinken und schon hat er Zugriff auf alle angebotenen Dienste, ohne das der Benutzer irgendetwas am Rechner konfigurieren muss.

Zugegeben dadurch wird es einen Angreifer erleichtert einen Dienst gezielt anzugreifen, aber dadurch muss der Angreifer aber Zugriff auf das Netzwerk erhalten.

Aber Nur aufgrund dieser Tatsache die Technik zu verteufeln, zu mindestens kommt mir das so vor als würde UTGamer das tun, ist auch nicht richtig.

----------

## UTgamer

 *firefly wrote:*   

> Aber Nur aufgrund dieser Tatsache die Technik zu verteufeln, zu mindestens kommt mir das so vor als würde UTGamer das tun, ist auch nicht richtig.

 

Diejenigen die keine Netzwerkausbildung wie ich (Certified Novell Engineer, Microsoft Certified Professional) genossen haben mögen es sicher so wie du, aber was ist mit denen die um Lücken und Wege Kenntniss haben, und genau deswegen von Windows weggegangen sind? Müssen diese Umsteiger sich den freien GNU-Weg verbauen lassen und wie in LFS (Linux from Scratch) alles selbst zusammenbauen? Müssen diesen Menschen ihre neu gewonne Freiheit gezwungen werden über Bord zu werfen, kann man ihnen nicht ihre Wahlmöglichkeiten lassen?

Was ist GNU, Linux und wofür steht Gentoo?

Meine HW-Flags (Fußnote) die ich seit Oktober 2005 nach jahrelanger Recherche und Assemblerkenntnissen einsetze sind ein Stück wofür GNU und auch Gentoo stehen sollen. Warum wird davon langsam abgekehrt?

Ich habe überhaupt nichts dagegen wenn sich jemand sein Netzwerk vereinfachen möchte aber genauso sollen diejenigen die sich ihr Netzwerk noch von Hand konfigurieren bitte auch nicht benachteiligt werden. 

Das ist jetzt pers. an dich gerichtet, ich rede jetzt darüber weil ich noch nicht dazu gekommen bin mich in Unix/Linux zu zertifizieren.

Wenn ich persöhnlich eine Konfiguration nicht kenne lese ich die Anleitung, verstehe ich die Anleitung nicht lass ich es bleiben. Das wurde mir in meiner Ausbildung eingetrichtert. >> Konsultiere Fachwissen oder du hast eine Sicherheitslücke und bist deinen Adminjob los.

Kommst du selbst nicht weiter gebe die Konfiguration an jemanden weiter der sich damit auskennt. Meine Kunden waren Banken, Versicherungen, High-Level-Kundensupport. Ich habe bereits Verbindungen zur Deutschen Börse und internationale Hochsicherheitskonferenzverbindungen zwischen CEOs aufgebaut (Großindustrie), als Sysadmin sowie als internationaler Konferenztechniker. Naja so ein >100.000€ Equipment wie in den Firmen habe ich zuhause nicht, und muß mich mit dem zufrieden geben was ich privat habe.

Vor wenigen Jahren träumte ich noch davon mir ein Novell-Netware-Servernetzwerk aufzubauen (http://developer.novell.com/wiki/index.php/NetWare_Management_Agent , http://www.novell.com/training/certinfo/cne/nw6.html), ich habe alles dafür was ich brauche, nur da ich mit einem Novelladmin direkt vom Hersteller Hand in Hand gearbeitet hatte wußte ich auch um Schwachstellen im Netwaresystem, unsichbaren Acounts etc. Wenn ich nur z.B. unsichtbare Accounts erstellen kann, dann kann es jemand anderes auch. Das Prinzip dort nach vielen Jahren an Managements ist: Security by obscurity.

Nein ich wollte was anderes, statt versteckter Features die nur die Eingeweihten kennen wollte ich was offenes, das was jeder nutzen und verstehen kann der nicht 10.000€ für Lizenzen ausgeben kann um mehr als 5 Clients/Server zu betreiben. Netware wird heute noch überwiegend bei Banken und Versicherungen eingesetzt, ja nach außen hin ist es sehr sehr sicher und xfach zertifiziert, aber nach innen besteht die Sicherheit aus Obscurity wie das BSI mich bestätigen kann: http://www.bsi.de/gshb/deutsch/m/m01042.htm. Wenn ich einen Webserver auf Netware installieren würde und z.B. im LAN freigebe könnte mich ein Hacker total auf einem toten Fuß erwischen, denn seien wir mal ehrlich, welcher Heimsysadmin hat die gleichen Fachkräfte für Sicherheit um sich herum wie in einem Firmennetzwerk mit z.B. gleich starken >100.000€ kostenden Firewalls. Also will ich Firewalls oder Server oder Clients zuhause Vollzeit administrieren? Sicher nicht, ich will zuhause entspannen von dem harten Arbeitsalltag. 

Was ist zuhause am sichersten? (Fangfrage)

- Etwas das nicht vorhanden ist?

- Viel Sicherheitsequipment?

- Guter Nachbar der weiterhilft?

- Forum in welchem ich fragen kann wenn ich mal Bretter vorm Kopf habe?

- Server hinter einem Panzerschrank?

Die Lösung ist ganz einfach: Etwas das nicht vorhanden ist.

Den es kann einfach nicht kompromitiert werden. Bequemlichkeit ist der erste Fuß den man sich selbst stellt. Ach ich könnte ja ... automatisieren. Also installiere ich nur das absolut nötige und was darüber hinaus geht muß ich erst erlernen bevor ich es einsetze.

OK, ich bin Hart, hart zur mir selbst, härter als die meisten zu sich selbst sind. Hier eine vereinfachung, dort eine Vereinfachung etc, etc, ... Und alles nichts wovon man selbst Ahnung hat.

Du hast keine Ahnung von wirklich sicheren Firewalls? Dann lass es und kauf dir eine fertig konfigurierte, jemand anderes kann es ganz sicher besser als du. Reparierst sicher deinen Fernseher oder dein Auto (TÜV-Mängel) auch nicht selbst, warum dann den Computer  :Wink:  Erlerne es, lese dich herein und nutze es.

^^^ Meine Einstellung, ansonsten lasse ich es.

Und ich will dich nicht in meine Kategorie einordnen. 

Währen alle gleich währe das Leben langweilung, tot und ohne Fortschritte. Ein Pionier erstellt eine Funktion, sie ist nutzbar aber nicht ausgereift, ohne die Pioniere eben auch kein Fortschritt. Also lass dich nicht von mir aufhalten oder bequatchen. Jeder muß eine einzigartige Einstellung haben. Meine ist eben: Komfort ist Luxus, aber die Grundbedingungen müssen stimmen, und die stimmen in meinen pers. Augen weder mit KDE noch mit Gnome nicht und darum lass ich es ganz einfach. So lerne ich neue Wege kennen.  :Wink: 

KPat aus KDE will ins Netzwerk > OK ohne mich > KDe runter und gesucht und gefunden > Pysol ist jetzt ein vollwertiger Spieleersatz für mich denn ich sonst niemals kennen gelernt hätte.  :Smile: 

----------

## SkaaliaN

 *UTgamer wrote:*   

>  Netware wird heute noch überwiegend bei Banken und Versicherungen eingesetzt... 

 

mh...also die beiden größten Rechenzentren im Bankenbereich in Deutschland setzen Beispielsweise nicht auf Netware. Ansonsten gebe ich dir bei deinem Post Recht...! Was sich die Konfiguration angeht...Damit haben Banken i.d.R. nicht viel am Hut wenn diese an einem externen Rechenzentrum angebunden sind. Die kümmern sich in der Regel um wiederkehrende Aufgaben (Releasewechsel, Backups etc. pp.). Der Rest liegt in der Hand des Rechenzentrums. Selbst die wiederkehrenden Aufgaben werden eines Tages verschwinden, wenn die letzten Server ins Rechenzentrum outgesourced werden. Denn da geht der Trend hin. Dicke Standleitungen, weniger lokale IT, mehr Outsourcing. "Mein Drucker druckt nicht" oder "mein Rechner geht nicht mehr an" (weil das Kabel nicht richtig steckte etc. pp., whatever...) wird in ein paar Jahren zum Allgemeinwissen gehören....Dies sollte es eigentlich auch jetzt schon tun.

Ich werde mir überlegen ob ich weiterhin kde einsetze oder nicht. Bisher fahre ich mit Enlightenment ganz gut. Bin eigentlich auch damit zufrieden. Allerdings wechsel ich auch mal gerne  :Wink: 

----------

## think4urs11

 *UTgamer wrote:*   

> Du beachtest nicht das der Angreifer keinen einzigen deiner LAN-Rechner selbst kompromitiert haben muß.
> 
> Der Router wird geflutet und fungiert nur noch als Bridge

 

Klassisches IP-Routing passiert auf Layer 3, Bridging auf Layer 2; deine Aussage ist also mindestens irreführend.

Erklär mir mal wie ich einen SOHO-Router von außen (ich nehme an mit gefakten DNS-Antworten?) so fluten können soll das dieser seine Routingfunktionalität einstellt und gleichzeitig der Angreifer von außen noch irgendwelche Daten aus deinem LAN zurückbekommt. Jeder halbwegs sauber arbeitende DNS-Forwarder/resolver sollte unangefragt ankommende 'Antworten' ignorieren.

 *UTgamer wrote:*   

> Diejenigen die keine Netzwerkausbildung wie ich (Certified Novell Engineer, Microsoft Certified Professional) genossen haben mögen es sicher so wie du, aber was ist mit denen die um Lücken und Wege Kenntniss haben, und genau deswegen von Windows weggegangen sind?

 

Ich bin unter anderem MCNE und MCSE, soviel mal dazu  :Wink: 

Wo wir uns einig sind ist die Tatsache das mDNS sicherheitstechnisch Käse ist,

Ohne es auszuprobieren sollte es aber genügen den Clients wahlweise ein/ausgehenden Traffic auf Port 5353/udp zu verbieten oder den Kernel ohne Multicast-Support zu übersetzen.

----------

## UTgamer

 *Think4UrS11 wrote:*   

>  *UTgamer wrote:*   Du beachtest nicht das der Angreifer keinen einzigen deiner LAN-Rechner selbst kompromitiert haben muß.
> 
> Der Router wird geflutet und fungiert nur noch als Bridge 
> 
> Klassisches IP-Routing passiert auf Layer 3, Bridging auf Layer 2; deine Aussage ist also mindestens irreführend.

 

Dieser engliche Cisco Artikel beschreibt das Layer2 und 3 Verhalten sehr gut: http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_1-2/switch_evolution.html

Ein Switch arbeitet auf Layer2 und verteilt die Netzwerkpakete welche auch nicht zwingend IP-Pakete sein müssen (z.B. IPX oder Appletalk, beziehe mich jetzt aber ausschließlich auf IP) in einem Subnetz oder VLAN. Alle Pakete die im gleichen Netz liegen werden darin weiter geleitet. 

In einem Netz währen in diesem Beispiel 192.168.0.xxx mit der Netzmaske 255.255.255.128 alle Rechner mit den IPs von 192.168.0.1 bis 192.168.0.127 im zweiten definierten Bereich mit dieser Netzmaske dann die IPs von 192.168.0.129 bis 192.168.0.254, die beiden Broadcastadressen sind 192.168.0.128 sowie 192.168.0.255.

Ein Soho-Switch bietet oft nichtmal eine VLAN-Konfig an und arbeitet meist nur in allen IP-Bereichen mit 254 Adressen also der Netzmaske 255.255.255.0, fast schon ein HUB nur eben mit Collisionprotection, kostet ja auch nur 20€.

Ein Router hingegen liegt auf Layer 3 und wird benötigt um zwischen z.B. diesen beiden Netzen zu übertragen. Eine oder mehrere CPUs gehen hin nehmen die Pakete die ein Netz verlassen sollen auf und verschieben sie in das andere Netz. Der Router/Switch führt in Tabellen welche MAC-Adresse zu welchem Netz gehört. *Quote:*   

> IP forwarding typically involves a route lookup, decrementing the Time To Live (TTL) count and recalculating the checksum, and forwarding the frame with the appropriate MAC header to the correct output port.

  Also sollten die MAC-Tabellen geflutet worden sein, weiss der Router nicht mehr zu welchem Netz die MACs gehören und leitet alle Pakete an alle angeschlossenen Netze weiter, also auch zum nächsten angeschlosenen Router ins Internet des Providers wo dann der eingebaute BKA-Abgriff stattfinden kann. 

So spät am Abend noch so komplizierte Fragen aufzuwerfen, gruml, bei meiner Zusammenfassung gibts textlich sicher noch was auszusetzen.

 *Think4UrS11 wrote:*   

> Erklär mir mal wie ich einen SOHO-Router von außen (ich nehme an mit gefakten DNS-Antworten?) so fluten können soll das dieser seine Routingfunktionalität einstellt und gleichzeitig der Angreifer von außen noch irgendwelche Daten aus deinem LAN zurückbekommt. Jeder halbwegs sauber arbeitende DNS-Forwarder/resolver sollte unangefragt ankommende 'Antworten' ignorieren.

 

Die ganzen Tools kenne ich nicht, das BSI hat diese Behauptung aufgestellt gehabt, siehe Link weiter oben, dann wird das auch stimmen, weil die sollten schon Beweise für solche Aussagen haben.

Dafür jetzt mal ein paar SOHO-Routernachrichten mit bösem Inhalt.

http://www.heise.de/newsticker/Trojaner-konfiguriert-Router-um--/meldung/109413

http://www.heise.de/newsticker/Router-luegen-nicht-was-wenn-doch--/meldung/114984

http://www.heise.de/newsticker/Erste-aktive-Angriffe-auf-DSL-Router-Update--/meldung/102281

http://www.heise.de/newsticker/Ungewollte-Fernkonfiguration-fuer-Heim-Router-Update--/meldung/101799

 *Quote:*   

> Petkov zeigt in seinem Bericht aber, wie sich Router auch über ActionScript in Flash-Applets umkonfigurieren lassen.Zwar kann NoScript auch Flash-Applets blockieren, andere JavaScript-Filter lassen sich aber einfach umgehen. Laut Petkov ist bei einem UPnP-Angriff via Flash nicht einmal eine XSS-Lücke im Router notwendig. Vielmehr sei Flash in der Lage, den Router über zusammengesetzte Header anzusprechen.

 

In Kombination mit anderen Schwachstellen auch solche Fehlerausnutzmöglichkeiten:

http://www.heise.de/newsticker/Neue-Sicherheitsluecke-bei-Internet-Routern--/meldung/20411

http://www.heise.de/newsticker/Voreingestellte-WPA-Schluessel-in-WLAN-Routern-leicht-erratbar--/meldung/103861

http://www.heise.de/tp/r4/artikel/24/24763/1.html

Reicht das alles als Beweislage für meine Behauptungen?.   :Rolling Eyes:   :Wink: 

Und das du Think4UrS11 fundiertes Wissen hast das wird denke ich niemand bezweifeln wollen.   :Very Happy:  Gruß

----------

## think4urs11

 *UTgamer wrote:*   

> Ein Soho-Switch bietet oft nichtmal eine VLAN-Konfig an und arbeitet meist nur in allen IP-Bereichen mit 254 Adressen also der Netzmaske 255.255.255.0, fast schon ein HUB nur eben mit Collisionprotection, kostet ja auch nur 20€.

 

Deswegen nennt man das diesen Teil des Dings ja Switch und nicht Hub.  :Wink:  Ein Switch ist im Grunde erstmal nichts anderes als eine Multiportbridge. Erst managbare Switches können mehr - Vlans, QoS und hastenichgesehen.

 *UTgamer wrote:*   

> Also sollten die MAC-Tabellen geflutet worden sein, weiss der Router nicht mehr zu welchem Netz die MACs gehörenund leitet alle Pakete an alle angeschlossenen Netze weiter, also auch zum nächsten angeschlosenen Router ins Internet des Providers wo dann der eingebaute BKA-Abgriff stattfinden kann.

 

Dem Router sind die MACs egal, der kümmert sich nur um IP-Adressen, das Problem macht der Switch darunter.

Das Fluten der MAC-table kann aber nicht von außen erfolgen, nur von innen (wenn wir mal den Fall ausklammern das jemand den ISP-Router hackt an dem du aufschlägst - und selbst da sollten zumindest einige der Routerli etwas gegen im Köcher haben).

Die ganzen Angriffe erfolgen aber alle von innen unter Zuhilfename einer internen Maschine, funtkionierende direkte Angriffe sind extrem selten.

 *UTgamer wrote:*   

> Reicht das alles als Beweislage für meine Behauptungen?.    

 

nö, weil das nur meine These untermauert das der Router nicht einfach so (von außen) geflutet werden kann  :Wink: 

----------

## UTgamer

 *Think4UrS11 wrote:*   

>  *UTgamer wrote:*   Reicht das alles als Beweislage für meine Behauptungen?.     
> 
> nö, weil das nur meine These untermauert das der Router nicht einfach so (von außen) geflutet werden kann 

 

Da ist noch ein Punkt der mir gerade einfällt.

Die Aussage des BSI das man Router von außen fluten kann bezieht sich auf die Cisxo-IOS-Switches beim Provider und in Unternehmen, jedoch nicht auf SOHO-Switches.

Denn so gut wie kein IOS (Betriebssystem) von Cisco ist bugfrei!

http://www.heise.de/security/25C3-Zuverlaessige-Exploits-fuer-Cisco-Router--/news/meldung/120983

Die meinten diese Router, und damit muß der Router des Privatmannes garnicht von außen Kompromitiert werden, man programmiert die Ciscos einfach nach gutdücken um um Pakete eines angegriffenen z.B. auszufiltern und an anderer Stelle zu verändern, siehe diese Technik wie sie von BT in England genutzt wird:

http://www.heise.de/security/BT-startet-freiwillige-Internet-Vollueberwachung--/news/meldung/116753

Naja, welcher Heimnutzer nutzt schon einen Cisco zuhause, es reicht ja wenn man die Route des Providers kompromitiert um alles in und aus dem Netzt heraus zu überwachen.

Also nichts anderes was Echelon auch schon seit jeher macht: 

http://www.heise.de/tp/r4/special/ech.html

----------

## Anarcho

 *UTgamer wrote:*   

> Naja, welcher Heimnutzer nutzt schon einen Cisco zuhause, es reicht ja wenn man die Route des Providers kompromitiert um alles in und aus dem Netzt heraus zu überwachen.

 

Womit du uns wieder recht gibst. Denn genau das können sie sowieso. Da kann man im lokalen Netz genau garnichts gegen machen. Das einzige was hierbei hilft ist und bleibt Verschlüsselung der Verbindung (HTTPS, SSL, TLS, VPN, etc).

Da kannst du dir die grössten und tollsten ARP-Tables erstellen, interessiert nicht. Schutz vor MAC-Flooding? Kommt extern nicht vor. Routerangriff? Brauchen sie nicht. Aber zum Thema Routerangriff: Wie ich schon weiter oben sagte, wer sich seinen Router nicht selber baut, kann sich bei dem Gerät halt auch nicht sicher sein. Ich an deiner Stelle würde mir deutlich mehr Sorgen um den Router als um deine ARP-Caches machen (es sei denn du lässt deine Wohnungstür immer offen wenn du gehst oder hast ne Netzwerkdose draussen auf dem Hausflur verlegt).

EDIT: Entschuldigt das ich mitrede, ich habe leider keine Tausend-EURO für MC-Dingsbums ausgegeben (noch mein Arbeitgeber). Ich habe aber immerhin mal vor etlichen Jahren den ersten Teil der LPI Prüfung bestanden und habe Informatik mit Schwerpunkt Rechnernetze studiert... Ich hoffe ich darf dennoch mitreden.   :Rolling Eyes: 

----------

## UTgamer

Ach Anarcho, ich wollte doch keinen angreifen. 

Da gibt z.B. ein BSI Routersicherheitswarnungen raus das die von Profis in unter 1 Minute geknackt sind, die SOHO-Meldungen auch noch über Heise reinkommen und erst wenn man sich mit euch doch mal wieder etwas tiefer in die Materie reindenkt dann sind nicht alle Gefahrenmeldungen so gefährlich wie sie den ersten Anschein geben.

Think4UrS11 hat sicher auch später durch nachdenken den Knackpunkt mit dem Privatbereich entdeckt.

Aber auch hier im Privatbereich sollte keine Entwarnung gegeben werden, Aktionscript von Adobe-Flash ist ebenfalls eine richtig dicke Gefahr, und wer nebenbei auch noch mit Windows hinter seinem Router surft hat die Lücke im Privatbereich schneller geöffnet als ihm lieb ist. 

Nein eine handgefertigte ARP-Tabelle schadet nicht, den sie schützt trotzdem wenn man sich den Privatrouter durch eingefangenes von innen durchlöchert. 

Also so "Paranoiker" wie mich wirst du nicht davon abbekommen, handgefertigte ARP-Tabellen zu nutzen.  :Wink: 

Ich surfe gerne mal auf Untergrundseiten und in russischen Netzen rum, wo sich so manches Hackerpotenzial sammelt. Erst letzte Woche habe ich durch Zufall beim surfen nach Linux-Demos ein dänisches Neonazinetz entdeckt, willst die Adresse haben? Aber ich warne direkt davor die Demos teils in "elf" zu installieren, wer weiß ob die nicht rechten Demos denn sauber waren die ich mir vorher als nicht-root im Userprofile installiert hatte?

Ich wollte mich schon in diesem Forum anmelden wegen der tollen Demos um mitzudiskutieren, aber nachdem was ich in den tiefergelegene Ordnerstruckturen fand war ich froh erst den 7. Sinn genutzt zu haben und vor der Anmeldung die Umgebung gecheckt hatte.

[Edit]

PS:

"Ihr" regt euch über meine Netzwerkparanoia auf währen "ihr" aber eine Festplattenparanoia habt:

https://forums.gentoo.org/viewtopic-t-713055-postdays-0-postorder-asc-start-0.html

Tsss, ich faße es nicht. Ihr habt dafür von Festplattenverschlüsselung weit mehr Ahnung als ich. 

Allerdings nutze ich einen Trick gegen Überwachung von Staatswegen. Der größte Terrorist bei uns ist für mich immer noch eine sich selbst ermächtigende Regierung, den das hatte unser Land bereits zweimal und wohin das führte wisst ihr ja auch alle.

Also eigentl. weitgehend alles was man sich herunterlädt hat eine registrierte Checksumme, und der Bundestrojaner sammelt Checksummen, siehe:

http://www.perkeo.net/

http://www.cyberfahnder.de/nav/them/erm/ondusu01.htm

Also gehe ich hin bei allem was ich downloade und jage es durch Verarbeitungsprogramme, denn dadurch habe ich nicht mehr eindeutige Checksummen mit dem was ich heruntergeladen habe, Bilder, Sound, Videos, Dokumente, ...

Schon bin ich für Überwacher genauso uninterressant wie als wenn ich die Dateien vor ihnen verstecke. Man lernt ja durch die großen: Security by Obscurity   :Laughing: 

----------

## think4urs11

 *Anarcho wrote:*   

> Ich hoffe ich darf dennoch mitreden.  

 

Titel sind nur Schall und Rauch und verdecken Flecken auf der Tapete das ist schon alles. Ich konnte es mir nur nicht verkneifen einen 'popeligen kleinen CNE' etwas auszubremsen  :Wink:   :Rolling Eyes: 

Plan haben ist viel wichtiger, und den haste  :Smile: 

@UTGamer:

Was mich bei deinem Grad an advanced paranoia wundert - warum betreibst du eigentlich nicht zwei physikalisch getrennte Netze (1m Luft reicht)? Eines für Internet und Co. und ein anderes für die wichtigen Daten. Alles andere ist inkonsequent da niemals sicher zu bekommen. Selbst mit viel Geld in Form von Infrastruktur gibt es immer Mittel und Wege. Bei einem EinzelPC physischer Zugriff, bei einem Netzwerk naja... Zugriff auf das Netz, mit Hilfe von 'innen' geht immer was - per Definition unmöglich zu verhindern.

Und vergiß Prüfsummen. Sicher ist das nur wenn die Kontrolle der Fingerprints über ein phyisch getrenntes Medium erfolgt (Telefon, Brieftaube, Buschtrommel, ...)

Ein Angreifer mit voller Kontrolle über deinen Upstreamrouter kann dir genau das zeigen was du sehen sollst. Schließlich könnte auch dein sha1sum executable passend infiziert sein; denn das hast du woher? Richtig, aus dem Internet gezogen ...

Und glaubst du wirklich ein z.B. jpg mit Gimp auf 90% herunterrechnen reicht? Es gibt Wasserzeichen die das überleben, unscharfe Prüfsummen, Bilderkennung, Steganografieanalyzer und hastenichgesehen.

An irgendeinem Punkt muß man einfach akzeptieren das es absolute Sicherheit nicht geben kann.

----------

## ChrisJumper

Sehr interessanter Thread!

Ich bedanke mich für die vielen Links und werde mal einen tieferen Blick hinein werfen, um später vielleicht nochmal darauf zurückzukommen.

Vorerst geht es mir aber darum das ich genau weiß was mDNS so unsicher macht, und wie man eben in Netzen die man nicht selber betreut ein höchstmögliches Maß an Sicherheit mit einem entsprechenden Aufwand einrichten kann. Wenn technisch weniger versierte Verwandten und Freunden das Zeroconf-Feature nutzen möchten (oder es nicht Wissen das Windows oder OS X sowas "per default" betreibt.), will ich in der Lage sein sie diesbezüglich entsprechend zu beraten.

Zeroconf nicht zu benutzen ist natürlich schon ein Schritt in die richtige Richtung. Das will ich auch nicht bestreiten. Halt nur das mir der Ansatz es generell abzulehnen nicht genügt und auch keine direkte Lösung für mich ist "weil irgendwer will das bestimmt benutzen.". Auch denke ich das in Zukunft mit IPV6 diese Autokonfigurationswahn eher zunimmt, was bestimmt darin Endet das eines Tages die beliebtesten Mobiltelefone und MP3-Player sich ohne so ein Feature nicht mehr bedienen lassen, was die 0815-User verärgert und (ich mir das nicht leisten kann). Und für den Fall will ich einfach gut darüber bescheid zu Wissen, und die beste Lösung finden und sicher anbieten können.

Sicherheit fällt zwar immer mit dem schwächsten Punkt, aber man kann durch eine Teilung/Verbesserung immer Puffer einbauen die den Schadensbereich irgendwie eindämmen und das sollte man immer irgendwie machen. Interne Dienste wie z.B. der Drucker-Server kann man dann halt splitten Cups lauscht  z.B. ein mal via VPN intern um Rechnungen etc zu drucken und eine andere Instanz für Besucher. Mir ist wichtig das man möglichst  sicher und offen mit dem Problem umgeht und es bequem anbietet. Also auch das man in Howtos/Dokumentationen dann darauf verweist oder kurz darauf eingeht.

Generell stimme ich mv und UTGamer zu etwas nicht zu benutzen oder die Codebasis klein zu halten ist der sicherste Ansatz überhaupt. Aber für mich war es halt gleichbedeutend etwas zu installieren (und den Dienst nicht zu aktivieren/zu nutzen) eben mit dem "es ist nicht vorhanden". Natürlich ist es ein bisschen einfacher wenn jemand meinen Rechner kompromittiert und dann den dienst Starten kann weil er nun mal installiert ist.

Aber der Tenor dieses Threads denn nun, das man KDE und Windows nicht mehr verwenden sollte weil es unsicher geworden ist? Mir wären Tipps lieber wie man das sicherer machen kann als die Einigung "Es ist sowieso alles unsicher.". Na ja gut das passt vielleicht auch nicht hier hin, aber es wäre gut sowas an geeigneterer Stelle zu vermerken. Ich werde mal das Thema mal im Auge behalten, und es bei Zeiten nochmal zusammenfassen.

Offtopic-Absatz-zu-Paranoia-An-UTGamer:

Wenn die Rechner deiner Freunde und Familien angehörigen entsprechend unsicher sind, oder Mitarbeiter anfällig für Sozial Engineering (gerne auch via StudiVZ und anderen Sozial Communitys) sind, ist dies einfach das schwächste Glied der Kette. Das betrifft auch Informationen über dich, die auf Rechnern von Unternehmen liegen, man braucht nicht unbedingt deinen Rechner zu kapern. Daher ist Sicherheit ist etwas das man Teilen muss, um es zu verbessern. Ich hab nichts gegen diese Paranoia und bin es selbst bestimmt auch, aber nicht so sehr wie du. "Paranoid sein" ist auch nicht schlecht da es neue Perspektiven/Standpunkte gibt und die Ideenmühle anwirft. Aber es wird immer genug andere Möglichkeiten geben die einfacher sind um deine Sicherheit auszuhebeln. Und grade bei einer gewissen Stufe der Paranoia (man stelle sie das wie bei einer Treppe vor), ist der Aufwand für die nächste Stufe einfach zu groß, sollte es für dich uninteressant machen "das Ding so umzusetzen" (und endet in Zeitverschwendung).  Da muss man dann andere Wege gehen.

----------

## UTgamer

Dank an alle Diskussionsteilnehmer.

Think4UrS11 hat mit diesem Punkt den besten getroffen:

Ein physikalisch getrenntes Netz ist unschlagbar solange die Wohnung unversehrt bleibt, bedeuted aber auch einen höheren Aufwand zu treiben alle wichtigen Daten immer umzuschaufeln.

 *ChrisJumper wrote:*   

> Offtopic-Absatz-zu-Paranoia-An-UTGamer:
> 
> Wenn die Rechner deiner Freunde und Familien angehörigen entsprechend unsicher sind, oder Mitarbeiter anfällig für Sozial Engineering (gerne auch via StudiVZ und anderen Sozial Communitys) sind, ist dies einfach das schwächste Glied der Kette. Das betrifft auch Informationen über dich, die auf Rechnern von Unternehmen liegen, man braucht nicht unbedingt deinen Rechner zu kapern. Daher ist Sicherheit ist etwas das man Teilen muss, um es zu verbessern. Ich hab nichts gegen diese Paranoia und bin es selbst bestimmt auch, aber nicht so sehr wie du. "Paranoid sein" ist auch nicht schlecht da es neue Perspektiven/Standpunkte gibt und die Ideenmühle anwirft. Aber es wird immer genug andere Möglichkeiten geben die einfacher sind um deine Sicherheit auszuhebeln. Und grade bei einer gewissen Stufe der Paranoia (man stelle sie das wie bei einer Treppe vor), ist der Aufwand für die nächste Stufe einfach zu groß, sollte es für dich uninteressant machen "das Ding so umzusetzen" (und endet in Zeitverschwendung).  Da muss man dann andere Wege gehen.

 

Bei Beruf und Privat bin ich seit Jahren strickt am trennen, und der Aufwand für immer mehr bedachte Sicherheit ist wirklich hoch. Es macht nämlich langsam keinen Spaß mehr solch einen Aufwand zu treiben alle Softwareabhängigkeiten zu überprüfen und einzeln nachzuschlagen wofür sie sind sie, dann zuzulassen oder abzulehnen oder dann ganz drauf zu verzichten.

Ich hab jetzt nur noch X, Fluxbox, Worker und Seamonkey (abgeändertes Ebuild overlay) als Hauptanwendungen. Dokumentationen schreibe ich sowieso seit ~10 Jahren in HTML wo man schnellen Überblick über den Sourcecode hat, teils garniert mit eigenen Javascripten, verteilt über mehrere Useraccounts. Lokale Webseiten sind bei mir Standard fast schon als Desktop, alles selbst zusammengesammelt. Je nach Useraccount Lesezeichendateien mit über 6000 Links, alle fein säuberlich sortiert. Lokale Dokumente können direkt auf Internetseiten verweisen und über Frames auch wieder zurück. Noscript im Browser schützt vor fremden Scripten. Selbst in meiner Fluxbox-slitliste sind unmegen an Html-Links zu Nah und fern.

Jeder Useraccount hat eine eigene Partiton mit Zugriffsrechten nur für ihn und ohne  Geräte-/oder Ausführenrechte. Dann 3 Gemischtpartitionen auf denen die Accounts sich austauschen dürfen. Ja nenn mich Paranoid pur.  :Wink:  Bei mir blickt niemand fremdes durch außer ich selbst eben, denn ich kenne niemanden der fast alles per HTML/Javascript erledigt, diese Neigung hatte ich 1998 schon begonnen mit javascriptverschlüsselten Daten, auch wenn man die knacken kann, es kennen sich heute aber schon garnicht mehr soviele damit aus. 

Der Thread hat wirklich viele zum Nachdenken angeregt und ich habe auch viel gelernt.

PS:

Das funktionierende RC-Script am Anfang des Threads ist von mir entwickelt, denjenigen die es sich aneignen wollen wünsche ich viel Spaß, habs als GNU deklariert, die Anleitung steht darunter. Und so ein MS-Titel, hust.   :Rolling Eyes:   :Wink: 

LPI hoffe ich kommt dieses Jahr bei mir noch, und dank Gentoo habe ich jetzt Einlicke in Prozesse bekommen die andere Systeme vor ihren Admins verschleiern.

----------

