News items for tag security - Koos van den Hout

I noticed some really unused records in one zone which is now DNSSEC signed. For example I still had gplus.idefix.net to point at my Google+ page.

So I removed them and did the signing after increasing the serial number. Indeed the records that had no update kept their original signature and the records that where changed (such as the SOA because of the serial number) were signed with new signatures.

Today I was reminded of the first zone I signed with DNSSEC and did the check again with DNSViz. And I saw a lot of error messages. Some searching found that I let all the signatures expire (after the default time of 30 days).

Solution: re-sign the zone and have a careful look at when I need to sign the zones again. Officially just in time for expiry time of the signature (default 30 days) minus TTL of the record.

Obviously this process has to be automated. In the first go I decided to force new signatures after 21 days. But I tested some things later and decided to go for more regular checks of the ages of the signatures and refresh the signatures that are about to expire. This is usually reserved for 'big' zones with lots of resolvers querying them but I decided to implement this myself to avoid problems, and learn more about DNSSEC.

The magic signing command is now:

-zone-signedserial:
    named-checkzone $* $^
    ./SOA.pl $^
    dnssec-signzone -S -K /etc/bind/keys -g -a -r /dev/random -D -S -e +2592000 -i 604800 -j 86400 -o $* $^
    rndc reload $*
    touch $@

The expiry is set with -e at 30 days, the checkinterval with -i at 7 days and the jitter factor with -j at 1 day.

Now there is a special part in the Makefile to be called from cron on a regular basis. It won't produce any output when there is nothing to update.

agecheck:
    @for zone in $(SIGNEDZONES); do if [ `find $${zone}-signedserial -mtime +7 -print` ]; then touch $${zone}-zone ; $(MAKE) --no-print-directory $${zone}-signedserial; fi ;done

The Make variable SIGNEDZONES is filled with the zonenames of the zones that have to be kept DNSSEC signed. File structure for each forward zone is as listed in first zone with valid DNSSEC signatures.

So now almost all my domains are DNSSEC signed. A learning experience and a good level of security.

While looking at some network issues at home I noticed some weird traffic coming in from the outside: forged SYN traffic. Fast enough to trigger my iptables rules to stop being part of tcp syn attacks so all traffic gets dropped. Searching for a bit finds Hell of a Handshake: Abusing TCP forReflective Amplification DDoS Attacks - usenix which discusses this kind of attack.

At the moment it's about 1 or 2 packets per second. The traffic itself isn't notable on my connection and even without the firewall rules it still wouldn't impact my system. But do this with a lot of systems on the Internet running some tcp service and quite some traffic will go to the targeted IP address.

I guess someone doesn't like some Maltese Casino website. I don't like casino websites either because they promote addictive behaviour but I'm not about to use a DDoS.

A search for the top 10 tried usernames for ssh gives a nice list:

     52 admin
     23 pi
     19 test
      7 oracle
      6 support
      6 nagios
      5 user
      5 ubnt
      4 ftpuser
      3 virtualbookcase

I noticed some interesting traffic in my home network this morning, an attempt at finding IPv6 systems. Since IPv6 privacy enhancements are enabled on most systems this is exactly like finding a needle in a haystack.

I noticed an amount of outgoing icmpv6 traffic, and looking at the destination addresses and the type of traffic found lots of 'unreachable route' messages to a few Chinese IPv6 addresses. Searching for the netblock '240e:f7:4f01:c' finds more reports of portscanning activity.

10:14:27.761704 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.12980 > 2001:980:14ca:1:5054:ff:feae:17.902: Flags [S], cksum 0xd0a9 (correct), seq 3726392987, win 29200, options [mss 1460], length 0
10:14:28.278108 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.19933 > 2001:980:14ca:1:5054:ff:feae:8003.12587: Flags [S], cksum 0xe1cc (correct), seq 95632679, win 29200, options [mss 1460], length 0
10:14:29.219766 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.41487 > 2001:980:14ca:1:5054:ff:feae:fff2.902: Flags [S], cksum 0x3c31 (correct), seq 500442149, win 29200, options [mss 1460], length 0
10:14:33.637405 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.35832 > 2001:980:14ca:1:5054:ff:feae:15.902: Flags [S], cksum 0xa6ea (correct), seq 2324914849, win 29200, options [mss 1460], length 0
10:14:34.468975 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.12470 > 2001:980:14ca:42::ffe8.16992: Flags [S], cksum 0x5a72 (correct), seq 3249792078, win 29200, options [mss 1460], length 0
10:14:34.469038 IP6 (flowlabel 0x63971, hlim 64, next-header ICMPv6 (58) payload length: 72) 2001:980:14ca:61::13 > 240e:f7:4f01:c::3: [icmp6 sum ok] ICMP6, destination unreachable, unreachable route 2001:980:14ca:42::ffe8
10:14:35.230776 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.63145 > 2001:980:14ca:1:20d:56ff:fece:8006.19: Flags [S], cksum 0xb87b (correct), seq 4259180220, win 29200, options [mss 1460], length 0
10:14:35.952841 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.9056 > 2001:980:14ca:42::8013.16992: Flags [S], cksum 0xbb3b (correct), seq 2896438720, win 29200, options [mss 1460], length 0
10:14:35.952880 IP6 (flowlabel 0x63971, hlim 64, next-header ICMPv6 (58) payload length: 72) 2001:980:14ca:61::13 > 240e:f7:4f01:c::3: [icmp6 sum ok] ICMP6, destination unreachable, unreachable route 2001:980:14ca:42::8013

My previous test with DNSSEC zone signing showed a problem with entropy in virtual machines. Today I had time to reboot the home server running the virtual machines including the virtual machine with the nameserver, based on bind9.

Now I can create DNSSEC signatures for zonefiles at high speed (0.028 seconds) with enough entropy available. My first test is with camp-wireless.com which is a domainname for redirecting to Camp Wireless but since that variant was mentioned somewhere I had to generate the redirects to the right version.

The next step was to upload the DS records for the zone to my registrar and get them entered into the top level domain. This failed on the first attempt, the DS records have to be entered very carefully at the registrar.

I tested the result with dnsviz for camp-wireless.com and found an error in the first try: I updated the serial after signing the zone. So the soa record wasn't signed correctly anymore.

I updated my zonefile Makefile to do the steps in the right order:

-zone-signedserial:
        named-checkzone $* $^
        ./SOA.pl $^
        dnssec-signzone -S -K /etc/bind/keys -g -a -r /dev/random -D -S -o $* $^
        rndc reload $*
        touch $@

For the zone camp-wireless.com the original data is in camp-wireless.com-zone, the DNSSEC signatures in camp-wireless.com-zone.signed. And make will abort when one of the commands gives an error level, so it will for example stop completely when I make a typo in the zonefile which will make named-checkzone fail. The -D option creates a file to be used with $INCLUDE in the original zonefile. This does create a circular dependency: named-checkzone will fail when the -signedserial file isn't available on the first run. So the first run will have to be manually.

So now the zone is signed correctly. The next developments will be to find out how to monitor this extensively so I won't be surprised by problems and to redo the signing from time to time to make DNSSEC zone walking very hard.

And when I trust all of this I will implement it on other domain names that I manage.

Today some of the letsencrypt certificates were older than 60 days, so the renewal script started to kick in. Last year I completely automated the certificate renewal of letsencrypt certificates with dehydrated and wrote some scripts around the renewal process with hopefully enough error handling.

Today some of the error handling got tested, one renewal gave an error:

  + ERROR: An error occurred while sending post-request to https://acme-v02.api.letsencrypt.org/acme/new-order (Status 500)

And indeed the dehydrated script gave an error level, the resulting (empty!) .crt file wasn't copied and nothing happened. On the next run of the renewal script this certificate will still be older than 60 days and therefore the renewal will be tried again.

IPv6 is growing up: I saw an ssh attempt to an inside machine, reachable only via IPv6. The source was a Chinese IPv6 address which had not tried anything on any other public service.

Jul 30 18:39:02 ritchie sshd[27454]: Bad protocol version identification '\026\003\001' from 240e:d9:d800:200::212 port 44926

A month later I'm still seeing SMTP floods from 185.222.211.11 and adjacent addresses. I activated the sendmail-reject filter ruleset in fail2ban which keeps several addresses in that range blocked most of the time.

Given reports like 185.222.211.238 | Cloud Core LP | AbuseIPDB and 185.222.211.243 | Cloud Core LP | AbuseIPDB I'm not the only one seeing abuse from this range.

I was looking at the options for implementing DNSSEC on the domains I have, and started doing this on a domain name that is just used for web redirects, so I won't break anything serious when I make an error. And I am looking at monitoring options at the same time.

Looking for usable documentation I found DNSSEC signatures in BIND named - sidn.nl which shows and explains a lot of the options for doing this with bind9, including full automation. I want to take steps I understand, so I will start with careful minimal automation on a domain name that I can 'break'.

Following that documentation I created a key-signing key (KSK) and a zone-signing key (ZSK). I used the /etc/bind/keys directory which is the standard location.

The first dnssec-signzone action took 54 minutes. After waiting for a bit I started wondering what was happening and it turned out to be a problem with entropy: the signing uses a lot of data from /dev/random. I have the virtio-rng module loaded but the host wasn't making randomness available to the guest operating system. The host server does run randomsound to get more entropy since there is no hardware random number generator available.

Documentation on how to 'forward' randomness from the host to the client virtual machine: Random number generator device - Domain XML format

So I did some tests with a test virtual machine with a similar configuration. The results:

• Just software kernel rng in the virtual machine: 54 minutes.
• Offering virtio-rng randomness from the host from /dev/urandom running randomsound: less than 1 second.
• Offering virtio-rng randomness from the host from /dev/random running randomsound: 11 minutes 10 seconds.
• Offering virtio-rng randomness from the host from /dev/random running randomsound and haveged: less than 1 second.

Installing haveged which gathers entropy from hardware processes fixes the whole problem.

Now to implement the same settings for the virtual machine running the production nameserver and I'll be able to take the next step.

I noticed a really big load of probes for names under idefix.net, maybe looking for possible ways to attack systems. Source is a resolver at a VPS hoster (linode). I can find websites that will do such a search for me (some even hosted at linode) but in a quick search I can't get the same pattern in names.

