Since activating sendmail authentication with secondary passwords I see a number of attempts to guess credentials to send mail via my system. This is not very surprising, given the constant attack levels on the wider Internet.

For work I am looking at log correlation and monitoring and with that in mind I noted that finding the right information from sendmail where and when the attempt came from is quite hard since there are several processes busy and it's hard to correlate the logging. The failed attempt is logged by saslauthd in /var/log/auth.log:

Aug 16 12:28:57 greenblatt saslauthd[32648]: pam_unix(smtp:auth): check pass; user unknown
Aug 16 12:28:57 greenblatt saslauthd[32648]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
Aug 16 12:28:59 greenblatt saslauthd[32648]: do_auth         : auth failure: [user=monster] [service=smtp] [realm=idefix.net] [mech=pam] [reason=PAM auth error]
Aug 16 12:29:00 greenblatt saslauthd[32649]: pam_unix(smtp:auth): check pass; user unknown
Aug 16 12:29:00 greenblatt saslauthd[32649]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
Aug 16 12:29:02 greenblatt saslauthd[32649]: do_auth         : auth failure: [user=monster] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]

This is probably related to this sendmail log information:

Aug 16 12:28:56 greenblatt sm-mta[20716]: STARTTLS=server, relay=62.82.128.182.static.user.indesat.com [62.82.128.182] (may be forged), version=TLSv1/SSLv3, verify=NO, cipher=DHE-RSA-AES256-SHA, bits=256/256
Aug 16 12:29:02 greenblatt sm-mta[20716]: w7GASspx020716: 62.82.128.182.static.user.indesat.com [62.82.128.182] (may be forged) did not issue MAIL/EXPN/VRFY/ETRN during connection to MSP-v6

But I can't be sure as there are multiple 'did not issue MAIL/EXPN/VRFY/ETRN' messages in the logs. So I can't build a fail2ban rule based on this.

This evening I tried several things to improve my chances of actually receiving anything other than the loudest stations in the upcoming SCC RTTY contest.

First try was with a borrowed receive loop indoor and using an HF upconvertor, an rtl-sdr dongle and gqrx as receiving software. This did not work for digital modes: letting wsjt-x (FT8 software) 'listen' to the audio output of gqrx gave no decodes.

Interesting detail: looking at the right piece of spectrum for FT8 showed that the frequency wasn't 100% stable, with frequencies slowly changing. Touching the rtl-sdr gave a bump in frequency.

Another attempt was with the loop indoor and reception on the FT-857D radio. Reception of a strong SSB station seemed somewhat better on the loop, but I heard no improvement of weaker stations.

So I moved the loop outside to the end of the garden and layed a long cable back to the radio setup. This made interference worse! It was already dark so this was not related to any solar panel setup, but some other source of interference on HF. The loop is supposed to receive less local interference but I could not get it to do that this time (it did work for SSB some other time).

----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014
.0.4830 / Virus Database: 4365/10772 - Release Date: 13/08/18

[-- Attachment #2: doc10089752487652120190813.docx.jar --]

I guess No known virus found was a better message for AVG.

The HP DPS-700 GB power supply adapted to feed the linear amplifier has no own internal fans so I connected a recycled 50mm PC fan. Which runs at full speed which is a lot of noise. I ordered a 12 volt fan control module on-line so it can run slower and keep the noise down a bit.

I'll probably replace the current fan with an 80mm PC fan and set a low minimum speed. The air has to move as the power supply has no internal fans and is quite good at a thermal shutdown. But as long as things don't get warm it would be nice to reduce the noise as this was very noisy.

The reason for making the HP DPS-700 GB powersupply deliver a somewhat higher voltage and lots of amperes is that I made the decision to buy a HF linear amplifier. With such a device I get more output power on HF bands which should increase my chances in radio contests.

I have been looking at new and secondhand linear amplifiers for a while. Since this market is dominated by US customers most amplifiers will give 1000-1500 Watts output power at a serious price. The legal limit here in the Netherlands is 400 Watt unless I request a special license which will never happen since the radio station is surrounded by other houses. But there isn't much on offer below 400 Watt output power. I found RM Italy which sells linear amplifiers for CB and radio amateur use at more reasonable amounts of power and at a better price-point. I selected the RM Italy HLA300V plus which should give 300 Watts on HF bands.

I bought it online and it arrived fast. After soldering some cables to the power supply I was able to use it and it works as intended.

On the 20 meter band and 10 meter band it works with the endfed antenna (which can take 400 watts). On the 40 meter band it goes into protection mode instantly. It turns out the amplifier is quite sensitive to SWR problems, the endfed gives a 1:1.5 SWR. Maybe I can improve this a bit, the resonant point is below the 40 meter band.

Giving it 5 watt input power in digimodes will make 5 of the 7 output power LEDs light up. To get it to light up 5 LEDs in SSB mode I need to give it 10 watts power in that mode.

Propagation wasn't great this weekend so I spent most time in FT8 mode. With the help of the new amplifier I was able to get two new countries in the log: V51MA in Namibia and 9G5AR in Ghana.

The receive side is currently a different story. Interference levels are at an all-time high. The way I currently get reception for FT8 is by using the UTwente WebSDR for the receive side and feeding the audio to WSJT-X. With the delays and audio-processing introduced by the WebSDR I still get better and more decodes than from the local receiver.

For contesting that setup is not going to work. Most contests have a rule that all equipment for a contest station has to be on a limited area. For example the upcoming SCC RTTY contest has the rule:

All operation must take place from one operating site. Transmitter and receiver must be located within a 500-meter diameter circle.

I'm looking into using a receive loop to have less interference on reception.

The authenticated SMTP setup with sendmail and secondary passwords I created is also attracting a new kind of attack: trying credentials from dataleaks. Leading to interesting tries in the log:

Aug 10 17:29:01 greenblatt saslauthd[32650]: do_auth         : auth failure: [user=409shop.com] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]
Aug 11 10:48:42 greenblatt saslauthd[32649]: do_auth         : auth failure: [user=409shop.com] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]

