Category Archives: Computers

Everything that has to do with, guess what, computers. :-)

Das perfekte USB-C-Ladekabel zum Apple-Netzteil

Kürzlich habe ich ein neues MacBook Pro 13″ mit USB-C-Ladestecker erworben. Da ich das Netzteil nicht ständig zwischen Büro und Zuhause hin und her schleppen möchte, habe ich ein zusätzliches original Apple Netzteil bestellt. Zu meinem großen Ärger ist im Lieferumfang (bei einem Preis von immerhin 75 EUR!) nicht einmal das USB-C-Ladekabel enthalten… 🙁

Zugegeben, das war in der Angebotsbeschreibung so erläutert (wie ich dann hinterher feststellen musste), aber wer rechnet schon mit sowas und liest die Artikelbeschreibung für ein Netzteil bis ins letzte Detail durch???

Daher habe ich auf Amazon nach einem geeigneten 2 m USB-C-Kabel gesucht. Dabei bin ich auf dieses magnetische Kabel gestoßen, von dem ich total begeistert bin, so dass ich mittlerweile drei Stück davon besitze. 😉

Das tolle an dem Kabel ist die magnetische Kupplung, die ich schon bei den Magsafe-Netzteilen meiner vorigen MacBook Pros so geschätzt habe. Zieht man nämlich unabsichtlich am Kabel, z. B. weil jemand versehentlich in das Kabel hineintritt oder sich dort verheddert, so wird einfach die magnetische Kupplung des Kabels vom Laptop getrennt. Das Kabel reißt also nicht das teure Gerät vom Tisch oder Schoß herunter.

Continue reading Das perfekte USB-C-Ladekabel zum Apple-Netzteil

PayPal schränkt nach Disput Konto ein

Ich bin seit über 16 Jahren “Kunde” bei PayPal. Nach einem Disput mit PayPal selbst hat PayPal nun plötzlich meinen Account in einen “eingeschränkten Zustand” versetzt.

Als jemand, der beruflich im Bereich IT-Sicherheit unterwegs ist, liegt mir dieses Thema natürlich gerade auch bei einem Finanzdienstleister wie PayPal sehr am Herzen. Daher benutze ich seit Einführung bei PayPal einen “Sicherheitsschlüssel” (allgemein “Zwei-Faktor-Authentifizierung”, “two-factor authentication”, 2FA, TFA, MFA genannt) als zusätzliche Sicherung meines Accounts.  (Zu diesem Thema gibt es auch einige Artikel hier in meinem Blog!) Zunächst einen Hardware-Schlüssel in Form eines kleinen feuerzeuggroßen elektronischen Geräts, später dann einen Software-Schlüssel in Form einer Handy-App.

Im Laufe der vielen Jahre der Nutzung von PayPal habe ich entsprechend oft einen neuen Sicherheitsschlüssel im PayPal-Account registriert, da ich diese Schlüssel jeweils auf meinen beiden (Privat- u. Dienst-) Handys benutze, und diese jeweils alle zwei Jahre durch neue Geräte ersetzt werden, so dass ich auch eine neue Schlüssel-App installieren und registrieren muss.

Dieser Fall war nun wieder eingetreten, und überraschenderweise konnte ich nicht mehr einen neuen Schlüssel registrieren. Der PayPal-Support teilte mir zunächst mit, diese Software-Schlüssel würden in Deutschland nicht mehr unterstützt, daher könne man keine neuen Schlüssel registrieren.

Nach längerem Hinundher fand ich jedoch heraus (u. a. durch Unterstützung von Lesern meines eigenen Blogs und eigene Untersuchungen), dass mir PayPal offensichtlich (bewusst!) die Unwahrheit gesagt hatte. Die wahre Ursache ist ein Problem auf Seiten von PayPal, nämlich eine willkürliche Beschränkung auf zehn Sicherheitsschlüssel. Man kann diese Schlüssel deaktivieren, z. B. wenn sie defekt sind oder verloren gingen, aber man kann sie nicht aus dem Account “löschen”. Erreicht man dadurch das Limit von zehn Schlüsseln, so kann man keine neuen Schlüssel registrieren.

