Flowmon Ads Business Userguide en 2

Flowmon ADS Business 8.02.
00
User Guide
October 25, 2016
Flowmon ADS Business 8.02.00
User Guide, October 25, 2016
Contents
1 Introduction 6
1.1 Features and capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Selected detection methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Basics of application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Distributed architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4.1 Architecture description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4.2 Node types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 Installation and configuration 11

2.1 Installing on probe/collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Quick configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Detailed configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.1 Data storage settings (Settings\Storage settings) . . . . . . . . . . . . . . . . . . 12
2.3.2 Application settings of the plug-in (Settings\Application settings) . . . . . . . . . 13
2.3.3 Configuration (Settings\Configuration) . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.4 Displaying configuration changes (Settings\Configuration changes) . . . . . . . 15
2.3.5 User Permissions (Settings\User Permissions) . . . . . . . . . . . . . . . . . . . . 15
2.3.6 Service names assignment (Settings\Named services) . . . . . . . . . . . . . . . 18
2.3.7 Querying LDAP settings (Settings\LDAP Settings) . . . . . . . . . . . . . . . . . . 18
2.3.8 Using own services to querying IP addresses (Settings\External IP services) . . 19
2.3.9 User interface configuration (Settings\User Preferences) . . . . . . . . . . . . . . 19
2.3.10 Configuration of Flow Data sources (Processing\Flow sources) . . . . . . . . . . 19
2.3.11 Configuring filters (Processing\Filters) . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.12 Configuration of detection methods (Processing\Methods) . . . . . . . . . . . . 24
2.3.13 Aggregation of events (Processing\Aggregation of events) . . . . . . . . . . . . . 24
2.3.14 Configuration of perspectives (Processing\Perspectives) . . . . . . . . . . . . . . 24
2.3.15 Configuration of categories of events (Processing\Event categories) . . . . . . . 25
2.3.16 Configuration of false positives (Processing\False positives) . . . . . . . . . . . . 25
2.3.17 Configuration of event reporting (Processing\Event reporting) . . . . . . . . . . 27
2.4 Distributed architecture configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4.1 Generating of encryption keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4.2 Configuring the architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3 Detection methods 33
3.1 Introduction to detection methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.1 Common configuration options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.2 Common features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
www.flowmon.com 2 / 102
3.1.3 Flow sources and assigned filters . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2 Common network behavior patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.1 ALIENDEV – New or alien device . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.2 BITTORRENT – BitTorrent traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.3 BLACKLIST – Communication with blacklisted hosts . . . . . . . . . . . . . . . . . 38
3.2.4 BPATTERNS – Flow-based behavior patterns . . . . . . . . . . . . . . . . . . . . . 40
3.2.5 COUNTRY – Behavior profiling – country reputation . . . . . . . . . . . . . . . . . 41
3.2.6 DHCPANOM – DHCP anomaly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2.7 DIRINET – Direct internet communication . . . . . . . . . . . . . . . . . . . . . . 43
3.2.8 DIVCOM – Target hosts/ports anomaly . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2.9 DNSANOMALY – DNS anomaly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2.10 REFLECTDOS – Amplificated DoS attack . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2.11 DOS – Denial of service attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2.12 HIGHTRANSF – High volume of transferred data . . . . . . . . . . . . . . . . . . . 48
3.2.13 HONEYPOT – Honeypot traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.2.14 HTTPDICT – Web form attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.2.15 ICGUARD – Internet connection utilization anomaly . . . . . . . . . . . . . . . . . 50
3.2.16 ICMPANOM – ICMP anomaly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2.17 IPV6TUNNEL – IPv6 tunneled traffic . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.2.18 INSTMSG – Instant messaging traffic . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.2.19 L3ANOMALY – L3 network anomaly . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.2.20 LATENCY – Network latency anomaly . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.2.21 MULTICAST – Multicast traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.2.22 NATDET – Network address translation . . . . . . . . . . . . . . . . . . . . . . . . 57
3.2.23 SMTPANOMALY – SMTP anomaly . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.2.24 PEERS – Partners communication anomaly . . . . . . . . . . . . . . . . . . . . . . 60
3.2.25 SCANS – Port scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.2.26 SRVNA – Service not available . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.2.27 TEAMVIEWER – TeamViewer traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.2.28 TELNET – Telnet anomaly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.2.29 TOR – TOR traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.2.30 UPLOAD – Data upload anomaly . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.2.31 VOIP – VoIP traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.2.32 VPN – VPN traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.2.33 WEBSHARE – Web sharing traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.3 Common behavior patterns for SIP traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.3.1 SIPFLOOD – SIP floods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.3.2 SIPSCAN – SIP scans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.3.3 SIPPROXY – SIP proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.4 Advanced network behavior patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

3.4.1 BROKENSEN – Broken sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.4.2 DNSQUERY – DNS query volume anomaly . . . . . . . . . . . . . . . . . . . . . . 72
3.4.3 RDPDICT – RDP attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.4.4 SSHDICT – SSH attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.5 Derived behavior patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.5.1 DNSREVERSE – DNS reverse records missing . . . . . . . . . . . . . . . . . . . . . 75
3.6 Anomaly detection system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.6.1 Basic principles of anomaly detection . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.6.2 Method parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3.7 General system procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.7.1 SYSCHECK – Data inconsistency . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.8 High level events, threat detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.8.1 Common configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.9 Threat detections – aggregations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
3.9.1 ACCESSATTACK – Network access attack . . . . . . . . . . . . . . . . . . . . . . . 80
3.9.2 DATALEAKS – Potential data leaks . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
3.9.3 DOSATTACK – Denial of service attack . . . . . . . . . . . . . . . . . . . . . . . . . 80
3.9.4 DNSTRAFFIC – DNS traffic anomaly . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.9.5 LARGETRANSFER – Large data transfer . . . . . . . . . . . . . . . . . . . . . . . . 81
3.9.6 MALWARE – Malware infected device . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.9.7 MISCONFIGURED – Misconfigured device . . . . . . . . . . . . . . . . . . . . . . . 82
3.9.8 NETANOMALY – Network anomaly . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.9.9 NETDISCOVERY – Network discovery . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.9.10 PROXYBYPASS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.9.11 SPAMMER – Potential e-mail spammer . . . . . . . . . . . . . . . . . . . . . . . . 83
3.9.12 SNIFFER – Potential network sniffer . . . . . . . . . . . . . . . . . . . . . . . . . . 84
3.9.13 SRVOUTAGE – Service outage or misconfiguration . . . . . . . . . . . . . . . . . . 84
3.9.14 UNDESIRED – Usage of undesired applications . . . . . . . . . . . . . . . . . . . 84
4 User interface 85
4.1 Basic controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.1.1 Main application menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.1.2 Status and information bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.1.3 Context menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.1.4 Search criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.2 Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.2.2 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4.3 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.3.1 Aggregated view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.3.2 Simple list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.3.3 By hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.3.4 Event details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.3.5 Interactive event visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.3.6 Event evidence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.4 Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.4.1 Chapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.4.2 Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.4.3 Default report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.4.4 Scheduling reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
1 Introduction
Flowmon ADS is a modern system for detection of anomalies and patterns of undesirable net-
work behavior, which is based on an analysis of data flows in the network (Flow). The main goal
of the solution is to increase external and internal security of a computer network. The main ad-
vantage over standard IDS systems lies in orientation on the overall behavior of the device on
a network, which enables to respond to yet unknown or specific threats for which the signature
is not available. Integrated dashboard displays a quick overview of the latest events and overall
statistics of events. This allows for immediate identification of problems or problematic devices in
the network.
User documentation is divided into the following chapters:
• Introduction –the first chapter, which aims to familiarize users with the features and capa-
bilities of the Flowmon ADS plug-in
• Installation and configuration – the second chapter designed for system administrators is
dedicated to the installation and detailed configuration of the plug-in
• Detection methods – the third chapter exactly specifies the features of the application, part
of the chapter describes the best practices and interpretation of results
• User interface – the fourth chapter is intended for ordinary user working with the application
• Contact information – a summary of contacts for the vendor and distributor of the plug-in
1.1 Features and capabilities

• Plug-in for Flowmon solution, easy to install on probe/collector
• Support for NetFlow v5/v9, for IPFIX and for IPv4 and IPv6
• Implementation of Bidirectional flows standard (RFC 5103)
• Building long-term behavioral profiles of devices on the network in terms of provided and
used services, traffic volumes and communication partners
• Predefined set of rules for detection of undesirable behavior patterns – operational issues,
attacks, unwanted services
• Predefined set of rules for detecting network anomalies such as behavior change of devices
on the network, discovering new network services, etc.
• A comprehensive dashboard with a direct indication of problems in the network
• Interactive visualization of events and relevant context in the form of directed graphs
• Complex filtering options and event prioritization linked to reporting and alerts
• Integration of tools for obtaining additional information (DNS, WHOIS)
• Support for adding custom information about IP addresses (name, role, username. . . )
• Automated outputs via e-mail, syslog, SNMP or custom scripts
• Remote traffic capture triggered by generated events
• Central user interface to use and manage more Flowmon ADS instances from single point
1.2 Selected detection methods

Detection of network anomalies:
• Anomaly detection system based on changes in the behavior profile
• Detection of heterogenous communication
• Detection of transmission of large volumes of data in the network
• Detection of service unavailability
• Detection of parasite device
Detection of remote management:
• Detection of Telnet protocol
• Detection of sharing desktop using TeamViewer
Detection of attacks:
• Detection of dictionary attacks on SSH services
• Denial of Service type attacks
• Detection of TCP scans
• Detection of outbound SPAM
Error checking at the configuration level:
• Detection of IP addresses without reverse DNS records
• Detection of delays on the network
Usage of unwanted services:
• Detection of Instant Messaging (ICQ, Jabber, MS Messenger, Google Talk, ...)
• Detection of BitTorrent P2P network
• Detection of different Voice-over-IP protocols
• Detection of different VPN connections and tunnels
• Detection of direct communication into the internet
1.3 Basics of application

Flowmon ADS is available as a standard plug-in for the Flowmon probe/collector. It is a web
application that uses modern scripting technology (Java Script and A JAX) and displays data through
Adobe Flash. The application is optimized for Firefox 31 and later, among the other supported
browsers are the latest versions of:
• Internet Explorer
• Opera
• Google Chrome
Figure 1: User interface preview
• Safari
User interface is divided into three main parts. In the upper part of the application is the status
and information bar, on the left shows the application main menu, which you can hide if neces-
sary. The remaining area of the user interface is the user’s desktop, where you see the information
and functionality combined under the currently selected item in the main application menu.
Another means of controlling the application is a context menu available by right clicking on
relevant object.
1.4 Distributed architecture
1.4.1 Architecture description
Distributed architecture can be used for load balancing of the processing to more devices. The
processing nodes are working separately and using only flows on the given node. It is necessary to
have whole context for given network segment on single node to provide the maximal precision.
Distributed architecture allows the central management and configuration. The same configuration
is applied on each node. The node is separate hardware or virtual Flowmon instance with Flowmon
ADS application. The encrypted communication between nodes uses the SSH protocol. There has
to be same Flowmon ADS license on each processing node.
1.4.2 Node types
Master The node to manage the whole architecture. It provides user interface, collect and
store the events from all Slave nodes and allows to configure all nodes. The Master node generates
and sends the PDF reports, reports the events via e-mail, triggers the custom scripts and traffic
captures. Master node has to have a network access to the IP addresses of all Slave nodes, or to the
IP address of Proxy node, if present. There has to be just one Master node in the architecture.
Proxy The node to transmiss the information between Slave and Master nodes. Proxy node
does not provide the web user interface neither process the data. The Proxy node has to have
network access to the IP addresses of the Master node and all the Slave nodes. There can be more
Proxy nodes in the architecture, but this type of node is not required.
Slave The node to process the data. It requires the license for the processing database. This
node does not provide the web user interface. The Slave node is used to report the events using
syslog and SNMP as well. The Slave node has to have network access to the IP address of the Proxy
node (to the Master node if there is none Proxy node in the architecture).
Proxyslave Slave node concurrently used as a Proxy node.
2 Installation and configuration
2.1 Installing on probe/collector

Flowmon ADS is a plug-in that can be run on the probe and the collector. Installation on probe/-
collector is carried out through Install/Update function found under Version tab in the Flow-
mon Configuration Center. More information on installing plug-ins can be found in the Flowmon
probe/collector documentation.
Installation process will automatically apply Common company configuration template con-
figuration template to the application. Common used detection methods and parameters will be
activated by this process. There is also prepared one Flow data source for the first monitoring
port on the probe. This Flow source must be activated manually. Information about Flow source
configuration is described in chapter 2.3.10 Configuration of Flow data sources.
The Flowmon ADS application can be installed only on Flowmon probe/collector (please see
release notes for proper version numbers). The license is part of united Flowmon license. The
license has to be loaded using Flowmon Configuration Center.
2.2 Quick configuration

The basic configuration of the plug-in consists of three steps:
1. Log into the plug-in –use the credentials used to log into Flowmon Configuration Center to
login. You can change your password and define other users through Flowmon Configura-
tion Center under System tab. More information on the management of user accounts can
be found in the Flowmon probe/collector documentation. The currently logged-in user can be
edited using the button with username in right upper corner.
2. Going through the configuration wizard – the welcome window with the link to configura-
tion wizard is shown after the first login into application (the wizard can be started using the
question mark icon from the Processing agenda as well).
The first step of the configuration wizard is applying the configuration template. The template
creates the basic IP range filters ans sets default values to the detection method parameters.
It is possible to extend the LAN filtr based on private IP ranges of the public IP addresses of
the monitored network segment, define specific devices in the network (e.g. DNS servers), set
the size of the monitored network and allow the use of external services (blacklist downloads)
in next steps. All set values are used for relevant detection method parameters.
3. Configuring the Flow data sources – in subsection Processing\Flow sources set up partic-
ular sources of Flow data that will be processed by the application. From the aspect of data
collection the applications works like a collector capable to receive data in the NetFlow v5/v9
format. For each source:
• Enter a unique Name

• Select the profile and the appropriate channels that should be used as an input.
• Set all data sources you want to use as active
2.3 Detailed configuration
2.3.1 Data storage settings (Settings\Storage settings)
In this section you can modify settings of the data storage.
Parameter Delete data after is used to set deleting old data. It is useful for archiving events
for later analysis. The value Never sets data lifetime to infinity while After default period sets the
default values (event – 183 days).
Number of days for which the data for the overview graph are being stored can be set by Days
to keep overview chart data parameter.
The Flowmon ADS allows to raise the performance using the SuperFast ™ mode. Using this op-
tion is recommended only for huge networks that generates more than 1000 flows per second. The
activation of the SuperFast ™ mode on smaller networks could cause the slowdown of the applica-
tion. It is necessary to limit the maximal amount of memory that can be used by the SuperFast ™
mode, too.
The Filter booster parameter is appropriate to activate if and only if there are some filters with
many IP ranges defined in the Flowmon ADS application (e.g. using wildcards). The activation can
cause lack of performance otherwise.
The Attach flows and Flow template parameters allows to activate saving the flow sample to
single events and the selection of fields to be saved. These samples can be attached to some types
of e-mail reports.
2.3.2 Application settings of the plug-in (Settings\Application

settings)
The admin user can lock some configurations (Reports, Settings\User preferences and Pro-
cessing\Event reporting) for non-admin users using the Lock configuration for non-admin
users option.
Access to external services (Internet services) might be allowed or denied using External ser-
vices option. If internet access is denied then geolocation services, whois service or detection
methods depending on external sources are unavailable. For details, see information on the vari-
ous detection methods.
The application uses all available CPUs. Parameter Maximal count of computational threads
allows limiting the number of CPU cores, which application can utilize.
The application allows resolving event source IP address immediately after event detection. This
function enables to determine the identity of the event source associated with a short IP address
using DHCP. IP addresses which should be resolved are defined by Capture source hostname.
2.3.3 Configuration (Settings\Configuration)
In the configuration section, functions for the management of device configuration are available.
All user data can be deleted anytime (Clean-up all data) or you can bring a device into the
factory setting (Reset to factory defaults), which also includes deleting all user data. User data
include all events. More information on managing the plug-in can be found in the Flowmon probe/-
collector documentation.
The application stores resolved DNS names for a short time period. It can be deleted using the
Clear DNS cache button.
To simplify the configuration of devices there are pre-defined templates for plug-in settings
available (Apply configuration template). Templates include configuration of Flow data filters,
individual detection techniques and perspectives setting. Application of template can be enforced
(Force), which means that the current setting which is in conflict with the selected template is
overwritten. There are currently following templates:
• Common company configuration template – template designed for small and medium-
sized organizations. Filter settings include commonly used private addresses (10.0.0.0/8,
172.16.0.0/12, 192.168.0.0/16). Activated detection methods and their settings correspond to
the typical security needs of small and medium sized organizations. Automatic anomaly de-
tection system is not activated network-wide; it must be activated afterwards on selected
portion of the network. Within the perspective settings the highest priority is given to events
that might indicate an attack or a serious breach of network security.
• Large company configuration template – template designed for large enterprises. Filter
settings include commonly used private addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Ac-
tivated detection methods and their settings correspond to the typical security needs of large
sized organizations. Automatic anomaly detection system is not activated network-wide; it
must be activated afterwards on selected portion of the network. Within the perspective set-
tings the highest priority is given to events that might indicate an attack or a serious breach
of network security.
• Internet service provider trunk template – template designed for large backbone net-
works. Filters are not part of the template. Activated detection methods and their settings
correspond to the typical security needs of ISP networks focused on massive attacks and
anomalies in the network.
It is possible to save current application configuration and restore if needed. Application con-
figuration is not portable between application versions. Configuration can be downloaded or up-
loaded back to the system using the Flowmon Configuration Center\System\Maintenance.
Figure 2: Configuration changes view
2.3.4 Displaying configuration changes (Settings\Configuration

changes)
Flowmon ADS allows to display configuration changes, that were done by individual users.
Changes are shown in a tree form and sorted by username and date when the change was made.
The changes could be searched using the search criteria filter.
2.3.5 User Permissions (Settings\User Permissions)
Flowmon ADS application allows admins to limit the data, that can be viewed by some non-
admin users. To limit the events, that can be shown to the given non-admin user, it is possible to
assign the perspective to each of these users. The user can view only the events, that are defined
in the perspective, and the method instance configuration appropriate to these events.
The perspectives can be defined using the simplified interface. It is enough to select the Flow
source, the IP address filter and to assign the priorities to the event types. The selected source and
filter is then assigned to each defined priority (the filter is assigned twice to each priority – once as
source filter and once as target filter).
User permissions conclusion
• User permissions for non-admin users
– Assigned filters
* User can see only filters assigned to him. He cannot edit them.
* Filter assigned to the user limits the content of displayed report chapters.
– Assigned perspectives
* User can see only perspectives assigned to him. He cannot edit them.
* User can see only the methods (and relevant events) that are defined by the perspec-
tives assigned to him.
* User can see only these e-mail reports, that are connected to perspectives assigned
to him.
* User can see only Flow sources connected to priorities in perspectives assigned to
him.
* Perspective assigned to the user limits the content of displayed report chapters.
* User without assigned perspective can see all Flow sources (including relevant events
and overview charts).
* User with assigned perspective with some priority defined as independent on Flow
source can see all Flow sources (including relevant overview charts, but events are
limited by the perspective).
• Hidden pages for non-admin users
– Settings \Storage settings

– Settings \Application settings
– Settings \Configuration
– Settings \Configuration changes
– Settings \LDAP settings
– Settings \EPO settings
– Processing \Event reporting: SNMP
– Processing \Event reporting: Syslog
– Processing \False positive
• Read-only pages for non-admin users
– Settings \User permissions (Only permissions assigned to him)

– Settings \Named services
– Settings \External IP services
– Processing \Flow sources (According the perspectives assigned to him)

– Processing \Filters (Only filters assigned to him)
– Processing \Methods (According the perspectives assigned to him)
– Processing \Aggregation of events (see below)
– Processing \Perspectives (Only perspectives assigned to him)
– Processing \Event categories
– Processing \Blacklists
• Settings, that can be changed by non-admin users
– Processing \Event reporting: E-mail reports (adding new reports for some perspective
assigned to him, viewing and editing reports owned by him)
– Processing \Event reporting: Custom scripts (adding new reports for some perspective
assigned to him, viewing and editing reports owned by him)
– Processing \Event reporting: Traffic recording (adding new captures for some per-
spective assigned to him, viewing and editing captures owned by him)
– Settings \User preferences
• Viewing and editing the reports by non-admin users
– User can see the report if he is the owner of the report, or the report is public and he can
see at least one of its chapters (the report is generated only with the allowed chapters).
– User can see the chapter (the chapter is allowed to him), if:
Events by priority The filter and perspective that are set have to have the non-empty
intersubsection with the filters and perspectives assigned to the user
Event matrix The filter and perspective that are set have to have the non-empty inter-
subsection with the filters and perspectives assigned to the user
Overall status The perspective that is set has to have the non-empty intersubsection
with the perspectives assigned to the user.
Events count by type The perspective that is set has to have the non-empty intersub-
section with the perspectives assigned to the user.
– User can create new reports from allowed chapters. He become the owner of the report.
– User can edit and delete the reports owned by him.
– User can define scheduled reporting on reports he can see.
– User can edit and delete the scheduled reports owned by him.
• Viewing the threats (since Flowmon ADS version 6.06) by non-admin users
– User can see the threats, that consist only from particular events, which can be seen by
the user according to the perspectives assigned to him.
– User can see only the threat methods configuration that are based on at least one de-
tection method, which can be seen by the user according to the perspectives assigned to
him.
• Universal facts
– Admin user can see even non-public reports of other users.

– Admin user can assign the owner to the reports and to the PDF reports.
– The change of the perspective has no influence on already existing events.
– The Lock configuration for non-admin users choice is locking the Settings \User pref-
erences, Processing \Event reporting and Reports settings.
2.3.6 Service names assignment (Settings\Named services)
In case, that there are services provided on unconventional ports in the monitored network, it
is appropriate to add this assignment (port number-service name) to the Named services list. This
assignment is used in event details of DOS and SRVNA detection method. If the assignment is
relevant only for some subnet, it is appropriate to use the IP address field or the Filter field to make
the assignment more specific.
2.3.7 Querying LDAP settings (Settings\LDAP Settings)
Flowmon ADS can be connected to the LDAP/Active Directory database. This connection could
be used to get additional information to IP addresses from monitored network. This information
can be get using IP tools from context menu over the given IP address.
It is necessary to properly configure the address of the LDAP/AD server, username and pass-
word used for authentication (it is necessary to upload the .pem certificate file of the certificate
authority that signs the servers certificate), search base, name of the field, that contains the IP
address and the specification if the server is Active Directory server or not.
2.3.8 Using own services to querying IP addresses (Set-

tings\External IP services)
It is possible to get additional info about IP addresses using any available web services. Defined
services can be invoked using context menu over an IP address. New tab on the current page is
opened after querying. The query is an URL address. In this URL should be used an $IP variable
that is replaced by the given IP address.
It is possible to use an $MAC instead of $IP variable. That web service can be applied on the MAC
address in the Event evidence view.
2.3.9 User interface configuration (Settings\User Preferences)
User can set own parameters of user interface. It is possible to turn on/off the showing the
welcome screen window and disabling the automatic load of the dashboard tables. Next, it is pos-
sible to hide the inactive methods from the search criteria filters. Each user can set the default scale
(logarithmic/linear) for the Dashboard:Overview view and the default Flow source and perspective
that will be used in search criteria.
2.3.10 Configuration of Flow Data sources (Processing\Flow

sources)
Flow data sources represent individual monitored points of the network and are one of the
licensing restrictions (number of simultaneously active Flow data sources). For each monitored
point of the network a Flow data source must be created in the plug-in. Configuration of data
source includes:
Name Unique data source name
Location Node of the distributed architecture to run the flow source. It should be set to localhost,
if the distributed architecture is turned off.
Profile Name of the profile which is used as an input.
Channels Channel selection which are used as input data for application.
Sampling rate Rate for sampling the input data.
Deduplicate If active, the uniqueness of the Flow received by one Flow source is guaranteed.
Check timestamps If active, the Flow with timestamp that differs more than 30 minutes from
system clock are deleted.
SIP processing The switch between the Flow data processing and processing of Flow data en-
hanced with the SIP entries. It is impossible to process both (Flow data with SIP entries and
Flow data without SIP entries) on the single Flow source together. Only the detection methods
with "SIP" prefix are used if the SIP processing is active.
State The current state of the Flow source.
Proxy active performs the replacement of two flows client-proxy and proxy-server by one flow
client-server. This correlation allows the functioning of some methods that would not be able
to detect events correctly in the network with proxy to work properly. Within the method
configuration it is possible to set up the tolerated data amount difference between the two
particular flows that have to be correlated (Tolerance) and the counts of milliseconds that
could take the flows outer the proxy longer (Request Overload, Response Overload). The
correlation has got high accuracy and coverage but it is not absolute.
The correlation of flows before and behind the proxy is possible only if the network is moni-
tored at two points – inside the network behind the proxy server and outside the proxy server.
It is necessary to set up the IP addresses of outer (External IP) and inner (Internal IP) inter-
faces and the proxy server’s listening port (Internal Port). For reducing false positives, the
proxy clients (Clients Filter) can be specified. It is possible to define more proxy servers for
each Flow source. The maximum count is limited by license.
Channels as virtual sources It is possible to activate so called Virtual sources for Flow sources.
These virtual sources are dedicated to isolate Flow data from individual channels of the input
profile. These virtual sources allows the channels to be assigned to the instances of detection
methods and to the priorities. Data from different channels are processed separately from
each other if active.
For example: An ISP can create virtual sources per ASN groups and analyse traffic anomalies
for every group separatelly. Just create new profile with channels for every ASN group, assign
the profile to ADS flow source, select all channels and activate virtual sources.
The Flow sources use (since the 6.04 version) directly the profiles on the collector (or on the built-in
collector of the probe), so it is not necessary to forward the data to next target. The Flow sources
can be used on any real profile, so the input data can be filtered on collector level. This leads to
decrease the load of the Flowmon ADS application. The Flowmon ADS Flow sources support the
NetFlow v5, v9 and the IPFIX protocol.
Details on configuring the exporters can be found in Flowmon probe documentation. The gran-
ularity of flows impacts the accuracy of detection methods. To reduce the number of flows that are
generated by the probe following values are appropriate:
• active timeout – 300 s
• inactive timeout – 30 s
2.3.11 Configuring filters (Processing\Filters)
Correct settings of Flow data sources and the logical network topology affects the results of the
detection methods and the overall plug-in predicative capability. The basic distinguishable entity in
the plug-in is the IP address. When the occurrence of an event is detected, the event is bound to
an IP address that caused it and to Flow data source on which the event has been detected. That
implies a number of limitations when IP addresses are dynamically allocated and stable allocation
of identical IP addresses to each network device is not guaranteed. In such case it is not possible
to derive a direct responsibility of particular user for the event detected in the network.
Filters are named logical groupings of arbitrary IP addresses. Each filter has a unique name,
can be linked to the defined Flow data sources and includes any number of IP address ranges.
Filters are also used by detection methods for limiting the range of the addresses relevant for each
detection method. Binding to Flow data sources can further reduce the processing of Flow data in
the detection method (see example later in this subsection).
The filters can be of two types – atomic (the Atomic tab) and relational (the Relations tab).
Atomic filters are such filters, that are defined and stored directly as an IP address ranges (see
below for possible formats). The relational filters are defined as relations over other filters (the
relation can be union/difference of more filters or inversion of the single filter and combinations).
Relational filters are stored just as a relation definition, in case the partial filter is changed, the
relevant relational filter is changed as well. See 2.3.11 for more details.
IP addresses for filters can be specified in the following ways:
• Network address/mask for the IP version 4 and 6 (e.g. 192.168.1.0/24, fc00::/7)
• Range of IP addresses for IP version 4 and 6 (e.g. 10.0.1.2-10.0.1.10, fe80::-fe80::ffff)
• Single IP address for IP version 4 and 6 (e.g. 192.168.2.1, 2001:db8::beef) or comma separated
list of single IP addresses
• Wildcards notation of IPv4 addresses (enumeration, range, all), only single wildcard can be
used in one IP address. Examples:
192.168.{1,3,20}.1 IP addresses 192.168.1.1, 192.168.3.1 and 192.168.20.1

10.[1-3].0.0 IP addresses 10.1.0.0, 10.2.0.0 and 10.3.0.0
172.16.*.1 Same as 172.16.[0-255].0
It is strongly recommended to activate the Filter booster parameter in the Settings\Storage if

there is a lot of IP ranges defined in some filter.
It is possible to use Import button and the Import filters tab for import filter definitions from
the text file. Format of the file is one filter definition per line where IP address definition is in the
first column, Name of the filter is in the second column. Columns are separated by semicolon. IP
address can be specified in the same ways as manual filter defining. If the name of the filter already
exists in the application, you will be noticed and the import fails.
If the checkbox Overwrite and skip problematic is checked then the IP ranges of the filters
with same name as in the uploaded file are overwritten by new ones that are given in the file. The
filter will be skipped if the relational filter would be overwritten.
192.168.1.0/24;LAN
192.168.10.0-192.168.10.25;LAN
192.168.1.1;SMTP
Figure 3: Example of filter definition file
It is possible to add own information from CSV text file by using Import IP information tab.
This additional information can be viewed using the IP detail containing data from whois and so
on. Remember, the import deletes all previous information! Following fields are supported:
• ip – IP address to which the information relates
• host – Domain name of IP address (max. 32 characters)
• username – Responsible user (max. 32 characters)
ip;host;role;username;os;hwconfig
192.168.1.1;stone.foo.com;LAN gateway;;CentOS 5.5;
192.168.1.33;pc33.foo.com;client-station;Johny;WindowsXP;VM
Figure 4: Example of the content of the file to import information about IP addresses
• os – Running operating system (max. 50 characters)
• hwconfig – Hardware description (max. 1000 characters)
• role – Role of devices on the network (max. 32 characters)
• notes – Additional notes (max. 1000 characters)
The text file consists of a header and records. The header contains of list of fields separated by
a semicolon. It must include required field ip and at least one optional (host, username, os, hw-
config, role, notes). Each record is on a single line. The fields are separated by a semicolon. Empty
lines are ignored. More records can be added to one IP address.
Information can be downloaded back by Export button.
Example of filter configuration – consider environment of an organization monitoring its net-

work at two points. The first point connected to probe port 1 and 2 is the Internet connection
behind a firewall, which is monitored via TAP. The second monitored point is a central switch of
the organization connected to the probe port 3 via SPAN port. In the Flowmon ADS plug-in we
define WAN data source representing the Internet connection and LAN data source representing
the central switch. We are going to export data from probe port 1 and 2 into the WAN source
and data from probe port 3 into the LAN source. Next, we create a filter LANout comprising ad-
dresses 192.168.1.0/24 and bind it to the WAN source and filter LANin comprising also the addresses
192.168.1.0/24 which we bind to the LAN source. We activate detection of instant messaging services
on the LANout filter, since this detection does not make sense for internal communication. If we
didn’t bind filters with Flow data sources, there would be duplication in the detection of Instant
Messaging (identical data would be processed twice independently).
The Relations tab can be used to define the relational filters. Adding new relation can be done
by Add new filter relation. The dialog window allows to define the relations as a filter union
(operation Add) or filter subtraction (operation Subtract). The operation can be combined with
inversion of the given filter. Using the Atomize option can be the created filter stored as the atomic
one (the IP address ranges are stored instead of the relation definition).
The relation filters can be edited, atomized or deleted using the relevant buttons. It is possible
to show the dependencies on given filter.
2.3.12 Configuration of detection methods (Processing\Methods)
Detection methods are predefined by the manufacturer and used to detect various potentially
undesirable activities on the network. Thus they build the core of Flowmon ADS plug-in. The
various methods are described in detail in the third chapter.
Part of the configuration is:
• activation/deactivation of a method
• assignment of filters to methods (any number of filters can be assigned)
• specific configuration (methods may have specific configuration parameters that can be set
or actions that can be performed)
Depending on the method nature some of the above options can be inactive. For example system
methods (e.g. event reporting) cannot be turned off nor assigned with filters. All configuration
changes will take effect immediately upon next batch of Flow data processing by given method.
2.3.13 Aggregation of events (Processing\Aggregation of events)
Aggregation of events merges some events into groups and allows to define patterns of larger
attacks which consist of several sub-events. Individual aggregations of events can be activated or
deactivate. Parameter Window sets maximum time in seconds between two separate events.
2.3.14 Configuration of perspectives (Processing\Perspectives)
In the Flowmon ADS plug-in you can create your own event perspectives that will assign events
with priorities according to their type, the network segment where they occurred (based on the
filter) and to the Flow source, that provides Flow data used for event detection. Priority can be
assigned to all sources by keeping default value NONE in the selection of the source. These per-
spectives can then be used when reporting events, alerting or searching in the application UI. Each
perspective is a uniquely named group of assigned priorities to events of given type (i.e. to events
generated by given detection method), and thus either network-wide or depending on the filter.
Flowmon ADS plug-in offers five event priorities:
• CRITICAL
• HIGH
• MEDIUM
• LOW
• INFORMATION
The predefined perspectives can be generated using the Create default perspectives button
(the icon with the star).
2.3.15 Configuration of categories of events (Processing\Event

categories)
In subsection Event categories you can define your own event categories into which you
can then assign events through Manage event categories context menu item. In this way you
can mark interesting events that should be further explored; marks can be used in subsequent
searches.
2.3.16 Configuration of false positives (Processing\False posi-

tives)
Detected events can be marked as false positives through Mark as false positive context menu
item. This mark means that the event of given type caused by given IP address will no longer be
reported. Validity of marking an event as false positive can be limited to individual days of the
week, time intervals and the Flow source. The validity of marking an event can be limited only to
the targets of the current event as well. If there is a limitation by the targets of the events, it is
possible to ignore the event source. The event source or event targets relevant to the rule can be
defined by filter as well. It is recommended to use these filters to define the restrictions based on
event source and event target IP addresses because of the limitations on the false positive number.
It is possible to send an e-mail about the false positive event to the Flowmon Networks com-
pany. The e-mail will consist from event details data, Flow entries that are related to the event,
application model and version and from the customer’s name. That data will be used to enhance
the performance of the application. The data will be processed in accordance with the law on
personal data protection.
The false positive rule can be defined by weekday choice. The events can be ignored during
the whole day or within the interval specified by the event time and by the radius of the interval in
minutes. The rule has to be connected to event source or to some (or all) event targets. It can be
set the validity and the comment to the rule.
It is possible to define the false positive rule without respect to the event on which was was this
dialog window opened. It is possible to manually choose the detection methods, enter the source
and target IP addresses and enter the time range. The rule is always created for each combination
of detection methods and source IP address, the targets are all assigned to each rule.
IP addresses can be entered as comma separated list. When entering the IPv4 address, one
of its fields can be written using wildcard. This wildcard can represent the numbers enumeration
(comma separated list enclosed in curly braces), range of two numbers (2 numbers separated by
dash enclosed in square brackets) or the asterisk that represents the 0-255 range.
Examples:
192.168.{1,7,100}.1 ] IP addresses 192.168.1.1, 192.168.7.1, 192.168.100.1
10.[1-3].0.0 IP addresses 10.1.0.0, 10.2.0.0, 10.3.0.0
172.16.*.1 Equivalent to 172.16.[0-255].0
It is possible to delete all events corresponding to the false positive rule using the Delete false
positive events choice. This option is disabled if there is chosen some Flow source, some specific
targets (no matter what way), more event types or the event sources are defined by some filter.
Removal of rules for false positives marking is done in the Processing\False positives subsec-
tion. Removal of selected rules can be done through Delete selected.
It is possible to edit the comments of the false positives in this subsection, too.
2.3.17 Configuration of event reporting (Processing\Event re-

porting)
E-mail reports
Flowmon ADS plug-in allows you to define regular reports which will be sent via e-mail by the
application.
Each e-mail report must be uniquely named and bound to just one perspective. A report has
active/inactive state. The inactive report is defined in the system but not sent regularly. The report
can be assigned with any number of recipient addresses by Add new mail. There is also an option
to suppress sending of an empty report (Prevent empty report – only daily and weekly reports can
be sent empty, if disabled) and option to set minimum priority of events to be reported (Minimal
priority to report). Reports are sent according to the following rules:
• CRITICAL – reporting immediately after the batch processing of Flow data, approximately
every 5 minutes, a blank report is never sent.
• HIGH – reporting hourly summaries1
• MEDIUM – reporting six hour summaries1
• LOW – reporting daily summaries1
• INFORMATION – reporting weekly summaries1
You can use the Same events gap parameter to suppress repetitive sending the same event in
the given report for the chosen time period. The events with same event type and event source are
considered as a same. Only one same event is reported in the long-term report (reports for priority
HIGH or lower) if set to non-zero value.
The Flowmon ADS application allows to sending e-mail reports in few formats.
1
Batch of e-mails in case the Mail per event format is used.
Summary reports The Full format sends the reports as a table formatted by HTML, the Com-
pact format sends the reports in plain text, the Extra compact format is also in plain text, but there
are some omitted information (e.g. event detail, event targets etc.) and the report is aggregated
with respect to the event code. All three types are summary reports. It reports all events for specific
time period and priority at once. The time period corresponds to priority rules above).
Separate event reports The Mail per event format sends in one e-mail only information
about single event and it is dedicated especially for automatic processing. It can generate a huge
number of e-mail reports (equal to count of evens). The number can be reduced using Same events
gap feature for filtering same events during the given time period. As other formats, the e-mail
event reports are sent according to priority rules above.
<ID>: (unique event identifier);