30-Jun-2019 03:53:24.538 client @0x7f578c0c7230 45.33.59.87#11197 (sync.idefix.net): query: sync.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.539 client @0x7f578c0c7230 45.33.59.87#9151 (bugzilla.idefix.net): query: bugzilla.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.540 client @0x7f578c0c7230 45.33.59.87#64181 (mailgw.idefix.net): query: mailgw.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.540 client @0x7f578c0c7230 45.33.59.87#46518 (se.idefix.net): query: se.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.542 client @0x7f578c0c7230 45.33.59.87#31554 (tw.idefix.net): query: tw.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.544 client @0x7f578c0c7230 45.33.59.87#56050 (origin-www.idefix.net): query: origin-www.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.547 client @0x7f578c0c7230 45.33.59.87#24795 (bugzilla.idefix.net): query: bugzilla.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.558 client @0x7f578c0c7230 45.33.59.87#60127 (log.idefix.net): query: log.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.564 client @0x7f578c0c7230 45.33.59.87#16816 (reseller.idefix.net): query: reseller.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.564 client @0x7f578c0c7230 45.33.59.87#46743 (cdn3.idefix.net): query: cdn3.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.567 client @0x7f578c0c7230 45.33.59.87#15593 (books.idefix.net): query: books.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.568 client @0x7f578c0c7230 45.33.59.87#23918 (adv.idefix.net): query: adv.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.570 client @0x7f578c0c7230 45.33.59.87#24503 (srv1.idefix.net): query: srv1.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.570 client @0x7f578c0c7230 45.33.59.87#20759 (cacti.idefix.net): query: cacti.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.571 client @0x7f578c0c7230 45.33.59.87#62846 (developer.idefix.net): query: developer.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.571 client @0x7f578c0c7230 45.33.59.87#40156 (delta.idefix.net): query: delta.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.571 client @0x7f578c0c7230 45.33.59.87#42375 (logs.idefix.net): query: logs.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.571 client @0x7f578c0c7230 45.33.59.87#25727 (delta.idefix.net): query: delta.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.572 client @0x7f578c0c7230 45.33.59.87#19060 (wpad.idefix.net): query: wpad.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.572 client @0x7f578c0c7230 45.33.59.87#63258 (katalog.idefix.net): query: katalog.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.572 client @0x7f578c0c7230 45.33.59.87#35848 (ftp3.idefix.net): query: ftp3.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.574 client @0x7f578c0c7230 45.33.59.87#50079 (archives.idefix.net): query: archives.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.575 client @0x7f578c0c7230 45.33.59.87#18507 (pg.idefix.net): query: pg.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.577 client @0x7f578c0c7230 45.33.59.87#62479 (manager.idefix.net): query: manager.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.577 client @0x7f578c0c7230 45.33.59.87#41830 (wwwtest.idefix.net): query: wwwtest.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.578 client @0x7f578c0c7230 45.33.59.87#14914 (ocs.idefix.net): query: ocs.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.581 client @0x7f578c0c7230 45.33.59.87#25754 (auction.idefix.net): query: auction.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.582 client @0x7f578c0c7230 45.33.59.87#42057 (students.idefix.net): query: students.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.729 client @0x7f578c0c7230 45.33.59.87#63617 (gosper.idefix.net): query: gosper.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.866 client @0x7f578c4feb30 45.33.59.87#57706 (books.idefix.net): query: books.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.870 client @0x7f578c0d59c0 45.33.59.87#57714 (delta.idefix.net): query: delta.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.872 client @0x7f578c51d780 45.33.59.87#57718 (delta.idefix.net): query: delta.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.874 client @0x7f578c0d59c0 45.33.59.87#57722 (archives.idefix.net): query: archives.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.874 client @0x7f578c4feb30 45.33.59.87#57726 (wwwtest.idefix.net): query: wwwtest.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.875 client @0x7f578c52bda0 45.33.59.87#57728 (auction.idefix.net): query: auction.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.876 client @0x7f578c51d780 45.33.59.87#57708 (katalog.idefix.net): query: katalog.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.879 client @0x7f578c0d59c0 45.33.59.87#57712 (srv1.idefix.net): query: srv1.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:24.943 client @0x7f578c0c7230 45.33.59.87#50168 (wpad.idefix.net): query: wpad.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.945 client @0x7f578c0c7230 45.33.59.87#59186 (cacti.idefix.net): query: cacti.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.947 client @0x7f578c0c7230 45.33.59.87#30509 (ftp3.idefix.net): query: ftp3.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.948 client @0x7f578c0c7230 45.33.59.87#25611 (manager.idefix.net): query: manager.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.948 client @0x7f578c0c7230 45.33.59.87#53201 (adv.idefix.net): query: adv.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.950 client @0x7f578c0c7230 45.33.59.87#25331 (students.idefix.net): query: students.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.954 client @0x7f578c0c7230 45.33.59.87#44043 (logs.idefix.net): query: logs.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:24.954 client @0x7f578c0c7230 45.33.59.87#9075 (ocs.idefix.net): query: ocs.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.236 client @0x7f578c4feb30 45.33.59.87#57748 (wpad.idefix.net): query: wpad.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.245 client @0x7f578c52bda0 45.33.59.87#57752 (adv.idefix.net): query: adv.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.250 client @0x7f578c51d780 45.33.59.87#57750 (ftp3.idefix.net): query: ftp3.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.257 client @0x7f578c0c7230 45.33.59.87#46992 (katalog.idefix.net): query: katalog.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.259 client @0x7f578c0d59c0 45.33.59.87#57754 (logs.idefix.net): query: logs.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.263 client @0x7f578c0c7230 45.33.59.87#50662 (ns9.idefix.net): query: ns9.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.264 client @0x7f578c0c7230 45.33.59.87#23392 (eu.idefix.net): query: eu.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.271 client @0x7f578c0c7230 45.33.59.87#62305 (app2.idefix.net): query: app2.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.293 client @0x7f578c0c7230 45.33.48.143#45998 (sam.idefix.net): query: sam.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.293 client @0x7f578c0c7230 45.33.59.87#43255 (banners.idefix.net): query: banners.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.299 client @0x7f578c0c7230 45.33.59.87#29869 (click.idefix.net): query: click.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.302 client @0x7f578c0c7230 45.33.59.87#36595 (customer.idefix.net): query: customer.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.322 client @0x7f578c0c7230 45.33.59.87#6272 (cgi.idefix.net): query: cgi.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.327 client @0x7f578c0c7230 45.33.59.87#23561 (awstats.idefix.net): query: awstats.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.331 client @0x7f578c0c7230 45.33.59.87#58477 (wwwtest.idefix.net): query: wwwtest.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.334 client @0x7f578c0c7230 45.33.59.87#12998 (cgi.idefix.net): query: cgi.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.335 client @0x7f578c0c7230 45.33.59.87#41654 (meeting.idefix.net): query: meeting.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.335 client @0x7f578c0c7230 45.33.59.87#36692 (hd.idefix.net): query: hd.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.337 client @0x7f578c0c7230 45.33.59.87#52048 (webapps.idefix.net): query: webapps.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.471 client @0x7f578c0c7230 45.33.59.87#11817 (ns9.idefix.net): query: ns9.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.479 client @0x7f578c0c7230 45.33.59.87#40723 (webgreenblatt.idefix.net): query: webgreenblatt.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.481 client @0x7f578c0c7230 45.33.59.87#57833 (app2.idefix.net): query: app2.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.499 client @0x7f578c0c7230 45.33.59.87#26285 (click.idefix.net): query: click.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.525 client @0x7f578c0c7230 45.33.59.87#51562 (cgi.idefix.net): query: cgi.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.533 client @0x7f578c0c7230 45.33.59.87#32101 (wwwtest.idefix.net): query: wwwtest.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.534 client @0x7f578c0c7230 45.33.59.87#36210 (meeting.idefix.net): query: meeting.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.543 client @0x7f578c0c7230 45.33.59.87#57693 (webapps.idefix.net): query: webapps.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.568 client @0x7f578c53a3c0 45.33.59.87#57768 (katalog.idefix.net): query: katalog.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.569 client @0x7f578c565900 45.33.59.87#57772 (eu.idefix.net): query: eu.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.598 client @0x7f578c557170 45.33.59.87#57776 (banners.idefix.net): query: banners.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.617 client @0x7f578c590fb0 45.33.59.87#57780 (customer.idefix.net): query: customer.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.620 client @0x7f578c52bda0 45.33.59.87#57782 (awstats.idefix.net): query: awstats.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.630 client @0x7f578c0d59c0 45.33.59.87#57790 (hd.idefix.net): query: hd.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.637 client @0x7f578c5489e0 45.33.59.87#57788 (cgi.idefix.net): query: cgi.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.664 client @0x7f578c0c7230 45.33.59.87#35680 (app2.idefix.net): query: app2.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.765 client @0x7f578c582820 45.33.59.87#57800 (ns9.idefix.net): query: ns9.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.786 client @0x7f578c0c7230 45.33.59.87#59047 (sk.idefix.net): query: sk.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.805 client @0x7f578c565900 45.33.59.87#57802 (click.idefix.net): query: click.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.825 client @0x7f578c590fb0 45.33.59.87#57804 (wwwtest.idefix.net): query: wwwtest.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.840 client @0x7f578c0c7230 45.33.59.87#6873 (app2.idefix.net): query: app2.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.843 client @0x7f578c0c7230 45.33.49.87#39819 (img4.idefix.net): query: img4.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.848 client @0x7f578c0c7230 45.33.49.87#35699 (registration.idefix.net): query: registration.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:25.856 client @0x7f578c0d59c0 45.33.59.87#57806 (webapps.idefix.net): query: webapps.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:25.942 client @0x7f578c0c7230 45.33.49.87#49819 (registration.idefix.net): query: registration.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:26.081 client @0x7f578c51d780 45.33.59.87#57816 (sk.idefix.net): query: sk.idefix.net IN AAAA -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:26.288 client @0x7f578c0c7230 45.33.59.87#49749 (meeting.idefix.net): query: meeting.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:26.309 client @0x7f578c0c7230 45.33.59.87#57344 (ocs.idefix.net): query: ocs.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:26.399 client @0x7f578c0c7230 45.33.59.87#44649 (develop.idefix.net): query: develop.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:26.583 client @0x7f578c50d150 45.33.59.87#57826 (meeting.idefix.net): query: meeting.idefix.net IN A -E(0)TDC (194.145.201.42)
30-Jun-2019 03:53:26.634 client @0x7f578c0c7230 45.33.49.87#9259 (ares.idefix.net): query: ares.idefix.net IN AAAA -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:26.662 client @0x7f578c0c7230 45.33.59.87#9440 (ocs.idefix.net): query: ocs.idefix.net IN A -E(0)DC (194.145.201.42)
30-Jun-2019 03:53:26.694 client @0x7f578c53a3c0 45.33.59.87#57830 (develop.idefix.net): query: develop.idefix.net IN A -E(0)TDC (194.145.201.42)

