Erste Schritte mit FreeBSD - Tor Relay installieren

[CoMo]

Ahoi,

ich habe mir gerade einen weiteren 1€ VPS bei Netcup geklickt. Ich wollte da gerne eine obfs4 Tor Bridge drauf installieren.

Weil ich adventurous bin, dachte ich, ich nehme mal FreeBSD anstelle von Linux.

Also das vorhandene FreeBSD13 Image installiert. Festgestellt, dass das End-Of-Life ist. Also wie hier beschrieben ein Upgrade auf FreeBSD14 durchgeführt.

Firewall, SSHD Settings etc wie auch unter Linux üblich geändert. pf musste ich erst mal kennenlernen.

Dann den pkg Branch wie hier beschrieben von quarterly auf latest geändert.

Dann festgestellt, dass das Tor Paket in FreeBSD14 outdated ist. FreeBSD15 ist current, da gäbe es das aktuellste Paket. Aber das ist ja eher so der Entwicklungszweig. Dann bei FreeBSD14 bleiben.

Also: Ports.

pkg install portsnap
portsnap fetch
portsnap extract
cd /usr/ports/security/tor/
make install clean

Endet in:

/usr/include/c++/v1/string_view:220:10: fatal error: '__string/char_traits.h' file not found

Ich dachte, Ports kümmert sich um alle Abhängigkeiten? Was habe ich hier übersehen?

Bitte nicht hauen, bin absoluter Anfänger in Sachen BSD

 

[Redundanz]

pkg install tor

13.2 ist übrigens nicht eol

 

[andy_m4]

Also das vorhandene FreeBSD13 Image installiert. Festgestellt, dass das End-Of-Life ist.

FreeBSD 13 wird nach wie vor gepflegt. Die aktuellste Inkarnation ist FreeBSD 13.2

Dann festgestellt, dass das Tor Paket in FreeBSD14 outdated ist.

Die Version in den Ports sollte eigentlich gleich sein mit den Packages aus dem latest-Repository. Offenbar gibt es aber da derzeit für FreeBSD14-Packages ein Problem. Bei FreeBSD 13.2 solltest Du die Tor-Version 0.4.8.10 kriegen.

portsnap

Soweit ich weiß, funktioniert portsnap unter FreeBSD 14 nicht mehr (richtig), da alles auf git umgestellt wurde.
Du musst Dir also ein git besorgen (pkg install git) und dann die den Ports-Tree mit
git clone https://git.FreeBSD.org/ports.git /usr/ports
ziehen (aktualisieren kannst Du ihn dann mit git -C /usr/ports pull)

(siehe dazu den Abschnitt Ports im Handbuch)

Ich dachte, Ports kümmert sich um alle Abhängigkeiten?

Die Fehlermeldung sieht jetzt aber nicht danach aus, als ob der über ne fehlende Abhängigkeit stolpert.
Die Datei
/usr/include/c++/v1/__string/char_traits.h
fehlt. Die sollte eigentlich da sein. Falls nicht, ist irgendwas an Deiner FreeBSD-Installation kaputt. Einen Schnellcheck kannst Du mit
freebsd-update IDS
machen. Außerdem solltest Du gucken, das Du den neusten Patchlevel hast:
freebsd-update fetch install

(siehe dazu die Manpage von freebsd-update)

 

[CoMo]

pkg install tor

Dann bekomme ich Tor 0.4.8.9 und nicht das aktuelle 0.4.8.10.

13.2 ist übrigens nicht eol

Das System hat mit ganz klar angezeigt, dass meine aktuell verwendete Version End of Life ist. Ich glaube, es war beim pkg update.

Ergänzung (18. Dezember 2023)

Die Version in den Ports sollte eigentlich gleich sein mit den Packages aus dem latest-Repository. Offenbar gibt es aber da derzeit für FreeBSD14-Packages ein Problem. Bei FreeBSD 13.2 solltest Du die Tor-Version 0.4.8.10 kriegen.

Oha, auf freshports steht ja wirklich, dass es Tor 0.8.4.10 für FreeBSD:13:amd64 gibt, für FreeBSD:14:amd64 aber nur die 0.8.4.9.