<Category>: (code of the detection method);
<Type>: (name of the detection method);
<Perspective>: (name of the perspective assigned to the report);
<Severity>: (priority of the event);
<Time>: (start time in UTC);
<Protocol>: (protocol related to the event or empty value);
<Source>: (source IP address);
<Target IPs>: (first 10 target IP addresses);
<Ports involved>: (port numbers related to the event or empty value);
Figure 5: Body of the Mail per event format
The RT e-mail format It is possible to send reports as a tickets to the ticketing systems. Nowa-
days, the RT ticketing system is supported. The format has to be set to RT value. This format
is adding three attributes into the e-mail header: X-RT-Tool-Name, X-RT-Incident-IP and X-RT-
Incident-Time. The first attribute is always set to the “Flowmon ADS - ” string concatenated with
the name of the event, the others have assigned their values with respect to the reported events.
There are all events with given type related to the one IP in the single e-mail/ticket for given time
period. The time period corresponds to priority rules above. The first event from the row is used
as a leader event. All corresponding events are listed in the Incident details.
If the Attach flows parameter in Storage settings section is activated, the Flow samples used
for event detection are attached to RT and Mail per event formatted reports.
It is possible to send reports using your own SMS gateway. Please contact the vendor, company
Flowmon Networks, a.s., in case you want to use this possibility.
IP: 192.168.1.1 // event source

Type: DNS traffic anomaly // detection method description
Severity: Use of unauthorized DNS server (connections: 20). // leader event detail
Time: 2015-11-05 17:00:13 GMT+0100 // leader event timestamp
Incident details: // event id, timestamp, detail, targets

5102353 2015-11-05 17:00:13 GMT+0100 Use of ... (connections: 20). 8.8.8.8
5102382 2015-11-05 17:00:13 GMT+0100 Use of ... (connections: 20). 8.8.8.8
Figure 6: Body of the RT e-mail, the event details were shortened
Syslog
Application also supports event export in the Common Event Format (CEF) to the remote syslog
which can be configured in Event reporting subsection. The target syslog has to be configured
in the Flowmon Configuration Center. All events are exported according to selected perspective,
according to this perspective they may be assigned with a specific level (CRITICAL priority fits to the
alert severity). It is possible to extend the syslog message with the field that contains the unique
identifier of the event by setting the parameter EventId to the value “yes”. It is possible to activate
sending one syslog message for each event target (Divide by targets parameter). The count of
messages for single event is limited by the value of Max messages for one event parameter. The
last message for the given event contains the list of the remaining targets. Syslog messages are
sent using the daemon facility. If the Machine readable syslog parameter is active, the list of
tuples parameter:value is used as a format of the event detail for better parsing.
SNMP
Application supports exporting events using SNMP too. Events are generated as a SNMP traps
that are generated based on MIB file FLOWMON-ADS-MIB.txt (this file can be downloaded from the
authenticated subsection of www.flowmon.com pages). Except for the SNMP traps that report the
events there are also generated the SNMP traps of the number of processed flows per a batch and
of the time necessary for processing of the batch. It is necessary to configure the IP address and
the port number of the device, that is dedicated to receive the traps. Then it is required to choose
the perspective.
Custom scripts
The Flowmon ADS application allows to use own custom scripts for exporting the events (actually,
it can be any executable – e.g. in bash/sh, perl, python C, C++, . . . ). The script functions are lim-
ited only by the permissions given to the flowmon system user (this user is used for running the
executables). It is recommended to validate the executables by an administrator because of this.
The user scripts can affect the duration of the Flow data processing, therefore it is recommended
to make these scripts fast enough.
Launching of the custom scripts is driven by chosen perspective and minimal priority. The
scripts are launched immediately regardless the priority of the given event. Launching the scripts
for the same event can be suppressed for given time period.
The executables can be uploaded by the admin user using the Settings\Custom scripts view. Two
types of the scripts are defined – the script can process only single event (and is launched for each
event, the Call per event option, the count of launches per priority and flow source is limited by
the Limit) or the script can process all events with the same priority at once (launched up to five
times, the Call per priority option). The events are passed to standard input of the script (one
event per line).
Each event is described by following fields (in this order):
• ID
• event timestamp
• timestamp of the first flow
• event type
• type description
• perspective
• priority
• event detail
• port numbers
• protocol
• event source
• captured source name
• event targets
• Flow source
• user identity
These fields are separated by a tab character. The empty field is replaced by a space character.
Additional parameters It is possible to define additional command line parameters for cus-
tom scripts. These parameters are used for passing suplementary information. The values of the
parameters can be set separately for single usages of the custom scripts. The parameters are op-
tional and have to be supported by the script. Parameters are passed as follows: ./script_name.sh
PARAM_1 ’VAL_1’ PARAM_2 ’VAL_2’ ... PARAM_n ’VAL_n’
The name of the parametru has to be nonempty, it can consist of alphanumerich characters,
dash or underscore. The parameters are passed every time in the same order, it is possible to
reference them by a position number.
Demo script The demo script is created after installation or after apply of the configuration
template. This script is used for sending event reports by e-mails. The script can be generated
on the page Settings\Custom scripts manually as well. It can be downloaded to read the code. It is
written as a Bash script. It can be used for Call per event even for Call per priority. The script is
using three parameters for passing e-mail address, e-mail body and e-mail subject. The parameters
are parsed using standard getopt function. E-mail reports are sent by Flowmon PHP CLI, the SMTP
configuration is get from the application configuration.
Traffic recording
It is possible to start automatic packet capture using the Flowmon Traffic Recorder (FTR, version
4.09.0 or higher is required) as a reaction to the generated events. The capture can be started on
remote device as well. Launching the capture is driven by the chosen perspective. The captures
are launched immediately for all events that are at least of the minimal priority. The number of
launched captures per priority and flow source is limited by the Limit parameter. PCAP files con-
taining captured traffic will be available using the detail view of relevant events. The capture is
stored for the time window defined by the Interception duration parameter.
2.4 Distributed architecture configuration

It is necessary to have at least 1 Master node and 1 Slave node to make the distributed architec-
ture work properly (see 1.4).
The access to Flowmon device terminal is necessary to configure the distributed architecture.
The configuration requires advanced knowledge of UNIX-like systems. We recommend to contact
the Flowmon Networks support for configuration of the distributed architecture.
2.4.1 Generating of encryption keys
It is needed to set the SSH encryption keys on single nodes of the distributed architecture. The
key pair can be generated using ssh-keygen.
$ ssh-keygen -N "" -f /data/ads/tmp/auth.key

Generating public/private rsa key pair.
Your identification has been saved in /data/ads/tmp/auth.key.
Your public key has been saved in /data/ads/tmp/auth.key.pub.
The key fingerprint is:
XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX flowmon@testmachine
The generated private key has to be added to each node (e.g. using scp application). The files
has to have set permissions correctly:
chmod 0600 /data/ads/tmp/auth.key

chown flowmon:flowmon /data/ads/tmp/auth.key
The generated public key has to be added on each node to authorized keys of flowmon user:
cat /data/ads/tmp/auth.key.pub >> /home/flowmon/.ssh/authorized_keys

chmod 600 /home/flowmon/.ssh/authorized_keys
chown flowmon:flowmon /home/flowmon/.ssh/authorized_keys
2.4.2 Configuring the architecture
Each node has to be configured separately using the /data/ads/KADS.cfg configuration file. If the
file is not present in the system or if each line in the file is commented, the distributed architecture
is turned off. Documentation of the config file is given in the file itself using the comment strings.
3 Detection methods
Detection methods are the core of Flowmon ADS . They serve for detecting various potentially
undesirable activities on the network or to cumulate appropriate information (behavior profiles).
Detection methods are predefined by the manufacturer who guarantees their development and
expansion according to the current trends in the area of network services and security of computer
networks in particular. Detection methods can be imagined like signatures for IDS systems (e.g.
SNORT). Unlike signatures which represent particular strings to be searched in individual packets,
detection methods contain specific behavior patterns of network devices. Flowmon ADS uses the
principle of detection methods also for other tasks (e.g. event reporting etc).
Detection methods are divided into the following groups:
• Common network behavior patterns – common network behavior patterns that generate
events always when processing the current batch of Flow data (typically every 5 minutes).
• Common behavior patterns for SIP traffic – common behavior patterns that are based on
SIP extensions. These methods works only with Flow sources with activated SIP processing.
• Advanced network behavior patterns – advanced network behavior patterns that detect
long term trends in network behavior based on continuous processing of Flow data.
• Derived behavior patterns – derived behavior patterns that generate characteristics of indi-
vidual devices. They do not directly depend on processing of the Flow data. Typically they use
the outputs of the above two detection method groups and are run periodically (every hour).
• Anomaly detection system – methods of general anomaly detection system based on

changes in the behavior of network devices.
A typical duty cycle of the Flowmon ADS application includes performing of following steps:
1. Receiving and storage of Flow data – receiving of Flow data batch representing the actual
network traffic, typically every 5 minutes.
2. Processing of Flow data batch – application of all active detection methods on given Flow
data batch which results in events generation and event reporting. Applications leverages
multi-threading to increase overall processing throughput.
Independently of the Flow data processing the application performs regularly every hour active
detection methods from General system procedures and Derived behavior patterns groups.
3.1 Introduction to detection methods

All detection methods have many common features and they are configured via uniform user
interface. The remaining text of this subsection is devoted to description of individual detection
methods in terms of the principle of their operation, their configuration and interpretation of their
results, which is typically based on practical experience with detection methods. Information on
the detection method always includes a general description, tips for method configuration. For
detection methods from the groups Common network behavior patterns, Advanced network
behavior patterns, Common behavior patterns for SIP traffic, Derived behavior patterns
or Anomaly detection system it also contains instructions for interpretation of results.
3.1.1 Common configuration options
It is possible to create so called instances of the detection methods. Each instance represents
specific settings of the detection method and it should be connected to some Flow sources. The
count of instances is limited by the maximal number of Flow sources for each detection method.
Two types of actions are available for method settings – actions performed collectively on whole
group of instances and actions performed on single method instances.
Actions for group of instances
• Method instance/instance group activation/deactivation – each method, except for the

system ones, can be activated or deactivated (Activate/Deactivate). This option is reflected
immediately, precisely when processing the next batch of Flow data.
• Method instance configuration/method configuration template edit – specific configura-

tion of detection methods is available through function Edit method.
• Adding new method instance – it creates new method instance with configuration along the
method configuration template. It is necessary to assign the method instance to some Flow
sources (New instance).
• Setting the time to store outputs – it sets the time period within which are the outputs of
the detection method stored in the system (Set Delete after parameter).
Actions for single method instances These actions are available in addition to events corre-
sponding to actions available for templates:
• Delete method instance – it removes the given method instance (Delete method instance).
• Perform action – some methods allows to call actions that are related with the given method.
This action could be for example deleting the learned classifier. The action is performed after
clicking the Perform action button.
• Activate/Deactivate method instance – activates or deactivates the given method instance.
• Edit method instance – allows to configure the given method instance
• Assigning filters to the method instance – most methods may be restricted in terms of pro-
cessed traffic by assigning filters to them (Assign filters). This setting is reflected immediately,
precisely when processing the next batch of Flow data.
3.1.2 Common features

• Event generating – most detection methods generate events. Events always include event
originator (IP address), event type (corresponding to a type of the method which detected
the event), the time stamp of event occurrence according to Flow data, link to the Flow data
source, event details (additional information on the event according to its type) and the list of
all event targets (IP addresses).
• Periodic deletion of events – all detection methods which generate events offer their peri-
odic deletion through a configuration option DeleteEventsAfter indicating the number of
days for which the events remain in application memory. Older events are automatically
deleted. When the option is set to value “0” events are never deleted.
3.1.3 Flow sources and assigned filters

• The method instance has to be assigned to at least one Flow source. Assigned filters are
optional except some detection methods.
• The method instance is always processing only the data from assigned Flow sources.
• Data from single Flow source are processed isolated, the classifiers based on these data are
also kept separately for each Flow source and each method instance.
• The assigned IP address filter restricts the data according the source or destination IP ad-
dresses (details follow).
• There is no need to use the IP filter, if all data from the current Flow source satisfies this filter.
• It is better not to use any filter instead of using the filter with all IP addresses.
• Some of detection methods needs assigned filter because of performance.
3.2 Common network behavior patterns
3.2.1 ALIENDEV – New or alien device

Method description A method for detecting parasite device in monitored network. There are two
ways used to detect parasite devices.
Within the configuration of the first one it is necessary to set the filter that exactly corresponds
to the IP addresses assigned to specific network devices (KnownSegment parameter) and
the filter (LANFilter parameter), that is corresponding to the whole used network segment
(including addresses that can be assigned by the DHCP server). If the KnownSegment pa-
rameter is empty, this way of detection is not used.
The other way of detection is using simple machine learning methods. It is necessary to
set the LANFilter parameter that defines whole network segment (including the gaps). The
ClosedSeason parameter determines how long should be the method in the learning phase
(the events are not generated). If the new device occur after learning phase, the event is
generated. The device is removed from the classifier after TimeToDeath days of inactivity.
The second way of detection is also applicable on the MAC addresses that appears on the lo-
cal network. The MAC address based detection configuration is separated from the IP address
based detection configuration, but the ClosedSeasonMAC and TimeToDeathMAC parame-

ters are applicable in the same way. The detection is performed only over the Flows, their’s
source IP addresses fit into the filter assigned to the detection method. It is necessary to re-
alize that the MAC addresses are available only for the devices in the subnet limited by the
closest router. The autoconfiguration link-local IPv6 address with embedded MAC address is
used as a event source. Each IP address, that was assigned to the device with the given MAC
address in the processed five-minute batch is displayed as a event target (these addresses are
limited by the filter assigned to the detection method).
Method configuration It is appropriate to activate this method network-wide for all traffic on the
network. Appropriate place for monitoring the traffic is the central switch.
Method parameters
LANFilter Name of the filter that defines the IP addresses used for devices inside the moni-
tored network.
ClosedSeason Count of days dedicated only for training the classifier based on IP addresses
of the devices. No events are generated during this time. If the value of the parameter is
equal to 0, the detection using the automatic classifier is disabled.
TimeToDeath Count of days during which is the inactive IP address stored in the list of the
classifier.
KnownSegment Name of the filter that defines just the IP addresses of the active devices in
the monitored network.
ClosedSeasonMAC Count of days dedicated only for training the classifier based on MAC
addresses of the devices. No events are generated during this time. If the value of the
parameter is equal to 0, the detection using the automatic classifier is disabled.
TimeToDeathMAC Count of days during which is the inactive MAC address stored in the list
of the classifier.
Assigned filter Filter is used for restricting source IP addresses.
Interpretation of results This method is able to detect unknown (or forgotten) devices that are
connected to the monitored network.
3.2.2 BITTORRENT – BitTorrent traffic

Method description A method for detecting P2P networks of the BitTorrent type. This method
consists of four different detection methods that analyze network traffic concurrently. The
incidents detected by individual methods are compared. The event is generated in case of de-
tecting Bittorrent traffic by multiple methods. The option MinimalProbability allows you to
set the minimum number of methods, that have to detect the incident, in the form of percent-
ages. In this way, it is possible to detect almost any Bittorrent clients. Parameter LANFilter
enables the reduction of possible false positive by excluding internal network communication
from detection. Next parameters are MinSeeds and MinHighPorts allowing to set minimal
count of remote peer sources, where data are downloaded from, and minimal count of con-
nections on ports higher than 10240.
network regardless of IP addresses excluded from communications on the LAN by the option
LANFilter. Appropriate place for monitoring the traffic is the Internet connection line.
Method parameters
LANFilter Name of the filter that defines the IP addresses in the monitored network. The
communication among these devices is ignored within this detection method for the
improvement of false positive ratio.
MinSeeds Minimal count of devices used as a source for the file download.
MinHighPorts Minimal count of connections on the ports greater than 10240.
MinimalProbability The probability of downloading using the BitTorrent service is evaluated
during the detection. The evaluation is based on the results of partial methods. The
parameter expresses the minimal probability to report the event.
Interpretation of results This method achieves very reliable results in detection of notorious P2P
downloaders. On the other hand, incidental and occasional use of P2P network may not be
detected, especially when strict mode is set on. Furthermore, this method may alert to spy-
ware infected devices, whose symptoms are often similar to the symptoms of P2P networks.
3.2.3 BLACKLIST – Communication with blacklisted hosts

Method description A method for detecting communication with IP addresses which are included
in the blacklist collected by Flowmon Networks a.s. Typically they are the control centers of
botnets or world-renowned attackers. The list of IP addresses is periodically updated (every
8 hours), if the method is active. Within the method configuration you can set up monitor-
ing of selected types of blacklists (BotnetActivities, SpammerActivities, AttackerActivities
a MalwareActivities). Parameter IgnoreUnreachable allows ignoring ICMP type 3 (destina-

tion unreachable) replies to request from blacklisted IPs. If the parameter IgnoreUnsuccExt
(or IgnoreUnsuccInt) is set to “yes”, the unsuccessful attempts from blacklisted IP addresses
are ignored (or from monitored network).
For Flowmon ADS application with active Gold Support are available the premium blacklists
as well. The P2P botnet supernodes blacklist (P2PBotnetActivities parametr) contains IP ad-
dresses and port numbers of supernodes of P2P botnet networks (e.g. ZeroAccess, Sality). The
Known phishing web domains blacklist (PhishingDomains parameter) contains the database
of HTTP URLs, on which are provided phishing web presentations. The Known botnet c&c do-
mains blacklist (BotnetDomains parameter) contains the database of HTTP hostnames, that
are used for communication of some botnets (e.g. ZeuS Gameover, Conficker B).
The method allows the user to define own blacklist. The blacklist can contain only the list of
IPv4 addresses. There should be only one IP address per line in the list. It is allowed to use
only the <pre>and </pre> tags except the IP addresses and the newline character.
network regardless of IP addresses. Appropriate place for monitoring the traffic is the Inter-
net connection line. To update the list of IP addresses correctly it is necessary not to block
the communication of the device (probe/collector) to port 443 (HTTPS, standard secured web
traffic) on services.invea.com server.
Parametry metody
BotnetActivities Activate the blacklist containing IP addresses known as botnet command

