Several forms described below have two tabs in the Enterprise Edition: Global Settings and Local Overrides. The global settings tab allows you to set a global set of values which apply to all sensors in the Enterprise Edition. The Local Overrides allow one to choose a sensor from the drop down box and modify the settings only for that sensor. This modification will only affect that sensor and will override the global settings for that sensor. The button labeled 'Clear Local Overrides' at the bottom of the Local Overrides tab will allow one to clear the local overrides for that sensor and make its settings equal to the global settings. The Local Overrides will not show anything until you choose a sensor from the drop down list box. When you choose that, all local override values will be filled-in, but if there are no local overrides, then the global settings values will be filled-in instead. Therefore, the values you see filled in are not all local overrides. Unless you have already made a local override, all values filled in will be global settings in the Local Overrides tab. Please note that you will need to click on the 'Save' button when you are on either tab in order to save the settings you modified. 'Reload' will reset all settings to the value currently used.

An example of this kind of form is shown in Figure 4.42, “Alerting: Global Settings” and Figure 4.43, “Alerting: Local Overrides”.

This is used to start or stop tuning a profile, which is used to specify the normal traffic. Any traffic that deviates from the profile is deemed abnormal. The button at the top of the form is used to create a new profile. One can tune an existing profile using the drop down box below or create a new profile using this button. Therefore, clicking this button is optional. When you click on the button to create a new profile, you are given an option to choose whether the profile is sensitive to time of day or day of week or both. If you would like to detect problems with more accuracy, then it is recommended that you make the profile sensitive to both. As a result, variations from day to evening to night as well as Monday through Sunday will be stored separately. Therefore, typically acceptable traffic during the day might be labelled abnormal at, for example, past midnight or another time of the day. However, making the profile time or day sensitive can cause more false alarms.

Discovery options allow one to specify whether to analyze the traffic to find the major servers and subnets. This is part of the tuning process. One can opt to start discovery from scratch to completely ignore all such discoveries from the past. This is a good idea when the network traffic has changed lately. Incremental discovery allows faster settling on a tuned profile, while no discovery allows the fastest results. If the network has changed minimally or has not changed recently after the most recent tuning, then it is recommended to choose incremental discovery.

The tuning duration is to be made at least a few days. If you have indicated that the profile is sensitive to day of week, then you will need at the minimum a week of tuning. Checking the box to make this profile automatically active will have any effect only if it is not the currently active profile. An active profile is a profile that is currently used to delineate abnormal traffic from normal.

The Start Tuning button starts the tuning. If you are already running a tuning, then click on Stop Tuning first before clicking on the start button.

The table view shown in Figure 4.36, “Manage Profiles” is used to create, delete, duplicate or edit a profile, or to set it active. The icons under 'Actions' help one do these. The big button at the bottom can also be used to create a new profile. Creating a brand new profile is described in section Section 4.8.2, “Profile Tuning”. The actions are used to manage profiles in the system. It is not recommended that you maintain a large number of profiles - maintain only as many profiles as absolutely needed and no more. Erase them when not needed. This management policy will save database space and improve the performance. Duplicating an existing profile can be used to create a new profile that is already tuned in the past. That can then be tuned further and deployed as active. This enables one to save a profile in its original form and then make a copy to tune further to fit the current traffic.

The icons under 'Sensitivities' show whether a profile is sensitive to tie of day and/or day of week. Once a profile is set as sensitive or not sensitive at its creation time, this fact cannot be changed.

By placing the cursor over the 'Status' icons, the status is displayed as a tooltip.

Business groups are managed in the table shown in Figure 4.37, “Business Groups ”. The groups are displayed with the highest priority groups at the top. The user can drag and drop the groups to change the priority. However, no business groups can be dropped below 'Internal Space' as it will cause a conflict of the definition of the 'Internal Space'. The groups can be edited or deleted using the action icons. See Section 3.1.5, “Business group” for details on business groups.

Once can manually create business groups using the button below the table which is appropriately labeled. One can also create the groups in batches using a text file that one prepares and uploads. in order to get a sample text file, one can click 'Download definitions' and save the contents of the group descriptions into a text file by copying and pasting. This file can then be edited for uploading. The efficient method for creating a set of business groups is by uploading a file with your group definitions.

Flow devices (routers and switches) are seen in the tree diagram shown in Figure 4.38, “Flow Devices”. These are the devices from which exported netflow is received. The devices are grouped by the user. A group cannot contain other groups. The buttons allow one to add, edit or delete these groups. It is important to note that a flow device can belong to more than one group. Dragging and dropping can change the memberships of the groups. The 'Drag Drop Options' button allows one to specify whether drag-drop operation will cause the membership of the device to be removed from the group where it originally belonged. The 'Refresh tree' button allows one to see the latest grouping configuration. The 'Edit' button not only allows one to edit the device names, etc., but also to see more details on the device. If the name is specified as 'auto' under the edit dialog for the device, it will be fetched using SNMP as long as the corresponding check box is checked in the same dialog.

It is also important to make sure that the check box is checked under 'Flow Device SNMP Settings' and the correct SNMP community strings are input (See Figure 4.39, “Flow Devices SNMP Community Strings”). The community strings are to be provided in comma-separated form and will be tried one by one until a string works on the device or all strings fail.

Flow interface groups are shown in Figure 4.40, “Flow Interfaces”. Flow interfaces can also be grouped independent of the device they are attached to. This is for convenience is creating reports and dashboards. Once can group the interfaces according to the logical or business functions of the network. It is important to note that a flow interface can only belong to one flow interface group at a time. The buttons work in a similar fashion as in the flow devices groups as described in Section 4.8.5, “Flow Devices”. Drag-and-drop also works for regrouping the flow interfaces.

The buttons shown in Figure 4.40, “Flow Interfaces” are used to undo all the actions taken on problems such as suppression of problem instances on the problem table and suppression of the detection of certain types of problems on certain hosts. These actions are described in detail in Section 4.4, “Dashboards with Problems”.

The alerting of problems is done via email. This is set up in the form shown in the figures. There are two tabs in this form for the Enterprise Edition: the Global Settings (Figure 4.42, “Alerting: Global Settings”) and Local Overrides (Figure 4.43, “Alerting: Local Overrides”). These are described in Section 4.8.1, “Global Settings, Local Overrides ”. Please read that section to understand how it works and to apply that in the several forms that are described below.

The checkbox allows one to decide whether to turn on or off the alerting email mechanism. By default, this is checked on. The drop down list box allows one to set the problem severity level at which the alerts are to be sent out. Problems can have severities 1,2 or 3. An alert is sent out once only when the problem is first spotted. The email addresses follow in the text box below where you can input a comma-separated list of up to five email addresses. The SMTP server IP address follows. It is important to provide the IP address of an internal SMTP server which does not require authentication. Otherwise, no email alerts will be sent out. Finally, the 'Save' button needs to be pressed to make changes that you have input.

There are several problem detectors built into the system. They are classified in the settings shown here in Figure 4.44, “Problem Detection”. Please note that this form takes a few seconds to load, so be patient. All of the problem detectors are active at the beginning. One can turn them off by unchecking the checkbox. The severity of problem detected by each of them varies from 1 to 3. It is recommended that you do not change this number to anything smaller than 1 or larger than 3. The sensitivity is best left at 50%, but you can make the detectors become more sensitive (detect more problems, with an increased chance of false alarms and reduced chance of undetected problems) or less sensitive (detect fewer problems with a decreased chance of false alarms and an increased chance of missed problems) by making this number higher or lower than 50%, respectively. Please be sure to scroll down to the bottom of the form to click on the 'Save' button to save your changes. Global Settings and Local Overrides are described in Section 4.8.1, “Global Settings, Local Overrides ”.

A port limiting mask is like a virtual firewall which uses ports to control traffic. However, in this case, no traffic is altered, unlike a firewall. The product will not alter or block any traffic using this port limiting mask settings, whether or not you enable it. The only thing it does is to mark any port (TCP or UDP) violation (traffic seen at a port that is not in the permitted port list). The score of any hosts that violate these port rules will be increased. This might cause an alerting or a peak in the host score charts. Please take a look at the form shown in Figure 4.45, “Port Limiting Mask”. Once can enable or disable these three masks. This is accomplished by using the check boxes. By default, they are all disabled. The ports can be input manually or by cutting and pasting from a text file. Once you finish editing the ports, click anywhere outside the box of the ports and you will see that they immediately sort into an ascending order. Clicking on the 'Save' button is necessary to save the changes. Local overrides are possible for each sensor separately as described in Section 4.8.1, “Global Settings, Local Overrides ”.

