UniFi USG – PiHole style – Part II – Analyse

Jetzt habe ich seit einiger Zeit meine USG mit dem Werbeblocker und zusätzlichen Firewall Regeln ausgestattet und alles läuft, wie gewünscht.

Zum “vollwertigen” PiHole Ersatz fehlte mir allerdings bisher immer noch ein wenig die Visualisierung der Statistiken bzw. grundsätzlich die Möglichkeit der Analyse von DNS queries, sprich, welcher Client ruft nach welchem DNS Eintrag und soll das alles auch so sein?

Also habe ich mich mal auf die Suche nach Möglichkeiten gemacht und dabei folgendes Setup entworfen, was ich für meine Lösung nutze:

• Unifi Security Gateway als Datenquelle,
  konkret den DNSMasq der da läuft
• Unifi CloudKey Gen2+ als zentrale Komponente für
  • Rsyslog als zentraler Logserver
  • PostgreSQL als Datenspeicher und
  • Grafana als Visualisierungstool

Auf dem CloudKey habe ich, dank apt Verfügbarkeit, recht einfach einen RSyslog mit Postgres Unterstützung installieren können:

apt install rsyslog-pgsql

Das angenehme dabei, es wird direkt die Notwendige Datenbank in Postgres installiert, d.h. die DB “rsyslog”.
Damit wir später auch von Grafana aus an die Daten kommen, brauchen wir noch einen Account:

sudo -u postgres psql
postgres=# create user rsyslog with encrypted password ‚mypass‘;
postgres=# grant all privileges on database Syslog to rsyslog;

Da zu erwarten ist, dass hier recht viel Aktivität in der Datenbank stattfindet, habe ich danach die Datenbank von nach /srv/db/ also auf die Festplatte, wie hier beschrieben ist, umgezogen.

Jetzt haben wir zwar die Postgres eingerichtet und den Rsyslog auch, gleichzeitig ist aber noch nichts hinterlegt, was wir genau in die DB schreiben wollen (und vor allem, was nicht),
Deshalb müssen noch in der Datei /etc/rsyslog.d/pgsql.conf folgende Einträge gepflegt werden:

###Configuration file for rsyslog-pgsql
###Changes are preserved
$ModLoad ompgsql
#. :ompgsql:localhost,Syslog,rsyslog,rsyslog
:syslogtag,contains,“dnsmasq“ :ompgsql:localhost,Syslog,rsyslog,rsyslog

Jetzt müssen wir dem Dämon auf ‘em CloudKey noch mitteilen, dass er auch erreichbar ist. Das stellen wir in der /etc/rsyslog.conf ein:

#Allow Connections from
$AllowSender UDP, 127.0.0.1, {eigene Subnetzmaske}

Damit nicht gleichzeitig alles in den üblichen Dateien landet, sollte man auch schauen, dass man ggfs. die eine oder andere Rule, die im Standard hinterlegt ist ausschaltet und eher auch in der pgsql.conf pflegt.

Damit ist der RSyslog bereits fertig eingerichtet inkl DB und wir können uns daran machen, “Inhalt” auf den Weg zu bringen. ;-)

Dazu muss im Unifi Network Controller unter
Settings -> Site -> Services -> Remote Logging -> “Enable remote Syslog Server”
lediglich hinterlegt werden, welche IP/Hostname “Remote IP or Hostname” + “Port” (default 514) für den CloudKey verwendet werden.

Nach dem Provisioning aller Unifi Komponenten (jetzt schicken alle die Logdaten an den Cloudkey) sammelt unser Rsyslog die Informationen. Oben hatten wir ja zunächst nur Log-Einträge vom “dnsmasq” zur Weiterleitung an die Datenbank konfiguriert.

Allerdings ist das bei der USG nicht direkt so sondern wir müssen under /etc/rsyslog.d/ eine Datei all.conf mit folgendem Inhalt anlegen:

. @{IP-des-CloudKeys}:514

Im normalen Setup, wie ich es in meinem ersten Artikel gezeigt habe und wie es der Unifi Default ist, protokolliert der DNSMasq zwar die normalen Events ins Syslog, nicht aber die “Queries” die er erhält, denn das können mitunter einige sein, die dann (wenn man sich nicht dafür interessiert) das Log recht fix unübersichtlich füllen.

Damit das geschieht, denn genau das wollen wir ja, muss lediglich in der Datei /config/scripts/BlacklistHosts.conf auf dem USG bei folgender Zeile der Kommentar entfernt (oder die Zeile ergänzt) werden:
dnsmasqOptions=“log-queries“
Danach einfach noch mal /config/scripts/getBlacklistHosts.sh ausführen und der DNSMasq protokolliert auch fleißig die Queries.

Im Default der USG logged diese in eine Datei. Damit das unterdrückt wird und der rsyslog genutzt wird, muss das Datei-Target noch auskommender werden. Das geschieht mit den folgenden zwei Zeilen und einer anschließenden Re-Provisionierung der USG:

cp /opt/vyatta/sbin/vyatta-dns-forwarding.pl ~/vyatta-dns-forwarding.pl.bak
sed -i 's/\$output \.= "log-facility/\$output \.= "# log-facility/' /opt/vyatta/sbin/vyatta-dns-forwarding.pl

Jetzt sammeln wir fleißig queries aber müssen uns noch um die UI kümmern. Dazu nutze ich, wie oben beschrieben Grafana, dessen Installation auf dem UCKP auch recht einfach ist:

curl https://packages.grafana.com/gpg.key | sudo apt-key add –
apt install -y apt-transport-https
add-apt-repository „deb https://packages.grafana.com/oss/deb stable main“

apt -y update && sudo apt -y install grafana
systemctl daemon-reload
systemctl start grafana-server
systemctl enable grafana-server.service
systemctl status grafana-server

Bleibt noch der finale Schritt, d.h. die Installation des Dashboards. Hierzu legt man sich eine “Data Source” vom Typ PostgreSQL an:

Wenn wir jetzt ins Grafana Dashboard wechseln, sollte es sich langsam “mit Leben” füllen.

Nachtrag (12.01.2022)

Ich habe mich entschieden die Dashboards und auch die restlichen Scripte in ein Git Repository zu legen und dort zu pflegen.