and control centers.
SpammerActivities Activate the blacklist containing IP addresses known as spam senders.
AttackerActivities Activate the blacklist containing IP addresses known as attackers.
MalwareActivities Activate the blacklist containing IP addresses known as malware sources.
CustomListServer The address of the server, that can be used for downloading custom
blacklist.
CustomListLocation The path to the custom blacklist on the CustomListServer
CustomListDescription The description of the custom blacklist (this description is used in
the event detail).
IgnoreUnreachable Ignore the ICMP type 3 responses (destination unreachable) to requests
from blacklisted IP addresses.
IgnoreUnsuccExt Ignore unsuccessful requests from blacklisted IP addresses.
IgnoreUnsuccInt Ignore unsuccessful requests from IP addresses from the monitored seg-
ment.
P2PBotnetActivities Activate the premium blacklist to detect communication to the P2P bot-
net supernodes.
PhishingDomains Activate the premium blacklist to detect HTTP requests to phishing web-
domains.
BotnetDomains Activate the premium blacklist to detect HTTP requests to domains used for
botnet communication.
IgnorePorts List of ports, that will be ignored in the detection.
Assigned filter Filter is used for restricting source or destination IP addresses.
Interpretation of results This method uses the Flowmon Network blacklist service. If some of the
blacklisted IP addresses are marked as the event originator it’s probably a network attack on
the organization. If some of the organization IP addresses is the event originator it’s likely to
be part of botnet or infected with some form of malware.
3.2.4 BPATTERNS – Flow-based behavior patterns

Method description This detection method is designed to unveil current threats such as zero-day
vulnerabilities etc. The behavior patterns are distributed from the services.invea.com server.
Downloading and performing these patterns is allowed only for devices with active Gold sup-
port. The list of the behavior patterns (including timestamps of last modification) is down-
loaded from the server each hour. The single behavior pattern is downloaded only if there is
a newer version on the server.
Each behavior pattern can be deactivated for the detection using relevant configuration pa-
rameters. Some patterns can provide other configuration parameters for setting the detec-
tion.
Method configuration It is appropriate to activate this method for whole communication of IP

addresses in monitored network. To update the behavior patterns correctly it is necessary
not to block the communication of the device (probe/collector) to port 443 (HTTPS, standard
secured web traffic) on services.invea.com server.
Method parameters The parameters of this detection method are relevant to particular behavior
patterns which are downloaded from the services.invea.com. These parameters can vary in
time.
Assigned filter Filter is used for restricting source or destination IP addresses (this can differ based
on given behavior pattern).
Interpretation of results This method uses the behavior pattern database, interpretation of each
pattern can differ.
3.2.5 COUNTRY – Behavior profiling – country reputation

Method description This method determines the daily country of communication peers for each
of monitored device. It stores count of flows and amount of transferred data between country
and monitored devices. The traffic statistics are divided according to whether the communi-
cation was initialized by IP address from out of monitored network (reply) or by IP address
from monitored network (request).
This method also allows to detect too big data transfers between the device and the given
country. Within the detection is monitored the amount of sent or received data or ratio be-
tween upload and download related to the given country. All values are compared to the
average of other devices in the monitored network, that are communicating with given coun-
try.
This detection is allowed after setting the GenerateEvents parameter to “yes”. Into the detec-
tion are included only these IP addresses that have sent to the given country more data than
is defined by the MinimalTransferredU parameter or downloaded more data than is defined
by the MinimalTransferredD parameter. The event is generated if the traffic is bigger than
the n-multilple of the network average, where the n is defined by the MinQuota parameter.
The event can be also generated if the upload/download rate of the device is bigger than m-
multiple of the network average, where the m is the value of the RatioQuota parameter. If
this parameter is zero, the rate comparison is not applied.
Method configuration It is appropriate to activate this method for IP addresses of an organiza-

tion. Appropriate place for monitoring the traffic is the central switch or the to/from Internet
connection line, but not both places at the same time.
Method parameters
MinimalTransferDataU The threshold for minimal data amount sent by single IP address to
one country (in MiB).
MinimalTransferDataD The threshold for minimal data amount received by single IP ad-
dress from one country (in MiB).
MinQuota Minimal ratio between the received or sent data by single IP address and the
relevant average value of the whole monitored network.
RatioQuota The threshold for the ratio between the sent to received rate of the single IP IP
address and the average value of the whole monitored network.
ExcludeCountries The communication with chosen countries is ignored within this detection
method.
Interpretation of results The results of this method can be used to identify IP addresses commu-
nicating with the potentially dangerous country destinations.
3.2.6 DHCPANOM – DHCP anomaly

Method description Detection method identifies suspicious communication in DHCP traffic. The
method is able to highlight the increased DHCP network traffic. It monitors the long-term
behavior of a node in the network and compares the current data transfer to historical statis-
tics for the node and also global statistics for the network. Additionally, it can detect fake
DHCP servers by observing UDP traffic from servers (port 67) towards clients (port 68) from
addresses that are not specified by filter as legitimate DHCP servers.
Using the parameter TimeWindow you can set the time window (in hours) for collecting and
processing long-term statistics. Filter DHCPServers defines DHCP servers that are used in the
network, it is necessary for proper detection of bogus DHCP servers. Parameter DHCPThresh-
old specifies the maximum allowed increase of observed DHCP traffic. The parameter Traf-
ficSizeThreshold is used to set the minimal amount of DHCP traffic for an individual IP ad-
dress to be considered as the flood attack. The detection of fake DHCP servers can be en-
abled by the parameter FakeDHCPDetEnabled. It is possible to exclude communication of
DHCP servers from detection of anomalously increased DHCP traffic (servers defined by filter
DHCPServers).
network regardless of IP addresses and additionaly set a filter defining DHCP servers. Appro-
priate place for monitoring the traffic is the central switch.
Method parameters
DHCPServers The name of the filter that defines IP addresses of the DHCP servers used in
the monitored network.
FakeDHCPDetEnabled The activation of the fake DHCP servers occurence detection.
TimeWindow Count of hours (the length of the sliding time window) for which are stored the
statistics of the DHCP traffic.
DhcpThreshold The threshold for increase of the DHCP traffic (in percents). It is used for
comparing to previous statistics of the given IP address and to the network average.
TrafficSizeThreshold Minimal amount of DHCP traffic (in KiB).

ExcludeDhcpServers The outgoing traffic from the DHCP servers can be ignored within the
detection of increased DHCP traffic.
Interpretation of results The method is able to detect flooding attacks in DHCP traffic and suspi-
cious increase of the volume of communication. The typical example is DHCP discover flood-
ing which is used to exhaust resources of DHCP server. Detection of fake DHCP server can
indicate attempted man-in-the-middle attack or incorrect configuration of a network device.
3.2.7 DIRINET – Direct internet communication

Method description This method detects devices that are communicating directly into the Inter-
net (beyond the segment defined by parameter LANSegment). It is possible to set reporting
of unsuccessful and successful communication out of the allowed network segment using pa-
rameter ReportTries (eventually ReportCommunication). The minimal transfer is given by
the value of MinimalTransfer parameter.
Method configuration It is appropriate to activate this method for IP addresses from own net-
work, that shouldn’t be able to communicate directly into the Internet (e.g. due to security
guidelines). Appropriate place for monitoring the Internet is the connection line.
Method parameters
LANSegment The name of the filter that defines IP addresses which are allowed to commu-
nicate only with IP addresses from this filter and with the proxy server.
ReportTries The choice to report unsuccessful attempts to communicate with IP addresses
outside the network defined by the LANSegment parameter.
ReportCommunication The choice to report successful communication with IP addresses
MinimalTransfer The minimal amount of transferred data between IP addresses inside and
Interpretation of results This method is capable to detect devices that communicate directly into
the Internet even if they are expected not to do this (they should use proxy server or they
should communicate only with other devices inside the local segment).
3.2.8 DIVCOM – Target hosts/ports anomaly

Method description A method for detection of detect devices which exhibit great diversity of com-
munication. The method determines for each IP address its communication factor as a prod-
uct of the unique destination address and unique destination ports. If the defined tolerance
limit (value of CommunicationFactor option) is reached the corresponding event is gener-
ated. Parameter ExcludeServers specifies name of filter that defines server’s IP addresses,
which should be excluded from detection. The servers have a higher diversity of communica-
tion than the client’s stations.
Method configuration It is appropriate to activate this method for IP addresses from own net-
work or for all addresses when monitoring publicly available server farms. Appropriate place
for monitoring the traffic is the central switch as well as the Internet connection line.
Method parameters
CommunicationFactor The threshold for multiplication of the communication partners and

destination ports counts to which is communicated from the given IP addresses (so called
communication factor).
ExcludeServers The name of the filter that defines the IP addresses for which communica-
tion factor is not computed within the detection (especially for servers).
Interpretation of results This method is capable of detecting devices that scan ports, spyware of
infected devices or misconfiguration of the devices. Typical false positives include detection
of devices implementing SNMP Monitoring such as Zabbix.
3.2.9 DNSANOMALY – DNS anomaly

Method description Method detecting the suspicious communication in DNS traffic. The method
is capable to notify about UDP traffic greater than 576 B (this follows from DNS service stan-
dard) or large data transfers on TCP port 53. UDP packet size control defined in RFC 1035 can
be disabled if you set IgnoreRFC1035 parameter to “1” (default value is “0”). Sensitivity in the
detection of large data transfers can be adjusted via the option TCPTransferLimit.
This method is extended by a detection of using DNS servers that are not allowed in the
monitored network. This extension is activated by the choice of the filter DNSServers that
defines IP addresses of allowed DNS servers.
Next extension is based on simple model of used DNS servers. The parameter LearnCycles
defines how long should be the model trained. The parameter MinimalRatio defines the
minimal ratio (in percents) of count of connections that should the DNS server satisfy to be
considered as usually used DNS server. It is possible to exclude the DNS servers in monitored
network from the detection by setting the ServersToExclude parameter.
network regardless of IP addresses. Appropriate place for monitoring the traffic is the Internet
connection line.
Method parameters
WithoutResponse The choice to report the communication to unauthorized or unusual DNS

servers even if there is no reply.
IgnoreRFC1035 The deactivation of the detection violation of the packet size defined by the
RFC 1035.
TCPTransferLimit The threshold for minimal amount of data transferred by the DNS service
over the TCP protocol.
EnabledTCP The name of the filter that defines the IP addresses of the devices that are al-
lowed to transfer the data using DNS over TCP (e.g. DNS servers for zone transfers).
DNSServers The name of the filter that defines the IP addresses of the DNS servers, which
can be used in the monitored network with respect to the security policy.
LearnCycles Count of the 5-minutes cycles intended for training the classifier. No event is
reported during this time period. If the value of this parameter is equal to 0, the detection
of using unusual DNS servers is inactive.
MinimalRatio The minimal ratio of the count of use of the DNS server by given IP address to
consider this server as commonly used (in percents).
ServersToExclude The name of the filter that defines the IP addresses of the DNS servers
that are ignored within the classifier.
Assigned filter Filter is used for restricting source IP addresses (classifier and illegal DNS servers
detection), source or destination IP addresses (large UDP packets and DNS TCP transfer de-
tection).
Interpretation of results This method is capable of detecting DNS service abuse for other unde-
sirable activities, which typically include tunneled traffic. The sudden change of usage of DNS
servers could indicate the malware infection.
3.2.10 REFLECTDOS – Amplificated DoS attack

Method description This detection method allows to unveil the DoS attacks using the weaknesses
of some services for amplification of the attack (the services can send much bigger response
on specific requests, this response is sent to the forged source IP address of the request).
Purpose of this method is to detect the misuse of the servers in the monitored network to
this type of DoS attack. It is implemented the detection of misuse of the NTP (UDP/123), DNS
(UDP/53, TCP/53), Portmap (UDP/111) and TFTP (UDP/69) services.
The misused servers are detected base on the ratio of sent and received data (communication
with single client). To generate an event, server has to send at least x-times more data, than
it receives (for x being the value of the ThresholdChanges parameter) and the server has
to send at least as much packets to all of its clients as it is the value of the MinimalReplies
parameter.
The detection method has to have assigned the filters defining the IP addresses of NTP and
DNS servers in the DNSServers and NTPServers parameters. If one of these filters is not as-
signed, the relevant part of detection is not active. The detection of amplification attacks that
misuse the Portmap or TFTP service doesn’t require filter assignment, this part of detection
method can be activated using the Portmap and TrivialFTP parameters.
network regardless of IP addresses. Appropriate place for monitoring the traffic is the central
switch.
Method parameters
MinimalReplies Minimal amount of data sent by the relevant server.

ThresholdChange The threshold value of the ratio between data sent and received by the
relevant server.
DNSServers The name of filter defining the IP addresses of DNS servers. If none filter is as-
signed, the detection of the amplificated DoS attacks misusing the DNS service (UDP/53,
TCP/53) is disabled.
NTPServers The name of filter defining the IP addresses of NTP servers. If none filter is as-
signed, the detection of the amplificated DoS attacks misusing the NTP service (UDP/123)
is disabled.
Portmap The activation of the amplificated DoS attacks which misuse the Portmap service
(UDP/111).
TrivialFTP The activation of the amplificated DoS attacks which misuse the TFTP service
(UDP/69).
Interpretace metody This method alerts to the misuse of the provided service. The solution of
this situation can be the change of the service configuration.
3.2.11 DOS – Denial of service attack

Method description A method for detection of Denial-of-Service or Distributed-Denial-of-Service
attacks. This method is based on evaluating the ratio of incoming to outgoing packets for
each device on the monitored network. It is predicted the maximal boundary with respect to
historical data. Exceeding the predicted boundary leads to generating the event. In case the
event is generated, source IP address is the address of the attack victim, attackers are listed
as event targets.
This method can be configured using the WindowLength parameter, that defines the maxi-
mal age of the data, that could be used to the classification, Threshold parameter, that de-
fines the tolerance to increase of the ratio (the tolerance is directly proportional to the value of
the parameter), MinimalIncoming parameter, that defines minimal count of incoming pack-
ets, AbsoluteThreshold parameter, that defines minimal ratio and AttackersThreshold pa-
rameter, that defines the minimal count of attackers involved into the attack.
connection line or the central switch (for large organizations with the vast network).
Method parameters
AttackersThreshold Minimal count of concurrently attacking devices.

Threshold The threshold for minimal increase (the increment of standard deviations) for the
received and sent packets ratio (for the attack victim).
AbsoluteThreshold The threshold for the minimal received and sent packets ratio (for the
attack victim).
MinimalIncoming The threshold for minimal count of incoming packets (for the attack vic-
tim).
WindowLength The count of hours (length of the sliding time window) to store the statistics
of incoming and outgoing packets for the devices in the monitored network.
MaxBpp The maximal bytes per packet to consider the connection as a potential attack.
SYNPackets The minimal count of flows containing only SYN packets to be considered as
a DoS attack (simplified detection, inactive if 0).
F2WThreshold The minimal count of connections finished by FIN flag only by one of the com-
munication partners. It is used to detect Fin2Wait DoS attacks, this detection is inactive if
the parameter equals 0.
Assigned filter Filter is used for restricting source IP addresses (victim of the attack).
Interpretation of results This method reliably alerts to the DoS/DDoS attacks of the specified
minimum range.
3.2.12 HIGHTRANSF – High volume of transferred data

Method description A method for detection of massive usage of the data link by one user (IP
address). Method aggregates all traffic for each IP address and checks exceeding the maxi-
mum limit. The option TransferThreshold specifies the absolute data volume threshold for
single IP address (in MiB). When this limit is reached or exceeded an event is reported. This
event has set only the IP addresses with which was transferred at least the given percent-
age (TargetPercentile parameter) of maximal transfer between two IP addresses. Parameter
ExcludeServers specifies name of filter that defines servers IP addresses, which should be
excluded from detection. The servers have typically higher data transfers than the client’s
stations. Parameter LegalServers specifies the name of filter that defines IP addresses with
which are the high transfers allowed.
Method configuration It is appropriate to activate this method only for IP addresses from own
network. The appropriate place for monitoring the traffic is the Internet connection line.
Method parameters
TransferThreshold The threshold for the transferred data amount (in MiB).
ExcludeServer The name of the filter that defines the IP addresses of the devices, which are
allowed to transfer big amounts of data (especially the servers in the monitored network).
TargetPercentile The value of the parameter defines the minimal percentage of the total
data amount should be transferred with single communication peer to indicate it as an
event target.
LegalServers The name of the filter that defines the IP addresses of the devices that are
allowed to be used for big data transfers by the devices in the monitored segment.
Interpretation of results This method reliably alerts to the IP addresses which transferred more
data then it is allowed.
3.2.13 HONEYPOT – Honeypot traffic

Method description This method is inspired by so called honeypots, the network traps. Comput-
ers on that are not expected for the incoming traffic. All such traffic can be considered as
anomaly. The detection method works similarly. The IP addresses representing honeypots
are defined as a filter and if there is any access to these IP addresses, the event is generated.
network except for the IP addresses from which we except the access to the honeypots (e.g.
because of configuration). It is necessary to set up the name of the filter defining honeypots
for proper functioning. Appropriate place for monitoring the traffic is the Internet connection
line or the central switch.
Method parameters
IgnoreAccessFrom The name of the filter that defines the IP addresses that are allowed to
communicate with the honeypots (e.g. because of the management).
HoneypotFilter The name of the filter that defines the IP addresses of the network traps that
shouldn’t be requested by any device (besides the IP addresses defined by the IgnoreAc-
cessFrom parameter).
Interpretation of results This method alerts to the unauthorized access on the chosen comput-
ers in the network. It could mean horizontal scanning or the attempt to network-wide ssh
attack.
3.2.14 HTTPDICT – Web form attack

Method description This detection method is focused on detecting web login form dictionary at-
tacks (or brute force attacks). Minimal number of attempts to login from single IP address
is given by the MinimalPerClient parameter. Due to the possibility of some false positives
caused by regullar webpage updates (using e.g. A JAX technology) is necessary to set the Min-
imalPageSize parameter as the minimal size of the page returned in case
Method configuration It is appropriate to activate only for the webservers in the monitored net-
work, possibly for all traffic on the network (to detect attacks from clients in the monitored
network). Appropriate place for monitoring the traffic is the Internet connection line or the
central switch.
Method parameters
MinimalPerClient The threshold for minimal count of unsuccessful attempts to login from
single IP address.
MinimalPageSize The minimal size of the webserver response sent after unsuccessful login
attempt.
Assigned filter Filter is used for restricting destination IP addresses.
Interpretation of results The method highlights the increased count of sending the same-sized
file from the webserver to single client. That probably means the dictionary attack on the web
login form.
3.2.15 ICGUARD – Internet connection utilization anomaly

Method description Detection method monitors usage of internet connection line and is able to
alert an excessive usage per host (user) or in total based on defined threshold values. Within
the configuration it is necessary to set connection type (symmetrical line, asymmetrical line)
and define the line speed in Mbps. Another configuration option is LANFilter which defines
local IP addresses; communication between these addresses is computation of line usage
ignored. Setting up the local addresses is mandatory.
This method can detect a high number of packets per second transferred over connection
to internet. Event is detected if the overall sum of packets per second exceeds the value
of TotalPPS parameter. If at least half of this operation is generated by one IP address the
address is identified as the originator of an event.
connection line or the central switch.
Method parameters
ConnectionType The type of the connection to the Internet (symmetrical or asymmetrical

line).
SLineSpeed The connection speed in case of symmetrical line (in Mbps).
ADownLineSpeed The download speed in case of asymmetrical line (in Mbps).
AUpLineSpeed The upload speed in case of asymmetrical line (in Mbps).
LANFilter The name of the filter that defines the IP addresses of the devices which are con-
nected to the Internet by the described line.
TotalGuard The threshold for total utilization of the connection line to be reported as an
event (in percents).
PerHostGuard The threshold for utilization of the connection line by single IP address to be
reported as an event (in percents).
TotalPPS The threshold for minimal count of packets per second.
Interpretation of results This method shows clearly the excessive usage of internet connection.
3.2.16 ICMPANOM – ICMP anomaly