Applications for the port masking are to determine whether there are random ports being used in the traffic, whether there is any peer-to-peer activity that went undetected by the P2P detector, or whether there are any applications running that are not permitted.

One or more standard reports can be scheduled to be sent via email attachment as a PDF document to one or more email addresses. They can be scheduled to be sent once a day or once a week. The form that sets up these schedules is shown in Figure 4.46, “Scheduled Reporting”. The currently scheduled reports are shown at the top table. The weekly schedules include reports that will be computed for a 7-day period, while the daily reports are computed for a duration of 24 hours. The 'Add New Schedule' allows one to add more reports to be added to the schedule. The Base URL field is for the product to access itself. This URL should not have HTTPS in it - only HTTP is allowed. This should be a URL that is accessible from itself such as 'http://localhost:80/V4/'. The 'V4/' at the end is necessary. The SMTP server IP address follows. It is important to provide the IP address of an internal SMTP server which does not require authentication. Otherwise, no email alerts will be sent out. Finally, the 'Save' button needs to be pressed to make changes that you have input for the URL and SMTP server.

The search preferences dialog is described elsewhere in Section 4.6.1, “Search Preferences” along with its figure.

Some settings for the console operation are shown in Figure 4.47, “ Console”.

Making the time to expire cached widgets larger will allow improved performance in reports and dashboards if there are simultaneously multiple users logged in, or if the users are pulling in dashboards repeatedly. Higher numbers here means that some data that is the chart may be about that many seconds older.

The maximum time to wait for sensors is to be increased if you experience failed creation of reports, dashboards or some other operation. Whenever a chart, table or graph is to be created, the console will enquire all sensors for relevant data and them merge them together. If the sensor cannot supply the data on time, then a timeout will occur and the widget that was being created will not be complete or accurate. Modify this setting if you experience problems in this area.

The hour at which maintenance is done is to be set some time late in the night when activity subsides. The maintenance operation include database and other maintenance that are performed at the console every 24 hours.

The duration before unused login sessions expire can be modified. This is effective only if the user has closed the browser without logging out. The log-in session in such cases will terminate after so many minutes. However, if the user has not closed the browser, the dashboards will be updates every 5 minutes, and this process will ensure that the login is not terminated automatically.

Log level is the number that sets how much detail is logged into the log files. The default is 1 and is the recommended level. For most details, use 3.

When there is a topology module present, as in the case of the Enterprise Edition, it will appear as Figure 4.48, “Topology Module”. Please note that the commands issued by the command buttons on this page and the discovery process will all take several minutes and occasionally hours to complete their jobs. The jobs are queued in the order in which they are issued. Do not stop or restart the application, or you will destroy the queue. Please wait for some time before you start to see the results of these operations.

'Refresh MAC-IP pairs at interval' is for the topology module to query all layer 3 devices using SNMP to determine the mapping of IP address versus MAC address (ARP cache). This is to be done frequently to ensure that the host names are correctly mapped to switch ports. Only those devices in the discovered list under Explorer will be queried.

'Refresh MAC-SwitchPort pairs at interval' is for the topology module to query all layer 2 and 3 devices using SNMP to determine the mapping of MAC address versus switch port. This is to be done frequently to ensure that the host names are correctly mapped to switch ports. Only those devices in the discovered list under Explorer will be queried.

For the explorer, topology module, and mapping of hosts to switch ports, one also needs to provide the SNMP community strings used throughout your network. Provide them in comma-separated format. Only read-only strings are needed at this point. For each device discovered, these SNMP strings will be tried one by one until one of them works or all of them fail.

The 'Discover switches and routers' button will open up a dialog the same way as in the Discover button under Explorer (Section 4.7, “Explorer”). Please refer to that section on the operation of this.

'Cleanup device database' will cleanup the database. Click this if you experience or suspect any problems.

'Remove aliased devices' will remove the duplicate instances of the devices that have multiple IP addresses when looked at from different subnets. This is recommended if you see the same device under Explorer (Section 4.7, “Explorer”) under different IP addresses.

