freebsd

 A duck is like a bicycle because they both have two wheels except the duck.
- Terry Lambert


14.10.2018

rudimentärer Clavister Support für LibreNMS

Eines der von mir benutzen Netzwerk Monitoring Systeme ist LibreNMS, für das ich vor Jahren mal ein wenig Code zum Support von Clavister Firewalls geschrieben habe. Nach einer Neuinstallation habe ich die dafür relevanten Dateien zusammengetart und hier verfügbar gemacht.

 Einige Anmerkungen dazu:

  • Das von mir hier verwendete LibreNMS ist in der Version 1.43 aus den FreeBSD Ports und läuft bei mir unter FreeBSD 11-Stable.

  • Der geneigte Leser muß sich die MIB's noch von von Clavister herunterladen (man suche nach "mib" im Download Bereich, dann findet man sie auch) und a) im Verzeichnis "mibs" auspacken und b) ein Verzeichnis "clavister" unter "mibs" erstellen und dort auch nochmal auspacken.

  • In der Datei includes/definitions/discovery/clavister-cos.yaml ist die MIB als absoluter Filename spezifiziert. Ohne diesen findet snmpbulkwalk die Clavister-MIB nicht. Auch nach viel Doku lesen und rumprobieren ist mir nicht ersichtlich, warum das so sein muß. Dieser absolute Filename muß auf anderen Systemen sicherlich angepasst werden!


1.10.2018

bind/named DNS Firewall  =  DNS Response Policy Zone (RPZ)

Es gibt immer wieder einige Domains, die möchte man nicht besuchen und man möchte auch nicht "besucht werden", meist durch komische Webseiten oder Scripte oder sonstwas. Bisher habe ich soetwas durch URL Blacklists in einem ALG in der Firewall meines Vertrauens erledigen lassen. Aber seit die Masse der Webseiten per https:// erreichbar ist, funktioniert das aus offensichtlichen Gründen nicht mehr.

Vor einiger Zeit bin ich nun auf "DNS Firewalls" oder Response Policy Zones im bind gestossen. Grob gesagt, werden dabei Domains so umgeschrieben, das sie nicht mehr auflösbar sind und dann ins Leere laufen. "Ins Leere" kann dabei auch eine eigene Webseite sein, auf der der Benutzer dann darüber informiert wird, was mit seinem Aufruf gerade geschieht. Voraussetzung dafür ist natürlich, das der so konfigurierte bind/named vom eigenen Resolver genutzt wird.

Im einfachsten Fall geht das so: in die "options" Section von named.conf wird der Name der Response Policy Zone konfiguriert, hier heisst sie "rpz.hallstr.de":

response-policy {
zone "rpz.hallstr.de";
};

Etwas weiter wird dann das Zonenfile benannt, in meinem Fall das File "db.rpz" im Verzeichnis "master":

zone "rpz.hallstr.de"{
        type master;
        file "master/db.rpz";
};

Die Datei db.rpz sieht dann schliesslich in etwa so aus:

$TTL    2h
$ORIGIN rpz.hallstr.de.

@        SOA                    nixda.nowhere.noplace. nobody.nowhere.noplace. (
                                2018100106      ; Serial
                                12h             ; Refresh
                                15m             ; Retry every
                                3w              ; Expire after
                                2h )            ; Minimum ttl

                                NS             nixda.nowhere.noplace.

waddehaddedudennda.com          CNAME           rpz.hallstr.de.
*.waddehaddedudennda.com        CNAME           rpz.hallstr.de.

.. und das bewirkt, das die Domain waddehaddedudennda.com und alle ihre Subdomains nicht mehr erreichbar sind. Wer mag, kann das auch auf IP Adressen anwenden, ist in unserem Fall unnötig.

Etwas ausführlicher ist das bei zytrax.com und bei der IETF und beim ISC beschrieben.


 

FreeBSD 11: TCP hostcache formatiert anzeigen und ggf. löschen    (Februar 2017) 

