Michael Stahn db166545f5 initial commit | il y a 9 ans | |
---|---|---|
.. | ||
TraCINg-Server | il y a 9 ans | |
frontend | il y a 9 ans | |
modules | il y a 9 ans | |
ssl | il y a 9 ans | |
Changelog.md | il y a 9 ans | |
GeoLiteCity.dat | il y a 9 ans | |
GeoLiteCity.dat.gz | il y a 9 ans | |
LICENSE | il y a 9 ans | |
README.md | il y a 9 ans | |
attack_stats.txt | il y a 9 ans | |
config.json | il y a 9 ans | |
config.json_bak1 | il y a 9 ans | |
fetch.sh | il y a 9 ans | |
genKeyCert.sh | il y a 9 ans | |
gulpfile.js | il y a 9 ans | |
index.js | il y a 9 ans | |
package.json | il y a 9 ans | |
simulator.py | il y a 9 ans | |
simulator_proberesponse.py | il y a 9 ans |
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.
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.
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.
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.
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.
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.
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.
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):
In order to run the server one must install the following packages (preferably with the systems package management system):
For example using pacman: pacman -S openssl sqlite3 nodejs
Additionally the following npm packages are required to be installed:
You can call npm install
in the root directory of this repository to install the dependencies.
To run the website one must provide several external libraries (at least the javascript and css files) in the frontend/extern folder:
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.
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.
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:
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.
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.
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
}
}
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.
Websites running this server: