Development January 2020

development@lists.ipfire.org

14 participants
58 discussions

[PATCH] BUG11695: Adding/editing rules with preset broken
by Alexander Marx 15 Jul '21

15 Jul '21

added another check to fill same ports in source and destination when a custom service is selected. Signed-off-by: Alexander Marx <alexander.marx(a)ipfire.org> Reported-by: erik(a)vanlinsteeict.nl --- html/cgi-bin/firewall.cgi | 1 + 1 file changed, 1 insertion(+) diff --git a/html/cgi-bin/firewall.cgi b/html/cgi-bin/firewall.cgi index 499f279..d17afab 100644 --- a/html/cgi-bin/firewall.cgi +++ b/html/cgi-bin/firewall.cgi @@ -757,6 +757,7 @@ sub checkrule } } if($fwdfwsettings{'nat'} eq 'dnat' && $fwdfwsettings{'dnatport'} eq ''){$fwdfwsettings{'dnatport'}=$custsrvport;} + if($fwdfwsettings{'nat'} eq 'dnat' && $fwdfwsettings{'grp3'} eq 'cust_srv'){$fwdfwsettings{'dnatport'}=$custsrvport;} } #check if DNAT port is multiple if($fwdfwsettings{'nat'} eq 'dnat' && $fwdfwsettings{'dnatport'} ne ''){ -- 2.7.4

3 2

[PATCH 1/2] mail.cgi: add support for implicit TLS usage
by Peter Müller 03 Feb '20

03 Feb '20

Fixes #12161 Reported-by: Michael Tremer <michael.tremer(a)ipfire.org> Signed-off-by: Peter Müller <peter.mueller(a)ipfire.org> --- html/cgi-bin/mail.cgi | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/html/cgi-bin/mail.cgi b/html/cgi-bin/mail.cgi index 25589046e..8c1b2d4e4 100755 --- a/html/cgi-bin/mail.cgi +++ b/html/cgi-bin/mail.cgi @@ -2,7 +2,7 @@ ############################################################################### # # # IPFire.org - A linux based firewall # -# Copyright (C) 2015 IPFire Team <alexander.marx(a)ipfire.org> # +# Copyright (C) 2007-2020 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 # @@ -110,8 +110,8 @@ if ($cgiparams{'ACTION'} eq "$Lang::tr{'save'}"){ #SaveButton on configsite $dma{'SMARTHOST'} = $cgiparams{'txt_mailserver'}; $dma{'PORT'} = $cgiparams{'txt_mailport'}; - $dma{'STARTTLS'} = '' if ($cgiparams{'mail_tls'}); - $dma{'SECURETRANSFER'} = '' if exists $dma{'STARTTLS'}; + $dma{'STARTTLS'} = '' if ($cgiparams{'mail_tls'}{'explicit'}); + $dma{'SECURETRANS'} = '' if ($cgiparams{'mail_tls'}{'explicit'} || $cgiparams{'mail_tls'}{'implicit'}); $dma{'SPOOLDIR'} = "/var/spool/dma"; $dma{'FULLBOUNCE'} = ''; $dma{'MAILNAME'} = "$mainsettings{'HOSTNAME'}.$mainsettings{DOMAINNAME}"; @@ -140,8 +140,6 @@ if ($cgiparams{'ACTION'} eq "$Lang::tr{'email testmail'}"){ #Testmail button on #FUNCTIONS sub configsite{ - - #If update set fieldvalues new if($cgiparams{'update'} eq 'on'){ $mail{'USEMAIL'} = 'on'; @@ -156,7 +154,9 @@ sub configsite{ } #find preselections $checked{'usemail'}{$mail{'USEMAIL'}} = 'CHECKED'; - $checked{'mail_tls'}{'on'} = 'CHECKED' if exists $dma{'STARTTLS'}; + $selected{'mail_tls'}{'explicit'} = 'selected' if exists $dma{'STARTTLS'}; + $selected{'mail_tls'}{'implicit'} = 'selected' if exists $dma{'SECURETRANS'} and not $dma{'STARTTLS'}; + $selected{'mail_tls'}{'disabled'} = 'selected' if not exists ($dma{'SECURETRANS'} and $dma{'STARTTLS'}); #Open site &Header::openpage($Lang::tr{'email settings'}, 1, ''); @@ -226,7 +226,13 @@ END </tr> <tr> <td>$Lang::tr{'email tls'}</td> - <td><input type='checkbox' name='mail_tls' $checked{'mail_tls'}{'on'}></td> + <td> + <select name='mail_tls'> + <option value='implicit' $selected{'mail_tls'}{'implicit'}>$Lang::tr{'email tls implicit'}</option> + <option value='explicit' $selected{'mail_tls'}{'explicit'}>$Lang::tr{'email tls explicit'}</option> + <option value='disabled' $selected{'mail_tls'}{'disabled'}>$Lang::tr{'disabled'}</option> + </select> + </td> </tr> END if (! -z $dmafile && $mail{'USEMAIL'} eq 'on' && !$errormessage){ -- 2.16.4

2 3

