• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

alte opentls-Verion updaten

Lord_Icon

Member
Hi,

ich hab hier ein alten Kundenserver am wickel, der in ca. 1-2 Monaten ersetzt wird. Verübergehend benötige ich aber eine aktuelle TLS Version.

Akueller Stand 0.9

ein apt-get update würde mir aber etliche Pakete mit upgraden, wo ich nicht weiß, ob die neuen Pakete nicht andere Dienste lahm legt.

Somit würde ich nur das Paket openssl aktualiseren.

apt-get ist aber aktuell nicht sehr hilfreich, da ich mir erstmal nur die abhängigkeiten anzeigen lassen wollen würde. Also erstmal nur testen, ob tatsächlich nur openssl oder auch noch andere libs oder sogar der apache2 mit geupdatet werden muß.

mittels ... kann ich mir ja schon mal die Abhängigkeiten von openssl selbst anzeigen lassen.
Code:
apt-cache show openssl | grep Depends
Depends: libc6 (>= 2.7), libssl0.9.8 (>= 0.9.8m-1), zlib1

Fraglich ist hier (für mich jetzt erstmal):
Sind das die abhängigkeiten für die NEUE Version oder für die aktuell installierte ?

Frage 2:
Wie lautet der Befehl um openssl (und nur dieser Dienst) zu updaten... VORHER aber eine Prüfung der Abhängikeiten durchführt ?

Danke
 
Last edited by a moderator:
Sehr verwunderlich das du sowas fragst..

Kurz gesagt: Ohne "alles" gegen die neue Openssl Version zu kompilieren wird das nichts. Lass die Finger von irgendwelchen Versuchen.
 
Ich vermute mal, du willst openssl von einer neueren Debian bzw. Ubuntu-Version installieren. apt-cache greift für die Informationen der lokalen Paket-Datenbank zurück - sofern du diese schon aktualisiert hast, sind es die neuen Versionen. Im Falle von openssl kannst du es aber an der Version von libssl erkennen, diese entspricht der Openssl-Version.
Da du aber sinnvollerweise das betreffende Debian-Paket herunter geladen hast, kannst du die informationen für diese deb-Datei per dpkg auslesen:
Code:
dpkg -I dateinname.deb
Allerdings solltest du auch ermitteln, welche anderen Pakete von dem zu aktualisierenden abhängen, falls dieses das alte ersetzt und nicht parallel installiert wird. Sonst sind deren Abhängigkeiten möglicherweise nicht mehr erfüllt.
 
Wie DjTom-i schon sagt wird ein solcher Versuch nicht funktionieren und bei manueller Installation den Server fachgerecht in Einzelteile zerlegen. Ich hab sowas auch schon mal versucht...

Wenn es um einen spezifischen Dienst geht kannst du ggf über einen chroot mit debootstrap fahren in welchen die entsprechenden Pakete installiert werden und dann über "bind --mount" /proc, /sys und die benötigten Dateipfade reingepanscht werden. Nicht sauber, nicht schön aber durchaus als "schnelle" Notlösung funktional.
 
oki. Danke euch erstmal.

OpenSSL ist damit erstmal durch:
Code:
OpenSSL 1.0.2l  25 May 2017

Es gibt zwar noch eine August Version aber die kann ich ja später nochmal händisch kompiliern.

Leider bin ich noch nicht am Ende, da CURL-php immer noch mit der alten Version arbeitet.

Code:
curl 7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 [COLOR="Red"]OpenSSL/0.9.8o[/COLOR] zlib/1.2.3.4 libidn/1.15 libssh2/1.2.6
Protocols: dict file ftp ftps http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

hier hab ich mir wohl apt-get zerschossen.
Mittels: apt-get -t testing install curl hab ich es erstmal testen wollen.
Wäre wohl besser gewesen, wenn ich es erstmal simuliert (apt-get install -simulate curl ) hätte.
Denn jetzt erhalte ich unerfüllte Abhängigkeiten, die aufgelöst werden können :mad:

Code:
[B]apt-get -f install[/B]
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Statusinformationen werden eingelesen... Fertig
Abhängigkeiten werden korrigiert... Fertig
Die folgenden zusätzlichen Pakete werden installiert:
  binutils libc-bin libc6
Vorgeschlagene Pakete:
  binutils-doc glibc-doc
