OpenBSD Firewall auf stable bringen

radiohead

Well-Known Member
Hi,

mein Alix Board ist ja nun bestellt und kommt hoffentlich zum WE bei mir an. Ich möchte mir also eine Firewall auf OpenBSD Basis bauen, auf der dann auch keine Compiler drauf sind. Wie patche ich aber nun mein Firewallsystem? Nehme ich mir eine virtuelle Maschine mit der gleichen Installation und baue dann da das System neu? Woher weiss ich dann aber, welche Dateien ich auf die Firewall übertragen muss?

Hat jemand ein ähnliches Szenario und praktiziert sowas schon? Für einige Step by Step Tipps wäre ich dankbar ;)
 
Es gibt keine "Binärflicken" bei OpenBSD. Eine Feuerwand ist nun auch kein klassisches Mehrbenutzersystem. Der "Dienst" der auf einer FW läuft ist nun mal der pf. Gibt es ein "Problem" mit dem pf hat der Angreifer welche Rechte? Es sollte ihm also mit diesen Rechten möglich sein, das Kompilerset zu holen und zu entpacken... oder?

OpenSSH bietet leckere Möglichkeiten, den Zugriff auf das System zu beschränken. Darauf würde ich mich konzentrieren...
 
Also soll man sein System nie patchen? Ist doch auch doof, oder?

Wie machst du es denn? Installierst dir also OpenBSD 4.2 Release und dann irgendwann mal das Update auf 4.3 Release?
 
man release

bauen, tgzs kopieren, entpacken, reboot, fertig... etc nicht vergessen (mergemaster hilft).

auf bald
oenone
 
auf der errata-seite werden patches bereitgestellt. wenn du nun ein ähnliches system (gleiche arch) hast, kannst du die sourcen (auf den cds bzw auch per ftp oder cvs) entsprechend patchen (wenn du nicht sowieso stable laufen lassen möchtest und dann per release wie oenone schon schrieb), neu bauen und dann einfach die binaries kopieren (weil ist ja die gleiche arch und was auf dem einen läuft, tuts auch auf dem anderen; deswegen gibts ja auch binaries zur installation eines release oder snapshots). was neu gebaut werden muss steht bei den patches dabei (und kommt auch als meldung nach erfolgreichem patchen). der vorgang wird auch von jacek in seinem pf-buch beschrieben, wie man die patches einbaut und was kopiert werden muss. ich persönlich bevorzuge aber ebenfalls die binary-variante mit nem selbstgebauten stable-release, den sich die maschinen bei nem upgrade per ftp holen.
irgendwie passiert es in letzter zeit zu jedem release, das zwischen freeze und release datum ein errata kommt und dann geht das geheule bei jeder gelegenheit wieder los, wann denn endlich die errata-seite für den neuen release freigeschaltet wird, weil die cd-sets etc. ja auch schon bei den leuten angekommen sind. das noch gar kein release-termin ist, stört die dann leider wenig...

hth,
marc
 
Hi,

mein Alix Board ist ja nun bestellt und kommt hoffentlich zum WE bei mir an. Ich möchte mir also eine Firewall auf OpenBSD Basis bauen, auf der dann auch keine Compiler drauf sind. Wie patche ich aber nun mein Firewallsystem? Nehme ich mir eine virtuelle Maschine mit der gleichen Installation und baue dann da das System neu? Woher weiss ich dann aber, welche Dateien ich auf die Firewall übertragen muss?

Hat jemand ein ähnliches Szenario und praktiziert sowas schon? Für einige Step by Step Tipps wäre ich dankbar ;)

Das habe ich folgendermassen gelöst. Ich habe mir ein 4.1 Release (stable) auf einer virtuellen Maschine gebaut. Dann habe ich daraus eine Release CD gebaut, von der ich meine WRAP (bzw. die Alix) installiert habe. Da die WRAP eine FW ist, ist hier nur eine minimal Installation (auf einer 256 MB CF Card).

Jetzt gibt es einen Kernelpatch für 4.1

Jetzt baue ich auf der virtuellen Maschine einen neuen Kernel und verteile den auf die WRAP und die ALIX. Leider gehen meine guten Uptimes flöten; Schade!

Das sollte es dann sein, ist nicht so komfortabel, aber auch relativ selten notwendig.
Ich gehe erst wieder auf 4.3 ;->
 
Meine Alix kam leider noch nicht an. Bekomme sie erst am Montag :(

Habe jetzt aber schon eine virtuelle Maschine aufgesetzt und dort mir nach der Anleitung http://theory.kaos.to/blog/archives/2006/01/26/how-to-build-a-stable-openbsd-install-cd-from-source/ ein stable release gebaut. Jetzt habe ich ja die tgz files in meinem RELEASEDIR liegen. Kann ich die dann jetzt einfach auf die zukünfztige Firewall übertragen und entpacken und das ist alles Tutti? Neustart brauche ich dann ja noch wegen des neuen Kernels, aber dann war es das doch oder habe ich da was falsch verstanden?

Danke für eure Hilfe!
 
Und noch einer...

Sollte jetzt ein Patch für z.B. den DHCP Server kommen, dann baue ich den Patch also in meiner virtuellen Maschine ein. Woher weiß ich dann, was ich alles auf die Firewall kopieren muss? Nur die dhcpd binary Datei? Oder gibt es eine Möglichkeit zu sehen, was alles an Dateien zu dem jeweiligen Patch gehört?
 
Ne, ich habe reichlich bemessene HW für mein Feuerwall. Ich habe den Kompilierer mit drauf. Wenn es erforderlich ist, einen Flicken zu nähen, dann tue ich das umgehend.

Mit nice kannst Du ja das "machen" freundlich gestalten. Erst mit einem make install werden die Sachen an Ort und Stelle kopiert. Macht sich natürlich schlecht, wenn man das System ro eingebunden hat.

An Deiner Stelle würde ich nur die Version in der VM pflegen (Flicken, Konfigurationsänderungen etc.). Wenn es erforderlich ist, würde ich mir dann das System auf die CF-Karte(n) neu schreiben und die Kiste verpflanzen. Das minimiert die Ausfallzeit lediglich auf das Neustarten und das Tauschen der CF.

Minimiere die Einfallsvektoren. Dann kann man auch mit einem selbst gebauten Feuerwall Nachts noch ruhig schlafen. :-)
 
So meinte ich das ja auch. Ich baue immer in der VM neu und dann will ich es rüberkopieren. Wenn ich mir ein stabe Release gebaut habe, kopiere ich ja einfach die tgz rüber und entpacke die.

Aber stimmt, bei einem ro System geht das ja auch wieder nicht. Oh mann, da werde ich erstmal einiges zu testen haben, wie ich das am besten mache. Aber eigentlich wollte ich dann immer nur die neuen Sachen rüberkopieren.

Jemand ne Ahnung ob ich das Entpacken eines tgz files auch irgendwie in eine ssh Session pipen kann, damit ich die tgz files nicht auf die CF kopieren muss, bevor ich sie entpacke?
 
Klar geht das:
Code:
cat tardatei.tgz | ssh user@andererhost tar xz -C / -f -

Zumindest so in etwa, habs jetzt nicht ausprobiert und bislang nur in die andere Richtung gemacht.

Gruß
Reks30
 
Zurück
Oben