At a hamfest a scouting group was offering a HP DPS-700 GB power supply for the nice sum of 5 euro. A quick search with google found information about the pinout so I bought it. This is a power supply that can deliver 56 Ampere at 12 Volts, and the 12 Volts can be adjusted upwards somewhat.

As usual with projects like this the power supply lived in the stack of projects for a while, but today I got around to testing it. Finding the pinout again was a bit hard, but I found the pins again at HP DPS-700GB 80mm fan shroud - Thingiverse which includes the simple modification to make the output voltage go up.

As this power supply has no internal fans and will stop fast due to internal overheating if not cooled, I set it up with a recycled computer fan. Power supplies like this will always be active in systems with enough fans to push air through the whole chassis.

The first test gave me 12.1 Volt. After adding a 1.5 kOhm resistor it went to 13.27 Volt. In theory the maximum current may have dropped as a result of this modification, but my best guess is that it can still deliver 50 Ampere.

After thoroughly automating Let's Encrypt certificate renewal and installation I wanted to get the same level of automation for systems that do not expose an http service to the outside world. So that means the DNS-01 challenge within the ACME protocol has to be used.

I found out dehydrated Let's Encrypt certificate management supports DNS-01 and I found a sample on how to do this with bind9 at Example hook script using Dynamic DNS update utility for dns-01 challenge which looks like it can do the job.

It took me a few failed tries to find out that if I want a certificate for the name turing.idefix.net that it will request the TXT record for _acme-challenge.turing.idefix.net to make me prove that I have control over the right bit of DNS. I first assumed something in _acme-challenge.idefix.net which turned out wrong. So the bind9 config in /etc/bind/named.conf.local has:

zone "_acme-challenge.turing.idefix.net" {
        type master;
        file "/var/cache/bind/_acme-challenge.turing.idefix.net-zone";
        masterfile-format text;
        allow-update { key "acmekey-turing"; };
        allow-query { any; };
        allow-transfer {
                localnetwork;
        };
};

And in the idefix.net zone there is just one delegation:

_acme-challenge.turing  IN      NS      ns2

I created and used a dnskey with something like:

# dnssec-keygen -r /dev/random -a hmac-sha512 -b 128 -n HOST acmekey-turing
Kacmekey-turing.+157+53887

This gives 2 files, both with the right secret:

# ls Kacmekey-turing.+157+53887.*
Kacmekey-turing.+157+53887.key  Kacmekey-turing.+157+53887.private
# cat Kacmekey-turing.+157+53887.key
acmekey-turing. IN KEY 512 3 157 c2V0ZWMgYXN0cm9ub215

and configured it in /etc/bind/named.conf.options:

key "acmekey-turing" {
        algorithm hmac-md5;
        secret "c2V0ZWMgYXN0cm9ub215";
};

And now I can request a key for turing.idefix.net and use it to generate sendmail certificates. And the net result:

        (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256          
        verify=OK)                                                              

SMTP between systems with TLS working and good certificates.