[erledigt] Rootserver, FW: UEFI/SecureBoot oder Legacy BIOS?

[BenutzerGa4gooPh]

Ich möchte nächste Woche eine private, dedizierte Firewall installieren, wahrscheinlich PFSense. Diese FW hängt ja dann direkt am Internet, deshalb kann ich diese wegen Sicherheitsbedarf/Gefaehrdung wohl als eine Art "Root-Server" betrachten. Ich habe nun Fragen an diejenigen, die sich mit Rootservern auskennen:

UEFI ist zumindest umstritten: Werden Rootserver deshalb ueblicherweise mit Legacy BIOS installiert?

Secure Boot fällt mit Legacy BIOS dann wohl aus. (Ging aber früher auch gut ohne.)

Das Secure-Boot-Feature wurde mit der Version 2.3.1 des BIOS-Nachfolgers 'Unified Extensible Firmware Interface' (UEFI) spezifiziert und soll die Sicherheit des Bootvorgangs erhöhen. Unter anderem soll Secure Boot Schadsoftware daran hindern, den Bootvorgang des Rechners zu manipulieren und so etwaige Sicherheitsmechanismen des Betriebssystems zu umgehen.
Umgesetzt wird dies durch einen digitalen Schlüssel. Nur Software, die sich über einen entsprechenden Schlüssel identifizieren kann, wird vom UEFI beim Computerstart geladen. Darunter fällt unter anderem der Bootloader von Microsoft, aber auch einige Linux-Distributionen arbeiten an einer Unterstützung für Secure Boot.
Jegliche Software, die über keinen entsprechenden Schlüssel verfügt, wird am Laden gehindert. Dies betrifft derzeit unter anderem verschiedene Linuxdistributionen aber auch ein Booten via USB-Stick wird durch Secure Boot verhindert, wenn auf diesem kein signierter Schlüssel vorhanden ist.

http://www.tweakpc.de/hardware/infos/pc ... rt/s01.php

Ich würde die Firewallsoftware genau so installieren, wie "erfahrene Hasen" Rootserver installieren, also entweder mit Legacy BIOS oder mit UEFI und SecureBoot (so es mit PFSense oder IPFire geht) - und mache damit nichts falsch? Also sagt bitte mal, in welchem Modus Ihr Rootserver/Internet-Server installiert! Und warum. Macht Euch nicht so viel Arbeit, manchmal genügt schon ein gut gewählter Link.

Ein schönes WE wünscht Euch Jana.

[rendegast]

Die Kernel von debian gibt es mittlerweile auch signiert, Bsp.

Code: Alles auswählen

$ grep -i benh /boot/config-*
/boot/config-4.6.0-0.bpo.1-amd64:CONFIG_SYSTEM_TRUSTED_KEYS="debian/certs/benh@debian.org.cert.pem"
/boot/config-4.7.0-0.bpo.1-amd64:CONFIG_SYSTEM_TRUSTED_KEYS="debian/certs/benh@debian.org.cert.pem"

Hier taucht NICHT der auch installierte 3.16.0-4 jessie auf,
eine Installation/Betrieb mit dem jessie Standarkernel unter secure-boot wird wohl nicht funktionieren.

[BenutzerGa4gooPh]

Hhm. So ich richtig verallgemeinere, heißt das: Server laufen sinnvollerweise mit stable, Jessie mit Kernel 3.16 ist aktuell stable, demzufolge momentan (und meist - wenn doch, dann aus Backports) kein signierter Kernel auf Debian-Servern. Heißt also, ich kann SecureBoot und damit UEFI guten Gewissens weglassen. Prima!
Danke dir und notfalls korrigiere bitte.
Uebrigens, interessante Herangehensweise an meine Frage!

[r4pt0r]

Da SecureBoot-implementierungen oft für Einschränkungen oder "Features" von OEMs - die als "untrusted" betrachtet werden müssen - genutzt wird, ist dieser Rohrkrepierer bei mir grundsätzlich deaktiviert. Zudem sind die "golden keys" von MS schon längst im umlauf; somit kann praktisch alles signiert werden und wird von SecureBoot freundlich durchgewunken.

Ansonsten sollte IMHO jedes moderne (=in den letzten ~10 Jahren gebaute) System per EFI gebootet werden - allein da man damit nicht mehr auf zufällige mappings der Platten angewiesen ist, damit der bootloader gefunden wird. Muss man Grub verwenden hat man damit schon ein ausreichend wackeliges Kartenhaus, da muss man sich nicht auch noch Legacy-boot ans Bein hängen.
Was ich persönlich aber grundsätzlich deaktiviere ist der Netzwerkstack des UEFI. Hier kann man nur ahnen welche gremlins dort wohnen - bei der qualität vieler (aller) Firmwares ist direkter Netzzugang das letzte was ich dafür haben will. Server-/"Enterprise"-systeme lassen diese Deaktivierung i.d.r. zu bzw einige haben den stack erst garnicht integriert; speziell wenn ein BMC/IPMI vorhanden ist. IIRC handhabt es z.b. Supermicro auf diese Weise.

