News archive June 2021 - Koos van den Hout

Vandaag de aankondiging die ik twee jaar geleden al voorzag:

Per 1 oktober 2021 vervalt batched SMTP op kzdoos.xs4all.nl

Het omzetten van e-mail adressen lukt vrij goed. Het meeste wat nog op oude adressen binnenkomt is spam.

De instructie die XS4ALL geeft om dit op te lossen op Batched SMTP op subdomein vervalt - xs4all is vrij simpel. In de mail stond Op xs4all.nl/bsmtp staat hoe u kunt zien op welke adressen u berichten heeft ontvangen en wat u in Mijn XS4ALL moet doen. maar op die site komt het neer op 'zoek in je eigen mailarchieven' en niet 'na authenticatie kunt u zien wat er voor u in de maillogs bij ons staat' wat mijn eerste verwachting was.

Het is jammer, maar met alle wijzigingen bij XS4ALL naar KPN niet onverwacht. Voor mij wel een signaal dat het tijd is om op te gaan stappen als klant bij XS4ALL.

Om in de toekomst alle opties open te houden heb ik het Draytek Vigor 130 modem voorzien van firmware 3.8.4.1 met modem6 DSL driver. Ik ben erg benieuwd naar de stabiliteit als ik actief ben op amateur banden onder 17 MHz, en ik wil weten hoe dit nu werkt op de lange termijn.

Bij de eerste testen met sterke signalen op de 20 meter en 40 meter band blijft de verbinding in ieder geval in stand, ik zie alleen een klein beetje packet loss bij de eerste signalen. In ieder geval geen volledig verbreken van de verbinding.

De latency is wel weer toegenomen, de verbinding is weer interleaved helaas. Opvallend is dat er later meer uitschieters kwamen in de latency voor IPv4 verkeer. Dat begon ongeveer omstreeks de tijd dat ik de test met radio signalen deed.

En nu weer een MTU van 1500 bytes op de ppp verbinding.

To share my work on mhaas / mqtt-to-influxdb-forwarder : IoT MQTT to InfluxDB forwarder I forked the repository to KHoos / mqtt-to-influxdb-forwarder: zigbee2mqtt to InfluxDB forwarder and committed my changes to the source, and later updated the documentation and committed those changes too.

I thought somebody must have been doing zigbee2mqtt measurements to influxdb before and I was somewhat right: it was mentioned in a bugreport! In issue Can't receive messages from mqtt #3 it shows that someone is already trying to do this but it's not completely there yet. So I cloned mhaas / mqtt-to-influxdb-forwarder : IoT MQTT to InfluxDB forwarder after a few updates it does what I want: correctly use the sensor id as tag and only parse messages that have live sensor data. Zigbee2mqtt likes to publish its internal housekeeping as mqtt messages and I don't need those.

So now I get from

zigbee2mqtt/0x00158d0006fafb00 {"battery":100,"humidity":37.86,"linkquality":84,"pressure":1032,"temperature":28.67,"voltage":3045}

To

DEBUG:forwarder.InfluxStore:Writing InfluxDB point: {'fields': {u'linkquality': 84.0, u'temperature': 28.67, u'battery': 100.0, u'humidity': 37.86, u'pressure': 1032.0, u'voltage': 3045.0}, 'tags': {'sensor_address': u'0x00158d0006fafb00'}, 'measurement': 'environment'}

And available as:

$ influx -database environment -precision rfc3339
Connected to http://localhost:8086 version 1.6.4
InfluxDB shell version: 1.6.4
> select * from environment;
name: environment
time                           battery humidity linkquality pressure sensor_address     temperature voltage
----                           ------- -------- ----------- -------- --------------     ----------- -------
[..]
2021-06-22T21:05:10.227577886Z 100     37.86    84          1032     0x00158d0006fafb00 28.67       3045

I will need to add something with friendly names, but this is a nice start. Data flows!

And regex101 regular expression tester and debugger saved the day in finding how to change the Python regular expression to only accept data from zigbee messages with a sensor address.

Voor mijn stukje over het luisteren naar marifoon kanalen zocht ik eigenlijk naar een afbeelding van een marifoon op een schip.

