PREPARE/tracing

TraCINg-Server

A webserver gathering malware incidents and visualizing them in multiple ways.

TraCINg (TUD Cyber Incident moNitor with TUD as an abbreviation of Technische Universität Darmstadt) is a project proposed by Emmanouil Vasilomanolakis from CASED (Center for Advanced Security Research Darmstadt) visualizing attacks of malware on the internet. Attacks are observed using honeypots especially the honeypot dionaea in conjunction with jsonfeeds and the honeypot HosTaGe but can be extended to use arbitrary honeypots, intrusion detection systems (IDS) and similar software.

This product includes GeoLite data created by MaxMind, available from http://maxmind.com/.
This project was inspired by but is not based on the Honeynet Project.

Features

Backend

The backend consists internally of two servers: A HTTPS server receiving sensor data and a HTTP server serving a website to visualize this data. Sensors are honeypots (or intrusion detection systems) collecting information about attacks of malware.

The HTTP server acts like a simple webserver with static content. Dynamic content is served using Socket.IO.

The HTTPS servers purpose is to receive sensor data, to store them in the database and to broadcast it via socket.io to every client currently viewing the content of the HTTP server. The encryption is mandatory to protect the sensors identity by hiding the content of the data transmission. This is necessary to avoid revealing the IP addresses of sensors by observing the transmitted content which could lead to blacklisting of sensor IPs in malware. Note that sensors are encouraged to hide their IP addresses using for example Tor to avoid revealing their IPs in an observation of the traffic to the HTTPS server with the assumption that every sent message to the HTTPS server is most likely sent from a sensor.

In order to receive genuine sensor data an authentification is used to recognize trustworthy sensors. This authentification is based on a public-key infrastructure (PKI) using a certificate authority (CA) to sign the client certificates. The authentification is based on sending the client certificate at the TLS handshake and verifying it on the server using the CA certificate.

Thus authorizing a sensor requires the sensor to send a certificate request to the CA and to get a valid certificate from the CA.

Frontend

The website visualizes malware attacks from the internet in five different ways (described below). Incidents will be shown live if in Live-View or can be retrieved by a database query if in Database-View. Additional features are an about and help screen to guide and inform the user.

2D Country View

The country view shows a map which contains only country borders. It can be moved and zoomed both with the mouse or the keyboard.
Attacks are shown as a marker in the country where the attackers IP was mapped to. Hovering a marker shows information about this specific attack and how many attacks originated from the same place.
Additionally countries are colored in a red shade depending on the ratio of markers in that country.

2D Map View

The map view behaves much like the country view but omits coloring of the countries. Instead it shows a more detailed map using OpenStreetMap map material.

3D Globe

The globe behaves much like the country view in the 3D space with the enhancement of adding a heatmap-like view of the markers which can be toggled with the keyboard.

Table View

The table view shows a sort- and searchable table containing detailed information about each attack. If the sensor was able to copy the malware the malwares md5sum is given in addition to a link to VirusTotal where one can get more detailed information about this specific malware. It is also possible to have a look into logs which dionaea creates to record every attack.

Statistics

The statistic shows either the number of attacks per country or per type in a specific time span. The data can be filtered in several ways (the same is possible in Database-View):

• show only authorized sensors data
• select countries
• select attack types
• select sensor types Note that statistics can only be applied to data queried from the database (though the statistic itself is independent from Live-View and Database-View).

Requirements

System Packages

In order to run the server one must install the following packages (preferably with the systems package management system):

• openssl
• sqlite3
• node.js

For example using pacman: pacman -S openssl sqlite3 nodejs

Node Packages

Additionally the following npm packages are required to be installed:

• socket.io
• sqlite3
• orm
• node-static
• geoip
• validator

You can call npm install in the root directory of this repository to install the dependencies.

Website Libraries

To run the website one must provide several external libraries (at least the javascript and css files) in the frontend/extern folder:

• bootstrap (including images)
• jVecorMap, world map
• leaflet (including images)
• globe.js (including images), requires three.js
• highcharts
• jQuery
• jQuery UI (including images)
• jquery-ui-multiselect-widget
• jrange
• jquery-throttle-debounce
• datatables (including images), datatables bootstrap plugin

Instead of installing all these libraries manually we encourage you to use the provided fetch.sh script to download them automatically along with the MaxMind GeoLiteCity database described in the next section.

MaxMind GeoLiteCity Database

