Initializing the GUI (initUI)

Defining a GUI in Python can be accomplished with many different third-party libraries. However, here we have chosen to utilize the built-in Python TKinter Library, TK for short. Tk/Tcl is an integral component of standard Python. It provides a robust and platform independent windowing toolkit that is readily available to Python programmers using the TKinter module, and its extensions. The extensions include the Tix and ttk modules. Additional details regarding TKinter can be found in the Python Standard Library at https://docs.python.org/2/library/tk.html .

The TKinter module is a thin object-oriented layer on top of Tcl/Tk, which provides a set of wrappers that implement the Tk widgets as Python classes. In addition, the internal module _TKinter provides a threadsafe mechanism which allows Python and Tcl to interact.

Using TKinter requires us to make specific declarations and configurations for each of the onscreen widgets along with any event handlers (for example button clicks) for each widget.

Configuring TK can be done using one of two geometry-based methods, commonly referred to as Grid and Pack. We have chosen to use the Grid method. Using the Grid method organizes widgets in a table-like structure, where each widget (buttons, labels, combo boxes, progress bars, etc.) are then placed at a specific row and column location.

In addition to visual widgets, other objects such as menu-based objects like those declared in the U1 highlighted section are placed on the frames menu bar.

In order to better explain how this is done, we will walk through each code section U1 through U7.

U1-Menu Bar

In addition, the keyboard shortcut bindings for Ctrl-X and Ctrl-A are defined to allow keystroke menu selections.

Finally, specific command executions are associated with the About and Exit menu options. For example:

If you examine Table 4-1 you will see the declarations for these two methods as part of the application object. We will examine those methods later in this chapter.

This produces the menu as shown in Figure 4-5.

U2-Folder and File Selection

Taking a close look at the first folder selection, we first define the label widget with the text Report Folder and place that label at row 1, column 0 on the parent frame and we anchor the frame to the westmost position in the column.

Next, we specify another label widget at row 1, column 1 and specify the label to be sunken to represent data that is specified.

Finally, we add a button widget at row 1, column 2 that will launch a dialog box for the user to select the folder where reports, baseline, and alerts will be stored. Notice this widget has a command associated with self.btnSelectFolder. This method is also defined in Table 4-1, and again, we will examine the details of this method. The method source code is shown here.

U3-Duration Selection

Duration selection specifies two widgets. The first is a label to display “Select Duration”, and the second is a combo box to list the possible duration options available. The label is placed at row 3, column 0, while the combo box is placed at row 3, column 1. When the user clicks the combo box, the list of possible options is displayed as shown in Figure 4-6. The current selection is maintained by the widget and we can retrieve that selection at any time. Of course, the string value will have to have been converted into a useable time value.

U4-Action Buttons

The action buttons, activate sensor, record baseline, stop and view Alerts are defined here. They are all defined to be placed in row 8, column 1. However, each contains a different padx value (padding from the westmost position of the row) allowing the buttons to be separated. Without the padding, they would be displayed on top of each other.

In addition, each button has a defined command associated with it that will be executed when pressed.

Also, notice that each of the buttons is set to DISABLED. The rationale is that the buttons cannot activate the specific operations until the report folder and/or the baseline have been correctly selected.

In addition, the stop button will be enabled once either the activate sensor or record baseline operations are underway, allowing the user to interrupt the operations. Once the selections have been made the buttons become activated, as shown in Figure 4-7.

The source code for each button selection are covered in the GUI Source Code Selection.

U5-Progress Bar

When the activate sensor or record baseline process is underway, a progress bar will be displayed to depict the time remaining in the scan. For this widget we are using a label and a ttk progress bar widget.

U6-Report Selection

As with the duration selection widgets, we are using a combo box to provide a list of possible reports that can be selected, a label to display the text “Select Report”, and a button to display the selected report. Note that the view selected report button is also disabled during initialization and only enabled when reports are available for display, as shown in Figure 4-8.

U7-Status Bar

The last section defines the status bar at the bottom of the frame. This is used to report status as the application executes. Once again, we use a simple sunken label widget for the status bar (Figure 4-9). The widget is placed at row 10, column 0.

Exploring Other Application Methods

Now that we have initialized the application interface, let’s look at the underlying functions that perform operations based on the user interactions described in Figure 4-3. We will start with selection of the report folder and baseline. The application will write newly generated reports to the selected report folder. In addition, the subfolders Baselines and Alerts will be created to hold any recorded baselines and alerts generated during active sensor operation.

Selecting the Report Folder (btnSelectFolder)

