• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

FreeBSD Security

Andy_m4

Well-Known Member
Themenstarter #1
Ich hab hier mal zusammengetragen, was ich auf meinen FreeBSD-Geräten standardmäßig einschalte zund benutze. Sozusagen Sicherheitseinstellungen, die ich eigentlich für fast immer sinnvoll empfinde (viele Maßnahmen sind ja vom Einzelfall abhängig).

Kommentare, Korrekturen oder Ergänzungen sind ausdrücklich erwünscht. Da ich ja auch nur Laie bin und hier und da sicher Fehler oder Fehleinschätzungen drin sind.

Systemaktualisierung & Management

Eine wesentliche Sicherheitsmaßnahme heutzutage ist, sein System auf dem aktuellen Stand zu halten. Da ist auch FreeBSD keine Ausnahme.

Mit freebsd-update und dem Pckage-Manager pkg stehen zwei Tools dafür zur Verfügung. Ersteres kümmert sich um die aktualisierung des Kernels und des Basis-Systems. Zweiteres für sonstige installierte Programme.

Am besten nutzt man beide Tools in Form von CRON-Jobs.

Dafür kann man sich unter /etc/cron.d/ eine Datei mit dem Namen update anlegen, welche im Crontab-Format befüllt wird:
Code:
SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin

# when  who     command
@daily  root    freebsd-update cron
@daily root pkg update --force && pkg upgrade -U -y -F
Ersteres Kommando prüft auf Systemupdates und schickt eine Mail, sobald welche vorliegen. Zweiteres guckt nach neuen Versionen der installierten Packages und lädt sie ggf. runter (installiert sie aber nicht!).

Für weitere Informationen:

Wenn man möchte, kann man auch noch folgenden Befehl von CRON ausführen lassen:
Code:
pkg audit -F
Dieser prüft, ob ein Paket installiert ist, welches momentan eine bekannte Sicherheitslücke aufweist.

Noch ein Wort zu den Packages. Standardmäßig kommen die aus dem Quarterly-Repository. Erfahrungsgemäß ist das aber nicht besonders gut gepflegt. Es kann daher eine gute Idee sein auf das Latest-Repository zu wechseln.
Man hat dann quasi für die Packages ein Rolling-Release, welches aber bei mir selten zu nennenswerten Problemen geführt hat.

Um auf das Latest-Repository umzustellen, ist die Datei /usr/local/etc/pkg/repos/FreeBSD.conf zu modifizieren bzw. zu erstellen (diese überschreibt quasi die Standardeinstellung in der /etc/pkg/FreeBSD.conf):
Code:
FreeBSD: {
  # url: "pkg+http://pkg.FreeBSD.org/${ABI}/quarterly",
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}
Tunen von Systemvariablen

Viele Dinge lassen sich über Systemvariablen einstellen, die sich über sysctl temporär im laufenden System ändern oder via /etc/sysctl.conf dauerhaft ändern lassen.

Eigene Einstellungen der /etc/sysctl.conf lassen sich schon während der Installation von FreeBSD vornehmen

Code:
# Keine Hardlinks zu Dateien die anderen Gruppen oder Benutzern gehören
security.bsd.hardlink_check_gid=1
security.bsd.hardlink_check_uid=1

# Unprivilegierte Prozesse sehen nicht Prozesse anderer User/Gruppen
security.bsd.see_other_gids=0
security.bsd.see_other_uids=0

# Überlauf-Sicherung
security.bsd.stack_guard_page=1

# Unprivilegierte Prozesse dürfen nicht auf Debug-Funktionen zugreifen
security.bsd.unprivileged_proc_debug=0

Unprivilegierte Prozesse dürfen nicht den Kernel-Nachrichtenpuffer lesen
security.bsd.unprivileged_read_msgbuf=0
Bei security.bsd.hardlink_check_gid und security.bsd.hardlink_check_uid muss man aufpassen, da dies die Funktionalität von Programmen wie Poudriere oder Mailman beeinträchtigen kann.

Es gibt aber noch weitere nützliche Einstellungen:
Code:
# Zufallswerte für Prozess-IDs
kern.randompid=1

# Kein Core-Dump für SUID-Programme
kern.sugid_coredump=0

# Verhindern, das das Keyboard-Mapping verändert werden kann
hw.kbd.keymap_restrict_change=4

# Shared-Memory Locking aktivieren, um ein auslagern zu verhindern
kern.ipc.shm_use_phys=1
Auch Netzwerkeinstellungen lassen sich hier tunen:
Code:
# Prüfe, ob Pakete ans korrekte Interface ankommen
net.inet.ip.check_interface=1

# zufallsgenerierte ID's für IP-Pakete
net.inet.ip.random_id=1

# IP-Redirects ignorieren
net.inet.ip.redirect=0

# IPv6-Redirects ignorieren
net.inet6.ip6.redirect=0

# ICMP-Redirects ignoieren
net.inet.icmp.drop_redirect=1
net.inet6.icmp6.rediraccept=0

# Drop TCP packets with SYN+FIN set
net.inet.tcp.drop_synfin=1

# Firewall ipfw für IPv6 aktivieren
net.inet6.ip6.fw.enable=1

# TCP/IP-Pakete ignorieren die sowohl SYN als auch FIN gesetzt haben
net.inet.tcp.drop_synfin=1

# TCP/IP-Pakete ignorieren, die auf geschlossene Ports ankommen
net.inet.tcp.blackhole=2

# UDP/IP-Pakete ignorieren, die auf geschlossene Ports ankommen
net.inet.udp.blackhole=1
Für IPv6 sollte man noch die Privacy-Erweiterung aktivieren

Code:
net.inet6.ip6.use_tempaddr=1
net.inet6.ip6.prefer_tempaddr=1
Wer keinen Router/Gateway betreibt, sollte darauf achten, das das IP-Forwarding deaktiviert ist:
Code:
net.inet.ip.forwarding=0
net.inet6.ip6.forwarding=0
SWAP verschlüsseln

Swap-Partitionen sind standardmäßig nicht verschlüsselt. Sie können aber durchaus sensible Informationen (Passwörter etc.) enthalten, wenn entsprechend RAM ausgelagert wird.

Dazu ist in der Datei /etc/fstab die entsprechende Zeile für die Swap-Partition durch ein .eli zu ergänzen. Siehe dazu nachfolgendes Beispiel.

Aus:
Code:
/dev/ada0p2      none  swap  sw  0  0
wird:
Code:
/dev/ada0p2.eli  none  swap  sw  0  0
Dateirechte

Die umask-Einstellungen (die also bestimmen, welche Rechte defaultmäßig neu erzeugten Dateien und Ordnern mitgegeben werden) sind mit 022 verhältnismäßig ungünstig gesetzt, da alle Nutzer standardmäßig Leserechte auf Dateien/Ordner bekommen.
Diese sollte in 027 geändert werden.

Diese Einstellung wird in der Datei /etc/login.conf vorgenommen.

Dort ersetzt man ein Vorkommendes

Code:
:umask=022:
durch
Code:
:umask=027:
Um die Änderungen wirksam werden zu lassen, muss man die login.conf mit

Code:
cap_mkdb /etc/login.conf
"kompilieren".

Bei der Gelegenheit kann man auch gleich gucken, ob irgendwelche Dateirechte unvorteilhaft gesetzt sind.
siehe dazu auch im Handbuch das Kapitel Zugriffsrechte.

Suche nach allen von jedem beschreibaren Dateien/Ordnern:
Code:
find / -perm -o+w
Wer möchte, kann dabei den gefundenen Dateien auch gleich die Schreibrechte für alle entziehen:
Code:
find / -perm -o+w -exec chmod o-r {} \;
Der Ordner /root/ ist standardmäßig für alle Nutzer lesbar. Dieser sollte nur für root lesbar sein:
Code:
chmod og-rwx /root
Ähnlich problematisch sind oft die Homeverzeichnisse unter /home bzw. /usr/home

Code:
cd /home
chmod o+rwx *
Bei folgenden Programmen und Dateien sollte auch der Zugriff durch beliebige Benutzer nicht möglich sein:
Code:
chmod o= /bin/getfacl
chmod o= /bin/setfacl
chmod o= /sbin/mount
chmod o= /sbin/umount
chmod o= /sbin/halt
chmod o= /sbin/ipfw
chmod o= /sbin/sysctl
chmod o= /usr/bin/users
chmod o= /usr/bin/w
chmod o= /usr/bin/who
chmod o= /usr/bin/last
chmod o= /usr/bin/lastcomm
chmod o= /usr/bin/ssh
chmod o= /usr/sbin/lastlogin
chmod o= /usr/sbin/jls
chmod o= /etc/crontab
chmod o= /etc/fstab
chmod o= /etc/ftpusers
chmod o= /etc/group
chmod o= /etc/hosts
chmod o= /etc/hosts.allow
chmod o= /etc/hosts.deny
chmod o= /etc/hosts.equiv
chmod o= /etc/hosts.lpd
chmod o= /etc/inetd.conf
chmod o= /etc/login.access
chmod o= /etc/login.conf
chmod o= /etc/newsyslog.conf
chmod o= /etc/rc.conf
chmod o= /etc/rc.local
chmod o= /etc/sysctl.conf
chmod o= /etc/syslog.conf
chmod o= /etc/ttys
chmod o= /etc/ssh/sshd_config
chmod o= /usr/local/etc/ntpd.conf
chmod o= /var/log/messages
chmod o= /etc/sysctl.conf
chmod o= /etc/ttys
chmod o= /etc/inetd.conf
chmod o= /etc/login.*
chmod o= /etc/fstab
chmod o= /etc/rc.conf
chmod o= /etc/ftpusers
chmod o= /etc/group
chmod o= /etc/host*
chmod o= /etc/inetd.conf
chmod o= /usr/bin/users
chmod o= /usr/bin/w
chmod o= /usr/bin/who
chmod o= /usr/bin/lastcomm
chmod o= /usr/bin/lastlogin
chmod o= /usr/bin/last
siehe: chmod(1)

Gleiches gilt für die Logdateien im Verzeichnis /var/log/

Code:
chmod o= /var/log
Für einzelne Logdateien sollte man die Rechte in der /etc/newsyslog.conf anpassen und in der Spalte mode den Wert auf 640 oder gar 600 setzen.

