Mit FreeBSD sicher gegen "Online-Dursuchungen"?

Was einmal ein Gedanke wäre, ich hoffe, daß sich nicht jemand auf den Schlips getreten fühlt (wenn ja, umso besser): Wir haben ein Wiki, also wäre es möglich, in einfachen Schritten zum Mitmeißeln zu erklären: Wie richtet man ein *BSD ein, daß eingermaßen sicher ist? Erklärt bitte dem Noob, z.B. mir, wie man so etwas bewerkstelligt. Und zwar idiotensicher.
Warum? Aus einem einfachen Grunde. Ich habe nicht alle Zeit der Welt, mich in alle Feinheiten der Sicherheit einzuarbeiten. Für mich ist FreeBSD in erster Linie ein Arbeitssystem, mit dem ich meine alltäglichen Probleme bewältigen will. Da ich mich für FreeBSD entschieden habe und damit weiß, daß ich die Minderheit gewählt und kein kein Windows oder MacOS oder ähnlich Verbreitetes benutze, akzeptiere ich auch, daß es heißt, immer selbst dazuzulernen, sich mit den Handbüchern, den manpages etc. auseinanderzusetzen, und das mache ich auch.
Aber bitte, seid nicht zu exklusiv, wer Erfahrungen mit Sicherheitskonzepten gesammelt hat und sie auch erfolgreich anwendet, warum stellt er/sie nicht ins Wiki und läßt sie verifizieren/verbessern?
Ich kenne mich mit den Problemen aus, die asiatische Sprachen so mit sich bringen, da ich es selbst ausprobiert habe und oft genug gescheitert bin. Ich stelle meine Erfahrungen, gut oder schlecht formuliert, ins Wiki, so ganz langsam. Jemand kommt vorbei, der noch mehr versteht von dem Kram und verbessert das: Feine Sache, kann ich wieder dazulernen und im Nachhinein wieder den Artikel aufwerten.

Hier wird ganz furchtbar diskutiert: was, wie , wenn, wenn aber usw. Ich vermisse einen einfachen Artikel, worauf man achten muß, um ein einigermaßen sicheres *BSD zu fahren. Sicherheitsexperten voran: wie geht das? Was kann man außer pf und tor/privoxy noch für die eigene Sicherheit tun, ohne Paranoia und trotzdem auf der sicheren Bank? Ich würde gern so etwas schreiben, wenn ich Ahnung davon hätte.
 
Ein frisch installiertes System ist Sicher. Danach hängt alles davon ab, was du aktivierst, bzw. nachinstallierst und wie du es konfigurierst. Du brauchst also keinen Artikel für ein BSD, sonder zum Beispiel eine Artikel für den sshd, einen für Apache einen für VPN, NFS, Samba usw.

Die Grundregel ist so restriktiv wie möglich zu sein und unverschlüsselte Dienste (ftp, Samba, NFS) nur über VPN anzubieten. Http ist normalerweise auch einer, aber da will man ja normalerweise, dass jeder an die Daten kommt. Nur wenn man sich einloggen muss, wäre es vielleicht sinnvoll das über https abzuwickeln.
 
Was einmal ein Gedanke wäre, ich hoffe, daß sich nicht jemand auf den Schlips getreten fühlt (wenn ja, umso besser): Wir haben ein Wiki, also wäre es möglich, in einfachen Schritten zum Mitmeißeln zu erklären: Wie richtet man ein *BSD ein, daß eingermaßen sicher ist? Erklärt bitte dem Noob, z.B. mir, wie man so etwas bewerkstelligt. Und zwar idiotensicher.
Warum? Aus einem einfachen Grunde. Ich habe nicht alle Zeit der Welt, mich in alle Feinheiten der Sicherheit einzuarbeiten. Für mich ist FreeBSD in erster Linie ein Arbeitssystem, mit dem ich meine alltäglichen Probleme bewältigen will. Da ich mich für FreeBSD entschieden habe und damit weiß, daß ich die Minderheit gewählt und kein kein Windows oder MacOS oder ähnlich Verbreitetes benutze, akzeptiere ich auch, daß es heißt, immer selbst dazuzulernen, sich mit den Handbüchern, den manpages etc. auseinanderzusetzen, und das mache ich auch.
Aber bitte, seid nicht zu exklusiv, wer Erfahrungen mit Sicherheitskonzepten gesammelt hat und sie auch erfolgreich anwendet, warum stellt er/sie nicht ins Wiki und läßt sie verifizieren/verbessern?
Ich kenne mich mit den Problemen aus, die asiatische Sprachen so mit sich bringen, da ich es selbst ausprobiert habe und oft genug gescheitert bin. Ich stelle meine Erfahrungen, gut oder schlecht formuliert, ins Wiki, so ganz langsam. Jemand kommt vorbei, der noch mehr versteht von dem Kram und verbessert das: Feine Sache, kann ich wieder dazulernen und im Nachhinein wieder den Artikel aufwerten.

