News items for tag security - Koos van den Hout

I learned about changes in GPG needing some updates to private keys so I loaded the private key for 0x5BA9368BE6F334E4 in a backup keyring and tried to find out what needs to be done. The explanation at Fixing old SHA1-infested OpenPGP keys seems to have the important parts.

Make sure the preferences are set correctly (no SHA1) and do a 'clear' on the key. I took the chance to change the expiry date to something a bit more in the future, set the e-mail address that I now use as primary and updated the weblink to my homepage to https://idefix.net/.

I also updated the details on PGP - Koos van den Hout so these can be verified.

After the recent work on updating the TLS settings for the webservers at home there was one element missing: TLSv1.3 support.

This needed an upgrade of openssl and the 'easy' way to get there was a full upgrade of the server running the external facing proxy. So I took that step yesterday evening. Made a snapshot first and started upgrading devuan ascii to beowulf.

After the update a lot of things were broken: I defined a non-standard location for bind9 logging and AppArmor disagreed. Without a working nameserver a lot of stuff breaks internally! So after managing to get on the upgraded system with console I changed the AppArmor rules to allow it. After that things started again.

For the next time I manage to break the resolving nameserver: I should remember that avahi/multicast dns works on most systems even when DNS resolving fails. I checked and I can use .local names to get to the right equipment.

After checking how everything is running for about a day I threw out the old snapshot.

Looking at the newest graphs I created with grafana of system statistics I noticed the available entropy was still getting dangerously low from time to time on the system that runs the home server. For some reason this system has no available hardware random number generator. Even after the earlier changes to add more sources of randomness it was sometimes dropping low, especially during dnssec signing operations.

This does mean that the encryption processes for TLS in the webservers may also get delayed. Which is really not what I want.

Time to update settings on randomsound and haveged: I want a minimum of 2048 bits of available entropy. Sofar, this seems to have the desired effect.

I'm currently following the course The Best TLS and PKI Training Course in the World and learning even more about the workings of encryption, TLS and certificates.

One of the things I learned is to balance security with performance. And I directly used this new insight on my own webservers. The connection which brought you this page from https://idefix.net/ is still encrypted but I saved a few milliseconds on the encrypted setup by switching from a big (4096 bit) RSA private key to a 384 bit ECDSA key which are comparable in cryptographic strength. But the calculations with the ECDSA key are less CPU intense. And yes, I have statistics on page loading times before and after the changeover of the key.

It was a good moment to change private keys anyway, the old keys were more than a year old.

This is one of those areas where I like having my knowledge hands-on. Actually understanding what is happening and why.

Omdat met redelijk goed Nederlands deze pogingen tot chantage zich ook specifiek tot het nederlandse taalgebied richten zal ik er ook maar in het nederlands over schrijven:

In diverse varianten al langsgekomen, de 'ik heb al je persoonsgegevens en seksbeelden van je' mail waarin een betaling in bitcoin nodig zou zijn om hier van af te komen. Hoe het beeld tussen de porno-website en de webcam is ingedeeld is in deze varianten niet meer precies terug te lezen, dat detail bleef bij eerdere varianten wel steeds terugkomen, dus er zit nog iets verandering in.

Het bedrag is omhoog gegaan, er is nu 1450 euro in bitcoin nodig en dat moet naar bitcoin rekening 133MphKowvCC1PDyfZVF9L76mQvxTtRY93.

Op dit moment is daar nog geen geld op binnengekomen, maar zo te zien al diverse meldingen over deze chantage.

Goede uitleg Ik word per mail gechanteerd - Fraudehelpdesk.

Update 2020-02-23: Twee nieuwe mails met dezelfde tekst maar met bitcoin rekening 1NcyvDdyuJ5tF9MTnk1LqUULaZHurt3gRF. Of het dezelfde crimineel is of dat er iemand de tekst wel handig vond is de vraag.

I recently almost had an expired certificate for a public service because I did some fiddling with the file and ended up with a file modified time which had no relationship to the certificate request time.

Time to use the -checkend option I noticed in openssl x509 to test the actual certificates for upcoming expiry. So I redid the cronjob around dehydrated to do just that and had a cleanup. A candidate list of certificates to renew is created from certificates that are about to expire, certificates that have a changed certificate signing request and certificates for which there is only a signing request. That list is sorted and deduplicated and fed to calls to dehydrated.

