Archiv ‘IT’

Sonntag, 19. Januar 2020

Signal-Werte meiner Ubiquiti UF-SM-1G-S

Kürzlich hat ein Bekannter ein zweites Stockwerk mit Netzwerkverkabelung erschlossen. Hierzu haben wir nicht Ethernet Cat6 gewählt, sondern wegen der Grösse der Lehrrohre auf Glasfaser gesetzt.

Dies bedingt leider aber auch, dass an beiden Enden des Glasfasers SFP-Module verwendet werden müssen, die die Lichtwellen auf Ethernet konvertieren.

Ich habe mich auf der einen Seite für einen gebrauchten Ubiquiti Unifi Switch US-8-150W entschieden, auf der anderen Seite ein bei mir nach Fiber7-Tests unbenutzt herumliegender TP-Link MC220L, der im Modus Auto mit Ethernet auf einen Ubiquiti Unifi Switch US-8-60W gepatcht ist. Als SFP-Module verwende ich beidseitig Ubiquiti UF-SM-1G-S. Als Kabel hat der Bekannte ein Lightwin LWL-Patchkabel LC/APC-LC, Singlemode, Simplex, 15m gezogen.

Aktuell erreiche ich mit diesem Setup auf Seite des US-8-150W folgende Signal-Werte:

  • Output Pwr. -6.03 dBm
  • Input Pwr. -8.57 dBm

Das SFP-Modul ist 47 Grad Celsius warm, die Spannung beträgt 3.284 Volt und der Strom beträgt 31.890 mA. Diese Infos kann man allesamt in Echtzeit über die UniFi Controller-Software auslesen.

Leider habe ich keine Ahnung, ob diese Werte gut oder schlecht sind …

Tags: , , , , , , , , , ,
Labels: IT

1 Kommentar | neuen Kommentar verfassen

Sonntag, 12. Januar 2020

Kabelmodem direkt nach dem Verstärker anschliessen? Schlechte Idee.

Ein Bekannter plant derzeit, die Stockwerke seiner Immobilie mit Ethernet- oder Glasfaser-Kabeln zu erschliessen.

Da hatte ich eine zündende Idee: Da der Bekannte upc cablecom-Kunde ist, könnte man nach der Verkabelungsaktion das Kabelmodem von der Stube im 1. OG in den Keller zügeln, wo der Verstärker angebracht ist. Ich erhoffte mir davon höhere Bandbreiten beim Up- und Download, da ich der Qualität der Verkabelung vom Verstärker zur Stube nicht traue. Je näher das Modem am Verstärker ist, desto weniger leistungsschwächende Interferenzen erhoffte ich mir.

Nachdem das Modem zum Verstärker gezügelt worden wäre, hätte man nur noch ein Netzwerkkabel vom Kabelmodem zum Stockwerks-Switch ziehen müssen und die Bewohner wären in den Genuss schnellerer Bandbreiten gekommen.

Falsch gedacht. Eine kurze Google-Recherche lotste mich auf folgende Forumsdiskussion:

Einfach so an den Verstärker anschließen geht nicht. Das Modem ist von genau definierten Pegelwerten abhängig, d.h. Deine vom Techniker gesetzte Dose wurde eingemessen. Bei dieser Einmessung fanden das zur Dose führende Kabel und die Dose selbst Berücksichtigung.

[…] [Die Installation einer neuen Kabeldose] sollte jemand machen der Ahnung von Kabelanlagen, Dämpfungen und Rückkanal hat.

Quelle: Kabelmodem direkt mit dem UM-Gerät im Keller verbinden

Tags: , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Montag, 16. Dezember 2019

Netflix mit zehntausenden DNS-Queries pro Tag von meinem Sony KD-55AF8

Seit ein paar Monaten steht in unserer Wohnung der erste richtig „smarte“ TV, ein Sony KD-55AF8, auf welchem mittlerweile Android TV 8.0 installiert ist.

Seit gestern analysiere ich die DNS-Queries, die von Netzwerkgeräten im LAN an den lokalen DNS-Forwarder gestellt werden sowohl quantitativ (welche Domains werden am meisten aufgelöst, welches Gerät setzt die meisten Queries ab und in welcher Stunde des Tages gibt es die meisten Queries) sowie qualitativ (werden von SANS als Suspicious eingestufte Domains aufgelöst, was ein Zeichen für Malware-Befall sein könnte). Ich war nicht schlecht überrascht, dass ein TV-Gerät, welches allerhöchsten zwei von 24 Stunden im Tag „läuft“, der Spitzenreiter aller Queries ist. Ich zählte innerhalb von 24 Stunden sage und schreibe 90’498 Queries. Gefolgt wurde der TV vom Server selber, auf welchem der DNS-Server läuft mit 72’411 Queries. Auf Platz drei dann ein Client mit noch 7’162 Queries.

Heute nun nahm mich Wunder, was zum Teufel der TV ständig abzufragen hat. Hier das Resultat der Analyse der named-Logs vom Vortag (10.1.2.3 ist die (fiktive) IPs meines TVs):

$ cat queries.log.1 | grep 10.1.2.3 | cut -d "(" -f 2 | cut -d ")" -f 1 | sort | uniq -c | sort -rn
  13052 cdn-0.nflximg.com
   9112 nrdp51-appboot.netflix.com
   8777 api-global.netflix.com
   8564 uiboot.netflix.com
   8487 ichnaea.netflix.com
   8332 customerevents.netflix.com
   8262 nrdp.nccp.netflix.com
   6970 secure.netflix.com
   6886 nrdp.prod.ftl.netflix.com
   3115 push.prod.netflix.com
   1556 occ-0-593-769.1.nflxso.net
   1284 clients3.google.com
   1220 connectivitycheck.gstatic.com
   1196 www.google.com
   1195 mtalk.google.com
    994 nrdp52-appboot.netflix.com
    324 events.cid.samba.tv
    162 us.edge.bamgrid.com
    142 watch.product.api.espn.com
    118 clients4.google.com
    109 androidtvchannels-pa.googleapis.com
    105 footprints-pa.googleapis.com
     91 fling.cid.samba.tv
     83 www.youtube.com
     52 mdh-pa.googleapis.com
     41 clientservices.googleapis.com
     37 www.googleapis.com
     35 play.googleapis.com
     34 platform.cid.samba.tv
     28 android.googleapis.com
     13 www.gstatic.com
     12 youtubei.googleapis.com
     10 static.doubleclick.net
      7 www.netflix.com
      7 android.clients.google.com
      6 api-cdn.arte.tv
      5 lh3.googleusercontent.com
      5 antv-26-sony-bravia4kgbatv3-414000300.api.amazonvideo.com
      4 sdk.hockeyapp.net
      4 middleware.7tv.de
      4 devices.ted.com
      4 cdn-gl.imrworldwide.com
      4 android.googleapis.com
      3 zdf-cdn.live.cellular.de
      3 geoloc.arte.tv
      3 geocheck.sim-technik.de
      3 config.ioam.de
      3 cdn.meta.ndmdhs.com
      3 bam-sdk-configs.bamgrid.com
      2 sdk.imrworldwide.com
      2 api.meta.ndmdhs.com
      1 www.sony.net
      1 www.sony-asia.com
      1 voledevice-pa.googleapis.com
      1 update.biv.sony.tv
      1 time.android.com
      1 static-cdn.arte.tv
      1 sportscenter.api.espn.com
      1 secure.espncdn.com
      1 safebrowsing.googleapis.com
      1 r4---sn-1gieen7e.gvt1.com
      1 people-pa.googleapis.com
      1 ocsp.int-x3.letsencrypt.org
      1 metadata.erabu.sony.tv
      1 log.core.cloud.vewd.com
      1 isrg.trustid.ocsp.identrust.com
      1 images.erabu.sony.tv
      1 fls-na.amazon.com
      1 cloudfront.xp-assets.aiv-cdn.net
      1 cert-cdn.meta.ndmdhs.com
      1 cdn.espn.com
      1 browserjs-legacy.core.cloud.vewd.com
      1 broadband.espn.com
      1 bravia-cfgdst-ore-pro.bda.ndmdhs.com
      1 bdcore-apr-lb.bda.ndmdhs.com
      1 app-measurement.com
      1 api.erabu.sony.tv
      1 api.auth.adobe.com
      1 ajax.googleapis.com

Netflix führt die Statistik unangefochten an:

$ cat queries.log.1 | grep 10.1.2.3 | cut -d "(" -f 2 | cut -d ")" -f 1 | sort | uniq -c | sort -rn | grep -i "netflix\|nflx"
  13052 cdn-0.nflximg.com
   9112 nrdp51-appboot.netflix.com
   8777 api-global.netflix.com
   8564 uiboot.netflix.com
   8487 ichnaea.netflix.com
   8332 customerevents.netflix.com
   8262 nrdp.nccp.netflix.com
   6970 secure.netflix.com
   6886 nrdp.prod.ftl.netflix.com
   3115 push.prod.netflix.com
   1556 occ-0-593-769.1.nflxso.net
    994 nrdp52-appboot.netflix.com
      7 www.netflix.com

Von den täglich über 90’000 Queries entfallen über 90 Prozent auf Netflix-Domains:

$ cat queries.log.1 | grep 10.1.2.3 | grep -i "netflix\|nflx" | wc -l
84114

Dabei schauen wir — wenn überhaupt — mit der Netflix-App auf dem Apple TV 4K mit einer anderen IP Netflix, und nie mit der Android TV App.

Netflix, shame on you! Die Frage, wieso die Netflix-App das macht, konnte ich bis jetzt noch nicht beantworten, werde es hier aber nachtragen, sollte ich es erfahren.

Tags: , , , , , , , , , , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 3. September 2019

MacTeX-Download extrem langsam

Gestern wollte ich mir MacTeX 2019 herunterladen (veröffentlicht im Mai 2019). Das macOS Installations-Package für die LaTeX-Distribution ist mittlerweile sagenhafte 3.9 GB gross.

Als ich den Link tug.org/cgi-bin/mactex-download/MacTeX.pkg auf der offiziellen Download-Seite anklickte, tröpfelten die Daten nur Kilobyte-weise rein.

Nach etwas Recherche (einen Torrent-Link fand ich auf die Schnelle leider nicht) stiess ich dann auf die Homepage der Distribution auf CTAN. Dort wird stattdessen der Link mirrors.ctan.org/systems/mac/mactex/MacTeX.pkg angeboten, der per Zufall (oder nach geographischen Kriterien?) einen Mirror zum Download auswählt. Über den gestern Abend gewählten Mirror erreichte ich dann Download-Geschwindigkeiten von bis zu 10 MB/s und hatte das Paket dementsprechend in ein paar Minuten heruntergeladen. Der Web-Download über den offiziellen Link war zu dem Zeitpunkt erst bei 189 MB angelangt …

Tags: ,
Labels: Apple, IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 21. Juli 2019

pixelserver-tls läuft nicht unter Debian 10 „Buster“

Mittels eines „manuellen“ Canary-Releases habe ich vor einer Woche einen meiner Linux-Server hier im Haus von Debian 9 „Stretch“ auf Debian 10 „Buster“ migriert.

Wie es zu erwarten war, klappte das nicht ganz ohne Schluckauf. Beispielsweise schaltet sich der Monitor meines Lenovo ThinkPads X201 (P/N 3626GN7) nicht mehr automatisch aus. Leider habe ich die Lösung im Internet noch nicht gefunden.

Das beunruhigendste Problem war aber folgende Fehlermeldung von monit, die nach der Neukompilierung von pixelserv-tls mit Debian 10 „Buster“ in meinem Postfach landete:

Connection failed Service pixelserv-tls 

	Date:        Mon, 15 Jul 2019 22:44:25
	Action:      restart
	Host:        ADBLOCKER
	Description: failed protocol test [HTTP] at [10.1.2.3]:443 [TCP/IP TLS] -- SSL connection error: error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error

Your faithful employee,
Monit

Der Aufruf der Statusseite unter http://10.1.2.3/servstats funktionierte ebenfalls nicht.

Am letzten Freitag fand ich nun etwas Zeit, um das Problem genauer anzuschauen.

Software-Versionen

pixelserv-tls hat seit Monaten keine Anpassung mehr erfahren — beim Abgleich meiner Sourcen mit denjenigen auf GitHub gab es nur in cert.c eine Anpassung, die ich einspielte, aber eigentlich nichts mit dem hier beschriebenen Problem zu tun hat.

Eine Ursache für das Problem war aber, dass die OpenSSL-Library, gegen welche pixelserv-tls kompiliert wird, aktualisiert worden war. Auf einem System mit Stretch (stable) waren installiert …

# dpkg --list | grep -i ssl
ii  libcurl3:amd64                       7.52.1-5+deb9u9                   amd64        easy-to-use client-side URL transfer library (OpenSSL flavour)
ii  libcurl4-openssl-dev:amd64           7.52.1-5+deb9u9                   amd64        development files and documentation for libcurl (OpenSSL flavour)
ii  libflac8:amd64                       1.3.2-1                           amd64        Free Lossless Audio Codec - runtime C library
ii  libgnutls-openssl27:amd64            3.5.8-5+deb9u4                    amd64        GNU TLS library - OpenSSL wrapper
ii  libio-socket-ssl-perl                2.044-1                           all          Perl module implementing object oriented interface to SSL sockets
ii  libnet-smtp-ssl-perl                 1.04-1                            all          Perl module providing SSL support to Net::SMTP
ii  libnet-ssleay-perl                   1.80-1                            amd64        Perl module for Secure Sockets Layer (SSL)
ii  libssl-dev:amd64                     1.1.0j-1~deb9u1                   amd64        Secure Sockets Layer toolkit - development files
ii  libssl-doc                           1.1.0j-1~deb9u1                   all          Secure Sockets Layer toolkit - development documentation
ii  libssl1.0.0:amd64                    1.0.1t-1+deb8u6                   amd64        Secure Sockets Layer toolkit - shared libraries
ii  libssl1.0.2:amd64                    1.0.2r-1~deb9u1                   amd64        Secure Sockets Layer toolkit - shared libraries
ii  libssl1.1:amd64                      1.1.0j-1~deb9u1                   amd64        Secure Sockets Layer toolkit - shared libraries
ii  mitmproxy                            0.18.2-6                          all          SSL-capable man-in-the-middle HTTP proxy
ii  openssl                              1.1.0j-1~deb9u1                   amd64        Secure Sockets Layer toolkit - cryptographic utility
ii  perl-openssl-defaults:amd64          3                                 amd64        version compatibility baseline for Perl OpenSSL packages
ii  python-backports.ssl-match-hostname  3.5.0.1-1                         all          Backport of the Python 3.5 SSL hostname checking function
ii  python-brotli                        0.5.2+dfsg-2                      amd64        lossless compression algorithm and format (Python 2 version)
ii  python-certifi                       2016.2.28-1                       all          root certificates for validating SSL certs and verifying TLS hosts
ii  python-openssl                       16.2.0-1                          all          Python 2 wrapper around the OpenSSL library
ii  python-passlib                       1.7.0-2                           all          comprehensive password hashing framework
ii  python-service-identity              16.0.0-2                          all          Service identity verification for pyOpenSSL (Python 2 module)
ii  ssl-cert                             1.0.39                            all          simple debconf wrapper for OpenSSL

… auf dem neuen System war hingegen installiert:

# dpkg --list | grep -i ssl
ii  libcurl4:amd64                 7.64.0-4                     amd64        easy-to-use client-side URL transfer library (OpenSSL flavour)
ii  libgnutls-openssl27:amd64      3.6.7-4                      amd64        GNU TLS library - OpenSSL wrapper
ii  libio-socket-ssl-perl          2.060-3                      all          Perl module implementing object oriented interface to SSL sockets
ii  libnet-smtp-ssl-perl           1.04-1                       all          Perl module providing SSL support to Net::SMTP
ii  libnet-ssleay-perl             1.85-2+b1                    amd64        Perl module for Secure Sockets Layer (SSL)
ii  libssl-dev:amd64               1.1.1c-1                     amd64        Secure Sockets Layer toolkit - development files
ii  libssl-doc                     1.1.1c-1                     all          Secure Sockets Layer toolkit - development documentation
ii  libssl1.0.0:amd64              1.0.1t-1+deb8u7              amd64        Secure Sockets Layer toolkit - shared libraries
ii  libssl1.1:amd64                1.1.1c-1                     amd64        Secure Sockets Layer toolkit - shared libraries
ii  libzstd1:amd64                 1.3.8+dfsg-3                 amd64        fast lossless compression algorithm
ii  mitmproxy                      4.0.4-5                      all          SSL-capable man-in-the-middle HTTP proxy
ii  openssl                        1.1.1c-1                     amd64        Secure Sockets Layer toolkit - cryptographic utility
ii  perl-openssl-defaults:amd64    3                            amd64        version compatibility baseline for Perl OpenSSL packages
ii  python3-brotli                 1.0.7-2                      amd64        lossless compression algorithm and format (Python 3 version)
ii  python3-certifi                2018.8.24-1                  all          root certificates for validating SSL certs and verifying TLS hosts (python3)
ii  python3-openssl                19.0.0-1                     all          Python 3 wrapper around the OpenSSL library
ii  python3-passlib                1.7.1-1                      all          comprehensive password hashing framework
ii  ssl-cert                       1.0.39                       all          simple debconf wrapper for OpenSSL

Relevant ist das Paket libssl-dev — auf Stretch war die Library 1.1.0j-1~deb9u1, in Buster 1.1.1c-1. Gegen diese kompiliert pixelserv-tls.

TLSv1.3?

Um Probleme mit TLSv1.3 auszuschliessen, hackte ich util.h und stellte das Script so ein, dass TLSv1.3-Support nie einkompiliert wird:

...
# ifdef TLS1_3_VERSION
#   define FEAT_TLS1_3  " no_tls1_3"
# else
#   define FEAT_TLS1_3  " no_tls1_3"
# endif
...

Leider half dies nichts zur Lösung des Problems.

Indem man pixelserv-tls ausführt, erfährt man, ob TLSv1.3 einkompiliert ist oder nicht:

$ pixelserv-tls --help
pixelserv-tls 2.2.1 (compiled: Jul 15 2019 22:34:41 flags: tfo tls1_3)
...

Respektive:

$ pixelserv-tls --help
pixelserv-tls 2.2.1 (compiled: Jul 15 2019 22:48:04 flags: tfo no_tls1_3)
...

Dasselbe erfährt man auch in error.log, wenn pixelserv-tls gestartet wird:

...
Jul 19 19:52:46 localhost pixelserv-tls[28352]: pixelserv-tls 2.2.1 (compiled: Jul 19 2019 19:51:13 flags: tfo no_tls1_3) options: 10.1.2.3 -u root -p 80 -k 443 -l 5 -z /tmp/pixelserv
...

AppArmor?

Zuerst vermutete ich ein Problem mit AppArmor, welches in Debian 10 out-of-the-box aktiviert ist und läuft. Doch nachdem ich mich ein wenig eingelesen hatte, war mir klar, dass AppArmor nur dann zur Anwendung kommt, wenn ein entsprechendes Applikationsprofil erstellt wurde. Auch scheint es keine Standardeinstellungen zu geben, die auf alle Prozesse angewendet werden.

Log-Analyse

Basierend auf den lokalen Einstellungen loggt pixelserv-tls mehr oder weniger hilfreiche Informationen in das syslog. Auf Grund der von mir temporär gewählten Kommandozeilenoption -l 4 („4“ steht für den Loglevel „info“) las ich dort:

$ tail -f /var/log/error.log
...
Jul 19 19:04:00 localhost pixelserv-tls[22361]: create_child_sslctx: cannot find or use $CERTDIR/_.google-analytics.com
Jul 19 19:04:00 localhost pixelserv-tls[22361]: tls_clienthello_cb: fail to create sslctx or cache _.google-analytics.com
...

Fragezeichen über Fragezeichen — haben wir ein Problem mit den Zertifikatsdateien?

Datei- und Verzeichnisberechtigungen

Dann vermutete ich Probleme beim Lesen und Schreiben der Zertifikate, obwohl ich an der Ordnerstruktur und den Ordner- und Dateiberechtigungen nichts geändert hatte. Sowohl das Starten von pixelserv-tls mit der Option -u root (normalerweise läuft pixelserv-tls unter „nobody“ — Sicherheitstechnisch eine sehr weise Einstellung, da die Software wie auch OpenSSL Schwachstellen aufweisen könnten, die dann jeder im lokalen Netzwerk ausnützen könnte) als auch das Verschieben des Zertifikatsordner nach /tmp/pixelserv lösten das Problem nicht.

Mit strace die Syscalls auf das Dateisystem anschauen

Auch die Verwendung von strace — einem Werkzeug, das ich nur bei ganz hartnäckigen Problemen zur Anwendung kommen lasse, zeigte keinen Hinweis, der mich auf die richtige Fährte gebracht hätte. Was ich lernte: Mittels der Option -p kann man sich bei strace in einen bereits laufenden Prozess „einklinken“. Hier das Resultat

# strace -p %PID%
...
select(8, [5 6 7], NULL, NULL, NULL)    = 1 (in [6])
accept(6, {sa_family=AF_INET, sin_port=htons(64242), sin_addr=inet_addr("10.0.1.102")}, [16]) = 9
fcntl(9, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(9, F_SETFL, O_RDWR)               = 0
setsockopt(9, SOL_TCP, TCP_NODELAY, [1], 4) = 0
setsockopt(9, SOL_SOCKET, SO_RCVTIMEO, "\0\0\0\0\0\0\0\0\360I\2\0\0\0\0\0", 16) = 0
getsockname(9, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("10.1.2.3")}, [128->16]) = 0
read(9, "\26\3\1\0\353", 5)             = 5
read(9, "\1\0\0\347\3\3n\277\307zl\26\2155A\257@\nFK\272\326x:Z\320\32:\347\32\2\217"..., 235) = 235
stat("/usr/local/apps/pixelserv/certs/_.optimizely.com", {st_mode=S_IFREG|0644, st_size=1596, ...}) = 0
openat(AT_FDCWD, "/usr/local/apps/pixelserv/certs/_.optimizely.com", O_RDONLY) = 10
fstat(10, {st_mode=S_IFREG|0644, st_size=1596, ...}) = 0
read(10, "-----BEGIN CERTIFICATE-----\nMIIB"..., 4096) = 1596
close(10)                               = 0
getpid()                                = 23461
sendto(3, "<27>Jul 19 19:21:47 pixelserv-tl"..., 131, MSG_NOSIGNAL, NULL, 0) = 131
getpid()                                = 23461
sendto(3, "<27>Jul 19 19:21:47 pixelserv-tl"..., 109, MSG_NOSIGNAL, NULL, 0) = 109
write(9, "\25\3\3\0\2\2P", 7)           = 7
getpid()                                = 23461
sendto(3, "<28>Jul 19 19:21:47 pixelserv-tl"..., 141, MSG_NOSIGNAL, NULL, 0) = 141
shutdown(9, SHUT_RDWR)                  = 0
close(9)

Da sah alles Bestens aus — das Zertifikat kann gelesen werden, wie die erste Zeile read(10, "-----BEGIN CERTIFICATE-----\nMIIB"..., 4096) = 1596
verdeutlicht.

Quellcode-Analyse

Als nächstes muss man sich in solchen hartnäckigen Fällen mit dem Source-Code auseinandersetzen. Ich durchsuchte das GitHub-Repository nach folgender Fehlermeldung: „cannot find or use“. Fündig wurde ich dazu in cert.c, ab Zeile 814:

...
if(SSL_CTX_use_certificate_file(sslctx, full_pem_path, SSL_FILETYPE_PEM) <= 0
       || SSL_CTX_use_PrivateKey_file(sslctx, full_pem_path, SSL_FILETYPE_PEM) <= 0)
    {
        SSL_CTX_free(sslctx);
        log_msg(LGG_ERR, "%s: cannot find or use %s\n", __FUNCTION__, full_pem_path);
        return NULL;
    }
...

Na toll! Die Log-Meldung wird somit generiert, wenn die OpenSSL-nativen-Funktionen SSL_CTX_use_certificate_file() oder SSL_CTX_use_PrivateKey_file() einen Wert zurückgeben, der kleiner gleich 0 ist. Gemäss Dokumentation der quelloffenen Library meldet ein Rückgabewert von 1, dass die Funktion erfolgreich ausgeführt wurde.

Quellcode hacken

Ich bin kein C-Programmierer, aber mir gefiel die Programmlogik aus folgenden Gründen nicht:

  1. Wenn eine der beiden Funktionen einen Fehler zurückgibt, bricht der Programmcode ab. Schön, dass man den Code damit komprimiert hat, aber beim Debugging wäre es noch nett zu wissen, welche der beiden Funktionen den Fehler generiert.
  2. Die Fehlermeldung "%s: cannot find or use %s\n" mit den zwei Variablen "Funktion" sowie dem Pfad zum Zertifikat sagt rein gar nichts darüber, was denn nun konkret schiefgegangen ist.
  3. <= 0 empfinde ich als den falschen Ansatz: Ich würde stattdessen prüfen, ob der Rückgabewert NICHT 1 entspricht (an dem sind wir interessiert).

Um dem Problem näher zu kommen war es deshalb nötig, dass ich selbst Hand an den Code anlegte, die Logik entzwirnte sowie die in OpenSSL intern vorhandenen detaillierten Fehlermeldungen in das Log ausgab. Natürlich fand ich über etwas Googlen heraus, wie man OpenSSL diese Fehlermeldung entlockt. Dies führte zu folgendem Code:

...
    if(!SSL_CTX_use_certificate_file(sslctx, full_pem_path, SSL_FILETYPE_PEM)) {
        log_msg(LGG_ERR, "%s: SSL_CTX_use_certificate_file error for file %s with error %s\n", __FUNCTION__, full_pem_path, ERR_error_string( ERR_get_error(), NULL ));
    }
    if(!SSL_CTX_use_PrivateKey_file(sslctx, full_pem_path, SSL_FILETYPE_PEM)) {
        log_msg(LGG_ERR, "%s: SSL_CTX_use_PrivateKey_file error for file %s with error %s\n", __FUNCTION__, full_pem_path, ERR_error_string( ERR_get_error(), NULL ));
    }
...

Die wahre Fehlermeldung

Neu kompiliert, installiert und gestartet, dann die Werbeschleuder SPIEGEL Online angesurft und das Log überprüft:

$ tail -f /var/log/error.loa
...
create_child_sslctx: SSL_CTX_use_certificate_file error for file /tmp/pixelserv/_.ioam.de with error error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small
...

"ee key too small"? Now we're talking! Eine erneute Google-Suche ergab, dass sich OpenSSL 1.1.1 (im Gegensatz zu 1.1.0) weigert, ein Zertifikat zu verarbeiten, dessen RSA-Schlüssellänge kleiner als 2048 Bit ist.

Die Lösung des Problems

Ich nahm deshalb folgende zwei Anpassungen vor:

Zuerst einmal generierte ich eine neue ca.key mit einer Schlüssellänge von 2048 Bits:

$ openssl genrsa -out $CERTDIR/ca.key 2048

Anschliessend passte ich auch noch cert.c an, da dort die mittlerweile als schwach erachtete Schlüssellänge (1024) hartkodiert ist:

...
if (RSA_generate_key_ex(rsa, 2048, e, NULL) < 0)
...

Seit ich pixelserv-tls ein letztes Mal neu kompiliert und installiert habe, funktioniert das Schwarze Loch für alle Arten von Web-basierten Trackern wieder einwandfrei.

Verifikation

Überprüfen kann man das ... natürlich auch mit openssl auf einem separaten Client:

pixelserv-tls funktioniert nicht (richtig)

$ openssl s_client -connect www.googleadservices.com:443
CONNECTED(00000003)
140735858492360:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error:s23_clnt.c:802:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 308 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1563537109
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

pixelserv-tls funktioniert (richtig)

Und jetzt:

CONNECTED(00000003)
depth=1 CN = Pixelserv CA
verify error:num=19:self signed certificate in certificate chain
---
Certificate chain
 0 s:/CN=10.1.2.3
   i:/CN=Pixelserv CA
 1 s:/CN=Pixelserv CA
   i:/CN=Pixelserv CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MII...=
-----END CERTIFICATE-----
subject=/CN=10.1.2.3
issuer=/CN=Pixelserv CA
---
No client certificate CA names sent
Peer signing digest: SHA256
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2148 bytes and written 434 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: F66E6966BF7CE8F970AF4834A1CC45FE396D1F7B041F512CA5B3F65419EACD24
    Session-ID-ctx: 
    Master-Key: 7EE1C54219A4CABF0BEB73BB420C93DD4F51F5F319897937137B9C1093045B4EB91B0FD50F30154DF5A7D18AD95A493C
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 3600 (seconds)
    TLS session ticket:
    0000 - e8 63 17 bb 31 c0 91 7d-95 eb f8 b4 78 dc a6 89   .c..1..}....x...
    0010 - be 14 43 2c ac cc 4c dd-f3 e9 9d f5 cb 36 46 a4   ..C,..L......6F.
    0020 - c6 9a 67 7c fb 83 a1 a6-6d 74 6b 62 4e b5 60 33   ..g|....mtkbN.`3
    0030 - 8b 1b 5f 1f cf ba c6 bf-73 c0 8a 7d 31 db 8a 75   .._.....s..}1..u
    0040 - 81 8b b3 c3 e5 76 1e 34-c3 3d 2e 11 e4 58 a3 fc   .....v.4.=...X..
    0050 - 73 5b 2e 9c 13 f5 64 4e-c3 26 10 98 96 e1 64 aa   s[....dN.&....d.
    0060 - ce 41 aa cd 54 68 12 a1-87 10 98 cc f0 e5 e9 d9   .A..Th..........
    0070 - de ec e6 2e 83 80 8f 51-71 ff 07 eb a7 b2 66 ae   .......Qq.....f.
    0080 - ad b5 44 c0 47 06 eb b7-5f 19 c2 74 5d 1f 47 20   ..D.G..._..t].G 
    0090 - 5d 93 0f 57 c4 ee 86 b7-7e 7f e3 2a ed 57 27 43   ]..W....~..*.W'C

    Start Time: 1563745313
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---

Das Problem habe ich nun auch im GitHub Issue-Tracker des Projekts beschrieben ("Use 2048-bit RSA key to make pixelserv-tls work on Debian 10 "Buster""). Eigentlich hätte ich den Patch ja auch gleich selber als Pull Request hochladen können, doch diese Funktion von Git verstehe ich immer noch nicht wirklich richtig ... hoffen wir, dass der Maintainer die Ursache des Problems deshalb selber bald beseitigt.

Tags: , , , , , , , , ,
Labels: IT

1 Kommentar | neuen Kommentar verfassen

Dienstag, 16. Juli 2019

Somfy RTS-Storen von einem PC aus steuern

Vor einiger Zeit hat mir ein Bekannter mit Elektriker-Ausbildung gezeigt, dass unsere Wandschalter zum Steuern der Fensterstoren (Lamellen) mit einem Schraubenzieher ganz einfach aus der Fassung zu hebeln sind. Im Grunde ist es nur eine Platine, gespiesen von einer Flachbatterie, mit drei Knöpfen, die über Funksignale die Motoren unserer Lamellen steuern.

image-8445

image-8446

Dem Schalter ist zu entnehmen, dass es sich um ein Produkt des französischen Herstellers Somfy handelt.

Nachdem ich den Schalter von der Wand entfernt hatte, konnte ich auf dem Rücken der Platine die genaue Typenbezeichnung unserer Storen lesen: Somfy Centralis RTS (Handbuch).

Daraufhin machte ich mich auf die Suche nach Handbüchern und Steuerungen.

Rasch war nach der Lektüre des Handbuchs klar, dass sich die Motoren der Storen mit weiteren (offiziellen) Schaltern paaren lassen. Hierzu dient der Knopf „PROG“ auf der Rückseite bereits verbundener Schalter, die einen Motor in den „Paarungsmodus“ setzen.

Auf Ricardo ersteigerte ich mir deshalb kurzerhand zwei weitere solche Schalter mit der Idee, einen davon auf dem Nachttisch zu platzieren, und den anderen portabel zu belassen.

Doch das ist heutzutage, im Zeitalter der Heimautomation, nur die halbe Miete: Diese Dinger muss man von einem PC aus steuern können, denn dann kann man nämlich nette Automationen bauen. Beispielsweise die Storen bei Sonnenaufgang hochfahren, bei Sonnenuntergang herunterfahren, oder wenn es zu heiss wird (bedingt Temperatursensoren auf dem Fenstersims) herunterfahren, damit sich die Zimmer nicht unnötig aufheizen.

USB-Fernbedienung eines Drittherstellers

Nach etwa einer Stunde Google stiess ich auf das Gerät RFXtrx433XL USB HA controller des Herstellers RFXCOM, welche auf dem auch von Somfy verwendeten Frequenzband 433 MHz sendet und empfängt.

Ohne lange zu überlegen habe ich mir dann über den Schweizer Online-Shop Swiss Domotique ein Exemplar dieses Geräts geleistet; heute Dienstag ist es nun per Paketpost angekommen.

USB-Fernbedienung mit den Somfy Motoren verbinden

Hierzu ist leider ein Windows-PC nötig, auf welchem man die offizielle Software RFXmngr installiert (Download). Sobald das geschehen ist, verbindet man die USB-Fernbedienung mit dem Computer, startet das Programm und verbindet sich auf die Fernbedienung.

Im besten Fall füllt sich das Log im gelben Bereich des Tools bereits jetzt von alleine, wenn der Empfänger Signale in der Luft auffängt. Bei mir war dies der Fall; jemand in der Nachbarschaft scheint einen Oregon Scientific Temperatursensor zu betreiben:

16.07.2019 07:44:06:777
Packettype    = TEMP_HUM
subtype       = TH1 - THGN122/123/132,THGR122/228/238/268
                channel 1
Sequence nbr  = 0
ID            = D401 decimal:54273
Temperature   = 23.8 °C
Humidity      = 22
Status        = Dry
Signal level  = 5  -80dBm
Battery       = Low

Um die drei Motoren in unserer Mietwohnung zu paaren, bin ich der französischen, bebilderten Anleitung auf einem Blog gefolgt. Ich habe die Storen jeweils ganz hochgefahren, denn würde mit dem Paaren etwas komplett schief laufen und der bestehende Schalter auch die Verbindung zum Motor verlieren, würde jedenfalls immer noch Tageslicht in den Raum fallen. Anschliessend habe ich mit einem flachen Schraubenzieher den Schalter aus der Fassung rausgehebelt, damit ich Zugang zum jeweiligen PROG-Knopf besass. Als nächstes wechselte ich in der Software auf das Tab RFY, stellte dort eine frei gewählte fünfstellige ID sowie den einstelligen Unit Code ein (diese Zahlen unbedingt aufschreiben, mitsamt dem zugewiesenen Motor), setzte das Dropdown auf Program. Nun drückte ich den PROG-Knopf, bis sich die Storen kurz bewegten — das Signal, dass der Motor nun für die Paarung mit einer zusätzlichen Fernbedienung bereit ist. Anschliessend drückte ich in der Software auf Transmit, worauf sich die Storen noch einmal kurz bewegten. Die Paarung war somit abgeschlossen, und ab sofort konnte ich über das Dropdown in der Software Kommandos an die Store übermitteln.

image-8447

Ich entschied mich, für jeden Motor eine eigenständige ID sowie einen Unit Code auszuwählen — denn, so denke ich mir, mit einem Script kann ich ja problemlos alle Storen in Serie herunter- oder hochfahren. Mindestens einen der Original Somfy-Schalter, welche ich auf Ricardo ersteigert habe, werde ich hingegen mit allen drei Motoren gleichzeitig paaren und so mittels eines Knopfdrucks alle Storen in der Wohnung hoch- oder herunterfahren.

Programmierung

Um meine Storen zu steuern möchte ich aber a) keinen Windows-PC in meinem Netzwerk am Laufen haben und b) auch nicht ein Win32-Software-GUI von RFXCOM verwenden — denn ein GUI ist nicht scriptbar. Somit machte ich mich auf die Suche nach einer Möglichkeit, das USB-Gerät an einen Linux-PC anzuschliessen und dann mit einer Programmiersprache zu steuern.

Fündig wurde ich bei der offiziellen nodejs-Bibliothek des Herstellers selber, freundlicherweise auf Github gehostet: rfxcom/node-rfxcom.

Installiert wird dies — ein funktionierendes nodejs vorausgesetzt — mittels …

# npm install rfxcom

Folgende Minimalvariante eines nodejs-Scripts lässt die Motoren bewegen:

var rfxcom = require('rfxcom');
var rfxtrx = new rfxcom.RfxCom('/dev/ttyUSB1', {debug: true});
var rfy = new rfxcom.Rfy(rfxtrx, rfxcom.rfy.RFY);
rfxtrx.initialise(function () {
    rfy.doCommand('0x00000/0', 'up', function(err, res, sequenceNumber) {
        if (!err) {
            console.log('Action succeeded');
            process.exit(0);
        }
        else {
            console.log('ERROR[' + res + ']: ' + err + ' with sequenceNumber=' + sequenceNumber);
            process.exit(1);
        }
    });
});

Erläuterungen:

  • /dev/ttyUSB1: An welchem USB-Port hängt der RFXtrx433XL? Vgl. auch nachfolgende Erläuterungen mit dmesg
  • 0x00000/0: Die ID und Unit des Motors, getrennt mit einem Slash. Entspricht der ID und der Unit, welche man im Software-GUI bei der Initialisierung eingegeben hat. Bei mir war keine Umrechnung in Hex nötig; einfach so eingeben, wie die Nummer im GUI ausgewählt wurde.
  • up: Das zu sendende Kommando. Im Software-GUI sind alle Kommandos aufgeführt; ich persönlich brauche aber derzeit nur „up“ sowie „down“. In der nodejs-Bibliothek sind die verfügbaren Befehle auch erwähnt (siehe „RfyCommands“).

Um herauszufinden, auf welchem USB-Port das Gerät lauscht, reicht ein Blick in die Ausgabe des Befehls dmesg:

...
[74849.641113] usb 1-1.2: new full-speed USB device number 7 using ehci-pci
[74849.756549] usb 1-1.2: New USB device found, idVendor=0403, idProduct=6015, bcdDevice=10.00
[74849.756556] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[74849.756560] usb 1-1.2: Product: RFXtrx433XL
[74849.756564] usb 1-1.2: Manufacturer: RFXCOM
[74849.756567] usb 1-1.2: SerialNumber: 00000000
[74849.788659] usbcore: registered new interface driver ftdi_sio
[74849.788692] usbserial: USB Serial support registered for FTDI USB Serial Device
[74849.788949] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
[74849.789022] usb 1-1.2: Detected FT-X
[74849.790248] usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB1

Für Nicht-root-Benutzer ausführbar machen

Damit das finale Script auch normale Linux-Benutzer ausführen können, muss man den gewünschten Benutzer noch der Benutzergruppe dialout zuweisen, damit er auf die USB-Schnittstelle zugreifen kann:

# adduser santa dialout

Nächste Schritte

  • Ein Web-Interface bauen, über welches man — bspw. im Bett liegend — die Storen betätigen kann
  • Das Script mit anderen Scripts koppeln, die bspw. bei erhöhter Temperatur am Fenstersims reagieren

Tags: , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 30. Juni 2019

Irgendwas ist am UniFi Firmware 4.0.42.10433 nicht ganz koscher

Bis vor wenigen Wochen hatte ich nie irgendwelche Probleme mit Firmware-Upgrades für UniFi-Produkte. Das hat sich mit Version 4.0.42.10433 geändert: Ich verzeichne mindestens zwei Probleme mit diesem Upgrade.

DHCP funktioniert mit gewissen Geräten nicht mehr

Bei mir macht dieses Update auf einem UniFi AP-AC-Mesh wie auch auf einem UniFi AP-AC-LR im Zusammenspiel mit DHCP-Anfragen Probleme. Das Resultat: Die Geräte sind zwar im Controller sichtbar, können aber keine IP beziehen.

In der Controller-App für iOS sieht man bei solchen Geräten die Warnung:

„DHCP Timeout. Please check that your DHCP server is accessible and properly configured“

image-8417

Die meisten Geräte wie Laptops, Smartphones und Tablets können mit DHCP IPs beziehen; Probleme haben derzeit nur zwei Geräte(typen) gemacht: Ein Canon Selphy sowie ein Industrieboard für einen Wechselrichter. Meine derzeitige Vermutung: Auf diesen Dingern läuft eine ältere Linux-Version und ein älterer DHCP-Client, der irgendwie nicht (mehr) mit Antworten des DHCP-Servers über UniFi-Komponenten klarkommt, oder UniFi blockiert Antworten auf DHCP-Requests dieser Clients aus irgendeinem Grund.

Das zeigt sich daran, dass in den DHCP-Server-Logs unzählige folgende Meldungen auftauchen:

...
Jun 30 18:16:31 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:17:36 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:17:37 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:18:42 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:18:43 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:19:48 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:19:49 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:20:54 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:20:55 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:22:00 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:22:01 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:23:06 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:23:07 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:24:12 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:24:13 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:25:18 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:25:19 DHCPSERVER dhcpd[19637]: DHCPOFFER on 10.1.2.225 to 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
Jun 30 18:26:24 DHCPSERVER dhcpd[19637]: DHCPDISCOVER from 00:00:00:00:00:00 (SELPHY_DHCP_INSTANCE_0) via eth0
...

Syslog geflutet

Der UniFi AP-AC-Mesh an einem Standort brachte meinen ELK-Cluster für das Sammeln von Syslog-Meldungen aus allen Sites fast zum Glühen, nachdem die neue Firmware installiert war und der Access Point neu gebootet hatte.

Das Gerät sendete folgende Meldung 29 Mal pro Sekunde an den Syslog-Server:

<4> Jun 10 16:00:00 unifi.site.domain.local U7MSH,788a20263e00,v4.0.42.10433 kernel: [103146.842183] [wifi1] FWLOG: [105639111] VDEV_MGR_DEBID_DEFINITION_START ( 0x3, 0x40, 0x1, 0x6 )

Sobald ich wieder die alte Firmware (4.0.21.9965) installiert hatte, hörte die Log-Flut auf.

In Kibana ist die Flutwelle gut ersichtlich …

image-8418

… welche sich auch in der CPU-Auslastung wiederspiegelt:

image-8419

Auch Smokeping zeigt, dass das Gerät mit dem neuen Firmware eine deutlich höhere Latenz bei ICMP Ping Requests aufweist:

image-8420

Ein anderer Benutzer hatte dieses Phänomen bereits im März 2019 beobachtet und dies in einem Beitrag im offiziellen Support-Forum kundgetan: WAL_DBGID_SECURITY_ALLOW_DATA and VDEV_MGR_DEBID_DEFINITION_START — leider ohne Lösung.

Um das Problem ohne Downgrade des Firmwares zu beheben, habe ich meine rsyslog-Konfiguration, welche die Meldungen lokal in Empfang nimmt und an ELK weiterleitet, folgendermassen angepasst:

/etc/rsyslog.conf

...
# EMERGENCY 2019-06-10
if $msg contains 'VDEV_MGR_DEBID_DEFINITION_START' then {
    /dev/null
    stop
}

# Send all logs to ELK server
*.* @10.1.2.3:514
...

Tags: , , , , , ,
Labels: IT

1 Kommentar | neuen Kommentar verfassen

Sonntag, 10. März 2019

nmap die offenen Ports einer bestimmten IP anzeigen lassen

Alle Schaltjahre einmal kommt es vor, dass ich eine neue Blackbox in eines meiner Netzwerke hänge und wissen will, was die Hersteller alles für Netzwerk-Services auf dem Gerät betreiben und gegen das LAN freigeschaltet haben.

Solche Services kann man notabene auch gut verwenden, um eine bessere Überwachung mit monit einzurichten (statt einem simplen Ping prüft man beispielsweise, ob der HTTP-Server auch tatsächlich auf HTTP-Requests antwortet).

Am Besten verwendet man dazu nmap, mit folgendem Befehl, um zumal die privilegierte Port-Range abzugrasen:

# nmap -v -sV -O -sS -T5 10.1.2.3
Starting Nmap 7.40 ( https://nmap.org ) at 2019-03-10 12:07 CET
NSE: Loaded 40 scripts for scanning.
Initiating ARP Ping Scan at 12:07
Scanning 10.1.2.3 [1 port]
Completed ARP Ping Scan at 12:07, 0.22s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 12:07
Completed Parallel DNS resolution of 1 host. at 12:07, 0.02s elapsed
Initiating SYN Stealth Scan at 12:07
Scanning 10.1.2.3 [1000 ports]
Discovered open port 53/tcp on 10.1.2.3
Discovered open port 111/tcp on 10.1.2.3
Discovered open port 22/tcp on 10.1.2.3
Discovered open port 80/tcp on 10.1.2.3
Completed SYN Stealth Scan at 12:07, 2.48s elapsed (1000 total ports)
Initiating Service scan at 12:07
Scanning 4 services on 10.1.2.3
Completed Service scan at 12:07, 14.22s elapsed (4 services on 1 host)
Initiating OS detection (try #1) against 10.1.2.3
NSE: Script scanning 10.1.2.3.
Initiating NSE at 12:07
Completed NSE at 12:07, 2.09s elapsed
Initiating NSE at 12:07
Completed NSE at 12:07, 0.01s elapsed
Nmap scan report for 10.1.2.3
Host is up (0.0043s latency).
Not shown: 996 closed ports
PORT    STATE SERVICE  VERSION
22/tcp  open  ssh      OpenSSH 6.7p1 Debian 5+deb8u3 (protocol 2.0)
53/tcp  open  domain
80/tcp  open  ssl/http 0.4
111/tcp open  rpcbind  2-4 (RPC #100000)
MAC Address: 00:00:00:00:00:00 (PC Engines GmbH)
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.6
Uptime guess: 3.768 days (since Wed Mar  6 17:41:57 2019)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=255 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Read data files from: /usr/bin/../share/nmap
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 22.34 seconds
           Raw packets sent: 1149 (53.132KB) | Rcvd: 1141 (48.056KB)

Quelle: Nmap Cheat Sheet

Wer Zeit und Geduld hat, lässt gleich alle 65’000+ Ports scannen:

# nmap -v -p 1-65535 -sV -O -sS -T5 10.1.2.3

Tags: , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 10. Februar 2019

Mit dem Wechsel auf ACS stellt Raiffeisen auch die PDF-Generierung um

Der Kontoauszug für mein Genossenschaftskonto bei der Raiffeisen vom Januar 2019 sieht anders aus als der Auszug vom Dezember 2018. Ich gehe deshalb davon aus, dass nun auch meine Raiffeisen-Bank vom Dinosaurier Dialba weg zum Arizon Core System migriert wurde. Und Francisco sich somit allerspätestens jetzt wohl noch einen Ferrari gepostet hat.

Bei Dokumenten, die bei meinen Banken automatisiert erstellt werden, schaue ich mir mit Apple Preview gelegentlich auch die in das Dokument eingebetteten Meta-Informationen an. Oftmals lernt man so das eine oder andere über die Software, welche im Auftrag der Kernbankenlösung die PDFs generiert.

Dezember 2018 — Dialba

Als PDF-Generator wird „FOP 0.20.5“ eingesetzt und das PDF-Format in Version 1.3 ausgegeben (aktuell wären mittlerweile 1.7 respektive 2.0):

image-8274

Hierbei handelt es sich um eine quelloffene Software namens Apache Formatting Objects Processor, welche XML-Dateien mittels XSL zu PDFs umwandelt.

Januar 2019 — ACS

Als PDF-Generator wird „M/TEXT CS version 6.7.0.476“ über den „OMSAdapter“ eingesetzt und das PDF-Format in Version 1.4 ausgegeben:

image-8275

Der Hersteller des neuen PDF-Generators heisst gemäss Informationen von IBM unter Textmanagement und Dokumenterstellung mit M/TEXT CS 6.8 kühn & weyh Software GmbH aus Freiburg i. Br..

Tags: , , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 3. Februar 2019

Installationsverzeichnis von MacTeX

Die Installation von MacTeX (der LaTeX-Distribution für macOS) findet sich standardmässig in folgendem Verzeichnis:

/usr/local/texlive

Hat man zudem vergessen, welche Version man installiert hat, hilft das Listing des Verzeichnisses:

$ ls -l /usr/local/texlive
total 0
drwxrwxr-x  20 root  wheel  680  1 Jan 19:42 2018
drwxr-xr-x   9 root  wheel  306  1 Jan 19:44 texmf-local

Der Ordner „2018“ signalisiert, dass MacTeX 2018 installiert ist.

Nachtrag: Will man eine neue Version von MacTeX installieren (bspw. die Version 2018 mit 2019 ersetzen), löscht man am Besten das Verzeichnis /usr/local/texlive

# rm -rf /usr/local/texlive

… und führt dann das neue macOS Installer-Package aus, welches man aus dem Internet heruntergeladen hat.

Tags: , , , , ,
Labels: Apple, IT

Keine Kommentare | neuen Kommentar verfassen