Hier wird ganz furchtbar diskutiert: was, wie , wenn, wenn aber usw. Ich vermisse einen einfachen Artikel, worauf man achten muß, um ein einigermaßen sicheres *BSD zu fahren. Sicherheitsexperten voran: wie geht das? Was kann man außer pf und tor/privoxy noch für die eigene Sicherheit tun, ohne Paranoia und trotzdem auf der sicheren Bank? Ich würde gern so etwas schreiben, wenn ich Ahnung davon hätte.

Hallo i18n,

sehr guter Vorschlag von dem alle provitieren werden....
Bei Fragen der Sicherheit gilt es allerdings auch zu beachten das vieles auch systemübergreifend stattfindet "Beispiel Internet"...

Generell bist Du neigentlich schon in einer besseren Position wenn Du ein OS einsetzt das nicht gerade den "Mainstream" widerspiegelt...

Aber selbst bei solch einem OS lässt sich doch so manches bewerkstelligen um etwas sicherer zu sein !

Ich für meinen Teil versuche mich in Projekten zu engagieren die sich explizit mit Sicherheitsfragen auseinandersetzen die auch plattformübergreifend sind und ich lerne viel daraus...

LG rudy
 
-remote-exploits ist eine linuxdistri für Sicherheit
-home kann man für andere user unsichtbar machen
-alle arbeiten an virtuellen Maschinen, MS, die Linuxfraktion etc..man kann dann eben auf knopfdruck den orginalen Zustand herstellen...ich weiß nicht was die Zukunft bringt und der Weg der IT hinführt, ich denke nichts wird hundertprozentig sicher sein schließlich arbeiten z.B die NSA und auch Experten für Verschlüsselung zusammen und werden immer einen Weg finden sich einzunisten oder abzuhören. Das wird vielleicht in den nächsten Jahren der zweite Arbeitsgang am PC nach Virenbekämpfung und Updates.

Jedenfalls bringt BSD genug Tools mit um veränderungen am System aufzuspüren oder Unregelmässigkeiten festzustellen
Wie ich kürzlich irgendwo gelesen habe, wird daran gearbeitet/geforscht , ein OS im laufenden Betrieb in eine VM zu verschieben, ohne das der Nutzer es merkt. Wenn das klappen sollte, und ich fürchte das wird es früher o. später, dann 'Gute Nacht!'.

Gruß c.
 
Wie ich kürzlich irgendwo gelesen habe, wird daran gearbeitet/geforscht , ein OS im laufenden Betrieb in eine VM zu verschieben, ohne das der Nutzer es merkt. Wenn das klappen sollte, und ich fürchte das wird es früher o. später, dann 'Gute Nacht!'.

Gruß c.

Ich dachte das geht schon längst. Wird dieses Verfahren nicht genutzt um "echte" Server in virtuelle Maschinen umzuwandeln um dann mehrere "echte" Server durch einen einzigen ESX-Server zu ersetzen?

Viele Grüße
 
Dafür braucht ein Prozess erstmal Kernel Rechte, und die bekommt er normalerweise nicht einfach geschenkt. Will heißen, der Vorgang kann nur über einen Fehler oder gewollt angestoßen werden.
 
Hier wird ganz furchtbar diskutiert: was, wie , wenn, wenn aber usw. Ich vermisse einen einfachen Artikel, worauf man achten muß, um ein einigermaßen sicheres *BSD zu fahren. Sicherheitsexperten voran: wie geht das? Was kann man außer pf und tor/privoxy noch für die eigene Sicherheit tun, ohne Paranoia und trotzdem auf der sicheren Bank? Ich würde gern so etwas schreiben, wenn ich Ahnung davon hätte.

