Development December 2019

development@lists.ipfire.org

13 participants
46 discussions

[PATCH 0/5] ipblacklist: IP Address Blacklists
by Tim FitzGeorge 16 Dec '19

16 Dec '19

Implements downloading of IP address blacklists and implementing them as IPSets. A separate IPSet is used for each blacklist; this simplifies handling of overlaps between different lists. Traffic to or from the red0/ppp0 interface is checked against the IPSets. The check is placed before the IPS check as the IPSet check is much lighter on CPU use which means that overall CPU use is reduced. The available lists are defined in a separate file. A WUI page allows the desired lists to be enabled and the interval between checks for updates to be defined. A minimum update check interval is defined for each blacklist in the definition file. Optionally, an automatically updating blacklist can be enabled. This adds addresses to an IPSet if the rate of packets dropped by the default red0/ppp0 input policy exceeds a user defined threshold. The addresses are kept in the IPSet until a user defined period without packets from the blocked address has passed. Tim FitzGeorge (5): ipblacklist: Main script ipblacklist: WUI and language file ipblacklist: Ancillary files ipblacklist: Modifications to system ipblacklist: Build infrastructure config/backup/backup.pl | 1 + config/backup/include | 2 + config/firewall/firewall-policy | 5 + config/ipblacklist/sources | 151 +++ config/logwatch/ipblacklist | 103 ++ config/logwatch/ipblacklist.conf | 34 + config/menu/50-firewall.menu | 5 + config/rootfiles/common/aarch64/stage2 | 1 + config/rootfiles/common/configroot | 2 + config/rootfiles/common/ipblacklist-sources | 1 + config/rootfiles/common/logwatch | 2 + config/rootfiles/common/misc-progs | 2 + config/rootfiles/common/stage2 | 1 + config/rootfiles/common/web-user-interface | 1 + config/rootfiles/common/x86_64/stage2 | 1 + html/cgi-bin/ipblacklist.cgi | 725 +++++++++++++ html/cgi-bin/logs.cgi/log.dat | 2 + langs/en/cgi-bin/en.pl | 31 + lfs/configroot | 4 +- lfs/ipblacklist-sources | 53 + lfs/logwatch | 2 + make.sh | 11 +- src/initscripts/system/firewall | 20 + src/misc-progs/Makefile | 2 +- src/misc-progs/getipsetstat.c | 28 + src/misc-progs/ipblacklistctrl.c | 52 + src/scripts/ipblacklist | 1558 +++++++++++++++++++++++++++ 27 files changed, 2792 insertions(+), 8 deletions(-) create mode 100644 config/ipblacklist/sources create mode 100644 config/logwatch/ipblacklist create mode 100644 config/logwatch/ipblacklist.conf create mode 100644 config/rootfiles/common/ipblacklist-sources create mode 100644 html/cgi-bin/ipblacklist.cgi create mode 100644 lfs/ipblacklist-sources create mode 100644 src/misc-progs/getipsetstat.c create mode 100644 src/misc-progs/ipblacklistctrl.c create mode 100755 src/scripts/ipblacklist -- 2.16.4

3 17

Core update 139 and IPS
by Mentalic 15 Dec '19

15 Dec '19

Loaded up 139 iso on test box, restored backup from core 138. IPS cannot be started. Noticed that for the first time since running ipfire that the connect/disconnect sounds work on my hardware, nice! Thanks and Regards Wayne

2 2

[PATCH] unbound: Update to 1.9.6
by Matthias Fischer 15 Dec '19

15 Dec '19

For details see: https://nlnetlabs.nl/pipermail/unbound-users/2019-December/011941.html Signed-off-by: Matthias Fischer <matthias.fischer(a)ipfire.org> --- config/rootfiles/common/unbound | 2 +- lfs/unbound | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/config/rootfiles/common/unbound b/config/rootfiles/common/unbound index 2cde9f424..3569a4170 100644 --- a/config/rootfiles/common/unbound +++ b/config/rootfiles/common/unbound @@ -11,7 +11,7 @@ etc/unbound/unbound.conf #usr/lib/libunbound.la #usr/lib/libunbound.so usr/lib/libunbound.so.8 -usr/lib/libunbound.so.8.1.5 +usr/lib/libunbound.so.8.1.6 #usr/lib/pkgconfig/libunbound.pc usr/sbin/unbound usr/sbin/unbound-anchor diff --git a/lfs/unbound b/lfs/unbound index 126cc154d..50ce9952c 100644 --- a/lfs/unbound +++ b/lfs/unbound @@ -24,7 +24,7 @@ include Config -VER = 1.9.5 +VER = 1.9.6 THISAPP = unbound-$(VER) DL_FILE = $(THISAPP).tar.gz @@ -40,7 +40,7 @@ objects = $(DL_FILE) $(DL_FILE) = $(DL_FROM)/$(DL_FILE) -$(DL_FILE)_MD5 = deb7a3c52fec66323b508c0be4be4849 +$(DL_FILE)_MD5 = e6423d68e293ffec953477ef1adbbfb7 install : $(TARGET) -- 2.18.0

2 1

Potentially useful site regarding Linux rootkits and kernel hardening
by Peter Müller 15 Dec '19

15 Dec '19

Hello *, by digging into that topic, I bumped into https://capsule8.com/blog/dont-get-kicked-out-a-tale-of-rootkits-and-other-… a while ago. In my humble opinion, this is a rare example of an useful comparison of different Linux rootkit types and techniques. Regarding Linux kernel hardening, these resources might also be of interest: - https://capsule8.com/blog/millions-of-binaries-later:-a-look-into-linux-har… - https://capsule8.com/blog/kernel-configuration-glossary/ I unfortunately did not have time yet to check whether IPFire can be improved here. Perhaps something to do over Christmas... Thanks, and best regards, Peter Müller

1 0

[PATCH 1/2] suricata: Update to 4.1.6
by Matthias Fischer 14 Dec '19

14 Dec '19

Excerpt from 'ChangeLog': "4.1.6 -- 2019-12-13 Bug #3276: address parsing: memory leak in error path (4.1.x) Bug #3278: segfault when test a nfs pcap file (4.1.x) Bug #3279: ikev2 enabled in config even if Rust is disabled Bug #3325: lua issues on arm (fedora:29) (4.1.x) Bug #3326: Static build with pcap fails (4.1.x) Bug #3327: tcp: empty SACK option leads to decoder event (4.1.x) Bug #3347: BPF filter on command line not honored for pcap file (4.1.x) Bug #3355: DNS: DNS over TCP transactions logged with wrong direction. (4.1.x) Bug #3356: DHCP: Slow down over time due to lack of detect flags (4.1.x) Bug #3369: byte_extract does not work in some situations (4.1.x) Bug #3385: fast-log: icmp type prints wrong value (4.1.x) Bug #3387: suricata is logging tls log repeatedly if custom mode is enabled (4.1.x) Bug #3388: TLS Lua output does not work without TLS log (4.1.x) Bug #3391: Suricata is unable to get MTU from NIC after 4.1.0 (4.1.x) Bug #3393: http: pipelining tx id handling broken (4.1.x) Bug #3394: TCP evasion technique by overlapping a TCP segment with a fake packet (4.1.x) Bug #3395: TCP evasion technique by faking a closed TCP session (4.1.x) Bug #3402: smb: post-GAP some transactions never close (4.1.x) Bug #3403: smb1: 'event only' transactions for bad requests never close (4.1.x) Bug #3404: smtp: file tracking issues when more than one attachment in a tx (4.1.x) Bug #3405: Filehash rule does not fire without filestore keyword Bug #3410: intermittent abort()s at shutdown and in unix-socket (4.1.x) Bug #3412: detect/asn1: crashes on packets smaller than offset setting (4.1.x) Task #3367: configure: Rust 1.37+ has cargo-vendor support bundled into cargo (4.1.x)" Signed-off-by: Matthias Fischer <matthias.fischer(a)ipfire.org> --- lfs/suricata | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lfs/suricata b/lfs/suricata index 12dcfe08c..b3d22003b 100644 --- a/lfs/suricata +++ b/lfs/suricata @@ -24,7 +24,7 @@ include Config -VER = 4.1.5 +VER = 4.1.6 THISAPP = suricata-$(VER) DL_FILE = $(THISAPP).tar.gz @@ -40,7 +40,7 @@ objects = $(DL_FILE) $(DL_FILE) = $(DL_FROM)/$(DL_FILE) -$(DL_FILE)_MD5 = 0dfd68f6f4314c5c2eed7128112eff3b +$(DL_FILE)_MD5 = da5de1e8053f05cbd295793210117d34 install : $(TARGET) -- 2.18.0

1 1

[PATCH] knot: Update to 2.9.2
by Matthias Fischer 14 Dec '19

14 Dec '19

For details see: https://www.knot-dns.cz/2019-12-12-version-292.html Signed-off-by: Matthias Fischer <matthias.fischer(a)ipfire.org> --- config/rootfiles/common/knot | 4 ++-- lfs/knot | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/config/rootfiles/common/knot b/config/rootfiles/common/knot index c0d900e6b..960f14d0a 100644 --- a/config/rootfiles/common/knot +++ b/config/rootfiles/common/knot @@ -9,7 +9,7 @@ usr/lib/libdnssec.so.7.0.0 #usr/lib/libknot.la #usr/lib/libknot.lai #usr/lib/libknot.so -usr/lib/libknot.so.9 -usr/lib/libknot.so.9.0.0 +usr/lib/libknot.so.10 +usr/lib/libknot.so.10.0.0 #usr/lib/libknotus.a #usr/lib/libknotus.la diff --git a/lfs/knot b/lfs/knot index 467f077db..513314e92 100644 --- a/lfs/knot +++ b/lfs/knot @@ -24,7 +24,7 @@ include Config -VER = 2.8.4 +VER = 2.9.2 THISAPP = knot-$(VER) DL_FILE = $(THISAPP).tar.xz @@ -40,7 +40,7 @@ objects = $(DL_FILE) $(DL_FILE) = $(DL_FROM)/$(DL_FILE) -$(DL_FILE)_MD5 = d2540d0a392e2f47fe48e5cf7bf491c9 +$(DL_FILE)_MD5 = 4f5ccc7b136858bb5dae8eacb2d3c4fe install : $(TARGET) -- 2.18.0

1 0

[PATCH] Fix bug 12252: updxlrator - handle \ in filename
by Justin Luth 13 Dec '19

13 Dec '19

