Development January 2020

development@lists.ipfire.org

14 participants
58 discussions

[PATCH] tmux: Update to 3.0.a
by Matthias Fischer 29 Jan '20

29 Jan '20

For details see: https://raw.githubusercontent.com/tmux/tmux/3.0a/CHANGES Signed-off-by: Matthias Fischer <matthias.fischer(a)ipfire.org> --- lfs/tmux | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/lfs/tmux b/lfs/tmux index d08904132..e91f5e0cf 100644 --- a/lfs/tmux +++ b/lfs/tmux @@ -1,7 +1,7 @@ ############################################################################### # # # IPFire.org - A linux based firewall # -# Copyright (C) 2007-2018 IPFire Team <info(a)ipfire.org> # +# Copyright (C) 2007-2019 IPFire Team <info(a)ipfire.org> # # # # This program is free software: you can redistribute it and/or modify # # it under the terms of the GNU General Public License as published by # @@ -24,7 +24,7 @@ include Config -VER = 2.7 +VER = 3.0a THISAPP = tmux-$(VER) DL_FILE = $(THISAPP).tar.gz @@ -32,7 +32,7 @@ DL_FROM = $(URL_IPFIRE) DIR_APP = $(DIR_SRC)/$(THISAPP) TARGET = $(DIR_INFO)/$(THISAPP) PROG = tmux -PAK_VER = 6 +PAK_VER = 7 DEPS = "" @@ -44,7 +44,7 @@ objects = $(DL_FILE) $(DL_FILE) = $(DL_FROM)/$(DL_FILE) -$(DL_FILE)_MD5 = bcdfcf910c94c3e02ce6b1c035880306 +$(DL_FILE)_MD5 = 003b7df5b12ba2553710492b89850ce5 install : $(TARGET) @@ -77,6 +77,9 @@ $(subst %,%_MD5,$(objects)) : $(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects)) @$(PREBUILD) @rm -rf $(DIR_APP) && cd $(DIR_SRC) && tar zxf $(DIR_DL)/$(DL_FILE) + + cd $(DIR_APP) && ./autogen.sh + cd $(DIR_APP) && ./configure \ --prefix=/usr -- 2.18.0

3 4

Question regarding IPsec N2N throughput with and without IPS
by Peter Müller 28 Jan '20

28 Jan '20

