This is a feature that will filter adult content from search
engine's results.
The old method of rewriting the HTTP request no longer works.
This method changes the DNS response for supported search engines
which violates our belief in DNSSEC and won't allow these search
engines to ever enable DNSSEC.
However, there is no better solution available to this and this
an optional feature, too.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Reviewed-by: Peter Müller <peter.mueller@ipfire.org>
Force the initscript to remove the PID file when calling "stop" section.
If suricata crashes during startup, the PID file still remains and the service
cannot be started anymore until the file has been deleted.
Now when calling "stop" or "restart" the PID file will be deleted and the service
can be used again.
Fixes#12067.
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
The script now will use the previously introduced seperate firewall chains called
IPS_INPUT, IPS_FORWARD and IPS_OUTPUT.
The commit also creates an AND connection between the choosen network zones in the UI and
the final firwall rules.
Fixes#12062.
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
Create and use seperate iptables chain called IPS_INPUT, IPS_FORWARD and IPS_OUTPUT
to be more flexible which kind of traffic should be passed to suricata.
Reference #12062
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
This causes some i2c drivers to load and tons of error messages
being created in syslog. So we skip searching for any sensors
that do not exist.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
If Tor is operating in relay mode, it has to open a lot of outgoing
TCP connections. These should be separated from any other outgoing
connections, as allowing _all_ outgoing traffic will be unwanted and
risky in most cases.
Thereof, Tor will be running as a dedicated user (see second patch),
allowing usage of user-based IPtables rulesets.
Partially fixes#11779.
Singed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
We are using the netfilter MARK in IPsec & QoS and this
is causing conflicts.
Therefore, we use the highest bit in the IPS chain now
and clear it afterwards because we do not really care about
this after the packets have been passed through suricata.
Then, no other application has to worry about suricata.
Fixes: #12010
Signed-off-by: Arne Fitzenreiter <arne.fitzenreiter@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
Marks "1-3" are used for marking source-natted packets on the
interfaces and 4 up to 6 for TOS and QOS. The mark "32" is used by IPsec.
See commit: f5ad510e3c
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
These are a cause of worry because they are sometimes generated with
an invalid timestamp and therefore render unbound being unusable.
There is no strong reason to use self-signed certificates for extra
security here.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This is a more general name for a script that will be extended
soon to do more than just add blocking rules.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This change is necessary to make sure that the script prefers
are link with internet access. That would usually be red (after
the second boot) or eth* (on the first boot).
That allows (and ensures) that we can install packages in
the user-data script.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This is done at boot time and doesn't normally need to be done again.
On AWS or in the setup, renaming any network interfaces is being
handled automatically.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
I accidently commited the wrong file in the previous commit.
This is the fixed and working version.
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