Dann sollte ich die Kiste vielleicht einfach noch mal platt machen und ein frisches FreeBSD13 installieren?

Soweit ich weiß, funktioniert portsnap unter FreeBSD nicht mehr (richtig), da alles auf git umgestellt wurde.
Du musst Dir also ein git besorgen (pkg install git) und dann die den Ports-Tree mit
git clone https://git.FreeBSD.org/ports.git /usr/ports
ziehen (aktualisieren kannst Du ihn dann mit git -C /usr/ports pull)

Ah. Hm. Das hatte ich hier auch gelesen, woanders dann aber was von portsnap gelesen und da das mit pkg install portsnap scheinbar funktionierte, habe ich das so probiert.

Dann vielleicht doch lieber bei FreeBSD14 bleiben und Ports ordentlich via Git einrichten?

 

[Redundanz]

komisch... sollte/dürfte nicht so sein.

(wohlgemerkt auf 13.2 !)

Das System hat mit ganz klar angezeigt, dass meine aktuell verwendete Version End of Life ist. Ich glaube, es war beim pkg update.

ja, dann warst du nicht auf 13.2, denn das ist sicher nicht eol.

Ergänzung (18. Dezember 2023)

Dann sollte ich die Kiste vielleicht einfach noch mal platt machen und ein frisches FreeBSD13 installieren?

ja

 

[CoMo]

/usr/include/c++/v1/__string/char_traits.h
fehlt. Die sollte eigentlich da sein. Falls nicht, ist irgendwas an Deiner FreeBSD-Installation kaputt. Einen Schnellcheck kannst Du mit
freebsd-update IDS
machen. Außerdem solltest Du gucken, das Du den neusten Patchlevel hast:
freebsd-update fetch install

freebsd-update IDS
src component not installed, skipped
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching metadata signature for 14.0-RELEASE from update2.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
/.profile has SHA256 hash 7e8ff395d58921c580fb4fc9781f0fb727d9068817620904209c888a536f2a0e, but should have SHA256 hash 2b12005be6bb67838430037c0b22b66c279d3e5b22e47d7da4851e763d1e3d7c.
/etc/hosts has SHA256 hash f7d8d845ad2095bfb2af53cdc944f7ea2944b77966d9d8bee96c1e4ef59a06f2, but should have SHA256 hash 336de0d20e14a6e526e147580ef5b0a7167a4ff4ebd788222d71e4c238e7ab2e.
/etc/login.conf has SHA256 hash 7e069e12bfed332379cd78cd9abdd3b13b1cb8a772fe5d465eca6371384675f3, but should have SHA256 hash 8f7ce595052cb4c6ad200e80565345ce7c6977f7f035928b3697a08d0e844527.
/etc/login.conf.db has SHA256 hash 698c9aaeaa467229f859ecff39dbf21bb1a72bf1eba5a56d07c65fbb9a8ff3a1, but should have SHA256 hash d3facdfbefea9e41a172746283694ce4bf3feaf1e88b9d9a8827ccb5aa642c81.
/etc/master.passwd has SHA256 hash da2fa19d7e2a58e4b669ac0852e632dbf2c3f8ec9bfd589c2204cd31e62714f6, but should have SHA256 hash 55dfb5a41ebad44523b26cba443d94c3d55e0b39a32558f81a1d50fed964ec34.
/etc/passwd has SHA256 hash 3b0651a1691f31230f039fb15fad8008f3af4362da7372c4fe6c5d4c28d652b3, but should have SHA256 hash 57d2a756f16439eb2bc13af8d4b0a958ccec88643c6246cfc00e5b0894417eec.
/etc/pwd.db has SHA256 hash faf5d18e32bffbcda47e285cb386ace87eeeb6344e78eff8a15c2e742595122f, but should have SHA256 hash bd30e09f6e06e4430bbb8fa20c4ed46babaec585d5580a92244c6a4227c5af56.
/etc/shells has SHA256 hash 5f6fc4cc13cdcf419256c8fe8b71849bc8b57e20e55ddfb14d9798f7e6436c5a, but should have SHA256 hash d4f435c3c24679f19609fcf0e78c473c85582cd0300ebcc0ac3088c34408cde4.
/etc/spwd.db has SHA256 hash 2af378e65ac00cd7fa6ae3c5e9909818b7275c3f1a14b2e1a174cb3ce3af249c, but should have SHA256 hash 5b8454a1d288eef2ed215f2280ac5cf9e9197ac1d2a1e46a67ba38c2c0c370e7.
/etc/ssh/sshd_config has SHA256 hash 8b0d09738d1ca74e3f8f6a1335c1e00ca1d85e49a6693784d0352e5d60f40ff2, but should have SHA256 hash 541cfd3b9b2837ac0072432210158e456fc753456ca076907ec6261d1faa73e5.
/etc/sysctl.conf has SHA256 hash 07b4c8f46a4fe5807e4bc7febf37a37a5695a4796672f293b53b78b7aea95b30, but should have SHA256 hash 45f469e7a9b4eef887bab7b55397305043fe101e1d6ce6f7e23d758e72f56dc6.
/etc/ttys has SHA256 hash 2254d276228f74a00f84cb3b87418e63709c40755acee694de097bb1da08f986, but should have SHA256 hash 233bbde35fce584ed8655483e5aa3f6f43978d27fa3fb3e55b6898f48eae7aea.
/root/.profile has SHA256 hash 7e8ff395d58921c580fb4fc9781f0fb727d9068817620904209c888a536f2a0e, but should have SHA256 hash 2b12005be6bb67838430037c0b22b66c279d3e5b22e47d7da4851e763d1e3d7c.