Checking how fail2ban was doing on a wordpress site I noticed the following error in the log:

46.105.99.163 - - [18/Jun/2019:09:03:46 +0200] "GET /wp-content/plugins/ungallery/source_vuln.php?pic=../../../../../wp-config.php HTTP/1.1" 404 15933 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0"

which is never going to work as an exploit. A full explanation in Hackers Will Try To Exploit Vulnerabilities in WordPress Plugins in Ways That Will Never Succeed - Plugin Vulnerabilities but this entire attempt is based on just the description of a vulnerability and can never ever have succeeded, not even on a system with the vulnerable version of the ungallery plugin.

Noticed in the recent logs, lots of variations on:

Jun  6 19:15:41 gosper sm-mta[22475]: x56HFc06022475: <mail@some.domain>... No such user in domain 
Jun  6 19:15:41 gosper sm-mta[22475]: x56HFc06022475: <support@some.domain>... No such user in domain 
Jun  6 19:15:41 gosper sm-mta[22475]: x56HFc06022475: <reply@some.domain>... No such user in domain 
Jun  6 19:15:41 gosper sm-mta[22475]: x56HFc06022475: srv-eml.info [185.222.211.11]: Possible SMTP RCPT flood, throttling.
Jun  6 19:15:41 gosper sm-mta[22466]: x56HFCbH022466: <financeiro@some.domain>... No such user in domain 
Jun  6 19:15:42 gosper sm-mta[22473]: x56HFVoi022473: <biuro@some.domain>... No such user in domain 
Jun  6 19:15:42 gosper sm-mta[22468]: x56HFItg022468: <michael@some.domain>... No such user in domain 
Jun  6 19:15:42 gosper sm-mta[22471]: x56HFPIC022471: <chris@some.domain>... No such user in domain 
Jun  6 19:16:51 gosper sm-mta[22466]: x56HFCbH022466: lost input channel from srv-eml.info [185.222.211.11] to MTA-v6 after rcpt
Jun  6 19:17:16 gosper sm-mta[22475]: x56HFc06022475: <jobs@some.domain>... No such user in domain 
Jun  6 19:17:17 gosper sm-mta[22475]: x56HFc06022475: <wh5gkoxp5wqk@some.domain>... No such user in domain 
Jun  6 19:17:18 gosper sm-mta[22475]: x56HFc06022475: lost input channel from srv-eml.info [185.222.211.11] to MTA-v6 after rcpt
Jun  6 19:17:18 gosper sm-mta[22475]: x56HFc06022475: from=<20tv13b4bu0h2107@europcar.ua>, size=0, class=0, nrcpts=1, proto=ESMTP, daemon=MTA-v6, relay=srv-eml.info [185.222.211.11]