Server absichern
Bezieht sich zwar auf die Serverseite aber ist doch schonmal besser als nix, oder?

Viele Grüße
 
Also prinzipiell kann wohl irgendwer immer irgendwo rein. Kommt auf das Know how an. Aber generell fährt man in dieser Krise mit *BSD wohl ganz gut, da es a) relativ wenig verbreitet ist b) wir unser Portssystem mit Checksummen haben und c) unsere Bundesregierung sowieso keine Ahnung hat. :)
In Relation zu Windows gesehen fährt man mit BSD am sichersten, noch vor Linux.
macht es den Spitzelheinis so schwer wie möglich, dann haben se irgendwann auch kein Bock mehr drauf :)
 
Die Checksummen werden auch nur heruntergeladen und können von jemandem der in der Leitung hängt problemlos ausgetauscht werden.
 
Also prinzipiell kann wohl irgendwer immer irgendwo rein. Kommt auf das Know how an. Aber generell fährt man in dieser Krise mit *BSD wohl ganz gut, da es a) relativ wenig verbreitet ist b) wir unser Portssystem mit Checksummen haben und c) unsere Bundesregierung sowieso keine Ahnung hat. :)
In Relation zu Windows gesehen fährt man mit BSD am sichersten, noch vor Linux.
macht es den Spitzelheinis so schwer wie möglich, dann haben se irgendwann auch kein Bock mehr drauf :)

Hallo marzl,

also zu den Punkt a.) kann ich dir uneingeschränkt zustimmen
zu den Punkt b.) nur eingeschränkt stimme da eher Kamikaze zu
zu den Punkt c.) begehst Du einen Fehler und zwar......

unterschätze niemals Deine Gegner und nach allem was die vorhaben ( Fingerabdruck - Beschneidung meiner demokratischen Rechte) definiere ich Die jetzt klar nicht als meine Freunde !

Einen kleinen Vorgeschmack wie gut die drauf sind habe auch schon den Link dazu hier gepostet XPIDER.

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

rate dazu sich einmal die technische Dokumentation durchzulesen, die findet Ihr hier als PDF Download:

http://www.informatik.uni-jena.de/dbis/veranstaltungen/datenbanktage-2003/DBTage2003-Nowitzky.pdf

gruss rudy
 
XPIDER sammelt information die eh öffentlich zur Verfügung stehen. Is also kein Trojaner. Mein Rechner aber steht nicht öffentlich zur Verfügung.

Klar können die Checksummen ausgetaucht werden. In Anbetracht der weit verzweigten downloadsourcen und der dazugehörigen Checksummen, halte ich es zwar nicht für technisch ausgeschlossen, aber praktisch nicht umsetzbar.

Dazu müsste a) meine Downloadurl umgeschrieben, b) die Datei verändert und c) die LOKAL vorliegende Checksummer modifiziert werden.

NEVER EVER! Die Ports sind ein recht gutes System gegen diesen ganzen Mist.
Es sei denn, es findet eine Zentrale Infiltration des "Ports-Servers" statt. Das würde aber Global (nicht nur DE) recht schnell auffallen :)
 
ja, es geht auch für BSD oder jedes andere System, der Trojaner kommt nur zum Einsatz wenn es einen richterlichen Beschluss gibt und nicht wahllos per Update Funktion. der Trojaner muss für jeden Einsatz neu geschrieben werden, es gibt keinen universellen Trojaner!
 
Dazu müsste a) meine Downloadurl umgeschrieben, b) die Datei verändert und c) die LOKAL vorliegende Checksummer modifiziert werden.

NEVER EVER! Die Ports sind ein recht gutes System gegen diesen ganzen Mist.
Es sei denn, es findet eine Zentrale Infiltration des "Ports-Servers" statt. Das würde aber Global (nicht nur DE) recht schnell auffallen :)

Das ist nicht notwendig, wenn der Code mittels man-in-the-middle-attacke eingespeist wird. Und es deutet vieles momentan darauf hin, daß dies die geplante Vorgehensweise ist.
 
der Trojaner muss für jeden Einsatz neu geschrieben werden, es gibt keinen universellen Trojaner!
Na dann viel spaß für mein OpenBSD System individuellen Trojaner zu schreiben. Das die Leute da das nötige Knowhow haben einen schönen Trojaner zu schreiben. Glaube ich gerne.

