Aktuelle Version vom 15. Oktober 2005, 17:27 Uhr

Inhaltsverzeichnis

1 Documentation
- 1.1 HowTo

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
no memory management required TODO:in den dt. teil übernehmen
no type declaration of variables TODO:in den dt. teil übernehmen
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

Limits of tests

Testscripts shall simulate the traffic and as a sequence representing a realistic packet exchange.

For example, in our netdate-example we have a restriction.

We don't really use the www.heise.de Server, but our agent take place of the Server, so that of course the IP-address from our agent b(bchen) is taken and shown in the IP-packet.

It is not really a restriction of the testscript, but of the breadboard construction. Is bchen www.heise.de the restriction is obsolete.

Another restriction is the complex emulation of a connection (road section), as the construction of ICMP Fragmentation Needed shows. We don't have all servers and computer that are needed for the reality, but that is not the point. We don't need them to test the firewall in a realistic way. We only want to test the firewall, if it has weak points or misconfigurations.

So only the packets, which pass the firewall are important.

@@ Zeile 5: / Zeile 5: @@
 === 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.
+Our testscript ist here the manager, who administer to the sending and generating of the packets, while using the [[Benutzer:Grey/wrapper-klassen_EN|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.
@@ Zeile 13: / Zeile 13: @@
 Python has many advantages:
 * simple syntax and easy to learn
+* no memory management required '''TODO:'''in den dt. teil übernehmen
+* no type declaration of variables '''TODO:'''in den dt. teil übernehmen
 * a mighty programming library
 * simple to integrate in C and reversed
@@ Zeile 26: / Zeile 28: @@
 * everything that Python can
-=== Wie sieht der Versuchsaufbau für ein Testskript aus? ===
+=== How does a breadboard construction for a testscript looking? ===
-Grundsätzlich läßt sich sagen, daß FWTEST zwei Agenten und einen FWTEST-Prozess benötigt.
+As a basic principle we can say that FWTEST has two agents- and one FWTEST-process.
-Es gibt momentan zwei Versuchsaufbauten, die hauptsächlich benutzt werden.
+We have two mostly used breadboard constructions.
-'''Variante 1:'''
+'''variation 1:'''
-Wir haben insgesamt drei Rechner: die Firewall(FW), Agent A(Achen) und Agent B(Bchen).
+We have three computers: the firewall, agent a(achen) and agent b(bchen).
-Auf Achen und Bchen laufen jeweils ein Agent, zusätzlich wird auf einem Rechner (der Agenten) FWTEST gestartet.
+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).
-Es übernimmt also ein Agent zusätzlich die Aufgabe vom FWTEST-Prozess.
+So one agent adopts the function of fwtest.
-Ein möglicher Aufbau wäre zum Beispiel:
+A possible construction could be:
 http://www.freitagsrunde.org/~grey/sonstiges/std/versuchsaufbau1.png
-'''Variante 2:'''
+'''variation 2:'''
-Die andere Variante geht von vier Rechnern aus, bei denen zwei Rechner ausschließlich die Funktion eines Agenten einnehmen, und der dritte Rechner als Controller fungiert (also FWTEST ausführt). Die Firewall wiederum bleibt wie zuvor unberührt davon.
+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.
-Ein möglicher Aufbau wäre zum Beispiel:
+A possible construction could be:
 http://www.freitagsrunde.org/~grey/sonstiges/std/versuchsaufbau2.png
-=== Wie schreibe ich meine eigenen Testskripte? ===
+=== How am I writing my own testscripts? ===
-Im Grunde ist das Implementieren eines Testskriptes recht einfach.
+Implementing a testscript is easy as breathing air.
-Nehmen wir beispielhaft ein UDP-Paket, welches den Inhalt "Hallo Welt!" hat.
+For example let us take a look at implementing a simple UDP-packet.
-Als erstes generieren wir ein default IP-Paket und passen die Felder unseren bedürfnissen an.
+At first the generation of a default ip-packet and its field modifications is done.
-Danach generieren wir erstmal unabhängig vom IP-Paket ein default UDP-Paket. Auch hier passen wir unser Paket unseren bedürfnissen an.
+After that a default UDP-packet is genrated, independently from the default IP-packet.
-Am Ende müssen wir noch das IP-Paket mit dem UDP-Paket verschmelzen.
+We also have to modify the fields content of the UDP-packet, so that we meet our needs.
-Wir geben dem IP-Paket das UDP-Paket als Payload und korrigieren die checksum-Felder mit der Funktion FIXUP.
-Nun sollte ein UDP/IP-Paket vorhanden sein, daß mittels transceive-Funktion verschickt wird.
-Eine genauere Erklärung, bei der ein UDP-Testskript implementiert wird, finden Sie hier:
+To finish, the default packets have to be melted together.
-[[Benutzer:Grey/UDP-Testskript|UDP-Testskript]]
+We take the UDP-packet as payload for the IP-packet, followed by FIXUP, so that the chekcsum is corrected.
-=== Grenzen von Tests ===
+Now with the transceive-function the UDP/IP-packet can be send.
-Testskripte sollen den Traffic simulieren und somit einen realistischen Paketaustausch darstellen.
+A detailed discription of writing a UDP-testscript can be found here:
-Zum Beispiel in unserem netdate-Beispiel haben wir eine Einschränkung.
+[[Benutzer:Grey/UDP-Testskript_EN|UDP-testscript]]
-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ß.
+=== Limits of tests ===
-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.
+Testscripts shall simulate the traffic and as a sequence representing a realistic packet exchange.
-So sind nur die Pakete wichtig die durch die Firewall gehen.
+For example, in our netdate-example we have a restriction.
+We don't really use the www.heise.de Server, but our agent take place of the Server, so that of course the IP-address from our agent b(bchen) is taken and shown in the IP-packet.
+It is not really a restriction of the testscript, but of the breadboard construction. Is bchen www.heise.de the restriction is obsolete.
+Another restriction is the complex emulation of a connection (road section), as the construction of ICMP Fragmentation Needed shows.
+We don't have all servers and computer that are needed for the reality, but that is not the point. We don't need them to test the firewall in a realistic way.
+We only want to test the firewall, if it has weak points or misconfigurations.
+So only the packets, which pass the firewall are important.

Benutzer:Grey/Security Tool Developement Projekt EN: Unterschied zwischen den Versionen