This entirely has been replaced by the providers section and the code to
handle the actions of this section.
Therefore this code is not longer needed.
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
The selected rulesfiles of a provider now will be written to an own
provider exclusive yaml file, which will be included dynamically when
the provider is enabled or not.
This allows very easy handling to enable or disable a provider, in this
case the file which keeps the enabled providers rulesets only needs to
be included in the main file or even not.
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
* The page and section now supports multiple ruleset providers at once.
* Adding / Editing a ruleset provider has been moved to a own sub-page.
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
The warning point to a wiki page which is currently in construction.
This should give us the opportunity to add further information for
these users even if we do not provide updates anymore.
Signed-off-by: Jonatan Schlag <jonatan.schlag@ipfire.org>
Reviewed-by: Bernhard Bitsch <bbitsch@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
This patch adds a little "help" icon to the page header.
If a manual entry exists for a configuration page, the icon
appears and offers a quick way to access the wiki.
Wiki pages can be configured in the "manualpages" file.
Signed-off-by: Leo-Andres Hofmann <hofmann@leo-andres.de>
Reviewed-by: Bernhard Bitsch <bbitsch@ipfire.org>
Tested-by: Bernhard Bitsch <bbitsch@ipfire.org>
Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>
iptables multiport only supports up to 15 elements for each protocol (TCP or UDP).
That can be single ports or portranges (they count doubble).
This commit extends the check to calculate the amount of used TCP and/or
UDP ports of all existing entries in a group, by increasing the amount
for the service which should be added.
If the amount of ports for TCP or UDP ports become greater than the
limit of 15 the error message will be displayed.
Fixes#11323.
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>
Reviewed-by: Bernhard Bitsch <bbitsch@ipfire.org>
- Option "--secret" was deprecated in OpenVPN 2.4 and removed in OpenVPN 2.5
It was replaced by "secret". If "--secret" is used with genkey then a user warning is
printed and this is what gives the Internal server error.
- Patch was defined by Erik Kapfer but currently he does not have a build environment
so I have submitted the patch on his behalf.
- Patch tested on a vm testbed running Core Update 160. Confirmed that without patch the
error still occurs and with patch everything runs smoothly.
Fixes: Bug #12574
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by : Erik Kapfer <ummeegge@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Reviewed-by: Peter Müller <peter.mueller@ipfire.org>
latest ipfroute2 update change the output so this repkace it by reading /sys/class/net/*/statistics
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
include general-functions.pl load and initialize many subfunctions that are not
needed by speed.cgi which was executed very often.
So this reduce the system load significant if webif was open in browser
and ajax-speed display enabled.
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
Reviewed-by: Bernhard Bitsch <bbitsch@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
We currently don't have IPv6 in vanilla IPFire 2.x installations, hence
there is no sense in letting Tor finding out IPv6 connectivity.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
This makes post-exploitation activities harder, in case the local Tor
instance has been compromised. It is worth noticing that Tor won't
respond to a "GETINFO address" command on the control port if sandboxed,
but our CGI does not make use of it, and neither is any legitimate
service on IPFire doing so.
Tested on a small middle relay running on an IPFire machine.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
When performing any action which requires pakfire, the page gets locked
with an message informing the user that pakfire is working. The page
will be reloaded when pakfire has been launched and is doing the
requested operation - showing the well known log output. This also
happens when pakfire has been launched via any kind of terminal or SSH
session and the CGI gets accessed.
Internally before pakfire gets started a variable called page_lock will
be set to lock the page. An while loop will keep the page locked until
pakfire is launched fully and has written it's lock_file.
This approach will prevent us from any kind of required time intervall
or race conditions.
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
An error message is still shown although there is no option to disable
DNSSEC at the moment. The old marker file could still be present on
older machines.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
'bandwith...' should be 'bandwidth...'.
Despite being my favourite typo for the past few years(?),
today I decided to try to say 'Goodbye' to an old friend.
Similar to 'MB writen' its hard but I think it just about time.
'qos' and 'guardian' will never be the same for me... ;-)
Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org>
Reviewed-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
There is no sense to display this to anybody, and we do not reveal
version information anywhere else on purpose. The IT staff knows which
version of IPFire they are running (hopefully the latest), and it's
none of the rest of the world's business.
Fixes: #12665 (in some way)
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Acked-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
This patch adds two new features to IPFire's web proxy:
(a) Proactive Fast Flux detection
FQDNs are resolved to their IP addresses, which are then resolved to
corresponding Autonomous System Numbers using IPFire's location
database. Most destinations will scatter across a very low number of
ASNs (not to be confused with IP addresses!). FQDNs hosted on Fast
Flux setups have a significantly higher ASN diversity (5 is usually
a good threshold), so they can be proactively detected.
(b) Detection for selectively announced destinations
Especially in targeted operations, miscreants host FQDNs for
exfiltrating data or malware distributions on ASNs not announced
globally, but only to the intended victim or it's upstream ISPs.
That way, security researchers located in other parts of the
internet have no insights into these attacks, hence not being able
to publish listings or send take down notices for the domains used.
While RPKI made this attack harder, it can still be observed every
now and then.
This feature also protects against accessing FQDNs resolving to IP
addresses not being globally routeable, hence providing a trivial
mitigation for so-called "rebound attacks" - which we cannot filter
at DNS level currently.
The second version of this patch consumes the user-defined whitelist for
the URL filter (if present and populated) for the ASNBL helper as well,
to make exceptions for funny destinations such as fedoraproject.org
possible. In addition, the ASNBL helper's sanity tests no longer include
publicly routable IP addresses, so failures on location01 cannot brick
IPFire installations in the field.
Thanks to Michael Tremer and Adolf Belka for these suggestions.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
This feature has to go in order to take advantage of CONNMARK which will
drastically decrease CPU load when passing packets.
We no longer will see every packet in the QOS-INC chain in order to
change classification of that packet. It is also party counter-intuitive
to have parts of one connection in one class and the corresponding ACK
packets in another.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