Daher bat ich den Support, dass dieser die alten, bereits von mir deaktivierten Schlüssel löschen möge. Dazu verlangte der Support, dass ich dort anrufen möge. Warum, das wurde mir auch auf ausdrückliche Nachfrage bis heute nicht erklärt. Insbesondere hat PayPal durch meinen Anruf keine größere Gewissheit, dass es sich tatsächlich um meine Person handelt. Ich teilte PayPal mit, dass ich nach 20 min. in der Warteschleife aufgegeben habe, und dass ich ohnehin aus Beweisgründen eine Korrespondenz per Nachricht innerhalb meines PayPal-Accounts bevorzuge.

Nun hat PayPal plötzlich meinen Account in einen eingeschränkten Zustand versetzt und verlangt von mir, dass ich ein Ausweisdokument hochlade sowie ein Dokument, welches meine aktuelle Adresse belegt. Ich lehne das Hochladen meines Personalausweises grundsätzlich ab wegen der drohenden Missbrauchsgefahr (siehe der aktuelle “Mariott”-Skandal, wo Daten von 500 Mio. Kunden gestohlen wurden, u. a. Ausweisnummern!). Außerdem ist es mir unverständlich, wieso PayPal nun plötzlich — fast sieben Jahre nach meinem letzten Umzug — meine Adresse verifiziert haben möchte. Bei Umzügen habe ich bisher immer einfach meine Adresse in meinem Account geändert, damit war der Fall erledigt.

Ich kann mich PayPal gegenüber nach wie vor durch Einloggen in meinen Account authentifizieren, da ich noch über ein Handy verfüge, welches dort registriert ist. PayPal kann also keine ernsthaften Zweifel an meiner Identität haben. Sehr negativ aus Sicherheitsgesichtspunkten ist die Tatsache, dass PayPal es erlaubt, den Sicherheitsschlüssel durch die Beantwortung von zwei Fragen (“Geburtsname meiner Mutter” und “Wohnort als “Kind) zu ersetzen. Es gibt eine Reihe von Personen außer mir selbst, die diese Fragen beantworten können. Die Sicherheit meines Accounts wird also stark geschwächt, und das Verfahren des Sicherheitsschlüssels ad absurdum geführt.

Das Verhalten von PayPal — immerhin eine “Bank”, da das Unternehmen meines Wissens über nach eine Bankenlizenz verfügt! — finde ich unglaublich, geradezu “nach Gutsherrenart”. Daher werde ich mich nun bei diversen Organisationen des Verbraucherschutzes und der Finanzaufsicht über PayPal beschweren.

ntp running in chroot stopped working after Debian Stretch upgrade

Today I upgraded my root server from Jessie to Stretch, and suddenly ntp stopped working.

I found errors like follows in the log, which were obviously due to failures in name resolution:

2018-05-31T07:44:48.900756+00:00 myhost ntpd[22855]: giving up resolving host 1.debian.pool.ntp.org: Servname not supported for ai_socktype (-8)

The solution to make this work was to bind-mount some files and directories essential for name resolution into the chroot jail.

First create some directories and some dummy files:

# mkdir /var/lib/ntp/etc /var/lib/ntp/lib /var/lib/ntp/proc
# mkdir /var/lib/ntp/usr /var/lib/ntp/usr/lib
# touch /var/lib/ntp/etc/resolv.conf /var/lib/ntp/etc/services

Then update your /etc/fstab as follows:

...
#ntpd chroot mounts
/etc/resolv.conf  /var/lib/ntp/etc/resolv.conf none bind 0 0
/etc/services	  /var/lib/ntp/etc/services none bind 0 0
/lib		  /var/lib/ntp/lib none bind 0 0
/usr/lib	  /var/lib/ntp/usr/lib none bind 0 0
/proc		  /var/lib/ntp/proc none bind 0 0

Finally mount all these binds:

# mount -a

Thanks to the ArchLinux guys where I found this.

