notes meeting 29 September 2015

[gijzelaerr]

my notes untill I had to leave the meeting:

• packetbeats also optie? losse module, geen honeypot
• per component bepalen welke taal de voorkeur heeft (door de persoon die daar veranwoordelijk voor is)
• stukje over github uitbreiden, gijs beheert document, document kan worden aangepast via PR's en issues.

antwoord van vragen:

• transport network - support both VPN en honeytrap-agent
  *

[gijzelaerr]

notes from Rogier:

Open questions beantwoording uit het document:
-honeytrap-agent en OpenVPN willen we naast elkaar ondersteunen. OpenVPN
op de dedicated sensoren en de honeytrap agent op laptops/servers waarop
al diensten draaien. Dit moet onafhankelijk van elkaar blijven.
-Partijen kunnen het framework inclusief centrale componenten zelf
deployen indien dat wenselijk is.
-het framework moet zo adaptief mogelijk zijn om zoveel mogelijk low
interfaction en ook high interaction honeypots te kunnen ondersteunen.
Voor het eind v.h. jaar willen we als demonstrator: dionaea, artillery,
suricata en honeytrap in een test omgeving beschikbaar willen hebben
-Voor de OpenVPN sensoren willen we we een vergelijkbare sensor
start/stop/update mechanisme willen hebben zoals SURFids. Ten aanzien
van de honeytrap agents willen we een vergelijkbare management. Het
bijhouden en aansturen van de agents/openvpn's moet aparte omgeving
worden, los van director en visualisatie
-oude SURFids scripts moeten alleen gebruikt worden indien ze
toegevoegde waarde hebben. Ze moeten wel geupdate worden.
-what are we going to store -> we zijn flexibel met elastic search maar
willen wel alle honeypots kunnen ondersteunen
-CentOS USB live -> ? Vraag is of de bank het acceptabel vindt dat
sensoren debian live draaien
-Encapsulating the honeypots -> We willen containers kunnen supporten
alsmede honeypots in VM's en/of fysiele machines
-docker -> lxc containers liggen meer voor hand om te gebruiken, in elke
container moeten verschillende OSen (distro) ondersteund kunnen worden

Regarding management of the nodes/agents: in order to be able to start/stop VPN there needs to be a control channel outside the VPN. So, management of start/stop VPN are completely independent of the VPN management, i.e. the eduVPN software.

For deploying. Instead of a focus on Debian it may make sense to focus on OpenWrt instead. It is possible to buy <= $15 devices that can run OpenWrt and be able to act as an agent. One would need to be able to figure out how to reduce the size of the Go binaries where they currently are way too big and be able to compile for ARM/MIPS. Not sure this is possible.