[PATCH 1/2] sshd_config: Do not set defaults explicitly
by Peter Müller 03 Feb '20

03 Feb '20

In order to keep configurations as small as possible and to make them easier to read/audit, this patch omits all default configuration in the OpenSSH server configuration file. Further, it mentions where to refer for the full documentation. Signed-off-by: Peter Müller <peter.mueller(a)ipfire.org> --- config/ssh/sshd_config | 62 ++++++++++++++++---------------------------------- 1 file changed, 20 insertions(+), 42 deletions(-) diff --git a/config/ssh/sshd_config b/config/ssh/sshd_config index a248c4906..bea5cee53 100644 --- a/config/ssh/sshd_config +++ b/config/ssh/sshd_config @@ -1,81 +1,59 @@ -# ultra-secure OpenSSH server configuration +# OpenSSH server configuration file for IPFire +# +# The full documentation is available at: https://man.openbsd.org/sshd_config +# -# only allow version 2 of SSH protocol +# Only allow version 2 of SSH protocol Protocol 2 -# listen on port 22 by default +# Listen on port 22 by default Port 22 -# listen on these interfaces and protocols -AddressFamily any +# Listen on every interface and IPv4 only +AddressFamily inet ListenAddress 0.0.0.0 -# limit authentication thresholds +# Limit authentication timeout to 30 seconds LoginGraceTime 30s -MaxAuthTries 6 -# limit maximum instanctes to prevent DoS +# Limit maximum instanctes to prevent DoS MaxStartups 5 -# ensure proper logging -SyslogFacility AUTH -LogLevel INFO - -# enforce permission checks before a login is accepted -# (prevents damage because of hacked systems with world-writeable -# home directories or similar) -StrictModes yes - -# only allow safe crypto algorithms (may break some _very_ outdated clients) -# see also: https://stribika.github.io/2015/01/04/secure-secure-shell.html +# Only allow safe crypto algorithms (may break some _very_ outdated clients) +# See also: https://stribika.github.io/2015/01/04/secure-secure-shell.html KexAlgorithms curve25519-sha256(a)libssh.org,diffie-hellman-group-exchange-sha256 Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com -# enable data compression after successful login only -Compression delayed - -# only allow cryptographically safe SSH host keys (adjust paths if needed) +# Only allow cryptographically safe SSH host keys (adjust paths if needed) HostKey /etc/ssh/ssh_host_ed25519_key HostKey /etc/ssh/ssh_host_ecdsa_key HostKey /etc/ssh/ssh_host_rsa_key -# only allow login via public key by default +# Only allow login via public key by default PubkeyAuthentication yes PasswordAuthentication no ChallengeResponseAuthentication no -PermitEmptyPasswords no -# permit root login as there is no other user in IPFire 2.x +# Permit root login as there is no other user in IPFire 2.x PermitRootLogin yes -# ignore user ~/.rhost* files -IgnoreRhosts yes - -# ignore user known hosts file +# Ignore user ~/.ssh/known_hosts file IgnoreUserKnownHosts yes -# ignore user environments -PermitUserEnvironment no - -# do not allow any kind of forwarding (provides only low security) +# Do not allow any kind of forwarding (provides only low security); # some of them might need to be re-enabled if SSH server is a jump platform -X11Forwarding no AllowTcpForwarding no AllowAgentForwarding no -PermitTunnel no -GatewayPorts no PermitOpen none -# detect broken sessions by sending keep-alive messages to -# clients (both via TCP and SSH) -TCPKeepAlive yes +# Detect broken sessions by sending keep-alive messages to clients via SSH connection ClientAliveInterval 10 -# close unresponsive SSH sessions which fail to answer keep-alive +# Close unresponsive SSH sessions which fail to answer keep-alive ClientAliveCountMax 6 -# add support for SFTP +# Add support for SFTP Subsystem sftp /usr/lib/openssh/sftp-server # EOF -- 2.16.4

2 5

[PATCH] coreutils: update to 8.31
by Peter Müller 03 Feb '20

03 Feb '20

Refer to https://lists.gnu.org/archive/html/coreutils-announce/2019-03/msg00000.html for release announcements. Signed-off-by: Peter Müller <peter.mueller(a)ipfire.org> --- lfs/coreutils | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/lfs/coreutils b/lfs/coreutils index 2c282b194..90af0cc87 100644 --- a/lfs/coreutils +++ b/lfs/coreutils @@ -1,7 +1,7 @@ ############################################################################### # # # IPFire.org - A linux based firewall # -# Copyright (C) 2007-2018 IPFire Team <info(a)ipfire.org> # +# Copyright (C) 2007-2020 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 = 8.30 +VER = 8.31 THISAPP = coreutils-$(VER) DL_FILE = $(THISAPP).tar.xz @@ -63,7 +63,7 @@ objects =$(DL_FILE) $(DL_FILE)= $(DL_FROM)/$(DL_FILE) -$(DL_FILE)_MD5 = ab06d68949758971fe744db66b572816 +$(DL_FILE)_MD5 = 0009a224d8e288e8ec406ef0161f9293 install : $(TARGET) -- 2.16.4