Falls es dir um Kompromittierung des Servers durch physischen Zugriff geht: Ein Server an den nicht authorisierte Personen rankommen und womöglich auch beliebig lange herumspielen können, muss spätestens nach dem ersten nicht selbs ausgelösten Reboot als Komprommitiert angesehen werden. Deshalb sucht man sich einen Hoster oder RZ nicht nur nach dem besten Preis aus... In Firmengebäuden muss der Zugang zum Serverraum und/oder Rack entsprechend beschränkt werden.


PFSense lässt sich problemlos per EFI oder Legacy booten. Der FreeBSD-bootloader ist seit einiger Zeit universell bzw es werden beide Varianten auf die Platte geschrieben; man muss sich nicht für eine Variante entscheiden und kann das installierte System auf beide Varianten booten. Ich bin gerade aber nicht sicher ob das schon vollständig zu PFSense durchgesickert ist. Da die aber erst vor kurzem auf 10.3-RELEASE gewechselt haben sollte das der Fall sein. Am besten die Releasenotes genau anschauen.
Alternativ zu PFSense kannst du dir ggf auch OPNSense anschauen - das ist deutlich näher an "vanilla" FreeBSD und kann damit auch schneller auf updates, securityfixes etc reagieren. Mittelfristig soll es möglich werden, OPNSense einfach als Paket über eine vorhandene installation von FreeBSD zu installieren. Was OPNSense nicht kennt, verwaltet es dann einfach nicht über die GUI; man kann die dienste aber problemlos betreiben und ist damit wesentlich flexibler.
PFSense hat eine völlig eigene Konfigurationsstrategie und darauf angepasste pakete sowie ein entsprechend umgestricktes OS, man ist also vollständig an PFSense und die verfügbaren pakete gebunden.

Für eine kleine Firewall mit schwacher Hardware wäre evtl auch smallwall interessant. Das ist eigentlich der legitime Nachfolger des eingestellten M0n0wall-Projekts. Kompakt, schlank, no-BS und damit sehr Ressourcenschonend.

[BenutzerGa4gooPh]

Danke r4pt0r. Also sind wir bei UEFI aber ohne SecureBoot.
(Mir geht es nicht um phys. Kompromittierung der FW, ist meine private.)

Was ich persönlich aber grundsätzlich deaktiviere ist der Netzwerkstack des UEFI.

Meinst du damit, einfach PXE-Boot (Boot ueber Netzwerk) im BIOS abschalten?

[r4pt0r]

Es gibt i.d.r. eine Option "UEFI Networking" oder ähnliches. Diese deaktiviert die Netzwerkfähigkeit des UEFI z.b. für Firmwareupdates direkt aus dem UEFI übers Internet. Daran gekoppelt ist teilweise auch die PXE-Bootfähigkeit - beim ASUS P9D-C/4L ist das z.b. der Fall. Die letzten beiden Supermicro Systeme die ich eingerichtet habe, hatten einen eigenen Menüpunkt für PXE-Boot, der auch bei deaktivierten 'UEFI network capabilites' weiterhin aktivierbar war. Ob PXE dann wirklich funktioniert hätte, habe ich aber nicht ausprobiert (PXE wurde sowieso deaktiviert).

Bei Acer ist UEFI besonders pikant, da man hier dessen Netzwerkfähigkeit für ein propretäres Verwaltungstool verwenden kann. Ist gedacht für große Enterpriseumgebungen, ist aber per default aktiviert - zumindest bei den kleinen desktop-komplettsystemen. Diese wurden bei uns bis vor ca 2 Jahren für unsere Clients gekauft, bis ich mich zum x-ten male beschwert hab, dass die kisten völlig überteuert sind und deren BIOS/UEFI völlig verbugt ist (PXE bei vielen nicht möglich, USB-Booten nur von manchen ports usw...). Jetzt ist leider das ganze Firmennetz mit den Dingern verseucht