Das scheinen alles Änderungen zu sein, die ich bewusst vorgenommen habe. Ich habe die default shell auf die bash geändert, $EDITOR auf vim , die Firewall aktiviert, sysctl Settings für Tor vorgenommen etc.

freebsd-update fetch install
src component not installed, skipped
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching metadata signature for 14.0-RELEASE from update2.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.

No updates needed to update system to 14.0-RELEASE-p3.
No updates are available to install.

Ergibt sich daraus, warum __string/char_traits.h fehlt? Das war ja das von Netcup zur Verfügung gestellte FreeBSD13 Image, das ich dann auf 14 hochgezogen habe.

komisch... sollte/dürfte nicht so sein.

pkg install tor
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 4 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        libevent: 2.1.12
        liblz4: 1.9.4,1
        tor: 0.4.8.9
        zstd: 1.5.5

Number of packages to be installed: 4

The process will require 21 MiB more space.
3 MiB to be downloaded.

Also das liegt dann wohl daran, dass es das Paket in der aktuellen Version in FreeBSD14 nicht gibt.

ja

Ich baue da eine ganz neue VM auf, die mindestens ein Jahr lang als Tor Bridge dienen soll. Trotzdem ein FreeBSD 13 installieren und nicht das aktuelle 14?

 

[Redundanz]

Ich baue da eine ganz neue VM auf, die mindestens ein Jahr lang als Tor Bridge dienen soll. Trotzdem ein FreeBSD 13 installieren und nicht das aktuelle 14?

du kannst jederzeit upgraden sobald die pakete, die du brauchst sauber im tree sind.
und technisch gesehen ist 13.2 mehr "stable" (rein im sinne von erprobt) als 14.
die frage, die du dir stellen solltest, warum brauchst du 14...
viele features der 14er branch sind ja in die minor releases von version 13 (also .1 und .2) integriert worden.

 

[CoMo]

Ok, frisch aufgesetzt, die Warnung lautet WARNING: FreeBSD 13.1-RELEASE-p6 HAS PASSED ITS END-OF-LIFE DATE..

Dann schau ich mal, dass ich das auf 13.2 hochziehe und dann installiere ich Tor via pkg

Ergänzung (18. Dezember 2023)

Aha, freebsd-update upgrade -r 13.2-RELEASE scheint der richtige Weg zu sein.

Ergänzung (18. Dezember 2023)

