2020-04-29 Seeing when it's time to walk to the laserjet printer
I have an aged laserjet 4100 DTN printer at home and it sometimes takes a while to print something. The logs from cups will state that it has been sent to the printer but the printer will still show processing. Solution: ask the printer for the active pagecounter. This will be updated after the page has really been output, so it will only change when the printer is done with the page.$ snmpget -v1 -c internal laserjet 184.108.40.206.220.127.116.11.18.104.22.168.1 iso.22.214.171.124.126.96.36.199.188.8.131.52 = Counter32: 738042
2020-04-04 Found the probable reason of the DNSSEC subzones problem
I think I found the most probable reason of the earlier problem with DNSSEC signed subzones. I was trying this with a domain for which I don't have control over one of the secondary nameservers. In one of my showerthought moments I decided to try another domain where I have that full control (just less nameservers) and was able to make it all validate correctly after some tries. Forgetting one or more of all the steps needed to correctly create a domain with DNSSEC and getting the delegation right will give errors. So I guess running a nameserver with all DNSSEC options disabled hinders validation.
2020-03-08 Updating the Fritz!box 7360v1: still no PPPoE passthrough
A while ago I noticed a mention of new firmware for the Fritz!box 7360v1. As I want a separate PPPoE process to have full control of my Internet connection I hoped the PPPoE passthrough option would become available, since this would be a firmware version later than 6.30, but no. At least the upgrade went fine without having to use the recovery options. So the 'in case of emergency' settings have been kept forwarding the necessary ports via IPv4.
2020-02-17 Tweaking the SSL cipher settings for 2020
A few days ago I changed the configuration of haproxy to stop accepting TLSv1.0 and TLSv1.1. With the upcoming deprecation of TLSv1.0 and TLSv1.1 this seemed the right SSL configuration. Today I remembered there is one directly reachable Apache server, so I had a look at the settings there and checked the results with the Qualys SSL Labs SSL Server test where I noticed some ciphers listed as 'weak'. And seeing different results between my haproxy and apache servers, which I did not expect as I used the same settings for SSLCipherSuite in Apache and ssl-default-bind-ciphers in haproxy. The last issue was caused by the fact that Apache2.4.25 in Devuan ascii uses libssl 1.0.2 and haproxy 1.7.5 uses libssl 1.1.0. I'm not sure that's an ideal configuration but it's what I work with. With the output of openssl ciphers -v I get a list of cipher names. But this is with libssl1.1.0 so the output lists ciphers that Apache doesn't have access to (yet). The good part is that Apache ignores ciphers that aren't available, so the net result is a running and working configuration. The current result is for Apache 2.4.25:SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 SSLHonorCipherOrder on SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256And for haproxy 1.7.5:ssl-default-bind-options force-tlsv12 no-tls-tickets ssl-default-bind-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256The fun part is that I can test the SSL negotiation with sslscan locally but sslscan is linked against openssl 1.0.2 so it misses some of the newer options. And I also test with the Qualys SSL Labs ssl test but that takes a while.
The too long; didn't read version of finding the right configuration optionsAnd later I found I could have saved a lot of time researching options using the Mozilla SSL Configuration Generator. I don't completely agree with the suggestions there because I want to generate my own dhparams. Using 'well-known Diffie-Hellman paramaters' has security risks. But otherwise all the suggestions for ciphers are very usable and save me a lot of time.
2020-02-10 Getting with the times and limiting the webserver to TLSv1.2
In 2020 the support for TLSv1.0 and TLSv1.1 will end so the famous qualys SSL test is giving capped grades. I decided to get with the times and limit my outside web ports to TLSv1.2 so now I am back at an A+ grade. Eventually this will start to cause problems as Devuan stable doesn't have an openssl with TLSv1.3 support yet.
2020-01-30 Backup to a remote webdav server, first success!
I found a completely different option for transferring files from linux to a remote webdav filesystem: fusedav. Mounting the remote 'cloud' disk with fusedav and synchronizing files with rsync is starting to work. I decided to split my backups into two categories: first there are file collections that usually only grow, like digital camera pictures and audio project files. This takes the most diskspace and doesn't really need versioning. The second category is configuration files, homedirs, mail and other things that change and where I may need an older version. This is where backups based on amanda work better. I mount the filesystem with:Read the rest of Backup to a remote webdav server, first success!$ fusedav -u koos -p topsecret https://webdav.cloudprovider/remote.php/webdav/ /home/koos/webdavmount/And the rsync command to backup to this mount:$ rsync -av --progress --bwlimit=512K --size-only --timeout=30 /camera/2003/ webdavmount/camera/2003/This looks scriptable so it can run on a regular basis with just a status update to me. Update:
Reliability is still an issue. I added the --timeout=30 parameter to make rsync abort when the bytes stop flowing.
2019-12-24 First tries with DNSSEC on subzones: no success
I tried adding subzones with DNSSEC by adding the DS record to the parent zone, but in both tries I got errors from DNSViz. Different errors even: in one case the signature on the DS record was seen as invalid and in another case there was no signature at all. The errors are reproducable, even after waiting for caches to empty.
2019-12-19 Removing an RRTYPE for a DNS name causes an expired RRSIG for that record
I kept seeing warnings about an expired signature when running named-checkzone or dnssec-signzone and it took some searching before I found the reason. Recently I removed the records with type SPF from my zones since the recommended approach is to use TXT records with SPF data. The RRSIG records for the SPF records were left in the signed zonefile, but not updated so they expired and started to give warnings. The SPF records were for names that had other data too which seems to trigger this. Removing a record completely (no RRTYPEs left for the name) removes all signatures. The things in DNSSEC I haven't tested yet are a signed subzone, a ZSK rollover and a KSK rollover. Those will eventually happen too.
2019-12-14 Moved the first domain registration to TransIP
The machine ns3.idefix.net moved so I had to do the whole update dance with the glue records again. Since the IPv6 glue records 'vanished' when I added DNSSEC to idefix.net I decided to move idefix.net to a different registrar where IPv6 glue records and DNSSEC are normal and don't require an extra support call. Since I have an account with TransIP anyway for the stack storage service I just had to add (and pay for) domain services. Interesting bit is that TransIP says I have to pay again next year. According to the registry the domain is registered until 11 august 2024 at the moment. Adding DNSSEC gave problems at first, the format they expect is from the public part of the key signing key, which is a different format from the dsset-idefix.net. file which gets generated by dnssec-signzone. After some tries and searching I found the right source and format. The error message was about the Key Tag which was confusing as that is a number where there isn't much to go wrong.
2019-12-12 Adding the first TLSA records for secured servicesItems with tag homeserver before 2019-12-12
Now I have DNSSEC running ok on my domains I can start looking at security innovations that rely on DNSSEC. The first one is DANE for the mailserver, in which the public key signature is published in DNS record secured with DNSSEC to give a separate path to verify the public key during the SMTP session. The public key of the mailserver is also signed by LetsEncrypt as described in Automating Let's Encrypt certificates further and Automating Let's Encrypt certificates with DNS-01 protocol so there are two completely independent paths to verify the identity of the mail server. To find the public key of the mailserver for a given domain:$ dig +short idefix.net mx 10 postbox.idefix.net. $ dig +short _25._tcp.postbox.idefix.net tlsa 3 1 2 2B55764A99A47AEC5B66D8EB4E741F2646BF6352CABC9BE3F37D2F42 0BD7EF56B5BE3058E7B10964BA963777364443057E45599E07A82375 7A812F1A7014356AI found the tlsa tool from package hash-slinger by Paul Wouters to create these records. This can be both from the protocol which has certain risks (if that connection is intercepted) or from the public key file. Or via the web tool Generate TLSA Record by Shumon Huque. TLSA records are generically linked to a TCP or UDP port. The next step will probably be to start adding records for other public services with TLS like https. There was a time that some people were convinced DANE was going to replace certificate authorities for https, but at this moment it is very limited. I have added TLSA records for https (tcp/443) for camp-wireless.com and www.camp-wireless.com for now and I'm testing with these. For now one of my favourite checkers isn't convinced. This does increase the chances for things to go wrong. With the tlsa program it is possible to verify records too, so I can use this to verify TLSA records.$ tlsa --verify -6 --starttls smtp --port 25 postbox.idefix.net SUCCESS (Usage 3 [DANE-EE]): Certificate offered by the server matches the TLSA record (2001:980:14ca:1::23)Although this certificate is a valid LetsEncrypt certificate, DNS-based Authentication of Named Entities (DANE) does not support usage 1 (check the certificate public key and verify certificate chain to a known root) for SMTP with STARTTLS, so it is usage 3 (just check the certificate public key). The tlsa program does not check this specifically, but the web checker at DANE TLSA Server checker found the issue, so I corrected that. I use selector 1 to just check the public key because the complete certificate changes with every LetsEncrypt renewal. My choice for mtype 2 (sha512) is just a wish for a strong hashing algorithm. This also makes the link between service configuration and DNS contents a lot stronger. Maybe this needs secure automated updates.