Method description Detection method identifies suspicious communication in ICMP traffic. The
method reports increased number of ICMP type 3 messages, which could signal spread of
worm. It monitors long-term behavior of a node in the network and compares the current
observation with statistics for the node and also global statistics for the network. Addition-
ally, it can detect ICMP scans, ICMP smurf, ping flood attacks and excessive payload of ICMP
packets.
Using the parameter TimeWindow you can set the time window (in hours) for collecting and
processing long-term statistics. When TimeWindow is set to 0 detection of ICMP type 3 mes-
sage anomalies is disabled. Parameter ICMPThreshold specifies the maximum allowed in-
crease of observed ICMP type 3 messages and parameter Type3MsgThreshold is used to set
the lower bound of ICMP type 3 messages for a single IP address (minimal number of mes-
sages that could be considered as anomalous). By setting the parameter ICMPSmurf and
ICMPScan to 1 you will enable detection of ICMP smurf attacks and ICMP scans, respectively.
The ICMP scans part of detection method can be limited by minimal count of scanned devices,
too (the ScannedDevices parameter).
The ICMP echo request flood detection is limited by the PingFloodThreshold parameter. Its
value defines minimal count of sent echo request packets. If the value equals zero, echo
request flood detection is not performed.
Excessive payload of ICMP packets detection is limited by MinimalPackets and MinimalPay-
load parameters that corresponds to minimal count of given ICMP type and their minimal
average payload. If the MinimalPayload parameter equals zero, the excessive payload of
ICMP packets detection is not performed.
Method configuration It is appropriate to activate this method for all IP addresses. Appropriate
place for monitoring the traffic is the central switch and the Internet connection line.
Method parameters
TimeWindow Count of hours (the length of the sliding time window) to store the statistics of
the ICMP traffic. If the value of the parameter equals to 0, the detection of the volumetric
anomalies in ICMP traffic is inactive.
ICMPThreshold The threshold for increase of the ICMP type 3 messages count (in percents).
It is used for comparison to the previous statistics and to the network average.
Type3MsgThreshold Threshold for minimal count of ICMP type 3 messages.
ICMPSmurf Choice to activate the ICMP Smurf attacks detection (the amplification DoS at-
tacks using ICMP messages).
ICMPScan Choice to activate the horizontal ICMP scans detection.
ScannedDevices The threshold for minimal count of scanned devices.
PingFloodThreshold The threshold for ICMP echo request messages count. If the value of
the parameter equals to 0, the ICMP echo request flood detection is inactive.
MinimalPackets The threshold for minimal count of given ICMP type packets used for the
detection of high transferres over the ICMP protocol.
MinimalPayload The threshold for minimal bytes per packet used for the detection of high
transferres over the ICMP protocol. If the value of the parameter equals to 0, this part of
detection is inactive.
Interpretation of results The method is able to detect increase of ICMP type 3 messages (Un-
reachable). This could happen during spread of worm, especially in case when UDP protocol
is used and hosts with closed ports send back ICMP Port Unreachable messages. ICMP scans
are used to determine live hosts in the network and it could be used by malware. The goal
of ICMP smurf attack is to flood the network and especially connection link to the victim with
a large number of ICMP Echo replies.
3.2.17 IPV6TUNNEL – IPv6 tunneled traffic

Method description The IPV6TUNNEL detection method allows detecting the network devices,
which are communicating through tunneled IPv6 protocol over Teredo or 6in4 protocol. The
first parameter is the ConnectionsThreshold parameter, which allows to restrict the mini-
mum amount of connections between stations. With parameter UploadDataThreshold re-
spectively DownloadDataThreshold is possible to limit the minimal amount of transferred
data. Another parameter is IgnoreFailedConnections, which allows to ignore unpaired com-

munication. It is possible to set method for ignoring Teredo protocol (Value of IgnoreTeredo
is set to “yes”) or for ignoring 6in4 protocol (Value of Ignore6in4 is set to “yes”).
Method parameters
ConnectionsThreshold The threshold for minimal count of connections over the IPv6 tun-
nels.
UploadDataThreshold The threshold for minimal amount of data sent by the device over
the IPv6 tunnels.
DownloadDataThreshold The threshold for minimal amount of data received by the device
over the IPv6 tunnels.
IgnoreFailedConnections Choice to ignore the connections without response.
IgnoreTeredo Choice to deactivate the detection of the Teredo tunneling protocol.
Ignore6in4 Choice to deactivate the detection of the 6in4 tunneling protocol.
Interpretation of results The method detects devices communicating over IPv6 protocol thah is
tunneled through IPv4.
3.2.18 INSTMSG – Instant messaging traffic

Method description A method detecting the use of instant messaging services even if they mask
through the ports reserved for other services (e.g. port 80 for web traffic). Based on the
statistical characteristics of the instant messaging traffic the method distinguishes between
OSCAR protocol (ICQ and its derivatives), XMPP (Jabber service and its derivatives, including
Google Talk) and Skype. Any client of any of the above listed services is sufficient for successful
detection. Detection of particular instant messaging types can be suppressed by setting the
Ignore option. For suppression of false positives which may arise from the local network,
there is the option LANFilter available, which allows you to specify the name of the filter
comprising a local network addresses between which the traffic exhibiting instant messaging
characteristics is ignored. Parameter IgnorePorts allows to ignore communication on ports
993 and 443 for reducing false positives during XMPP instant messaging detection.
connection line or the central switch (with option LANFilter set).
Method parameters
LANFilter The name of the filter that defines the IP addresses with which is the communica-
tion ignored within the detection.
IgnoreOSCAR The choice to deactivate the detection of the OSCAR instant messaging proto-
col (used e.g. by the ICQ service).
IgnoreXMPP The choice to deactivate the detection of the XMPP instant messaging protocol
(used e.g. by the Jabber service).
IgnorePorts The choice to ignore the TCP ports 443 and 993 within the XMPP protocol detec-
tion.
IgnoreSkype The choice to deactivate the detection of the Skype communication application.
IgnoreOnlineMSG The choice to deactivate the detection of chosen instant messaging web
applications.
IgnoreSNGL The choice to ignore the attempts to connect to the instant messaging web ap-
plication without response.
Interpretation of results Although this is a heuristic the method achieves very reliable results
in the real traffic. In some cases the confusion of roles of the event originator/event target
occurs, i.e. IP address from a local network that runs the client’s instant messaging is marked
as the event target and the server of the service as the event originator.
3.2.19 L3ANOMALY – L3 network anomaly

Method description The detection method reveals traffic anomalies on the network layer. The
first part detects situations where the source or destination IP address of the communicating
parties is not from our legitimate internal networks (additional info is available in RFC 2827).
The second part reports the flows with broadcast or multicast source IP address. The third
one detects packets with the same source and destination IP address. Both IPv4 and IPv6 are
supported.
The filter InternalNetworks specifies the range of allowed internal networks and it is impor-
tant for the first part of the detection (IP spoofing). It is possible to individually enable or
disable each part of the detection using parameters IPSpoof, SourceIPAnom and SameSr-
cDestAnom. Enabling the parameter IgnoreBroadMulticast you can inhibit the detection of
IP spoofing for the flows with multicast or broadcast destination IP address. The flows with
link-local IP addresses and zero network broadcasts are by default excluded from detection
of IP spoofing.
connection line or the central switch (with option InternalNetworks) set).
Method parameters
InternalNetworks The name of the filter that defines all IP addresses of the monitored net-
work.
SourceIPAnom The choice to activate the detection of connections with broadcast or multi-
cast IP address as a source.
SameSrcDestAnom The choice to activate the detection of connections with same source
and destination IP addresses.
IPSpoof The choice to activate the detection of connections with source and destination IP
adresses which are both outside the network defined by InternalNetworks parameter.
IgnoreBroadMulticast The choice to ignore the connections with broadcast or multicast des-
tination IP address during the IPSpoof detection.
Interpretation of results The communication of IP addresses outside the scope of local networks
may indicate IP spoofing or an attempt to modify IP headers. In case of flows with incorrect
IP addresses (broadcast or multicast source IP address or the same source and destination
IP address) it could be an attack on some implementation issue of TCP/IP stack of a network
equipment.
3.2.20 LATENCY – Network latency anomaly

Method description A method for measurement of delay at the network level, i.e. delay between
the recording of the first request packet and the first response packet. The method uses
Bidirectional flows standard (RFC 5103), i.e. classification of data flows such as requests and
responses. The delay has to be measured for a given group of IP addresses specified by a fil-
ter. Within the configuration it is necessary to set the option LatencyThreshold whose value
determines the maximum tolerated value of the delay between the request and the response.
Another option is StrictMode which determines whether the delay will be measured for ad-
dresses matching the filter assigned to the detection method (value “normal” of the option)
or exclusively between these addresses (value “strict” of the option). It is possible to affect
the behavior of this method using option TCPFlags which enables to detect the latency only
during connection establishment.
Method configuration It is appropriate to activate this method according to network topology

of the network and the objectives of the measurement. In any case, it makes no sense to
measure the delay on any targets in the Internet. Optimal place for monitoring the traffic is
for example data link between two workplaces of the organization or line to the organization
servers.
Method parameters
LatencyThreshold The threshold for minimal difference between the timestamps of the re-
quest and response (in miliseconds).
StrictMode The choice to detect the latency just among the IP addresses defined by the as-
signed filter.
TCPFlags The choice to limit the detection just on the flows containing packets with TCP SYN
flag.
Interpretation of results This method shows a particular value of delay between recording of the
first request packet and the first response packet. This value thus indicates the delay at the
network layer and can help in analyzing the problem of latency in selected application or data
link. The method can also be used to check the SLA on the selected data link.
3.2.21 MULTICAST – Multicast traffic

Method description A method for detection of IPv4 multicast traffic based on the use of mul-
ticast addresses (224.0.0.0 to 239.255.255.255), directed broadcast addresses (X.Y.Z.255), all-
host broadcast address (255. 255. 255. 255) and IPv6 multicast (ff00::/8). Detection of di-
rected broadcast and all-host broadcast traffic can be suppressed by setting the option Ig-
noreBroadcast to value “Yes”. Minimum number of multicast requests to be reported can be
set via option MinimalAttempts (this threshold is allways evaluated). The condition is satis-
fied if at least one of the MaxBPP and MinTransferred thresholds satisfies. If some of these
thresholds is equal to zero, the other one has to be satisfied. If both od these thresholds are
equal to zero, they are ignored.
Method configuration In the case of network problems or suspicion to problems associated with
multicast traffic, it is appropriate to activate this method network-wide for all communication
in the network regardless of IP addresses. Appropriate place for monitoring the traffic is the
Internet connection line or the central switch.
Method parameters
IgnoreBroadcast The choice to ignore the broadcast and IPv6 all-host multicast within the
detection.
MinimalAttempts The threshold for minimal count of multicast (or broadcast) connections.
MaxBPP Maximal average value of bytes per packet (this metric is not used, if the parameter
is set to 0).
MinPPS Minimal average value of packets per second (this metric is used only together with
the MaxBPP parameter).
MinTransferred Minimal amount of data transferred to Multicast or Broadcast IP addresses
(in MiB).
Interpretation of results This method reliably alerts to the IP addresses on the network that gen-
erate multicast traffic.
3.2.22 NATDET – Network address translation

Method description The detection method reveals the IP addresses used by more devices (using
NAT). As the detection method uses the specific behavior patterns of distinct operating sys-
tems, the detection is limited just to NATs with at least two devices with different operating
systems present in it.
Method configuration It is appropriate to activate this method only for the IP addresses of the
monitored network segment. Appropriate place for monitoring the traffic is the central switch.
The detection method requires proprietary IPFIX fields by Flowmon Networks. It is necessary
to activate the User Agent fields from HTTP OS & Application info extension and the whole L3/L4
extended fields extension.
Method parameters
DistinctSYNSize Minimal count of TCP SYN packets with distinct size for single IP address.
DistinctTTL Minimal count of TCP SYN packets with distinct TTL set for single IP address.
DistinctTCPWindow Minimal count of TCP SYN packets with distinct TCP window set for sin-
gle IP address.
DistinctOS Minimal count of distinct operating systems (from HTTP user agent) for single IP
address.
MinimalProbability Minimal probability, that the given IP address corresponds to more dif-
ferent devices (there is a NAT).
MaxHop Maximal count of hops expected in given network (i.e. maximal count of the routers,
which can be passed by the single packet). It is used for NAT detection based on nonstan-
dard TTL values.
Interpretation of results This detection method alerts to the IP addresses corresponding to

many different devices using NAT (physical eventually virtual devices).
3.2.23 SMTPANOMALY – SMTP anomaly

Method description A detection method based on the assumption that in the corporate environ-
ment emails should be sent only in a defined way. The method detects sending or attempts
to send mails through other than explicitly defined mail servers.
In addition, parameter SPAMCounter can activate detection of increased number of sent
emails from one station. The increased number is specified by parameter Multiplicator,
which defines times the average number of mails sent at other stations. The average is com-
puted only from stations which sent more than MinimalMailLimit messages in one hour.
The method takes interest in the TCP/25 (SMTP), TCP/465 (Secured-SMTP) and TCP/587 (Mes-
sage Submission service). Based on the number of flows and responses from the mail servers
the method estimates the number of emails and whether the emails were actually sent. This
information is then available in the detail of the generated event. Event targets represent all
mail servers through which attempts to send mail were made.
The option ServersFilter identifies legitimate SMTP servers through which you can send mail.
The option StrictMode set to value “strict” means that IP addresses assigned to the method
by the filter have to be the sources of the event. The option ExcludeMailServers set to value
“exclude” means that IP addresses from the ServersFilter list are excluded from detection.
The option IgnoreSecuredSMTP allows to ignore secured SMTP traffic (port TCP 465). The
option IgnoreScans set to value “ignore” allows ignoring too small transmission, that can’t be
e-mail traffic. The option IgnoreTCP587 allows to ignore Message Submission service (port
TCP 587).
Method configuration It is appropriate to activate this method for IP addresses of the organi-
zation. Appropriate place for monitoring the traffic is the central switch and the Internet
connection line.
Method parameters
ServersFilter The name of the filter that defines the IP addresses of the e-mail servers which
are allowed to be used in the monitored network.
StrictMode The choice to ignore the e-mail traffic comming from outside of the network
defined by the assigned filter.
ExcludeMailServers The choice to ignore the outgoing traffic from IP addresses defined by
the ServersFilter parameter within the detection.
IgnoreSecuredSMTP The choice to ignore the traffic of the Secured SMTP service (TCP/993)
within the detection.
IgnoreTCP587 The choice to ignore the traffic of the Message Submission service (TCP/587)
IgnoreScans The choice to ignore the traffic recognized as a port scanning within the detec-
tion.
SPAMCounter The choice to activate the detection of increased sent e-mails count.
MinimalMailLimit The threshold for minimal count of e-mails sent by single device.
Multiplicator The coefficient used for computing the dynamic threshold for e-mail sent by
single devices. The threshold is computed simply as a multiplication of the coefficient
and the network average.
IgnoreSYNflows The choice to ignore the flows with only TCP SYN flag. It is apropriate to
activate this choice if and only if there are flow data with correctly assigned TCP flags.
Assigned filter Filter is used for restricting source IP addresses (according the StrictMode param-
eter and in the profiler part of detection).
Interpretation of results This method not only detects attempts to spam, but also may help to
identify spyware infected devices. Further it may help detecting employees that use other
than corporate mail servers, which may indicate misconfiguration as well as an intention.
3.2.24 PEERS – Partners communication anomaly

Method description Detection method reveals increased number of unique communication part-
ners. The method keeps sliding window with relevant statistics. The length of the window in
hours can be set by WindowLength parameter.
The detection is limited only on connections with more transferred packets than defined by
PacketsMinCount parameter. The detection is based only on requests sent by monitored
devices. It is possible to activate ignoring requests with no response using the IgnoreSNGL
parameter. The IP addresses defined by ExcludeServers filter are excluded from detection.
The devices with less unique communication partners than given by PartnersMinCount pa-
rameter are excluded as well.
The average and standard deviation of communication partners statistics are calculated for
the sliding window during the detection. If the current count of unique communication part-
ners is higher than the sum of average and the standard deviation, then the increase rate is
calculated. The event is reported if the increase rate is higher than the value of the Threshold
parameter.
Method configuration It is appropriate to activate this method only for IP addresses from moni-
tored network.
Method parameters
WindowLength Count of hours (the length of the sliding time window) to store the statistics
of the communication peers for single IP addresses in the monitored network.
Threshold Threshold for minimal increase of the communication peers count compared to
the sliding window average.
ExcludeServers The name of the filter that defines IP addresses theirs statistics of the peers
are not evaluated.
PartnersMinCount The threshold for minimal communication peers count for single device.
PacketsMinCount The threshold for minimal packet count per flow.
IgnoreSNGL The choice to ignore the requests without responses within the detection.
Interpretation of results This method alerts increased number of communication partners for
certain IP address.
3.2.25 SCANS – Port scanning