2 2

unbound.conf: Do not set defaults explicitly
by Peter Müller 03 Feb '20

03 Feb '20

In order to keep configuration files small and easy to review/audit, omitting defaults makes more sense than configure them explicitly (have changed my mind here). Unbound comes with a good default confiuration, and we should only make changes when they are necessary. In addition, this patch updates the documentation's URL to the current one. Signed-off-by: Peter Müller <peter.mueller(a)ipfire.org> Cc: Michael Tremer <michael.tremer(a)ipfire.org> --- config/unbound/unbound.conf | 22 ++-------------------- 1 file changed, 2 insertions(+), 20 deletions(-) diff --git a/config/unbound/unbound.conf b/config/unbound/unbound.conf index 24822ee67..c78ca1db7 100644 --- a/config/unbound/unbound.conf +++ b/config/unbound/unbound.conf @@ -2,7 +2,7 @@ # Unbound configuration file for IPFire # # The full documentation is available at: -# https://www.unbound.net/documentation/unbound.conf.html +# https://nlnetlabs.nl/documentation/unbound/unbound.conf/ # server: @@ -10,26 +10,17 @@ server: chroot: "" directory: "/etc/unbound" username: "nobody" - port: 53 - do-ip4: yes do-ip6: no - do-udp: yes - do-tcp: yes - so-reuseport: yes - do-not-query-localhost: yes # System Tuning include: "/etc/unbound/tuning.conf" # Logging Options - verbosity: 1 use-syslog: yes log-time-ascii: yes - log-queries: no # Unbound Statistics statistics-interval: 86400 - statistics-cumulative: yes extended-statistics: yes # Prefetching @@ -42,26 +33,17 @@ server: # Privacy Options hide-identity: yes hide-version: yes - qname-minimisation: yes - minimal-responses: yes # DNSSEC auto-trust-anchor-file: "/var/lib/unbound/root.key" - val-permissive-mode: no - val-clean-additional: yes val-log-level: 1 + log-servfail: yes # Hardening Options - harden-glue: yes - harden-short-bufsize: no harden-large-queries: yes - harden-dnssec-stripped: yes - harden-below-nxdomain: yes harden-referral-path: yes - harden-algo-downgrade: no use-caps-for-id: yes aggressive-nsec: yes - qname-minimisation: yes # TLS tls-cert-bundle: /etc/ssl/certs/ca-bundle.crt -- 2.16.4

2 1

[PATCH] ddns: Update to 013
by Stefan Schantl 31 Jan '20

31 Jan '20

