52
edits
Global settings: Difference between revisions
Jump to navigation
Jump to search
Add snort analysis setting explanation
(Add snort analysis setting explanation) |
|||
| Line 46: | Line 46: | ||
[[File:Webshark.jpg|900px|Built in Webshark - Allegro Network Multimeter ]] | [[File:Webshark.jpg|900px|Built in Webshark - Allegro Network Multimeter ]] | ||
=== Detail of traffic analysis === | === Snort analysis=== | ||
{{Warning|title=Beta Feature|This feature is still in active development and is therefore subject to changes in the future. If you encounter issues or bugs using this feature please report them to our support.}} | |||
The Allegro Network Multimeter is able to perform intrusion detection based on the [https://www.snort.org/ Snort] software project. The detection can be performed on live traffic or ring buffer traffic. This analysis is invoked via the capture dialog on any page and respects the same capture filter expressions as a normal traffic capture. | |||
[[File:Snort Analysis Results.png|thumb|Snort Analysis Results]] | |||
This feature is disabled by default, to enable it navigate to Global Settings > Snort Analysis and enable it via the toggle switch. Once enabled a new setting will appear to regulate the allowed memory usage by the intrusion detection. The user is able to set a hard maximum limit on the usable memory, and if the Snort process exceeds this limit it will be killed by the OOM-Manager. Additionally, another soft memory limit will be installed just below the hard maximum, and if the process reaches this limit it will be throttled heavily. If your intrusion analysis appears to get stuck or is unusually slow, a good troubleshooting step is to increase the memory limit. It is generally not recommended to keep the memory limit above around 200MB. | |||
When invoking the analysis a new modal will open which displays the results of the analysis. The result modal is a list of detected incidents, sorted by order of appearance. An entry in this list has the following structure: | |||
{| class="wikitable" | |||
|+ | |||
!Severity | |||
!Time | |||
!Classification | |||
!Message | |||
!Connection | |||
|- | |||
|This is denoted by the color on the left hand side of the row. | |||
|The packet timestamp of the offending packet. | |||
|A normalized name for the type of incident that occured. | |||
|A more detailed description of the incident | |||
|A diagram of the connection in which the incident occured. The IPs can be clicked to go to the IP detail page, and on the right there is an "external link" icon that opens the connection details page in a new tab. | |||
|} | |||
Additionally, on the right hand side of the modal is another color band that serves as a rough overview over all incidents. The band is static and roughly aligned with the scroll bar to make it easier to navigate to specific severity incidents. | |||
Snort works by reading a rule file which contains a list of rules used to match packets against. These rules can match subnet, direction, protocol, payload contents, and more (see the Snort documentation for more information on rules), and are given a classification, message and priority, which are displayed in the analysis results. Internally this feature uses a community rule set which is available for free and receives periodic updates. '''Note:''' The Allegro Network Multimeter does NOT automatically update this rule set. We are deploying the same rule set to all devices independent of the date of installation. Thus the analysis may not be able to detect zero day exploits and should not be relied on when trying to detect recently discovered attack vectors. | |||
At the moment, only critical and severe incidents are reported (Snort priorities 0 and 1). The classification and message strings are taken directly from the rule that triggered this incidents. | |||
===Detail of traffic analysis=== | |||
Limit module processing, allows you to configure which OSI-layers (2,3,4,7) are actively processed and analyzed by the Allegro Network Multimeter. With this setting, the performance of the Allegro Network Multimeter can be significantly improved and allows for higher throughput when disabling some analysis modules. | Limit module processing, allows you to configure which OSI-layers (2,3,4,7) are actively processed and analyzed by the Allegro Network Multimeter. With this setting, the performance of the Allegro Network Multimeter can be significantly improved and allows for higher throughput when disabling some analysis modules. | ||
| Line 52: | Line 79: | ||
For both realtime and offline parallel analysis, the following modes are possible : | For both realtime and offline parallel analysis, the following modes are possible : | ||
* Only capturing: Only interface statistics and the capture module is provided. Capture filters are supported without Layer 7 protocol specification/recognition. | *Only capturing: Only interface statistics and the capture module is provided. Capture filters are supported without Layer 7 protocol specification/recognition. | ||
* Capturing and protocol detection: Additionally Layer 7 protocol specification in Capture filters will now work. | *Capturing and protocol detection: Additionally Layer 7 protocol specification in Capture filters will now work. | ||
* Up to Layer 2: Additionally all Layer 2 related modules are active such as MAC, MAC protocols, ARP and Burst Analysis. | *Up to Layer 2: Additionally all Layer 2 related modules are active such as MAC, MAC protocols, ARP and Burst Analysis. | ||
* Up to Layer 3: Additionally all Layer 3 related modules are active such as IP and DHCP statistics. | *Up to Layer 3: Additionally all Layer 3 related modules are active such as IP and DHCP statistics. | ||
* Up to Layer 4: Additionally all Layer 4 related modules are active such as TCP and Layer 4 server ports. | *Up to Layer 4: Additionally all Layer 4 related modules are active such as TCP and Layer 4 server ports. | ||
* Unlimited: All Allegro Network Multimeter modules are active. | *Unlimited: All Allegro Network Multimeter modules are active. | ||
When switching to another mode you need to restart the processing in order to activate the new settings. | When switching to another mode you need to restart the processing in order to activate the new settings. | ||
| Line 63: | Line 90: | ||
NOTE: The data recorded to/stored in the Packet Ring buffer, will NOT be affected by any of the above settings. Packet ring buffer capture rules may be configured under "Generic - Packet Ring Buffer", further explained in our wiki here https://allegro-packets.com/wiki/Packet_ring_buffer#Packet_ring_buffer_snapshot_length_filter | NOTE: The data recorded to/stored in the Packet Ring buffer, will NOT be affected by any of the above settings. Packet ring buffer capture rules may be configured under "Generic - Packet Ring Buffer", further explained in our wiki here https://allegro-packets.com/wiki/Packet_ring_buffer#Packet_ring_buffer_snapshot_length_filter | ||
==== Enable single flow load balancing ==== | ====Enable single flow load balancing==== | ||
When the ''Limit module processing'' slider is turned to ''Only capturing'' the option to enable ''single flow load balancing'' appears. If this option is enabled, even a single flow is load-balanced to different analyzer threads. | When the ''Limit module processing'' slider is turned to ''Only capturing'' the option to enable ''single flow load balancing'' appears. If this option is enabled, even a single flow is load-balanced to different analyzer threads. | ||
This is only recommended when there are very few flows and there is an imbalance in the load of the analyzers. As the packets of a single flow are processed by different analyzers the packets of the flow may be stored out-of-order in the Packet Ring Buffer and a larger amount of memory may be required to reorder the packets when capturing from the Packet Ring Buffer (see [[Capture module#Configuration settings|Capture module]] configuration settings). | This is only recommended when there are very few flows and there is an imbalance in the load of the analyzers. As the packets of a single flow are processed by different analyzers the packets of the flow may be stored out-of-order in the Packet Ring Buffer and a larger amount of memory may be required to reorder the packets when capturing from the Packet Ring Buffer (see [[Capture module#Configuration settings|Capture module]] configuration settings). | ||
=== Graph detail settings === | ===Graph detail settings=== | ||
It is possible to modify the detail level of all graphs in the interface. This settings allow you to see a more detailed view (with higher time resolution) or to reduce the detail level so more data can be stored on the device. Changing the default values has an impact on the performance and memory usage. Changing a slider to the left increases the detail level of graphs, but increases memory usage and decreases performance. | It is possible to modify the detail level of all graphs in the interface. This settings allow you to see a more detailed view (with higher time resolution) or to reduce the detail level so more data can be stored on the device. Changing the default values has an impact on the performance and memory usage. Changing a slider to the left increases the detail level of graphs, but increases memory usage and decreases performance. | ||
* Best graph resolution: This option configures how detailed the graph information are shown in the best case (the latest information). The default value is one second which means that a graph sample point represents a second of packet time. You can change the resolution up to 1 millisecond which gives a detailed sub-second representation of the traffic. You can also decide to decrease the resolution which enables the Allegro Network Multimeter to store more data for a longer period of time. | *Best graph resolution: This option configures how detailed the graph information are shown in the best case (the latest information). The default value is one second which means that a graph sample point represents a second of packet time. You can change the resolution up to 1 millisecond which gives a detailed sub-second representation of the traffic. You can also decide to decrease the resolution which enables the Allegro Network Multimeter to store more data for a longer period of time. | ||
* Reduce graph resolution of old data by up to: The resolution of older graph data is automatically reduced to save memory and to allow a longer view into the traffic history. This option allows you to change this behaviour. With a reduction factor of 1/1 no reduction is done at all which means the selected graph resolution is available for the complete time. | *Reduce graph resolution of old data by up to: The resolution of older graph data is automatically reduced to save memory and to allow a longer view into the traffic history. This option allows you to change this behaviour. With a reduction factor of 1/1 no reduction is done at all which means the selected graph resolution is available for the complete time. | ||
:This reduces the time period to see historical data. You can choose to increase the reduction factor to store more data for a longer period. The time printed in parentheses represents the worst-case graph resolution based on the chosen resolution and reduction factor. The reduction is done in multiple steps up to this limit. The newest data always has the highest resolution defined by the "Best graph resolution" setting above. Between 60 and 120 data points are stored at a minimum, so with default resolution of 1 second, between one and two minutes are available in the highest resolution. Due to internal compression, the exact number of data points cannot be foreseen but 60 data points are always available at least, usually much more. Once the limit is reached, data is reduced by a factor of two thus doubling the amount of time available in half resolution (2 to 4 minutes in 2 second resolution). When the next limit is reached, the data is halved again thus doubling the time again, until the configured reduction limit is reached. With default settings of one second resolution and reduction limit of 1/6, the worst resolution of 64 seconds (or 1 minute and 4 seconds) is reached not before 2 hours into the past. The drop down menu in graph view gives an exact number about the available graph resolution in the given time period. | :This reduces the time period to see historical data. You can choose to increase the reduction factor to store more data for a longer period. The time printed in parentheses represents the worst-case graph resolution based on the chosen resolution and reduction factor. The reduction is done in multiple steps up to this limit. The newest data always has the highest resolution defined by the "Best graph resolution" setting above. Between 60 and 120 data points are stored at a minimum, so with default resolution of 1 second, between one and two minutes are available in the highest resolution. Due to internal compression, the exact number of data points cannot be foreseen but 60 data points are always available at least, usually much more. Once the limit is reached, data is reduced by a factor of two thus doubling the amount of time available in half resolution (2 to 4 minutes in 2 second resolution). When the next limit is reached, the data is halved again thus doubling the time again, until the configured reduction limit is reached. With default settings of one second resolution and reduction limit of 1/6, the worst resolution of 64 seconds (or 1 minute and 4 seconds) is reached not before 2 hours into the past. The drop down menu in graph view gives an exact number about the available graph resolution in the given time period. | ||
| Line 88: | Line 115: | ||
* 1 second resolution, 1/1 reduction factor: 90% of default performance | * 1 second resolution, 1/1 reduction factor: 90% of default performance | ||
* 100 millisecond resolution, 1/1 reduction factor: 50% of default performance, | *100 millisecond resolution, 1/1 reduction factor: 50% of default performance, | ||
* 10 millisecond resolution, 1/1 reduction factor: 15% of default performance | *10 millisecond resolution, 1/1 reduction factor: 15% of default performance | ||
* 1 millisecond resolution, 1/1 reduction factor: 10% of default performance | *1 millisecond resolution, 1/1 reduction factor: 10% of default performance | ||
=== PCAP parallel analysis === | === PCAP parallel analysis=== | ||
The PCAP parallel analysis feature allows to analyse PCAP files or the | The PCAP parallel analysis feature allows to analyse PCAP files or the | ||
| Line 101: | Line 128: | ||
described [[parallel packet processing|here]]. | described [[parallel packet processing|here]]. | ||
== IPFIX settings == | ==IPFIX settings == | ||
The Allegro Network Multimeter may be running as an IPFIX exporter. These settings allows for reporting configuration. When enabled, the following settings are possible: | The Allegro Network Multimeter may be running as an IPFIX exporter. These settings allows for reporting configuration. When enabled, the following settings are possible: | ||
* IP address: Address of IPFIX collector. | *IP address: Address of IPFIX collector. | ||
* Port: Corresponding port. | *Port: Corresponding port. | ||
* Protocol: TCP or UDP. | *Protocol: TCP or UDP. | ||
* Update interval: Interval in seconds for sending a status update of flows. | *Update interval: Interval in seconds for sending a status update of flows. | ||
* UDP resend interval: Interval in seconds for resending IPFIX templates for UDP connections. | *UDP resend interval: Interval in seconds for resending IPFIX templates for UDP connections. | ||
* TCP reconnect timeout: When TCP connections could not be established, wait for this time period until the next attempt to establish a connection. | * TCP reconnect timeout: When TCP connections could not be established, wait for this time period until the next attempt to establish a connection. | ||
Individual IPFIX messages can be enabled or disabled by toggling corresponding options. See the NetFlow/IPFIX interface documentation for details about the message types. | Individual IPFIX messages can be enabled or disabled by toggling corresponding options. See the NetFlow/IPFIX interface documentation for details about the message types. | ||
== Time settings == | ==Time settings== | ||
The Time settings were moved to [[Administration]]. | The Time settings were moved to [[Administration]]. | ||
==Email notification== | == Email notification== | ||
The Email notification settings were moved to [[Administration]]. | The Email notification settings were moved to [[Administration]]. | ||
| Line 126: | Line 153: | ||
See [[Memory extension]] for details about this beta feature. | See [[Memory extension]] for details about this beta feature. | ||
== DB persistance (BETA) == | ==DB persistance (BETA) == | ||
See [[DB persistence]] for details about this feature. | See [[DB persistence]] for details about this feature. | ||
== Longterm DB (BETA) == | ==Longterm DB (BETA)== | ||
See [[Longterm DB]] for details about this feature. | See [[Longterm DB]] for details about this feature. | ||
==Expert settings== | == Expert settings== | ||
The Expert settings contains parameter which are only necessary to change in rare installation scenarios or some specific need for a different operation mode. | The Expert settings contains parameter which are only necessary to change in rare installation scenarios or some specific need for a different operation mode. | ||
| Line 144: | Line 171: | ||
*Layer 2 with frame check sequence: Account packet length on Layer 2 with frame check sequence (4 Bytes) When switching to another mode, it will only be applied on new packets. Older packet size statistics will not be changed. | *Layer 2 with frame check sequence: Account packet length on Layer 2 with frame check sequence (4 Bytes) When switching to another mode, it will only be applied on new packets. Older packet size statistics will not be changed. | ||
=== VLAN handling === | ===VLAN handling === | ||
The Allegro Network Multimeter can '''ignore VLAN tags''' for connection tracking. Enabling this option may be necessary if network traffic is seen on the Allegro Network Multimeter that contains changing VLAN tags for the same connection. For example, depending on the configuration of the Mirror Port to which the Allegro Network Multimeter is connected, incoming traffic could contain a VLAN tag while outgoing traffic does not. In this example, a connection would appear twice in the statistics which often is desired behaviour to be able to identify a network misconfiguration. In some cases however, such "duplicate" data in the dashboard may be misleading, and the user would want to see only one connection. In these scenarios the option ignore VLAN tags may be enabled. | The Allegro Network Multimeter can '''ignore VLAN tags''' for connection tracking. Enabling this option may be necessary if network traffic is seen on the Allegro Network Multimeter that contains changing VLAN tags for the same connection. For example, depending on the configuration of the Mirror Port to which the Allegro Network Multimeter is connected, incoming traffic could contain a VLAN tag while outgoing traffic does not. In this example, a connection would appear twice in the statistics which often is desired behaviour to be able to identify a network misconfiguration. In some cases however, such "duplicate" data in the dashboard may be misleading, and the user would want to see only one connection. In these scenarios the option ignore VLAN tags may be enabled. | ||
| Line 155: | Line 182: | ||
* don't decapsulate traffic (default) | * don't decapsulate traffic (default) | ||
* decapsulate tunnel traffic, discard non-encapsulated traffic | *decapsulate tunnel traffic, discard non-encapsulated traffic | ||
* decapsulate tunnel traffic, process also non-encapsulated traffic | *decapsulate tunnel traffic, process also non-encapsulated traffic | ||
Optionally, a filter can be set to limit decapsulation on specific packets with a certain IP address, IP ranges or interfaces. If the filter is empty, all packets will be decapsulated. | Optionally, a filter can be set to limit decapsulation on specific packets with a certain IP address, IP ranges or interfaces. If the filter is empty, all packets will be decapsulated. | ||
| Line 164: | Line 191: | ||
When capturing, packets with complete outer Layer 2, Layer 3, GRE, ERSPAN, GENEVE, CAPWAP and L2TPv3 headers will be stored as seen on the wire. | When capturing, packets with complete outer Layer 2, Layer 3, GRE, ERSPAN, GENEVE, CAPWAP and L2TPv3 headers will be stored as seen on the wire. | ||
===Database mode settings === | ===Database mode settings=== | ||
The database mode is a special analysis mode for high-performance Allegro Network Multimeters with multiple processors to increase the performance on such systems. It is normally enabled automatically but depending on the actual network traffic and system usage, some parameter tweak might be necessary to improve overall system performance. | The database mode is a special analysis mode for high-performance Allegro Network Multimeters with multiple processors to increase the performance on such systems. It is normally enabled automatically but depending on the actual network traffic and system usage, some parameter tweak might be necessary to improve overall system performance. | ||
| Line 172: | Line 199: | ||
You can read more about the meaning of the settings [[DB mode|here]]. | You can read more about the meaning of the settings [[DB mode|here]]. | ||
===Network performance=== | ===Network performance === | ||
There are several network performance settings available to improve performance on high-performance systems in case of packet drops during very high incoming bandwidth. They are only visible if your Allegro Network Multimeter is capable of changing these settings. | There are several network performance settings available to improve performance on high-performance systems in case of packet drops during very high incoming bandwidth. They are only visible if your Allegro Network Multimeter is capable of changing these settings. | ||
| Line 186: | Line 213: | ||
Processing performance may be modified on high-performance systems. This is only visible if your Allegro Network Multimeter is capable of changing this setting. | Processing performance may be modified on high-performance systems. This is only visible if your Allegro Network Multimeter is capable of changing this setting. | ||
* Processing performance mode: This setting allows for fine tuning processing performance. By using '''Analysing''', as much processing ressources on all CPUs as possible are used for data analysis. By using '''Capturing''', the focus will be on high data throughput and low latency for capturing purposes by using only the CPU where the preferred network controller is attached to. This has an impact on data analysis performance. '''Analysing''' is used by default. | *Processing performance mode: This setting allows for fine tuning processing performance. By using '''Analysing''', as much processing ressources on all CPUs as possible are used for data analysis. By using '''Capturing''', the focus will be on high data throughput and low latency for capturing purposes by using only the CPU where the preferred network controller is attached to. This has an impact on data analysis performance. '''Analysing''' is used by default. | ||
You should only change this parameter in discussion with the Allegro Packets support department. | You should only change this parameter in discussion with the Allegro Packets support department. | ||
| Line 200: | Line 227: | ||
When the data retention timeout is set to a value greater than 0, data will be removed everywhere throughout the system after the given number of minutes. This means that entities like IPs, which have been inactive for longer than the timeout, will be removed. History graph data for entities that are still active will be truncated to cover only the given timespan, while the absolute values for the whole runtime will be retained. When a packet ring buffer is active, packets which are older than the timeout will be discarded. | When the data retention timeout is set to a value greater than 0, data will be removed everywhere throughout the system after the given number of minutes. This means that entities like IPs, which have been inactive for longer than the timeout, will be removed. History graph data for entities that are still active will be truncated to cover only the given timespan, while the absolute values for the whole runtime will be retained. When a packet ring buffer is active, packets which are older than the timeout will be discarded. | ||
===Multithreaded capture analysis=== | ===Multithreaded capture analysis === | ||
This option enables the use of multiple CPUs for capture analysis like when | This option enables the use of multiple CPUs for capture analysis like when | ||
| Line 235: | Line 262: | ||
This slider allows to configure the amount of memory which is used to buffer received packets. A larger amount of ingress packet memory may help in processing bursts of high bandwidth traffic without packet drops but it also decreases the amount of memory available for statistics. It is important to know that a restart of the processing does not suffice to make changes to this setting active. A full reboot of the device is required for that. See [[Performance Optimization Guide]]. | This slider allows to configure the amount of memory which is used to buffer received packets. A larger amount of ingress packet memory may help in processing bursts of high bandwidth traffic without packet drops but it also decreases the amount of memory available for statistics. It is important to know that a restart of the processing does not suffice to make changes to this setting active. A full reboot of the device is required for that. See [[Performance Optimization Guide]]. | ||
=== Jumbo frame mode === | ===Jumbo frame mode=== | ||
This options allows to set how jumbo frames are handled by the system. | This options allows to set how jumbo frames are handled by the system. | ||
Three settings are available and the '''normal''' mode, which is also the default, is the mode that was used before this configuration option was introduced: | Three settings are available and the '''normal''' mode, which is also the default, is the mode that was used before this configuration option was introduced: | ||
* '''Normal''': the default mode offers the best balance of full support for jumbo frames with an efficient usage of the ingress packet memory. This mode uses efficiently sized packet buffers and splits larger packets over multiple packet buffers. | *'''Normal''': the default mode offers the best balance of full support for jumbo frames with an efficient usage of the ingress packet memory. This mode uses efficiently sized packet buffers and splits larger packets over multiple packet buffers. | ||
* '''Large buffers''': this mode uses a single large buffer for each packet which may improve the performance but does not use the ingress packet memory as efficiently and limits the maximum jumbo frame size to 9kB. | *'''Large buffers''': this mode uses a single large buffer for each packet which may improve the performance but does not use the ingress packet memory as efficiently and limits the maximum jumbo frame size to 9kB. | ||
* '''Disabled''': this mode disables support for jumbo frames and offers the best performance and efficient usage of the ingress packet memory. Jumbo frames will be discarded by the network interface. | *'''Disabled''': this mode disables support for jumbo frames and offers the best performance and efficient usage of the ingress packet memory. Jumbo frames will be discarded by the network interface. | ||
=== Hardware packet timestamping === | ===Hardware packet timestamping=== | ||
This option allows to enable the use of high-precision hardware packet timestamps on supported interfaces (quad 25G and dual 100G expansion). | This option allows to enable the use of high-precision hardware packet timestamps on supported interfaces (quad 25G and dual 100G expansion). | ||
| Line 251: | Line 278: | ||
When enabled, packets received on supported interfaces will carry a timestamp with nanosecond resolution instead of microsecond resolution. | When enabled, packets received on supported interfaces will carry a timestamp with nanosecond resolution instead of microsecond resolution. | ||
=== External timestamps === | ===External timestamps=== | ||
When this option is enabled, the system will use timestamps contained in the packet data instead of timestamps measured at packet arrival. Currently the Arista and Ixia/Keysight as well as the SRCMAC timestamp formats are supported. | When this option is enabled, the system will use timestamps contained in the packet data instead of timestamps measured at packet arrival. Currently the Arista and Ixia/Keysight as well as the SRCMAC timestamp formats are supported. | ||
| Line 263: | Line 290: | ||
This feature can also be used in combination with the ''External timestamps'' option to support packets that contain a Ixia/Keysight trailer with both timestamp and original length information. | This feature can also be used in combination with the ''External timestamps'' option to support packets that contain a Ixia/Keysight trailer with both timestamp and original length information. | ||
=== Memory utilization limit === | ===Memory utilization limit=== | ||
This option allows to reduce the limit until old data is removed from the in-memory database. By default the system tries to target 90% memory utilization. In some case, the load might be too high to match this limit. A smaller limit may enable the system to keep the target memory utilization and perform better in general. | This option allows to reduce the limit until old data is removed from the in-memory database. By default the system tries to target 90% memory utilization. In some case, the load might be too high to match this limit. A smaller limit may enable the system to keep the target memory utilization and perform better in general. | ||