Method description A detection method used to detect common and used techniques of map-
ping the network and running services through the port scanning. The method distinguishes
different types of scans (SYN scan, FIN scan, Xmas scan and Null scan) and styles (horizontal
scan, vertical scan, chaotic scan). Parts of details are the number of scans, number of unique
targets, information about response from a scanned device and list of scanned ports. To ad-
just the sensitivity of the method serves the option ScansThreshold whose value indicates
the minimum number of attempts to scan from a single source that should be recognized as
an event. The option IgnoreChaotic allows to ignore chaotic scans and detect only horizontal
and vertical scanning. The option IgnoreUnsucc allows ignoring scans with no response. It
is possible to limit the detection only to the ports less than 1024 using DetectOnlyKnown
parameter. This can be extended by the comma separated list of port numbers defined as
a DetectThesePorts parameter value. In combination with the detect specified value of the
DetectOnlyKnown parameter can be the detection limited only to the ports listed in the De-
tectThesePorts parameter.
This detection method is also able to detect the unsuccessful attempts to scan the ports on
protocol UDP. This part of detection can be set by the UDPThreshold parameter, which de-
fines the minimal attempts number. Chaotic scans are ignored.
The detection, that can be activated using PortBasedDetection parameter is intended for
monitored network with Flows without correctly assigned TCP flags. This detection is using
the portlist defined in DetectThesePorts parameter. Only communication on these ports is
controlled. The attacker has to access on each port from the list on each target of the attack
for successful detection. The DetectOnlyKnown and IgnoreChaotic are ignored in this type
of detection.
Method parameters
ScansThreshold The threshold for minimal count of attempts to port scanning by a single
device.
IgnoreChaotic The choice to ignore the chaotic port scans (it is not possible to determine, if
the scan is vertical or horizontal).
IgnoreUnsucc The choice to ignore the attempts to port scanning without response.
DetectOnlyKnown The choice to detect just the port scanning on ports lesser than 1024 or
on ports defined by the list.
DetectThesePorts The comma separated list of the port numbers to limit the port scans
detection.
PortBasedDetection The choice to use the detection based on given port numbers. This
type of detection is suitable when there are the TCP flags incorrectly recognized in the
monitored traffic (caused by some types of data sources).
If the PortBasedDetection parameter is active, it is appropriate to activate this method
only for IP addresses from monitored network. The event is then reported only if some
IP address from this definition is scanned.
UDPThreshold The threshold for minimal count of unsuccessful attempts to scan UDP ports
by single device. The detection is based on monitoring the ICMP traffic. If the value of
the parameter equals to 0, the UDP ports scanning detection is inactive.
ARPScan The threshold for minimal count of ARP requested to be considered as an ARP
scanning. If the value of the parameter equals 0, the ARP scans detection is inactive.
MinTargets The minimal count of IP addresses scanned using the ARP requests.
Assigned filter Filter is used for restricting source or destination IP addresses, for destination IP
addresses only in case of portbased detection.
Interpretation of results Apart from detecting attempts to deliberate port scanning this method
may detect misconfigured devices which are unsuccessfully trying to establish a connection
or devices infected with malware that is trying to replicate itself to other devices.
3.2.26 SRVNA – Service not available

Method description A detection method used to detect unavailable services (IP address/port),
to which clients want to access. This method can be restricted by minimal number of ac-
cesses to the service (parameter AttemptsThreshold) and by filter that defines IP addresses
of provided services (parameter ServiceProviders). In case the event is generated, source IP
address is the address of the unavailable service provider. There is listed the count of suc-
cessful connection and successfully connected clients in the detail, too. It is possible to limit
the detection using the RelativeUnsuccessful parameter that defines minimal ratio between
unsuccessful requests and all connections to the given service.
This method allows also to detect the unavailable services on UDP protocol. This part of
detection can be set by the UDPThreshold parameter, that defines the minimal threshold of
unsuccessful attempts number.
place for monitoring the traffic is the central switch and the Internet connection line. It is
recommended to activate the OnlyRejected parameter if the detection is performed on the

sampled traffic.
Method parameters
ServiceProviders The name of the filter that defines the IP addresses of servers theirs fail-
ures should be detected.
AttemptsThreshold The threshold for minimal count of attempts to single service (defined
as IP address, protocol, port tuple).
RelativeUnsuccessful The threshold for ratio of the unsuccessful attempts to service to total
count of attempts (in percents).
OnlyRejected The choice to evaluate only the rejected attempts to the service (attempts with
response with TCP RESET flag).
UDPThreshold The threshold for minimal count of attempts to the service on UDP protocol.
If the value of the parameter equals to 0, the detection of the unavailable service on UDP
protocol is inactive.
Assigned filter Filter is used for restricting source IP addresses (servers).
Interpretation of results Apart from detecting successful Denial of Service attack this method
may also detect an erroneous configuration – either on server, which does not provide the
service that should be provided, or on the clients, which demands services that are not pro-
vided.
3.2.27 TEAMVIEWER – TeamViewer traffic

Method description A method used to detect sharing desktop using TeamViewer.
Method configuration It is appropriate to activate this method only for IP addresses from the
monitored network. Appropriate place for monitoring the traffic is the central switch.
Method parameters There is no additional parameter for this detection method.
Interpretace This method detects devices that are sharing their desktop using TeamViewer.
3.2.28 TELNET – Telnet anomaly

Method description A method used to detect increased use of Telnet service. Telnet service is
obsolete and currently should not be used at all for safety reasons. Eventually its use should
be a subject to a special regime. The method detects all connections to TCP port 23 (Telnet
service) including connection attempts and counts the number of connections for individual IP
addresses. Within the method configuration you must set up the minimum number of Telnet
connections to be considered unwanted through the option TelnetThreshold. Detection may
include all connection attempts including scans (option IgnoreScans and value “no”) or only
successfully established connections (option IgnoreScans and value “yes”). The servers to
which is allowed to logon via telnet protocol can be excluded from the detection using the
AllowedTelnet parameter.
place for monitoring the traffic is the central switch and the Internet connection line. By
setting the option IgnoreScans to value “yes” it is possible to detect devices that are infected
with some form of malware (e. g. botnet Chuck Norris) invading other network devices such
as routers, IP cameras, etc.
Method parameters
TelnetThreshold The threshold for minimal count of the connections using the Telnet service
(TCP/23).
IgnoreScans The choice to ignore the traffic recognized as a scanning the TCP port 23.
AllowedTelnet The name of the filter that defines the IP addresses that are allowed to be
accessed using the Telnet service.
UploadThreshold Minimal amount of data uploaded by a single device.
DownloadThreshold Minimal amount of data downloaded by a single device.
Interpretation of results This method detects devices using or attempting to use the Telnet ser-
vice (depending on configuration). The method can also detect specialized devices that are
infected with some form of malware oriented to misuse specialized network devices.
3.2.29 TOR – TOR traffic

Method description A method designed to detect using anonymity protocol Tor while browsing
the Internet. The method configuration allows setting the minimal count of concurrently
started connections (parameter ConcurrentStart) and the minimal duration of the long-
standing connection (parameter LongConnection). It is possible to limit the false positives
by setting the filter that defines local network segment (parameter LANFilter) and minimal
probability of the event to be reported (parameter MinimalProbability).
Method configuration It is appropriate to activate this method for client stations of the monitor-
ing network. Appropriate place for monitoring the traffic is the Internet connection line.
Method parameters
LANFilter The name of the filter that defines the IP addresses of the devices in the monitored
network.
ConcurrentStart The threshold for minimal count of concurrently established connections.
LongConnection The minimal duration of continuous long connections (in seconds).
MinimalProbability The threshold for minimal probability evaluated by the detection
method.
Interpretation of results This method detects client’s stations that are using the anonymity Tor
protocol while they are browsing the Internet.
3.2.30 UPLOAD – Data upload anomaly

Method description This method monitors amount of transferred data between individual com-
municating stations and checks the ratio of data transferred from computers of monitoring
network and data transferred in the opposite direction. When user-defined ratio or absolute
threshold is exceeded, the event is generated. Parameter ExcludeServers specifies the name
of filter that defines servers IP addresses, which should be excluded from detection. The
servers have a greater upload than the client’s stations.
The large data uploads can be detected by two different ways. The first method is based on
all traffic statistics between two devices, so the upload to the server that is sending back some
other data concurrently cannot be detected. The second method is comparing each request
to the relevant response, so the upload is detected even despite the concurrent download.
However, uploading using large amount of small connections may not be detected. The de-
tection mode can be set by the Pairwise parameter.
Method configuration It is appropriate to activate this method for client’s stations of monitoring
network. Appropriate place for monitoring the traffic is the Internet connection line.
Method parameters
ExcludeIPs The name of the filter that defines the IP addresses which are allowed to upload
the data to them.
AbsoluteThreshold The threshold for minimal amount of sent data by a single device. If the
value of the parameter equals to 0, the detection based on the absolute threshold is
inactive.
RelativeThreshold The threshold for minimal ratio between sent and received data for a sin-
gle device in the network.
MinimalThreshold The minimal amount of sent data to check the sent to received data ratio.
ExcludeServers The name of the filter that defines the IP addresses of the devices which are
allowed to sent data.
Pairwise The choice to use the detection based on request-response pairs besides the total
statistics of sent and received data.
Interpretation of results This method reports the stations from which a file was uploaded, so it
may be an attempt to sensitive data leakage.
3.2.31 VOIP – VoIP traffic

Method description A method for detection of VoIP traffic by known pairs of port/protocol. The
practical applicability of the method is limited to a strict corporate environment and selected
devices and is appropriate for detecting SIP and H.323 traffic. The method enables detecting
network devices that generate standard VoIP traffic.
Method configuration It is appropriate to activate this method for explicitly selected IP addresses
of organization whose traffic structure is known or expected. Appropriate place for monitor-
ing the traffic is the Internet connection line.
Method parameters There are no additional parameters for this detection method.
Interpretation of results This method focuses solely on pairs of port/protocol therefore it can
produce large number of false positives in case that it is misconfigured.
3.2.32 VPN – VPN traffic

Method description A method for detection of VPN connections and tunnels by pairs of port/pro-
tocol. Parameter Advanced allows activating the advanced VPN tunnels detection based on
station communication with external network, which is characterized by long connection to
one IP address. Basic detection is appropriate mainly for detecting Microsoft PPTP, IKE Key Ex-
change or OpenVPN traffic on standard ports. Advanced detection allows detecting a general
VPN traffic to external servers. Parameter LanFilter specifies local network. Other parame-
ters MinimalTime and MinimalData defines minimal length of connection with external VPN
server and minimal capacity of transferred data in five-minute batch. Ror Microsoft PPTP it is
possible to set minimal length of VPN connection in seconds and minimal amount of trans-
ferred data in MiB.
Method configuration It is appropriate to activate this method for explicitly selected IP addresses
of an organization whose traffic structure is known or expected. Appropriate place for moni-
toring the traffic is the Internet connection line.
Method parameters
Advanced The choice to use the VPN traffic detection based on the behavioral analysis.
MinimalData The threshold for minimal amount of transferred data (in MiB).
MinimalTime The threshold for minimal duration of the VPN connection.
LANFilter The name of the filter that defines the IP addresses in the local network. The
communication among the devices in the local network is ignored within the detection.
Standard The choice to use the port-based detection.
ConnectionLength The threshold for minimal duration of the MSPPTP VPN connection (in
seconds).
Transferred Minimal amount of transferred data using the MSPPTP protocol (in bytes).
MSPPTP The choice to detect the use of MSPPTP protocol.
Interpretation of results This method allows determining the devices on your network using VP-
N/tunnels. Basic detection is focused solely on pairs of port/protocol therefore it can produce
large number of false positives in case that it is misconfigured. Advanced detection success-
fully detects general VPN traffic where all station communication with external network is
going through.
3.2.33 WEBSHARE – Web sharing traffic

Method description The WEBSHARE detection method allows identifying the network devices,
which download from web share services (e.g. RapidShare). Method can be configured to
ignore unsuccessful connections by option (Value of IgnoreSNGL set to “yes”). Detail of the
event can be extended by estimation of downloaded ("dowloaded to the WAN") and uploaded
("uploaded to the WAN") data from/to the Internet. This extension should not be activated if
the data from behind the proxy server are monitored. This extension can be enabled by set-
ting the parameter LANFilter. If this extension is enabled, the detection can be limited using
MinimalUp and MinimalDown parameters. These parameters limit the minimal transferred
data in the given direction.
Method parameters
IgnoreSNGL The choice to ignore the attempts to a fileshare webserver without response
LANFilter The name of the filter that defines the IP addresses of the devices in local network.
It is used for identification of uploading/downloading devices.
MinimalDown The threshold for minimal amount of data downloaded probably from the
fileshare webserver (in MiB). Applies only if the LANFilter parameter is set.
MinimalUp The threshold for minimal amount of data uploaded probably to the fileshare
webserver (in MiB). Applies only if the LANFilter parameter is set. It is enough to exceed
one of the MinimalDown and MinimalUp thresholds to report an event.
Interpretation of results Accuracy of detection depends on the database of known web sharing
services. There is also statistical distortion in the Event evidence. This distortion is caused
by webshare server IP address used during transmission, which is often different from known
gateway address. Therefore the amount of transferred data is less than the amount shown in
the Detail field.
3.3 Common behavior patterns for SIP traffic
3.3.1 SIPFLOOD – SIP floods

Method description This detection method allows to detect devices that are trying to overwhelm
the SIP stations in the monitored network segment using the flood attack. It is possible to
(de)activate the detection of respective types of attacks using RegisterFlood and InviteFlood
parameters. The Threshold parameter allows to set the minimal ratio between the relevant
received and sent packets by the victim. The PerCalledParty parameter allows to set the
minimal count of relevant packets sent to single SIP address. The MessageLimit parameter
allows to set the minimal count of attempts to the victim of the attack.
Method configuration It is recommended to activate this method for all IP addresses of SIP de-
vices in the monitored network segment. Appropriate place for monitoring the traffic is the
Internet connection line. It is necessary to activate this detection method combined with the
Flow source with activated SIP processing.
Method parameters
RegisterFlood The choice to activate the detection of flood of SIP packets with Register flag
set.
InviteFlood The choice to activate the detection of flood of SIP packets with Invite flag set.
Threshold The threshold for minimal ratio of count of packets with Invite (or Register) flag
set to the count of relevant responses.
PerCalledParty The threshold for minimal count of packets with Invite (or Register) flag set
per called party.
MessageLimit The threshold for minimal total count of attempts.
Assigned filter Filter is used for restricting source IP addresses (attack victims).
Interpretation of results The victim of the attack is shown as a event source. Event targets (at-
tackers or devices trying to attempt actual SIP connection during the attack) have generated
large amount of Register or Invite requests and the victim cannot handle this amount of re-
quests. The flooded victim cannot handle the real phone calls, too.
3.3.2 SIPSCAN – SIP scans

Method description This detection method allows to detect devices, that are scanning the SIP
stations in the monitored network segment. It is possible to (de)activate the detection of some
scanning types using RegisterScan, OptionsScan or InviteScan parameter. It is possible to
set the minimal count of attempts with relevant SIP flags (Register, Options, Invite) using the
Threshold parameter.
Method parameters
RegisterScan The choice to detect SIP devices scans which are using the Register flag.
OptionsScan The choice to detect SIP devices scans which are using the Options flag.
InviteScan The choice to detect SIP devices scans which are using the Invite flag-
Threshold The threshold for minimal attempts count.
Assigned filter Filter is used for restricting destination IP addresses.
Interpretation of results The scanning attacker is trying to detect SIP PBX’s and gateways (hori-
zontal, especially Register and Options scans; the information can be misused e.g. for eaves-
dropping) or active SIP addresses (vertical, especially Invite scans; the information can be mis-
used for telephonical SPAM).
3.3.3 SIPPROXY – SIP proxy

Method description This method uses the knowledge of single SIP URIs to detect the SIP proxy
servers (IP addresses used for SIP communication from distinct SIP URIs). The detection
method allows to set up the training period (ClosedSeason parameter)- During training pe-
riod aren’t generated any events by this detection method. The second option, that can be
set, is the time period used for storing the inactive devices in the classifier (TimeToDeath
parameter) – if the device becomes active after this time period, next event is generated.
If the filter is assigned, only devices outside these IP addresses are detected.
Method parameters
ClosedSeason Count of days intended for training the classifier on the monitored network.
No events are reported during this time.
TimeToDeath Count of days to store inactive SIP gateway (or proxy) in the classifier before
removing.
Interpretation of results The device indicated as SIP proxy (the event source) transmits the SIP
traffic for callers with distinct SIP URIs. This device can be dedicated for wiretrapping the
forwarded communication (Man-in-the-middle attack).
3.4 Advanced network behavior patterns
3.4.1 BROKENSEN – Broken sensor

Method description This method is intended to control active sensors that are sending the mea-
sured data in a regular time periods. The method works on a machine learning principles.
Classifier for sensor is in a learning state as long as the parameter LearnCycles determines.
The minimum coverage of training data that has to be satisfied by a classifier is defined by
parameter MinimalCoverage. The tolerance used to control individual variables is defined
by parameters PeriodTolerance and TrafficTolerance.
Method configuration It is appropriate to activate this method only for IP addresses that belongs
to sensors. All non-sensors IP addresses in the controlled range would cause high amount of
false positives. Appropriate place for monitoring the traffic is the central switch.
Method parameters
IgnoreShorterPeriods The choice to ignore the events caused by sensor transmission after
shorter than trained period.
PeriodTolerance The tolerated deviation from trained classifier for the time period (in per-
cents).
TrafficTolerance The tolerated deviation from trained classifier for rhe transferred data (in
percents). It the value of the parameter equals to 0, the detection of the transferred data
deviation is inactive.
ConceptDriftThr The count of consequent events to delete the classifier for the given device
and train a new one. If the value of the parameter equals to 0, the detection of the
concept drift is inactive.
MinimalCoverage The threshold for minimal amount of samples that are covered by the
classifier for given device to switch the classifier to the detection mode (in percents).
PerHourEnough The choice to enable the classifier to switch to the detection mode even if
the transmission count per hour is the only one successfuly trained metric.
LearnCycles The count of training cycles to collect the data for given device.
ReportImmediately The choice to report the anomalies immediately or in hourly summary.
Interpretation of results this method alerts to the wrong behavior of sensor (based on transmis-
sion period, bytes per packet or transmissions per hour). It is necessary to consider how large
and often deviation from standard behavior can be caused by defective sensor.
3.4.2 DNSQUERY – DNS query volume anomaly

Method description Method detecting an increased number of DNS queries sent by one station.
Number of DNS queries (one packet is considered as one DNS query) is counted for last hour.
The event is reported in case that the number is n-times greater than the average of the other
stations, where n is defined by parameter Multiplicator. The average is calculated only from
stations that sent more than MinimalQueryLimit queries. The DNS servers can be excluded
from this detection (value of the parameter ExcudeDNS is set to “yes”, default value is “no”).
network regardless of IP addresses. Appropriate place for monitoring the traffic is the central
switch.
Method parameters
MinimalQueryLimit The threshold for minimal count of DNS queries sent by single device.
Multiplicator The coefficient intended for computing the dynamic threshold. The threshold
is evaluated as a multiplication of this coefficient and the network average.
ExcludeDNS The name of the filter that defines the IP addresses which are allowed to send
increased count of DNS queries.
Interpretation of results This method reliably alerts to the increased number of DNS queries,
which can indicate the viral infection of the station identified as the event source.
3.4.3 RDPDICT – RDP attack