En het aanbod viel zwaar tegen. Via de de wikipedia pagina over het ontwerp Marifoon kom ik wel een creative commons afbeeldingen tegen van een oude marifoon, maar niets actueels. Kwa beeld zocht ik iets als een moderne marifoon zoals te koop via Inbouwmarifoons - Maritiem - hamshop.nl en dan ingebouwd op een schip, want dat is mijn persoonlijke beeld. Blijkbaar heeft nog niemand die foto gemaakt en onder creative commons beschikbaar gesteld. Termen 'marifoon', 'marine radio' en 'ship radio' in combinatie met de juiste licentie leveren niet het beeld op wat ik heb.

Als ik de vraag om een open licentie er af laat kom ik best voorbeelden tegen zoals in het artikel Marifoon aan boord - Myon zeiljacht verhuur maar die zijn niet expliciet vrij te gebruiken.

Gisteren op een zeilboot geweest en vanuit mijn hobby als radioamateur was ik natuurlijk ook benieuwd naar de radio aan boord. Daar werd niet veel mee gedaan omdat de eigenaar van de zeilboot nog geen marifoon bedienings certificaat heeft. Verder leuk een stukje mee gevaren. Ik heb geen idee van zeilen maar met iemand er bij met kennis en inzicht is het leuk om mee te maken.

Dat was natuurlijk wel aanleiding om me eens te verdiepen in de ontvangst van het marifoon verkeer. Hier in Utrecht is er niet zoveel te beleven maar er zijn een paar bruggen en sluizen met misschien wat verkeer wat ik zou kunnen ontvangen. Dus ik heb de programmeerkabel voor de QYT KT-8900 opgedoken en na wat zoeken deed deze het weer. Marifoonkanalen en gebruik gevonden op Marifoon kanalen en marifoon frequenties en de frequenties via Overzicht VHF marifoonkanalen - frequentieland en daarnaast nog Marifoonkanalen Nederland - Binnenvaart kennis.

Uiteindelijk een set kanalen gevonden die kans gaven op verkeer en deze in de radio geprogrammeerd. Puur voor ontvangst, niet om daar ooit op te willen zenden!

De kanalen en frequenties waarvan ik denk dat ze interresant zijn:

Kanaal	Frequentie schip	Frequentie wal	Gebruik
1	156.050 MHz	160.650 MHz	Centrale meldpost IJsselmeer
6	156.300 MHz	Simplex	Intership
10	156.500 MHz	Simplex	Intership
13	156.650 MHz	Simplex	Intership
15	156.750 MHz	Simplex	Intraship
17	156.850 MHz	Simplex	Intraship
16	156.800 MHz	Simplex	Noodoproepen
18	156.900 MHz	161.500 MHz	Sluizen en bruggen, Merwedekanaal
20	157.000 MHz	161.600 MHz	Sluizen en bruggen
22	157.100 MHz	161.700 MHz	Sluizen en bruggen
61	156.075 MHz	160.675 MHz	Verkeersbegeleiding blokkanaal Maarssen Amsterdam-Rijn kanaal
72	156.625 MHz	Simplex	Sociaal
77	156.875 MHz	Simplex	Sociaal
84	157.225 MHz	161.825 MHz	Sluizen en bruggen
85	157.275 MHz	161.875 MHz	Sluizen en bruggen

Een deel van de kanalen zoals die voor sluizen en bruggen hebben een aparte schip en wal frequentie. Dat zorgt natuurlijk dat de brugwachter of sluiswachter altijd het woord kan nemen en een mededeling kan doen zonder dat er een radio vanaf een schip doorheen kan storen.

Met het lezen over marifoon gebruik en kanalen is het wel duidelijk dat het allemaal zeer goed gestructureerd is en gebruikers dienen te weten welk kanaal voor welk gebruik is en hoe de procedures zijn. Sociaal gebruik was eerst helemaal niet de bedoeling, bij uitbreiding van de kanalen is daar iets ruimte voor gekomen. De frequenties laten zien dat de uitbreiding van de beschikbare kanalen is gekomen door het overschakelen op een ander kanaalraster.