Die folgenden Pakete werden aktualisiert (Upgrade):
  binutils libc-bin libc6
3 aktualisiert, 0 neu installiert, 0 zu entfernen und 290 nicht aktualisiert.
8 nicht vollständig installiert oder entfernt.
Es müssen noch 0 B von 7.243 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 14,2 MB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren [J/n]?

Vorkonfiguration der Pakete ...
(Lese Datenbank ... 30562 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Ersetzen von libc6 2.11.3-4 (durch .../libc6_2.24-11+deb9u1_amd64.deb) ...
dpkg: Fehler beim Bearbeiten von /var/cache/apt/archives/libc6_2.24-11+deb9u1_amd64.deb (--unpack):
 ci-Triggerdatei enthält unbekannte Anweisung »activate-noawait«
configured to not write apport reports
                                      Fehler traten auf beim Bearbeiten von:
 /var/cache/apt/archives/libc6_2.24-11+deb9u1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Sicherheitshalber frage ich jetzt lieber nach, bevor ich das System weiter zerschieße.

Danke für Tipps
 
fehlende Abhängikeiten bzw. fehlerhafte pakete neu installieren, sodass apt-get wieder funktional wird
 
ich hab hier ein alten Kundenserver am wickel, der in ca. 1-2 Monaten ersetzt wird.

An dieser Stelle mußt du ansetzen.
Laut OpenSSL-Changelog ist die Version 0.9.8m vom März 2010. Dementsprechend sind alle anderen installierten Pakete ähnlich veraltet.
Aufgrund der Unmengen an Sicherheitslücken, die seitdem gefunden und gefixt wurden, ist der Server als kompromittiert zu betrachten.
Mach deinem Kunden nachdrücklich klar, daß er jetzt nicht noch wochenlang mit diesem Softwarestand weiterarbeiten sollte.
Wenn auf dem Server sensible Kundendaten verwaltet werden (z.B. Webshop o.ä.), dann ist das Ganze auch aus datenschutzrechtlichen Gründen mehr als grenzwertig, da dein Kunde (durch dich) von der veralteten Software und von den Sicherheitslücken und damit auch von der Angreifbarkeit des Systems weiß.

Sicherheitshalber frage ich jetzt lieber nach, bevor ich das System weiter zerschieße.

Danke für Tipps

Hier gibt es nur einen einzigen sinnvollen Tip:
Fahr die Kiste runter, boote ins Rescue, mach im Rescue eine Datensicherung aller Nutzerdaten und setz den Server mit einer aktuellen OS-Version neu auf!
 
Die Zeit, die man benötigt, um das wieder sauber hinzubekommen, kann man auch nutzen, um z.B. einen zweiten Server aufzusetzen und die relevanten Daten zu migrieren.

Daher würde ich das wie Nexus machen und einfach die Daten migrieren und gleich mit vernünftigen Versionen der Pakete arbeiten.
 
Fahr die Kiste runter, boote ins Rescue, mach im Rescue eine Datensicherung aller Nutzerdaten und setz den Server mit einer aktuellen OS-Version neu auf!

Das wird ja parallel gemacht. Allerdings mit einen neuen Shop System. Was auch fast fertig ist. Nur wird dieses erst in 1-2 Monaten online gehen. Solange muß der alte Server noch am Leben erhalten werden.

ABER: Ein reboot hat erstmal das apt-get problem behoben.
openssl-1.1.0f kompiliere ich grad.

Was aber nachher imemr noch nicht mein Problem mit curl/php5-curl beheben wird :mad:
 
Ich wenn du schon mit testing rumprobiert hast, kannst du mehr oder weniger kaputt machen, aber das kennst du ja (du wurdest von anderen gewarnt!).

Was hindert dich an dem hier?
apt-get -t testing --simulate install php5-curl

Dass du möglicherweise wegen der neueren openssl 1.0.2 bei Apache und anderen auf SSL aufsetzenden Programmen Probleme haben könntest, hast du bestimmt schon bei deinem Upgrade-Experiment berücksichtigt.

Viel Erfolg beim Experiment.

PS: Du bist mutig.
Ich würde sowas niemals mit einem Kundenserver machen, ich würde den gleich neu aufsetzen oder richtig komplett auf eine neuere Distri upgraden.
 
Last edited by a moderator:
Allerdings mit einen neuen Shop System. Was auch fast fertig ist. Nur wird dieses erst in 1-2 Monaten online gehen. Solange muß der alte Server noch am Leben erhalten werden.

Ich bin kein Jurist, aber mit dem Wissen um die veraltete Systemsoftware dürfte das mit hoher Wahrscheinlichkeit gegen irgendwelche Datenschutzgesetze verstoßen und du als "Mitwisser" begibst dich da vermutlich auf sehr, sehr dünnes Eis. :eek:

Davon mal ganz abgesehen...Du kannst doch mit einem aktuellen OS wahrscheinlich noch das alte Shopsystem zum Laufen bekommen, bis das neue System am Start ist.

Was aber nachher imemr noch nicht mein Problem mit curl/php5-curl beheben wird :mad:

Da du schon angefangen hast, dein System zu zerschießen, wird das nur das erste von noch vielen weiteren Problemen sein.
Verstehe bitte endlich, daß alle installierten Pakete aufgrund ihrer Abhängigkeiten auch zueinander passen müssen. Ein einzelnes Paket zu aktualisieren, ist deswegen völlig sinnfrei.
 
Ich bin kein Jurist, aber mit dem Wissen um die veraltete Systemsoftware dürfte das mit hoher Wahrscheinlichkeit gegen irgendwelche Datenschutzgesetze verstoßen und du als "Mitwisser" begibst dich da vermutlich auf sehr, sehr dünnes Eis. :eek:
Ich fass es nicht. Wir sind doch nicht im Kindergarten.
Wer Kunden hat, ist gewerblich tätig und muss sich mit den juristischen Folgen auskennen, wenn er so einen Server breit stellt.
 
Dass du möglicherweise wegen der neueren openssl 1.0.2 bei Apache und anderen auf SSL aufsetzenden Programmen Probleme haben könntest, hast du bestimmt schon bei deinem Upgrade-Experiment berücksichtigt.

DAS wird hier wohl der dreh und Angelpunkt sein. Den Indianer werd ich vermutlich noch updaten können. PHP wird vermutlich das Finale und nicht lösbare Problem sein.

Aktuell PHP 5.3 => 5.4 ist nicht möglich. Da macht das late Shop-System nicht mit. Dehalb wird es auch ausgetauscht.

Na wird werd vermutlich nicht ums neuaufsetzen rum herrumkommen :mad::mad::mad:
 
Ich fass es nicht. Wir sind doch nicht im Kindergarten.
Wer Kunden hat, ist gewerblich tätig und muss sich mit den juristischen Folgen auskennen, wenn er so einen Server breit stellt.

Bevor du mit noch dickere Geschützen schießen willst, mach dir klar, dass das nur die halbe Wahrheit ist, die du hier rumposaunst. Sry !

Der Kunde selbst ist dafür verantwortlich, da dies sein Eigentum ist oder diesen angemietet hat. Ist der Kunde selbst nicht fähig diesen auf Datenschutzniveu zu halten, obliegt (!!!!) es dem Kunden einen Admin ins Boot zu holen. Tut er das nicht, so trifft deine Aussage natürlich wieder zu.

Hat besagter Kunde nun einen Admin, kann dieser auch nur das Umsetzen, was besagter Kunde beauftragt. Der Admin hat hier aber auf die Mißstände hinzuweisen. Ignoriert der Kunde diese Mißstände ist der Admin von Haftungsgründen freigestellt bzw. nur in einen SHR begrenzten Rahmen haftbar.

Kritischer wird es sogar für den Admin, wenn dieser änderungen/aktualisierungen auf den Server vornimmt, wozu er garnicht berechtigt/beauftragt worden ist.

Wir gehen hier einfach mal davon aus, dass Kunde die Mißstände kennt und bereits dabei ist diese zu Lösen.
 
Leider bin ich noch nicht am Ende, da CURL-php immer noch mit der alten Version arbeitet.

Natürlich arbeitet curl weiterhin mit der alten OpenSSL-Version, da es dagegen compiliert wurde. Wie es DjTom-i oben schon geschrieben hat, mußt du sämtliche Programme gegen die neue Version kompilieren (oder entsprechende Pakete verwenden, die das sind).
Deswegen muß man Abhängigkeiten immer in beiden Richtungen prüfen, wenn man eine neue Version installieren will.
Das system in der jetzigen Form zu betreiben ist, da es sich um ein Shop-System handelt, extrem verantwortungslos auf Grund der auf dem System gespeicherten Kunden- und möglicherweise sogar Zahlungsdaten (Kontonnummer, Kreditkartennummern usw.) - einfach auf Grund des extrem veralteten Systemstandes und der unbekannten Anzahl vorhandener Sicherheitslücken.
 
Wenn dein einziges Problem warum du den Server nicht neu aufsetzen willst eine veraltete PHP-Version ist dann - bitte - STOP!

Falls das ShopSystem keine exotischen Anforderungen hat sollte der einer oder andere regulärer Webhoster dir hier weiterhelfen können, so einige bieten aus Kompatibilitätsgründen noch alte PHP-Versionen an. Diese werden entweder intern oder von Drittanbieter (Cloudlinux, ...) gegen neue Sicherheitslücken gepatcht und können auf aktuellen Systemem laufen.

In der Zwischenzeit kann der Bestandsserver dann aktualisiert werden. Alternativlösung wäre alles hinter Cloudflare zu setzen welches sowohl die meisten Angriffe als auch SSL-Terminierung für dich korrekt übernehmen kann und deshalb eigentlich deine Probleme gut umgehen kann.

Die aktuelle Aktion kann ich bei allem guten Willen nur als "Murks" betiteln.
 
Bevor du mit noch dickere Geschützen schießen willst, mach dir klar, dass das nur die halbe Wahrheit ist, die du hier rumposaunst. Sry !
Wieso fühlst du dich denn angegriffen? Mir ist es völlig egal was du mit deinen Kunden machst. Das ist dein Gewerbe.

Du hast meinen Post https://serversupportforum.de/threads/alte-opentls-verion-updaten.58373/post-382863 aus dem Zusammenhang gerissen, ich antwortete auch nicht dir.
Es ging mir darum nexus zu sagen, dass man nicht jedem gewerblichen Anbieter hier juristisch die Schuhe zubinden muss, dass kann der doch selbst.
Es ist ja schön zu sehen wie besorgt manche sind, wenn es im die Betreiber eines Servers geht. Aber wir sind doch nicht die Sozpäds der Leute hier. ;)

