Menu
▾
▴
[Audit-test-developer] [PATCH 02/09] network filtering
|
From: James C. <cz...@li...> - 2011-06-26 22:37:17
|
Signed-off-by James Czyzak <cz...@li...> <mailto:cz...@li...> diff --git a/audit/README.netfilter b/audit/README.netfilter new file mode 100644 index 0000000..ae3413d --- /dev/null +++ b/audit/README.netfilter @@ -0,0 +1,250 @@ +README.netfilter + +ABOUT NETFILTER TESTS +The netfilter tests reside in the sub-directories netfilter and netfilebt of +the audit-test suite. The tests of the iptables and ip6tables reside in +netfilter, and the bridge table filtering tests are in netfilebt. The use +of a remote server running the lblnet_tst_serves required for these tests. + +The ebtables tests also require the creation of a bridge (logical) device on +a secondary network to which the secondary network's ethernet (physical) +device is enslaved. The bridge should be created prior to running the +config-server.bash script is run + +The iptables and ip6tables tests have a large number of the tests that run +over the local loopback device to a locally running lblnet_tst_server. +Some of the tests for iptables and ip6tables are run over the primry ethernet +device against a remote server executing the lblnet_tst_server application. +The locally run lblnet_tst_server which the iptables and ip6tables tests +utilize is automatically started and stopped in the run.conf file, however +the lblnet_tst_server that runs on the remote server must be started before +any of the tests can begin as connectivity to it is tested prior to the +start of any tests. If connectivity cannot be established the test will +error out. The iptables/ip6tables tests have some tests that check the +ability to filter packets requiring forwarding. This requires the use of +a third platform known as the catcher. It can be any platform capable of +running netcat listens. + +You should read the README.netwk_svr for instructions on how to setup the +remote network server. + +Their are a number of environmental variables required in order to provide +the information needed to set the rules in iptables, ip6tables and ebtables. +Some of these environmental variables are also required by the network +tests in the audit-test/network directory. These environmental variables +may be set manually prior to running the tests but the process of setting them +all is simplified by the config-server.bash script. This script will ask for +the pertinent ipv4, ipv6, and mac addresses as well as device names to which +these adresses are assigned. This allows considerable flexibility in +configuring systems with 2 or possibly several more network interfaces on +both the TOE platform as well as the network server platform. The +config-server.bash script will build a profile in the /tmp directory that +should be sourced prior to running the tests. it is important to pay +attention to the format and correctness of the answers. While the +config-server.bash script will echo your response to the questions and allow +you the opportunity to change your responses, it currently does no format +checking and cannot verify if an address or device name is accurate. It does +however use a profile.sample file to provide a default answer which is +primarily provided for the purpose of giving a sample of the format expected +in the response. + +TESTING STRATEGY +The strategy of the testing is to provide a known and preferable empty +chain in the tables prior to the start of the testing. Then a test message is +run throught the appropriate chain of the tables showiing that it is not +blocking or filtering on the test message. The rule is applied with the +approriate filter information and the test message is run through again. +The result is checked for the expected result of either the dropping, +acceptance, or rejection of the test message. Often the dropping of a message +is verified through the timeout of a listen for the message or the timeout +of a connect request. It is usually verified again via the action parameter +for the message type NETFILTER in the audit log which is rotated before +the start of each test. In the case of a chain policy drop rule the listen +or connect timeout must suffice. This is because the only way to audit a +dropped message is to insert a rule with a target of AUDIT_DROP, however +by inserting such a rule it would not verify that the drop is caused by the +policy change as opposed to the rule inserted to audit the drop. + +ENVIRONMENTAL VARIABLES +Below is a list of the environmental variables required to run all the tests +as well as an explanation of what they are. + +RHOST="localhost" (always the local loopback IPv4) + +RHOST6="::1" (always the local loopback IPv6) + +MODE (set to either 32 or 64 depending on whether the TOE OS is + installed as 32 bit or 64 bit) + +PPROFILE (set to capp if running selinux targeted policy (a.k.a base)on + the TOE or set to lspp if running mls policy on the TOE) + +PATH="$PATH:." (The PATH should include the local directory) + +PASSWD (This should be set to the super user password) + +AUDITPATH (Should be set to the audit-test suite directory on the TOE + the directory path should include audit-test. This would + normally be set to /usr/local/eal4_testing/audit-test) + +LOCAL_DEV (primary ethernet device of the TOE for example "eth0") + +LOCAL_SEC_DEV (secondary ethernet device of the TOE for example "eth1") + +LOCAL_SEC_MAC (MAC address of the secondary ethernet device on the TOE + +LOCAL_IPV4 (IPv4 address of primary device on TOE) + +LOCAL_IPV6 (IPv6 address of primary device on TOE) + +LOCAL_SEC_IPV4 (IPv4 address of secondary device on TOE) + +LOCAL_SEC_IPV6 (IPv6 address of secondary device on TOE) + +TOE_GLOBAL (This needs to be either a global or site local IPv6 + address for the primary device on the TOE. Link local + addresses are not forwarded and this is used in the + forwarding test) + +TOE_SEC_GLOBAL (Must be a global or site local IPv6 address for the + secondary device on the TOE) + +LBLNET_SVR_IPV4 (This is the IPv4 address for the primary device on the + network server where the lblnet_tst_server application + is running) +LBLNET_SVR_IPV6 (This is the IPv6 address for the primary device on the + network server where the lblnet_tst_server application + is running) + +LBLNET_SVR_DEV (The device name for the network server's primary interface + for example "eth0") + +LNET4MASK (Network mask being used on the primary IPv4 network for + example 255.255.255.0) + +LNET6MASK (Network mask being used on the primary IPv6 network, + specified in number of bits for example "64") + +SECNET_SVR_IPV4 (IPv4 address of the network server's secondary address) + +SECNET_SVR_IPV6 (IPv6 address of the network server's secondary address) + +SECNET_SVR_DEV (Device name for the network server's secondary interface + for example "eth1") + +SECNET_SVR_MAC (MAC address of secondary device on the network server + where the remote lblnet_tst_server application is running) + +SECNET_IPV4 (IPV4 address of the secondary device onn the network server + where the remote lblnet_tst_server application is running) + +SNET4MASK (Network mask being used on the secondary IPv4 network for + example 255.255.255.0) + +SNET6MASK (Network mask being used on the secondary IPv6 network, + specified in number of bits for example "64") + +CATCHER_IPV4 (IPv4 address of 3rd platform where netcat listen on + specified port is performed ...nc -l $CATCHER_PORT4) + +CATCHER_IPV6 (Global or site local IPv6 address of 3rd platform where + netcat listen is performed ...nc -l $CATCHER_PORT6) + +CATCHER_DEV (Device name of interface on 3rd platform providing + connectivity to the TOE's secondary network) + +CATCHER_PORT4 (Port # on 3rd platform designated for the IPv4 netcat listen + for example "4100") + +CATCHER_PORT6 (Port # on 3rd platform designated for the IPv4 netcat listen + for example "4200") + +PITCHER_IPV6 (Global or site local IPv6 address of network server's + primary network interface) + +PITCHER_DEV (Is always the same as LBLNET_SVR_DEV simply used in the + scripts to signify the forwarding tests) + +BRIDGE_FILTER (Name of the bridge created on TOE for the ebtables testing. + This bridge should have the secondary device enslaved to + it. + +PROCEDURES FOR CONFIGURATION + +The config-server.bash script in the top level directory of the audit-test +suite should be run on each platform prior to running any of the netfilter +tests. The config-server.bash script must be executed on the TOE first. + +The config-server script will query the user for the adresses, device names, +and network masks needed to properly configure the network, set routes in +the routing table, and set up the chain rules in iptables, ip6tables, and +ebtables. If you choose not to run the config-server.bash script you must set +the above environmental variables and routing tables manually prior to running +the tests. + +Prior to running the config-server.bash script you should create the logical +bridge on the TOE that will be used to test ebtables. The name of the logical +bridge will be requested by the config-server.bash script. The bridge can be +set up with the following commands: + +brctl addbr <bridge name> -- This creates an instance of the + ethernet bridge + +After executing this command it is a good time to modify the +ifcfg-<ethernet interface> in the /etc/sysconfig/network-scripts directory +Below is a sample of what the content of this file (ifcfg-eth1) might look +like if the ethernet interface name was eth1 and the bridge name was br1 + +DEVICE="eth1" +BOOTPROTO="static" +HWADDR="00:21:5E:F0:31:9F" +ONBOOT="yes" +BRIDGE="br1" + +brctl addif <bridge name> <ethernet interface> -- This assigns the ethernet + interface as a port of the bridge + +After executing this command it is a good time to create the +ifcfg-<bridge name> in the /etc/sysconfig/network-scripts directory +Below is a sample of what the content of this file (ifcfg-br1) might look +like if the ethernet interface name was eth1 and the bridge name was br1 + +DEVICE="br1" +BOOTPROTO="static" +IPADDR="192.168.1.67" +NETMASK="255.255.255.0" +IPV6INIT="yes" +ONBOOT="yes" +TYPE="Bridge" + +Restart the network at this point with either a "service network restart" if +running in capp mode or "run_init service network restart" if running mls +policy. + +brctl setageing <bridge name> 3600 --sets the ageing timer + +Setting the ageing timer to a high value is helpful to the testing as +it prevents the learned mac addresses in the bridge's forwarding database +from being deleted when it hasn't seen a frame from that mac address in the +timer number of seconds. + +The setup of this bridge will be placed within the config-server.bash script +at a later date. + +After the config-server script has been run there will be a file named profile +in /tmp. This file will contain all the export commands for the environmental +variables listed above. It contains environmental variables that are needed on +each of the 3 platforms. To keep from having to do the many queries again on +each platform the file /tmp/profile needs to be copied to the /tmp directory of +each of the other two platforms and a source /tmp/profile should be executed +on each of the platforms. The config-server script should be then be run on +the other two platforms (netserver and catcher) The order of the remaining +two platforms is not important. The config-server.bash script when +run on the other two platforms will only query for the role (netserver or +catcher) and the superuser password. It will use the information from the +/tmp/profile to setup the network configuration and routing + +Once the config-server.bash script has been run on each of the 3 platforms +(TOE first followed by the other two) The netfilter tests will be ready +to run. + |