Well. Ich bin auf 13.2 und tor: 0.4.8.10 wird mir angeboten. Perfekt!

Etwas weird finde ich, dass ich mich mit Passwort per SSH anmelden konnte, obwohl ich in der sshd_config sowohl PubkeyAuthentication yes wie auch PasswordAuthentication no gesetzt hatte.

Ich musste erst UsePAM no setzen, um den Passwort Login zu deaktivieren.

Aber das scheinen wohl Eigenarten von FreeBSD gegenüber Linux zu sein, die ich noch lernen muss. Ich werde mich da jetzt mal reinfuchsen. Vielen Dank für eure Hilfe!

 

[andy_m4]

Das scheinen alles Änderungen zu sein, die ich bewusst vorgenommen habe

Ja. Sieht stark danach aus. :-)

Ergibt sich daraus, warum __string/char_traits.h fehlt?

Nein. Aber hast Du mal einfach im Dateisystem nachgeguckt?
Gut. Die Frage hat sich eh erledigt, da Du ja offenbar auf FreeBSD 13.2 gegangen bist. :-)

Das war ja das von Netcup zur Verfügung gestellte FreeBSD13 Image, das ich dann auf 14 hochgezogen habe.

Was da schief gegangen ist, kann ich nicht sagen. Allerdings wenn das irgendwie ein 13.0 war und Du direkt auf 14.0 geupdatet hast, dann könnten die Probleme darin begründet liegen. Ein Major-Upgrade möchte gerne, das Du auf der aktuellsten Minior-Version bist.
Das kann aber auch einfach sein, das man beim Image bestimmte Dinge weggelassen hat, damit es schlanker ist.

Trotzdem ein FreeBSD 13 installieren und nicht das aktuelle 14?

Ansich ist das kein Problem, weil der 13er-Zweig noch ne ganze Weile supportet werden wird (und wir auch noch ein 13.3 kriegen werden). Und 14 hat jetzt auch keine Neuerungen von der tor sigifikant profitieren würde.

Zudem ists ja keine Lebensentscheidung. Ein Upgrade auf die 14 ist ja immer noch machbar. Ich denke mal, in nächster Zeit wird sich auch das Problem mit dem Package-Build erledigen und wieder die aktuellsten Pakete verfügbar sein.

Ich musste erst UsePAM no setzen, um den Passwort Login zu deaktivieren.

Eigentlich sollte es reichen zusätzlich zu PasswordAuthentication auch KbdInteractiveAuthentication auf no zu setzen.

Aber das scheinen wohl Eigenarten von FreeBSD gegenüber Linux zu sein,

Naja. In FreeBSD kommt letztlich auch nur das OpenSSH zum Einsatz, was auch unter Linux benutzt wird.
Sprich: Letztlich ist es eher ne Sache der Konfiguration

pf musste ich erst mal kennenlernen.

pf kann man natürlich nehmen. Im ersten Schritt kann aber die ipfw angenehmer sein, weil die vorgefertigte Setups anbietet, die man benutzen kann ohne erst eine eigene Konfiguration basteln zu müssen.

Noch ein genereller Tipp. Wenn man mal keine Konfigurationsdatei findet auf die man aufsetzen kann, dann kann man mal unter /usr/share/examples/ nachgucken, ob man da was findet, wo man drauf aufsetzen kann.

 

[CoMo]

So, Tor Bridge läuft. Die Firewall habe ich nach langem Gefummel so konfiguriert:

# /etc/pf.conf

# Default Deny
block all

# Allow all traffic on the loopback interface
pass in on lo0
pass out on lo0

# Allow outgoing traffic
pass out from any to any

# Allow IPv6 ICMP
pass proto ipv6-icmp from any to any

# Allow incoming traffic on vtnet1 from 192.168.0.0/16
pass in on vtnet1 from 192.168.0.0/16 to any

# Allow incoming traffic on vtnet1 (IPv6) from fc00::/8
pass in on vtnet1 inet6 from fc00::/8 to any

# Allow incoming TCP traffic on Port 22 (IPv4 and IPv6)
pass in proto tcp to port 22

