SSL kaputt ... Heartbleed Bug

Du musst noch die Umgebungsvariable UNAME_r überschreiben. Also sowas wie UNAME_r=10.0-RELEASE
 
-Nuke- schrieb:
Du musst noch die Umgebungsvariable UNAME_r überschreiben. Also sowas wie UNAME_r=10.0-RELEASE
Zum Vergrößern anklicken....

Danke für den Hinweis :) Leider klappt das irgendwie nicht...

Code: 
setenv UNAME_r 10.0-RELEASE
ezjail-admin update -U -s 10.0-RELEASE-p1
freebsd-update: Cannot upgrade from 10.0-RELEASE to itself

Mit der Option "-s 10.0-RELEASE" (ohne Patchlevel) geht es auch nicht:
Code: 
setenv UNAME_r 10.0-RELEASE
ezjail-admin update -U -s 10.0-RELEASE
freebsd-update: Cannot upgrade from 10.0-RELEASE to itself

Habt ihr da eine Idee, woran das liegt? :)
 
Aha :) Jetzt ging es so:

Code: 
setenv UNAME_r 10.0-RELEASE
ezjail-admin update -u

Mal schauen, ob nach den Reboot auch wirklich alles passt... *daumen drück*

Nachtrag: Jup, alle Jails haben neugestartet, alles passt :)
 
@Vektoren: das ist klar. Du versuchst von 10.0-RELEASE auf 10.0-RELEASE zu aktualisieren. Wenn der Host auf 10.0-RELEASE-p1 läuft, kannst du einfach
Code: 
ezjail-update -u
benutzen, dann bekommst du die gleiche Version wie das Hostsystem.

EDIT: Ups, hab die Folgebeiträge übersehen.
 
Kann man eigtl. irgendwie in den Webserver Logs nach pattern suchen, um einen potentiellen Heartbleed Angriff zu erkennen?
Wenn ja, was waeren denn potentielle Patterns?

LG
 
Du muss eigentlich nur schauen ob Payload-Länge (nullterminiert) nicht mit der angegebenen Länge zusammenpasst.
 
In Web-Server-Logs nicht. Der Angriff hinterlässt keine Spuren dort. Du solltest ein IDS (zum Beispiel snort) laufen lassen, wenn Du es aufdecken möchtest.
 
für iptables habe ich ein simples Ruleset basieren auf u32 gesehen. Hat jemand ein Equivalent unter pf im Einsatz? "52=0x18030000:0x1803FFFF"
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben