Posts Tagged ‘arpwatch’

Samstag, 29. Juli 2017

postfix ausgehende E-Mails mit einem bestimmten Betreff automatisch verwerfen lassen

arpwatch und Apple-Geräte wie Apple TV und Time Capsules sind keine guten Freunde.

Überwacht man das lokale Netzwerk mit arpwatch und hat im selben Netzwerk einen Apple TV sowie mindestens eine Time Capsule stehen, wird man damit konfrontiert, dass die IP des Apple TVs (scheinbar, aus Sicht von arpwatch) konstant die MAC-Adresse wechselt.

Ich vermute Folgendes hinter diesem komischen Sympton: Geht der Apple TV schlafen, simuliert die Time Capsule den Apple TV und seine Funktionen irgendwie im Netzwerk — wahrscheinlich, damit man auf iOS-Geräten den Apple TV weiterhin „sieht“ und als AirPlay-Ziel anwählen kann. Erfolgt dann tatsächlich eine solche Anfrage, erweckt die Time Capsule den Apple TV irgendwie aus den Schlaf und das iOS-Device kann dann auf den Fernseher streamen. Man möge mich korrigieren, wenn ich (völlig) falsch liege.

Leider hat dieses Verhalten den unerwünschten Nebeneffekt, dass arpwatch konstant meine INBOX vollballert mit Meldungen zur Apple TV IP, welche ständig die MAC-Adresse zu wechseln scheint.

Da ich kein Netzwerkprofi bin und nicht C programmieren kann, verwehrt sich mir der Weg, arpwatch mit einer Funktion auszustatten, MAC-Wechsel von Apple-Geräten zu ignorieren.

Ich setze deshalb später in der Verarbeitungskette an und verwende einen Filter in postfix, um Mails mit einem bestimmten Betreff nicht mehr an mein Mailkonto weiterzuleiten. Dies ist ganz simpel, sofern man bereits eine funktionierende postfix-Installation am Laufen hat:

/etc/postfix/header_checks

/^Subject:.*flip flop \(apple-tv.domain.local\).*/ DISCARD

/etc/postfix/main.cf

...
header_checks = regexp:/etc/postfix/header_checks

Und Ruhe ist. Wenn man sich nicht sicher ist, ob postfix überhaupt etwas blockt, oder wenn man befürchtet, dass postfix zu viele Mails verwirft, hilft /var/log/postfix.log weiter:

$ cat /var/log/postfix.log | grep discard
...
Jul 27 22:41:23 SERVER postfix/cleanup[8564]: A8BCB1560312: discard: header Subject: flip flop (apple-tv.domain.local) from local; from=<root@SERVER>

Tags: , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 21. Januar 2016

smokeping auf einem Raspberry Pi installieren

Gestern habe ich einen verstaubten Raspberry Pi 1 aus meinem Endlager für obsolete IT-Hardware gerettet und ihn als arpwatch-Überwachungsstation aufgesetzt. Auf dem Gerät läuft folgendes Debian:

Linux raspberrypi 4.1.13+ #826 PREEMPT Fri Nov 13 20:13:22 GMT 2015 armv6l GNU/Linux

Etwas später stiess ich in Vorbereitung auf meinen Wechsel von upc cablecom zu Fiber7 auf den Artikel Fiber7 performance, in welchem Michael Stapelberg aufzeigt, wie sich die Latenz seiner Internetverbindung nach dem Wechsel von Swisscom auf Fiber7 verbessert hat.

Gedacht — getan: So etwas benötige ich natürlich auch, um meinen bevorstehenden Providerwechsel mit harten Fakten zu untermauern — wobei, ehrlich gesagt, ist mir die Latenz nicht so wichtig (bin kein Gamer), sondern viel mehr der vierfache Durchsatz und die symmetrische Down- und Upload-Geschwindigkeit zum selben Preis wie beim Kabelriesen.

Nichtsdestotrotz installierte ich mir also das Softwarepaket smokeping und seine Dependencies, wie das berühmte rrdtool aus dem Hause Oetiker:

# apt-get update
...
# apt-get upgrade
...
# apt-get install smokeping

Es wurde zwar alles nett installiert, doch konnte ich danach noch nicht auf die Web-Oberfläche unter http://localhost/smokeping/smokeping.cgi zugreifen. Unter einem x86-64 Debian war das nach der Installation automatisch möglich.

Zuerst wohl mal den Apache starten, dachte ich mir:

# /etc/init.d/apache2 start

Der Web-Server kam hoch, zeigte unter http://localhost/ die obligate Startseite an, doch unter dem Smokeping-Link kam ich statt der Smokeping-Oberfläche nur einen HTTP 403er zu Gesicht (mangels Screenshot und Text-Kopie mittels Auszug aus dem Apache error.log unter /var/log/apache2/):

...
[Wed Jan 20 22:52:59.338858 2016] [authz_core:error] [pid 2706:tid 3036673072] [client 10.0.1.101:56967] AH01630: client denied by server configuration: /usr/lib/cgi-bin/smokeping.cgi
...

Oookey … da ich smokeping auch noch auf einem „richtigen“ Linux-Server im Elternhaus laufen hatte, kopierte ich kurzerhand dessen VirtualHost-Konfiguration auf den Raspberry Pi (natürlich als Symlink auf conf-available):

# cat /etc/apache2/conf-enabled/smokeping.conf 
ScriptAlias /smokeping/smokeping.cgi /usr/lib/cgi-bin/smokeping.cgi
Alias /smokeping /usr/share/smokeping/www

<Directory "/usr/share/smokeping/www">
    Options FollowSymLinks
</Directory>

<Directory "/usr/lib/cgi-bin/">
    Options FollowSymLinks
    Require all granted
</Directory>

Noch ein …

# apache2ctl graceful

… und der 403er war weg. Das smokeping-GUI wurde aber weiterhin nicht angezeigt, sondern nur der Inhalt des CGI-Scripts im Klartext:

#!/bin/sh

exec /usr/share/smokeping/smokeping.cgi /etc/smokeping/config

Was zur Hölle … ? Doch auch diesem Fehlverhalten schaffte ich nach 15 Minuten googlen, Artikel lesen und pröbeln den Garaus: Ein simples

# a2enmod cgi

Via: Perl Apache : Perl script displayed as plain text

reichte aus, und plötzlich führte Apache das CGI-Script aus. Halleluja!

Tags: , , , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 9. August 2015

Apple TV verursacht zusammen mit einer Apple Time Capsule arpwatch flip flops

Seit ich vor einigen Tagen im Netzwerk eines Familienangehörigen zwei gebrauchte Apple Time Capsules (500GB sowie 2TB) installiert habe, füllt sich das Log meiner arpwatch-Instanz mit folgenden Meldungen:

            hostname: 
          ip address: 192.168.44.155
           interface: eth1
    ethernet address: aa:bb:cc:dd:ee:ff
     ethernet vendor: 
old ethernet address: 00:11:22:33:44:55
 old ethernet vendor: Apple, Inc
           timestamp: Sunday, August 9, 2015 15:36:58 +0200
  previous timestamp: Saturday, August 8, 2015 23:03:54 +0200
               delta: 16 hours

Aus Sicht von arpwatch „übernimmt“ die Time Capsule 500GB die IP-Adresse des Apple TVs. Dies ist insofern unzulässig, weil ich die IPs statisch festgelegt habe und mittels einem DHCP-Server an die anfragende MAC-Adresse aushändige.

Nach kosmetischen Anpassungen an der Konfiguration der Time Capsule brachte ich die Fehlermeldung nicht weg. Eine Google-Suche hingegen liefert mir einen Hinweis, was das wirklich Problem sein könnte:

Bug 841067 – Arpwatch repeatedly misdetects „Bonjour Sleep Proxy“ as „flip flop“

Frei übersetzt legt die Time Capsule die Bonjour-Informationen des Apple TVs in ihrem Zwischenspeicher ab. Wenn sich der Apple TV in den Schlafmodus verabschiedet, weil das Gerät nicht (mehr) genutzt wird, sendet die Time Capsule Infos über den Apple TV regelmässig ins Netzwerk, damit andere Apple-Geräte wissen, dass ein Apple TV im Netz hängt. Irgendwie scheint dieser Bonjour-Broadcast für arpwatch auszusehen, als ob die Time Capsule unter der IP-Adresse des Apple TVs funkt.

Ich habe den Log-Alarm deshalb nun so umgestellt, dass er flip flops mit dieser IP ignorieren wird.

Nachtrag

Ein bereits älterer Thread zu dem Thema im Apple-Diskussionsforum: ARP Cache Poison behavior by Apple TV

Tags: , , , , , , ,
Labels: Apple, Linux

3 Kommentare | neuen Kommentar verfassen