This is an update to the first python3-based release of ddns. Signed-off-by: Stefan Schantl <stefan.schantl(a)ipfire.org> --- lfs/ddns | 8 +-- .../ddns-012-noip-fix-handle-name.patch | 36 ---------- .../ddns-012-noip-rename-provider.patch | 65 ------------------- 3 files changed, 2 insertions(+), 107 deletions(-) delete mode 100644 src/patches/ddns-012-noip-fix-handle-name.patch delete mode 100644 src/patches/ddns-012-noip-rename-provider.patch diff --git a/lfs/ddns b/lfs/ddns index 47817c058..89ab02e96 100644 --- a/lfs/ddns +++ b/lfs/ddns @@ -24,7 +24,7 @@ include Config -VER = 012 +VER = 013 THISAPP = ddns-$(VER) DL_FILE = $(THISAPP).tar.xz @@ -40,7 +40,7 @@ objects = $(DL_FILE) $(DL_FILE) = $(DL_FROM)/$(DL_FILE) -$(DL_FILE)_MD5 = 00e70e8bf619148e14b6f6836314bbb7 +$(DL_FILE)_MD5 = a988a808a08c810c41964ac6b0febbeb install : $(TARGET) @@ -71,10 +71,6 @@ $(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects)) @$(PREBUILD) @rm -rf $(DIR_APP) && cd $(DIR_SRC) && tar axf $(DIR_DL)/$(DL_FILE) - # Add upstream patch for fixing noip.com - cd $(DIR_APP) && patch -Np1 < $(DIR_SRC)/src/patches/ddns-012-noip-rename-provider.patch - cd $(DIR_APP) && patch -Np1 < $(DIR_SRC)/src/patches/ddns-012-noip-fix-handle-name.patch - cd $(DIR_APP) && [ -x "configure" ] || sh ./autogen.sh cd $(DIR_APP) && ./configure \ --prefix=/usr \ diff --git a/src/patches/ddns-012-noip-fix-handle-name.patch b/src/patches/ddns-012-noip-fix-handle-name.patch deleted file mode 100644 index d1d281c34..000000000 --- a/src/patches/ddns-012-noip-fix-handle-name.patch +++ /dev/null @@ -1,36 +0,0 @@ -commit c0277eeea2b2c1ed8f40f1248b28438e44e51912 -Author: Stefan Schantl <stefan.schantl(a)ipfire.org> -Date: Tue Nov 12 08:43:31 2019 +0100 - - NoIP.com: Rename handle back to no-ip.com - - The old handle name is required for backward compatiblity. - - Signed-off-by: Stefan Schantl <stefan.schantl(a)ipfire.org> - -diff --git a/ddns.conf.sample b/ddns.conf.sample -index 528684f..61a608a 100644 ---- a/ddns.conf.sample -+++ b/ddns.conf.sample -@@ -120,7 +120,7 @@ - # password = pass - - # [test.noip.org] --# provider = noip.com -+# provider = no-ip.com - # username = user - # password = pass - -diff --git a/src/ddns/providers.py b/src/ddns/providers.py -index 4789107..661fbcc 100644 ---- a/src/ddns/providers.py -+++ b/src/ddns/providers.py -@@ -1344,7 +1344,7 @@ class DDNSProviderNamecheap(DDNSResponseParserXML, DDNSProvider): - - - class DDNSProviderNOIP(DDNSProtocolDynDNS2, DDNSProvider): -- handle = "noip.com" -+ handle = "no-ip.com" - name = "NoIP" - website = "http://www.noip.com/" - protocols = ("ipv4",) diff --git a/src/patches/ddns-012-noip-rename-provider.patch b/src/patches/ddns-012-noip-rename-provider.patch deleted file mode 100644 index acc5e66a7..000000000 --- a/src/patches/ddns-012-noip-rename-provider.patch +++ /dev/null @@ -1,65 +0,0 @@ -commit bfdba55a5eeb3dac5ed35ff72b6c74b941da6445 -Author: Stefan Schantl <stefan.schantl(a)ipfire.org> -Date: Tue Nov 5 19:09:53 2019 +0100 - - No-IP.com: Rename provider and handle to NoIP.com - - Fixes #11561. - - Signed-off-by: Stefan Schantl <stefan.schantl(a)ipfire.org> - -diff --git a/README b/README -index 76f63bc..c75c448 100644 ---- a/README -+++ b/README -@@ -75,7 +75,7 @@ SUPPORTED PROVIDERS: - loopia.se - myonlineportal.net - namecheap.com -- no-ip.com -+ noip.com - now-dns.com - nsupdate.info - opendns.com -diff --git a/ddns.conf.sample b/ddns.conf.sample -index 5b3b845..528684f 100644 ---- a/ddns.conf.sample -+++ b/ddns.conf.sample -@@ -119,8 +119,8 @@ - # provider = namecheap.com - # password = pass - --# [test.no-ip.org] --# provider = no-ip.com -+# [test.noip.org] -+# provider = noip.com - # username = user - # password = pass - -diff --git a/src/ddns/providers.py b/src/ddns/providers.py -index f3c62c1..4789107 100644 ---- a/src/ddns/providers.py -+++ b/src/ddns/providers.py -@@ -1344,16 +1344,16 @@ class DDNSProviderNamecheap(DDNSResponseParserXML, DDNSProvider): - - - class DDNSProviderNOIP(DDNSProtocolDynDNS2, DDNSProvider): -- handle = "no-ip.com" -- name = "No-IP" -- website = "http://www.no-ip.com/" -+ handle = "noip.com" -+ name = "NoIP" -+ website = "http://www.noip.com/" - protocols = ("ipv4",) - - # Information about the format of the HTTP request is to be found -- # here: http://www.no-ip.com/integrate/request and -- # here: http://www.no-ip.com/integrate/response -+ # here: http://www.noip.com/integrate/request and -+ # here: http://www.noip.com/integrate/response - -- url = "http://dynupdate.no-ip.com/nic/update" -+ url = "http://dynupdate.noip.com/nic/update" - - def prepare_request_data(self, proto): - assert proto == "ipv4" -- 2.25.0

2 1

Re: [PATCH 0/5] ipblacklist: IP Address Blacklists
by Michael Tremer 30 Jan '20

30 Jan '20

