Nessus zeigt Lücken aber es gibt keine Updates von Suse

[mikespi]

Hallo,

Nessus hat mir einige Lücken und Problemzonen an meinem Server aufgezeichnet.
Nach Recherche auf dem Update Server ( der meiner Meinung fast identisch wie der von SuSe ist ) muss ich feststellen das ich die jeweils neuesten Versionen installiert habe.

Kontrolliert habe ich die mit rpm -q Paketname.

Nessus verlangt z.B. Apache 1.3.28 aber SuSe bittet eben nur 1.3.26-57 an. Jetzt weiss ich dank diesem Forum das SuSe die Sicherheitslücken patcht und eben nicht die Versionsnummern.

Mein Problem jetzt ist soll ich Nessus in diesem Fall ignorieren oder gibt es eine Möglichkeit die Datenbank von Nessus SuSe 8.1 konform zu machen.

Und da habe ich auch ne andere Frage:

Code: Select all

Remote SSH version : SSH-1.99-OpenSSH_3.4p1

Nessus sagt das die Gefahr Medium ist, allerdings ist das wiedermal die aktuellste Version die Suse anbietet.

Und zu guter letzt noch

Code: Select all

The remote host is vulnerable to an 'icmp leak' -
when it receive a packet that raise an ICMP error packet
(except ICMP destination unreachable), the ICMP packet is
supposed to contain the original message.

Due to a bug in the remote TCP/IP stack, it will also contain fragments
of the content of the remote kernel memory.

An attacker may use this flaw to remotely sniff what is going on into
the host's memory, expecially network packets that it sees, and
obtain useful informations such as POP passwords, HTTP authentication
fields, and so on.


Solution : Contact your vendor for a fix. If the remote host is running
           Linux 2.0, upgrade to Linux 2.0.40.
See also : http://www.cartel-securite.fr/pbiondi/adv/CARTSA-20030314-icmpleak
           http://www.kb.cert.org/vuls/id/471084
Risk factor : High

Ich habe mir den Link angeschaut aber das schaut härter aus als das ich da so einfach rangehe.
Wäre nett wenn mir das jemand näher erklären könnte.

Mike

[Joe User]

Moin,

kleiner Tip: Lad' Dir die jeweils aktuellen Quell-RPMs der 'bemängelten' Pakete und sieh Dir die darin enthaltenden Patches an. Wie (fast) alle Distributoren integriert auch SuSE etliche 'Backports' in ihre Pakete, ohne dabei die Versionsnummer zu ändern, wodurch das Paketmanagment funktionsfähig (Auflösung der Paketabhängigkeiten) gehalten wird. Du wirst feststellen, dass viele, aber auch nicht alle, 'Lücken' bereits vor der Veröffentlichung des jeweiligen Pakets (unbewusst) 'geschlossen' waren...

Gruss,
Markus

[captaincrunch]

Der große Nachteil von Nessus : man muss noch mehr als bei kommerziellen Security-Scannern zwischen richtigen Meldungen und "false positives" unterscheiden können.

Die Bugfixes der aktuellen Apache-Version hat SuSE definitiv in die "alte" mit reinfließen lassen, schau dir dazu (wie schon gesagt) entweder die Changelogs der Source-Pakete, oder halt die Security-Meldungen seitens SuSE an.

Remote SSH version : SSH-1.99-OpenSSH_3.4p1

Die Meldung sagt dir nur, dass du noch die unsichere ssh-Version 1 nutzt, was SuSE standardmäßig (unverständlicherwiese) so voreingestellt hat.
Um das abzustellen, such dir in der /etc/ssh/sshd_config die Zeile

Protocol 1,2

ändere sie in

Protocol 2

und starte den sshd neu.

Was den Kernel angeht : hast du dir schon mal die Meldung genau durchgelesen ? Nutzt du Kernel 2.0.X ? ;)

[mikespi]

Danke,

na da bin ich froh das Nessus lieber mehr als zu wenig warnt. Wenn man drauf vorbereitet ist macht einen die Liste weniger Sorgen.

Ich habe heute noch mal einen Scann durchgeführt und da war das angebliche Loch mit dem Kernel ( habe ich das dann doch richtig verstanden ) nicht mehr da.

Was den Kernel angeht : hast du dir schon mal die Meldung genau durchgelesen ? Nutzt du Kernel 2.0.X ?

Ok ich weiss das ich den 2.4er benutze aber ich wollte mir da lieber eine Bestätigung einholen da ich sobald ICMP auftaucht nur böhmische Dörfer sehe ( noch sind es böhmische Dörfer aber Step by Step gehts weiter ). Und Risiko Level "hoch" machte mich dann schon nachdenklich.

Ich habe zu Anfangs auf SSH Version 2 eingestellt. So weit ich mich erinnere allerdings mit Webmin.

Code: Select all

pxxxxxxx:~ # ssh -V
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f

Sehe ich das also richtig das Webmin dann nicht richtig in die confs schreibt oder habe ich falsch konfiguriert.
Allerdings muss ich gestehen das ein SSH Dienst Neustart nicht vorgenommen worden ist. ( Oh Mann das sollte ich nicht mehr vergessen in der Zukunft :lol: )

Das ist aber doch ne heikle Sache wenn ich da die falschen Parameter angebe stürtzt SSH ab und ich kann nicht mehr drauf oder?

Leider habe ich keine Möglichkeit per Befehl gefunden ( ausser kernelversion ) wie ich die genaue Kernelversion rausfinden kann. Ein Ratschlag wäre nett.

Mike

[captaincrunch]

Das ist aber doch ne heikle Sache wenn ich da die falschen Parameter angebe stürtzt SSH ab und ich kann nicht mehr drauf oder?

Wenn du wirklich nur diese Ã?nderung machst, brauchst du dir keine Sorgen zu machen. Desweiteren ist der sshd so "intelligent", dass er die bestehende Sitzung (normalerweise) beibehält.

Leider habe ich keine Möglichkeit per Befehl gefunden ( ausser kernelversion ) wie ich die genaue Kernelversion rausfinden kann. Ein Ratschlag wäre nett.

uname -a

[mikespi]

Danke

uname -a

Gespeichert

Mein Adrenalin Spiegel ist doch kurz mal in Höhe geschossen beim restart des sshd. :lol:

Mike

[outofbound]

Wenn du zum dritten mal einen Kernel verhunz hast, verfliegt dieses Gefühl, glaub mir. :)

Gruss,

Tommy