Zum Thema Fernwartung: Wenn das System kein BMC/IPMI besitzt, aber ein anderer Server in direkter Nähe ist, verwende einfach die seriellen Schnittstellen. Wenn je 2 vorhanden sind geht das sogar "über kreuz" - auf com1 ist die Konsole des jeweiligen systems, com2 ist jeweils auf com1 des anderen Systems verbunden. So kann man beim Ausfall eines Systems per ssh aufs andere zugreifen und sich auf die serielle Konsole verbinden. Hat man die Konsolenweiterleitung im BIOS aktiviert, kann man dem system beim kompletten Bootvorgang zuschauen und ggf eingreifen (z.b. singleuser mode booten).
PFSense bzw FreeBSD lässt sich auch direkt über die Konsole installieren - Der Bootloader erkennt ob Tastatur und Grafikadapter angeschlossen sind und wechselt ggf zur comconsole. Ansonsten lässt sich auch auf dem fertigen USB-Stick die /boot/loader.conf um 'console="comconsole"' ergänzen. So habe ich die letzten male meinen Testserver zuhause vom Schreibtisch aus neu installiert - USB-Stick einstecken, einschalten und dann in der ssh-session auf dem anderen Server auf die Konsole zugreifen.

[BenutzerGa4gooPh]

Also jetzt bringst du mich durcheinander:
Wenn ich die erste Hälfte deines letzten Beitrages lese, fühlt es sich doch sicherer an, die FW im Legacy Mode zu installieren. Die FW enthält nur 1 SSD und damit kann ich Nachfolgendes schmerfrei in Kauf zu nehmen, zumal es früher auch (gut) ohne EFI ging:

Ansonsten sollte IMHO jedes moderne (=in den letzten ~10 Jahren gebaute) System per EFI gebootet werden - allein da man damit nicht mehr auf zufällige mappings der Platten angewiesen ist, damit der bootloader gefunden wird. Muss man Grub verwenden hat man damit schon ein ausreichend wackeliges Kartenhaus, da muss man sich nicht auch noch Legacy-boot ans Bein hängen.

Na ja, ich schaue mir das BIOS genau an, ob ich den UEFI-Nezwerkstack und nicht nur PXE deaktivieren kann. Wenn nicht, ist wohl bei meiner kleinen, dedizierten FW-Büchse mit 1 SSD Legacy BIOS sicherer.

[smutbert]

Selbst wenn du im BIOS/CSM/Legacy-Modus installierst, ist das uefi ja immer noch da. Für das Booten im BIOS-Modus ist ein bestimmtes UEFI-Modul und zwar das CompatibilitySupportModule verantwortlich. Auf welche Art du das System booten willst ändert also afaik nichts daran, dass es wahrscheinlich (?) sicherer ist "UEFI Networking" oä zu deaktivieren.

(mir wäre übrigens der uefi-Modus lieber, weil es mir sympathischer ist den Bootloader in einer normalen Datei auf der EFI System Partition zu haben, statt ihn in Teilen über MBR, Partitionsbootsektoren, BIOS Bootpartionen oder weitere ungenutzte Bereiche der Festplatte verteilt zu wissen)

[BenutzerGa4gooPh]

Na, wenn 2 Experten sich einig sind ... wäre ich ja schön blöd, was Anderes zu tun. Danke!

Eine theoretische Frage stellt sich noch: Wird im Legacy Modus der UEFI-Netzwerkstack nicht (implizit) deaktiviert oder ist zumindest nutzlos? (Ich habe jetzt gar keine Idee, wie man das ermittelt. In meinem BIOS finde ich keine Option für EFI-Networking, sonst könnte ich ja einfach die Abhängigkeit dieserr Option zum Boot-Modus Legacy/UEFI nachsehen.)

[DeletedUserReAsG]

Bei den heutigen Firmware-Menüs gibt’s immer noch das gleiche Problem, wie bei den BIOS-Menüs: der eine Hersteller hat diese Möglichkeit, der andere jene, bezeichnen tut’s eh jeder, wie er lustig ist – gut möglich, dass es bei dir diese Option einfach nicht gibt. Ich habe auch so ein Board, bei dem die Firmware schon ins Netz könnte und das nicht sicher deaktivierbar ist; allerdings ist es auf DHCP angewiesen, was die Sache nicht ganz so dramatisch macht, zudem ist das Gerät nicht direkt am Netz: meine Schnittstelle zum Netz ist ein ARM-Board, und das hat weder UEFI, noch BIOS und das Einzige, was dessen hartcodierte Firmware kann, ist einen bestimmten Block von der SD-Karte zu laden. Halte ich noch mit für die sicherste praktikable Möglichkeit.

[BenutzerGa4gooPh]

Danke auch dir. Ich habe auch mal überlegt, einfach eine embedded Version (die meisten Router/Firewall-Distris bieten beides) zu nutzen, aber damit verbaue ich mir squid, snort etc. Will ich wenigstens mal probieren, auch wenn es für mein bisschen Kram eher oversized ist.

