Debian Wenn rkhunter nach einem Update zickt

Wer kennt es nicht, man macht ein Update auf seiner Maschine, alles stimmt und rkhunter ist nach dem Update der Meinung, dass ist doch alles Falsch nun.
In diesem Moment sollte man am besten vor dem Update einen Systemcheck durführen ( Händisch, da rkhunter hdparm, /dev/.udev, /dev/.initramfs, /dev/.mdadm.map und portsentry moniert und aptitude nicht weiterläuft, als Bsp. rkhunter -c –cs2 –rwo –sk -X ) und nach dem Update. Schaut nach einer ganz schönen Arbeit aus, nur um seine Maschine einem Update zu unterziehen.
Da springt natürlich für uns eine Funktion ein, welche bei Debian scheinbar nicht vielen bekannt ist und einen mächtigen Syntax besitzt.
Aptitudes und das darunterliegende apt könne konfiguriert werden und zwar über die Datei: /etc/apt/apt.conf.d/70debconf

Wenn man  die Datei betrachtet:

// Pre-configure all packages with debconf before they are installed.
 // If you don't like it, comment it out.
 DPkg::Pre-Install-Pkgs {"/usr/sbin/dpkg-preconfigure --apt || true";};

ist in dem Moment nur der standard vorhanden. Das möchten wir ändern.
Ich setze ein Befehl ein, welcher nach dem Update ausgeführt werden soll,  Dpkg::Post-Invoke {„Befehl“;};.

DPkg::Post-Invoke {"rkhunter --propupd";};

Hier wird nun ein Update der neu installierten Files, bzw der kompletten Datenbank von rkhunter gemacht, welches die False/Positives auszumerzt.
dies unterdürckt Fehlermeldungen bei dem nächsten Cronjob. Ein Update der coreutils  hätte fatale Folgen, ein dpkg -L coreutils gibt Auskunft darüber ;)

Dieser Tipp dient nicht dem absolutem Schutz vor einem Rootkit und es sollte nicht nur rkhunter lokal ausgeührt werden, sondern auch mal mit einer LiveCD. Wer rkhunter nutzt, sollte sich wirklich mit dem Programm auseinandersetzen und sich im Klaren darüber sein, dass Sicherheit ein laufender Prozess ist und vereinzelte Programme nicht den Menschen ersetzen.

Sicherheit der Debian-Pakete

Es wurde auch endlich mal Zeit, dass ein „böses“ Debianpaket aufschlägt und ich hatte es schon früher erwartet. Nicht nur ich, auch andere Debianer warteten auf den Moment bei welchen es richtig los geht. Dieser Moment ist nun gekommen und eine Aussage, welche ich immer in die Welt hinausposaune ist jene:

– Installiere nur Pakete aus Quellen, welche Dir bekannt sind.
– Sind Dir die Quellen nicht bekannt, nimm den Quellcode sichte Ihn und baue selber eines.
– Kannst Du jenes nicht, warte bis das Paket Deine Distributionsserver erreicht, ist dem nicht so, schlage das Paket vor.
– Nimmt sich keiner des Paketes an, lerne Debianpakete zu bauen.

Scheinbar ist dies eine Situation, welchen nicht Allen Linuxnutzern bekannt ist und jene scheinen sich darauf zu verlassen, Linux sei Sicher. Dem ist nicht so, es ist vielleicht sicherer, aber nicht sicher per se. Wird es auch niemals¹. Nur im Gegensatz zu Windows, kann man mit einem unixoiden System einiges mehr anrichten, als mit einem Windows, welches von Haus aus nicht so massive Werkzeuge mit sich bringt, wie ein Unix/Linux.
Zum Glück, das ist es wirklich, hat sich der kleine Scripthippie nicht auf eine sehr böse Sache spezialisiert, sondern er haut einfach ein „paar“ Pings auf eine Domain. Ich erinnere nochmals daran, dass man ein Paket mit Rechten des Benutzers root installiert. Stellt sich die Frage, was wäre, wenn er etwas mehr in die Trickkiste gegriffen hätte und sich die Maschinen wirklich unter den Nagel reißen würde. Remote. Eine Firewall dazwischen ist nicht wirklich das Problem, denn Outbound ist immer etwas erlaubt. Man muss es nur versuchen. Eine Anleitung dazu gebe ich nicht.
Also, Pakete nur aus bekannten Quellen installieren.