'Erase all Contents of the Topology Database' will completely delete the topology database so you will have to start a fresh new discovery process starting from a central layer 3 device. It is not recommended to press this button unless you would like to build the topology databases from scratch.

This form is used to set up packet analysis and netflow inputs and a few miscellaneous things (Figure 4.49, “Sensors::General”). All of these settings primarily affect the sensors. Global Settings and Local Overrides available as described in Section 4.8.1, “Global Settings, Local Overrides ”.

'Console Server IP Address' is to be set differently than 'localhost' if you are adding additional stand alone sensors for an Enterprise Edition installation.

'Disable problem detection' is used to disable all problem detection and profile tuning.

'Disable flow analysis' is to disable netflow receiving completely. The next setting, 'Flow Listener UDP Port' is to be altered only if you change the listener port.

'Packet sensing Ethernet interfaces' is set only under the 'Local Overrides' tab since each sensor may have to have a different set of interface names, etc. There is no way to set these globally.

The 'Disable packet analysis' check box will disable packet analysis front-end altogether.

'BPF packet filter expression' is for advanced users only. You will need to test these elsewhere since there is no syntax checking for these inside the application. Example expressions can be found under the documentation of 'tcpdump' program on *nix systems or Windump program on Windows. For instance 'not port 80' will filter out port 80 traffic and allow all other traffic to be sensed. Please note that the BPF setting will only affect packet sensor and not the netflow sensor.

Log level is the number that sets how much detail is logged into the log files. The default is 1 and is the recommended level. For most details, use 3.

The form shown in Figure 4.50, “Sensors::Database” is used to control the amount of traffic data stored for both packet analysis and netflow. The database is segmented into intervals of 5 minutes, 1 hour, 4 hours, 1 day, 1 week, 1 month and 1 year. Each database segment contains tables with a certain number of rows which store aggregate traffic information (not each and every flow). The depth as well as the time duration of this database is what is being set in this form.

'Number of days of data to be kept' is how long one keeps the data. Anything older than this is erased permanently. Erasing takes place once a day.

'Minimum free disk space to ensure (in GB)' is there to ensure that the computer disk drive does not get clogged with traffic data. This will override the above settings for the number of days.

'Hour of the day when disk database maintenance it to be done' is when the database erasing and cleaning up are done every day.

'Advanced Database Settings' is to be modified only by advanced users. This part controls the depth of the database for each segment. If you increase the depth, more data will be stored and your searches are likely to find even the least frequent types of events in the traffic. This is preferred for forensic investigation where you may need to find needles in haystacks. Larger numbers like 50000 or 100000 are needed for this. However, for general bandwidth measurements, and overall traffic visibility problems, we may not need to store rare events. instead only the most bandwidth consuming events and frequent need to be stored. Smaller numbers like 100 or 1000 in these boxes will do the trick, but will cause permanent discarding of traffic data from rarer events.

Smaller numbers here allow faster reporting and smaller storage spaces. So if you are not particular about using the data for detailed forensic investigations and searches, we recommend that you choose smaller numbers.

If, on the other hand, you choose smaller numbers for all boxes, but a large number like 300000 for the 5 minute intervals, then even the rarest events will be stored in the 5-minute segments of the database. General reporting, when you choose boundaries of hours of days (without any fractional parts that may need access to the 5-minute segments), then those reports will be fast. However, you still have the rare events stored in the 5-minute segments of the database. In order to access that part of the database, you can choose to search in a fraction of the hour, from, say 10:05 AM to 11:55 AM, which does not include a whole hour. This search will then only access the 5-minute database segments which contain more detailed information.

Global Settings and Local Overrides available as described in Section 4.8.1, “Global Settings, Local Overrides ”.

The form shown in Figure 4.51, “Sensors::Host Identity” manage the name resolution of hosts. The names are resolved frequently, periodically, and as needed. The name resolutions are throttled so that they do not overwhelm your DNS servers or networks. However, an attempt is made to resolve the names as frequently as possible to ensure the freshness of names even in the case of frequently changing DHCP leases. However on occasion, names resolved may not be up to the minute.

The 'Do not resolve domain names' checkbox is to turn off domain name resolution. It is not recommended that you check this on.

