# Verschlüsselung Netzwerk (z.B. eth0)

## ixo

Hallo,

Suchen im Internet hat mich nicht weitergebracht, da zu viele Treffer, die nichts bringen.   :Confused: 

Was ich suche, ist ein (möglichst zuverlässiges) Verfahren, mit dem ich z.B. eth0 (oder eth1 usw.) komplett verschlüsseln kann. Auf diese Art und Weise könnten dann z.B. 10 Rechner "normal" miteinander schwatzen, ohne dass mitgelesen werden kann. Die Verschlüsselung soll im Rechner erfolgen, nicht in einem Netzwerkswitch.

VPNs wären nach meiner Einschätzung (vielleicht liege ich ja falsch   :Exclamation:  ) nicht das Wahre, da dort immer nur Punkt-zu-Punkt Verbindungen aufgebaut werden, was bei mehr als ein paar Rechnern eher lästig wird.

Grüße, ixo

----------

## bell

VPN ist schon das richtige. OpenVPN kann ja TUN und TAP. Siehe auch http://wiki.openvpn.eu/index.php/Vergleich_TUN/TAP

TAP ist nur Punkt-Zu-Punkt. Wenn Du aber den OpenVPN Server als TUN (Routing) aufsetzt, und auch das Routing konfigurierst, dann können die einzelnen VPN-Clients über den Tunnel mit einander reden. Alle Clients müssen dann sich mit dem Server verbinden und nur über den VPN-Router (als Default Gateway) mit einander reden.

Der Nachteil ist natürlich dass ein zentraler Server benötigt wird. Aber anders geht es nicht wirklich, denn für die Verschlüsselung braucht man immer zwei Seiten: Verschlüsselung und Entschlüsselung. Also entweder über einen zentralen Server oder für alle Paar-Kombinationen jeweils eine P2P-Verbindung.

----------

## ixo

