make a honeytrap binary that will start subprocesses like:

• honeytrap server will start honeytrap-server
  This is the base server

• honeytrap cli wil start honeytrap-cli
  This will show all information regarding running containers and attackers and such.

The honeytrap agent will forward traffic conforming the defacto PROXY protocol.

eg. honeytrap -f https://server/config.toml

The binaries should check for a new version compared to current. If available install the new version automatically.

#Issue
gometalinter reports specific errors as to linting, these need to be resolved.

Log

director/director/director_linux.go:22:6:warning: exported type Director should have comment or be unexported (golint)
director/director/director_linux.go:29:1:warning: exported function New should have comment or be unexported (golint)
director/director/director_linux.go:76:1:warning: exported method Director.NewContainer should have comment or be unexported (golint)
director/director/director_linux.go:82:1:warning: exported method Director.GetContainer should have comment or be unexported (golint)
director/director_linux.go:48::error: range var c copies lock: github.com/honeytrap/honeytrap/vendor/gopkg.in/lxc/go-lxc.v2.Container contains sync.RWMutex (vet)
director/director_linux.go:57::error: possible formatting directive in Error call (vet)
director/director_linux.go:41:15:warning: error return value not checked (go pusher.Run()) (errcheck)
director/director_linux.go:72:14:warning: error return value not checked (hasher.Write([]byte(fmt.Sprintf("%s%s", rhost, d.config.Token)))) (errcheck)
director/director.go:6::warning: Use of weak cryptographic primitive,HIGH,HIGH (gas)
director/director.go:67::warning: Use of weak cryptographic primitive,MEDIUM,HIGH (gas)
director/director.go:68::warning: Errors unhandled.,LOW,HIGH (gas)
director/director_linux.go:6::warning: Use of weak cryptographic primitive,HIGH,HIGH (gas)
director/director_linux.go:71::warning: Use of weak cryptographic primitive,MEDIUM,HIGH (gas)
director/director_linux.go:72::warning: Errors unhandled.,LOW,HIGH (gas)

With Regards to Issue #1

We need to implement the message filtering on the basis of the channels we wish to deliver to, currently I think it's possible to divert a message from a default channel to another channel easily with the slack webhooks API.

Goal

Filter messages to other slack channels based on a map of channel names and regexp.

Currently the agent copies the server configuration. For a more distributed approach, it's useful to have agents with different configurations (different credentials, banners, etc).

This could be done based on agent tokens or agent IP ranges in the server config file.

Something like

[agent.type1]
range=83.84.85.0/24

[agent.type2]
tokens=["abc","def","ghi"]

and then at the listener config:

agents=["type1", "type2"]

With Regards to Issue #1

We need to implement the base message sender for a giving slack channel. This code should be very simple and only cater to just allow the giving set of messages to be sent without adding any extra feature like filters.

Goal

Able to deliver a message payload to a slack channel.

The file channel, allows you to write all events and message to one or more files. This should work fine with the filters, allowing different events to be written to different files.

Support the INFO redis command.

INFO

With Regards to Issue #1

We need to implement the message filtering on the basis of the message types which should be generally handled by the slack channel.

Ideas

Accept a global map of regexp which filter messages by Sensor, Category, SessionID and ContainerID.

Goal

Filter messages to the slack group and channels based on the provided fieldNames -> regexp strings for filtering messages handled by the slack message sender.

Containers don't seem to suspend automatically after a timeout.
This commented line is likely the cause: https://github.com/honeytrap/honeytrap/blob/master/director/lxc/lxc_linux.go#L152
But the housekeeper functionality seems to be lost in a merge somewhere.

Lets use a more granular logging configuration. Using the following configuration, we can define common backend configs and have channels write to multiple backends while filtering on events, categories or sensors.

[[backend.honeytrap]]
host = "http://api.honeytrap.io/"
token = "b0b6e462-ef0b-11e6-abc7-0fb6247f5820"

[[backend.slack]]
token = "blabla"

[[channel]]
backend = ['honeytrap', 'slack']
events = ['*']
categories = ['ping']
sensors = ['ssh', 'http']

[[channel]]
backend = ['slack', 'honeytrap', 'elasticsearch']
events = ['reads*']
categories = ['ping']
sensors = ['http']

To get started: why does the slack pusher have the channel selection? What I was thinking was the following:

• The channel will check the message and if it complies, put it through to the backend(s). We’re using a unmarshal config now, but it will be cleaner to use a toml.Primitive, see https://godoc.org/github.com/BurntSushi/toml#MetaData.PrimitiveDecode (Take a look at the Bands).

We should change all the push messages to use the new messaging structure , so every call to Push should be rewritten (as in the ssh protocol for example), like:
Like this:

lw.events.Deliver(EventConnectionClosed(lw.Addr(), lw.Addr(), "ProxyListener", nil, nil))

Why not just

if it doesn’t fit well then we need to add an extra event like EventProxyConnectionClosed.

There is no need to save the backends to own variable, we can have a local variable, and add that to each channel, not going to change them now btw, because of presentation

Each sub module should be parsing its own config using toml.Primitive

Presentation of Project:
https://transfer.sh/FWSzb/honeytrap.tar.gz
for your understanding, that’s the presentation I’ll be giving.

So the plan will be the following:

• We’ll fixup the complete messaging structure, with multiple channels, backends and filtering of messages
• We’ll make sure the director will work as it should
• We’ll work on the protocols, make sure they work perfectly, now we have a first release