Gut, ein Thread ist nicht nur für einen selbst, deshalb noch eine recht gute Website zu UEFI, Unterseite Legacy/CSM, die auch smutberts Hinweise ausführlich erläutert, bestätigt: http://www.rodsbooks.com/efi-bootloader ... -ugly.html

r4pt0rs und niemands Beitraege zu verschiedenen FW-Distributionen fuehrte mich u. a hierhin:
https://en.m.wikipedia.org/wiki/List_of ... tributions
https://distrowatch.com/search.php?osty ... tus=Active
Die Qual der Wahl, zumindest für x86_amd64-Hardware.
Ich ziehe mal PFSense und OPNSense und IPFire in nähere Betrachtung, mit PFSense beginne ich, schon etwas eingelesen.

Edit: Eine deutsche Distri mit ISDN-Support: http://www.fli4l.de/fileadmin/doc/deuts ... index.html

[r4pt0r]

Problem bei vielen BIOS und aktiviertem Legacy-Modus: Der EFI-Modus ist dann oft fehlerhaft. Ich habe mehrere Geräte im einsatz, die nur bei völlig deaktiviertem Legacy/Compatibility-Mode sauber und erfolgreich/zuverlässig per EFI booten. Wenn möglich deaktiviere ich daher alles was mit Legacy/Kompatibilität/Steinzeit zu tun hat (ebenso wie alles andere was nicht benötigt wird - also ggf Sound, Grafik etc pp...). Auch die diversen proprietären Fastboot/Quickstart/Rapidstart/... Lösungen mancher Hersteller deaktiviere ich grundsätzlich, da sie nicht selten Probleme mit Suspend oder Warmstarts verursachen.

@Embedded/ARM:
Für FreeBSD auf ARM sind auch squid und snort verfügbar, somit auch zumindest für OPNSense.
Snort ist aber _sehr_ Ressourcenintensiv; da muss also schon ein recht aktueller high-end ARM vorhanden sein. Auf nem gateway mit nem alten Xeon L5410 und ein paar aktiven filtern, verursacht snort Lasten von 0.8-1.8 je nach Traffic - mindestens ein Kern ist also konstant von snort ausgelastet. Mit nem Spielzeug-ARM aus nem Plastikrouter wird das also nix...

Wenn IDS nicht direkt an der FW laufen soll/muss, wären mit ARM ggf auch die ClearFog Boards von solidrun interessant: https://www.solid-run.com/marvell-armad ... /clearfog/

Für maximale Flexibilität greife ich persönlich zu x86 Hardware. Für den Heimgebrauch kann man recht günstig ehemalige/ältere NetworkAppliances ohne Lizenz/Betriebssytem auf ebay erstehen Ich habe Zuhause z.b. 2 ältere Infoblox in Betrieb: Stückpreis 40 EUR + paar EUR für leise Lüfter, kleine SSD und für 25 EUR gabs noch 8GB RAM für einen der beiden (darauf laufen u.a squid als cache + mehrere privoxy und tor). Unterm Strich also <200EUR für 2 Systeme mit je 4x Intel GBit NIC...

[BenutzerGa4gooPh]

Problem bei vielen BIOS und aktiviertem Legacy-Modus: Der EFI-Modus ist dann oft fehlerhaft. Ich habe mehrere Geräte im einsatz, die nur bei völlig deaktiviertem Legacy/Compatibility-Mode sauber und erfolgreich/zuverlässig per EFI booten. Wenn möglich deaktiviere ich daher alles was mit Legacy/Kompatibilität/Steinzeit zu tun hat (ebenso wie alles andere was nicht benötigt wird - also ggf Sound, Grafik etc pp...). Auch die diversen proprietären Fastboot/Quickstart/Rapidstart/... Lösungen mancher Hersteller deaktiviere ich grundsätzlich, da sie nicht selten Probleme mit Suspend oder Warmstarts verursachen.

Mache ich so, danke.

Wenn IDS nicht direkt an der FW laufen soll/muss, wären mit ARM ggf auch die ClearFog Boards von solidrun interessant: https://www.solid-run.com/marvell-armad ... /clearfog/

Das Board gefällt mir auch, allerdings 250 Euro mit Gehäuse und Netzteil und ohne WLAN. Und nur OpenWrt laut Hersteller moeglich. Was aber im allgemeinen genügen sollte.
OpenWrt wird wohl gerade geforkt? LEDE?

Für maximale Flexibilität greife ich persönlich zu x86 Hardware.