To check whether your ntp is working again, you can use the following command which shows a list of peers known to your ntp server:

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 0.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 1.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 2.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 3.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
*ptbtime1.ptb.de .PTB.            1 u   46   64  377   11.483   -0.411   0.201
+ptbtime2.ptb.de .PTB.            1 u   52   64  377   11.502   -0.533   1.069
+ptbtime3.ptb.de .PTB.            1 u   47   64  377   11.451   -0.510   3.866
#batleth.sapient 131.188.3.221    2 u   44   64  377    0.188    1.097   0.176
#5.199.135.170 ( 130.149.17.21    2 u   45   64  377   11.271    0.581   0.396
-mail.morbitzer. 193.175.73.151   2 u   47   64  377    2.760    0.556   0.278
#hotel.zq1.de    161.62.157.173   3 u   46   64  377    0.094    1.384   0.261
-ntp2.m-online.n 212.18.1.106     2 u   47   64  377    7.167   -0.333   0.190
#2a03:b0c0:3:d0: 81.94.123.16     3 u   49   64  377    6.288   -2.071   1.760
#touka.thehomeof 130.149.17.21    2 u   48   64  377    0.206    0.932   0.222
+maggo.info      124.216.164.14   2 u   42   64  377    0.278   -0.137   0.436
+weyoun4.cord.de 124.216.164.14   2 u   44   64  377    2.849   -0.255   0.409
+opnsense.sauff. 222.217.153.8    2 u   43   64  377    0.270   -0.617   0.167
-web1.sys.ccs-ba 192.53.103.104   2 u   35   64  377    0.173   -1.251   0.220
#uruz.org        122.227.206.195  3 u   49   64  377    0.216    1.694   0.309
#clients5.arcani 162.23.41.55     2 u   38   64  377    6.120   -1.500   0.130
+stratum2-1.NTP. 129.70.130.71    2 u   47   64  377   14.043    1.625   0.394

The following command confirms that your current time is actually correct (within certain limits, of course):

# ntpstat
synchronised to NTP server (192.53.103.108) at stratum 2
   time correct to within 15 ms
   polling server every 64 s

If this was helpful, I would be happy to hear from you.

Exim malware scanner issue after upgrade from Jessie to Stretch

Today I finally upgraded by personal root server from Debian Jessie to Stretch, thereby upgrading Exim from 4.84 to 4.89.

After the upgrade, I observed the following errors in mainlog:

2018-05-31 08:02:03 +0000 1fOIX5-0001rg-AM malware acl condition: cmdline  : scanner returned error code: 36096
2018-05-31 08:02:03 +0000 1fOIX5-0001rg-AM H=([IPv6:2a00:6020:1efc:ee20:8857:7824:6a49:8368]) [2a00:6020:1efc:ee20:8857:7824:6a49:8368]:48523 I=[2a01:4f8:141:429::2]:465 Warning: ACL "warn" statement skipped: condition test deferred
2018-05-31 08:02:04 +0000 1fOIX5-0001rg-AM malware acl condition: cmdline  : scanner returned error code: 13
2018-05-31 08:02:04 +0000 1fOIX5-0001rg-AM H=([IPv6:2a00:6020:1efc:ee20:8857:7824:6a49:8368]) [2a00:6020:1efc:ee20:8857:7824:6a49:8368]:48523 I=[2a01:4f8:141:429::2]:465 Warning: ACL "warn" statement skipped: condition test deferred
2018-05-31 08:02:05 +0000 1fOIX5-0001rg-AM malware acl condition: cmdline  : scanner returned error code: 13
2018-05-31 08:02:05 +0000 1fOIX5-0001rg-AM H=([IPv6:2a00:6020:1efc:ee20:8857:7824:6a49:8368]) [2a00:6020:1efc:ee20:8857:7824:6a49:8368]:48523 I=[2a01:4f8:141:429::2]:465 Warning: ACL "warn" statement skipped: condition test deferred

Each of the three cmdline scanners caused an error, as shown above.