then we’ll continue with the other functionalities. For all backends (like logging, but also directors etc), We’ll create a global map.

In slack.go:

Register(“slack”, slack.New).

Then we’ll just call backendskey to register a new configured instance that saves the selector, same can be for director and services.

We should have a default configuration, that works out of the box, without the config. The logging should probably be a channel as well (not sure)

Allow services to respond by the first bytes, instead of the port number.

We need to refactor the usage of slice of pointers to use slice of values for message.PushMessage has this allows us to take advantage of the compilers optimization to keep the slice of values on the stack instead of the heap and reduces the costs of memory read calls.

• based on
  https://github.com/kubernetes/kubernetes/blob/c14fa94a4a7d12dd382ea7296a81ab9647954362/staging/src/k8s.io/client-go/pkg/api/v1/generate.go#L59
• current md5 chars are too long and will give warnings
• use format {template}-{unique}
• it would be great if it is a one way hash based on originating ip address

We need to implement a director for a Qemu. We need to investigate the libraries and possibility to communicate and how we will interface with our current services (http,ssh, agent).

We need to implement a director for a hyperV. We need to investigate the libraries and possibility to communicate with hyper v and how we will interface with our current services (http,ssh, agent).

When there's a listener on a non-default port (say port 22000 for SSH forwarded traffic) and the service dials an LXC container, this is also done using port 22000. Services should be configured to dial on a standard port, regardless of the incoming connection.

In addition to the HTTP API endpoints(/sessions and /events) exposed, we will be also adding the /ws endpoint which will allow us continuously receive updates on the changes on events from the systems events updates.

Requirements

Honeytrap needs to send notifications to slack with filtering support by:

• Per Message Type using Regular Expression
  Slack will be a message channel in honeytrap and will be the means through which will deliver messages to slack, the messages which will be passed into this channel will be filtered based on Regular Expression.

• Per Channel
  Slack allows us override the channel destination of a giving message hence allow providing channel name from configuration file to allow notifications for specific channels.

Questions

How will the filtering for the channels be done, by configuration through a UI or json configuration file?

Required Clarity

What is the current structure for honeytrap and how will it be supporting filtering and what means will this values be provided for.

port 27017

example payload

3b0000000100000000000000d40700000000000061646d696e2e24636d640000000000ffffffff14000000106275696c64696e666f000100000000

Why

We wish to reason about a new system where the director is abstracted into a common interface for all vms and emulators to implement, this will directly allow us to work with other platforms apart from lxc such as docker,etc.

Reason:

As part of our plans detailed in the API Plans page, we want to focus solely on the first point on abstracting out the directory.

Honeytrap should support usage of emulators apart from lxc containers, possible with 
vms that make it possible for us to target IOT platforms and architecture, which will 
require abstracting the director.

Brief

Since we want to support other emulators/vms, then lets reason how the current director works and what we need to actually support the other emulators, since we will need:

• A consistent interface for all directors to implement.
• A grasp of the different implementation details of the current director, how it works and what is specific to lxc that we know is required in other platforms which helps us create a generic method contract through the interface.
• What platforms we need to initially support.

Services need access to some kind of persistent key value storage, those services will use the key value storage to persist session information across restarts.

Intro

We need a central API for the project which centrally provides the ability to request stats, session data, and other related needs.

Functions

We have the following needs:

1. Will provide endpoints for requesting latest sessions and info.
2. Allow configuration of honeytrap.

Questions

Specific questions are needed for this:

• Will it be exposed over a HTTP based API?
• Apart from Session details what other data reports need to be provided?

Remark

Also, not all features need be developed at once, we currently target want to initially release a API for
No. 1 on the functions target.

Observe once with unknown cause. An agent just stops pinging. No relevant output in the stdout or logs. Nothing to investigate, but let's see if it happens more often.
After a restart it's been working fine since.

We need to implement a director for a firejail. We need to investigate the libraries and possibility to communicate and how we will interface with our current services (http,ssh, agent).

Honeyctl will give us features as preparation of container templates and such. Also we'll be able to retrieve information about containers. Inspired on kubectl.

This will need to implement a basic API as well.

Honeyctl will be a command within honeytrap binary.

https://github.com/watson/ipp-printer

We need a way to properly execute shell commands for each user connection to honeytrap. We desire to be able to do the following:

• Execute initial commands when a connection regardless of service is initialized on the director level. All containers must execute this commands first.
• Execute series of commands peculiar to a specific director and container generated by that director.

Each command must come with critical level settings which helps us define how the response of that command is treated. Consider the following:

• Critical Level: 1 (Normal)
  This level would allow commands to be executed regardless of their ending response and output. For instance, if a executed command fail, it will not interfere with the rest of commands to be executed.

• Critical Level: 2 (Debug, Warning, Permissive)
  This level will allow us associated that the executed commands result should be logged out to the user during the execution of such a command and will require the user to take action has might be critical to their operations but not the the operation of the container. It also will not interfere with the execution of the remaining commands

• Critical Level: 3 (Code Red, Stop the world)
  This level execution will abruptly end all future execution and kill the creation of the command has this is a critical command and must pass before the container is allowed to be created. This will allow us ensure all commands are valid and pass before attempting to create container sessions for users.

the smb service should emulate access to a smb share

the movement of the mouse should update the mouse cursor

• https://github.com/pkg/sftp/blob/master/examples/sftp-server/main.go

• https://github.com/golang/dep