Setting up a client-to-site VPN using the Check Point (CP) Remote Access Client is a common scenario in CP infrastructures. As the central gateway is set up the Remote Access Client is started, connected to the gateway using valid user credentials, the gateway fingerprint needs to be verified and accepted on the first connection attempt and the VPN is ready to be used as nearly everything
may be configured centrally.
But what if a deployment of thousands of clients is planned? What if the Remote Access Client will be used in an ATM scenario and the deployment has to work without user interaction? Accepting the fingerprint automatically or let the user accept it is not a good choice from a security perspective.
A working solution for this challenge is to deploy the fingerprint together with the Remote Access Client. As the fingerprints are stored in the registry this is possible within a few steps.
But at first a little warning:
The registry key containing the gateway fingerprint is not deleted while the Remote Access Client is uninstalled. When testing auto installation software multiple times on the same system the fingerprint has to be deleted manually before running a test. Otherwise the fingerprint verification is skipped and the test results may be incorrect.
The registry key containing the fingerprints is:
HKEY_LOCAL_MACHINE\SOFTWARE\CheckPoint\accepted_cn\

You may now export all fingerprints or a single fingerprint at your choice using the ordinary regedit context menu. The German word “Exportieren” at the figure means “export”.

As a result you will get a .reg file that you may import on all systems that should know the fingerprint.
To sum all that up to a one click installation a simple two line batch script is sufficient to import the fingerprint and start the “E80.42 for ATM” installation.

regedit /S Fingerprint.reg
CP_EPS_E80.42_RAC_Windows_ATM.msi /quit /forcerestart

This works for most auto deployments and avoids the necessity to verify the fingerprint on every new installation of the Remote Access Client.
Note: This has been tested using Check Point Remote Access Client E40.42 for ATM