Recently some Microsoft patches are alternating between using \ and / as directory separators, leaving files behind in /var/updatecache/download that can only be removed in a terminal. What was happening was that the lock file was created using the URL name containing %5c while wget was actually writing to a filename with a real backslash. The zero-sized lockfile was moved into the uuid folder, and the actual .cab file was orphaned in the download folder, indicated in the GUI as a stranded file that couldn't be deleted. An alternate way to fix the problem could be to force wget to use --restrict-file-names=windows - in which case \ | : ? " * < > would all be saved as escaped codes. That would seem to better match the URL mangling that apparently is happening. Cons: -removing sourceurl mangling means re-downloading existing caches. -less human-readable URLs / filesnames -conceptual alternative: I didn't prove/test this theory since it means re-downloading all oddly-named files. P.S. I didn't change perl's utime command to use updatefile_shellEscaped since the filepath is in quotes - the space didn't actually need to be escaped. --- config/updxlrator/download | 20 ++++++++++++++++---- config/updxlrator/updxlrator | 2 ++ 2 files changed, 18 insertions(+), 4 deletions(-) diff --git a/config/updxlrator/download b/config/updxlrator/download index afa6e6cb9..df4a58725 100644 --- a/config/updxlrator/download +++ b/config/updxlrator/download @@ -26,6 +26,7 @@ my @http_header=(); my $remote_size=0; my $remote_mtime=0; my $updatefile=''; +my $updatefile_shellEscaped=''; #double escaped for re-processing by shell/system calls my $unique=0; my $mirror=1; @@ -38,11 +39,24 @@ my $restartdl = defined($ARGV[3]) ? $ARGV[3] : 0; umask(0002); +# Hopefully correct documentation: based on debugging a "\" problem... +# WGET doesn't use the filename from the URL, but gets the filename from the server info. +# -mangles that name according to --restrict-file-names. +# -for unix, only mangles "/", so +, ~, \ etc. are not escaped/mangled. +# -(which suggests the entry for %2f is incorrect BTW) +# The URL passed to this module is mangled (correct? - perhaps by http://search.cpan.org/dist/URI/lib/URI/Escape.pm) +# -but $updatefile needs to match wget's download name, regardless of the URL's encoding. +# -achievable either by mangling the URL and/or the filename. +# -*make sure "updxlrator" has the same adjustments* $sourceurl =~ s@\%2b@+@ig; $sourceurl =~ s@\%2f@/@ig; $sourceurl =~ s@\%7e@~@ig; $updatefile = substr($sourceurl,rindex($sourceurl,"/")+1); +$updatefile_shellEscaped = $updatefile; +$updatefile_shellEscaped =~ s@\%20@\\ @ig; +$updatefile_shellEscaped =~ s@\%5c@\\\\@ig; $updatefile =~ s@\%20@ @ig; +$updatefile =~ s@\%5c@\\@ig; $vendorid =~ tr/A-Z/a-z/; unless (-d "$repository/download/$vendorid") @@ -58,7 +72,7 @@ if($restartdl == 0) # hinder multiple downloads from starting simultaneously. Create empty "lock" file. # TODO: Another thread may sneak in between these two commands - so not fool-proof, but good enough? - system("touch $repository/download/$vendorid/$updatefile"); + system("touch $repository/download/$vendorid/$updatefile_shellEscaped"); } else @@ -169,11 +183,9 @@ if ($_ == 0) } &writelog("Moving file to the cache directory: $vendorid/$uuid"); - $updatefile =~ s@ @\\ @ig; - system("mv $repository/download/$vendorid/$updatefile $repository/$vendorid/$uuid"); + system("mv $repository/download/$vendorid/$updatefile_shellEscaped $repository/$vendorid/$uuid"); # Workaround for IPCop's mv bug: utime time,$remote_mtime,"$repository/$vendorid/$uuid/$updatefile"; - $updatefile =~ s@\\ @ @ig; &UPDXLT::setcachestatus("$repository/$vendorid/$uuid/source.url",$sourceurl); &UPDXLT::setcachestatus("$repository/$vendorid/$uuid/status",$UPDXLT::sfOk); diff --git a/config/updxlrator/updxlrator b/config/updxlrator/updxlrator index cdc7eeb50..1febae51e 100644 --- a/config/updxlrator/updxlrator +++ b/config/updxlrator/updxlrator @@ -338,11 +338,13 @@ sub check_cache my $sourceurl=$_[0]; my $cfmirror=$_[4]; + # Any changes made here must be mirrored in "download" $sourceurl =~ s@\%2b@+@ig; $sourceurl =~ s@\%2f@/@ig; $sourceurl =~ s@\%7e@~@ig; $updfile = substr($sourceurl,rindex($sourceurl,"/")+1); $updfile =~ s@\%20@ @ig; + $updfile =~ s@\%5c@\\@ig; if ($cfmirror) { -- 2.17.1

2 3

Observing (malicious?) traffic from RFC 1918 source IP addresses to ppp0 interfaces
by Peter Müller 13 Dec '19

13 Dec '19