Lange Zeit wurde ich von einem Fehler geplagt (siehe weiter unten "pf + ipv6 path mtu discovery" ), von dem ich nun herausgefunden habe, das das kein Fehler im FreeBSD ist. Im Zuge der Fehlersuche entstand ein perl script, mit dem man sich den TCP Hostcache im FreeBSD formatiert anschauen kann, nach verschiedenen Kriterien die angezeigten Daten auswählen kann und bei Bedarf (geht erst ab FreeBSD 11) den Hostcache löschen kann (welcher sich dann nach und nach wieder aufbaut). Nötig wurde das Ganze, weil in diesem Hostcache Änderungen der MTU eingetragen werden, die durch IPv6 ICMP "packet too big" Pakete angestossen worden sind. Diese Änderungen der MTU für bestimmte Hosts sind damit sichtbar und rückgängig zu machen.

Erklärungen zu den angezeigten Feldern findet der geneigte Leser unter /usr/src/sys/netinet/tcp_hostcache.h, Parameter werden wie üblich durch -h erklärt, manpage gibt's nicht.

Das perl Script ist, wie bei solchen Dingen üblich, nicht das Allerschönste, aber es tut was es soll: dies ist der Link zum Download.

 


 

FreeBSD auf Beaglebone Black von interner eMMC booten    (Februar 2017)

Mit crochet kann man ganz hervorragend FreeBSD Images erstellen, die dann auf eine SD geschrieben werden, von der dann ein Beaglebone bootet. Der Beaglebone Black hat aber auch eine eingebaute SD (oder besser eMMC), von der der Beaglebone potentiell auch booten kann. Auf einem laufenden Beaglebone findet man unter /root das script copy-to-emmc.sh, das aber - zumindest bei mir - noch nie funktioniert hat, führt man es aus und versucht man danach von der eMMC zu booten, schlägt das fehl. Es scheint, das der gpart Befehl, wenn er auf einem Beaglebone selbst ausgeführt wird, zu merkwürdigen Ergebnissen führt.

Um das aber jetzt zum laufen zu bekommen, habe ich das Script abgeändert, so das jetzt fdisk statt gpart zur Erstellung der DOS Partiotion benutzt wird und dann funktioniert das Ganze. Wenn man jetzt von der eMMC bootet, wirft der Beaglebone Loader Massen von „Card did not respond to voltage select!“ Meldungen aus, das hört aber auf, sobald der kernel gestartet ist.

Den diff gibt's hier: https://people.freebsd.org/~hm/misc/copy-to-emmc.sh.diff

 


 

ssh brute force Attacken auf FreeBSD 10.x minimieren    (Mai 2016)

Seit langer Zeit nerven mich die völlig sinnlosen Attacken auf meine ssh Ports auf den diversen Servern. Ich benutze schon lange z.B. sshguard und pf brute force Regeln, aber so richtig befriedigend ist das nicht. Nun schaue ich mir von Zeit zu Zeit an, woher die Attacken denn so kommen und sehe meist immer die gleichen IP Bereiche aus den immer gleichen Teilen der Welt.

Neulich nun hat Clavister eine neue Version seiner Firewallsoftware herausgebracht, mit der es auf Basis von Geo-Lokationsdaten möglich ist, IP Datenströme zu filtern: schöne Sache, nach entsprechender Konfiguration hört der Spuk einfach auf und es ist ziemlich Ruhe !

Da ich auch einige Rechner nur mit pf Firewall betreibe, habe ich mir etwas ähnliches mit FreeBSD Bordmitteln gebaut: Basis sind die frei verfügbaren Datenbanken der Firma MaxMind ( Danke sehr !!! ), die man hier bekommen kann und die einmal pro Monat upgedatet werden, das reicht für meine Zwecke völlig aus. Die Datenbank wird geholt, die IP Adressen/Ranges der gewünschten Länder extrahiert (das Länder File pf_blck_countries.txt ist ein Text File, in dem einfach Zeile für Zeile die nicht gewünschten Länder - Englisch - eingetragen sind) und in ein pf-lesbares Tabellenformat gewandelt. Den Rest erledigt eine pf-Regel in /etc/pf.conf. Das shell script, das das tut, hängt unten dran, das Programm tableutil gibts in den Ports (net/tableutil) und dann braucht man noch zwei Zeilen in /etc/pf.conf: eine Zeile deklariert die Tabelle (aus Datei /var/db/pf/blocked.ip4) und eine Zeile blockt darauf basierend - fertig. Nicht ganz, ein crontab-entry der das einmal pro Monat ausführt wird benötigt (und pf nicht vergessen zu reloaden !).

#!/bin/sh
#---------------------------------------------------------------------------
#
#       update_geoip_dbs
#       ----------------
#
# Hellmuth Michaelis, hm@m-bit.net
#
#       last edit-date: [Sun May  1 17:03:16 2016]
#
#       - fetch free IP geolocation database
#       - extract needed county ip adresses
#       - convert to pf table format
#
#---------------------------------------------------------------------------
LDIR=/usr/local/share/GeoIP
GIPCL=GeoIPCountryCSV.zip
GIP4=http://geolite.maxmind.com/download/geoip/database/$GIPCL
GIPCSV=GeoIPCountryWhois.csv
PFLIST=/var/db/pf/blocked.ip4
CLIST=/usr/local/etc/pf_blck_countries.txt

# cd to dest dir, create if necessary
cd $LDIR
if [ $? != 0 ]
then
        mkdir -p $LDIR
        cd $LDIR
        if [ $? != 0 ]
        then
                echo "ERROR, cannot create $LDIR, exit"
                exit 1
        fi
fi

# check if country list file exists
if [ ! -s $CLIST ]
then
        echo "ERROR, $CLIST nonexistent or empty, exit"
        exit 1
fi

# get free IP geolocation database
fetch $GIP4
if [ $? != 0 ]
then
        echo "ERROR, cannot fetch $GIP4, exit"
        exit 1
fi

# move old csv out of our way
if [ -f $GIPCSV ]
then
        mv $GIPCSV $GIPCSV.bak
fi

# unzip database
unzip $GIPCL
if [ $? != 0 ]
then
        echo "ERROR, cannot unzip $GIPCL, exit"
        exit 1
fi

# remove zip-file
rm $GIPCL

# move old filter table to backup
if [ -f $PFLIST ]
then
        mv $PFLIST $PFLIST.bak
fi

# grep: filter only the needed ip's based on country in country file
# awk: filter only the ip address ranges
# sed: remove the remaining "'s
# tableutil: convert ip address ranges into cidr representation
grep -i -f $CLIST $GIPCSV | awk '{ FS=","; print $1 "-" $2 }' | sed 's/"//g' | tableutil -q text > $PFLIST

exit 0

# EOF

 

 


 

IPv6 DHCP client unter FreeBSD 10.2   (August 2015)

Um einen Rechner automatisch unter FreeBSD 10.2 mit einer IPv6 Adresse zu versorgen, gibt es mehrere Möglichkeiten. Um das per IPv6 DHCP zu tun, braucht man einen dhcp v6 client - der muß aus den ports installiert werden weil soetwas bis jetzt nicht im Basissystem enthalten ist; der mitgelieferte dhclient kann kein IPv6 DHCP. Ich habe den dhcp6 KAME DHCP6 client ausprobiert (/usr/ports/net/dhcp6) - der tat auf Anhieb das, was ich brauchte.

Zur Konfiguration vom dhcp6 client bedarf es eines Konfigurationsfiles /usr/local/etc/dhcp6c.conf, das sieht bei mir so aus:

interface re0 {
     send ia-na 0;
};

id-assoc na {
};

Das Interface, um das es geht, ist "re0". In der Datei /etc/rc.conf sieht es diesbezüglich so aus:

ifconfig_re0_ipv6="inet6 accept_rtadv"

dhcp6c_enable="YES"
dhcp6c_interfaces="re0"

Nachdem diese Einträge gemacht worden sind, funktioniert das schon ganz gut, aber ich möchte wieder fest zugeordnete IP Adressen haben, damit das mit meinem DNS harmoniert.

Der besagte KAME dhcp6 client legt im Verzeichnis /var/db eine Datei "dhcp6c_duid" an, in der die DUID des clients zu finden ist. Das ist eine Binärdatei, die man sich als hexdump mit "hd" angucken kann, also lautet das Kommando: "hd /var/db/dhcp6c_duid", hier sieht das so aus:

00000000  0e 00 00 01 00 01 1d 67  0c 76 00 0d ww xx yy zz |.......g.v......|

