One primary function of DAQ is the ability to automatically (and continuously) test devices against a set of recognized standards. The goal is to increase the overall security level of devices to help prevent system compromise. In the base case, once the system is setup, a device can be plugged in and automatically tested against the built-in suite of tests to measure complicance. Core tests focus on base network operation (e.g. proper handling of DHCP) and security measures (e.g. proper use of TLS). Techincally, the core framework is a python program that coordinates the operation of dockerized test containers to run against tests against network-attached target devices; afterwards, a report is generated and optionally uploaded to a web dashboard.
Running bin/setup_daq will setup all key components and the basic prerequisites.
For the system overall, this installs a minimum set of basic packages, docker, and openvswitch.
Additionally, it sets up a local install of required packages and components. After setup,
also run cmd/build to build the necessary Docker images.
To configure the system to run the comprehensive suite of tests, do
echo "include: ../config/system/all.conf > local/system.yaml
(creating local if necessary). The basic qualification suite can be run with cmd/run -s. The -s means single shot and will run tests just once and then exit (see the
options documentation for more details). The output should approximately look like this example log output.
After an initial test-install run, edit local/system.yaml to specify the network adapter name(s) of the device adapter(s) or external physical switch.
If the file does not exist, it will be populated with a default version on system start with defaults that use the internal faux test client: This is recommended the first time around as it will test the install to make sure everything works properly.
The various options are documented in the configuration file itself. Note that the file follows "assignment" semantics, so the last declaration of a variable will be the only one that sticks. (The local/ subdirectory contains all information local to the DAQ install, such as configuration information or cloud credentials.)
After a test run, the system creates a test report document in a file that is named
something like inst/report_macaddressXX_timestamp.txt. This file
contains a complete summary of all the test results most germane to qualifying a device
(complete example report). If qualification dashboard is configured, this report will be uploaded to the configured cloud instance and available for download from the Web UI. Please see more in the next section.
The (optional) cloud dashboard requires a service-account certification to grant authorization.
Contact the project owner to obtain a new certificate for a dashboard page on an already
existing cloud project. Alternatively set up a new project by following the
Firebase install instructions. The bin/stress_test script is useful for
setting up a continuous qualification environment: it runs in the background and pipes the output into a rotating set of logfiles. See here for configuring DAQ to use the service account.
The majority of device tests are run as Docker containers, which provides a convenient bundling of
all the necessary code. The docker/ subdirectory contains a set of Docker files that are used
by the base system. Local or custom tests can be added by following the
"add a test" documentation. Tests are generally supplied the IP address of the
target device, which can then be used for any necessary probes (e.g. a nmap port scan).
The inst/ subdirectory is the instance runtime directory, and holds all the resulting
log files and diagnostic information from each run. There's a collection of different files in
there that provide useful information, depending on the specific problem(s) encountered. A device's
startup sequence log provides useful debugging material for intial device
phases (e.g. DHCP exchange).
Command-line options that can be supplied to most DAQ scripts for diagnostics:
-s: Only run tests once, otherwise loop forever.-e: Activate tests on device plug-in only, otherwise test any active port.daq_loglevel=debug: Add debug info form the DAQ test runner suite.mininet_loglevel=debug: Add debug info from the mininet subsystem (verbose!)
See the options documentation file for a more complete description of all the configuration options.
The startup (including DHCP negotiation and baseline ping tests) network capture can be found in the node-specific directory, and can be parsed using tcpdump with something like:
tcpdump -en -r inst/run-port-01/nodes/gw01/tmp/startup.pcap ip
The example pcap output file shows what this should look like for a
normal run (replace 01 with the appropriate port set number).