All from the same IP, trying a lot of addresses (and failing), with a retry later trying all those addresses again.

Just seen in an e-mail with a virus, looking like it's something from a bank:

Security tips

1. Install virus detection software and personal firewall on your computer. This software needs to be updated regularly to ensure you have the latest protection.
2. To prevent viruses or other unwanted problems, do not open attachments from unknown or non-trustworthy sources.
3. If you discover any unusual activity, please contact the remitter of this payment as soon as possible. 

But the attachment has malware.

While making a lot of my websites available via HTTPS I started wondering about enabling Server Name Indication (SNI) because the list of hostnames in the one certificate (subjectAltName parameter) keeps growing and they aren't all related.

So on a test system with haproxy I created two separate private keys, two separate certificate signing requests and requested two separate certificates. One for the variants of camp-wireless.org and one for most of the idefix.net names. The whole requesting procedure happened on the system where my automated renewal and deployment of LetsEncrypt certificates with dehydrated happens so the request went fine. For the configuration of haproxy I was following HAProxy SNI where 'terminating SSL on the haproxy with SNI' gets a short mention.

So I implemented the configuration as shown in that document and got greeted with an error:

haproxy[ALERT] 123/155523 (3435) : parsing [/etc/haproxy/haproxy.cfg:86] : 'bind :::443' unknown keyword '/etc/haproxy/ssl/webserver-idefix-main.pem'.