Start with the btnSelectFolder method (depicted in code segment F1), which is activated upon the button click action defined in “U2 Folder and File Selection.” This section is straightforward; we are using the built-in tkFileDialog.askdirectory function, which displays a directory selection dialog as shown in Figure 4-10. As you can see, the baselines and alerts folders have also been created.

If the selection result is a valid directory (we use the os.path.isdir() method to verify this) then we can enable the record baseline button. In addition, if the baseline has previously been established, then the activate sensor button could also be enabled.

Source Code Methods for GUI Elements

When we examine the btnSelectBaseLine method depicted in F2, we see that this function is a bit more complicated. First, this method uses the built-in tkFileDialog.askopenfilename to select the baseline. Since the user can select any file with the .baseline extension, we need to verify that this is a valid baseline generated by the record baseline method. Once this is verified, we create a set of local dictionaries to hold extracted values from the baseline, including previously observed countries and MAC addresses; these will be used during the monitoring process to generate alerts from unknown countries and new observed MAC addresses.

Once a verified baseline and report folder have been selected, both the activate sensor and record baseline selections are available, as shown in Figure 4-11.

Record Baseline Method (btnPerformCapture)

The method first performs some setup tasks (section R1) to disable the other action buttons and to enable the Stop button, allowing the user to interrupt the recording. In addition, a packet processor object is instantiated, which in turn loads the necessary lookups for manufacturer OUI identification, port and protocol translations, and country lookups. If the PaPirus display is detected and available, it will be initialized to display details of the ongoing recording.

Finally, the network adapter is set to promiscuous mode to collect all traffic presented at Eth0.

Moving to section R2, the main loop is established and processes each packet observed over the network. The loop continues until either the duration time expires or the user presses the stop button. Every 2 seconds, the packet count is updated in the status bar and the progress bar is updated marking the progress toward the time expiration.

Once R2 completes (either by the user interrupting the process or through time expiration), a new baseline is created and stored in the baseline directory, and all the HTML and CSV reports are generated and stored in the selected report folder. The code in the R3 section calls each report generation function. Let’s take a deeper look at one of the report generation functions to examine how the resulting HTML reports are generated in the next section.

Master Report Generation (GenHTML)

The report generators all work basically the same, but they filter and sort data based on the specific reports being created. The method is a unique method of autogenerating an HTML file. One could use XML (eXtensible Markup Language) and style sheets as an alternative.

Examining M1, we start by updating the status bar of our progress. The current date and time are obtained in order to generate a unique file name for the desired report. Each report name is prepended with the date-time in order to provide easy sorting of the report results. For this example, the report name would be in the following format:

Next, the html file is built from a template stored in the rpt.py file. Each report has a separate template that is used. Basically, the template contains an HTML_START section, HTML_HEADER section, (multiple) HTML_BODY sections, and HTML_END section.

Examining the code in section M2, the Python dictionary object d contains all the unique observations collected during this recording. A loop is created to iterate over each unique observation, and the values extracted from the key/value pairs of the dictionary are stored in local variable prefaced with fld (for example, fldAlert, fldSrcIP, etc.). Once they are collected we use the format method available for strings, as shown here, to replace the placeholders defined in the template HTML.

The template HTML placeholders highlighted here are then replaced by the corresponding local variables to generate the final HTML code.

Once all the HTML code has been generated, the code in section M3 writes out the complete htmlContents to the report filename created in section M1.

Saving the Baseline (SaveOb)

In addition to generating the various reports associated with the record baseline process, the actual baseline is also created. This is a straightforward process in Python, as we are serializing the Python dictionary object d using the pickle standard library module.

In Section S1, the SaveOb method uses the same naming convention used when creating report files, but adds the file extension “.baseline” to the file. Then with only two lines of code, the baseline file is created.

Activate Sensor (btnActivateSensor, PacketMonitor)

The final method to examine in this chapter is the btnActivateSensor method. The front end of this method mimics that of the packer recorder. The difference is in the processing of each received packet. The PacketMonitor method examines the received packet and determines if “the same packet construction” exists in the current baseline. If not, then an alert report item is generated to indicate a “New Observation”. In addition, the key elements of the packet, such as IP country location, MAC address, packet size, and time of the observation, are compared to known or expected values. If anomalies are discovered, additional report items are recorded. The following code snippet includes the btnActivateSensor, PacketMonitor, and supporting methods.

def PacketMonitor (self, packet, alertDict, baseCC, baseMAC):

Packet Monitor Supporting Methods