It seems there was a change in Exim from upstream, as reported by another user. Somehow it seems that if you define a cmdline scanner that uses a chain of commands, when there was an error return code encountered in the middle of the chain, the whole chain is considered failed.

To “fix” this issue (or rather work-around it), I changed the three ACL clauses as follows:

   warn  message                = This message contains malware ($malware_name)
         set acl_m0      = cmdline:\
-                               /usr/lib/AntiVir/guard/avscan -s --batch --scan-mode=all %s; /bin/echo -e \N"\navira_retval $?"\N:\
+                               /usr/local/bin/avscan_wrapper %s:\
                                \N^avira_retval 1$\N:\
                                \N^.*ALERT::[ \t]+([^;]*)[ \t]+;.*$\N
         malware                = *

I created a “wrapper” that effectively hides error return codes, and forces a return code of 0. The above wrapper looks like this:

#!/bin/bash

ARG="$1"

/usr/lib/AntiVir/guard/avscan -s --batch --scan-mode=all "${ARG}"
/bin/echo -e "\navira_retval $?"

exit 0

To make sure I didn’t break the malware scanning by my changes, I downloaded the EICAR test virus and sent it to myself. Exim caught the “virus” and ditched it.

Get certificates for “internal” hosts from Let’s Encrypt

I have a pretty large internal IT “landscape” in my house, and as an IT pro I want everything to be clean and “safe.” So even internally I’m using official SSL (or I should say “TLS”, as SSL 2.0 or 3.0 is deprecated since many years…) certificates for my router, WiFi access points, NAS devices, intranet server, etc., using host names in my own domain. I host this domain DNS-wise myself on a root server I rent from Hetzner.

Before the StartSSL disaster I got my certs from them. Afterwards I switched to WOSign, but now that they had their scandal as well, what to do?!

Well, Let’s Encrypt, a free public CA, is something I’m using anyway for my root server since they started operating. But to verify ownership of a domain name you had to run a web server on that respective host — something I can’t easily do for my internal hosts, as they have private IP addresses only, and their host names are not even publicly visible (they don’t have  a public A record, only one visible in my internal LAN). Even for my router’s externally visible host name I can’t easily use an HTTP-based challenge, as for security reasons I don’t want to operate a web server there.

By chance I came across the dns challenge that is now available in Let’s Encrypt’s certbot. This challenge works by deploying a TXT record that certbot requests to be under this domain name. Once you did this, you tell Let’s Encrypt to check, and if they find the TXT record this proves that you have authority over the domain.

Using it is quite straight forward:

# certbot certonly --manual -d hostname.internal.bergs.biz --preferred-challenges "dns"
[...]
Please deploy a DNS TXT record under the name
_acme-challenge.hostname.internal.bergs.biz with the following value:

YrAE-fmu-Zjsdhsjhd328723hjdhjcjHJJHJhds

Once this is deployed,
-------------------------------------------------------------------------------
Press Enter to Continue

A few seconds later I had successfully received my certificate.

So now I will write a script that will run periodically on my intranet server, and that will retrieve the then-current certificates for my internal hosts from my root server, and deploy them internally.

Hard drive slot does not matter in Synology

You can read all over the internet that it’s important to put your hard drives into their original slots, e. g. when you migrate to a new Synology device, or when you need to remove the drives to add memory.

This is simply not true.

As expected DSM, which is a flavor of “Linux,” will automatically discover your physical partitions based on the GUIDs each partition has, and then reassemble your volumes. I just tested this (i. e. intentionally put the drives into the device in the wrong order) with a JBOD volume, and I had no issues whatsoever. I cannot see why this should be different with SHR or RAID-5, for example.

If you have also tested this, please let me know how it went for you.

Securely erase Drives on Synology NAS

I had to erase an external hard drive, a WD My Book, because I had to return it due to defects. So I searched on the web how to do that on a Synology DS916+ NAS, but I could not easily find the solution. Therefore I did a more generic search how to do it under Linux, and came across the tool “shred” which I had used years ago for the last time.