Der Kunde selbst ist dafür verantwortlich, da dies sein Eigentum ist oder diesen angemietet hat.
Ja, korrekt. Wenn er das Upgrade bei dir so beauftragt hat wie du es machst, haftet er für Folgen.
 
Last edited by a moderator:
Vorbereitung zum Ersetzen von libc6 2.11.3-4 (durch .../libc6_2.24-11+deb9u1_amd64.deb) ...
Du willst ein Paket für Debian Stretch auf Debian Squeeze installieren? Damit sorgst du nicht für Sicherheit, sondern zerschießt das System komplett. Die viel höheren Abhängigkeiten zu erfüllen ist praktisch unmöglich.
Laut OpenSSL-Changelog ist die Version 0.9.8m vom März 2010. Dementsprechend sind alle anderen installierten Pakete ähnlich veraltet.
Man muss nicht gleich den Teufel an die Wand malen, Debian Squeeze LTS wurde immerhin noch bis letztes Jahr mit Updates versorgt. Vorausgesetzt diese Aktualisierungen wurden eingespielt...
Zum Betreiben einen Shops wäre der Server natürlich trotzdem nicht mehr geeignet.
 
und möglicherweise sogar Zahlungsdaten (Kontonnummer, Kreditkartennummern usw.) -
Kreditkartendaten können wir getrost ausschliessen, ebenso dass er direkt mit einem Payment provider zusammenarbeitet. Für beides braucht man (unterschiedliche) PCI DSS Compliances welche quartalsweise einzureichende Scans durch einen akkreditierten PCI-Scanner beinhalten. Für ein solches System gäbe es keine Zertifierung.

Laut OpenSSL-Changelog ist die Version 0.9.8m vom März 2010. Dementsprechend sind alle anderen installierten Pakete ähnlich veraltet.
*stöhn*. Bitte fangt nicht hier an wie Comodo... alle 3 Monate denen eidesstattlich zu erklären dass eine Programmversion von den Distros lange nach Veröffentlichung noch Updates kriegt reicht mir :D


Wenn es keine Symptome gibt ist es sehr unwahrscheinlich dass das System kompromittiert ist, wenn auch nicht unmöglich.
 
Back
Top