continuation of previous commit bde5d34deb
- Allow to reconfigure stats limits (how many events we keep on the
daemon, number of workers, ...)
- Allow to reconfigure loggers.
- Fixed firewall dialog label alignment.
- Fixed potential race condition when stopping the daemon, and there're
connections being enqueued.
- Added "clear" button to GUI's filter line (#786)
- Create ebpf cache object only if the modules have been loaded.
- Set default stats workers to the sme amount defined in configuration.
Closes#785
Under heavy network traffic load, writing to a remote syslog fails with
a timeout. Under this situation the connection didn't recover from that
state, blocking other connections.
To ensure that we continue working normally, as well as keep sending
events to syslog:
- Set a max timeout when writing to a remote syslog.
- Restart the connection with the server, if there're more than 10
errors.
With these fixes along with few other changes, writing to remote syslog
is more reliable, it works as expected.
We need to find the root cause of this behavior, and further test it
(#638).
Now you can send events to syslog, local or remote.
This feature was requested here #638
This feature allows you to integrate opensnitch with your SIEM. Take a
look at the above discussion to see examples with
syslog-ng+promtail+loki+grafana.
There's only one logger implemented (syslog), but it should be easily
expandable to add more type of loggers (elastic, etc).
The event format can be CSV or RFC5424. It sould also be easy to add
more formats.
- Allow to configure stats workers. They were hardcoded to 4.
Previous behaviour:
1) Before version 1.0.0b the daemon kept a list of processes that had
established connections. The list was displayed on the GUI as is, so
the maximum number of connections displayed were 100 (hardcoded).
2) When the intercepted connections reached 100, the last entry of the
list was removed, and a new one was inserted on the top.
After v1.0.0 we started saving connections to a DB on the GUI side, to
get rid of the hardcoded connections limit. However, the point 2) was
still present that caused some problems:
- When the backlog was full we kept inserting and deleting connections
from it continuously, one by one.
- If there was a connections burst we could end up missing some
connections.
New behaviour:
- The statisics are deleted from the daemon everytime we send them to
the GUI, because we don't need them on the daemon anymore.
- If the GUI is not connected, the connections will be added to the
backlog as in the point 2).
- When the backlog reaches the limit, it'll keep deleting the last
one in order to insert a new one.
- The number of connections to keep on the backlog is configurable.
- If the statistics configuration is missing, default values will be
150 (maxEvents) and 25 (maxStats).
Notes:
If the GUI is saving the data to memory (default), there won't be
any noticeable side effect.
If the GUI is configured to save the connections to a DB on disk, and
the daemon sends all the backlog at once, the GUI may experience a
delay and a high CPU spike. This can occur on connecting to the daemon
(because the backlog will be full), or when an app sends too many
connections per second (like nmap).
Use the timestamp instead of the event object when iterating over the last events. ~15x speed increase.
Increase event buffer to 100. On my machine I routinely hit the ceiling of 50 events under some multitasking workloads. Small buffer results in connection attempts not being logged.
Fix Makefile to rebuild when ui.proto changes
