weaklayer / gateway

Browser Detection and Response (Reference Server Application)

Weaklayer Gateway (Reference Implementation)

N.B. As of early 2021, this project is no longer under active development and has been removed from browser extension stores. However, the Weaklayer sensor and gateway still work well at the time of writing. The sensor just requires installing from source now.

Welcome to the Weaklayer Gateway (Reference Implementation) repository. Weaklayer is a software system for Browser Detection and Response - like Endpoint Detection and Response (EDR) but in the browser. The Weaklayer Gateway (a server application) receives security data from Weaklayer Sensors (browser extensions).

These are the Weaklayer Gateway Reference Implementation goals:

• Be suitable for use in production
• Be open source
• Enforce sensor identity and authentication
• Make data available to downstream systems
• Enable the use of all Weaklayer Sensor features
• Be the primary Weaklayer Gateway implementation used for Weaklayer Sensor development

These are not goals of the Weaklayer Gateway Reference Implementation:

• Graphical user interface
• Advanced administrative capabilities
• Detection analytics
• Direct integration with downstream systems

These things better belong in the Weaklayer Gateway Enterprise Edition. Please see the Weaklayer Website for more details on the enterprise edition.

The idea is that the reference gateway implementation is simple software that gives you everything you need for Weaklayer to meaningfully contribute to your security stack.

Note that there is only one edition of the Weaklayer Sensor, and it is open source.

Usage

Usage instructions can be found in the Docs section of the Weaklayer Website. This includes instructions for execution and configuration. Things that follow in this README are for Weaklayer Gateway development.

Note: Sensor data is not sanitized / pruned. That is, the gateway will not drop or modify data presented to it as long as it meets a couple simple requirements. For example, the gateway does not modify strings to prevent cross-site scripting or SQL injection.

Building From Source

You may want to build from source to accommodate a platform not covered in the binary release or to incorporate your own modifications.

This requires you have golang (1.14+) installed.

git clone https://github.com/weaklayer/gateway.git
cd gateway
go test ./...
go build -o weaklayer-gateway

This produces an executable called weaklayer-gateway for the platform you are currently on.

gateway's Issues

Indicate in Install events if the installation is new

Install events may be more useful if there is context indicating which of these situations an install happened under:

1. The sensor authenticated with an install key and a new identity was generated
2. The sensor renewed its identity by providing an install key and a valid identity token

Print the version number from the Gateway CLI

Can be annoying to not know which version of the binary you are using.
Gateway versions should be present inside the binary and printed by the Gateway CLI.
It should be printed on the following commands:

• weaklayer-gateway
• weaklayer-gateway help
• weaklayer-gateway license
• In an application log in weaklayer-gateway server

Support Writing Events to Filesystem

Don't want events going to stdout forever.
Writing to the filesystem feels like the lowest common denominator for being able to integrate Weaklayer data into other systems (e.g. SIEM/SOAR).

Current idea for design:

• use config to specify an output directory
• subdirectories are created based on sensor group
• one file at a time being appended to in these subdirectories, rotated by time/size
• data from many sensors in the same group goes to the same file

This setup is desired mainly because we don't want to scale the number of open file with the number of sensors.
Scaling with the number of groups is more reasonable.
Can later add ability to write to multiple files for a group simultaneously if throughput is limited by this.

Add support for sensor text input events

weaklayer/sensor#20 will require a new event type from the sensor.
The gateway needs to support this new event type.

Add TLS to sensor API

The sensor should communicate with the gateway over https in production.

Undecided if this should be implemented though.
You probably want to load balance across two Weaklayer Gateways in production for HA.
That load balancer can do TLS offloading.

Add option for compressing filesystem output files

The filesystem output files are JSON files with lots of repeated data (e.g. sensor/group UUIDs).
Compression should be pretty effective at reducing file size.
This is important for use cases like putting these files in cloud storage where storage and bandwidth are billed based on file size.

Add a boolean option to the gateway for writing to compressed files.
For example, with this option set, files could be {filename}.json.gz

I'm leaning toward GZIP as it will give good interoperability with other tools like zgrep.

Add the User-Agent header value to Install events

The User-Agent is set on requests sent from the sensor.
The browser does this automatically.
This gives pretty granular data about what browser the sensor is running in.
This information might be useful.

Install events are the natural place for this information in my opinion.