Also openVPN nutze ich selbst (um mich über's Internet bei mir einzuwählen) - das läuft aber schon so lang, dass ich die Details vergessen habe.   :Embarassed: 

Wenn ich Dich richtig verstehe, dann sagst Du, dass ein zentraler Rechner Router spielt!?

Das ist aber u.a. das, was ich vermeiden will. Es geht darum, Server in einem RZ im LAN über Verschlüsselung miteinander "reden" zu lassen - also z.B. für Multitier Anwendungen. Und da ist eine zentrale Kiste (aus Performance- (Bandbreite / Latenz) und Verfügbarkeitsgründen) nicht gerade ideal.

Oder habe ich da etwas falsch verstanden?

Was mir vorschwebt wäre, dass alle Rechner ihren Traffic auf bestimmten Interfaces grundsätzlich ver-, bzw. entschlüsseln und ansonsten "normal" kommunizieren. Das bedeutet, dass der Header des IP Paketes nicht verändert würde, sehr wohl aber die transportierten Inhalte.

Grüße, ixo

----------

## forrestfunk81

Mit IPsec kann man auch verschlüsselte Host zu Host Verbindungen (auf Network-Layer) aufbauen. Das benötigt aber Konfiguration auf jedem Rechner und ist deshalb je nach Größe des Rechenzentrums schwer zu warten.

----------

## bell

Wie gesagt, entweder ein zentraler Server oder eine Point2Point Verbindung jeweils zwischen allen beteiligten, was wie forrestfunk schreibt sehr schwer zu warten ist. Denn ohne einen zentralen Server muss jeder jeden kennen und für jede mögliche Verbindung eine Verschlüsselung konfiguriert sein. Ob OpenVPN oder IPSec ist egal.

----------

## ixo

Prinzipiell müsste es doch gehen (ob's das gibt wäre die Frage), dass man jedes Paket (meinetwegen symmetrisch) verschlüsselt und entschlüsselt. Dann gibt's auf jedem Rechner nur eine Konfiguration, weil die unabhängig davon ist, mit wem der Rechner über das betreffende Device kommuniziert. Eine andere Form der Kommunikation ist dann über diesen Port nicht möglich.

Das würde den Konfigurationsaufwand in engen Grenzen halten - daher die Frage bzw. die Idee dahinter.

Grüße, ixo

----------

## firefly

 *ixo wrote:*   

> Prinzipiell müsste es doch gehen (ob's das gibt wäre die Frage), dass man jedes Paket (meinetwegen symmetrisch) verschlüsselt und entschlüsselt. Dann gibt's auf jedem Rechner nur eine Konfiguration, weil die unabhängig davon ist, mit wem der Rechner über das betreffende Device kommuniziert. Eine andere Form der Kommunikation ist dann über diesen Port nicht möglich.

 

Das was du beschreibst klingt für mich eher so, dass die Applikation selbst seine Kommunikationsdaten verschlüsselt.

Aber das müsste die Applikation dann unterstützen.

----------

## ixo

 *firefly wrote:*   

> 
> 
> Das was du beschreibst klingt für mich eher so, dass die Applikation selbst seine Kommunikationsdaten verschlüsselt.
> 
> Aber das müsste die Applikation dann unterstützen.

 

Neben vielem anderen, über das ich hier nicht schreiben kann / darf, geht es darum, dass auf den Rechnern irgendetwas laufen kann, was mit Verschlüsselung des Traffics zwischen den Servern untereinander nichts zu tun hat. (Traffic vom User zur Applikation ist was anderes, das hat mit meiner Frage nichts zu tun.) Es geht "nur" darum, dass alles, was zwischen ein Gruppe von Servern über das Netzwerk verschickt wird verschlüsselt ist. Und zwar sobald die Bytes aus dem Rechner herauspurzeln.

Viele Grüße, ixo

----------

## schmidicom

Ist das hier vielleicht das was du suchst?

http://tcpcrypt.org/

Dieses Projekt scheint allerdings nicht mehr wirklich aktiv zu sein.

EDIT:

Oder wie wäre es hiermit:

http://www.netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO-4.html#ss4.10

----------

## ixo

 *schmidicom wrote:*   

> Ist das hier vielleicht das was du suchst?
> 
> http://tcpcrypt.org/
> 
> Dieses Projekt scheint allerdings nicht mehr wirklich aktiv zu sein.
> ...

 

Das letzte Mal scheint was vor einem Jahr passiert zu sein. Grundsätzlich sieht es so aus, als würde es in die Richtung gehen - werde ich mir mal näher ansehen.

So etwas:

 *Quote:*   

> Tcpcrypt is opportunistic encryption. If the other end speaks Tcpcrypt, then your traffic will be encrypted; otherwise it will be in clear text. Thus, Tcpcrypt alone provides no guarantees—it is best effort.
> 
> By default Tcpcrypt is vulnerable to active attacks—an attacker can, for example, modify a server's response to say that Tcpcrypt is not supported (when in fact it is) so that all subsequent traffic will be clear text and can thus be eavesdropped on.

 

ist natürlich schon nicht so toll - aber vielleicht kann man das abschalten.

 *schmidicom wrote:*   

> 
> 
> EDIT:
> 
> Oder wie wäre es hiermit:
> ...

 

 :Cool:  Wenn ich das richtig verstehe, handelt es sich um eine XOR "Verschlüsselung" - lieber nicht.

Ich hätte dazuschreiben müssen, dass es hierbei um "harte" Anforderungen geht. Als Basis wird auch noch TPM verwendet.

Danke für die Tipps,

ixo

----------

## schmidicom

Naja du wolltest eine Möglichkeit zur Verschlüsselung der in den Paketen transportierten Daten, davon das sie sicher sein soll haste nix gesagt.  :Laughing: 

Aber stimmt schon, habe mich gerade selbst etwas schlau gemacht im Internet über XOR und selbst nach einem schnellen durchlesen erweckte es nicht wirklich den eindruck sicher zu sein.

EDIT:

Scheinbar versuchte sich Lennart Poettering ebenfalls mal an dieser Idee:

http://0pointer.de/lennart/projects/seppl/

EDIT2:

Obwohl dieses "seppl" von LP kommt scheint es von Funktionsumfang her gar nicht so schlecht zu sein. Wenn ich das richtig verstanden habe kann dort jeder Computer seinen eigenen schlüssel haben und man kann scheinbar auch den "cipher" frei wählen.Last edited by schmidicom on Tue Jul 24, 2012 2:28 pm; edited 3 times in total

----------

## bell

Der "XOR" Ansatz im IP-Tables scheint mir am saubersten. Habt Ihr im RZ nicht ein Paar Leute die C können und ausgehend von dem XOR-Patch ein eigenes Iptables-Target-Kernel-Modul mit einer sicheren Verschlüsselung schreibt? Wenn es ein synchrone Verschlüsselung ist kann man das Target für Input und Output nutzen. Für Asynchrone Verschlüsselung werden zwei Targets benötigt.

----------

## ixo

 *bell wrote:*   

> Der "XOR" Ansatz im IP-Tables scheint mir am saubersten. Habt Ihr im RZ nicht ein Paar Leute die C können und ausgehend von dem XOR-Patch ein eigenes Iptables-Target-Kernel-Modul mit einer sicheren Verschlüsselung schreibt? Wenn es ein synchrone Verschlüsselung ist kann man das Target für Input und Output nutzen. Für Asynchrone Verschlüsselung werden zwei Targets benötigt.

 

Klare Antwort: Nein.

Es geht schon deshalb nicht, weil man mit "selbstgebastelten" Lösungen in dem Umfeld keinen Blumentop gewinnen kann. Deshalb fragte ich ganz zu Anfang ja auch nach "zuverlässigen" (bewährten, weit eingesetzten) Lösungen. Die scheint es wohl tatsächlich nicht zu geben.

Grüße, Heinz-Josef

----------

## bell

Auch Eigenentwicklung kann professionell sein. Wenn Ihr die Patches an netfilter.org sendet, dann durchlaufen die automatisch eine Qualitätssicherung (Viele Entwickler schauen drüber und machen auch Korrekturen). Dann sind sie ein Teil einer der weit verbreiteten IP-Tables / Netfilter Lösung, die in der Linux-Welt eigentlich DIE Standard-Firewall Lösung ist.

An sonsten, wer suchet der findet:

http://0pointer.de/lennart/projects/seppl/

Die Idee ist also nicht neu  :Wink: 

----------

## ixo

Klar kann Eigenentwicklung professionell sein - hier muss es nur schnell verfügbar sein, die Entwickler gibt es nicht (schon gar nicht mir Linux/Kernel/iptables Erfahrung). Bei einer Eigenentwicklung wäre wohl eine Zertifizierung fällig.   :Crying or Very sad: 

 Etwas, was zum Linux-Standard Kernel gehört, ist natürlich per se schon mal akzeptiert. (Ich habe da in meinem Konzept auch diverses, was ich nutze.)

Wie schon geschrieben, ich kann leider keine Details rauslassen oder worum es eigentlich geht. Das hier ist nur ein kleines Detail, was sowieso lösbar ist - die Frage ist, wie (un)elegant.

Die von Dir dargestellte Lösung ist wirklich schick, aber leider auch wohl nicht mehr weitergepflegt. Das ist wirklich schade - die hat was!

Nochmals Danke für die Mühe oder etwas allgemeiner gesagt "Wir entschuldigen uns für die Strapazen".   :Wink: 

ixo

----------

## bell

Ich muss zugeben zuerst war ich irritiert dass es solch eine Lösung nicht gibt btw nichts aktiv gepflegt wird. Aber wenn ich mehr drüber nachdenke wundert es mich nicht. Denn egal wie gut die Lösung wäre, wäre sie immer noch ein Hack/Bastelei um ein konzeptionelles Problem in dem Netzwerk-Aufbau zu vertuschen.

Bedenke dass die Verschlüsselung ein Overhead ist und wie jede Software-Lösung auch anfällig für Angriffe. Du hättest also zwei Probleme:

1. Die Verschlüsselung kostet Zeit. Selbst wenn der Rechner diese on-the-fly machen kann so gibt es ein Zeitverzug der die Ping-Zeiten runterzieht. Wenn ich Dich richtig verstanden habe so geht es um Zeitkritische Anwendungen.

2. Wenn Du alle mit dem selben Schlüssel verschlüsselst und dieser mal irgend wie in die falschen Hände kommt, so kann ein "Maulwurf" die ganze Zeit mitlauschen und alles verstehen.

Wie wäre es konzeptionell richtig? Die Server müssen für die vertrauliche Kommunikation ein eigenes Netzwerk-Segment haben in dem sie frei und unverschlüsselt mit einander kommunizieren können. Das Schulbuch-Konzept dazu ist DMZ. Dies gilt als richtig "Professionell". Davon kann man jedoch je nach Anforderung/Bedarf abweichen, was jedoch die Sicherheit reduziert. Die niedrigste Stufe wäre: Du steckst in jeden der betroffenen Server eine zweite Netzwerkkarte und dadran bildest Du mit roten Kabeln ein neues Secure-Netzwerksegment. Dann können die Server wie gehabt im alten Netz hängen, unter einander jedoch über die rote abhörsichere Leitung reden.Last edited by bell on Wed Jul 25, 2012 6:57 am; edited 1 time in total

----------

## py-ro

wpa_supplicant könnte das richtige für dich sein.

Py

----------

## ixo

Hallo bell.

 *bell wrote:*   

> Ich muss zugeben zuerst war ich irritiert dass es solch eine Lösung nicht gibt btw nichts aktiv gepflegt wird. Aber wenn ich mehr drüber nachdenke wundert es mich nicht. Denn egal wie gut die Lösung wäre, wäre sie immer noch ein Hack/Bastelei um ein konzeptionelles Problem in dem Netzwerk-Aufbau zu vertuschen.
> 
> Bedenke dass die Verschlüsselung ein Overhead ist und wie jede Software-Lösung auch anfällig für Angriffe. Du hättest also zwei Probleme:
> 
> 1. Die Verschlüsselung kostet Zeit. Selbst wenn der Rechner diese on-the-fly machen kann so gibt es ein Zeitverzug der die Ping-Zeiten runterzieht. Wenn ich Dich richtig verstanden habe so geht es um Zeitkritische Anwendungen.
> ...

 

Wenn ich im Netzwerk verschlüssele, hat das gegenüber einer nicht-verschlüsselten Lösung natürlich Nachteile. Wo ich verschlüssele (im Rechner oder in speziellen Netzwerkkomponenten) ist dabei erst mal grundsätzlich egal.

Es geht nicht um irgendeine Anwendung, sondern (hier) um die technische Ausgestaltung eines Konzeptes, das u.a. Netzwerkverschlüsselung vorsieht - und zwar bezieht sich dieser Thread auf alles, was da aus einem Rack an IP Netzwerk herauskommt. Dabei versuche ich natürlich eine Lösung zu finden, die möglichst wenig Einschränkungen bedeutet (operativ und technisch).

 *bell wrote:*   

> 
> 
> 2. Wenn Du alle mit dem selben Schlüssel verschlüsselst und dieser mal irgend wie in die falschen Hände kommt, so kann ein "Maulwurf" die ganze Zeit mitlauschen und alles verstehen.
> 
> 

 

Die Verschlüsselung läuft hier normalerweise über TPM und Trustcenter. Inwieweit das für die hier vorgeschlagenen Tools kombinierbar ist, kann ich nicht sagen. Das wäre zu untersuchen, sofern sie überhaupt (aus anderen Gründen, s.o.) in Frage kommen. (TPM kann bei einigen VPNs verwendet werden.)

 *bell wrote:*   

> 
> 
> Wie wäre es konzeptionell richtig? Die Server müssen für die vertrauliche Kommunikation ein eigenes Netzwerk-Segment haben in dem sie frei und unverschlüsselt mit einander kommunizieren können. Das Schulbuch-Konzept dazu ist DMZ. Dies gilt als richtig "Professionell". Davon kann man jedoch je nach Anforderung/Bedarf abweichen, was jedoch die Sicherheit reduziert. Die niedrigste Stufe wäre: Du steckst in jeden der betroffenen Server eine zweite Netzwerkkarte und dadran bildest Du mit roten Kabeln ein neues Secure-Netzwerksegment. Dann können die Server wie gehabt im alten Netz hängen, unter einander jedoch über die rote abhörsichere Leitung reden.

 

Wie schon geschrieben, ich kann hier (leider) über das Konzept nichts schreiben. Versuch erst gar nicht, es zu ergründen - ich kann mich dazu nicht äußern (egal ob Du richtig oder falsch liegst) und Du wirst zu 99% falsch liegen, da Du die Gründe nicht kennen kannst.

Viele Grüße, ixo

----------

## ixo

 *py-ro wrote:*   

> wpa_supplicant könnte das richtige für dich sein.
> 
> Py

 

Hallo py-ro,

interessante Idee. Ich wusste gar nicht, dass man das außerhalb von WLAN verwenden kann. Kennst Du da irgendwelche Ansätze wie das gehen soll? (Da ich auf meinen Arbeitsplatzrechner(n) kein Gentoo mehr verwende, und WLAN inzwischen bei den Distris einfach so funktioniert bin ich da alles andere als fit   :Embarassed:  ).

Aber wichtiger: Gab's nicht mal Meldungen, dass man wpa relativ leicht knacken kann, wenn man genügend Pakete mitschneidet - oder verwechsle ich das jetzt mit WEP?

Das wird ja ein richtig interessanter Thread - hoffentlich nicht nur für mich   :Cool: 

Grüße, ixo

----------

## py-ro

Nein, hab es selber bisher nicht benutzt, von daher kann ich da leider keine Hilfe sein.

WPA2 ist nur leicht zu knacken, wenn das Passwort zu kurz ist, dann kann man es per Bruteforce knacken.

Py

----------

## toralf

 *ixo wrote:*   

> Wie schon geschrieben, ich kann hier (leider) über das Konzept nichts schreiben. Versuch erst gar nicht, es zu ergründen

 Eigentlich hat er dies auch nicht getan/vor(?), sondern Dir mit Punkt 2. ein starkes Argument geliefert, "es" (was auch immer das ist und "es" ist ja so geheimnisvoll, daß Du nicht darüber schreiben darfst/willst/kannst) _nicht_ so zu machen, oder ?

----------

## bell

 *Quote:*   

> sondern Dir mit Punkt 2. ein starkes Argument geliefert, "es" ... _nicht_ so zu machen, oder ?

 Genauso ist es. Statt Verschlüsselung lieber eine physische Trennung.  :Exclamation: 

Aber wie dem auch sei... interessant, wpa_supplicant hat einen "wired Ethernet" Treiber.   :Shocked: 

Für mich bleibt die Frage offen ob die Kommunikation damit dann direkt zwischen den Clients passiert oder über einen "Access Point", wie bei WLAN üblich. Das könntest Du mal testen und dann hier berichten. 

Irgend wie findet man nichts im Netz dazu ausser dass Studenten es einrichten müssen um in das Uni-Netz zu kommen   :Sad: 

----------

## USB-Heini

Der Thread ist zwar schon älter und ich hole sowas nur ungern wieder hoch, sorry.

Eine Lösung für Dein Problem könnte Opportunistic Encryption ("OE") sein. Das ist eine transparente Verschlüsselung auf IP-Ebene und kommt ursprünglich aus dem Free S/WAN-Projekt, das mittlerweile unter libreswan/openswan/strongswan weitergeführt wird.

Bei OE werden Schlüssel im DNS hinterlegt (und optional über DNSsec signiert). Bei jedem TCP/IP-Verbindungsaufbau auf einen Server wird im DNS nachgeschaut, ob ein Schlüssel verfügbar ist und die Verbindung verschlüsselt werden kann. Falls nicht, gibt es den Fallback auf "herkömmliches" IP ohne Verschlüsselung.

Ich hab mal an einem Firewall-Projekt gearbeitet, das diese OE angeboten hat. Falls Du also (kommerziellen) Support für sowas brauchst: kein Problem.   :Razz: 

Grüße,

USB-Heini

----------