Wenn man möchte, kann man das Verzeichnis auch so konfigurieren, das nur Daten angehängt aber nicht mehr gelöscht werden können:
Code:
chflags sappnd /var/log
chflags sappnd /var/log/*
Allerdings muss man hierbei beachten, dass dann auch Log-Rotation (siehe logrotate(8)) nicht mehr funktioniert.

System-Passwörter mit blowfish verschlüsseln

Passwörter sind unter FreeBSD standardmäßig mit MD5 verschlüsselt. Dieser gilt nicht mehr als sicher. Es empfiehlt sich daher auf Blowfish zu wechseln. Das erreicht man mit einer Änderung in der Datei /etc/login.conf in dem man den Eintrag

Code:
:passwd_format=md5:
ändert in
Code:
:passwd_format=blf:
Um die Änderungen wirksam werden zu lassen, muss man die login.conf mit
Code:
cap_mkdb /etc/login.conf
"kompilieren".

Denk daran, das bisherige Passwörter im MD5-Format bleiben und nur neu vergebene Passwörter mit Blowfish verschlüsselt werden.

CPU - Microcode-Updates

Spätestens seit Bugs wie Meltdown wissen wir, das wir hin und wieder auch CPUs updaten müssen durch sogenannte Mikrocode-Updates.

Dafür benötigt man ein Eintrag in der /etc/rc.conf:
Code:
microcode_update_enable="YES"
Außerdem müssen die Microcode-Updates installiert werden:
Code:
pkg install devcpu-data
Firewall

FreeBSD bietet gleich 3 Firewall-Lösungen an.

Ich selbst nutze meist die ipfw, die sich auch sehr einfach konfigurieren lässt.

Um sie zu aktivieren, trägt man in der Datei /etc/rc.conf folgendes ein:
Code:
firewall_enable="YES"
Wichtig ist es dann noch ein Typ anzuigeben:
Code:
firewall_type="workstation"
Es sind mehrere Werte möglich. Näheres dazu ist im ipfw-Kapitel des Handbuches beschrieben. open erzeugt beispielsweise nur rudimentäre Regeln. Mit workstation ist eine Menge mehr Konfiguration möglich und auch (im Gegensatz wie die Bezeichnung vermuten lässt) für Server sinnvoll.

Folgende Optionen lassen sich noch setzen:
Code:
firewall_client_net="192.168.0.0/16"
firewall_myservices="80 22"
firewall_allowservices="192.168.0.0/8"
firewall_client_net definiert sozusagen des lokale LAN.
In firewall_myservices kann man Ports angeben, welche nach außen hin freigegeben werden sollen. Exemplarisch hab ich hier mal 80 (http) und 22 (ssh) genommen.
firewall_allowservices definiert das Subnetz, aus denen die freigegebenen Ports tatsächlich erreichbar sind.

Wenn man schauen möchte, welche Server-Ports durch welches Programm geöffnet sind, kann man dies mittels sockstat tun:
Code:
sockstat -l46
Mandatory Access Control mit bsdextended

Der Thematik Mandatory Access Control widmet das offizielle Handbuch ein ganzes Kapitel.

Hier möchte ich aber nur den Einsatz von bsdextended anreißen. Dieses bietet nämlich eine Vorkonfiguration die es erlaubt relativ einfach und problemlos einzusetzen.

Voraussetzung ist, das das entsprechende Modul mac_bsdextended beim Boot geladen wird durch Ergänzung der /boot/loader.conf:
Code:
mac_bsdextended_load="YES"
Nun können die default-Regeln aus der Datei /etc/rc.bsdextended in dem in die /etc/rc.conf
Code:
ugidfw_enable="YES"
aktiviert werden.

Die Datei /etc/rc.bsdextended kann noch für die eigenen Bedürfnisse angepasst werden. Ohne Änderungen sorgt sie dafür, das Nutzer nur noch auf eigene Dateien zugreifen können aber nicht Dateien fremder Besitzer.
Ausnahmen bestehen für die eigene Mailboxdateien.

Zur genauen Syntax siehe auch: ugidfw

sudo / doas

sudo ist eine gute Möglichkeit, um Admin-Aufgaben an normale Useraccounts zu delegieren.

sudo ist allerdings nicht standardmäßig installiert, sondern muss mit

Code:
pkg install sudo
nachinstalliert werden. Änderungen an der Konfigurationsdatei /usr/local/etc/sudoers sollten dabei immer mit visudo erfolgen.

Eine einfache Konfiguration im Stile der unter Linux bekannten Vorkonfiguration könnte so aussehen:
Code:
%wheel ALL=(ALL) ALL
Alle Nutzer der Gruppe wheel dürfen Kommandos via sudo ausführen.

Mehr Informationen finden sich auch im Handbuch: 13.14. Gemeinsame Administration mit Sudo

sudo ist ein recht komplexes Werkzeug, welches man auch schnell falsch konfigurieren kann.

Eine einfachere und meist ausreichende Alternative ist doas die ebenfalls übers Paketmanagement installierbar ist:
Code:
pkg install doas
Die Konfigurationsdatei liegt unter /usr/local/etc/doas.conf.

Obiges sudo-Beispiel als doas-Konfiguration:
Code:
permit :wheel keepenv
Mailserver dma als Alternative zu sendmail

Standardmäßig wird FreeBSD mit sendmail ausgeliefert.
Dieser Mailserver ist für viele Anwendungen meist überdimensioniert und viel in der Vergangenheit schon einige Male durch eklatante Sicherheitslücken auf.

Eine Alternative ist der relativ schlanke DragonFly Mail Agent. Er kann nur lokale Mails annehmen, was aber für viele Zwecke völlig ausreicht.

Installation:

Code:
pkg install dma
Konfiguration:

Anpassung der /etc/mail/mailer.conf

Code:
sendmail        /usr/local/libexec/dma
send-mail       /usr/local/libexec/dma
mailq           /usr/local/libexec/dma
Anpassung der /etc/rc.conf

Code:
# sendmail deaktivieren
sendmail_enable="NO"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"

# Dragonfly Mail Agent aktivieren
dma_enable="YES"
sendmail-spezifischen Kram in der Datei /etc/periodic.conf deaktivieren

Code:
daily_clean_hoststat_enable="NO"
daily_status_mail_rejects_enable="NO"
daily_status_include_submit_mailq="NO"
daily_submit_queuerun="NO"
ssh absichern

Auf vielen Servern ist OpenSSH verbreitet.

Die Vorgabewerte für den SSH-Server sind sicherheitstechnisch ziemlich großzügig und können (wahlweise) etwas enger gezogen werden durch Modifikation der /etc/ssh/sshd_config:
Code:
AllowTcpForwarding no
ClientAliveCountMax 2
Compression no
MaxAuthTries 3
MaxSessions 2
Port 22   # sollte auf einen non-Standard-Port gesetzt werden!
TCPKeepAlive no
UseDNS no
X11Forwarding no
AllowAgentForwarding no
Zudem sollte man natürlich Pubkey-Authentifizierung einsetzen, wie im Handbuch beschrieben:


OpenNTPd / chrony

Bei FreeBSD wird als Zeitserver standardmäßig der ntpd von ntp.org. Dieser gilt als Komplex und hatte in der Vergangenheit auch schon mit sicherheitsrelevanten Bugs zu kämpfen.

Es gibt zwei praktikable Alternativen. Einmal den OpenNTPd des OpenBSD-Projektes, der sehr viel mehr auf Sicherheit getrimmt ist.
Und Chrony, ein schlanker NTP-Server.

OpenNTPd installieren:
Code:
pkg install openntpd
Eintrag in der /etc/rc.conf:
Code:
openntpd_enable="YES"
Beispielhafte /usr/local/etc/ntpd.conf

Code:
# Bindung an bestimmte IP-Adresse wenn in Server-Rolle
#listen on 127.0.0.1
#listen on 81.35.21.0

# auf welchen Interfaces lauschen, wenn in Server-Rolle
#listen on *

# ggf.nähere Server auswählen (http://www.pool.ntp.org/zone/@)
servers de.pool.ntp.org
chrony installieren:
Code:
pkg install chrony
Eintrag in der /etc/rc.conf:
Code:
chronyd_enable = "YES"
Beispielhafte Client-only Konfiguration der /usr/local/etc/chrony.conf

Code:
# Use public NTP servers from the pool.ntp.org project.
pool 0.freebsd.pool.ntp.org iburst

# Record the rate at which the system clock gains/losses time.
driftfile /var/db/chrony/drift

# Allow the system clock to be stepped in the first three updates
# if its offset is larger than 1 second.
makestep 1.0 3

# Enable kernel synchronization of the real-time clock (RTC).
rtcsync
Beispielhafte Server Konfiguration der /usr/local/etc/chrony.conf

Code:
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
pool 0.freebsd.pool.ntp.org iburst

# Record the rate at which the system clock gains/losses time.
driftfile /var/db/chrony/drift

# Allow the system clock to be stepped in the first three updates
# if its offset is larger than 1 second.
makestep 1.0 3

# Enable kernel synchronization of the real-time clock (RTC).
rtcsync

# Enable hardware timestamping on all interfaces that support it.
#hwtimestamp *

# Increase the minimum number of selectable sources required to adjust
# the system clock.
#minsources 2

# By default chronyd binds to the loopback interface.  Uncomment the
# following lines to allow receiving command packets from remote hosts.
bindcmdaddress 0.0.0.0
bindcmdaddress ::

# Allow NTP client access from local network.
#allow 192.168.0.0/16

# Serve time even if not synchronized to a time source.
#local stratum 10

# Specify file containing keys for NTP authentication.
#keyfile /usr/local/etc/chrony.keys

# Get TAI-UTC offset and leap seconds from the system tz database.
#leapsectz right/UTC

# Specify directory for log files.
logdir /var/log/chrony

# Select which information is logged.
#log measurements statistics tracking
Kernel Secure-Level

Für den Kernel lassen sich verschiedene Sicherheitsstufen einstellen über die Systemvariable kern.securelevel
Der aktuelle Wert abfragen lässt sich mit
Code:
sysctl kern.securelevel
Der Default-Wert ist -1, also keine Security.

Es lassen sich höhere Werte setzen, wobei sich im laufenden Betrieb der Secure-Level nur erhöhen, aber nicht verringert werden kann.
Höhere Secure-Level enthalten alle Einstellungen der jeweilig niedrigen Secure-Level

Weitere mögliche Werte:

  • 0 Insecure mode
    Über chflags(1) gesetzte Dateiattribute wie append-only oder immutable lassen sich nicht wieder zurücksetzen.
  • 1 Secure mode
    /dev/mem und /dev/kmem können nicht beschrieben werden
    Kernel-Module können nicht geladen und entladen werden
    Kernel-Debugger deaktiviert
  • 2 Highly secure mode
    Dateisysteme können nicht unmounted werden
    Disks können nicht beschrieben werden
    Kernel-Time-Änderungen sind beschränkt auf 1 Sekunde (oder weniger)
  • 3 Network secure mode
    Firewall-Regeln können nicht geändert werden

Secure-Level 3 temporär setzen:
Code:
sysctl kern.securelevel=3
Secure-Level bei Systemstart via /etc/rc.conf setzen:
Code:
kern_securelevel_enable = "YES"
kern_securelevel = 3
Integritätscheck mit mtree

Mit mtree(8) lassen sich leicht Dateien auf Manipulationen prüfen.
Man kann damit von einem Verzeichnisbaum einen Snapshot von Dateimerkmalen wie Größe, Hashwert über den Inhalt, Dateiattribute machen und dann zu einem späteren Zeitpunkt vergleichen, ob ob sich daran etwas geändert hat.

Um beispielsweise eine solchen Snapshot vom Verzeichnis /usr/ anzufertigen und dabei den Hashwert mit SHA256 zu berechnen:
Code:
mtree -c -p /usr -K sha256 > /path/to/mtree-snapshot.txt
In der Datei mtree-snapshot.txt werden quasi die Informationen gespeichert. Es macht sich natürlich gut, die auf ein Read-Only-Medium zu packen oder anderwertig gegen Manipulationen zu schützen, damit etwaige Schadsoftware sie nicht ändern kann.

Zu einem späteren Zeitpunkt kann man dann folgendermaßen eine Prüfung vornehmen:
Code:
mtree -p /usr -K sha256 -f /path/to/mtree-snapshot.txt
Im Verzeichnis /etc/mtree/ finden sich übrigens auch verschiedenste Snapshot-Dateien, womit man schnell das FreeBSD-System checken kann.
Ganz ähnlich funktioniert es übrigens auch, wenn man eine Prüfung des Basis-Systems via

Code:
freebsd-update IDS
vornimmt.

Damit stellt mtree(8) eine einfache Möglichkeit da, ein simples Intrusion-Detection-System zu implementieren, in dem Dateimanipulationen erkannt werden.

Wenns ein bisschen mehr sein darf. Weitere Host-based-Intrusion-Detection-Systeme:

Sonstiges

Weitere sicherheitstechnisch nützliche Einstellungen für die /etc/rc.conf:
Code:
# /tmp beim booten löschen
clear_tmp_enable="YES"

# syslogd im Secure-Mode
# empfängt keine syslog-Nachrichten von anderen Computern
# und öffnet auch kein Socket, um welche ins Netz zu senden
syslogd_flags="-ss"

# Deaktiviere Crash-Dumps
dumpdev="NO"
Man-Page zu FreeBSD-Security: security(7)

Mit Lynis gibt es ein Programm, mit denen man sein System auf typische Schwachstellen und unsichere Einstellungen checken lassen kann. Es macht auch Vorschläge, welche Dinge man ändern könnte.

Installation:
Code:
pkg install lynis
Ausführung:
Code:
lynis audit system
Auch als CRON-Job einsetzbar.

Zum Abschluss noch ein kleiner Hinweis. Bei Änderungen in der Datei /etc/rc.conf empfiehlt es sich das Tool sysrc einzusetzen. Es ermöglicht eine sichere Änderung der /etc/rc.conf, in dem zum Beispiel verhindert wird, das Einträge doppelt vorkommen.

Das aktivieren und deaktivieren von Diensten (Services), sollte mit dem Kommando service erfolgen.

Um zum Beispiel sendmail zu deaktivieren:
Code:
service sendmail disable
bzw. zu aktivieren:
Code:
service sendmail enable
 

Esjott

Kellerkind
#5
Afaik ist dma schon im base vorhanden, nur (noch?) nicht standard.

Statt den pkg cronjob oben benutze ich
Code:
/usr/sbin/pkg version -qvRL=
in der crontab, damit bekomme ich nur eine mail, wenn neue packages (im poudriere repo) vorhanden sind, sonst Stille.

Den Rest gucke ich mir für meinen homeserver an :cool:
 

Andy_m4

Well-Known Member
Themenstarter #6
Wie wäre es mit einem Wiki Eintrag?
Das bedeutet jetzt was?

Afaik ist dma schon im base vorhanden, nur (noch?) nicht standard.
Du Afaikst richtig. Ich hab jetzt hier zwar nur FreeBSD 12.1 griffparat, aber da findet es sich (laut SVN seit Version 11.0, wenn ich das jetzt richtig sehe).

Allerdings in der Version 0.11. Bei den Ports sind sie schon bei 0.13 :-)

Aber guter Hinweis für eine Änderung.
 

lme

FreeBSD Committer
#8
Blowfish würde ich nicht zum Hashen der Passwörter benutzen. SHA1512 ist weiter verbreitet und du könntest dann die PW-Hashes auch auf anderen Unixen verwenden. MD5 wird allerdings seit ner Ewigkeit nicht mehr per default unter FreeBSD verwendet.
 

Andy_m4

Well-Known Member
Themenstarter #11
Das deine "Anleitung/Übersicht" einen besseren Ort im Wiki hätte als das sie hier in 2-3 Wochen im Forum untergeht.
Zunächst mal wollte ich ja nur gucken, ob es Ergänzungen Korrekturen gibt.
Ansonsten gebe ich Dir natürlich recht. Wenn sich das als sogar nützliches Posting herausstellt, wäre es in einem Wiki besser aufgehoben.

Ich habe weder einen github-Account noch ist mit der github-Workflow vertraut. Ich wüsste jetzt also auf Anhieb gar nicht, wie ich etwas in das Wiki bekommen sollte.

Wenn das jemand machen würde, für den das alles kein Problem ist, dann hätte ich aber natürlich nix dagegen.
Das Posting ist sozusagen public-domain. :-)

Und es ist entstanden aus Notizen für mich selbst. und liegt dadurch im Markdown-Format vor. So wie ich beim überfliegen des Links verstanden hab, ist es ja das bevorzugte Format des Wikis. Wenn also jemand zum hochladen ins Wiki die Markdown-Variante haben möchte, so kann ich die natürlich zur Verfügung stellen.
Das einfache hochladen hier im Forum scheitert leider an
Die hochgeladene Datei hat keine erlaubte Erweiterung.
 

Zirias

Well-Known Member
#12
In dem Kontext vielleicht auch interessant diese etwas kontroverse Seite: https://vez.mrsk.me/freebsd-defaults.html
Ist ein bisschen mit Vorsicht zu genießen, allerdings auch nicht ganz falsch :) Im Prinzip kann man die dort erwähnten Dinge in drei Kategorieren sortieren:
  • Nicht mehr aktuell (aber war früher mal so)
  • Hängt vom eigenen Setup ab, ob es relevant ist (z.B. läuft poudriere ja schon seit langem auch komplett in einem Jail, wenn man das will)
  • Tatsächliche aktuelle Probleme
Die grundsätzliche Forderung, defaults bei der Installation möglichst an Security auszurichten, halte ich für sinnvoll.

Jedenfalls vermittelt der Text, es sei quasi ein Ding der Unmöglichkeit, FreeBSD "sicher" zu betreiben -- dem ist definitiv nicht so, dass allerdings defaults oft nicht ideal sind dürfte immer noch der Wahrheit entsprechen.
 

Andy_m4

Well-Known Member
Themenstarter #13
Wenn man die Sachen umsetzt die da stehen, sollte man teilweise auch auf Überraschungen gefasst sein.
z.B. führt
C-ähnlich:
kern.elf64.aslr.enable=1
kern.elf64.aslr.honor_sbrk=0
kern.elf64.aslr.pie_enable=1
dazu, das Firefox nicht mehr läuft und den Start mit ein too much recursion quittiert.
Vermutlich liegt auch darin der Grund, warum manche Defaults nicht strenger sind. Weils dann nämlich Programme kaputt macht.
Nicht umsonst haben die Leute von HardenedBSD FreeBSD geforkt. Ist halt nicht mit ein paar Einstellungen getan. Hier und müssen sicher Anpassungen vorgenommen werden.
 

Crest

rm -rf /*
Mitarbeiter
#14
Man sollte auf keinen Fall die forwarding Sysctls direkt setzen. Der korrekte Weg ist über die /etc/rc.conf wie in der rc.conf Manpage beschrieben. Der Grund dafür ist das standardmäßig unter FreeBSD devd läuft und dieser auf LINK_UP messages in der Standardkonfiguration reagiert indem er /etc/rc.d/dhclient anwirft. Das kann wiederum diese forwarding Sysctls überschreiben. Diese Sysctls sollten also nicht direkt geschrieben werden sondern über die zuständigen rc.d Skripte. In dem von dir beschrieben Fall macht es keinen Sinn sie überhaupt anzufassen, weil die Defaults schon richtig sind (nämlich nicht zu routen).
 

Andy_m4

Well-Known Member
Themenstarter #17
Es geht um die Systemvariable
net.inet.ip.forwarding
für das Forwarding/Routing (siehe dazu auch im Handbuch: 31.2. Gateways und Routen) von IP-Paketen.
Das kann man ja mit sysctl setzen (oder auch in der /etc/sysctl.conf). Beispielsweise
sysctl net.inet.ip.forwarding=1
um das Forwarding einzuschalten.

Das soll man aber eher nicht machen. Stattdessen soll man in der /etc/rc.conf
gateway_enable="YES"
setzen, wenn man Forwarding wünscht.
Dieser sorgt dann dafür, dass das RC-Skript /etc/rc.d/routing die Systemvariable setzt.

Das gleiche gilt dann auch für net.inet6.ip6.forwarding respektive dem rc.conf-Pendant ipv6_gateway_enable