Hiermit kann man nun den Eintrag in ein ISC dhcp v6 Server Konfigurationsfile vornehmen (die beiden ersten Blöcke "0e 00" löschen und nur den Rest verwenden):

host mein_rechner {        
host-identifier option dhcp6.client-id 00:01:00:01:1d:67:0c:76:00:0d:ww:xx:yy:zz;
        fixed-address6 2001:nnnn:mmmm:pppp::49;
}

und schwupp - geht's schon.


 

pf + ipv6 path mtu discovery   (Mai 2014)

Es gibt offenbar ein Problem mit IPv6 Path MTU Discovery unter aktuellen FreeBSD Versionen (10.x) im Zusammenhang mit der Benutzung des pf-Paketfilters. Die Auswirkungen sind derart, das wenn dieses Phaenomen auftritt, "hängende" IPv6 Verbindungen zu beobachten sind. Genaueres hierzu ist in einer Mail an freebsd-net zu finden. Einen patch mit einem Workaround (es ist wirklich ein Hack und nicht im geringsten ein Fix) findet der geneigte Leser hier - die Datei /usr/src/sys/netpfil/pf/pf.c wird derart gepatcht, das bei einem IPv6 ICMP Packet Too Big Fehler (von dem der pf denkt, es sei fehlerhaft) das Paket vom pf an den Stack durchgelassen wird. Damit funktioniert es dann wieder . . .

 

Update 02/2017: der Fehler liegt nicht im FreeBSD oder im pf-Paketfilter. Die zwischen den FreeBSD Instanzen liegende Firewall verändert die TCP Sequence Nummern, allerdings werden in dem durch die Firewall gehende ICMP "packet too big" Paket in der damaligen Konfiguration die darin enthaltenen Fragmente der verursachenden TCP Pakete nicht die Sequence Nummern geändert, so das die Validierung der Sequence Nummer durch den pf fehl schlägt und das Paket verworfen wird und daher keine Änderung der MTU vorgenommen wird.

 


 

openssl / Heartbleed   (April 2014)

Auch dieser Webserver ist vom openssl Heartbleed bug betroffen gewesen. Genaueres dazu findet der geneigte Leser im CAcert Blog. Am 12.4.2014 ist sowohl openssl auf eine nicht betroffene Version upgegradet worden als auch ein neues CAcert Zertifikat für diese Webseite generiert und installiert worden.

Ob ein Webserver von diesem Bug betroffen ist, kann u.a. mit dem SSL Server Test getestet werden.

Genauere technische Informationen gibt es bei CVE und eine (nicht vollständige) Liste der betroffenen Produkte gibt es u.a. auf OSVDB.

 


 

SSL fingerprint T-Online   (März 2014)

T-Online hat ja - wie andere Provider auch - auf verschlüsselte Verbindungen zum Mailtransport umgestellt. Fetchmail benötigt u.a. SSL fingerprints der serverseitig verwendeten Zertifikate. Blöd ist nur, das T-Online diese Zertifikate offenbar von Zeit zu Zeit ändert, die Frequenz ist ziemlich hoch (dreimal innerhalb 2014 bis jetzt).

Der fingerprint wird so generiert: erstmal Zertifikat holen

openssl s_client -connect securepop.t-online.de:995 -showcerts > t-online.out

und dann das Zertifikat im Editor herausschnipseln und nach t-online.zertifikat speichen. Anschliessend mit

openssl x509 -in t-online.zertifikat -noout -fingerprint -md5

den fingerprint generieren und in die fetchmailrc eintragen.

 


 

Beaglebone Black   (Februar 2014)IMG 0595

Da der Raspberry Pi netzwerktechnisch nicht so performant ist, bin ich auf den Beaglebone Black gestossen. Der ist sowohl vom Ethernetinterface als auch on der CPU her merklich schneller als der Raspberry Pi, allerdings ist die Unterstützung seitens des FreeBSD Kernels noch nicht ganz so gut, er läuft stabil, aber man merkt, das da noch debuggt werden muß (ein Kernel ohne WITNESS und INVARIANTS bootet nicht, FreeBSD 11-current). "crochet" unterstützt den BBB und es ist ziemlich einfach zu bedienen und zu konfigurieren.

 

 

 


 

Raspberry Pi - "sixxsbox"     (Januar 2014)IMG 0608