# Allow incoming TCP traffic on Port XXXXX (IPv4 and IPv6) from any for Tor
pass in proto tcp to port XXXXX

# Allow incoming TCP traffic on Port 443 (IPv4 and IPv6) from any for Tor
pass in proto tcp to port 443

So scheint's zu funktionieren.

Ein Problem, über das ich gestolpert bin, war dass ich den obfs4 Prozess nicht an den Port 443 binden konnte. Unter Linux kann man das Problem ja mit setcap cap_net_bind_service=+ep lösen.

Unter FreeBSD gibt es das wohl nicht. Also habe ich das jetzt mit net.inet.ip.portrange.reservedhigh=0 gelöst. Gute Idee?

Der Server soll erst mal ausschließlich die Bridge hosten. Ich habe aktuell nicht vor, da noch weitere Dienste drauf zu packen.

Was da schief gegangen ist, kann ich nicht sagen. Allerdings wenn das irgendwie ein 13.0 war und Du direkt auf 14.0 geupdatet hast, dann könnten die Probleme darin begründet liegen. Ein Major-Upgrade möchte gerne, das Du auf der aktuellsten Minior-Version bist.

Möglich. Ich hatte direkt von 13.1 auf 14 geupgraded.

Ob Ports funktioniert, habe ich jetzt gar nicht probiert. Ich bekomme ja nun das aktuelle Paket via pkg

 

[andy_m4]

So scheint's zu funktionieren.

Ich sehe jetzt beim überfliegen auch nix grob Falsches. :-)

Also habe ich das jetzt mit net.inet.ip.portrange.reservedhigh=0 gelöst. Gute Idee?

Also ich rekonstruiere mal, wo das Problem liegt:
tor läuft nicht als root und daher hat es keine Erlaubnis sich an Ports unterhalb von 1024 zu binden.
Und diese "privilegierte" Port-Range ist durch die Kernelvariablen
net.inet.ip.portrange.reservedlow und net.inet.ip.portrange.reservedhigh definiert. Und wenn man the upper bound einfach runter setzt, kann man sich dem Problem entledigen.

Und im Prinzip kann man das so machen. Das es reservierte (root-exklusive) Ports gibt, ist ja vor allem historisch begründet. Früher hatte man betreue Netze und die Grundannahme war: "Die Administratoren sind die Guten aber die User, da kann es durchaus welche geben die Schindluder treiben". Und wenn man sich mit nem Dienst (auf einem reservierten Port) verbindet, kann man sich dann halt sicher sein, das dieser von den guten Administratoren kommt und nicht etwa ein fieser Kollege da einen User-Prozess am laufen hat um Credentials abzugreifen (oder was auch immer).

Im Internet-Kontext macht das natürlich alles wenig Sinn. Da weiß man üblicherweise ja auch nicht, von wem das administriert wird usw. Bei tor ist das ja sowieso noch mal besonders egal, weil es ja darauf ausgelegt ist, das man da keine vertrauenswürdigen Nodes drin haben kann.

Reservierte Ports sind im Kontext des Internets möglicherweise in Hinblick auf self-security relevant. Der Dienst den Du als Serverbetreiber anbietest, kann natürlich theoretisch Sicherheitslücken enthalten, der es Angreifern ermöglicht Code einzuschleusen. Der hat dann zwar nur User-Rechte aber wenn auf der gleichen Maschine ein SSH läuft und man den irgendwie dazu bewegen kann sich zu beenden, dann kann der Angreifer seinen eigenen Fake-SSHd an Port 22 starten.

Das Problem bei sowas wie net.inet.ip.portrange.reservedhigh ist, das es halt global wirkt. Ne Lösung für dieses (theoretische) Problem ist, das man net.inet.ip.portrange.reservedhigh nicht auf 0 setzt, sondern z.B. auf 442. So das alle Ports die darunter sind weiter unters Privileg fallen und nicht von User-Prozessen vereinnahmt werden können.

Oder man definiert via der Firewall eine Port-Weiterleitung, so das man tor an einen High-Port bindet und 443 dahin umlenkt.
Es gibt dann noch die Möglichkeit mit dem Mandatory Access Control Framework was zu basteln, aber das ist dann schon ziemlich "Kanonen auf Spatzen".

 

