tun/tap als Lösung, Arbeitsweise

[HMarkus]

Hallo,

ich möchte auf meinem Rechner sämtliche Netzwerkpakete mittels einer eigenen Software prüfen und ggf. verwerfen (ein- und ausgehende Pakete). Prüfen bedeutet
1. Zeiladresse (IP, ggf. auch MAC) und Zielport kontrollieren
2. Quelladresse (IP / MAC) und Quellport kontrollieren

Ist alles OK, dann soll das Paket bei gesendeten Paket ans Netzwerk weitergeleitet werden ansonsten weggeworfen werden.
Ist bei ankommenden Paketen alles klar, so soll es anschließend an die adressierte Anwendung weitergeleitet werden.

Meine Frage ist nun, wie ich das realisieren kann. Damit meine ich nicht die konkrete Umsetzung des Programms, welches dies Überprüfung vornimmt, sondern die Eingliederung in das Linuxsystem, so dass die Anwendungsprogramme davon nichts merken (transparente Lösung).

Schon fertige Tools oder ähnliches welche diese Aufgabe erledigen, möchte ich nicht verwenden, da der Überprüfungsvorgang später vielleicht noch komplexer wird.

Bis jetzt habe ich nur herausgefunden, dass dies wohl mit tun/tap möglich sei, bin mir da aber selbst nicht sicher. Ist dem so? Gibt es Alternativen? Wie müsste ich tun/tap ggf. verwenden und meine Anwendung in diesen Mechanismus eingliedern?

Gruß
Markus

 

[spoensche]

Du willst also quasi eine Firewall bzw. Paketfilter schreiben. Für welchen Anendungsbereich brauchst du das bzw. willst du das entwickeln?

Du müsstest das ganze auf Kernelebene, also als Kernelmodul oder auf dem LSM Framework basierend implementieren.

PS:

Mit IP- Tables kann man sehr komplexe Filterregeln erstellen.

 

[HMarkus]

Du willst also quasi eine Firewall bzw. Paketfilter schreiben. Für welchen Anendungsbereich brauchst du das bzw. willst du das entwickeln?

Ja die Bezeichnung Paketfilter bzw. Firewall trifft die Sache zwar schon gut, aber nicht exakt.
Unter anderem soll folgendes möglich sein: Eine eigene Anwendung soll etwa bei diesem Filter ihren Datenstrom anmelden und dann bevorzugt behandelt werden. Nichtangemeldete Datenpakete anderer Anwendungen werden dann ggf. teilweise bzw. ganz blockiert. Wäre also eine Art anwendungsbezogener Traffic Shaper.

Was ich jetzt nicht einschätzen kann ist ob ich mit tun/tap diese Möglichkeiten habe.
I: Kann ich Pakete prüfen (IP und Port, Quelle, Ziel) und diese ggf. verwerfen?

II: Ist das ganze dann transparent für andere Programme?
Ein Problem das ich da sehe, könnte die Bindung eines Sockets an eth0 sein. Würde dann das tun/tap device alle Pakete automatisch abfangen, oder muss ich da dann noch mit iptables arbeiten?

Wäre schon froh, wenn mir ein Profi diese Fragen sicher beantworten könnte.
Und glücklich wäre ich, wenn mir jemand einen Tipp/Anlaufpunkt/... nennen könnte, wie ich das in Linux eingliedern kann.

Gruß
Markus

 

[spoensche]

Eine eigene Anwendung soll etwa bei diesem Filter ihren Datenstrom anmelden und dann bevorzugt behandelt werden. Nichtangemeldete Datenpakete anderer Anwendungen werden dann ggf. teilweise bzw. ganz blockiert. Wäre also eine Art anwendungsbezogener Traffic Shaper.

Kurz gesagt du suchst was für die Bandbreitenpriosierung. Es ist allerdings nicht nötig, dass du das Rad neu erfindest und Monate und noch länger eine Software entwickelst.