Nachdem ich mit dem Raspberry Pi eine Zeit lang gespielt hatte, entschloß ich mich, meinen sixxs IPv6 Zugang auf den Pi zu verlegen. Hierzu habe ich eine möglichst kleine FreeBSD Installation gebaut, die zwar noch Verbesserungsmöglichkeiten bietet, aber im Grossen und Ganzen das tut, was ich erwarte.

Als Anlaufstellen zu FreeBSD auf dem Raspberry Pi gibt es eine Seite im FreeBSD Wiki, sowie die Seite kernelnomicon.org.

Das Netzwerkinterface des Raspberry Pi ist über (das interne) USB angeflanscht, die Netzwerkperformance ist nicht so berauschend, dieser Thread beschreibt das Problem. Um dieses Problem hat sich jemand gekümmert, es gibt einen Patch, der USB von polled auf DMA umstellt, es gibt aber offenbar noch "Nebenwirkungen". Ich habe nichts am USB angeschlossen und für mich funktioniert der Patch gut, er dreht die maximale Transferrate um 50%...100% hoch.

Dann hab ich noch "crochet" gefunden, um bootfähige FreeBSD Images zu bauen, das schaut ganz vielversprechend aus ...

Mein build script gibt es hier (ist eine Abwandlung des Scripts von kernelnomicon.org - meins ist wie alle diese Spiel-Dinge leicht grausam, der geneigte Anwender mag das vorher noch mal durchsehen ...), dazu gehört auch eine src.conf. Die Ports mounte ich mir per NFS und baue dann auf dem Pi das, was ich brauche. Da in src.conf auf die Text Tools und man-Pages verzichtet wird, fehlen beim Port bauen irgendwann "makeinfo" und "install-info". Einfach in /usr/local/bin "touch"-en und dann kann's weiter gehen.

Update 02/2014:
das sixxs-aiccu script startete nicht durch nach einem reboot, es stellte sich heraus, das die lokale Zeit nicht stimmte. Hintergrund ist, das der RPi keine RTC hat und den ntpd benötigt, um die Zeit zu setzen. Der ntpd wiederum benötigt aber eine Weile, bis er sich mit dem Server synchronisiert hat. Also muß - rcorder(8) ist dein Freund - das sixxs-aiccu script ganz zum Schluß laufen und das start command benötigt noch ein paar Sekunden sleep(1).


 

Upgrade auf bind 9.9.x - Probleme mit "views"     (Dezember 2013)

Nach einem Upgrade auf bind 9.9.3-P2 gab es Probleme mit views: in dem view, in dem Adressen rekursiv aufgelöst werden konnten, funktionierte genau das nicht mehr. Die Fehlermeldung im syslog war:

client 172.16.17.18#58510 (www.example.com): view recursion: query (cache) 'www.example.com/A/IN' denied

Es stellte sich heraus, das sich einige default Werte im neuen bind geändert hatten, ein allow-query-cache statement im entsprechenden view stellte das gewohnte Verhalten wieder her. Genauer beschreiben ist dies in einem Artikel der ISC Knowledge Base: What has changed in the behavior of "allow-recursion" and "allow-query-cache"


 

FreeBSD 10 (current/head) - "alten" C-Code kompilieren     (Juli 2013)

FreeBSD 10 benutzt einen neuen C-Compiler (CLANG) statt des bisher benutzten GNU C-Compilers im Basissystem. Der verhält sich nun in einigen Details anders ( = moderner ) so das es u.U. Probleme gibt, K&R und/oder c89 C-Sourcen zu übersetzen.

Die häufigste Fehlermeldung, über die ich gestolpert bin, ist:

file.c:nnn:nn: error: non-void function 'c_function' should return a > value [-Wreturn-type]

Dies ist jetzt ein Fehler und im Grunde muss man durch den ganzen alten Code durch (früher wurde void und int im Kontext function return nahezu gleich behandelt) - das ist nervig.

Ändern kann man dies Verhalten, indem man -Wno-return-type zu den CFLAGS hinzufügt, dann bekommt man das klassische Verhalten. Bisher kompilierte mein alter Code damit problemlos und ich habe auch keine Merkwürdigkeiten zur Laufzeit festgestellt.