Hi, > On 16 Dec 2019, at 20:06, Tim FitzGeorge <lists(a)tfitzgeorge.me.uk> wrote: > > Hi, > > I've attached the current GUI screenshot. Thanks for that. I have a couple of suggestions/concerns about it: a) I am not sure what the value is about the top box that is called “Status”. It is basically a summary of the iptables output, but will it help the user? A blacklist with more or fewer entries is not better or worse, blocking more packets isn’t better than blocking fewer. It is about the quality of the blocks. b) I would prefer to move the settings box to the top. If you like you can show the size of the blacklists there and when they have been updated, too. c) I would suggest to remove the “safe” column because that is a very hard summary of what the lists do. We should explain that on the wiki. I guess this is too complicated to explain to our users in one sentence and it needs at least a page of text. People who do not read that have you just lost out. d) I do not understand what the “update check rate” means. I suppose we should show the update interval of the lists in the table and just refresh them according to that. e) Do we want to keep the automatic blacklists now? I do not think it will actually improve the security of IPFire. > > I'll update the code based on our discussions, and submit an updated set > of patches - I imagine there will have to be at least one more iteration. Let’s wait until we have come to decisions :) -Michael > > Tim > > (No additional comments below) > > On 13/12/2019 23:11, Michael Tremer wrote: >> Hi, >> >> Again my apologies for my late reply. Busy busy weeks. >> >>> On 8 Dec 2019, at 20:50, Tim FitzGeorge <ipfr(a)tfitzgeorge.me.uk> wrote: >>> >>> Hello, >>> >>> It's my turn to apologise for being slow to respond - I've had a busy >>> week, but I should have plenty of time over the next couple of weeks. >> >> No worries. Turns out we all do :) >> >>> I've made most of the comments inline, however I think Michael had a >>> question (which I can't find now) about what happens if someone enables >>> all the lists. One thing which would perhaps make this less likely is >>> that the WUI tags the available lists with whether they're safe or not, >>> with a footnote that safe means that the list only blocks malicious >>> traffic. This won't guarantee that a user won't still try to enable all >>> the lists, but it should make them realise that they should think first. >> >> We had a couple of features going slightly wrong or being “misunderstood” by some users. People still seem to panic when they see “local recursor”. To this day I do not know why. >> >> We cannot make everything idiot-proof. And when some user if of that category, they probably should shutdown their IPFire box, educate themselves and then come back again. So I do not want to limit people, but make things as easy as possible. >> >> If someone enables all the lists, good luck with passing packets :) >> >>> I have considered replacing this tag with a risk high/medium/low and >>> maybe adding a category (invalid/application/scanner/C&C or something >>> like that), but that may provide too much information and dissuade them >>> from actually following the links to checkout what the list actually does. >> >> Can we have a screenshot of the GUI right now? I didn’t run the code, yet. >> >> We should document the lists like we do it with the rulesets of the IPS. People might ignore this, but that is on them. >> >>> >>> Tim >>> >>> >>> On 05/12/2019 22:25, Michael Tremer wrote: >>>> Hello, >>>> >>>>> On 4 Dec 2019, at 17:05, Peter Müller <peter.mueller(a)ipfire.org> wrote: >>>>> >>>>> Hello Tim, hello Michael, >>>>> >>>>> please see my responses inline... >>>>>>>> >>>>>>>> We could periodically update the blacklists on our main mirror (and >>>>>>>> wait for the network to sync it), make sure it is signed and write >>>>>>>> a small downloader that fetches, validates and installs them. >>>>>>>> >>>>>>>> @All: Thoughts on this? >>>>>>> >>>>>>> I think there are a number of points here. >>>>>>> >>>>>>> Firstly, from the point of a third party using IPFire, is this really >>>>>>> solving the privacy disclosure problem? There's no way round disclosing >>>>>>> your public IP address to someone you're downloading from; all this does >>>>>>> is change who that information is being disclosed to. For the user >>>>>>> there's no way of knowing whether the source is more or less protective >>>>>>> of the user's privacy than the blacklist provider. Indeed it won't be >>>>>>> possible to know who the lists are being downloaded from until the >>>>>>> download starts. >>>>>> >>>>>> There is a way: Tor. But that is a totally different story. >>>>> Well, I see a third option on this: Use the mirror infrastructure we already >>>>> have. Every IPFire installation discloses its public IP address to one of these >>>>> servers sooner or later, so we do not disclose additional data if the blacklists >>>>> were fetched from these. >>>>> >>>>> Needless to say, Tor (hidden services) would be better, but that is a different >>>>> story indeed. :-) >>>>>> >>>>>> The point is rather that a forget list can be sent instead of the “real” one. >>>>> I did not get this. Forget? Forged?? ??? >>>> >>>> Yes, I meant to write forged, but auto-correct didn’t let me. >>>> >>>>>>> Secondly, latency; some of the lists are updated every 5 minutes. While >>>>>>> I've limited the maximum check rate to hourly, will the updates >>>>>>> propagate quickly enough. For reference on my main system the 24 >>>>>>> updates on the CIARMY list made 143 498 changes (additions or >>>>>>> deletions). I've seem it do over 200 000. >>>>> Yes, I observe that behaviour for CINS/CIArmy too. Unfortunately, they do not >>>>> document a recommended update interval anywhere, so we can only guess. >>>>> >>>>> Personally, more static lists seem to be preferable for packet filtering. Highly >>>>> dynamic ones such as CIArmy should be done via DNSBL queries or something similar >>>>> - do we really want to have that list here? >>>> >>>> It is not really an option to implement a DNSBL into a packet filter, but I get your point. >>> >>> One of the 'selling points' for an IP address blacklist is that it can >>> respond quickly to new threats - or rather new attackers. While a new >>> IDS/IPS rule needs time to analyse the threat, generate a rule and check >>> it, it's easy to add an address to a list. So, I think the CIArmy list >>> is potentially useful for protecting home systems etc. with budget >>> hardware, but I would be very careful about using it for a protecting a >>> general access website. >> >> If they are very volatile, we should honour that and update them often, too. >> >> It probably is more about false-positives being removed very quickly instead of adding threats very quickly. The average IPFire user is probably not under threats like these to need to react very quickly. >> >> So I do not see much value in adding those lists and then updating once a day. Does it have to be every 5 min? No. I would suggest 15 which should be good enough for everyone. >> >> Other lists should of course not be updated every 15 minutes when not needed. >> >> Running every 15 minutes would allow us to retry downloading lists that are on an hourly schedule if the download failed. >> >>>> >>>>>> How did you come up with the hour? Will it be retried more often if the download was not successful? >>>>> One hour is the most common interval indeed, but adding some random time might >>>>> be useful in order to reduce load on the servers providing a blacklist. >>>> >>>> Yes, definitely. Otherwise we will shoot down our mirrors. >>> >>> When I implemented that section of code, specifying the minimum check >>> period in hours seemed to provide a convenient way of allowing a check >>> period covering a wide range, with an hour as the fastest and a week as >>> the slowest. I didn't looked at the CIArmy list until much later. Most >>> of the lists don't change nearly as much, but the CIArmy list is >>> described as one that deliberately responds quickly. >>> >>> From my production system, for yesterday: >>> >>> The following block lists were updated: >>> BLOCKLIST_DE: 24 Time(s) - 9341 change(s) >>> BOGON_FULL: 1 Time(s) - 10 change(s) >>> CIARMY: 24 Time(s) - 159134 change(s) >>> DSHIELD: 7 Time(s) - 18 change(s) >>> EMERGING_FWRULE: 1 Time(s) - 50 change(s) >>> FEODO_AGGRESIVE: 24 Time(s) - 13 change(s) >>> SHODAN: 1 Time(s) - 0 change(s) >>> SPAMHAUS_DROP: 1 Time(s) - 0 change(s) >>> TOR_EXIT: 24 Time(s) - 162 change(s) >> >> Very interesting statistics. >> >>> >>> and my test system: >>> >>> The following block lists were updated: >>> ALIENVAULT: 19 Time(s) - 5331 change(s) >>> EMERGING_COMPROMISED: 1 Time(s) - 26 change(s) >>> TALOS_MALICIOUS: 1 Time(s) - 36 change(s) >>> >>> That covers most of the lists. From the WUI, since 1 Dec: >>> >>> Blacklist Entries pkts bytes Last updated >>> in in >>> AUTOBLACKLIST 0 731 51144 Sun Dec 8 18:40:02 2019 >>> BLOCKLIST_DE 28020 857 46735 Sun Dec 8 18:40:02 2019 >>> BOGON_FULL 214 5255 189K Sun Dec 8 16:50:04 2019 >>> CIARMY 15000 19774 976K Sun Dec 8 18:04:01 2019 >>> DSHIELD 20 7992 321K Sun Dec 8 16:45:13 2019 >>> EMERGING_FWRULE 1647 197 8383 Fri Dec 6 05:29:07 2019 >>> FEODO_AGGRESIVE 7169 0 0 Sun Dec 8 18:50:07 2019 >>> SHODAN 32 34 1530 Sun Dec 8 17:54:09 2019 >>> SPAMHAUS_DROP 823 0 0 Fri Dec 6 18:22:35 2019 >>> SPAMHAUS_EDROP 111 82 16433 Thu Dec 5 17:27:09 2019 >>> TOR_EXIT 1055 0 0 Sun Dec 8 18:31:02 2019 >> >> This as well. >> >> Those are more packets than I would have expected. >> >>> >>> (I've left out the pkts/bytes out fields which were all 0) >>> >>> Note that where possible I do a HEAD request first and then only >>> download the list if the modification time has changed since the last >>> check. For dynamically generated lists this isn't possible. >> >> You won’t need a HEAD request for it. You can include it in the GET request. >> >> Have a look at location downloader where I use that. The server will respond with 304 and not send any payload. >> >> https://git.ipfire.org/?p=location/libloc.git;a=blob;f=src/python/location-… >> >>> >>> If the download isn't successful it just gives up and waits for the next >>> attempt (apart from the usual retries in the library). I probably >>> should to change that so that it only applies the per list minimum >>> update period in this case (specified in the sources file) rather than >>> the user specified value as well. >> >> I think it is not the worst if an update fails. It might just happen every once in a while. >> >> So I would suggest to just re-run the script more often and when the mtime of the file is older than the threshold, a download is attempted. You can use that timestamp for the GET request. >> >>> I already use a time offset on the downloads - when it's started from >>> boot, backup restore or WUI enable, it checks to see if it's installed >>> in the fcrontab, and if not adds itself at a randomly generated offset >>> in the hour. >> >> That should potentially go to red.up, or if we can settle on 15 minutes, I would consider that often enough to quickly update all lists after a reboot. >> >>> >>>> >>>>>>> Third, bandwidth; while the downloads are fairly small (ALIENVAULT is >>>>>>> the largest at a few MB), there are going to be a lot of them. How will >>>>>>> this affect the willingness of people to mirror IPFire? >>>>> I do not consider this being a problem as we do not generate that much traffic >>>>> to them. Of course, that depends on the update interval again. >>>> >>>> That depends on your point of view. >>>> >>>> I do not have a problem with this at all in my data center, but there are plenty of people with a volume-based LTE plan or simply a 128 kBit/s connection. It will take a longer time to download the lists for them. We need to mind that. >>>> >>>>>>> >>>>>>>> >>>>>>>> Talking about the preference of packet filter and IPS, I prefer to >>>>>>>> use the latter as well as it gains more insight in what kind of malicious >>>>>>>> traffic tried to pass a firewall machine. On systems with low resources, >>>>>>>> this might be problematic and removing load from the IPS can be preferred >>>>>>>> (make this configurable?!), on others, people might want to have both >>>>>>>> results. >>>>>>>> >>>>>>> You're only going to get one result for a packet whichever way round the >>>>>>> IP blacklist and IPS are since whichever comes first will drop the >>>>>>> packet before it reaches the second (well it would be possible to put >>>>>>> the IP blacklist first and get it to log and mark packets which are then >>>>>>> dropped after the IPS, but I think that's getting a little complicated. >>>>>>> In addition I've seen the messages about the trouble marking was >>>>>>> causing in the QoS). >>>>>>> >>>>>>> I think it's a 50/50 choice as to which is more valuable first; it's >>>>>>> probably going to differ from packet to packet. For me the possibility >>>>>>> of reducing the IPS load means I prefer putting the IP blacklist first >>>>>>> >>>>>>> It should be fairly easy to add the choice of where to put the IP >>>>>>> blacklist. I think it'll have to be in the main firewall script, so >>>>>>> it'll require a firewall restart, but it's not something that'll be >>>>>>> changed often. >>>>>> >>>>>> I do not think that the user should choose this. If we cannot easily make a decision, how can our users do this? Not saying they are stupid here, we are just giving them something so that they do not have to put the thought and research into things themselves and make their jobs easier. >>>>> Agreed. >>>>> >>>>>> >>>>>> I think performance matters. And if the IPS comes first, the most likely case would be that we are seeing a SYN packet that is being scanned and after that being dropped by the blacklist. It was pointless to even scan the empty packet (TCP fast open aside). This is only different for other packets with payloads. >>>>>> >>>>>> We would protect the IPS from a SYN flooding attack here at least and from scanning more packets unnecessarily. >>>>> So dropping packets from blacklisted IP addresses/networks before IPS is it, then. >>>>>> >>>>>> I do not even think it makes sense to swap the order in the outgoing direction. >>>>> Me too. >>>>> >>>>>> >>>>>> What IPFire is lacking is a statistical analysis for those logs. Collecting more and more data isn’t helpful from my point of view. Only if you are looking at a very specific thing.This is true, but I am not sure if it makes sense to spend too much work on this. >>>>> Based on my personal experience, firewall hits observed on a single machine exposed >>>>> to the internet are interesting, but the overall situation across multiple machines >>>>> is even more interesting. Very quickly, you'll end on something like a centralised >>>>> logging server and custom statistical analysis here... >>>> >>>> Probably a project for IPFire 4.0 :) >>>> >>> Or use one of the existing services, like the DSHIELD client >>> https://dshield.org/howto.html (subject to privacy concerns again). >>>>>> >>>>>>>> >>>>>>>> Personally, I consider Spamhaus DROP/EDROP can be safely enabled by default. >>>>>>>> I would love to see the bogon ruleset here, too (think about 8chan successor >>>>>>>> hosted at unallocated RIPE space in Saint Petersburg), but that will likely cause >>>>>>>> interference if RED does not have a public IP address assigned. >>>>>>> >>>>>>> I can add a field to the options file that controls whether a list is >>>>>>> enabled by default. >>>>> Thank you. :-) >>>>>> >>>>>> To stress the point from above again: We would then share all public IP addresses of all IPFire systems in the world with Spamhaus and who is hosting their infrastructure. That can be considered a threat. >>>>> This is my only objection against this patchset. Now, what can we do about it? >>>>> One possibility is to apply the patchset now and implement a custom download >>>>> source thing later on, or do that before releasing Core Update 139 (or which version >>>>> the patchset will be to) after we agreed on something. >>>> >>>> I do not see this being merged for 139. But that is not important. We need to get it right first and then release it. >>>> >>>> As far as I know, nobody has tested this, yet. >>> >>> There are a number of people who have been running an earlier version >>> which I shared on GitHub. There were a few early issues, but it seems >>> to be OK now. >>> >>> https://forum.ipfire.org/viewtopic.php?f=27&t=21845 >>> >>> This version wasn't integrated into IPFire, so (for example) it inserted >>> itself into the INPUT IPTables chain rather than having it's chains >>> created as part of the firewall start-up script. >>> >>>> >>>> I have huge concerns about the automatic blacklist. @Peter: What is your opinion on this? >>>> >>> >>> While I implemented it, I'm aware of its potential to cause problems, >>> which is why it has to be separately enabled. It's not caused me any >>> issues at the default settings (blocks at over 10 packets per hour until >>> 1 hour has passed without seeing packets from the address), but I've not >>> used it on a site with publicly announced services. If I was going to >>> use it on a web site I would want to, at the very minimum, drop the >>> block period drastically. >> >> I suppose this is entirely unusable on an IPFire box in a data center that hosts things. Let’s say our rack in Hanover. >> >> You will have hits from some broken IP stacks and people might just end up on this without doing anything wrong. >> >> You can denial-of-service easily as well and I suppose without aggregation of data from many many systems, it does not make sense to instantly block addresses. And even then you probably would block an entire subnet. >> >> So I am not sure how I should feel about it. I do not think that it adds anything because the packets would have been blocked anyways. >> >>> >>> On the other hand, it's good at responding quickly. Usually I see only >>> 1-2% of blocks from the automatic list: >>> >>> Reason Count % First Last >>> CIARMY 2416 45 Dec 6 00:00 Dec 6 23:59 >>> DSHIELD 1353 25 Dec 6 00:00 Dec 6 23:59 >>> INPUT 1294 24 Dec 6 00:00 Dec 6 23:59 >>> AUTOBLACKLIST 122 2 Dec 6 00:20 Dec 6 16:28 >>> BLOCKLIST_DE 89 2 Dec 6 00:20 Dec 6 23:46 >>> >>> and sometimes none at all, but one one occasion it blocked over 8000 >>> packets. Again I'm aware this is for a home system, which is rather >>> different than from a Web server. >>> >>>>> If we do, I will have a look at the licensing stuff (DShield and Spamhaus do not >>>>> seem to be problematic, as they are hosted on 3rd party servers, too). >>>> >>>> One of them will be, sooner or later. And one is enough I suppose. >>> >>> DShield (https://dshield.org/api/#threatfeeds) and firehol >>> (http://iplists.firehol.org/) seem to host copies of most of the lists >>> as well. >>>> >>>> I do not really want to overthink this - we didn’t do this with clamav for example either. But it probably is a decision to be made by the user what they want to enable and we should not enable anything by default. So no data will be leaked as long as the user does not consent. >>>> >>>> -Michael >>>> >>>>> >>>>> Thanks, and best regards, >>>>> Peter Müller >> > > <Screenshot_2019-12-16_IP_Address_Blacklists.png>