It's now one script for both certificates that are renewed via the http-01 method and for certificates that are renewed via dns-01. By now both methods work fine for me, it depends on the use of the name which is fitting.

Buttcoins have had some interesting price changes recently and while I normally only associate bitcoin with sextortion scams I'm now receiving spam about 'getting rich from bitcoin'. Most notably from the mails:

Don't like these emails? Unsubscribe. a Company or Organization Name | Latvia

Wahnsinnig reich werden Wahnsinnig reich werden Don't like these emails? Unsubscribe. a Organization Name | France Unsubscribe {recipient's email} Update Profile | About our service provider

I guess they are abusing some cheap spam provider (probably known to themselves as "e-mail marketing company").

The bitcoin sextortion scams continue in this year. The one I got today tries to avoid spam filters that trigger on bitcoin addresses:

Ok! So.. to get some coins go and search on Google for "Buy BIT C0lN instantly"
and send to this address:

Address: 1 L 2 U a v M T r h p C X W n 9 L v q h C q R S v x Y z f Q s B w 4
Amount: 0.027

The address 1L2UavMTrhpCXWn9LvqhCqRSvxYzfQsBw4 is valid according to 1L2UavMTrhpCXWn9LvqhCqRSvxYzfQsBw4 - blockchain explorer but not yet known at BitcoinAbuse.

I hope some day one of these scammers is brought to justice.

Update 2021-01-10: More of the same, with reasonably good Dutch language writing. New bitcoin addresses: 1Emh6CsbF4eo425ph3sSCNZ2aGCWerRB7w 1JakpfFpX4HFyiuv7WKviV5xAanMwknArV 1Emh6CsbF4eo425ph3sSCNZ2aGCWerRB7w and the criminal wants 1500 US Dollar in buttcoins to not publish the videos.

Update 2021-01-13: More good Dutch although I am sure it's a translation because of the familiairity in the writing style. Bitcoin address Eu8sHWG2Uzvd1ukxumae5ctfSNWWtsFkS. The amount has changed to 1400 Euro in buttcoins.

I also note bitcoin address 1JakpfFpX4HFyiuv7WKviV5xAanMwknArV has received 2 incoming transactions of somewhat above 1500 dollars so it seems this crime pays.

Interesting find in the logs: SMTP authentication brute force.

Dec 20 20:57:22 gosper saslauthd[1616]:                 : auth failure: [user=iknidcam1974] [service=smtp] [realm=camp-wireless.org] [mech=pam] [reason=PAM auth error]
Dec 20 20:57:26 gosper saslauthd[1613]:                 : auth failure: [user=iknidcam1974] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]
Dec 20 21:54:42 gosper saslauthd[1615]:                 : auth failure: [user=iknikieh] [service=smtp] [realm=camp-wireless.org] [mech=pam] [reason=PAM auth error]
Dec 20 21:54:47 gosper saslauthd[1617]:                 : auth failure: [user=iknikieh] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]
Dec 20 21:57:14 gosper saslauthd[1614]:                 : auth failure: [user=iknikieh] [service=smtp] [realm=camp-wireless.org] [mech=pam] [reason=PAM auth error]
Dec 20 21:57:23 gosper saslauthd[1615]:                 : auth failure: [user=iknikieh] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]

With lots more for different names. The last one is probably this session:

Dec 20 21:57:16 gosper sm-mta[15854]: STARTTLS=server, relay=[5.188.206.203], version=TLSv1.2, verify=NOT, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256/256
Dec 20 21:57:24 gosper sm-mta[15854]: 0BKKvEuN015854: [5.188.206.203] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-SSL

Due to the fact that they abort the session when they can't log in the IP is seen as annoying by fail2ban and added to the deny list. But that list grows (suggesting a distributed attack) and is at this moment at 142 currently blocked hosts.

I noticed the certificate for idefix.net was expired according to my webbrowser. I dug up the reason and found out the scripts to maintain the ocsp files managed to confuse the Makefile to keep the haproxy certificates updated.

The ocsp responses have more updates than the certificates, but a certificate update needs to be processed anyway.

So I updated the Makefile in the previous post. The dependency is now certificate-stamp depends on installed certificates, installed certificates depend on copied certificates. And installing the certificate also updates the ocsp response.