Sieh dir mal folgendes an:
http://www.heise.de/ct/ftp/02/24/224/
http://www.linux-magazin.de/Online-Artikel/QoS-Differentiated-Services-unter-Linux/(offset)/2
http://www.google.de/search?q=linux+bandbreiten+priorisierung&hl=de&client=firefox-a&hs=sg7&rls=org.mozilla:defficial&prmd=df&ei=lVRcTLTPI4PgOJzxpekN&start=10&sa=N

Zu dem Thema gibt es reichlich Lesestoff.

Was ich jetzt nicht einschätzen kann ist ob ich mit tun/tap diese Möglichkeiten habe.

Ein TUN/TAP Interface ist wie ein Ethernet Interface, nur das TUN/TAP nicht zwangsläufig hardwareabhängig ist und eher in Richtung der virtuellen Interfaces geht.

I: Kann ich Pakete prüfen (IP und Port, Quelle, Ziel) und diese ggf. verwerfen?

Dafür brauchst du kein TUN/TAP Interface, sondern solltest die Schichten des OSI- Schichtenmodells kennen. Ein Paketfilter arbeitet auf dem Layer 2. Zum Vergleich: Ein Proxy arbeitet auf dem Application Layer, was quasi dem Letzten Layer entspricht.

II: Ist das ganze dann transparent für andere Programme?
Ein Problem das ich da sehe, könnte die Bindung eines Sockets an eth0 sein. Würde dann das tun/tap device alle Pakete automatisch abfangen, oder muss ich da dann noch mit iptables arbeiten?

Nein es fängt nicht automatisch alle Pakete ab, sondern nur die, die auch für das Interface bestimmt sindd, es sei den du lässt das Interface im promiscous Mode arbeiten, dann liest es alles.

Wäre schon froh, wenn mir ein Profi diese Fragen sicher beantworten könnte.

Ich hoffe das meine Antworten dich weiterbringen.

Und glücklich wäre ich, wenn mir jemand einen Tipp/Anlaufpunkt/... nennen könnte, wie ich das in Linux eingliedern kann.

Da muss ich dich jetzt leider enttäuschen. Ein Paketfilter ohne Exploits ist nicht mal gerade eben programmiert und als Kernelmodul in den Kernel geladen worden. Als Anlaufpunkt kannst du dir den Quellcode von IP- Tables mal ansehen.

 

[HMarkus]

Hallo,

inzwischen habe ich ein paar Fortschritte gemacht, die ich hier für Interesierte mitteilen möchte.
Das tun/tap Device habe ich bis jetzt nicht vollends zum laufen gebracht. Wer diesbezüglich etwa Quellcode braucht, der findet z.B. hier http://svn.unix-ag.uni-kl.de/vpnc/trunk/sysdep.c etwas. Wer schon etwas mehr Erfahrung diesbezüglich hat, dann würde ich mich über weitere Informationen freuen. Irgendwas passt hier mit den route Einstellungen noch nicht, was evtl. dadurch erschwert wird, dass mein Linux unter VirtualBox läuft.

Die aktuelle Basis für mein Projekt wird ein IP-Hook sein, den ich mit libnetfilter http://netfilter.org/projects/libnetfilter_queue/doxygen/index.html umsetze. Auf der Seite ist auch ganz unten etwas Quellcode als Beispiel, der eigentlich für den Einstieg ausreichend ist.
Mit dem IP-Hook kann ich ein- und ausgehende Pakete abfangen, analysieren und ggf. modifizieren und anschließend passieren lassen oder verwerfen. Also vorerst alles, was ich für mein Projekt brauche.
Eine kleine Stolperfalle: mit
iptables -A OUTPUT -j NFQUEUE --queue-num 3
müssen erst die Pakete an diesem Hook weitergeleitet werden, wobei 3 hier die Queuenummer der Funktion nfq_create_queue entspricht.

Hoffe damit anderen einen guten Startpunkt gezeigt zu haben, und wie gesagt, wer Näheres zu tun/tap hat, bitte posten.

Gruß
Markus