3 19

[PATCH] oinkmaster: Do not skip threshold.conf
by Stefan Schantl 30 Jan '20

30 Jan '20

Fixes #12096. Signed-off-by: Stefan Schantl <stefan.schantl(a)ipfire.org> --- config/oinkmaster/oinkmaster.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config/oinkmaster/oinkmaster.conf b/config/oinkmaster/oinkmaster.conf index a04e32987..57c328139 100644 --- a/config/oinkmaster/oinkmaster.conf +++ b/config/oinkmaster/oinkmaster.conf @@ -222,7 +222,7 @@ skipfile deleted.rules # local thresholding/suppressing in some local file and still update # and use the official one though, in case important stuff is added to # it some day. We do update it by default, but it's your call. -# skipfile threshold.conf +skipfile threshold.conf # If you update from multiple URLs at the same time you may need to # ignore the sid-msg.map (and generate it yourself if you need one) as -- 2.25.0

1 0

Re: [PATCH] ovpnmain.cgi: Validate CCDNet name when renaming it.
by Michael Tremer 30 Jan '20

30 Jan '20

Okay. Can you ask the reporter to check your changes and confirm here on the list? > On 30 Jan 2020, at 12:48, Stefan Schantl <stefan.schantl(a)ipfire.org> wrote: > > Hello Michael, > > thanks for reviewing the patch. > > There is no need that the pool name is a FQDN, I mainly inserted the > same check when editing as when adding a new pool. > > Best regards, > > -Stefan >> Hi, >> >>> On 28 Jan 2020, at 10:51, Stefan Schantl <stefan.schantl(a)ipfire.org >>>> wrote: >>> >>> 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; >>> + } >>> + >> >> Why does the name of the pool need to be a FQDN? >> >>> &General::readhasharray("${General::swroot}/ovpn/ccd.conf", >>> \%ccdconfhash); >>> foreach my $key (keys %ccdconfhash) { >>> if ($ccdconfhash{$key}[0] eq $oldname) { >>> -- >>> 2.25.0 >>> >

1 0

[PATCH] vnstat: Add restart command.
by Stefan Schantl 30 Jan '20

30 Jan '20

From: Markus Untersee <m.untersee(a)buerliag.ch> Signed-off-by: Stefan Schantl <stefan.schantl(a)ipfire.org> --- src/initscripts/system/vnstat | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/src/initscripts/system/vnstat b/src/initscripts/system/vnstat index 518b2d7c6..363307013 100755 --- a/src/initscripts/system/vnstat +++ b/src/initscripts/system/vnstat @@ -21,7 +21,11 @@ case "$1" in stop) umount_ramdisk "${VNSTATLOG}" ;; - + restart) + ${0} stop + sleep 1 + ${0} start + ;; backup) # Backup all data if ramdisk is used if mountpoint "${RRDLOG}" &>/dev/null; then @@ -30,7 +34,7 @@ case "$1" in ;; *) - echo "Usage: $0 {start|stop|backup}" + echo "Usage: $0 {start|stop|restart|backup}" exit 1 ;; esac -- 2.25.0

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

Development January 2020