Habe ich auch bestellt, vielleicht schreibe ich mal einen Erfahrungsbericht. Damit ist nahezu jede FW-Distri möglich. Und dieses eigenartige "Flashen", was ja auch Risiken (Bricking nennt das wohl die Fachwelt) birgt, entfällt.

Ich habe Zuhause z.b. 2 ältere Infoblox in Betrieb: Stückpreis 40 EUR + paar EUR für leise Lüfter, kleine SSD und für 25 EUR gabs noch 8GB RAM für einen der beiden (darauf laufen u.a squid als cache + mehrere privoxy und tor). Unterm Strich also <200EUR für 2 Systeme mit je 4x Intel GBit NIC...

Ist zwar nun zu spät, weil Geraet da, habe aber aufgrund deiner Worte mal bei EBay nach " Network Appiance" gestoebert: 19 Zoll und Stromverbrauch und Aufpassen muss man auch: Auf eine Cisco-Appliance passt wohl nur Ciscos IOS. Juniper war auch im Angebot. Aber was tut man nicht für Hobbies. Jedenfalls meine Familie steckt mich in 's Heim, wenn ich mit 19 Zoll beginne und Vitrine gegen Schaltschrank (mit Glastür) tausche.

Schönen Abend, r4pt0r!

PS: Extra wegen dir mal gesucht: https://de.m.wikipedia.org/wiki/Raptor
(Hatte irgendeine Erinnerung an Jurassic Park, da gab es so gefräßige, kleine ... erfolgreiche ... . )

[r4pt0r]

Das Board gefällt mir auch, allerdings 250 Euro mit Gehäuse und Netzteil und ohne WLAN. Und nur OpenWrt laut Hersteller moeglich. Was aber im allgemeinen genügen sollte.
OpenWrt wird wohl gerade geforkt? LEDE?

OpenWRT wird halt aufgeführt da es den höchsten buzzword-faktor hat. FreeBSD läuft auch auf ARM, mit 11.0 kam auch ARMv8 dazu. Die ClearFog boards wurden schon ende 2015 erfolgreich getestet: https://www.freebsd.org/news/status/rep ... -Armada38x

Ist zwar nun zu spät, weil Geraet da, habe aber aufgrund deiner Worte mal bei EBay nach " Network Appiance" gestoebert: 19 Zoll und Stromverbrauch und Aufpassen muss man auch: Auf eine Cisco-Appliance passt wohl nur Ciscos IOS. Juniper war auch im Angebot.

Das sind im innern normale Serversysteme - SSD rein und per USB + Serieller Konsole installieren was man braucht. Schlimmstenfalls muss man das BIOS upgraden da es teilweise passwortgeschützt und ziemlich vernagelt ist - ist bei fast allem was EFI hat direkt aus der EFI-Konsole möglich, man muss sich also nicht mit irgendwelchen DOS-Tools rumschlagen.
Ja, Stromverbrauch ist etwas höher als mit nem kleinen ARM-Board - wenn ich aber hochrechne was ein Embedded-System mit 4x GBit NIC kosten würde, kann ich die Infoblox locker noch einige Jahre laufen lassen...

Aber was tut man nicht für Hobbies. Jedenfalls meine Familie steckt mich in 's Heim, wenn ich mit 19 Zoll beginne und Vitrine gegen Schaltschrank (mit Glastür) tausche.

Bei mir steht ein kleines, rollbares open-frame rack hinterm sofa - da drin sind auch storagesystem, USV, switch, WLAN-AP und Kabelmodem verstaut und alles ist sauber verkabelt. Das ist definitiv aufgeräumter und sauberer als wenn alles lose in der ecke steht/liegt und staub frisst...

[BenutzerGa4gooPh]

Du schreibst informative Beiträge - die einen ins Grübeln bringen. Wollte zwar PFSense installieren - aber ich gehe jetzt erst mal per Web deinem Hinweis nach, mich drängt ja nichts:

Alternativ zu PFSense kannst du dir ggf auch OPNSense anschauen - das ist deutlich näher an "vanilla" FreeBSD und kann damit auch schneller auf updates, securityfixes etc reagieren. Mittelfristig soll es möglich werden, OPNSense einfach als Paket über eine vorhandene installation von FreeBSD zu installieren. Was OPNSense nicht kennt, verwaltet es dann einfach nicht über die GUI; man kann die dienste aber problemlos betreiben und ist damit wesentlich flexibler.
PFSense hat eine völlig eigene Konfigurationsstrategie und darauf angepasste pakete sowie ein entsprechend umgestricktes OS, man ist also vollständig an PFSense und die verfügbaren pakete gebunden.

Doku lesen, im entsprechenden Forum stöbern ... .