One must download the GeoLiteCity.dat file provided by MaxMind at http://dev.maxmind.com/geoip/legacy/geolite/ and place it in the same folder as index.js.

Certificates

To run the HTTPS server part one must provide at least a self signed server certificate along with the corresponding private key. To use the server to its full extent (with sensor authentification) one must prepare a public-key infrastructure (PKI) containing a certificate authority (CA) which signs the server and sensor certificates. Hence one must provide the following files:

• server certificate (signed by the CA)
• server private key
• CA certificate

Note that the certificates and private keys must be provided in the pem format.

To test the functionality one may use the provided genKeyCert.sh script which generates CA, server, simulator and several client certificate/private key pairs in the ssl folder. Note that these keys are weak (only 1024 bit long and not encrypted with a passphrase) and are valid for just three days.

Usage

To start the server execute node index.js. If the servers private key is encrypted you must unlock the key by entering the passphrase.
You may use the simulator (requires python 3 along with the Requests library) to simulate a sensor and thus test the functionality of the server.

Configuration file

The server comes with a configuration file (config.json) which must be adapted to the users preferences:

{
	"db": "sqlite:///tmp/test.sqlite?debug=true",
	"server": {
        	"httpPort": 8888,
        	"httpsPort": 9999,
        	"webroot": "./frontend"
	},
	"ssl":  {
		"keyPath": "ssl/server_key.pem",
		"certPath": "ssl/server_cert.pem",
		"caPath": "ssl/ca_cert.pem",
		"requestCert": true,
		"rejectUnauthorized": false
	}
}

• db: the path to the database storing attack data monitored by sensors
• geoip: the path to the GeoLiteCity.dat file provided by MaxMind
• server:
  • httpPort: the port of the HTTP server (serving the website)
  • httpsPort: the port of the HTTPS server (receiving sensor data)
  • webroot: the webroot containing the websites content
• ssl:
  • keyPath: the path to the server private key
  • certPath: the path to the server certificate
  • caPath: the path to the CA certificate
  • requestCert: if true the server requests a certificate to check sensors authenticity
  • rejectUnauthorized: if true unauthorized sensors are rejected

Server Interface

A sensor must stick to the following JSON notation of a data entry to be able to send data to this server. Note that the data entry must be in one line and must not be separated by line breaks as shown here for a better readability:

{
	"sensor": {
		"name": "sensorName",
		"type": "sensorType"
	},
	"src": {
		"ip": "sourceIP",
		"port": "sourcePort"
	},
	"dst": {
		"ip": "destinationIP",
		"port": "destinationPort"
	},
	"type": "incidentTypeID",
	"log": "incidentLog",
	"md5sum": "incidentMd5sum",
	"date": "unixTimestamp"
}

This data must be sent via a POST message to the HTTPS server in order to be received correctly. The sensor may send multiple datasets in one POST message each separated with a "\n".

The following table shows which data fields may be omitted and which are mandatory along with the default values:

Field	Description	Datatype	Example	Default Value
sensor.name	sensor name	String	Sensor1	"Unknown"
sensor.type	sensor type	String	Honeypot	"Unknown"
src.ip	attacker IP	String	130.83.151.135	mandatory field
src.port	attacker port	Integer	54321	0
dst.ip	attacked IP (sensor IP)	String	130.83.151.136	empty string
dst.port	attacked port (sensor port)	Integer	80	0
type	attack type (cf. next table)	Integer	11	"Unknown"
log	attack log	String	TCP accept...	empty string
md5sum	md5sum of a malware	String	0e65972dce...	empty string
date	date of the attack	Integer	1376645816	unix time of the server

The following table shows the association between attack type numbers and attack type definitions:

Attack Type	Attack Name	Attack Description
0	Unknown	The sensor could not determine the attack type
10	Transport Layer	The attacker connected to an open port, but did not interact with it
11	Portscan	The attacker tried to connect to a closed port
20	Shellcode Injection	The attacker successfully used an emulated security issue and would have been able to execute malicious code
30	SQL	Attack on a database server
31	MySQL	Attack on a MySQL database server
32	MS SQL	Attack on a Microsoft database server
40	SMB	Attack on a SMB file server
50	VoIP	Attack on a Voice over IP device

Note that these attack types are based on the ability of dionaea to distinguish between these types of attacks.

Examples

Websites running this server:

• http://ssi.cased.de