Neulich kamm mir die Idee einer 'QoS-NIC' welche auf Ethernet Layer arbeitet. Das zihl sollte es sein bei rechenlistungs schwachen Rechnern (z.B. Enbeded systems) eine Ueberlastung durch eine flood-basirende Attacke des Systems zu vermeiden bzw. zu unterdreucken. Ich ging bei diesen Ueberlegungen von einem nicht geroutetem Netzwerk aus. Die idee war eien dynamisirte Prioritaten verwaltung anhand der netzlast relativ zur Verarbeitungsgeschwindigkeit des Systems. So ist eine maximale ausnutzung des Netzes weiterhin gewaerleistet. Die Ueberlegung basirte auf der Idee die Ethernet Frames im Puffer zu mappen so das hoeher priorisirte Frames eine geringere Framedopingrate haben als niedricher Priorisirte im falle einer hohen Systemauslastung. Wenn nun also ein Packt kommt wird geprueft ob Platz im Puffer ist. Ist dies der Fall so wird der Frame in den Puffer geschriben und als Letzer angekommener Frame in der 'Map' eingetragen. Ist dies nicht der Fall so wirt ueberprueft welche absender MAC Addresse die meisten Fr
ames im Puffer hat. Ist diese MAC nun identich mitder MAC des senders des ankommenden Frames wirt der Frame sofort gedropt. Ist dies nicht der Fall wird der zeitlich letzte Frame mit dieser Absender MAC gedropt und durch den neuen Frame ersetzt. Die neue Frame wirt wieder als letzter angekommene Frame in der 'Map' eingetragen.
Durch dieses Verhalten werden Frames mit einem Absender hoeher Priorisirt welcher weniger Traffic macht. Kann das System alle Frames schnell genug Abarbeiten hat das Verhalten keinerlei Efeckt. Im Falle eines Angriffes wird nun also nur so viel an das System heran gelassen wie es verarbeiten kann. Ein potensieller Administrator erzeugt mit einer Login session relativ wenig Traffic wirt also gegenueber dem Angreifer als Beispiel wesentlich hoeher Priorisirt.
Der Efeckt, dass das System nur die Anzahl der Frames bekommt die es Verarbeiten kann entsteht von gantz allein bei dieser Verhaltensweise. Jedesmal wenn ein Frame kommt der nicht gedropt wird bekommt das System einen Interupt und kann den Frame abhohlen. Hohlt es nicht schnellgenug die Frames ab wird die Ueberschuessige menge gedropt und somit sinkt auch die Anzahl der Interupts. Das System regelt sich von selbst aus.
Es gibt ansich mir bis jetzt nur zwei bekannte Schwachstellen. Zum einen muss das betroffene Netz nicht geroutet sein bzw. darf nich geroutet sein da sonst der Router herunter Priorisirt wird. Der andere Schwachpunkt ist die erkennung des Absenders. Wechselt dieser seien MAC Adresse so kann er dieses System ueberwinden. Das System ansich bleibt weiterhin Stabiel da nun die Framedroppingrate rapide zunimt ist aber ueber das Interface nur noch sehr schwer bzw. langsam erreichbar. Da eine login Session ein Stream ist wirt sie durch eine Packetrecovery Funktion (z.B. dem TCP Recovery) vor dieser Framedropingrate geschuetzt, sie wirt allerdings extrem langsam.
Ich denke das mein Ansatz ansich nicht schlecht ist sovern er richtig verwendet wird. Vieleicht habe ich hiermit ja den ein oder Anderen angeregt. Die idee ansich ist ja auf jedes Medium das nicht ansich Recovert anwendbar. z.B. auf einen UDP basirenden Dienst. Ich wuerde mich Speziell bei dieser Idee sehr ueber Rueckmeldung freuen.