And found out that the crt keyword has to be repeated.

This is why I like having a test environment for things like this. Making errors in the certificate configuration on the 'production' server will give visitors scary and/or incomprehensible errors.

So the right configuration for my test is now:

frontend https-in
    bind :::443 v4v6 ssl crt /etc/haproxy/ssl/webserver-campwireless.pem crt /etc/haproxy/ssl/webserver-idefix-main.pem

And testing it shows the different certificates in use when I use the -servername parameter for openssl s_client to test things.

$ openssl s_client -connect testrouter.idefix.net:443 -servername idefix.net -showcerts -verify 3
..
Server certificate
subject=/CN=idefix.net
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
..
Verification: OK
$ openssl s_client -connect testrouter.idefix.net:443 -servername camp-wireless.org -showcerts -verify 3
..
Server certificate
subject=/CN=www.camp-wireless.org
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
..
Verification: OK

The certificates are quite separate. Generating the certificate signing requests with a separate private key for each request works fine.

So if I upgrade my certificate management to renew, transport, test and install multiple certificate for the main webserver it would work.

After upgrading to the new homeserver my old setup to allow two passwords for IMAPS logins so I can use a separate password for IMAPS access for those devices that insist on saving a password without asking.

I have the following PAM libraries:

ii  libpam-modules 1.1.8-3.6    amd64        Pluggable Authentication Modules

And I debugged the problem using the pamtester program which makes debugging this problem a lot easier than constantly changing the configuration and restarting the imap server.

The relevant configuration now is:

# PAM configuration file for Courier IMAP daemon

#@include common-auth
# here are the per-package modules (the "Primary" block)
auth    required    pam_succeed_if.so quiet user ingroup users
#auth   [success=1 default=ignore]      pam_unix.so nullok_secure
auth    sufficient      pam_unix.so nullok_secure
auth    sufficient  pam_userdb.so db=/etc/courier/extrausers crypt=crypt use_first_pass
# here's the fallback if no module succeeds
auth    requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth    required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config
@include common-account
@include common-password
@include common-session

And now both my unix login password and the extra password are accepted.

I noticed a lot of entries in my mail logging about aborted smtp transactions

Mar 22 21:04:04 gosper sm-mta[30180]: x2MK437r030180: [193.169.254.68] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v6
Mar 22 21:04:58 gosper sm-mta[30229]: x2MK4vv0030229: [185.234.217.222] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v6
Mar 22 21:05:25 gosper sm-mta[30307]: x2MK5Oas030307: [193.169.254.68] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v6
Mar 22 21:06:01 gosper sm-mta[30328]: x2MK5xAc030328: [185.234.217.222] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v6
Mar 22 21:06:02 gosper sm-mta[30331]: x2MK5xg5030331: [185.222.209.209] did not issue MAIL/EXPN/VRFY/ETRN during connection to MSP-v6

