Description Company: None


Nemea

Keywords: Flow traffic analysis, network monitoring

Functional Components Description

Nemea system consists of separate building blocks called modules which are interconnected by interfaces. A module is a separate system process receiving a stream of data on its input interface(s), processing it, and sending another stream of data through module’s output interfaces(s). There are modules for data acquisition (e.g. receiving NetFlow/IPFIX records), preprocessing, detection of various types of malicious traffic or anomalies (network attacks, link failure…), postprocessing of detection results, logging and reporting.

Use request Open Source

Services provided: The NEMEA Framework implements the communication layer, flexible format called UniRec and other common tasks. As such when installed it detects network security events in flow data.

Current UsageNemea is deployed in CESNET backbone network infrastructure, SWITCH, Casablanca.

Technical equipment: CESNET network backbone

Services:


IPFIXcol

Keywords: Flow record collector

Functional Components Description

PFIXcol framework is a set of:
- IPFIXcol - collector for capturing IPFIX NetFlow data
- input, intermediate and storage plugins for collector
- tools for data processing etc.

Use request Open Source

Services provided: IPFIXcol is a flexible IPFIX flow data collector designed to be easily extensible by plugins. It loads input, intermediate and output plugins on startup. Each input plugin runs in a different process. IPFIXcol corresponds to RFC7011

Current UsageIPFIXcol is deployed in CESNET backbone network infrastructure, SWITCH, Casablanca.

Technical equipment: Network monitoring

Services:


NERD

Keywords: Network entity reputation database

Functional Components Description

First, there are several databases. The main one, called entity database, stores all the entity records. There is also a separate database to store original data from primary sources (events, alerts). These may be actually multiple databases, since different technologies may be suitable for different types of data. At last, there is an instance of a fast in-memory key-value database (Redis), that serves for storage of various, often temporary or fast changing, data that need to be accessed globally by different components. It also serves for various logging and caching purposes. The main input of the system is represented by a set of primary data receivers. They receive messages, alerts, or entity lists from the primary data sources and put tasks (called update requests) to a global queue to create or update records of related entities. The tasks are processed by the core of the system – a set of workers. They apply the requested updates on given entity records. Also, the workers fetch data from external (secondary) sources and compute other attributes. This functionality is handled by plug-in modules, so it is easy to add, change or remove secondary data sources or computed attributes.
The workers may run in any number of instances in parallel, which makes the system easily scalable. Tasks are distributed to workers according to a hash of the entity identifier (a task always involves processing of a single entity record only), so the same record is always handled by the same worker. This helps to avoid a need for record locking and other concurrency issues. If the processing core or a plug-in needs to store a global state information, it is stored outside the workers, usually in the Redis database. Most of the plug-ins fetches data from external sources. Depending on the type and availability of the data, three methods of data acquisition are used: (i) the data are queried directly from their original sources by the plug-in module (for example, whois data are got this way); (ii) there is a special microservice or a cache to provide easier or more efficient access to the data (an example Services provided From a user’s point of view, the Network Entity Reputation Database (NERD) system is an online portal where the user can search any IP address, domain name or another network identifier (an entity) and get all security related information known about it list of all alerts that reported it as a source of some malicious activity, whether it is listed on some blacklists or other databases, related information from DNS, whois, geolocation, or data from internet wide scanning services. It is also possible to search for entities that match various criteria and sort them by various attributes or by a score summarizing the associated threat level. There is also a REST API for easy integration of the data into any other security or threat intelligence system. Behind the web portal and the API, which servers to access the data, there is a complex, modular system to acquire and process data from various sources, store them to the database and periodically update them.

Use request Open Source

Technical equipment:
Server:
- Virtual server WMware
- 8x vCPU (Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz)
- 32 GB RAM
- 132 GB


Warden

Keywords: Network security, event sharing, platform

Functional Components Description

The architecture of the WARDEN system is that of the client – server type. The Warden system consists of a server, receiving clients and sending clients. The server, on request of receiving clients, distributes new (previously undistributed) events fed to the server by sending clients. Each entity/network that wishes to feed data into the WARDEN system should have a so called sending client. Each entity/network that wishes to receive data from the WARDEN system should have a so called receiving client. The server (the centre) ensures the data reception and storage as well as the interface for the access to data stored. Data which the clients send into the centre will be referred to as events. Events are sent by the clients after authentication; the access to the centre is also authenticated. X.509 is used for the authentication.

Current UsageThe Warden system is currently developed and deployed mainly to satisfy the needs of the national research and education network CESNET2 administered by the CESNET association for its members and other entities involved. In the future, we plan to develop the Warden project as open. Until then, non-members of CESNET2 wishing to participate in the project can participate only based on ad-hoc agreements.

Use request Open Source

Technical equipment:
Server:
- Dell PowerEdge R410
- 2x Intel Xeon L5640 (2.26GHz, 6C, 12M Cache, 5.86 GT/s QPI, 60W TDP, Turbo, HT)
- 32 GB RAM, DDR3-1066MHz
- 540 GB RAID5 HDD (3x 300GB, 15k RPM, 3.5” SAS; PERC H700A RAID Controller)
-2 port Broadcom NetXtreme II BCM5716 1000Base-T (C0) PCI Express

Services: