Hallo!
Ich bin jemand, der gern Dinge bis ins letzte Bit versteht. Vor Jahren
hab ich mal einen MP3-Player gebastelt und war stolz, jede Zeile Code
selbst geschrieben zu haben und eine Bus-Weiche erfunden zu haben, die
den ewigen Lese-Schreib-Zyklus umgeht. An Hardware bin ich mittelmäßig
und an Toolchain-Fummeleien überhaupt nicht interessiert.
Demnächst möchte ich mich mal mit Internetprotokollen beschäftigen und
einen kleinen Netzwerk-Analyser oder eine kleine "Firewall" bauen
(Ethernet links rein, rechts raus).
Ich suche nun die passende Hardware, die zu mir passt. Zunächst dachte
ich an einen Arduino mit 2 Netzwerk-Shields. Zwar würde ich das
Arduino-Framework weglassen (das schon für das Setzen eines Pins
wahnsinnig viele Takte braucht), aber die Leistung wird wohl nicht
reichen, um bei einem normalen DSL-Anschluss mitzulesen.
Ich wende mich also an Euch. Hat jemand Erfahrungen, wie viel
Rechenpower eine kleine Firewall benötigt? Welche Hardware würdet ihr
mir empfehlen? Um es ausdrücklich zu sagen: Ich möchte kein Linux
haben, sondern direkt auf der Hardware programmieren, um wirklich zu
verstehen wann wo welches Bit ist. (Anleitungen wie
http://elk.informatik.fh-augsburg.de/hhweb/elinux/ngw100/howto.html
schrecken mich ab. Das ist alles ja nicht das, was ich eigentlich machen
möchte, sondern notwendiges Linux-Wissen auf dem Weg dahin.) Gute
Erfahrungen habe ich damals mit ATmega und libavr (damals WINavr)
gemacht. Die Toolchain ist Open Source, läuft auf Anhieb auf
verschiedenen Betriebssystemen, übersteht auch Betriebssystemupdates,
der Prozessor ist leicht zu verstehen, es gibt gute Doku, usw. Da kann
man ziemlich schnell mit dem Bits-Schupsen anfangen. Gibt es solche
Gespanne auch unter den schnelleren Prozessoren?
Wenn da wirklich ne Firewall bei rauskommen soll hast Du nen
ordentliches Stück Arbeit vor Dir.
Mein Tipp wäre nimm nen Linux als Basis, bau aber das Firewalling
selbst. Also setze nicht auf Netfilter, sondern ersetze das durch Deinen
eigenen Code.
Bei der Hardware würde ich mich nach einem von OpenWRT unterstützten
Router umsehen und dann dort Dein eigenes Linux reinpflanzen.
Begründung:
Damit das ganze irgendwie sinnvoll nutzbar wird, brauchst Du nen
größeren Prozessor als die gängigen µCs. Also sowohl was RAM angeht, als
auch was Leistung angeht. Die sind dann wesentlich aufwendiger zu
Programmieren als nen Atmega.
Das Projekt wächst dadurch dann auf Mannjahre.
Das Linux nimmt Dir die ganze Basisarbeit wie Hardware initialisieren
und ansprechen, Speicher verwalten, Prozesse schedulen, etc. ab. Du
kannst Dich dadurch ganz auf Deine Aufgabe mit der Firewall
konzentrieren. Das ist schon aufwendig genug.
Ob am Ende wirklich eine Firewall draus wird, weiß ich noch nicht. Ich
dachte, ich leite erst mal alle Pakete 1:1 weiter. Und dann lese ich mit
und es gibt kleine Meldungen wie "Da verbindet sich gerade jemand mit
Google" oder "Jetzt gehen x Pakete pro Minute verloren". Einfach um die
Protokolle mal tiefgründig zu verstehen. Mannjahre sehe ich da nicht.
Um Linux wollte ich eigentlich drumrum kommen. Ich schätze da den
Lernaufwand sehr groß ein. Lieg ich damit richtig?
Warum sind die großen Prozessoren eigenltich schwieriger zu
programmieren als Mikrocontroller?
Was ich nicht verstehe, ist, wo mir Linux Arbeit abnimmt. (Die nächsten
Fragen sind ernst gemeint.) Was brauch ich mehr als zwei
Ethernet-Bausteine zu initialisieren? Und wozu brauche ich Multitasking?
Die Bits kommen doch eh seriell an. Und wenn mein System schnell genug
ist, sollte es unmöglich sein, dass an beiden Ethernet-Buchsen
gleichzeitig etwas empfangen wird. Also hätte ich jeweils nur einen
Bitstrom von einer Seite zur anderen. Da brauch ich kein kompliziertes
Multitasking. Und damit bräuchte ich auch keine Speicherverwaltung. 1
Haupt-Thread, 1 großer Datenbereich, ein paar Interrupthandler, mehr
sehe ich da nicht. Schätze ich das falsch ein?
mh555 schrieb:> Und wenn mein System schnell genug> ist, sollte es unmöglich sein, dass an beiden Ethernet-Buchsen> gleichzeitig etwas empfangen wird.
Hä?
> Um Linux wollte ich eigentlich drumrum kommen. Ich schätze da den> Lernaufwand sehr groß ein. Lieg ich damit richtig?
Wie schon angedeutet gibt es das schon fertig funktionsfähig, z.B. bei
dem OpenWRT. Das kannst Du so wie es ist nehmen und fertig. Dann kannst
Du Stück für Stück mehr eigenen Code einbauen und mehr selbst machen.
Meiner Meinung kann man so schneller lernen als mit nem "toten" Stück
Prozessor den man erst von 0 an programmieren muss.
> Warum sind die großen Prozessoren eigenltich schwieriger zu> programmieren als Mikrocontroller?
Zum einen will die ganze Peripherie und die Funktionseinheiten
initialisiert werden.
Der eigentliche Grund ist aber daß wenn Du die Hardware sinnvoll
ausnutzen willst, musst Du irgendeine Form von Multitasking verwenden.
> Die Bits kommen doch eh seriell an. Und wenn mein System schnell genug> ist, sollte es unmöglich sein, dass an beiden Ethernet-Buchsen> gleichzeitig etwas empfangen wird. Also hätte ich jeweils nur einen> Bitstrom von einer Seite zur anderen.
Ganz so einfach ist es nicht. Schau Dir vielleicht als Vorübung mal die
Standards zu Ethernet an. Und dann die Ansteuerung eines Ethernet-MACs
wie er z.B. in einem der aktuellen ARM µCs implementiert ist. Dann wird
Dir vielleicht einiges klarer.
Ich würde erst mal vorschlagen ein Handy selbst zu bauen, damit man in
Übung kommt. Wenn das fertig ist dann kann man auch zwei Ethernetbuchsen
dranlöten.
Hmmm ...
Soll auf beiden Seiten ein Netzwerk sein? Fang mit einem Switch an.
Sollen auf beiden Seiten verschiedene Netzwerke sein?
Dann mußt Du auch NAT machen. Mit den ganzen Tabellen dahinter ...
ARP benötigst Du auch.
Eine Speicherverwaltung.
Evtl. mußt Du Pakete neu packen können. (MTU)
Soll FTP funktionieren? Dann muß in die Pakete geschaut werden und
dynamisch Ports geöffnet werden.
Die Pakete trudeln auf beiden Seiten nicht syncron ein. Du wirst um
Multitaskting also nicht drumherum kommen (und das ist noch ein relativ
einfaches Problem)
Und noch viele weitere Dinge, die Du berücksichtigen und erledigen
musst.
(Das hier ist nur ein kleiner Bruchteil vom Ganzen!)
mh555 schrieb:> Mannjahre sehe ich da nicht.
Ich schon ...
Gruß
Jobst
Also ich formuliere mal um. Ich möchte einen Repeater haben, der auch
mal die Pakete inspizieren kann. Die "kleine Firewall" soll dann
höchstens so funktionieren, dass ich mal ein HTTP-Paket an eine
bestimmte URL zwischendrin einfach abbreche. Wie der Zensor beim
Fernsehen, der plötzlich auf den Zensur-Knopf drückt. Nicht
professionelles, einfach um zu lernen.
@Rufus Τ. Firefly: Bei einem Repeater kommen die Pakete an den beiden
seiten nicht gleichzeitig an, bzw. kollidieren sie dann und die beiden
Sender kümmern sich selbst um die Auflösung.
@Gerd E.
Ja, ich weiß dass einige Leut so lernen: Nimm was Kompliziertes und bau
es langsam um. Ich lerne da anders. (MMC und FAT habe ich auch nicht
gelernt, indem ich eine Library langsam umgebaut habe, sondern indem ich
von 0 angefangen habe.) Ist vielleicht Typ-Sache. Das hab ich in meinem
ersten Posting ausführlich versucht zu erklären.
Für welche "ganze Hardware" brauche ich Multitasking?
Du hast Recht, auf der physikalischen Ethernet-Ebene kenne ich mich
jetzt noch nicht so aus. Will ich eigentlich auch nicht. Ich hätte
gehofft, dass ein Ethernet-Treiber einen Paket-Bitstrom kriegt und den
dann auf die Leitung gibt und sich um CSMA/CD etc. selbst kümmert. Ist
das etwa nicht so?
@Jobst M.
An beiden Seiten soll das gleiche Netz hängen. Das ganze soll als
Repeater starten und später mal Pakete inspizieren, vielleicht
irgendwann mal eins blocken oder ändern. Dafür brauche ich kein NAT. MTU
ist gleich. Ich muss zu Beginn keine Pakte neu packen solang ich nichts
verändere. Und am Anfang wird es kein FTP geben, vielleicht niemals.
Ich wiederhole nochmal: Ich möchte einen Repeater haben, auf dem ich
Stück für Stück aufbauen kann. Das Ziel ist das Lernen und nicht, dass
ich am Ende einen voll funktionsfähigen Router habe, der alle Rafinessen
besitzt. Wenn ich zwischendurch die Lust verliere, dann höre ich halt
auf. Bitte lest doch mein erstes Posting. Ich möchte ein bisschen mit
Internetprotokollen spielen und dabei etwas lernen. Ziel ist das Lernen.
Wem es schwer fällt, das zu verstehen, der kann einfach alles ignorieren
und nur auf die Frage antworten "Welche Hardware würdet ihr mir
empfehlen um einen Ethernet-Repeater zu bauen mit einem Prozessor
zwischendrin, der sich die Pakete ansehen kann".
mh555 schrieb:> Bitte lest doch mein erstes Posting. Ich möchte ein bisschen mit> Internetprotokollen spielen und dabei etwas lernen. Ziel ist das Lernen.
Dann nimm Raw-Sockets und programmiere deine Wünsche im Userspace.
Also wenn es um das Lernen von "Internetprotokollen" geht, würde ich
hier auch nicht bei 0 anfangen.
Ich würde mir da eher die Pakete/Frames mit Tools wie Wireshark
anschauen. Eventuell dann noch Cain&Abel (ist soweit ich weiß für den
privaten Gebrauch noch erlaubt, bin mir aber nicht sicher). Damit kannst
du alles auslesen und per Cain&Abel dich sogar durch eine falsche
ARP-Zuordnung zwischen Rechner und Internet schalten.
Hierbei wirst du Kenntnisse erlangen wie du in den meisten Netzwerken
Daten ausspionieren und auswerten kannst. Natürlich darfst du das nur
mit Einverständnis der User in deinem eigenen Netzwerk machen.
Aber der Lernfaktor ist meines Erachtens wirklich groß wenn du die
Pakete erstmal abfängst und dann per Wireshark ausliest.
Bin mir nur nicht sicher wie das mit Verschlüsselung aussieht. Cain&Abel
schafft selbst hier, dass die Geräte nur zum Programm eine
verschlüsselte Verbindung aufbauen und man über das Programm dann zB an
Passwörter etc. kommt. Ob man die Pakete dann unverschlüsselt aber auch
per Wireshark o.Ä. sieht, weiß ich nicht.
Die Möglichkeiten sind schier unglaublich.
Also ich habe das erste mal richtig LowLevel Internet-Protokolle auf
einem FPGA zusammen mit einem Freund gemacht. Einfach Phy an den FPGA
und dann ARP empfangen und senden. ARP ist auf der gleichen Ebene wie
IP, also nur eins über MAC. Sprich, habe ARP und MAC implementiert,
wobei für mehr keine Zeit war. Da lernt man schon einiges, man muss eben
jedes Bit das übers Ethernet geht selbst bestimmen, und wenn mans falsch
macht, kommt nichts an. Da ist dann zum Debuggen ein wenig Geschick
gefragt, habe mir letztendlich ein Loopack Ethernet Kabel gebastelt, da
die CRC nicht gestimmt hat, man Pakete mit falscher MAC CRC aber auch in
Wireshark und co. nicht sieht.
Auch für eine Firewall wäre so ein FPGA wunderbar geeignet. Einfach 2
Phys und Ports drannbauen, dann kannst du erstmal anfangen die Signale
des einen Phys einfach an den anderen durchzugeben, und wenn das
Funktioniert kannst du anfangen die Pakete schichtweise auszupacken und
neu zu verpacken/droppen/modifizieren/wieauchimmer. Nur für Pakete ab
TCP wirst du wohl einen Softcore brauchen.
mh555 schrieb:> Demnächst möchte ich mich mal mit Internetprotokollen beschäftigen und> einen kleinen Netzwerk-Analyser oder eine kleine "Firewall" bauen> (Ethernet links rein, rechts raus).
Die ideale Hardware wäre ein AT91SAM9X25 mit zwei Ethernet-MACs und
DM9161A PHYs. Dazu noch ein DDR2 SRAM-Baustein wie der H5PS1G63JFR von
Hynix oder Micron MT47H128M16 (128M*16) und ein x8 NAND-Flash (da passt
eigentlich jedes x-beliebige), und das System ist in den Grundzügen
komplett.
Hast DU schon mal 6- oder 8-lagige Multilayerboards mit BGAs drauf
gemacht?
fchk
Tokyo Drift schrieb:> Funktioniert kannst du anfangen die Pakete schichtweise auszupacken und> neu zu verpacken/droppen/modifizieren/wieauchimmer. Nur für Pakete ab> TCP wirst du wohl einen Softcore brauchen.
Ist schon bei UDP (SNMP, NFS) und ICMP (Ping) ohne Softcore haarig, wenn
der Filter nur Initiativen von links nach rechts zulassen soll, nicht
aber andersrum. Denn dann muss die Firewall einen internen Zustand
erzeugen, der bei einem erlaubten Paket für eine gewisse Zeit die
Gegenrichtung für exakt diese IP/Port-Kombination zulässt.
