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
Schaust Du hier, Du glaubst es nicht: http://www.mikrotik-shop.de/Mainboards:::56.html?XTCsid=b80357b3b213fae6106527b61468b15e
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.