Dus nu staat de radio constant deze frequenties en daarnaast diverse amateur frequenties en pmr frequenties te scannen. Voorlopig is de conclusie dat het vrij rustig is op de marifoon kanalen en dat als ik wat hoor de communicatie volgens nette regels gaat en vrij kort is, er is duidelijke etherdiscipline. Daarnaast hoor ik op PMR kanaal 7 soms een babyfoon en soms gesprekken die me het idee geven dat een restaurant dat kanaal gebruikt voor communicatie. Ik denk dat ze elkaar niet horen, ik heb een veel hogere antenne.

The page How to improve network range and stability - zigbee2mqtt.io has using an USB extension cable as the first solution to improve communications. And indeed my earlier problems with zigbee communications now seem solved and I get good quality readings from longer distances.

After reinstalling the Raspberry Pi in the utility closet so it can run newer software I did the steps to install zigbee2mqtt on it which was quite possible this time.

I migrated the settings and the database from my first run of zigbee2mqtt on a linux laptop and on the first try no communication started with the zigbee dongle.

On the second try (different usb port) things started working. The zigbee dongle is currently plugged directly into the Raspberry and as several manuals say this is not an ideal configuration. Those manuals are right: suddenly the sensor about 4 meters away isn't seen. I will need to improve the situation and move the dongle or its antenna to a better location.

Zigbee2MQTT:info  2021-06-18 22:28:15: MQTT publish: topic 'zigbee2mqtt/0x00158d0006fafb00', payload '{"battery":100,"humidity":62.52,"linkquality":147,"pressure":1023,"temperature":27.77,"voltage":3175}'

Because the installation of zigbee2mqtt was not possible on the Raspberry pi in the utility closet I decided to do a reinstallation with Raspbian buster. According to some on-line opinions reinstalling is better than a distro upgrade on a microsd card.

I was lucky to have a spare MicroSD card and a spare Raspberry Pi available. I did the whole installation on the spare and made sure to set up everything already so things would start running. And the thing that I missed was fixed easily with the old configuration still available. The Raspberry Pi in the utility closet was only running the smart meter monitoring, but now it is upgraded it can do more things, and running zigbee2mqtt for checking on wireless sensors in the house is next.

The package with the zigbee environment sensors I ordered arrived this morning and I had to get the first test done right away.

Joining the network/resetting the sensor is easy with a long press of the button and it showed up:

Zigbee2MQTT:info  2021-06-12 11:53:17: Device '0x00158d0006fafb00' joined
Zigbee2MQTT:info  2021-06-12 11:53:17: Starting interview of '0x00158d0006fafb00'
gbee2MQTT:info  2021-06-12 11:53:52: Successfully interviewed '0x00158d0006fafb00', device has successfully been paired
Zigbee2MQTT:info  2021-06-12 11:53:52: Device '0x00158d0006fafb00' is supported, identified as: Xiaomi Aqara temperature, humidity and pressure sensor (WSDCGQ11LM)
Zigbee2MQTT:info  2021-06-12 11:53:52: Configuring '0x00158d0006fafb00'
Zigbee2MQTT:info  2021-06-12 11:53:52: Successfully configured '0x00158d0006fafb00'

And now it gives me data!

Zigbee2MQTT:info  2021-06-12 12:15:53: MQTT publish: topic 'zigbee2mqtt/0x00158d0006fafb00', payload '{"battery":100,"humidity":45.77,"linkquality":153,"pressure":1033,"temperature":24.9,"voltage":3055}'
Zigbee2MQTT:info  2021-06-12 12:15:53: MQTT publish: topic 'zigbee2mqtt/0x00158d0006fafb00', payload '{"battery":100,"humidity":45.85,"linkquality":156,"pressure":1033,"temperature":24.9,"voltage":3055}'
Zigbee2MQTT:info  2021-06-12 12:15:53: MQTT publish: topic 'zigbee2mqtt/0x00158d0006fafb00', payload '{"battery":100,"humidity":45.85,"linkquality":156,"pressure":1033,"temperature":24.9,"voltage":3055}'

Also visible via mqtt:

koos@testrouter:~$ mosquitto_sub -t zigbee2mqtt/0x00158d0006fafb00 -v
zigbee2mqtt/0x00158d0006fafb00 {"battery":100,"humidity":45.77,"linkquality":153,"pressure":1033,"temperature":24.9,"voltage":3055}
zigbee2mqtt/0x00158d0006fafb00 {"battery":100,"humidity":45.85,"linkquality":156,"pressure":1033,"temperature":24.9,"voltage":3055}
zigbee2mqtt/0x00158d0006fafb00 {"battery":100,"humidity":45.85,"linkquality":156,"pressure":1033,"temperature":24.9,"voltage":3055}

I started looking at the instructions for running zigbee2mqtt and the instructions for installing npm/nodejs gave me a lot of error messages on the raspberrypi running in the utility closet and checking the smart meter.

It turns out it needs an upgrade from Raspbian jessie. This Raspberry Pi is dedicated to reading the smart meter since August 2016 and it has been running fine gathering the smart meter data.

The raspbian forums state that it is better to upgrade by reinstallation on a different SD card. So I guess it's time to rebuild the smartmeter Pi if I want it to run the zigbee sensor network.

Update:
I installed all the software on a linux laptop and now I have a running zigbee2mqtt.

Diverse media die ik volg berichtten vanmorgen over een artikel in Trouw: 'Tientallen websites overheid voldoen niet aan veiligheidsrichtlijnen' - nos.nl en ‘Tientallen overheidswebsites zijn onvoldoende beschermd tegen hackers’ - volkskrant.nl.

De aanname in het originele artikel (achter betaalmuur) is dat omdat een website van een overheidsinstantie gebruik maakt van wordpress waar je prima de beheer login pagina kunt vinden deze websites automatisch allemaal kwetsbaar zijn. En voor het gemak wordt dan even de link gelegt met de inbraak bij de gemeente Hof van Twente.

Hiermee worden zo'n hoop stappen overgeslagen in beveiliging en gereduceerd tot 'openbare login dus onveilig'. Ik weet dat wordpress bekend en berucht is om onveiligheden en dat elke wp-login pagina constant geprobeerd wordt en als die er is bruteforce aanvallen krijgt. Deze website draait geen wordpress en ik zie 5-11 pogingen per dag om de wp-login pagina te vinden. Een andere site waar ik de hosting voor verzorg draait wel wordpress en met een heel strak afgesteld filter wat herhaalde login pogingen blokkeert zie ik 500 tot 1300 pogingen per dag om in te loggen. Zo'n login pagina is dus een bekend risico en daar moet iets mee. Daar neem je maatregelen zoals beperkingen van het aantal login pogingen per bron en sterke wachtwoorden. Daarnaast moet dus wordpress zelf goed beheed worden en bij eventuele kwetsbaarheden snel bijgewerkt worden.

Ik denk ook dat sommige van de genoemde websites juist expres voor een externe wordpress gebaseerde site hebben gekozen na een goede risico-afweging. De site kan dan zeer eenvoudig compleet losgekoppeld zijn van de verdere computersystemen van de overheidsdienst waar het om gaat. En gebeurt er iets met die wordpress website dan gooi je die weg en bouwt de site opnieuw op.

Het artikel mist al dit soort overwegingen en nuances. Er wordt nog even een link gelegd naar het slechte wachtwoord wat aan de bron lag van de ransomware aanval op de gemeente Hof van Twente. Maar dat slechte wachtwoord gaf zonder 2e factor toegang tot het interne netwerk van die gemeente via remote desktop. Onbevoegde toegang tot een besturingssysteem middels remote desktop is in veel gevallen een veel groter risico dan beheerrechten op een wordpress site.

Ik vind het een slecht artikel en het is jammer dat diverse andere media het zonder al te kritisch te zijn overnemen.

Voor de goede orde: ook al werk ik in de informatiebeveiliging, dit is mijn persoonlijke opinie en heeft niets te maken met werkgevers.

The zigbee stick I ordered for environmental monitoring at home is making its way over here and I received an sms about the duty and tax to be paid for importing it from the United Kingdom. Indeed, since brexit taxes have to be paid.

My first reaction when receiving an sms about a package was to think of malware attempts since that has been in the news recently. So I checked carefully. It's good dpd also sends an e-mail with the same information, and I can check the validity of the links and the source of the e-mail a lot better on a computer.

I still had the unfinished business of not having a good backup when half a filesystem ended in lost+found and it took a whole day to recover from that problem. And I still found missing things today.