[CoMo]

Ne Lösung für dieses (theoretische) Problem ist, das man net.inet.ip.portrange.reservedhigh nicht auf 0 setzt, sondern z.B. auf 442.

Das ist ne gute Idee. Außer Tor läuft da eh nur noch der SSHd und so bleibt der 22 ein privilegierter Port. Habe ich direkt mal so umgesetzt

 

[andy_m4]

Habe ich direkt mal so umgesetzt

Du wirst es wahrscheinlich schon wissen, aber trotzdem der Hinweis:
Änderungen die Du per sysctl machst, überleben keinen Reboot. Daher solltest Du sie auch in die Datei /etc/sysctl.conf eintragen.

 

[CoMo]

Ganz genau da hab ich das gemacht. Das ist ja nicht anders als unter Linux.

cat /etc/sysctl.conf
# $FreeBSD$
#
#  This file is read when going to multi-user and its contents piped thru
#  ``sysctl'' to adjust kernel values.  ``man 5 sysctl.conf'' for details.
#

# Uncomment this to prevent users from seeing information about processes that
# are being run under another UID.
#security.bsd.see_other_uids=0
net.inet.ip.random_id=1
net.inet.ip.portrange.reservedhigh=442

 

[andy_m4]

Das ist ja nicht anders als unter Linux.

Genau. :-)

Zeig mir Deine sysctl.conf und ich sag Dir, wer Du bist. :-)

 

[CoMo]

Ich muss mich jetzt noch mal kurz hier melden, da ich mit den Updates noch nicht ganz durchblicke.

Kürzlich gab es wohl ein wichtiges Update für OpenSSH. Ich habe also mittels

freebsd-update fetch
freebsd-update install

ein Update auf 13.2-RELEASE-p9 durchgeführt. Und das hat wohl geklappt? Denn nach dem Reboot:

# freebsd-update fetch
src component not installed, skipped
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching metadata signature for 13.2-RELEASE from update1.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.
The following files are affected by updates. No changes have
been downloaded, however, because the files have been modified
locally:
/etc/ssh/sshd_config

No updates needed to update system to 13.2-RELEASE-p9.

Das System begrüßt mich aber weiterhin mit FreeBSD 13.2-RELEASE-p8 GENERIC

Und:

# freebsd-version ; uname -a
13.2-RELEASE-p9
FreeBSD vXXXX 13.2-RELEASE-p8 FreeBSD 13.2-RELEASE-p8 GENERIC amd64

Ich dachte zunächst, das SSH-Update war halt ein Notfall-Update und es gab halt bisher keinen neuen Kernel. Aber nun sind ein paar Tage vergangen und die Diskrepanz p8 <> p9 bleibt bestehen.

Ich habe das System neu gestartet, sogar testweise komplett heruntergefahren und über die Netcup-Konsole neu gestartet. Und auch danach mehrfach fetch und install durchgeführt. Habe ich irgendwas falsch gemacht?

 

[andy_m4]

Ich dachte zunächst, das SSH-Update war halt ein Notfall-Update und es gab halt bisher keinen neuen Kernel. Aber nun sind ein paar Tage vergangen und die Diskrepanz p8 <> p9 bleibt bestehen.

Genau. Das Update hat nur das Userland geupdatet. Deshalb ist auch nur dafür die Versionsnummer/Patchlevel gestiegen.
Es gibt das Tool freebsd-version. Damit lässt sich auch die Version/Patchlevel vom Userland abfragen:
freebsd-version -u

Das ist übrigens auch nur so, weil freebsd-update den neuen Kernel nicht ausgeliefert hat (wozu auch; hat sich ja nix geändert). Wenn Du jetzt ein neues System installieren würdest oder das System aus den Quelltexten selbst kompilierst, würde auch der Kernel den neuen Patchlevel haben. Ist also nicht so, das die von Kernel und Userland auseinander laufen. Beim nächsten freebsd-update haben höchstwahrscheinlich wieder den gleichen Stand.