Added new task to monitor the resources of remote nodes, like
ram, swap, number of processes or load average of the system.
The task is initiated when the user selects a node, and the data
received from the node is added to the right panel of the Nodes tab.
The task is stopped when changing to another tab, or when deselecting a
node.
Particularly useful for monitoring remote nodes.
daemon tasks are actions that are executed in background by the daemon.
They're started from the GUI (server) via a Notification (protobuf),
with the type TASK_START (protobuf).
Once received in the daemon, the TaskManager starts the task in
background.
Tasks may run at interval times (every 5s, 2days, etc), until they
finish an operation, until a timeout, etc.
Each task has each own configuration options, which will customize the
behaviour of its operations.
In this version, if the GUI is closed, the daemon will stop all the
running tasks.
Each Task has a flag to ignore this behaviour, for example if they need
to run until they finish and only send a notification to the GUI,
instead of streaming data continuously to the GUI (server).
- Up until now we only had one task that could be initiated from the GUI:
the process monitor dialog. It has been migrated to a Task{}.
- go.mod bumped to v1.20, to use unsafe string functions.
- go.sum updated accordingly.
When filtering by checksum and the checksum of a rule changes, we
display a warning on the popup, indicating that something happened.
The user had the option to update the checksum of one rule, directly
from the popup.
Now there's a new button to update all the rules that have a checksum as
filtering parameter.
When creating/editing rules to filter by lists of nets/IPs/domains, we
check if the path entered is a directory.
However on remote nodes, the path may not exist where the GUI is
running, but be valid where the daemon is running.
Now we only check the path if the node where it's being configured is
local.
Closes#1174
Up until now we had a way of customizing the views, by defining
"actions". See for context cba52cf3d8
The configuration syntax has not changed, but now every "action" is a
python plugin, for example when loading this configuration:
{
"name": "commonDelegateConfig",
"actions": {
"highlight": {
"enabled": true,
"cells": [
{
"text": ["allow", "✓ online"],
"color": "white",
"bgcolor: "green",
we'll try to load "highlight" as plugin, which should exist under
opensnitch/plugins/highligh/highlight.py
Three new plugins has been added:
- Highlight: colorize cells or rows based on patterns.
- Downloader: a simple downloader which downloads files to local
directories, for example to download blocklists.
- Virustotal: a plugin to analyze IPs, domains and checksums with the
API of virustotal when a new popup is fired.
There're 3 points where the plugins are configured and executed:
- opensnitch/service.py - _load_plugins() (background/global plugins)
- opensnitch/dialogs/prompt/__init__.py - _configure_plugins(), _post_popup_plugins()
- opensnitch/dialogs/processdetails.py - _configure_plugins()
Plugins can't be configured from the GUI (yet).
For more details, read:
opensnitch/plugins/__init__.py
opensnitch/actions/__init__.py
opensnitch/plugins/downloader/downloader.py
opensnitch/plugins/virustotal/virustotal.py
Since the name of the rule is used for the file name on the disk,
certain characters caused issues when saving the rule, like '/'.
Now if the user types or pastes '/' in the name field, a warning is
displayed, indicating that some characters are not allowed.
Closes#1166
google.golang.org/protobuf/cmd/protoc-gen-go@v1.34.2 generates
protobuffers incompatible with go1.17, it fails with the error:
"ui/protocol/ui.pb.go:2716:47: predeclared any requires go1.18 or later
(-lang was set to go1.17; check go.mod)"
Notes:
- consider using go1.18 as min required version if there's no problem
compiling the daemon on Debian <= 13 and other distros.
- github.com/golang/protobuf is deprecated and we should get rid of
it.
When exporting rules, use rfc3339 format for the Created field.
We were exporting as timestamp, which caused issues when importing them.
Related:
58aa979cae
issue #1140
pyinotify has stopped working in python3.12, it fails loading with the
error:
ModuleNotFoundError: No module named 'asyncore'
For now, ignore this error and keep working as usual.
Applications icons will be loaded on GUI startup, but we loose the
ability of discovering the icons of applications while the GUI is
running.
Closes: #1132
When exporting rules from the GUI, the Created field was exported as
timestamp. Importing rules worked fine, because json.Marshall() accepts
the timestamp format.
However, when the daemon was loading a rule with the Created field as
timestamp, since the field was defined as time.Time, it expected a RFC3339
string (https://pkg.go.dev/time#Time.UnmarshalJSON)
so it failed to parse the timestamp and the rule was not loaded.
Now the field is defined as string, it's always saved as RFC3339, and if
we fail to parse these fields we'll use a temporary date instead of
failing loading the rule.
More info:
https://github.com/evilsocket/opensnitch/issues/1140#issuecomment-2140904847Closes#1140
Allow to configure from the preferences dialog:
- max stats and events.
- rules path (use default path if empty).
- internal GC percentage, flush connections on start.
Disabled daemon's DefaultDuration option when the daemon is not
connected to the server (GUI). By default is "once".
Improved configuration parsing.
Minor improvements to display status messages.
Start monitoring the config file every time we read the file, to survive:
- malformed json file
- intermediate file removal (when writing we receive 2 write events,
one of0 bytes)
"A watch will be automatically removed if the watched path is deleted or
renamed"
"A path can only be watched once; watching it more than once is a no-op and
will not return an error"
https://pkg.go.dev/github.com/fsnotify/fsnotify#Watcher.Add
- When reloading rules from a path:
stop existing (domains,ips,regexp) lists monitors, stop rules
watcher and start watching the new dir for changes, delete existing
rules from memory, etc.
- Previously, cli parameters (queue number, log file, etc) were taking
into account before loading the configuration.
Now the configuration file is loaded first (default-config.json), and
if any of the cli parameter has been specified, it'll overwrite the
loaded configuration from file.
This means for example that if you use "-process-monitor-method proc",
and "ebpf" is configured in default-config.json, firstly "ebpf" will
be configured, and later "proc".
(-queue-num option for now requires to match config option
cfg.FwOptions.QueueNumber)
- Added "More information" label to the preferences dialog, and open a
link to our wiki with more information.
- Allow to configure node auth settings from the GUI:
When we added the authentication options (12b4cf3104,
6556eed1ae, f63d9dce72)
we allowed to configure auth options from the GUI, but only if the
nodes already had the options configured. If the auth options
received were empty, we simply disabled the auth options on the
preferences dialog.
Now we build the configuration in this scenario, and sent it back to
the nodes.
Allow to customize:
- EventsWorkers: number of goroutines to handle kernel events.
Default 8.
- QueueEventsSize: max number of events in the queue.
By default 0, meaning that it'll relay on the available goroutines to
process the events. If it's > 0, and the daemon can't process the
events fast enough, they'll be queued. Once the queue is full, it'll
behave as it was of size 0.
If there're lost events, a message will be logged: "Lost ebpf events..."
- Added new configuration field to allow configure fw interception
number queue (default to 0):
"FwOptions": {
"QueueNum": 0
}
(we still need to reconfigure nfqueue queues in order for this to
take effect).
- If the fw configuration path is not supplied, default to
/etc/opensnitchd/system-fw.json
- The loggers were not being properly initialized.
- The fw was only being load on reload, instead of on startup
and reload.
Kudos to @1fishe2fishe for reporting this problem and proposing a
fix in #1130!