Hello *, thanks to very close IPS log monitoring, I stumbled across some packets from RFC 1918 addresses to the public IPv4 address on the ppp0 interface (ADSL connection) of an IPFire machine: > 12/09/2019-11:38:23.050370 [Drop] [**] [1:2010935:3] ET SCAN Suspicious inbound to MSSQL port 1433 [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 10.66.1.11:49902 -> 85.XXX.XXX.XXX:1433 > 12/12/2019-09:30:46.800360 [Drop] [**] [1:2010935:3] ET SCAN Suspicious inbound to MSSQL port 1433 [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 192.168.145.52:53061 -> 85.XXX.XXX.XXX:1433 Digging more deeply into the packet filter logs, this seems to happen quite frequently (I guess those both packets above were not logged because the IPS already dropped them; otherwise it would be really alarming): > Dec 8 21:49:14 fw-01 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.170 DST=85.XXX.XXX.XXX LEN=40 TOS=0x00 PREC=0x00 TTL=52 ID=18456 PROTO=TCP SPT=54261 DPT=5555 WINDOW=60621 RES=0x00 SYN URGP=0 > Dec 9 11:01:29 fw-01 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=10.0.0.8 DST=85.XXX.XXX.XXX LEN=44 TOS=0x00 PREC=0x00 TTL=51 ID=29997 PROTO=TCP SPT=30279 DPT=23 WINDOW=6695 RES=0x00 SYN URGP=0 > Dec 9 20:52:38 fw-01 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=10.10.204.161 DST=85.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=112 ID=25793 DF PROTO=TCP SPT=2146 DPT=445 WINDOW=8192 RES=0x00 SYN URGP=0 > Dec 9 21:22:07 fw-01 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.120 DST=85.XXX.XXX.XXX LEN=44 TOS=0x00 PREC=0x00 TTL=51 ID=60440 PROTO=TCP SPT=48033 DPT=23 WINDOW=57033 RES=0x00 SYN URGP=0 > Dec 11 14:29:09 fw-01 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.76 DST=85.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=115 ID=30575 DF PROTO=TCP SPT=59055 DPT=8291 WINDOW=8192 RES=0x00 SYN URGP=0 > Dec 11 14:29:12 fw-01 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.76 DST=85.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=115 ID=15843 DF PROTO=TCP SPT=59055 DPT=8291 WINDOW=8192 RES=0x00 SYN URGP=0 > Dec 11 14:29:13 fw-01 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.76 DST=85.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=115 ID=29263 DF PROTO=TCP SPT=58991 DPT=8291 WINDOW=8192 RES=0x00 SYN URGP=0 > Dec 11 14:29:16 fw-01 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.76 DST=85.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=115 ID=17475 DF PROTO=TCP SPT=58991 DPT=8291 WINDOW=8192 RES=0x00 SYN URGP=0 > Dec 11 14:29:16 fw-01 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.76 DST=85.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=115 ID=17600 DF PROTO=TCP SPT=59050 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0 > Dec 11 14:29:20 fw-01 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.76 DST=85.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=115 ID=11551 DF PROTO=TCP SPT=59050 DPT=8728 WINDOW=8192 RES=0x00 SYN URGP=0 > Dec 11 23:51:27 fw-01 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=172.16.42.211 DST=85.XXX.XXX.XXX LEN=40 TOS=0x00 PREC=0x00 TTL=54 ID=10682 PROTO=TCP SPT=20479 DPT=80 WINDOW=28891 RES=0x00 SYN URGP=0 > Dec 12 16:00:57 fw-01 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=172.21.75.234 DST=85.XXX.XXX.XXX LEN=40 TOS=0x00 PREC=0x00 TTL=52 ID=36323 PROTO=TCP SPT=57273 DPT=9527 WINDOW=39680 RES=0x00 SYN URGP=0 I initially blamed the (rather small German) ISP of that machine for not dropping bogon traffic at their edge routers. However, the same - hostile? - traffic can also be observed at different locations behind different ISPs (using VDSL here): > Dec 9 23:37:18 fw-02 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.170 DST=85.XXX.XXX.XXX LEN=40 TOS=0x00 PREC=0x00 TTL=52 ID=45421 PROTO=TCP SPT=54261 DPT=5555 WINDOW=60621 RES=0x00 SYN URGP=0 > Dec 10 09:44:52 fw-02 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.100.159 DST=85.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=112 ID=2893 DF PROTO=TCP SPT=50188 DPT=445 WINDOW=8192 RES=0x00 SYN URGP=0 > Dec 11 14:29:08 fw-02 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.76 DST=85.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=116 ID=23895 DF PROTO=TCP SPT=52374 DPT=8291 WINDOW=8192 RES=0x00 SYN URGP=0 > Dec 11 14:29:11 fw-02 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.76 DST=85.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=116 ID=7772 DF PROTO=TCP SPT=52374 DPT=8291 WINDOW=8192 RES=0x00 SYN URGP=0 > Dec 11 14:29:12 fw-02 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.76 DST=85.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=116 ID=15452 DF PROTO=TCP SPT=52374 DPT=8291 WINDOW=8192 RES=0x00 SYN URGP=0 > Dec 11 14:29:15 fw-02 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.76 DST=85.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=116 ID=8231 DF PROTO=TCP SPT=52374 DPT=8291 WINDOW=8192 RES=0x00 SYN URGP=0 > Dec 11 14:29:15 fw-02 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.76 DST=85.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=116 ID=8764 DF PROTO=TCP SPT=52374 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0 > Dec 11 14:29:18 fw-02 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.76 DST=85.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=116 ID=29653 DF PROTO=TCP SPT=52374 DPT=8728 WINDOW=8192 RES=0x00 SYN URGP=0 > Dec 11 14:29:21 fw-02 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.76 DST=85.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=116 ID=23036 DF PROTO=TCP SPT=52374 DPT=8728 WINDOW=8192 RES=0x00 SYN URGP=0 > Dec 2 21:09:01 fw-03 kernel: INPUTFW IN=ppp0 OUT= MAC= SRC=10.79.38.29 DST=87.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=112 ID=3529 DF PROTO=TCP SPT=63955 DPT=445 WINDOW=8192 RES=0x00 SYN URGP=0 > Dec 3 09:19:53 fw-03 kernel: INPUTFW IN=ppp0 OUT= MAC= SRC=192.168.254.129 DST=83.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=119 ID=31437 DF PROTO=TCP SPT=52877 DPT=445 WINDOW=8192 RES=0x00 SYN URGP=0 > Dec 4 15:04:01 fw-03 kernel: INPUTFW IN=ppp0 OUT= MAC= SRC=10.6.199.89 DST=87.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=117 ID=2522 DF PROTO=TCP SPT=59118 DPT=445 WINDOW=8192 RES=0x00 SYN URGP=0 > Dec 12 13:31:33 fw-03 kernel: INPUTFW IN=ppp0 OUT= MAC= SRC=10.78.21.142 DST=83.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=111 ID=12337 DF PROTO=TCP SPT=59620 DPT=445 WINDOW=8192 RES=0x00 SYN URGP=0 Looking at these log lines, this kind of traffic seems hostile to me as it targets commonly attacked ports such as 22, 23 and 445. I talked to Michael about attack vectors such as injecting traffic from remote IPsec networks (which can also appear on ppp0) the other day, and to his opinion, that is not possible. For obvious reasons, I am very keen to learn how this traffic is even routable at that place. An ISP support department suggested someone on the same house connection line is injecting traffic, claiming that DSLAM linecard ports usually do not allow DSL subscribers to talk to each other directly, provided the DSLAM operator (which is Deutsche Telekom AG for nearly every location in Germany) filters RFC 1918 traffic. Either way, this precisely shows why we need a universal switch to drop traffic from and to RFC 1918 (and other) networks on the RED/ppp0 interface of an IPFire machine. As far as I am concerned, this can be done regardless of the blacklist patchset Tim handed in and is not safe to be enabled by default. If someone else has additional information on this topic, please drop me a line. :-) Thanks, and best regards, Peter Müller

2 1

[PATCH] Core Update 139: fix syntax of generated Suricata DNS server file
by Peter Müller 13 Dec '19

13 Dec '19

The YAML syntax of /var/ipfire/suricata/suricata-dns-servers.yaml was invalid and caused Suricata to crash after upgrading to Core Update 139. Due to strange NFQUEUE behaviour, this caused IPsec traffic to be emitted to the internet directly. While this patch represents a quick solution for Core Update 139, another one is needed for changing the IPtables chain order to avoid similar information leaks in future. Thanks to Michael for his debugging effort. Fixes #12260 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> --- config/cfgroot/ids-functions.pl | 51 +++++++++++++++++++++-------------------- 1 file changed, 26 insertions(+), 25 deletions(-) diff --git a/config/cfgroot/ids-functions.pl b/config/cfgroot/ids-functions.pl index 54d86f70f..89ad90c2e 100644 --- a/config/cfgroot/ids-functions.pl +++ b/config/cfgroot/ids-functions.pl @@ -17,7 +17,7 @@ # along with IPFire; if not, write to the Free Software # # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA # # # -# Copyright (C) 2018 IPFire Team <info(a)ipfire.org>. # +# Copyright (C) 2018-2019 IPFire Team <info(a)ipfire.org> # # # ############################################################################ @@ -706,7 +706,7 @@ sub generate_dns_servers_file() { open (FILE, "${General::swroot}/red/dns") or die "Could not read DNS configuration from ${General::swroot}/red/dns. $!\n"; # Read-in whole file content and store it in a temporary array. - my @file_content = <FILE>; + my @file_content = split(' ', <FILE>); # Close file handle. close(FILE); @@ -714,31 +714,32 @@ sub generate_dns_servers_file() { # Format dns servers declaration. my $line = "\"\["; - # Loop through the array which contains the file content. - foreach my $server (@file_content) { - # Remove newlines. - chomp($server); - - # Check if the current DNS configuration is using the local recursor mode. - if ($server eq "local recursor") { - # The responsible DNS servers on red are directly used, and because we are not able - # to specify each single DNS server address here, we currently have to thread each - # address which is not part of the HOME_NET as possible DNS server. - $line = "$line" . "!\$HOME_NET"; - } else { + # Check if the current DNS configuration is using the local recursor mode. + if ($file_content[0] eq "local" && $file_content[1] eq "recursor") { + # The responsible DNS servers on red are directly used, and because we are not able + # to specify each single DNS server address here, we currently have to thread each + # address which is not part of the HOME_NET as possible DNS server. + $line = "$line" . "!\$HOME_NET"; + + } else { + # Loop through the array which contains the file content. + foreach my $server (@file_content) { + # Remove newlines. + chomp($server); + # Add the DNS server to the line. $line = "$line" . "$server"; + + # Check if the current DNS server was the last in the array. + if ($server ne $file_content[-1]) { + # Add "," for the next DNS server. + $line = "$line" . "\,"; + } } + } - # Check if the current DNS server was the last in the array. - if ($server eq $file_content[-1]) { - # Close the line. - $line = "$line" . "\]\""; - } else { - # Add "," for the next DNS server. - $line = "$line" . "\,"; - } - } + # Close the line... + $line = "$line" . "\]\""; # Open file to store the used DNS server addresses. open(FILE, ">$dns_servers_file") or die "Could not open $dns_servers_file. $!\n"; @@ -866,7 +867,7 @@ sub get_suricata_version($) { # Remove newlines. chomp($version_string); - # Grab the version from the version string. + # Grab the version from the version string. $version_string =~ /([0-9]+([.][0-9]+)+)/; # Splitt the version into single chunks. @@ -882,7 +883,7 @@ sub get_suricata_version($) { } else { # Return the full version string. return "$major_ver.$minor_ver.$patchlevel"; - } + } } # -- 2.16.4

2 1

Core Update 139 (testing) report
by Peter Müller 13 Dec '19

13 Dec '19

Hello *, upcoming Core Update 139 (testing, see: https://blog.ipfire.org/post/ipfire-2-23-core-update-139-is-available-for-t…) is running here for about 24 hours by now, and caused major trouble especially related to IPsec. First, the update did not triggered a "reboot is requried" message, which is obligatory since we are shipping some new Intel microcodes. Those need a reboot in order to be loaded into the CPU. Second, I forgot to execute /usr/local/bin/sshctrl during update (update.sh), so user settings were not applied to the SSH configuration. My fault (again). Third, IPsec N2N connections are not set up automatically after rebooting although they were configured to be. Worse, something seems to go seriously wrong, as traffic to a destination IP address on the other side of the IPsec connection is emitted directly to the internet. Surprisingly enough, connections initiated from the remote network behind an IPsec connection succeed and response packets apparently are sent back through the tunnel. Reason for this is unknown; as far as I am concerned, this Core Update is not yet ready. I will open bug tickets for the problems mentioned above (and others, if necessary). Output of "uname -a" for reference purposes: > [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 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

Development December 2019