¹ Software, von Menschen geschrieben, wird immer einigen Fehlern unterliegen. Ich meine wir sind Menschen. Ich denke, dass muss ich nicht weiter ausbreiten.

Perlbasierte apt-Suite

Wie erweitert man apt und bringt es mit Perl in eine Richtung, welche neu ist?
Man reimplementiert apt neu auf Basis von Perl und fügt ein Consolefrontend dazu und nennt es cupt:

Why?

  •  to finally avoid some bugs in APT design;
  •  to introduce some useful features;
  •  to make an extensible and readable codebase;

What infrastructure does Cupt use?
It uses the same APT infrastructure, e.g. index files, deb cache archive
files, configuration files. It understands some of widely used APT options.


What useful features has Cupt already?

  •  full-case strict dependency problem resolver;
  •  command-line and APT-like option name checker;
  •  case-sensitive search;
  •  pinning by source package name;
  •  pinning by package groups using shell-like patterns;
  •  configurable ‚depends‘ and ‚rdepends‘ subcommands;
  •  ’satisfy‘ subcommand.

What features will Cupt have in future?

See incomplete roadmap

Why is it ‚experimental‘?

Because not all important functionality is implemented yet:

  •  ‚update‘ action;
  •  cooperating with debconf;
  •  working with source packages;
  •  translated package descriptions;

Weiter Infos über cupt finden sich bei JackYF’s blog und ich warte mal ein wenig ab, was sich sonst noch so tut, aber ich finde es eine gute Idee, aber gebe zu, dass ich es mir bis Dato nicht in der Praxis angeschaut habe.

KDE 4.2 Debian Lenny

Debian-Desktop.org haben einen KDE 4.2 Backport für Debian Lenny gemacht. Vorhanden sind die Repositories für i386 und PPC. Ich habe sie selber nicht getestet, denn ich bin bekennender Tilingfreund unter ion3.
Man muss nur:

deb  lenny kde42
deb-src  lenny kde42

der sources.list hinzufügen und seinen Gefühlen freien Lauf lassen. Vielleicht kann jemand mal ein Kommentar hinterlassen, wie die Arbeit des Teams gelaufen ist. Auch sollte man dies nicht als Anleitung ansehen, somit Seitenbesuchbefehl.
Danke an das Debian-Desktop-Team.

Hae, oder was will aptitude?

Eben auf dem Server (Lenny):

Hole:2 http://security.debian.org lenny/updates Release [40,8kB]
Ign http://security.debian.org lenny/updates Release       
Ign http://security.debian.org lenny/updates/main Packages/DiffIndex
Ign http://security.debian.org lenny/updates/non-free Packages/DiffIndex
Ign http://security.debian.org lenny/updates/contrib Packages/DiffIndex    
Ign http://security.debian.org lenny/updates/main Sources/DiffIndex        
Ign http://security.debian.org lenny/updates/non-free Sources/DiffIndex    
Ign http://security.debian.org lenny/updates/contrib Sources/DiffIndex     
Treffer http://security.debian.org lenny/updates/main Packages             
Treffer http://ftp-stud.fht-esslingen.de lenny/non-free Packages/DiffIndex 
Treffer http://ftp-stud.fht-esslingen.de lenny/contrib Packages/DiffIndex  
Treffer http://ftp-stud.fht-esslingen.de lenny/main Sources/DiffIndex
Treffer http://ftp-stud.fht-esslingen.de lenny/non-free Sources/DiffIndex
Treffer http://ftp-stud.fht-esslingen.de lenny/contrib Sources/DiffIndex
Treffer http://security.debian.org lenny/updates/non-free Packages
Treffer http://security.debian.org lenny/updates/contrib Packages
Treffer http://security.debian.org lenny/updates/main Sources
Treffer http://security.debian.org lenny/updates/non-free Sources
Treffer http://security.debian.org lenny/updates/contrib Sources
Treffer http://ftp-stud.fht-esslingen.de lenny/non-free Sources
41,0kB wurden in 1s heruntergeladen (23,1kB/s)
Paketlisten werden gelesen... Fertig
W: GPG error: http://security.debian.org lenny/updates Release: Die folgenden Signaturen waren ungültig: BADSIG A70DAF536070D3A1 Debian Archive Automatic Signing Key (4.0/etch) 

Jo was iss denn das nu?
Denke mir ich warte mal ab.