I checked on my NAS, and the tool was readily available. So I ran the following command to securely erase the (external) hard drive:

 shred /dev/sdq1

Hope this helps people who need to accomplish the same.

Nie wieder Synology!

Ich muss mir heute mal meinen Frust über die schlechte Qualität der Synology-Disk Station Manager (DSM)-Software vom Leib schreiben.

Seit ich Synology-Produkte einsetze — immerhin seit mehr als fünfeinhalb Jahren (DS212+, DS414, DS415+, DS916+, wir reden hier über insgesamt mehr als 1.800 EUR, die nur die “nackten” Geräte gekostet haben!) — ärgere ich mich immer wieder über geradezu stümperhafte Implementierungen von bestimmten Funktionen. Und was dem Ganzen dann die Krone aufsetzt ist der geradezu unverschämt reagierende Synology-Support, der Bugs einfach nicht als Bugs akzeptiert, sondern “gerne in meinem Namen einen Change Request einreicht, aber ob und wann der implementiert wird können wir nicht sagen”. Oder teilweise geradezu dämliche Workarounds als “Lösung” vorschlägt, statt das Problem richtig zu lösen. 🙁

Damit wir uns nicht falsch verstehen: Die absoluten Grundfunktionen (Dateiserver über SMB, CIFS, AFP) funktionieren selbstredend problemlos. Aber dabei ist ja auch nichts falsch zu machen. Synology übernimmt einfach die bekannten und bewährten Open Source-Dienste, wie z. B. Samba. Aber bei fast allem anderen, was Synology “oben drauf gesetzt” hat, gibt es Probleme. Die unten beispielhaft geschilderten Probleme lassen sich allesamt im Netz wieder finden. Unzählige Kunden leider unter diesen Problemen, aber Synology lässt ihre Kunden “im Regen stehen”!

Einige Beispiele von Problemen der letzten Jahre, die ich gegenüber Synology reklamiert habe, die aber bis heute nicht beseitigt sind: Continue reading Nie wieder Synology!

Stop Windows from waking up from Sleep for Updates

Since I have Windows 10 on my PC, I have a very annoying behavior, namely that Windows wakes up from sleep in the middle of the night to perform a reboot to install updates.

There is many “hacks” on the Internet how to disable this, but the only “proper” way seems to be by defining a Group Policy:

  • Run Group Policy Editor: gpedit.msc
  • Open branch Computer Configuration\Administrative Templates\Windows Components\Windows Update\
  • Set node Enabling Windows Update Power Management to automatically wake up the system to install scheduled updates to Disabled

This should stop your PC from resuming from sleep to install updates.

Please let me know if this helped.

Monitoring Microsoft SNDS Status

If you operate a mail server, you should be aware of its “reputation,” because a bad reputation can give you issues sending email to certain recipients.

Microsoft operate a set of services called “Smart Network Data Services (SNDS)” to protect their own email services. If they see spam or other “malicious” activity from your address space, they might put you on a blacklist, and based on that reject email from you. It is easy to register yourself so that you can query the status of your IP address space. Just visit the above site and get started.

I created a quick’n’dirty monitoring script for Nagios to monitor the status of my IP address space in SNDS. Whenever there is data for one of my IP addresses, this script will return a WARNING status, so that I can look into it.

The script looks like follows:

#!/bin/bash

URL='https://postmaster.live.com/snds/ipStatus.aspx?key=12345678-1234-1234-1234-0123456789ab'

content="$(curl -s $URL)"
size=${#content}

if [ $size -gt 0 ]; then
    echo "WARNING:SNDS status seems to be UNHEALTHY"
    exit 1
fi

echo "OK:SNDS status is OK"
exit 0

You also need command and service definitions in Nagios as follows:

define command{
        command_name    check_snds
        command_line    /usr/local/lib/nagios/plugins/check_snds
}

define service {
        host_name                       my_host
        service_description             SNDS
        check_command                   check_snds
        use                             generic-service-internal
        notification_interval           0 ; set > 0 if you want to be renotified
}

Now, Nagios will monitor the “reputation” of your address space for you.