I have no working tapedrives left, but a good amount of disk storage available. I still like amanda as backup program, so I looked into the vtapes (virtual tapes) option. The sample amanda.conf explains this nicely:

# To use vtapes, create some slotN directories (slot0, slot1, etc.) under
# /var/amanda/vtapes and use this tapedev:
## tapedev "chg-disk:/var/amanda/vtapes"
tapedev "chg-disk:/scratch/nasback/vtapes"

So I created those writeable by the amanda user.

I try to only backup data that I can't get by a reinstallation. So I backup /etc (configuration), /var (system data), /home (user data) and a few other directories.

Since January 2008 I measure temperatures and other environmental data in and around the house with 1-wire sensors and adaptors. These work fine but need wires between the sensors and that isn't ideal for quick spot measurements.

So I looked into other options recently, and found affordable zigbee temperature/air pressure/humidity sensors. And an USB zigbee interface which works with linux and with a lot of the available application software. Because the next problem is going sensor - zigbee network - zigbee usb interface - some magic - database of measurements.

Because I see myself wanting long series of measurements from a number of places in the house and testing without breaking those series I ordered two USB zigbee interfaces and eight environmental sensors. I guess I want production and development enviromental monitoring.

• Zigbee interface: zzh! CC2652R Multiprotocol RF Stick (tindie)
• Sensors: Xiaomi Aquara smart home sensor air pressure temperature humidity (aliexpress)

The zigbee stick is not the cheapest solution but it is documented to work with zigbee2mqtt and buying one supports work on that software.

New bitcoin extortion spam coming in for wallet 122F3j5EfUKnuKjFY54pCE43C793eVPSTY. I got it in English, but given the reports it was also sent out in at least one other language.

Which means the author has no idea who pays, but just likes a filled bitcoin wallet.

Ik beheer mijn eigen mailserver (met al meer dan 25 jaar sendmail in gebruik) en nu kreeg ik ook de brief over de aanpassingen in SMTP van xs4all. Het komt er op neer dat relaying op basis van IP adres gaat verdwijnen.

Om een helpdeskramp te voorkomen gaat het uitschakelen per gebruiker. Ik heb een brief gekregen dat ik soms gebruik maak van deze route en dat moet aanpassen.

Dat klopt, voor sommige servers was het feit dat ik weinig mail naar die servers stuur een reden om het te blokkeren. Of het ooit ontbreken van een IPv6 reverse pointer. Dat laatste heb ik goed laten zetten toen.

Op de website van xs4all staat wel een uitleg: Veilig e-mailen 2020 - xs4all maar daar staat niets bij over sendmail. Thuisservers die mailen zijn blijkbaar niet meer hun doelgroep (mijn Cron Daemon is er anders best goed in!).

Ik ben maar eens begonnen met het leeggooien van de lijst in de mailertable. We gaan zien welke domeinen nu onbereikbaar zijn.

I am looking at better protection inside my home network since there is a mix of "trusted" and "not so trusted" devices in the house. I consider devices that just need Internet access to talk to some server out there (the well-known "cloud" better known as "Someone else's computer") and are (mostly) black boxes untrusted compared to systems that are installed with a known operating system and where I can control what they can and can't do.

One of the things I wanted to improve are local host-based firewalls. The firewall in the router linux machine is the result of years of fine-tuning and experience so I manage that by hand. But for somewhat standard hosts I want simple firewalls that are easily managed.

I tried ufw, the Uncomplicated Firewall and on the first (test) machine it went fine without a problem. On the second machine where there are already a few active firewall rules managed by fail2ban something hickupped and before I knew it ufw managed to leave me with an unreachable machine.

The error message from ufw-init was something about being unable to initialize firewall rule ufw-track-output and the net result was that the machine became unreachable. I needed console access to get back in again. Removing/purging the ufw package didn't help, after reinstalling it and trying again the same error came up and the system was unreachable again.

It turns out ufw leaves its own rules in iptables/ip6tables active (prefixed with 'ufw') and this confused ufw-init. I tried removing them by hand (lots of work) or with a very small shell script, but in the end rebooting the machine and only reinstalling ufw after that reboot got me back to a normal usable situation.