And I wondered what was going on, until I did a capture of the session and had a look:

    1   0.000000 185.234.217.222 → 82.95.196.202 TCP 68 55448 → 25 [SYN, ECN, CWR] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
    2   0.000314 82.95.196.202 → 185.234.217.222 TCP 68 25 → 55448 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=128
    3   0.034751 185.234.217.222 → 82.95.196.202 TCP 56 55448 → 25 [ACK] Seq=1 Ack=1 Win=65536 Len=0
    4   6.038967 82.95.196.202 → 185.234.217.222 SMTP 395 S: 220-gosper.idefix.net ESMTP Sendmail 8.15.2/8.15.2/Debian-8; Fri, 22 Mar 2019 21:00:55 +0100; (No UCE/UBE) | 220-   This is a private SMTP server. | 220-   The use of this or any related system for the transmission of | 220-   Unsollicited Bulk E-mail (UBE) is prohibited. | 220 logging access from: [185.234.217.222](FAIL)-[185.234.217.222]
    5   6.072501 185.234.217.222 → 82.95.196.202 SMTP 76 C: EHLO 82.95.196.202
    6   6.072915 82.95.196.202 → 185.234.217.222 TCP 56 25 → 55448 [ACK] Seq=340 Ack=21 Win=29312 Len=0
    7   6.073011 82.95.196.202 → 185.234.217.222 SMTP 267 S: 250-gosper.idefix.net Hello [185.234.217.222], pleased to meet you | 250-ENHANCEDSTATUSCODES | 250-PIPELINING | 250-EXPN | 250-VERB | 250-8BITMIME | 250-SIZE | 250-DSN | 250-ETRN | 250-STARTTLS | 250-DELIVERBY | 250 HELP
    8   6.106154 185.234.217.222 → 82.95.196.202 SMTP 68 C: AUTH LOGIN
    9   6.106585 82.95.196.202 → 185.234.217.222 SMTP 86 S: 503 5.3.3 AUTH not available
   10   6.141445 185.234.217.222 → 82.95.196.202 TCP 56 55448 → 25 [FIN, ACK] Seq=33 Ack=581 Win=65024 Len=0
   11   6.141775 82.95.196.202 → 185.234.217.222 TCP 56 25 → 55448 [FIN, ACK] Seq=581 Ack=34 Win=29312 Len=0
   12   6.174430 185.234.217.222 → 82.95.196.202 TCP 56 55448 → 25 [ACK] Seq=34 Ack=582 Win=65024 Len=0

Each session starts ESMTP and even with the ESMTP reply not listing AUTH the next command is 'AUTH LOGIN' for authenticated smtp, and as soon as my server denies offering this the session gets aborted. This does mean no failed authentication attempt is logged which would trigger fail2ban.

This does look like a bit of a distributed attack, but without the network remembering that the attack is not going to work in this way and therefore trying it again and again.

Update: IPs active in this scanning attack sofar: 185.234.217.222 193.169.254.68 185.234.219.56 37.49.225.232 185.222.209.202 141.98.80.15 114.207.112.188 185.222.209.209 23.227.207.215 185.211.245.170 141.98.80.17 89.248.171.176 185.211.245.198 164.132.45.117 37.49.225.224 119.176.218.216 103.114.104.175 37.49.225.47 103.207.37.40 37.49.227.49 185.234.219.57

Update 2019-03-24: I noticed the incorrect EHLO above and looked at options for HELO/EHLO checking in sendmail. Searching did not show a lot of options, trying with the $&s delayed s macro did not fire on the given HELO/EHLO. So I kept searching and found the latest sendmail administration guide ('Bat book') with FEATURE(block_bad_helo). I activated this feature to see if it stops some of this traffic.

An interesting bit of news: SSH client gets patched after RSA key exchange memory vuln spotted.

The fixes implemented on PuTTY over the weekend include new features plugging a plethora of vulns in the Telnet and SSH client, most of which were uncovered as part of an EU-sponsored HackerOne bug bounty.

Get your updated putty at the PuTTY download page.

Update: Interesting visual change in putty: informational lines from the client are now prefixed by a putty logo. This could make it harder to mislead the user in certain attacks.

According to “FINAL WARNING” email – have they really hacked your webcam? - Naked Security there is a big flood the last day(s) of "Sextortion" scam mails going around. Don't fall for these. It's all fake.

A new level of stupid in the "I have you on video watching porn" extortion scams: the whole message embedded as an image, including the instructions to carefully cut and paste the bitcoin wallet address.

Links: Report history for 12Vso1cRX7zQovZG4wH7RAz2HqtdW1Lvek - Bitcoin Abuse Database, Bitcoin Address 12Vso1cRX7zQovZG4wH7RAz2HqtdW1Lvek.

Before, before, before.