opensnitch

by evilsocket

evilsocket / opensnitch

OpenSnitch is a GNU/Linux port of the Little Snitch application firewall

5.4K Stars 288 Forks Last release: Not found GNU General Public License v3.0 379 Commits 0 Releases

Available items

No Items, yet!

The developer of this repository has not created any items for sale yet. Need a bug fixed? Help with integration? A different license? Create a request here:

opensnitch

Release Software License Go Report Card

OpenSnitch is a GNU/Linux port of the Little Snitch application firewall.

OpenSnitch

THIS SOFTWARE IS WORK IN PROGRESS, DO NOT EXPECT IT TO BE BUG FREE AND DO NOT RELY ON IT FOR ANY TYPE OF SECURITY.

TL;DR

Make sure you have a correctly configured Go >= 1.8 environment, that the

$GOPATH
environment variable is defined and then:
# install dependencies
sudo apt-get install git libnetfilter-queue-dev libpcap-dev protobuf-compiler python3-pip
go get github.com/golang/protobuf/protoc-gen-go
go get -u github.com/golang/dep/cmd/dep
cd $GOPATH/src/github.com/golang/dep
./install.sh
export PATH=$PATH:$GOPATH/bin
python3 -m pip install --user grpcio-tools
# clone the repository (ignore the message about no Go files being found)
go get github.com/evilsocket/opensnitch
cd $GOPATH/src/github.com/evilsocket/opensnitch
# compile && install
make
sudo make install
# enable opensnitchd as a systemd service and start the UI
sudo systemctl enable opensnitchd
sudo service opensnitchd start
opensnitch-ui

Daemon

The

daemon
is implemented in Go and needs to run as root in order to interact with the Netfilter packet queue, edit iptables rules and so on, in order to compile it you will need to install the
protobuf-compiler
,
libpcap-dev
and
libnetfilter-queue-dev
packages on your system, then just:
cd daemon
make

You can then install it as a systemd service by doing:

sudo make install

The new

opensnitchd
service will log to
/var/log/opensnitchd.log
, save the rules inside
/etc/opensnitchd/rules
and connect to the default UI service socket
unix:///tmp/osui.sock
.

UI

The user interface is a Python 3 software running as a

gRPC
server on a unix socket, to order to install its dependencies:
cd ui
sudo pip3 install -r requirements.txt

You will also need to install the package

python-pyqt5
for your system (if anyone finds a way to make this work from the
requirements.txt
file feel free to send a PR).

The UI is pip installable itself:

sudo pip3 install .

This will install the

opensnitch-ui
command on your system (you can auto startup it by
cp opensnitch_ui.desktop ~/.config/autostart/
).

UI Configuration

By default the UI will load its configuration from

~/.opensnitch/ui-config.json
(customizable with the
--config
argument), the default contents of this file are:
{
    "default_timeout": 15,
    "default_action": "allow",
    "default_duration": "until restart"
}

The

default_timeout
is the number of seconds after which the UI will take its default action, the
default_action
can be
allow
or
deny
and the
default_duration
, which indicates for how long the default action should be taken, can be
once
,
until restart
or
always
to persist the action as a new rule on disk.

Running

Once you installed both the daemon and the UI, you can enable the

opensnitchd
service to run at boot time:
sudo systemctl enable opensnitchd

And run it with:

sudo service opensnitchd start

While the UI can be started just by executing the

opensnitch-ui
command.

Single UI with many computers

You can also use

--socket "[::]:50051"
to have the UI use TCP instead of a unix socket and run the daemon on another computer with
-ui-socket "x.x.x.x:50051"
(where
x.x.x.x
is the IP of the computer running the UI service).

Rules

Rules are stored as JSON files inside the

-rule-path
folder, in the simplest cast a rule looks like this:
{
   "created": "2018-04-07T14:13:27.903996051+02:00",
   "updated": "2018-04-07T14:13:27.904060088+02:00",
   "name": "deny-simple-www-google-analytics-l-google-com",
   "enabled": true,
   "action": "deny",
   "duration": "always",
   "operator": {
     "type": "simple",
     "operand": "dest.host",
     "data": "www-google-analytics.l.google.com"
   }
}

| Field | Description | | -----------------|---------------| | created | UTC date and time of creation. | | update | UTC date and time of the last update. | | name | The name of the rule. | | enabled | Use to temporarily disable and enable rules without moving their files. | | action | Can be

deny
or
allow
. | | duration | For rules persisting on disk, this value is default to
always
. | | operator.type | Can be
simple
, in which case a simple
==
comparison will be performed, or
regexp
if the
data
field is a regular expression to match. | | operator.operand | What element of the connection to compare, can be one of:
true
(will always match),
process.path
(the path of the executable),
process.command
(full command line, including path and arguments),
provess.env.ENV_VAR_NAME
(use the value of an environment variable of the process given its name),
user.id
,
dest.ip
,
dest.host
or
dest.port
. | | operator.data | The data to compare the
operand
to, can be a regular expression if
type
is
regexp
. |

An example with a regular expression:

{
   "created": "2018-04-07T14:13:27.903996051+02:00",
   "updated": "2018-04-07T14:13:27.904060088+02:00",
   "name": "deny-any-google-analytics",
   "enabled": true,
   "action": "deny",
   "duration": "always",
   "operator": {
     "type": "regexp",
     "operand": "dest.host",
     "data": "(?i).*analytics.*\\.google\\.com"
   }
}

An example whitelisting a whole process:

{
   "created": "2018-04-07T15:00:48.156737519+02:00",
   "updated": "2018-04-07T15:00:48.156772601+02:00",
   "name": "allow-simple-opt-google-chrome-chrome",
   "enabled": true,
   "action": "allow",
   "duration": "always",
   "operator": {
     "type": "simple",
     "operand": "process.path",
     "data": "/opt/google/chrome/chrome"
   }
 }

FAQ

Why Qt and not GTK?

I tried, but for very fast updates it failed bad on my configuration (failed bad = SIGSEGV), moreover I find Qt5 layout system superior and easier to use.

Why gRPC and not DBUS?

The UI service is able to use a TCP listener instead of a UNIX socket, that means the UI service itself can be executed on any operating system, while receiving messages from a single local daemon instance or multiple instances from remote computers in the network, therefore DBUS would have made the protocol and logic uselessly GNU/Linux specific.

We use cookies. If you continue to browse the site, you agree to the use of cookies. For more information on our use of cookies please see our Privacy Policy.