'Do not resolve Windows host names' is to turn off Windows Netbios name resolutions. It is not recommended that you check this on.

'Windows host names take precedence over domain names as host identifier' is for preferring Netbios names over DNS names as the main host identifier. It is not recommended that you check this on.

'Query hosts directly, if query to domain controller fails' is for querying the hosts directly to resolve their Netbios names.

'Make one query at a time for improved reliability' is to be turned on if you see errors in resolved names. But this may slow down resolutions and may have a backlog of name resolutions build up in large networks.

Primary and Secondary Domain Controller or WINS servers are to input so Netbios queries can be made directly to them. You can also leave these blank so that Netbios name queries are made directly to the hosts. Please note that DNS resolutions are not made by queries to these controllers. Instead, DNS name resolutions are made by querying the operating system.

'DHCP Minimum lease time' and 'DHCP Scopes' are used to optimize the internal complex host resolution prioritization mechanism. If you leave 'DHCP Scopes' blank, all of the network will be considered DHCP. This is not going to cause any problems except that the host resolution parts may have some extra work to do. Therefore, in large networks with a lot of DHCP segments, you may leave this blank for convenience, unless you can aggregate all of those DHCP scopes into a comma-separated list.

'Maximum time between any host resolution' is also used to ensure that hosts are resolved on time.

'Profile hosts whose identities are ambiguous' is a setting that is usually turned off. The nLive problem detection mechanism usually profiles hosts that have a name or unique identity that can be detected. Sometime there may be hosts whose name is not visible or whose MAC address is not visible. Such hosts are called ambiguous. If they are also include in the profiling process, it may cause false alarms, but also increases the chance of detecting abnormal traffic and problems.

'Maintain phantom hosts in database' is also a checkbox that is not usually checked on. Phantom hosts are hosts that do not seem to exists in the network, but attempts are seen by other hosts to communicate with them. For example, if there is a network scanner or worm connecting to hosts whose IP addresses are manufactured on the fly, several of these destinations are non-existent. They are now called phantom hosts and are erased from the hosts database frequently to prevent bloating of the database. So checking this box on may cause database bloating and poorer performance and may result in problematic operations. It is here for purposes that involve diagnostics.

User's are managed from the table in Figure 4.52, “Manage Users”. There are administrators and regular users. Only administrators can make changes to the system. Regular users can only access the system to see the reports, dashboards etc. All user operations are under the 'Actions' column.

An administrator can reset the passwords of any other user including other administrators. All administrators have equal privileges. The special user 'Master Administrator' cannot be deleted, but has no more privilege than regular administrators.

The 'Add new user' button is for adding new users. This is only operable by an administrator.

This form, Figure 4.53, “Change My Password”., is used to change the password of one's own user account, and is self explanatory.

The form Figure 4.54, “Manage Sensors” is used to manage sensors in an Enterprise Edition installation. The sensors that are not deployed on the same machine as the console are to have their own IP addresses to access them from the console. The form is generally self explanatory. The column 'Active' shows whether the sensor is to be included in this console. The port number is generally to be left at the default value.

The 'Add sensor' button is to be used to add a new sensor. After adding, the sensor is automatically inactive. you will need to open the edit dialog to activate it.

The dialog Figure 4.55, “Edit Sensors Dialog” is used to edit sensors. Please note that there is a check box 'Active for this console' which needs to be checked for the sensor to be used in this console's system.

The table in Figure 4.56, “Manage Regions” shows regions which are defined as a collection of sensors. Each region can have one or more sensors. Each sensor can belong to one or more regions. The concept of regions is provided for convenience in reporting on geographical or other regions.

The dialog Figure 4.57, “Edit Region Dialog” shows how to add sensors to a region and how to change the region name and description. The 'Select more sensors' button allows the user to add more sensors to the current region. Removing the sensors can only be done by clearing all of them at once.

The license management screen has only one button called 'Manage license'. When pressed, this brings up the license management screen as described in Section 2.6, “License Screen”. Since there is no need to repeat the details of license management here, the reader is referred to that section. Please note that the currently installed license key will not be visible on the screen. Instead, the license key text box will be blank. If you input another license key, it will take effect so long as there is no error.