Ein wichtiger Teil unserer Arbeit ist es, Risiken in IT-Systeme zu identifizieren, diese auszuschließen oder auf ein hinreichendes Niveau zu minimieren. Bei der Planung von Sicherheitsarchitekturen nimmt die Verwendung von automatisierten Malwarescannern schon lange einen elementaren Platz ein. Clientsysteme ohne Anti-Viren-Programm sind nahezu undenkbar. Ein anderes Bild zeigt sich jedoch, trotz eines erhöhen Schutzbedarfs, bei den Serversystemen. Entsprechende Lösungen sind verfügbar und sollten ein zwingender Baustein jedes Sicherheitskonzeptes sein.
Bei Rootkits, die darauf spezialisiert sind sich durch Manipulation des Betriebssystems der Entdeckung zu entziehen, stoßen viele der gängigen Lösungen an ihre Grenzen. Drei Möglichkeiten dieser Gefahr auf Linuxsystemen durch zusätzliche Sicherheitsmechanismen zu begegnen zeigt der folgende Artikel.
Eine mögliche Lösung bietet die Software AIDE (http://aide.sourceforge.net/). Mit AIDE können, wie das folgende Listing zeigt, Veränderungen im Dateisystem schnell sichtbar gemacht werden. Das Beispiel zeigt eine Manipulation der Ausführbaren Dateien des Systems um durch Veränderungen des Programms ps einen schadhaften Prozess zu verstecken.

#!/bin/bash
#Beispielkonfiguration um nur /bin zu überprüfen
aide -c sample_bin.conf -C
AIDE 0.15.1 found differences between database and filesystem!!
Start timestamp: 2012-10-12 14:21:40
Summary:
Total number of files: 118
Added files: 0
Removed files: 0
Changed files: 1
# Änderungsdetails gekürzt
changed: /bin/ps

Der Mehraufwand, der für den Einsatz von AIDE geleistet werden muss, besteht darin, nach Systemupdates die Datensätze der bekannten Dateien zu aktualisieren.
Doch auch diese Methode hat ihre Grenzen, wenn der Linux-Kernel manipuliert wurde oder Änderungen lediglich in Ordnern auftreten, die nicht überwacht werden. Hier kann eine andere Klasse von Tools zur Rootkiterkennung verwendet werden.
Die Software chkrootkit (http://www.chkrootkit.org/) prüft auf die Anwesenheit bekannter Rootkits. Dies entspricht etwa dem Vorgehen der signaturbasierten Virensuche.

#!/bin/bash
chkrootkit
ROOTDIR is `/'
Checking `amd'... not found
Checking `basename'... not infected
Checking `biff'... not found
...
Searching for sniffer's logs, it may take a while... nothing found
Searching for rootkit HiDrootkit's default files... nothing found
Searching for rootkit t0rn's default files... nothing found
Searching for t0rn's v8 defaults... nothing found
Searching for rootkit Lion's default files... nothing found
Searching for rootkit RSHA's default files... nothing found
...

Genau wie die signaturbasierte Virensuche muss für ein Programm wie Chkrootkit bekannt sein wie sich ein Rootkit verhält, bevor die Suche erfolgreich ist. Dies bedingt aktuelle Signaturen wie bei jedem Virenscanner auch.
Einen anderen Weg verfolgt das Programm Unhide (http://www.unhide-forensics.info/). Unhide versucht mit verschiedenen Methoden die Anwesenheit von versteckten Prozessen und Ports aufzudecken. Dies kann auf einen Rootkitbefall hindeuten.

#!/bin/bash
unhide -f procall brute
Unhide 20110113
http://www.unhide-forensics.info
[*]Searching for Hidden processes through /proc stat scanning
[*]Searching for Hidden processes through /proc chdir scanning
[*]Searching for Hidden processes through /proc opendir scanning
[*]Searching for Hidden thread through /proc/pid/task readdir scanning
[*]Starting scanning using brute force against PIDS with fork()
Found HIDDEN PID: 14496 " ... maybe a transitory process"
[*]Starting scanning using brute force against PIDS with pthread functions

Das Vorgehen von Unhide ist dabei übertragbar auf jedes Rootkit, dass einen Prozess versteckt. Birgt jedoch die Gefahr von False-Positives. Die gefundenen PIDs sollten daher weiter geprüft werden, bevor von einem Rootkitbefall ausgegangen werden kann.
Sollte sich der Verdacht auf einen Rootkitbefall erhärten ist es jedoch ratsam, dass betroffene System aus dem laufenden Betrieb zu nehmen und eingehend forensisch zu untersuchen.
Dies ist insbesondere bei Serversystemen sehr schmerzhaft. Der Befall mit einem Rootkit kann jedoch bedeuten, dass das System bereits vorher von einem Hacker übernommen wurde und das Rootkit als „versteckter Eingang“ installiert wurde. Dieser Gefahr sollte man sich nicht ungeprüft aussetzen.

In zwei Artikeln der bekannten Fachzeitschrift “Hakin9” zeigt Patrick Burkard (BSK Consulting GmbH) Methoden zur Erkennung und Analyse von Rootkits auf  Linux Plattformen.

Artikel “Linux Memory Forensics”

Die forensische Analyse des Arbeitsspeichers von Linuxsystemen befindet sich noch in ihren Anfängen. Dies hat den einfachen Hintergrund, dass die Notwendigkeit für eine solche Analyse bisher nur in sehr geringem Ausmaß gegeben war. Durch den Trend hin zu virtualisierten Infrastrukturen, zum Beispiel beim Virtual Server Hosting oder beim Cloud Computing, kann sich dies in Zukunft schnell ändern.
Dieser Artikel zeigt Schritt für Schritt, wie die Tools Volatilitux und Volatility für die Analyse von Linux RAM-Dumps verwendet werden können. Nach dem Einrichten der Tools wird außerdem noch gezeigt, wie im RAM das Linux Kernel Rootkit Kernel Beast (KBeast) erkannt und analysiert werden kann.

Artikel “Anatomie von Linux Rootkits”

Viele User wechseln derzeit von ihrem Windows- zu einem Linuxsystem. Eine häufig gelesene Begründung ist, dass unter Linux keine Virengefahr besteht. Selbst Zeitungen aus dem nicht technischen Bereich, wie der Spiegel, führen Artikel zu diesem Thema. Fakt ist jedoch, dass es durchaus Schadsoftware für Linux gibt, diese jedoch bei weitem nicht so stark verbreitet ist wie unter Windows. Eine besonders gefährliche Art von Schadsoftware sind sogenannte Rootkits. Wie Rootkits unter Linux funktionieren und welche Möglichkeiten zur Erkennung gebräuchlich sind, erklärt der Artikel in der Hakin9 extra 2/2012.