Method description This method is used to detect attempts to guess a user name /password for
Remote Desktop service (TCP/3389). The method builds a persistent tree of attackers and
victims and in the case of the exceeding limit values (20 attempts from a single IP address or
value of the options AttackAttempts) for a pair of attacker/victim an event is reported. The
data in the tree are stored for the period defined by TimeWindow parameter. This method
can be used to detect the distributed attack, too. There has to be at least so much attempts
by single attacker to a single victim, that is defined by multiplication of the PartOfAttack
and AttackAttempts parameters. The detection can be improved by specifying the minimal
number of targets of the attack using the MinTargets parameter. If needed, it is possible
to set the list of unusual ports on which is the RDP service provided besides the standard
TCP/3389 (ObscurePorts parameter). Most (not all) of the unsuccessful RDP connections
have TCP RST flag activated. Using the ResetFlag parameter is possible to limit the detection
only to these connections.
With this method it is possible to promptly detect the ongoing attack and block the attacker
before he can guess the password. If there is a greater delay between the attacker’s activities
(more than 30 minutes or value of the AttackHole option), the attack from a single IP address
can be interpreted as several separate attacks.
Method configuration It is appropriate to activate this method for all IP addresses and monitor
not only attacks against own servers, but also the attacks from own network to the Internet.
Appropriate place for monitoring the traffic is the central switch and the Internet connection
line.
Method parameters
AttackAttempts Minimal count of attempts to login from one attacker on the RDP service.
AttackHole If there isn’t any attempt to login for this time, the attack is marked as finished.
MinTargets Minimal count of targets of the attack to generate the event.
ObscurePorts Comma separated list of the port numbers different from 3389, on which is
the RDP service provided in the monitored network.
PartOfAttack If the given address is already a target of some detected attack, the attack from
different attacker is detected after less attempts to login (given by this ratio).
TimeWindow The attempts statistics are saved for given time (unless the attack is detected).
ResetFlag The choice to evaluate only the flows with TCP RESET flag set within the detection.
Interpretation of results The results of this method are relatively straightforward, the method
detects an attack against the RDP service.
3.4.4 SSHDICT – SSH attack

Method description This method is used to detect attempts to guess a user name /password or
login by forged certificate for SSH service (TCP/22). The method builds a persistent tree of
attackers and victims and in the case of the exceeding limit values (20 attempts from a single
IP address or value of the options AttackAttempts) for a pair of attacker/victim an event
is reported. The method is also capable to detect a successful attack based on an abrupt
change of statistical properties of the traffic and ending of the attack. With this method it is
possible to promptly detect the ongoing attack and block the attacker before he can guess the
password. If there is a greater delay between the attacker’s activities (more than 30 minutes
or value of the AttackHole option), the attack from a single IP address can be interpreted as
several separate attacks.
Method configuration It is appropriate to activate this method for all IP addresses and monitor
not only attacks against own servers, but also the attacks from own network to the Internet.
Appropriate place for monitoring the traffic is the central switch and the Internet connection
line.
Method parameters
AttackAttempts Minimal count of attempts to login from one attacker on the SSH service.
AttackHole If there isn’t any attempt to login for this time, the attack is marked as finished.
MinTargets Minimal count of targets of the attack to generate the event.
ObscurePorts Comma separated list of the port numbers different from 22, on which is the
SSH service provided in the monitored network.
MaxPackets Maximal count of packets per login attempt that are taken into account during
the detection. It doesn’t apply if 0. Ignoring of the flows with higher count of packets
lowers the false positive rate but it makes the success determination more inaccurate.
ExcludeUnsuccessful Unsuccessful attacks are not reported.
PartOfAttack If the given address is already a target of some detected attack, the attack from
different attacker is detected after less attempts to login (given by this ratio).
SuccAttack Minimal count of unsuccessful attempts before the successful attempts to con-
sider them as an attack, as well.
TimeWindow The attempts statistics are saved for given time (unless the attack is detected).
Interpretation of results The results of this method are relatively straightforward, the method
detects an attack against the SSH service. The method may produce false positives when
evaluating activities of some surveillance systems using the SSH protocol.
3.5 Derived behavior patterns
3.5.1 DNSREVERSE – DNS reverse records missing

Method description This method detects network devices without reverse DNS record. Reverse
DNS record is a standard means of configuration, which allows to convert IP address to DNS
name. It is also possible to determine the minimum amount of data that has to be sent by
the device daily to be included in detection (MinimalTransfer). The detection is performed
every day at midnight the previous day.
Method configuration It is appropriate to activate the method for all the IP addresses depending
on the DNS configuration policy of the organization. Appropriate place for monitoring the
traffic is the central switch and the Internet connection line.
Method parameters
MinimalTransfer The threshold for minimal amount of transferred data by single device for
last 24 hours (in MiB).
Interpretation of results This method can detect configuration problems, and also alert to new
or unauthorized devices on the network.
3.6 Anomaly detection system
3.6.1 Basic principles of anomaly detection
Automatic anomaly detection system provided by Flowmon ADS application works on the prin-
ciples of prediction based on short-time historical data. The statistics describing the network be-
havior are predicted for the whole network. In case the outlier between the predicted and the
current value occurs, the possible responsible device is identified and the event is generated.
The detail of the event always contains the predicted value of the relevant statistic, its current
value, its current value computed only for the responsible device and the procentual increase for
this device since the last batch of Flow data.
Automatic anomaly detection system is evaluating these statistics:
• Transferred data
• Transferred packets
• Established connections
• Communication peers
• Devices connected to the monitored network
• Amount of the requests
• Amount of the replies
• Amount of unsuccessful requests
• Amount of the TCP traffic
• Amount of the UDP traffic
• Amount of the traffic over other protocols
• Total count of services
• Count of provided services
• Count of used services
• The ratio of the unsuccessful connections to the whole traffic
The ANOMALY method that is used for automatic anomaly detection has to have assigned the
filter defining the monitored segment to work properly. Two parameters defining the sensitivity of
the classifier can be set.
The first parameter is the length of the sliding window (WindowLengthNet), that defines the
maximal age of data used for the current value prediction. It applies that the longer period is used,
the less adaptable is the classifier in general (therefore more sensitive).
The second parametr is the threshold value for the event detection (NetworkThreshold). This
value defines how much bigger has to be the current value than the predicted value to generate
the event. E.g. if the predicted value is 100, the value of this parameter is 2, then the current value
has to be bigger than 300 (= 100 + (2 × 100)) to generate the event. This parameter can be set to
two decimal places. The lower is the given value, the higher is the sensitivity of the classifier.
The MinimalPart parameter can be used for improving the event source identification. This
parameter defines minimal part of whole traffic relevant to single device and to the exceeded mea-
sure. If the device exceeds this threshold, it gets bigger weight (the devices under the threshold get
the weight equal to 1).
3.6.2 Method parameters

WindowLengthNet Count of hours (the length of the sliding time window) to collect the statistics
for monitored traffic.
NetworkThreshold The coefficient intended for computing the dynamic threshold. The threshold
is evaluated as a sum of predicted value and the multiplication of predicted value and the
coefficient. The computation of the predicted value is based on stored statistics.
MinimalPart The threshold for the minimal ratio of one device to the total traffic to be identified
as an event source.
StrictMode The strict filtering during the reverse tracing of the flows to be attached to the e-mail
reports. In case there are some e-mail reports with empty flow list, this option should be
turned off.
IgnoreInternal If the parameter is set to yes, the statistics for detection method are based only on
the communication with just one IP address in the assigned filter (source, or destination).
3.7 General system procedures
3.7.1 SYSCHECK – Data inconsistency