Hello Stefan, hello list (CC'ed), are you aware of any IPS bottlenecks regarding IPsec N2N throughput? I finally (!) managed to get an IPsec connection between OpenBSD 6.6 (OpenIKED) and IPFire 2.23 Core Update 139 working. During throughput tests, where I downloaded a 1 GByte test file from the machine via the IPsec tunnel, a rather large throughput difference with and without IPS enabled on RED has come to my attention: With IPS enabled on RED, the download starts at ~ 2.5 MByte/sec. and continually decreases to ~ 580 kByte/sec. - 800 kByte/sec., which is even lower than OpenVPN performance. Without IPS enabled on RED, throughput is 4.0 MByte/sek. on average - running the IPS on other interfaces does not change this behaviour, neither does enabling monitoring mode. This suspiciously sounds like the issue we have had with Suricata last year - as far as I am concerned that was fully fixed. Are you aware of any other similar issue that could cause this massive throughput loss? Anyway, thank you in advance for any help and hints. :-) Kernel and CPU information of the OpenBSD machine: > openbsd# uname -a > OpenBSD openbsd 6.6 GENERIC.MP#4 amd64 > openbsd# sysctl hw.model hw.machine hw.ncpu > hw.model=Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz > hw.machine=amd64 > hw.ncpu=2 Content of /etc/iked.conf on the OpenBSD machine: > set fragmentation > > ikev2 "[REDACTED]" active esp \ > from 10.xxx.xxx.2/24 to 10.xxx.xxx.0/24 \ > local [REDACTED] peer [REDACTED] \ > ikesa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 group curve25519 \ > childsa enc aes-256-gcm group curve25519 \ > srcid [REDACTED] dstid [REDACTED] \ > ikelifetime 3h \ > lifetime 1h Kernel and CPU information of the IPFire machine: > [root@maverick ~]# uname -a > Linux maverick 4.14.154-ipfire #1 SMP Fri Nov 15 07:27:41 GMT 2019 x86_64 Intel(R) Celeron(R) CPU N3150 @ 1.60GHz GenuineIntel GNU/Linux Thanks, and best regards, Peter Müller

2 5

[PATCH] ovpnmain.cgi: Validate CCDNet name when renaming it.
by Stefan Schantl 28 Jan '20

28 Jan '20

Fixes #12282 Signed-off-by: Stefan Schantl <stefan.schantl(a)ipfire.org> --- html/cgi-bin/ovpnmain.cgi | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/html/cgi-bin/ovpnmain.cgi b/html/cgi-bin/ovpnmain.cgi index e76a688fe..22a2b9905 100644 --- a/html/cgi-bin/ovpnmain.cgi +++ b/html/cgi-bin/ovpnmain.cgi @@ -490,6 +490,13 @@ sub modccdnet my $oldname=$_[1]; my %ccdconfhash=(); my %ccdhash=(); + + # Check if the new name is valid. + if(!&General::validhostname($newname)) { + $errormessage=$Lang::tr{'ccd err invalidname'}; + return; + } + &General::readhasharray("${General::swroot}/ovpn/ccd.conf", \%ccdconfhash); foreach my $key (keys %ccdconfhash) { if ($ccdconfhash{$key}[0] eq $oldname) { -- 2.25.0

2 1

[PATCH] convert-dns-settings: Fix check to prevent doubble-adding the same server
by Stefan Schantl 28 Jan '20

28 Jan '20

Signed-off-by: Stefan Schantl <stefan.schantl(a)ipfire.org> --- src/scripts/convert-dns-settings | 23 +++++++++++++++-------- 1 file changed, 15 insertions(+), 8 deletions(-) diff --git a/src/scripts/convert-dns-settings b/src/scripts/convert-dns-settings index e9d4de86b..073356f50 100755 --- a/src/scripts/convert-dns-settings +++ b/src/scripts/convert-dns-settings @@ -43,17 +43,24 @@ main() { for var in DNS1 DNS2; do local server="${!var}" - # Check if the current server is allready part - # of the array. - for element in "${SERVERS[@]}"; do - [[ $element == $server ]] && continue - done - - SERVERS+=($server) + # Check if the servers array is empty. + if [ ${#SERVERS[@]} -eq 0 ]; then + # Allways add the first found nameserver to the array. + SERVERS+=($server) + else + # Check if the current server is allready part ot the array. + if [[ ! "${SERVERS[@]}" =~ "${server}" ]]; then + # Add the server to the array. + SERVERS+=($server) + fi + fi done # Remove DNS1 and DNS2 settings from profile file. - sed -i "/^DNS[12]?=/d" $file + sed -i "/^DNS[12]=/d" $file + + # Unset the local variables for the next round. + unset DNS1 DNS2 done elif [ -s "/var/ipfire/dns/settings" ]; then -- 2.25.0

2 1

[PATCH] avoid emitting VPN traffic to the internet if the IPS crashed
by Peter Müller 27 Jan '20

27 Jan '20

Due to strange NFQUEUE behaviour, traffic to remote VPN (IPsec or OpenVPN) destinations was emitted to the internet (ppp0 or red0 interface) directly if the IPS was enabled but crashed during operation. This patch places the IPSECBLOCK and OVPNBLOCK chains before the ones responsible for forwarding traffic into the IPS. Thanks to Michael for his debugging effort. Partially fixes #12257 Cc: Michael Tremer <michael.tremer(a)ipfire.org> Cc: Stefan Schantl <stefan.schantl(a)ipfire.org> Signed-off-by: Peter Müller <peter.mueller(a)ipfire.org> --- src/initscripts/system/firewall | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/src/initscripts/system/firewall b/src/initscripts/system/firewall index ec396c708..ab144ea18 100644 --- a/src/initscripts/system/firewall +++ b/src/initscripts/system/firewall @@ -185,14 +185,6 @@ iptables_init() { iptables -A INPUT -j GUARDIAN iptables -A FORWARD -j GUARDIAN - # IPS (suricata) chains - iptables -N IPS_INPUT - iptables -N IPS_FORWARD - iptables -N IPS_OUTPUT - iptables -A INPUT -j IPS_INPUT - iptables -A FORWARD -j IPS_FORWARD - iptables -A OUTPUT -j IPS_OUTPUT - # Block non-established IPsec networks iptables -N IPSECBLOCK iptables -A FORWARD -m policy --dir out --pol none -j IPSECBLOCK @@ -204,6 +196,14 @@ iptables_init() { iptables -A FORWARD -i tun+ -j OVPNBLOCK iptables -A FORWARD -o tun+ -j OVPNBLOCK + # IPS (suricata) chains + iptables -N IPS_INPUT + iptables -N IPS_FORWARD + iptables -N IPS_OUTPUT + iptables -A INPUT -j IPS_INPUT + iptables -A FORWARD -j IPS_FORWARD + iptables -A OUTPUT -j IPS_OUTPUT + # OpenVPN transfer network translation iptables -t nat -N OVPNNAT iptables -t nat -A POSTROUTING -j OVPNNAT -- 2.16.4

2 1

Firewall rules with predefined service groups for both source and destination?
by Peter Müller 27 Jan '20

27 Jan '20

Hello *, since I am not sure whether I am dealing with a bug, a missing feature or my very own personal incompetence, asking the mailing list seemed reasonable for this. :-) For security purposes, dropping packets from source ports < 1024 is a good idea as the latter indicates successful compromise of services running on privileged ports. New connections are usually established from ports > 1023, so there is little legitimate scope for this if in doubt. When creating a firewall rule via the WebIF, it does not seem to be possible to limit source _and_ destination ports if a predefined service (group) is used - the latter one always refers to the destination port(s). As soon as a single protocol such as TCP or UDP is selected, however, a field "source port" is available. Is this behaviour intentional? If yes, how do I limit firewall rules to certain source ports then? Aren't the descriptions "service" and "service group" misleading? Thanks, and best regards, Peter Müller

3 5

firewall oddities when accessing services at the far side of an IPsec N2N connection
by Peter Müller 26 Jan '20

26 Jan '20

Hello list, due to reasons, I currently work on migrating an upstream (Squid) proxy machine from HardenedBSD connected via OpenVPN to OpenBSD connected via IPsec. The latter one seems to work since the connection is stable and SSH usage over the tunnel is possible. However, using the remote Squid proxy as an upstream proxy (refer to corresponding setting in proxy.cgi) is impossible as responses are not answered from the remote side: > [root@maverick ~]# export http_proxy="http://10.xxx.xxx.2:3128/" > [root@maverick ~]# wget -vv example.com > --2020-01-25 16:58:00-- http://example.com/ > Connecting to 10.xxx.xxx.2:3128... connected. > Proxy request sent, awaiting response... > (wget stalls and eventually runs in a timeout) Oddly enough, doing the same thing on a machine within the GREEN network works: > user@machine:~> export http_proxy="http://10.xxx.xxx.2:3128/" > user@machine:~> wget -vv heise.de > --2020-01-25 16:59:26-- http://heise.de/ > Verbindungsaufbau zu 10.xxx.xxx.2:3128 … verbunden. > Proxy-Anforderung gesendet, auf Antwort wird gewartet … 407 Proxy Authentication Required > 2020-01-25 16:59:26 FEHLER 407: Proxy Authentication Required. However, a SSH login _is_ possible from the firewall machine to the remote IPsec one, which makes me writing this mail as I am not sure about the behaviour's root cause. Connecting to the IPsec machine seems to require a firewall rule like this: - source: firewall (any) - use NAT: yes, source NAT enabled, new source IP address = GREEN - destination: IPsec remote machine - protocol: any If source NAT is omitted, accessing the IPsec machine is not possible via any given way (ping, SSH, Squid, ...). However, _if_ SNAT is enabled, it also affects connections made from the machine within the GREEN network. As far as I am concerned, there are two oddities: (a) Even with SNAT enabled, the firewall itself is unable to reliably establish a connection to an remote IPsec destination. (b) If SNAT is enabled for outgoing traffic generated by the firewall, it also seems to affect traffic from GREEN/... sources, while it is not configured to do so. Is there anybody who got remote upstream proxies via IPsec working? Are (a) and (b) bugs? If not: What shall I do to work around these? Thanks, and best regards, Peter Müller

3 8

[PATCH] mc: Update to 4.8.24
by Matthias Fischer 26 Jan '20

26 Jan '20

For details see: http://midnight-commander.org/wiki/NEWS-4.8.24 Signed-off-by: Matthias Fischer <matthias.fischer(a)ipfire.org> --- config/rootfiles/packages/mc | 2 ++ lfs/mc | 6 +++--- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/config/rootfiles/packages/mc b/config/rootfiles/packages/mc index 73ff588c7..42a6aadf4 100644 --- a/config/rootfiles/packages/mc +++ b/config/rootfiles/packages/mc @@ -111,6 +111,7 @@ usr/share/mc/skins/featured.ini usr/share/mc/skins/gotar.ini usr/share/mc/skins/gray-green-purple256.ini usr/share/mc/skins/gray-orange-blue256.ini +usr/share/mc/skins/julia256.ini usr/share/mc/skins/mc46.ini usr/share/mc/skins/modarcon16-defbg.ini usr/share/mc/skins/modarcon16.ini @@ -217,6 +218,7 @@ usr/share/mc/syntax/unknown.syntax usr/share/mc/syntax/verilog.syntax usr/share/mc/syntax/vhdl.syntax usr/share/mc/syntax/xml.syntax +usr/share/mc/syntax/yabasic.syntax usr/share/mc/syntax/yaml.syntax usr/share/mc/syntax/yum-repo.syntax usr/share/mc/syntax/yxx.syntax diff --git a/lfs/mc b/lfs/mc index ff23c4064..528cb4d4a 100644 --- a/lfs/mc +++ b/lfs/mc @@ -24,7 +24,7 @@ include Config -VER = 4.8.23 +VER = 4.8.24 THISAPP = mc-$(VER) DL_FILE = $(THISAPP).tar.xz @@ -32,7 +32,7 @@ DL_FROM = $(URL_IPFIRE) DIR_APP = $(DIR_SRC)/$(THISAPP) TARGET = $(DIR_INFO)/$(THISAPP) PROG = mc -PAK_VER = 18 +PAK_VER = 19 DEPS = "" @@ -44,7 +44,7 @@ objects = $(DL_FILE) $(DL_FILE) = $(DL_FROM)/$(DL_FILE) -$(DL_FILE)_MD5 = 466c3135f727f8ac2102d060a080ace3 +$(DL_FILE)_MD5 = 3a11df2dd379dd67c497c8d2c344715c install : $(TARGET) -- 2.18.0

2 1

[PATCH] squid: Update to 4.10
by Matthias Fischer 26 Jan '20

26 Jan '20

For details see: http://www.squid-cache.org/Versions/v4/changesets/ Signed-off-by: Matthias Fischer <matthias.fischer(a)ipfire.org> --- lfs/squid | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lfs/squid b/lfs/squid index 9801c153b..8553d7113 100644 --- a/lfs/squid +++ b/lfs/squid @@ -24,7 +24,7 @@ include Config -VER = 4.9 +VER = 4.10 THISAPP = squid-$(VER) DL_FILE = $(THISAPP).tar.xz @@ -46,7 +46,7 @@ objects = $(DL_FILE) $(DL_FILE) = $(DL_FROM)/$(DL_FILE) -$(DL_FILE)_MD5 = 5c2e335dd1e8ced9dda6e0e11894b344 +$(DL_FILE)_MD5 = af7ac6e70f9bd03ae4fcec0c9b99c38a install : $(TARGET) -- 2.18.0

2 1

[PATCH] logwatch: Update to 7.5.3
by Matthias Fischer 26 Jan '20

26 Jan '20

For details see: https://sourceforge.net/p/logwatch/activity/?page=0&limit=100#5e27da933241d… Signed-off-by: Matthias Fischer <matthias.fischer(a)ipfire.org> --- lfs/logwatch | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lfs/logwatch b/lfs/logwatch index eb576717c..a980b1b40 100644 --- a/lfs/logwatch +++ b/lfs/logwatch @@ -24,7 +24,7 @@ include Config -VER = 7.5.2 +VER = 7.5.3 THISAPP = logwatch-$(VER) DL_FILE = $(THISAPP).tar.gz @@ -40,7 +40,7 @@ objects = $(DL_FILE) $(DL_FILE) = $(DL_FROM)/$(DL_FILE) -$(DL_FILE)_MD5 = 634b2ac423b77b809d400cc6085db49d +$(DL_FILE)_MD5 = 8bcf3edc5a4687c8aad1b9c01e2be54b install : $(TARGET) -- 2.18.0

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

Development January 2020