Aber mit Vorzustellen: „Eine ganzes Entwickler Team arbeiten Wochen/Monate (jahre :D ) an einem Trojaner um mein System zu infiltrieren“ Have Fun !

Wenn doch würde ich mich sehr freuen diesen dann im Einsatz zusehen.

EDIT:

Damit will ich nicht sagen das ich hier ein extrem abgesichertes Netzwerk stehen habe. Aber Leute Windows/Linux kann keiner mit (Open)BSD vergleichen.
 
Zuletzt bearbeitet:
Und wo kommt die her? Aha.
Die kommt von einem Zentralen Portserver, das ist richtig, ja. Da per porstnap aber auch wiederum gepackte Archive gezogen werden (die auch via Checksumme geprüft werden) sehe ich keine praktische Angriffsfläche. Nur eine theoretische.
 
Theoretisch möglich ja, aber ich bezweifle schlicht die praktische Durchführbarkeit. Dem müsste eine globale Infiltration aller Portsserver durch unsere Stasi vorangehen.
 
Lies noch mal was Kamikaze geschrieben hat:
Die Checksummen werden auch nur heruntergeladen und können von jemandem der in der Leitung hängt problemlos ausgetauscht werden.

Die Manipulation erfolgt nicht auf den Portsservern selbst, sondern auf dem Weg zwischen Deinem Rechner und dem Portsserver, sprich: Bei Deinem Provider. Wenn dort staatliche Schnittstellen geschaffen werden (die es im übrigen teilweise für andere Zwecke schon gibt, siehe TKÜV), dann wird es schwierig sich dagegen schützen.
 
Lies noch mal was Kamikaze geschrieben hat:


Die Manipulation erfolgt nicht auf den Portsservern selbst, sondern auf dem Weg zwischen Deinem Rechner und dem Portsserver, sprich: Bei Deinem Provider. Wenn dort staatliche Schnittstellen geschaffen werden (die es im übrigen teilweise für andere Zwecke schon gibt, siehe TKÜV), dann wird es schwierig sich dagegen schützen.
--------------
Die TKÜV noch eingefügt zur Begriffserklärung Bitte um Nachsicht zzz Link: http://bundesrecht.juris.de/tk_v_2005/index.html

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

genauso sieht das aus FullACK ! sehe das haargenauso wie Du zzz,


so aber noch etwas Lesestoff zu UNIX im Speziellen:

Auszug aus Betriebssystem UNIX-Einführung Abschnitt X und Sicherheit:

Ein anderes Problem liegt am Konzept des TCP/IP-Protokolls. noch Eingefügt Link zu TCP-Protokoll: http://de.wikipedia.org/wiki/Transmission_Control_Protocol

Da nicht alle Rechnertypen, die am Internet hängen, das Konzept einer Benutzer-ID haben, ist diese auch bei TCP/IP nicht vorgesehen. Auf den X-Server kann also nicht nur der augenblickliche Benutzer der Konsole zugreifen, sondern alle Benutzer des Rechners. Und das in beliebiger Form. Ein anderer Benutzer kann zum Beispiel den gesamten Bildschirminhalt überschreiben.

------------------
Der Link:

http://www.netzmafia.de/skripten/unix/unix1.html

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

Dann noch ein weiterer Link zur Datensicherheit und Datenschutz als PDF Download:

http://www.staff.uni-mainz.de/pommeren/Artikel/ds.pdf

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

gruss rudy
 
Zuletzt bearbeitet:
Sehr wichtig bitte lesen

Hallo Forum,

nachfolgend stelle ich hier die Antwortmail des Datenschutzzentrums Niedersachsen

https://www.datenschutzzentrum.de/presse/20070402-online-durchsuchung.htm

auf meine diesbezüglichen Fragen zur technischen Umsetzung als Diskussionsbeitrag in das Forum zur öffentlichen Diskussion....

Natürlich habe ich mir die Erlaubniss geben lassen dieses auch hier im Forum zu veröffentlichen..

Aus dieser Mail könnt Ihr entnehmen wie die technische Umsetzung funktionieren soll, wie schwierig es auch dann ist sich davor zu schützen, und das die Wahl des Betriebssystems eigentlich leider keine Rolle dabei spielt...

Es tut mir leid euch vielleicht den Tag zu vermiesen, aber was soll mann/frau es schön reden wenn es nichts zum schön reden mehr gibt!

Unsere Befürchtungen sind eingetreten leider

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

Die Antwortmail

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


Delivered-To: rudolf.fehren@gmail.com
Received: by 10.114.203.5 with SMTP id a5cs140335wag;
Wed, 4 Apr 2007 06:26:20 -0700 (PDT)
Received: by 10.67.116.3 with SMTP id t3mr1432461ugm.1175693180096;
Wed, 04 Apr 2007 06:26:20 -0700 (PDT)
Return-Path: <ld10@datenschutzzentrum.de>
Received: from mail2.privacyservice.org (mail2.privacyservice.org [213.178.78.86])
by mx.google.com with ESMTP id z33si1235559ikz.2007.04.04.06.26.19;
Wed, 04 Apr 2007 06:26:20 -0700 (PDT)
Received-SPF: neutral (google.com: 213.178.78.86 is neither permitted nor denied by best guess record for domain of ld10@datenschutzzentrum.de)
Received: from mail1.privacyservice.org (unknown [192.168.200.140])
by mail2.privacyservice.org (Postfix) with SMTP id 34D1ED3D11
for <rudolf.fehren@googlemail.com>; Wed, 4 Apr 2007 15:24:17 +0200 (CEST)
Received: (qmail 13349 invoked from network); 4 Apr 2007 13:20:25 -0000
Received: from unknown (HELO Postman.ULD.local) (192.168.200.148)
by mail1.privacyservice.org with SMTP; 4 Apr 2007 13:20:25 -0000
Received: from [192.168.30.115] ([192.168.30.115])
(authenticated user marit.hansen@postman.uld.local)
by Postman.ULD.local (Kerio MailServer 6.1.4)
(using TLSv1/SSLv3 with cipher AES256-SHA (256 bits));
Wed, 4 Apr 2007 15:28:17 +0200
Message-ID: <4613A7E7.501@datenschutzzentrum.de>
Date: Wed, 04 Apr 2007 15:28:07 +0200
From: Marit Hansen <ld10@datenschutzzentrum.de>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Rudolf Fehren <rudolf.fehren@googlemail.com>
CC: mail@datenschutzzentrum.de
Subject: Re: =?ISO-8859-1?Q?H=E4nde_weg_von_heimlichen_Online-Dur?=
=?ISO-8859-1?Q?chsuchungen_vom_02=2E_April_2007?=
References: <5054c62b0704031313s29ae94dcp4842f275b6dbad4d@mail.gmail.com>
In-Reply-To: <5054c62b0704031313s29ae94dcp4842f275b6dbad4d@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Sehr geehrter Herr Fehren,

vielen Dank für Ihre E-Mail!

> mit Interesse habe ich das Statement, zu den heimlichen
> Online-Durchsuchungen gelesen, und teile Ihre Sicht der Dinge.
> Als besorgter Bürger der um seine demokratischen Rechte bangt und
> gleichzeitig technisch interesierter Nutzer und von Beruf
> ############# frage ich mich ernsthaft wie das technisch
> umgesetzt werden soll !

Die Funktionsweise der heimlichen Online-Durchsuchung ist zurzeit nicht
offengelegt. Wir haben aber Hinweise ausgewertet, wonach sich die Ideen
zur Realisierung erschließen lassen (siehe beispielsweise die
Berichterstattung unter http://blog.koehntopp.de).

> Nutzt mir die Verwendung eines Unix vorwiegend FreeBSD oder Open BSD
> um mich gegen solch ein Vorgehen zu schützen, oder ist es in der
> Endkonsequenz eigentlich völlig egal welches OS ich einsetze um mich
> zu schützen..

Die Wahl des OS soll nach der Planung unerheblich sein.

> Wie kann ich mir das vorstellen, werden die HeaderDateien beim
> Handshake ausgetauscht/manipuliert und oder verändert, dann gebe es
> doch faktisch keine Möglichkeit mich zu schützen und es wäre wirklich
> egal welches OS ich einsetze da ich schutzlos in der Endkonsequenz
> bin!
>
> Würde das über die Internetknoten gehen, selbst mein Provider könnte
> mich dann nicht mehr schützen !

Der Staat (mit der Funktionalität des Einbaus einer Hintertür zur
Online-Durchsuchung) würde als Man-in-the-Middle fungieren.
Bei einem Download einer beliebigen Datei könnte zusätzlich eine
manipulierte Fassung untergeschoben werden.
Solange man nur auf der Basis von im Web veröffentlichten Informationen
die Prüfsumme oder Signatur einer solchen Datei prüfen wollte, könnten
auch die entsprechenden Informationen über Prüfsumme bzw. öffentlichen
Schlüssel manipuliert sein.
Ein Schutz wäre möglich, wenn man Prüfinformationen über gesonderte
Kanäle austauschen würde, die nicht der Manipulation im Zuge der
Online-Durchsuchung unterliegen.

Ein nachträgliches Übernehmen einer SSL-Kommunikation durch einen
(staatlichen oder nicht-staatlichen) Angreifer wäre aber vermutlich
schwierig. (Ein Etablieren von zwei SSL-Kommunikationen beidseitig des
Man-in-the-Middles aber wohl wiederum nicht.)

> Oder würde das über Exploits gehen, oder Shellcodes oder Payloads die
> müssten aber speziell für das jeweilige OS angepasst werden..

Nach den uns vorliegenden Informationen würde man sich nicht auf
Exploits verlassen.
Der implantierte Code wäre betriebssystemspezifisch vorzusehen.

> In diesem Kontext hätte ich ein sehr grosses Anliegen, könnten sie mir
> vielleicht Informationen zu technischen Fachlitereaturen -
> Dokumentationen - Büchern zugänglich machen die es mir ermöglichen,
> mein Wissenstand zu verbessern und gegebenfalls da ich der
> Programmiersprache Java mächtig bin, Software zu programmieren um
> meine Verfassungsmässigen Rechte zu schützen..

Leider gibt es nicht _den_ Pointer auf Literatur zur
Online-Durchsuchung. Oben habe ich aber ja einen Link genannt, von dem
aus weitere Informationen verlinkt sind.

> Gerne bin ich bereit diese dann als OpenSource Lösung unter die GPL zu
> stellen und sie meinen Mitbürgern zur Verfügung zu stellen..

Da die Infrastruktur des Internets betroffen sein kann, ist es recht
schwierig, sich clientseitig abzusichern.
Man denke nur an die regelmäßigen Online-Updates der Virenscanner, bei
denen man zusätzliche Checks der Integrität (z.B. durch Anrufe oder
Papierveröffentlichungen oder individuell verschlüsselt durch eine
nicht-manipulierte Stelle) machen müsste. Bestimmt kann man sich mit
Hilfe von Verschlüsselung besser schützen als bisher, aber es wird nicht
trivial sein.

Herzliche Grüße

Marit Hansen
--
Marit Hansen, ULD SH, Kiel, Germany, LD10@datenschutzzentrum.de
Tel +49 431/988-1214, Fax -1223, http://www.datenschutzzentrum.de
Unabhaengiges Landeszentrum fuer Datenschutz Schleswig-Holstein
Independent Centre for Privacy Protection Schleswig-Holstein


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

diesmal ohne Gruss der rudy
 
Zuletzt bearbeitet:
Vielen Dank für die Antwort, sehr interessant!
In Theorie ist das auch absolut nachzuvollziehen, der Aufwand bei einem 0815 Windows verhältnismässig klein (windowsupdate, antivirensignaturen, andere updates), aber alles was so verteilt im Internet rumlegt wie OSS Softeware, is doch wesentlich schwerer, oder irre ich mich da?

Also dann müsste wirklich jemand genau Bescheid wissen, was ich mir da JETZT runterlade und welche Checksumme JETZT zu verändern wäre (und dann muss fer untergejubelte KOMPILIERTE Code auch noch laufen!).
Praktisch gesehen wäre das dazu ne absolute Punktlandung, bei Ports sogar noch ne Veränderung der SOURCEN nötig (Opensource Trojaner:)? ).
Dann könnense aber auch direkt vorbeikommen und mir über die Schulter gucken :D

Als Fazit müsste ich also sagen: Alles was man selber kompileirt kann auch nicht gefährlich sein/werden. Finger weg von Binaries, dann kann nix passieren?

Bitte nicht falsch verstehen, ich möchte die ganze Geschichte in keinster Weise bagatellisieren, mir geht das ebenfalls aufn Sack, aber ganz so einfach wie es die Theorie darstellt, ist es einfach nicht.
 
Zuletzt bearbeitet:
Zurück
Oben