on all Linux Platforms
TEST GRID
Test Grid History
Sept.18-00 | Sherry Ghafarpour | Document Creation
To do: a method to analyze the results, Automate the test so that each test case is one script |
Contents
To be noted for each test case
-The filter used for tcpdump
-The output file of tcpdump
-Freedom nym state: True Identity/ Nym Selected
-Script used to create traffic
-Output log files of scripts
-To test the socket filtering and packet filtering capabilities of clientshim in the context of freedom client.
Useful tcpdump filters:
1- to filter out all valid traffic and some broadcasts while the nym
is selected:
host "your_host_name" and (not arp) and (not udp port 51101)
and (not tcp port (51103 or 51104 or 51107 or 51101 or 51102 )) and not
net 127.0
2- to filter all traffic but erroneous when nym is active
on a single user set up when the user always sends mail under a nym
identity
tcp port (80 or 8080 or 443 or 23 or 22 or 119 or 25 or 110 or 7000
or 6670 or 6669 or 6668 or 6667or 6666 or 6665 or 6664 or 6663 or 6662
or 6661)
3- to filter out all traffic but the cloud traffic (useful when freedom
is set to true identity) -- define cloud traffic
udp port (51101 and 51100 ) and tcp port (51103 or 51102 or 51107
or 51104 or 51109 or 51108)
4- to filter all traffic but the route creation traffic
udp port 51102 (True?)
client.pl
Description:
This script makes a connection to the server specified by hostname
and send a test line to the server.
The output of this script is appended to clientoutput.log file.
Usage:
client.pl hostname(or IP address) port (1- 65000) protocol(tcp
or udp)
Exampl: client.pl caesar 24 tcp
client.pl 10.16.0.8 51101 udp
run_clients.pl
Description: Makes connections as above to all ports in the given range
Usage: run_clients.pl hostname first_port last_port
protocol
Example: run_clients.pl caesar 25 1024 tcp
server.pl
Description:
This script creates a socket on a given port and listens to incoming
connections.
Usage: server.pl port
Exampl: server.pl 51100
run_servers.pl
Description
This script creates several generic server .
Usage: run_servers.pl first_port last_port
Example: run_servers 65000 65009 -will create ten servers,
each listening for incoming connections.
portscan.pl
Description:
Make an attempt to connecti to all tcp ports on the host specified
by the hostname
Usage: portscan hostname
Example: portscan.pl localhost
startfreedom.pl
Description:
Must have a root access. Starts tcpdump collects the output of tcpdump
in dumpoutput.log and starts freedom, requires the user id and group id
of the user to start freedom.
Usage: startfreedom.pl userid groupid
Example: startfreedom.pl 56784 300
starttcpdump.pl
Description:
Usage:
Example:
Description:
Steps:
Run Freedom client and configure it to True identity
Run Tcpdump
Run the portscan script with destination localhost
Expected Results: TCP ports 51201 to 51207 on localhost should be listening for connections
Description:
Steps:
Run Freedom client and configure it to True identity
Run Tcpdump
Login as another user
Run the port scan script with destination localhost on ports 51201-
51208
Expected Results:
Non freedom user should not be able to connect to freedom proxy
Description:
** How to test?
Run Freedom client and configure it to True identity
Run tcpdump
Run the portscan script with an external destination
** Freedom proxies should be triggered for each freedom supported port
(Ref )
Steps:
Expected Results:
Freedom proxies should be triggered for each freedom supported protocol
(HTTP, SMTP ,...)
And the connection should NOT be made.
Description:
This test requires two machines, one (the server) running the server
listening on port x and the other running the client trying to connect
to port x. On the client side freedom is running under true identity. The
traffic between the server and the client should also be collected preferably
on a third machine. All three computers can be connected through a hub.
** We do have this setup in the lab
All communication between the server and the client is collected
in a log file.
Steps:
Run the server (server needs to be running on an external address,
address recognized to a user on Internet **)
Run Freedom client configure it to True identity.
Run tcpdump (using the script )
Run the client script
Save all results : clientoutput.log, serveroutput.log, dumpoutput.log
, tcpdumpfilter
Expected Results:
Freedom should not interfere with network traffic.
No traffic is sent through the cloud
Exceptions:
Description:
This test requires two machines, one (the server) running the server
listening on port x and the other running the client trying to connect
to port x. On the client side freedom is running under true identity. The
traffic between the server and the client should also be collected preferably
on a third machine. All three computers can be connected through a hub.
All communication between the server and the client is collected
in a log file.
Steps:
Run the server
Run Freedom client configure it to True identity.
Run tcpdump (using the script )
Run the client script
Save all results
Expected Results:
Freedom should not interfere with network traffic.
No traffic is sent through the cloud.
Exceptions:
All proxied ports are exceptions to this rule, connections to these
ports will be redirected to freedom proxy and proxy will not recognize
the protocol an it is expected to return error.
Description:
Steps:
Expected Results:
The traffic does not go through the cloud. Client should be able to
connect to the server on all ports.
Exception on connection to the port 53 (Well known DNS) . Client will
try to connect to the server, the connection go to freedom DNS server,
DNS server won't understand the packet that we are sending to it . Our
generic server wont receive a connection. (True?)
Description:
Steps:
Expected Results: (Check with Mario)
All traffic on our supported protocols must be routed through the cloud.
Client should be able to connect to the server.
Test Case - Inspecting traffic for UserX while UserY is running freedom
Expected Results:
The following template can be used for each specific configuration , the Result should only indicate a pass or the bug number. The expected results should be clear and concise.
Number: 1
Release Number:
Expected Results:
Set up:
list of log files
Result:
Pass / or BugNumber (or link to the bug entry)
Comments:
1) Can't really run freedom from a script
To be able to run many automated test what is required here is
a process to control the output from the freedom application and take actions
accordingly. For example to be able to analyze and parse the result of
tcpdum we need to know the state of freedom (Nym, True Identity) and each
time this state changes. It would be even preferable to have the output
of tcpdump in seperate log files for each state. One way to detect the
state changes is to analyze the STDOUT while freedom is running and act
accordingly. In otherwords we need to drive freedom application this is
exactly how the pseudo terminals are used for, "to drive interactive programs
in noninteractive modes" (Ref 1.).
In Unix systems this is done through the use of expect program.
In the future, it should be possible to write a an expect script to
run freedom while analyzing the output and running blackbox test scripts
interactively, this script can accept an input file with a set of commands
send the command to freedom client, wait for expected results and react
base on the accepted results. For exaple all the steps mentioned for each
test in this test plan can be performed automatically.
2) Can't parse the output of tcpdum correctly
To be able to analyze the result of tcpdump we need to be aware of
freedon state changes from true identity to nym and vice versa. For
example if the packets have been logged while a nym was selected any packet
with destication address 80 is considered to be a huge security hole, but
obviously the same is not true if freedom is set to true identity.
This is a limitation , while running the tests it is important to stop
logging if the state of freedom has been changed. But how to detect this
in an automated test ?
One solution would be to pipe the debug messages to a file and analyze
the file while freedom is running as explained above.
3) The server script should be running on a valid IP address that can be resolved by freedom.
4) One way to validate the results is to have tcpdump filters
that always filter out all valid traffic so that the output log of tcpdum
would contain not packets unless there is an error.