Benutzer:Grey/Security Tool Developement Projekt EN: Unterschied zwischen den Versionen
(→Wie sieht der Versuchsaufbau für ein Testskript aus?) |
(→Wie schreibe ich meine eigenen Testskripte?) |
||
Zeile 49: | Zeile 49: | ||
http://www.freitagsrunde.org/~grey/sonstiges/std/versuchsaufbau2.png | http://www.freitagsrunde.org/~grey/sonstiges/std/versuchsaufbau2.png | ||
− | === | + | === How am I writing my own testscripts? === |
− | + | Implementing a testscript is easy as breathing air. | |
− | + | For example let us take a look at implementing a simple UDP-packet. | |
− | + | At first the generation of a default ip-packet and its field modifications is done. | |
− | + | After that a default UDP-packet is genrated, independently from the default IP-packet. | |
− | + | We also have to modify the fields content of the UDP-packet, so that we meet our needs. | |
− | |||
− | |||
− | + | To finish, the default packets have to be melted together. | |
− | [[Benutzer:Grey/UDP-Testskript|UDP- | + | We take the UDP-packet as payload for the IP-packet, followed by FIXUP, so that the chekcsum is corrected. |
+ | |||
+ | Now with the transceive-function the UDP/IP-packet can be send. | ||
+ | |||
+ | A detailed discription of writing a UDP-testscript can be found here: | ||
+ | [[Benutzer:Grey/UDP-Testskript|UDP-testscript]] | ||
=== Grenzen von Tests === | === Grenzen von Tests === |
Version vom 14. Oktober 2005, 21:29 Uhr
Inhaltsverzeichnis
Documentation
HowTo
For what do we need the testscript?
For testing a firewall, we need the ability to generate and send different packets through our firewall. Our testscript ist here the manager, who administer to the sending and generating of the packets, while using the wrapper-classes. The testscript is refered in the commandline(the path to the script is refered) to FWTEST, so that FWTEST has not be compiled again for using another testscript.
Which language is used to implement a testscript? And why this language?
Python.
Python has many advantages:
- simple syntax and easy to learn
- a mighty programming library
- simple to integrate in C and reversed
- platformindependent
What abilities has a testscript?
- default packets
- IP-packets
- UDP-packets
- TCP-packets
- ICMP-packets
- sending packets
- everything that Python can
How does a breadboard construction for a testscript looking?
As a basic principle we can say that FWTEST has two agents- and one FWTEST-process.
We have two mostly used breadboard constructions.
variation 1:
We have three computers: the firewall, agent a(achen) and agent b(bchen). On achen and bchen is running an instance of our agent, additionaly is an instance of fwtest running on one of our agents (achen or bchen). So one agent adopts the function of fwtest.
A possible construction could be:
http://www.freitagsrunde.org/~grey/sonstiges/std/versuchsaufbau1.png
variation 2:
The ohther variation is based on four computers, two computers are functioning as agents and the third adopts the function of the controller (so FWTEST). The fourth, the firewall, is untouched.
A possible construction could be:
http://www.freitagsrunde.org/~grey/sonstiges/std/versuchsaufbau2.png
How am I writing my own testscripts?
Implementing a testscript is easy as breathing air. For example let us take a look at implementing a simple UDP-packet. At first the generation of a default ip-packet and its field modifications is done. After that a default UDP-packet is genrated, independently from the default IP-packet. We also have to modify the fields content of the UDP-packet, so that we meet our needs.
To finish, the default packets have to be melted together. We take the UDP-packet as payload for the IP-packet, followed by FIXUP, so that the chekcsum is corrected.
Now with the transceive-function the UDP/IP-packet can be send.
A detailed discription of writing a UDP-testscript can be found here: UDP-testscript
Grenzen von Tests
Testskripte sollen den Traffic simulieren und somit einen realistischen Paketaustausch darstellen. Zum Beispiel in unserem netdate-Beispiel haben wir eine Einschränkung.
Wir benutzen nicht wirklich den Heise-Server, sondern unser Agent nimmt diese Funktion ein, so daß natürlich die IP-Adresse unseres Agenten B (Bchen) im IP-Paket stehen muß. So gesehen ist es nicht wirklich eine Einschränkung des Testsktiptes, sondern eher des Versuchaufbaus. Es sei denn Bchen ist www.heise.de.
Eine weitere Einschränkung ist die komplexe Nachbildung einer Verbindungsstrecke, wie beim ICMP Fragmentation Needed Aufbau. Wir haben nicht alles, Server und Rechner zu denen eine Verbindung in der Realität aufgebaut werden würde, aber das ist auch nicht nötig. Es soll nur die Firewall getestet werden, ob sie richtig konfiguriert ist oder Schwachstellen hat.
So sind nur die Pakete wichtig die durch die Firewall gehen.