Method description The method is contolling the input data consistency and the effectivity of
current Flowmon ADS application settings.
Method configuration It is possible to configure the threshold ratio for each individual metric (e.g.
amount of unpaired flows) and set on or off the detection of wrong active timeout settings on
the Flow exporter or the detection of duplicit packets in the monitored network.
Method parameters
MinSingle The amount of unpaired flows in the processed sample of traffic to raise the warn-
ing (the control is not performed, if 0).
MinBroadcast The amount of broadcast and multicast traffic in the processed sample to
raise the warning (the control is not performed, if 0).
MaxDecrease The maximal value, to which can decrease current amount of transferred data
relative to the minimal of the foregoing 4 hours (the control is not performed, if 0).
DetectTimeout Activating the control of the active timeout different from the standard 300
seconds (5 second tolerance).
Duplicates Activating the control of the duplicit packets in flows (it is recommended to turn
this control off, if there is active sampling on the collector.
CoreCount Activating the control of the ineffective settings of CPU core count allowed to be
used by Flowmon ADS application.
MaxPerBatch The amount of the events generated by single detection method instance per
one processed batch to raise the warning (the control is not performed, if 0).
MaxPerHour The amount of the events generated by single detection method instance per
one hour to raise the warning (the control is not performed, if 0).
DeactivateOnFlood The multiple of the MaxPerBatch parameter – if exceeded, the instance
of the detection method is deactivated. The detection method is not deactivated, if 0.
MinDelta Minimal difference of timestamps. The detection is performed on the timestamps
of the first and the last flow of the batch and on the timestamp of the last flow and the
timestamp of the batch itself. The timestamp check is not performed, if 0.
Interpretation of results The method is generating simple warnings. These warning can be inter-
preted as some problems with Flow exporters (e.g. wrong configuration, incomplete data).
3.8 High level events, threat detection

The so called High level events are available in the Flowmon ADS application since the version
6.5. It allows to analyze the outputs of individual detection methods (simple events). The high
level events are known as threats in the Flowmon ADS application. The threats can represent
aggregation of the simple events or some deduction from the given sequence of simple events (E.g.
the detection of successful spread of the malware infection using SSH service can be described as
a sequence of the SCANS event, SSHDICT event and the SCANS event again. In case of the first
scanning, the victim of the infection is the target. In the second case, the victim is the source of the
scanning). Only aggregations are available in the Flowmon ADS application currently.
Threat detections can be activated, deactivated and configured using the relevant parameters.
The individual threat detections always depends on the set of the simple event detetections. If
there is no active dependency, the threat detection cannot be activated.
The detected threats are displayed in the own tab in the Dashboard:Overview view. The
source, start time, current end time, completion (there will be no further update to the threat,
if closed), aggregated details and the list of particular simple events (dependencies, that are aggre-
gated into the threat) are shown for each threat.
In the moment, the particular event is deleted, the threat is deleted too.
3.8.1 Common configuration
Each aggregation threat detection can be configured using the Window parameter, which de-
fines the maximal time window between two consecutive simple events (in seconds; if there is no
other desired simple event in the time window, the threat is closed).
3.9 Threat detections – aggregations
3.9.1 ACCESSATTACK – Network access attack

Method description The method is aggregating the simple events informing about the attacks
against authentication.
Dependencies SSH attack, RDP attack, Web form attack, Communication with blacklisted
hosts (Known botnet command & control center)
Method configuration The method does not provide any parameter other than the Window pa-
rameter.
Interpretation The threats has to be interpreted according to the number of particular events. In
case of very high number, it can be sign of an malware infection.
3.9.2 DATALEAKS – Potential data leaks

Method description The method is aggregating the simple events informing about possible data
leaks.
Dependencies Data upload anomaly, Country reputation, Web sharing traffic (only uploads).
Method configuration It is possible to set the minimal threshold for data sent out of the network
for particular event (Threshold parameter) except the Window parameter.
Interpretation The threats can be interpreted as a potential data leaks or as an use of the moni-
tored network to private purposes (e.g. uploading some vacation photos – but there could be
watermarked data in these).
3.9.3 DOSATTACK – Denial of service attack

Method description The method is aggregating simple events informing about different kinds of
denial of service attacks.
Dependencies Denial of service attack, Amplificated DoS attack, ICMP anomaly (ICMP smurf
attack, ping flood), Behavior anomaly (increased packet ratio)
rameter.
Interpretation The source of the threat is a victim of some kind of denial of service attack.
3.9.4 DNSTRAFFIC – DNS traffic anomaly

Method description The method is aggregating simple events informing about the nonstandard
DNS traffic.
Dependencies DNS traffic anomaly (large TCP DNS traffic, use of unusual/unauthorized DNS
server), DNS query volume anomaly
rameter.
Interpretation The threat can be interpreted as a presence of the malware infection on the device
(the DNS is used as a communication channel to the C&C center) or as a wrong configuration
of the device.
3.9.5 LARGETRANSFER – Large data transfer

Method description The method is aggregating simple events informing about the large data
transfers.
Dependencies High volume of transferred data, Internet connection utilization anomaly
rameter.
Interpretation The threat can highlight the longlasting or frequently recurring high data transfer-
res.
3.9.6 MALWARE – Malware infected device

Method description The method is aggregating simple events that could be the sign of malware
infection.
Dependencies Port scanning (scanning the 22, 23, 135, 137, 139, 389, 445, 1433 or 3389 ports),
SMTP anomaly, Telnet anomaly, Honeypot traffic, Target hosts/ports anomaly (only after
some of the other dependencies), Communication with blacklisted hosts (Known botnet
command & control center)
Method configuration It is possible to set the minimal count of targets for particular events
(MinTargets parameter) except the Window parameter.
Interpretation According the increasing number of the particular events is increasing also the
probability of the malware infection on the threat source.
3.9.7 MISCONFIGURED – Misconfigured device

Method description The method is aggregating simple events that could mean wrong configura-
tion of the device.
Dependencies SMTP anomaly (low number of e-mails using low number of mailservers), DNS
traffic anomaly (attempt to use unexpected/unauthorized DNS server), IPv6 tunneled traf-
fic
Method configuration It is possible to set the maximal number of mailservers and maximal
number of e-mails (MaxTargets and MaxEmails parameters) for particular SMTPANOMALY
events except the Window parameter.
Interpretation The source of the threat is probably wrong configured – it is trying to use the unex-
pected/unauthorized DNS server, or it is using the unauthorized SMTP server (but still sending
adequate number of e-mails).
3.9.8 NETANOMALY – Network anomaly

Method description The method is aggregating simple events related to the standard behavior of
the network.
Dependencies Behavior anomaly, DHCP anomaly, Multicast traffic
rameter.
Interpretation The threat is highlighting significant changes in the monitored network traffic.
3.9.9 NETDISCOVERY – Network discovery

Method description The method is aggregating simple events informing about the devices trying
to discover the monitored network.
Dependencies ICMP anomaly (scanning), Port scanning, Honeypot traffic
rameter.
Interpretation The threat source is discovering the monitored network and trying to find some
exploitable weaknesses.
3.9.10 PROXYBYPASS
Method description The method is aggregating simple events informing about the devices that
are bypassing (or trying to bypass) the specified proxy server.
Dependencies Direct internet communication
rameter.
Interpretation The threat is simple aggegation of the DIRINET events.
3.9.11 SPAMMER – Potential e-mail spammer

Method description The method is aggregating simple events informing about potential spam-
mers.
Dependencies SMTP anomaly, Communication with blacklisted hosts (Known SPAM sources)
Method configuration It is possible to set the minimal count of mailservers (MailServers param-
eter) for particular SMTPANOMALY events except the Window parameter.
Interpretation The probability of the threat source sending the unwanted e-mails is increasing
according the number of particular events.
3.9.12 SNIFFER – Potential network sniffer

Method description The method is aggregating simple events unveiling the devices that are pos-
sibly eavesdropping the traffic on the network.
Dependencies DHCP anomaly (fake DHCP server), L3 network anomaly
rameter.
Interpretation Threat source is probably eavesdropping the network traffic.
3.9.13 SRVOUTAGE – Service outage or misconfiguration

Method description The method is aggregating simple events informing about unavailable ser-
vices.
Dependencies Service not available
rameter.
Interpretation The threat is simple aggregation of the SRVNA events.
3.9.14 UNDESIRED – Usage of undesired applications

Method description The method is aggregating simple events informing about the use of appli-
cations, that could be undesired in the given environment.
Dependencies BitTorrent traffic, Instant messaging traffic, Online messaging traffic, TOR
traffic, TeamViewer traffic, Target hosts/ports anomaly, Web sharing traffic, Telnet
anomaly, Country reputation.
Method configuration It is possible to set the maximal count of targets for particular TELNET
events (Telnet parameter) except the Window parameter.
Interpretation The threat highlights using the services/application, that can be undesired in the
given environment – either with respect to theirs nature (BitTorrent), or with respect to the
security (Telnet).
4 User interface
The Flowmon ADS plug-in offers a complete Web user interface based on JavaScript and A JAX
technology. For basic control and accessing various parts of the application there is the main menu
on the left side. The upper part displays the status and information bar, the rest of the window
area serves as the user workspace. Another means of controlling application is a context menu
available by right clicking on relevant object.
Tips of the day are part of the application displayed after successful user login. After login to the
application a welcome screen is displayed. You can find there some important information about
what should be done before you start using the application.
4.1 Basic controls
4.1.1 Main application menu
The main application menu is a basic guidepost to all perspectives and features available in the
application. Related functions and views are brought together in joint groups. The main application
menu contains the following items:
Dashboard Overview of current network status
Overview Chart of the legitimate and undesirable traffic.

Events Overview of the most important and the latest events, summary of all recognized
events.
Events Set of views on events
Aggregated view Aggregated view brings together neighbor events of the same type of indi-
vidual device into continuous blocks, which are then graphically displayed on the time-
line.
Simple list A simple list of events, advanced searching and filtering of events.
By hosts A view of events grouped by IP addresses, which relate to the events.
Reports A set of HTML/PDF reports (reports on request) that summarize all information about
individual IP addresses available in the plug-in.
Generate report Generate report based on given template and time window.
Reports Configuring the templates used for generating reports.
Chapters Configuring the chapters of reports.
Scheduled reports Scheduling of automatic generating and sending reports via e-mail.
Configuration Function used to configure and manage plug-in

Configuration and management of plug-in is described in detail in Chapter 2 (Installation and
configuration). In this chapter we are not dealing with functions of the Configuration group.
About Displaying a brief information about the application and its version, information about the
number of processed flows, license information, access to user documentation, information
about skipped methods and batches during the data processing.
The currently selected menu item is always highlighted. The main application menu can be
hidden and thus increase the available workspace of the user. For hiding/displaying the main menu
of the application there is a panel separating the main menu from the workspace of the user with
the arrow icon (left – to hide, right – to display). Moving between the individual subsubsections can
be done using the tabs in the user workspace.
4.1.2 Status and information bar
Status and information bar indicates selected basic information concerning the application and
its user interface to the user (items are listed from left to right):
Drop-down menu Switching between individual plug-ins that are available on the Flowmon
probe/collector.
Flow sources problem indicator Status icon which has a green color when everything is working
correctly. If there are some warnings or errors, it changes color to orange or red. The most
recent error is displayed on the left of the icon. The number inside the status icon indicates
the number of unread messages. Click on the icon to open a window listing all messages,
time and severity. Users in the admin group can delete these messages.
Language switch An immediate switch of the user interface of the application to the language
selected by positioning the language switch (available English and Czech).
Help Link to the root page of the online help.
Logged on user The name of currently logged on user.
Logout Logs out currently logged user
4.1.3 Context menu
Context menu is a means for fast control of the application. Context menu brings together all
the actions that can be performed with element that is selected in the user interface. Context menu
appears after clicking the right mouse button.
Figure 7: Context menu of IP address/event
The most frequently used context menu is a menu of IP address/events which includes the
following items:
General information The translation of IP address on the DNS name, obtaining WHOIS informa-
tion and displaying custom information about IP address (if specified – see Configuring filters).
The data are displayed in a floating window.
Related events A view of events associated with the IP address, transition to the perspective of
Events\By hosts view.
External IP services Allows to display additional information about IP addresses using user de-
fined external internet services.
Aggregated events A view of aggregated events on timeline associated with the IP address, tran-
sition to the Events\Aggregated view.
IP Tools Common diagnostic IP tools
Locate in map Traces the physical location of IP address and displays it on the map. This
function communicates with an external service (Yahoo Maps) and for its functionality it
is necessary not to block the communication of the device (probe/collector) to port 80
(standard web traffic) and the External services has to be allowed.
Ping Check availability of selected IP addresses.
Traceroute Is a computer network tool for measuring the route path and transit times of
packets across an Internet Protocol (IP) network.
Resolve all IP addresses Translation of all visible IP addresses to DNS names.
Display events of this type A view of all events of the same type, transition to the Simple list
view.
Mark as false positive Marks the event as a false alarm, it will be no longer reported. It is possi-
ble to send an e-mail about the false positive event to the Flowmon Networks company. The
e-mail will consist from event details data, Flow entries that are related to the event, applica-
tion model and version and from the customer’s name. That data will be used to enhance
the performance of the application. The data will be processed in accordance with the law
on personal data protection. It is possible to add an explanation as a comment during the
marking procedure.
Manage event categories The classification of events into a user-defined categories.
Event details Transition to event details, displaying of related information (categorization, notes).
Event evidence A detailed view of events including all data flows from which the event has been
generated. The view is primarily intended for exporting the evidence from the application;
displayed Web page is adapted to copy its contents in plain text to the clipboard.
The menu item is only available if the given address of your Flow collector data is tied to the
event.
Visualize event A view of the events through an interactive chart based on Flow data caused by
the event.
The menu item is only available if the given address of your Flow collector data is tied to the
event.
Visualize events A view of method-specific visualisations.
Latency Graphical view of the latency of the packets between monitored devices.
Export as image This function opens focused dashboard or events table in new window as image.
It can be saved or copied into clipboard.
This function is available for Firefox browser only.
Export events to .csv This function exports the events from the displayed table into the CSV file.
Send feedback Allows to send the bugreport or feedback to Flowmon Networks company. The
form is placed on external web page.
Other specific context menu is given under the relevant parts of the user interface description,
namely the context menu available at some dashboard tables. Above the context menu there is
also a tooltip for IP addresses available. Tooltip contains information about the country where the
IP address is located.
4.1.4 Search criteria
It is possible to filter data in all views according to corresping search criteria. For greater clarity
are the search criteria devided to basic search criteria, that are displayed always, and to advanced,
that are available only in the complete form (the complete form can be open by clicking on the
bottom edge of the reduced form).
Figure 8: Example of reduced and complete search form
Basic search criteria Available in reduced search form
From, To The relevant period for displaying the information on the dashboard, the period
can be specified directly or chosen from associated calendar.
IPs, IP address, Targets IP addresses, which are to be given information on the Dashboard,
individual IP addresses can be separated by a comma. It is also possible to enter the
network address/mask, instead of IP addresses you can enter the DNS name.
In case of IP address field it is allowed to write only single IP address.
Advanced search criteria Available in complete search form
Categories User-defined categories of events

Event types Type of the events, in fact a reference to the detection method, which recognized
the event.
Filters Selection of the IP addresses, which are to be displayed.
IP’s role Role of the IP address (event source/target)
Max. rows Maximal number of rows that are displayed
Flow sources Flow sources
Perspective, Priority Rules for the prioritization of events, eventually minimal displayed pri-
ority.
4.2 Dashboard
Dashboard is a basic interface element that is displayed to the user right after logging on to the
application. Dashboard is used to obtain an overall picture of what is happening on the network
via a set of top 10 statistics. The default view shows events for the last 24 hours with the possibility
of adjusting the view by changing the corresponding search criteria (From, To, IPs, Event types,
Filters, FlowSources).
According to dashboard part (Overview, Events only relevant search criteria are available.
4.2.1 Overview
The Overview chart allows to view the comparison of transferred data (packet count, flow
count) with respect to the priority of the events that are detected using this data. If the data were
used to detection of more events with different priorities, the data are displayed according the
highest priority, that was achieved. The color assignment to priorities follows: Critical and High
priorities – red, Medium priority – orange, Low and Information priorities – yellow.
Data can be filtered by start and end time, the perspective and the Flow source.
It is possible to mark the shorter time period. The available information are displayed for the
marked interval. You can use the context menu over the marked interval to display this data in
other views (Aggregated view, Simple list, By hosts and Dashboard events) or to zoom in or out.
You can shift the marked interval using arrows in right lower corner of the chart and switch the
scale of the vertical axis (linear, logarithmic, left upper corner of the chart).
Figure 9: Dashboard: Overview
4.2.2 Events
Top 10 events by priority The table shows the 10 most important events from the chosen per-
spective.
Within the table, you can:
• Change the perspective through the Perspective drop-down list

• Switch table/chart view
• Restore the content of the table according to currently configured filters
• View all events according to selected perspective, transition to the Events\Simple List,
view the chart including the legend
The latest 10 events Table displays 10 newest events.


• View all events according to selected perspective, transition to the Events\Simple list
Top 10 events by event type The table shows the top 10 event types along with the number of
occurrences of the events of that type.

• View a complete table of all kinds of events along with the number of occurrences of the
events of given type in a new tab, view the chart including the legend
• Display the context menu above the type of an event, which allows you to search all
events of the type (Display events of this type), transition to the Events\Simple list
view
Top 10 IPs by event count The table shows the 10 IP addresses, which produce the greatest num-
ber of events.

• Restore the content of the table according to currently configured filter
• View a complete table of all IP addresses with the number of occurences of the events
with given IP address as a source in a new tab, view the chart including the legend
Events in last batch The table shows maximum 10 event types, which was detected during the
last processed batch of data.
• Restore the content of the table according to currently configured filter
• View a complete table of all events in last batch, transition to the Events\Simple list view,
view the chart including the legend
• Display the context menu above the type of an event, which allows you to search all
events of the type (Display events of this type), transition to the Events\Simple list
view
4.3 Events
4.3.1 Aggregated view
Aggregated view presents events of particular device in an intuitive graphical way considering
the aspect of time.
Events are filtered by the following search criteria: From, To, IPs, Event types, Filters, Flow-
Sources, Categories, Perspective.
Each event type the device takes place in a given time period is represented by one line called
a swimline.Event occurrences are represented by a colored rectangle in a particular swimline.
Event occurrences are represented by a colored rectangle in a particular swimline. According to
the selected scale the neighbor events are aggregated into one rectangle. Lenght of the rectangle
corresponds to the time length of the event. Time goes prom from left to right at the x axis. For
clarity the night and the day alternation is displayed.
Visualization interaction
Zoom User can zoom in visualization (showing in a larger scale) by using left mouse button to
select the requested time interval. There are “Undo” and “Redo” icons on the right side above the
visualization to navigate through changes of the scale. Using the icons “Plus” and “Minus” you can
change the size of colored rectangles in a swimline.
Event details By right clicking on the event (green rectangle) it is possible to display context
menu allowing displaying event details (IP address, start time, end time, summary) or transition
Figure 10: Example of displaying aggregated events
to Events\Simple list with the corresponding events. The detail summary can be shown only for
events detected after installation of application Flowmon ADS version 2.08.00 because of migration
to new technologies, which allow us to aggregate the events into the high level events better.
Computing aggregated event details, which consists of more than 25 events is accelerated by
sampling. When sampling is used there is information about lower accuracy of data in event detail.
4.3.2 Simple list
View of events in the form of a simple list (events table). It is primarily sorted by the time of the
event creation.
Events are filtered by the following search criteria: From, To, Source IP, Targets, Filter, Method,
Categories and Perspective.
User can show directly the Event details view of the event with known event ID using the search
dialog available after clicking the magnifier glass icon in upper right corner of the search criteria
box.
The results of query are divided into pages where one page contains a maximum of 500 items
of the result. The result is a table that includes the following items:
Figure 11: Example view of events grouped by IP addresses
Row number Number of the table row
Event source Event originator (IP address)
Type Type of event, in fact a reference to the detection method, which recognized the event.
Detail Detailed information on the event
Timestamp Time stamp of event generation
Flow source Flow data source on which the event has been generated
Targets Event targets (a list of IP addresses). At most 10 items is shown in the table. If more targets
are associated with the event they are available on request in a dialog window.
It is possible to export the output into the CSV file by clicking Export events to .csv in context
menu.
4.3.3 By hosts
A table view of the events grouped according to the sources and targets of events.
Events are filtered by the following search criteria: From, To, Source IP, Filter, Method, Cate-
gories, Perspective, IP’s role and Number of events.
The result table is sorted according to the IP addresses, for each IP address the number of
events where the IP address is the source or the target of the event is displayed. Consequently,
it is possible to view a list of event types related to the IP address. For each event type can be
displayed specific events in the form of a separate table, which includes the same data as in event
table Events\Simple list.
4.3.4 Event details
The Event detailsview is unlike other event views available only through the context menu.
Event details include all available information about the event, event comments and classification
of events into categories.
Event details include the following information:
Type Type of event, in fact a reference to the detection method, which recognized the event
Timestamp Timestamp of event generation
First Flow Timestamp of the first Flow on which was based the event detection
Event source Event originator (IP address)
Captured source hostname DNS name assigned to the IP address at the time of event detection
Detail Detailed information on the event
Probability Probability with which the event has been detected
Flow source Flow data source on which the event has been generated
False positive Indicates whether it is a false positive (according to rules for marking events as
false positives currently in effect). Event can be marked as a false positive by Mark as false
positive context menu item. When marking an event it is necessary to enter time relevance of
marking (individual days of the week, time tolerance). Marking of an event as a false positive
means that event of the same type and originator will not be generated if there is a rule for
marking the events as the false positive in effect.
Targets Event targets (a list of IP address). The targets can be shown grouped by the appropriate
countries or address prefixes.
User Identity User ID from domain controller (for more information see Flowmon collector docu-
mentation)
Further for each event there are chronologically listed related comments. The comment always
includes the author (Author) and a timestamp of comment insertion (Timestamp). Comments
may be changed (Change) or deleted (Delete)depending on the author and currently logged on
user. It is always possible to add a new comment (Add new comment).
Event details also include event categories. The category always includes the author (Author)
and the timestamp (Timestamp). Individual categorization can be removed (Remove) or added
(Add to category). Note that the management of event categories is also available through Man-
age event categories context menu item.
Figure 12: Example of event details
4.3.5 Interactive event visualization
The Interactive event visualization view enables to view the network traffic data, based on
which the event was detected. The view is available for each event detected on the basis of network
traffic through the Visualize event context menu item. Similarly as in the Event details view the
event details are displayed first in the table to make clear what the event is visualized.
Interactive visualization displays individual IP addresses as nodes and data transmission be-
tween the IP addresses as edges. Size of nodes and edges is proportional to the volume of trans-
mitted data and their colors ranged from green to red are corresponding to the number of flows.
Event visualization can be interactively traversed; each node has a context menu marked by sym-
bol “+”. The item More data of this menu ensures downloading of all relevant IP address com-
munication. The item Info obtains and displays the details of the network traffic in the form of
a floating table. For nodes it displays table of aggregated communication with other IP addresses.
For inbound traffic the communication is aggregated on source IP address, destination port and
protocol. For the outbound traffic it is aggregated on the destination IP address, source port and
protocol. For edges it displays a table of individual data flows that constitute the edge including
details such as the duration of the connection, flags and the type of service (TOS).
Special type of node is called aggregation. Aggregation represents a larger number of IP ad-
dresses and is visualized as a circle shaped node. Clicking on such a node displays a list of IP
addresses that constitute the aggregation. Selecting any of the displayed IP address will tear it
from the aggregation. Furthermore it is possible to work with the IP address and details of its
communication by a standard means that are described above.
Figure 13: Example of interactive visualization of events
4.3.6 Event evidence
The Event evidence view provides the means to export the evidence (network data flows on
the basis of which the event was detected) from the application. Displayed web page is adjusted to
be able to copy its content to the clipboard in a plain text. For each event there is the event type,
timestamp of event creation, event originator, event details and targets.
It is followed by the histogram, which could display relations between various pairs of vari-
ables. Below is displayed the list of data flows (raw Flow data from the collector). The displayed
Figure 14: Example of Event evidence view
information includes the source and the target IP address, time stamp of the data flow, its dura-
tion, protocol, source and destination port, the volume of transferred data, number of transmitted
packets and the type of service.
The listed flows can be filtered along one of the columns. The filter can be defined by chosing
the column and the relation from the lists and by writing the constant into the text box.
The listed flows with the same (or reversed) tuple source IP address, destination IP address,
source port, destination port and protocol can be highlighted using the context menu over the
single flows (Flows coloring\Follow flow). The flows without corresponding opposite flow can be
highlighted using the Flows coloring\Single flow item.
The list in the user interface is limited to 10000 flows. The exported text file includes all appro-
priate flow records.
4.4 Reports
The reports are a means to obtain complete information about the IP address/IP addresses
registered in the application. Reports save the information on events into an assembly, which can
be directly exported to the PDF.
The reports consist from chapters, which could be modified by user.
4.4.1 Chapters
Following types of chapters are defined:
Overall status report It displays the network traffic overview chart and the traffic statistics table.
Event matrix Table of the most important events in the network. It is displayed by single days and
devices.
Event list List of the most important events in the network displayed as in Events\Simple list
view.
Events count by type List (and the piechart) of the counts of the most important events in the
network.
The given chapter consists from the given type and parameter settings. It is possible to create
more chapters of same type but different settings.
Only admin user can create, edit and delete the chapters. The user is warned if the deleted
chapter belongs to some report. If the deleted chapter is the last one in the report, the user will be
warned and the report will be deleted, too.
4.4.2 Reports
The report is defined as the sequence of chosen chapters. Each user can create and edit his
own reports. The user can mark the report as public (it could be seen by other users). The common
user can edit or delete only his own reports, the administrator can see, edit or delete all reports.

To generate the report it needed to choose one of the defined report templates and specify the
time window, which will be included into the report. The generated report can be directly exported
to the PDF. Generating the report can consume much time and system resources with respect to
the chapter parameters settings and the chosen time window. The generating of the report can be
interrupted anytime.
4.4.3 Default report
It could be used also the default report template beyond the user defined report templates. The
default report consists from following chapters:
Overall status for Security Issues Based on the Security Issues perspective, the chart is gener-
ated along the flow count in the logarithmic scale for each Flow source separately.
Overall status for Operational Issues Based on the Operational Issues perspective, the chart is
generated along the flow count in the logarithmic scale for each Flow source separately.
Event matrix for Security Issues For the priority HIGH or higher.
Event matrix for Operational Issues For the priority HIGH or higher.
4.4.4 Scheduling reports
The Flowmon ADS application allows to set up the automatic report generating and sending
in the PDF format. It is necessary to choose the report to generate (Report), activate/deactivate
the generating and sending (Active), select the period used for the generating (Interval). When
is the daily or weekly reporting selected, it is necessary to choose which weekdays are the reports
generated. Using the monthly generated report, the report is generated at the first day of the next
week. Using the Custom interval (it is needed to choose the first and last day of the report), the
report is generated at the end of the given period.
It is possible to set the e-mail addresses of the sender (Sender email) and of the recipients
(Recipient emails).

Contacts
Flowmon Networks, a.s.

U Vodarny 2965/2
Brno 61600
Web: www.flowmon.com
Email:info@flowmon.com
Tel.: +420 511 205 251
Feedback
We would be pleased if you tell us your comments to this text (typing errors, incomplete or unclear
information). Please, contact us via email support@flowmon.com.
Copyright
This document is intended for informational purposes only. Any information herein is believed to be reliable. However,
Flowmon Networks assumes no responsibility for the accuracy of the information. Flowmon Networks reserves the right
to change the document and the products described without notice. Flowmon Networks and the authors disclaim any
and all liabilities.
Except as stated herein, none of the document may be copied, reproduced, distributed, republished, downloaded, dis-
played, posted, or transmitted in any form or by any means including, but not limited to, electronic, mechanical, pho-
tocopying, recording, or otherwise, without the prior written consent of Flowmon Networks. Any unauthorized use of
this specification may violate copyright laws, trademark laws, the laws of privacy and publicity, and communications
regulations and statutes.
Flowmon logo is a trademark registered to Flowmon Networks, a.s. Other brands and product names are trademarks of
their respective owners.
This product contains NfSen and Nfdump software Copyright © 2004, SWITCH - Teleinformatikdienste fuer Lehre und
Forschung.
All other trademarks are the property of their respective owners. Copyright © 2007 – 2016 Flowmon Networks, a.s. All
rights reserved.

Flowmon Ads Business Userguide en 2

Uploaded by

Copyright:

Available Formats

Flowmon Ads Business Userguide en 2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Flowmon Ads Business Userguide en 2

Uploaded by

Copyright:

Available Formats

Flowmon ADS Business 8.02.

2 Installation and conﬁguration 11

3.1.3 Flow sources and assigned ﬁlters . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.4 Advanced network behavior patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

User documentation is divided into the following chapters:

1.1 Features and capabilities

• Implementation of Bidirectional ﬂows standard (RFC 5103)

• A comprehensive dashboard with a direct indication of problems in the network

• Integration of tools for obtaining additional information (DNS, WHOIS)

• Automated outputs via e-mail, syslog, SNMP or custom scripts

• Remote traﬃc capture triggered by generated events

1.2 Selected detection methods

• Anomaly detection system based on changes in the behavior proﬁle

• Detection of heterogenous communication

• Detection of transmission of large volumes of data in the network

• Detection of service unavailability

• Detection of parasite device

Detection of remote management:

• Detection of Telnet protocol

• Detection of sharing desktop using TeamViewer

• Detection of dictionary attacks on SSH services

• Denial of Service type attacks

• Detection of TCP scans

• Detection of outbound SPAM

Error checking at the configuration level:

• Detection of IP addresses without reverse DNS records

• Detection of delays on the network

Usage of unwanted services:

• Detection of Instant Messaging (ICQ, Jabber, MS Messenger, Google Talk, ...)

• Detection of BitTorrent P2P network

• Detection of different Voice-over-IP protocols

• Detection of different VPN connections and tunnels

• Detection of direct communication into the internet

1.3 Basics of application

Figure 1: User interface preview

1.4 Distributed architecture

1.4.1 Architecture description

1.4.2 Node types

Proxyslave Slave node concurrently used as a Proxy node.

2 Installation and configuration

2.1 Installing on probe/collector

2.2 Quick configuration

• Enter a unique Name

2.3 Detailed configuration

2.3.1 Data storage settings (Settings\Storage settings)

In this section you can modify settings of the data storage.

2.3.2 Application settings of the plug-in (Settings\Application

2.3.3 Configuration (Settings\Configuration)

Clear DNS cache button.

Figure 2: Conﬁguration changes view

2.3.4 Displaying configuration changes (Settings\Configuration

2.3.5 User Permissions (Settings\User Permissions)

User permissions conclusion

• User permissions for non-admin users

• Hidden pages for non-admin users

– Settings \Storage settings

• Read-only pages for non-admin users

– Settings \User permissions (Only permissions assigned to him)

– Processing \Flow sources (According the perspectives assigned to him)