Kleine und große Linux AHAs
Beiträge getaggt mit administration
xdrp: auch ne Möglichkeit für Remote Zugriff
26. Feb
Es gibt unter Linux viele Möglichkeiten sich remote an einem System anzumelden – auch viele das grafisch zu tun. Da gibt es zum Beispiel XDMCP, X11 über einen ssh Tunnel, VNC, freenx oder das kommerzielle Pendant, … All diese Möglichkeiten waren mir bisher bekannt und ich habe sie auch schon mal ausprobiert. Aus irgendeinem Zufall bin ich nun auf was – für mich – neues gestossen: xrdp.
xrdp kann quasi VNC in das RDP Protokoll umschreiben und dadurch VNC über RDP zur Verfügung stellen. Das ganze ist recht interessant, da der RDP Client bekannterweise in einem von mir nicht zu nennenden “Betriebssystem” zur Standardausrüstung gehört und somit von diesen Clients aus keine extra Software / Installation benötigt wird.
Installation
Die Installation unter Ubuntu ist denkbar simpel -> apt-get install xrdp.
Konfiguration
xrdp läuft nach der Installation automatisch. Allerdings muss man um Zugriff auf den Rechner zu gewähren über die Gnome Desktop Einstellungen den VNC Server starten. Das ganze findet sich unter Menü-System-Einstellungen-Entfernter Bildschirm. Dort muss man “Anderen Benutzern erlauben, Ihren Bildschirm anzuzeigen” und “Anderen Benutzern erlauben, Ihren Bildschirm zu steuern” aktivieren. Des Weiteren sollte man ein Passwort setzen. Dieses hat jedoch nichts mit dem Anmeldepasswort des Accounts zu tun.
Anmeldung per RDP
Nun wird der RDP Client mit dem Rechner verbunden. Es erscheint ein Menü, in diesem man den Typ “Console” für die Sitzung wählt und kann dann mit dem vergebenen Passwort auf seine Sitzung zugreifen.
Naja
Also so wie ich es beschrieben habe gefällt es mir an sich selbst nicht. Ein großer Nachteil der Lösung ist, dass der Vino-Server (VNC Server unter Gnome) bei einem gesperrten Bildschirm versagt -> einen schwarzen Bildschirm zeigt. Des Weiteren ist in diesem Szenario der RDP Port als auch der VNC Port auf der Maschine offen. Gepaart mit dem “schwachen” Passwort welches wie oben konfiguriert haben, ist das nicht wirklich Sicher.
Man kann den Vino-Server auch deinstallieren und dafür x11vnc nehmen. Damit funktioniert das ganze auch bei gesperrtem Bildschirm. Leider ist damit die Performance um einiges schlechter. Ich habe keine Einstellung gefunden mit der x11vnc über xrdp so flüssig läuft wie mit dem Vino-Server. Da beißt sich die Katze in den Schwanz.
Mehr Bandbreite: Bonding mit Cisco
25. Feb
Gründe um Server mehrfach an die Netzwerkinfrastruktur anzubinden gibt es mehrere. In den meisten Fällen wird das (unter Linux) so genannte “bonding” dazu genutzt, einen Server an mehrere Switches anzubinden um die Redundanz zu erhöhen, wobei die Durchsatzrate dabei nicht erhöht wird – es wird immer nur eine Verbindung genutzt; sollte ein Switch ausfallen ist das System trotzdem weiterhin erreichbar.
| |
|port3 port3|
+-----+----+ +-----+----+
| |port2 ISL port2| |
| switch A +--------------------------+ switch B |
| | | |
+-----+----+ +-----++---+
|port1 port1|
| +-------+ |
+-------------+ host1 +---------------+
eth0 +-------+ eth1
Quelle: http://www.cyberciti.biz/howto/question/static/linux-ethernet-bonding-driver-howto.php
Meeeehr Bandbreite
Was wir hier möchten ist mehr Bandbreite. Dazu kann man – z.B. mit einem Cisco Switch – den Linux Bonding Mechanismus dazu nutzen, beide Verbindungen an einen Switch zu bündeln und dem entsprechend die Bandbreite zu verdoppeln. Damit habe ich auch schon ein Problem dabei angesprochen. Dieser Mechanismus funktioniert nur auf einem Switch. Man kann keinen “Etherchannel” (aus Cisco Sicht) über mehrere Switches bauen. Das damit entstandene Problem ist, dass ich keine Redundanz aufbauen kann im Sinne von “siehe oben”. Fällt dieser eine Switch aus, ist auch die Netzwerkverbindung komplett weg.
+----------+ +----------+ +--------+
| |eth0 port1| +-------+ Host B |
| Host A +------------+ switch |port3 +--------+
| +------------+ | +--------+
| |eth1 port2| +------------------+ Host C |
+----------+ +----------+port4 +--------+
Quelle: http://www.cyberciti.biz/howto/question/static/linux-ethernet-bonding-driver-howto.php
Konfiguration auf der Linux Seite
Die Konfiguration auf der Linux Seite sieht an sich eine normale Bonding Konfiguaration vor; hier die kurze Version für ein bond0:
/etc/sysconfig/network-scripts/ifcfg-eth0:
DEVICE=eth0 USERCTL=no ONBOOT=yes MASTER=bond0 SLAVE=yes BOOTPROTO=none
/etc/sysconfig/network-scripts/ifcfg-eth1:
DEVICE=eth1 USERCTL=no ONBOOT=yes MASTER=bond0 SLAVE=yes BOOTPROTO=none
/etc/sysconfig/network-scripts/ifcfg-bond0:
DEVICE=bond0 IPADDR=192.168.1.1 NETMASK=255.255.255.0 NETWORK=192.168.1.0 BROADCAST=192.168.1.255 ONBOOT=yes BOOTPROTO=none USERCTL=no
Normalerweise trägt man nun in der /etc/modprobe.conf folgendes ein (eine Variante):
alias bond0 bonding options bond0 mode=1 miimon=100
Damit wird das Modul für bonding geladen und festgelegt in welchem Modus das ganze arbeitet.
- mode=1 -> bedeutet “active-backup” – eine aktive Verbindung und die andere als Backup (unbenutzt für Traffic)
- miimon=100 -> damit wird alle 100 millisekunden per MII geprüft
Wir möchten aber nicht active-backup sondern einen PortChannel nach “IEEE 802.3ad” -> Dynamic link aggregation. Laut Doku:
Creates aggregation groups that share the same speed and duplex settings. Utilizes all slaves in the active aggregator according to the 802.3ad specification.
Dabei wird also eine Gruppe aus “Links” gebildet, die dann zusammen genutzt werden. Die Konfiguration dafür auf der Linux Seite ist sehr einfach, da lediglich die Einstellung für das bonding Device in der /etc/modprobe.conf geändert werden müssen. Also:
alias bond0 bonding options bond0 mode=4 lacp_rate=1 miimon=100
- mode=4 -> IEEE 802.3ad; ein Protokollstandard, den auch Cisco verwenden kann
- lacp_rate=1 -> dieser Parameter ist optional und legt fest, wie oft die Link-Parameter zwischen Switch und Server abgeglichen werden sollen (s. Bonding Howto)
Konfiguration der Cisco Seite
Auf dem Switch wird ein neuer Port-Channel angelegt …
interface Port-channel24 description POC-to-Linux-Server switchport <switchport access vlan 152 | switchport mode trunk> switchport mode access no ip address spanning-tree portfast end
und dann die korrespondierenden Interfaces …
interface GigabitEthernet3/33 description POC-to-Linux-Server switchport <switchport access vlan 152 | switchport mode trunk> switchport mode access no ip address channel-protocol lacp channel-group 24 mode passive end
Wie in den Beispielen zu sehen, kann man den Port-Channel so einrichten, dass nur ein VLAN durchgereicht wird oder auch als Trunk. Im Trunk mode würden dann alle VLANs durchgereicht und man könnte über eine VLAN Netzwerkkonfiguration beispielsweise einen “HT Router” (High Throughput) bauen.
An sich war es das. Der Server sollte nun die doppelte Bandbreite zum Switch hin haben. Am sinnigsten ist eine solche Anbindung natürlich an den zentralen Netzwerkkomponenten (Core Switches / Backbone). Es bringt nicht viel mit 2 oder sogar 4 Gbit/s an einen Switch angebunden zu sein, der seinerseits nur mit 1Gbit/s an dem Backbone angeschlossen ist.
sftp Server Teil II – “Jail made easy”
08. Feb
Im ersten Teil haben wir das aktuelle openssh Paket für RHEL gebaut und sollten das auch mittlerweile installiert haben. Die Konfiguration des SSH-Servers hat sich nur wenig geändert. Es gibt eigentlich auch nur wenig neue Stellen die hier für uns interessant sind. Aber wir beginnen am Anfang:
Gruppe für sftp
Die Steuerung ob ein Benutzer in einer “gechrooteten” Umgebung landet wird über eine Gruppe gesteuert. Diese könnte man beispielsweise “sftpchroot” nennen. Diese Gruppe wird also angelegt:
groupadd sftpchroot
Benutzer anlegen
Als nächstes muss der Benutzeraccount angelegt werden, der sich auch in der Gruppe sftpchroot befindet:
useradd testuser -G sftpchroot
(Passwort setzen oder disablen, je nach dem ob sich per Key oder Passwort eingeloggt werden soll. Eine Shell benötigt der User auch nicht unbedingt.)
Benutzerhome anpassen
Das Benutzerhome (/home/testuser) muss von den Rechten her angepasst werden, damit das “chrooten” funktioniert. Gleichzeitig legen wir ein Verzeichnis (exchange) an, in welches der Benutzer über sftp schreiben darf.
chown root:sftpchroot /home/testuser mkdir /home/testuser/exchange chown testuser:testuser /home/testuser/exchange
Möchte man die Authentifizierung per Key machen, so muss folgendes ebenfalls eingerichtet werden:
mkdir /home/testuser/.ssh chown testuser:testuser /home/testuser/.ssh
Der Key kommt dann in die authorized_keys; die Rechte werden auf 0600 gesetzt und fertig.
Logging
Wir möchten genau sehen, welche Befehle auf dem SFTP Server abgesetzt werden. Daher muss auch das Logging aufgesetzt werden. Dazu ist es nötig, dass in jedem Home ein dev Verzeichnis angelegt wird (-> mkdir /home/testuser/dev). Dort wird dann vom dem Syslog Server des Vertrauens eine Pipe angelegt und damit ist das Logging im System.
Wir verwenden den syslog-ng (syslog-ng). Die Konfiguration dafür sieht wie folgt aus:
source s_sftpchroot {
# Please add each chrooted environment here
# These logs stay on the local machine; not sended to the syslog-server
unix-stream ("/home/testuser/dev/log");
};
destination d_sftplog { file("/var/log/sftp_chrooted.log"); };
log { source(s_sftpchroot); destination(d_sftplog); };
Jede Chroot Umgebung muss hier im Abschnitt “source” eingetragen werden. Damit fließen alle sftp logs in eine Datei. Alternativ kann natürlich auch für jeden Benutzer ein eigenes Log geschrieben werden. Welche Konfigteile dazu angepasst werden müssen sollte ersichtlich sein
Openssh Chroot
Nun zu dem früher schwierigsten, heute jedoch einfachsten Teil. Das Openssh Chroot. Ich zeige einfach die Konfiguration – it`s that easy !
Subsystem sftp internal-sftp Match group sftpchroot X11Forwarding no AllowTcpForwarding no ForceCommand internal-sftp -l VERBOSE ChrootDirectory /home/%u
Mit dieser Konfiguation am Ende der sshd_config (/etc/ssh) bekommt jeder Benutzer, der sich in der Gruppe sftpchroot befindet, besondere Optionen. Unter anderem wird lediglich der interne sftp-server (internal-sftp) zugelassen, der mit dem Parameter “-l VERBOSE” sämtliche Befehle des Benutzers loggt. Fertig.
sftp Server Teil I – RPM bauen “made easy”
04. Feb
Ein SFTP Server ist heutzutage eigentlich nichts besonderes mehr – kommt auf die Anforderungen an. Ich möchte in zwei Teilen erklären, wie man einen sicheren “SFTP only” Server aufbaut. Das ist an sich auch wirklich nicht so schwierig.
Wenn googelt wird man schnell sehen, dass es wahnsinnig viele Anleitungen gibt um sowas zu machen. “chrooted sftp” ist da das Stichwort und es sind diverse Patches notwendig. Allerdings sind die meisten dieser Anleitungen hinfällig, da die aktuellen Version von Openssh (5.3p) bereits alles mitbringt, was man benötigt.
Unter RHEL 5 gibt es zur Zeit Openssh Version 4.3p2 als aktuellstes Package. Damit kann man weder ein “Gefängnis” (Jail -> chrooted User) bauen, noch ist das Logging so, dass man damit auch im Problemfall etwas nachvollziehen kann. Da es sehr einfach ist, das Paket selbst zu bauen, bin ich auch gar nicht erst auf die Suche gegangen um irgendwo ein fertiges zu finden.
Quellen besorgen
Die Quellen für Openssh gibt es natürlich unter openssh.org – bzw. die Mirrorliste hier. Bei Erstellung war die aktuelle Version openssh-5.3p1.tar.gz
Prerequisites
yum install gcc openssl-devel pam-devel rpm-build
Auspacken und los
tar zxvf openssh-5.2p1.tar.gz cp openssh-<VERSION>/contrib/redhat/openssh.spec /usr/src/redhat/SPECS/ cp openssh-<VERSION>.tar.gz /usr/src/redhat/SOURCES/ cd /usr/src/redhat/SPECS # askpass wird nicht benoetigt perl -i.bak -pe 's/^(%define no_(gnome|x11)_askpass)\s+0$/$1 1/' openssh.spec rpmbuild -bb openssh.spec
Fertige RPMs
Die fertigen RPMs sind dann unter
cd /usr/src/redhat/RPMS/`uname -i`
zu finden.
Vor der Installation sollten die alten (alle !) Pakete deinstalliert werden oder die neuen mit “rpm -U” als Update installieren.
Aufzeichnen von Administratortätigkeiten II
05. Okt
“timing_shorter.sh”
Cooler Name für etwas ganz einfaches. Man wird schnell feststellen, dass das abspielen einer Aufnahme schnell “langweilig” wird, da alle Pausen in voller Länge aufgezeichnet wurden. Wenn also jemand 30 Minuten lang nichts macht, dann sind diese 30 Minuten 1-1 in der Aufzeichnung.
Um dieses Problem zu umgehen läuft vor dem Cleanup Script der “timing_shorter”. Dieses Script erkennt alle Zeilen innerhalb der .timing Datei die > 3 Sekunden sind; diese werden auf 3 Sekunden gekürzt. Damit sind die Pausen maximal 3 Sekunden lang.
#!/bin/bash
# This reduces the time for typescript
# pauses (when user gives no input and
# system gives no output) to max 3 secs
# by changing the .timing file.
#
# No changes to the typescript !
#
# Ronny Becker, 09.2009
#set -x
for TIMINGFILE in `find /adminmon/timing/ -mmin +300`
do
TIMINGLINE=0
cat $TIMINGFILE | while read LINE
do
(( TIMINGLINE++ ))
if [ ${LINE%\.*} -gt 3 ]; then
sed -i "${TIMINGLINE}s/^.*\./3\./" $TIMINGFILE
fi
done
done
Das Script sollte vor dem Cleanup laufen.
Das Cleanup Script
Wir möchten die Dateien die während einer Aufzeichnung entstehen verwaltbar machen. Dazu sollen die zusammengehörigen Dateien gepackt werden – die Originale werden dann gelöscht. Womit das Problem des Zugriffs ( auf die .timing Dateien ) auch spätetstens gelöst ist.
#!/bin/bash
ADMINMON_PATH="/adminmon"
for SCRIPTFILE in `find ${ADMINMON_PATH}/output/ -mmin +300`
do
MAINNAME=`basename $SCRIPTFILE`
MAINNAME=${MAINNAME%\.*}
echo $SCRIPTFILE
echo $MAINNAME
if [ -e ${ADMINMON_PATH}/timing/${MAINNAME}.timing ]; then
tar -czf ${ADMINMON_PATH}/pairing/${MAINNAME}.tgz ${ADMINMON_PATH}/timing/${MAINNAME}.timing $SCRIPTFILE
if [ $? != 0 ]; then
echo "Fehler bei tar $MAINNAME"
continue
else
rm -f ${ADMINMON_PATH}/timing/${MAINNAME}.timing $SCRIPTFILE
fi
else
tar -czf ${ADMINMON_PATH}/pairing/${MAINNAME}_notiming.tgz $SCRIPTFILE
if [ $? != 0 ]; then
echo "Fehler bei tar $MAINNAME"
else
rm -f $SCRIPTFILE
fi
fi
done
Das Script einfach per cron alle X ausführen und gut.
Aufzeichnen von Administratortätigkeiten
28. Sep
Nahezu jeder Admin ist heute mit dem Problem der “Kontrollen” und “Nachweispflicht” konfrontiert. Dabei sind Changes / Changemanagement der Anfang und das komplette “Monitoring der Administratortätigkeiten” die logische Konsequenz. Dazu werden beispielsweise auf einem Terminalserver alle Sitzungen per Video aufgezeichnet. Was ich nun suchte war eine Möglichkeit die kompletten Bildschirmausgaben einer SSH Sitzung aufzuzeichnen. Damit könnten dann sämtliche Befehle … recht einfach nachvollzogen werden, bzw. sogar zur Fehlerfindung genutzt werden wenn der Admin Unsinn gemacht hat und selbst nachvollziehen möchte was er eigentlich gemacht hat.
Ob das ganze sinnvoll oder nicht ist, das soll an dieser Stelle nicht diskutiert werden. Es geht darum eine Lösung für diese Anforderung zu finden.
Ich habe lange nach einer Lösung gesucht. Die gibt es auch. Es sind die Boxen zweier Hersteller, die den kompletten ssh Traffic, teilweise sogar inklusive X11 und auch anderer Protokolle aufzeichnen. Schaut man sich jedoch die Preise für eine solche Lösung an, dann überlegt man sich doch zweimal, ob man wirklich so viel Geld dafür ausgeben möchte / muss. Eines vorweg: Die Boxen wurden von mir nicht getestet, da das ganze preislich völlig uninteressant war.
Also wurde Dr. Google bemüht und auch diverse Kollegen wurden gefragt – leider nirgendwo eine wirkliche Lösung.
Naja, wie man es so aus der Community gewöhnt ist wird sich dann eben selbst hingesetzt und versucht etwas zu “bauen”. Ganz neu erfinden musste ich das ganze nicht. Es gab – wie so schön unter Linux – schon diverse Möglichkeiten und Tools. Dabei ist eines das zentrale und wichtigste: script. Mit Hilfe von script ist es möglich z.B. Befehlsfolgen aufzuzeichnen inkl. der Ausgabe. Wobei die Ausgabe ebenfalls alls Steuerzeichen für die Ausgabe enthällt. Im Endeffekt entsteht ein “Video” der Ausgabe, welches man beispielsweise zum Support schicken kann.
Das Programm um die Aufnahmen zu erstellen und abzuspielen war also gefunden. Als nächstes musste eine Lösung gefunden werden um die Aufzeichung automatisch und auch sicher zu starten. Es bringt nur relativ wenig wenn ich von einem Benutzer erwarte einen Befehl zu starten wenn er sich anmeldet, bzw. wäre es auch ein wenig albern das ganze als bsp. SOX konformes Monitoring zu deklarieren, wenn ich einfach den Prozess beenden kann und dem entsprechend dann machen kann was ich möchte ohne dass das ganze aufgezeichnet wird. Dazu wurden diverse Schritte nötig die im folgenden Howto enthalten sind.
Prerequisites
- jumphost (Server, über den alle ssh Zugriffe auf Server gestartet werden; dieser Host sollte der einzige sein, der Zugriff auf die Server hat (iptables, …))
- script (normalerweise in den linux-utils Paketen enthalten)
- das wars schon
Technische anpassungen
Anpassen der /etc/bashrc
Um den Benutzern nach der Umstellung weiterhin zu erlauben eigene alias Definitionen, bzw. Funktionen zu setzen, wird in der /etc/bashrc eine Kleinigkeit hinzugefügt:
# additional aliases to be set by the user
if [ -e /home/$USER/.bashrc_user ]; then
. /home/$USER/.bashrc_user
fi
Dadurch kann jeder Benutzer sich in der Datei ~/.bashrc_user seine eigenen Definitionen hinterlegen.
Anpassen der ~/.bashrc
Meldet ein Benutzer sich am Jumphost an, so muss das Programm “script” automatisch gestartet werden. Dies wird über die ~/.bashrc realisiert. Diese sieht aus wie folgt:
# jumphost configuration
#
# If you want to set own alias definitions, please
# create a file .bashrc_user in your homedirectory !!
#
script -c "/bin/bash --rcfile /etc/bashrc" -f -q -t 2>/adminmon/timing/`date +%Y%m%d_%H%M%S`-$$-$USER.timing /adminmon/output/`date +%Y%m%d_%H%M%S`-$$-$USER.script
wait
exit
Verzeichnisse
Die Daten (.script, .timing) werden in eigenen Verzeichnissen gesammelt. .script in einem Verzeichnis, welches nur von root gelesen und beschrieben werden darf, und eines für die .timing Dateien auf die der Benutzer kompletten Zugriff hat. Eigentlich könnte man sagen, dass doch beide Dateien in einem Verzeichnis liegen könnten, auf die der Benutzer selbst keinen Zugriff hat – richtig. Leider funktioniert das nicht mit script. script schreibt die Bildschirmausgaben per Parameter in eine Datei – also mit den Rechten des Benutzerkontextes unter dem script gestartet wird. Die Timing Informationen werden jedoch als Ausgabe auf STDERR von script ausgegeben und umgelenkt (s. Befehl in der .bashrc) – die .timing Datei wird also mit den Rechten des Benutzers geschrieben. script wird während der Konfiguration (s.u.) die setuid root Rechte bekommen. Dadurch wird das Programm zwar vom Benutzer gestartet, allerdings mit root Rechten. Das gilt wie eben beschrieben für die Ausgabedatei der Bildschirmdaten, jedoch nicht für die Umleitung der Timing Informationen. Daher die Verzeichnisse mit den verschiedenen Rechten.
[root@machine adm32]# ls -la /adminmon/
total 20
drwxrwxrwx 4 root root 4096 Sep 25 11:05 .
drwxr-xr-x 25 root root 4096 Sep 25 11:05 ..
drwx------ 2 root root 4096 Sep 25 14:22 output
drwxrwxrwx 2 root root 4096 Sep 25 14:22 timing
script setuid root
Aus oben genanntem Grund muss /usr/bin/script das setuid root Bit bekommen.
[root@machine adm32]# chmod u+s /usr/bin/script
Überwachungsscript
Das Überwachungsscript ist für die Überwachung der angemeldeten Benutzer verantwortlich. Überwachung in dem Sinne, als dass jeder Benutzer einen laufenden script Prozess besitzen muss – ansonsten wird er automatisch abgemeldet.
#!/bin/bash
# Security Script to check if all users are
# monitored by script to get typescripts of
# their doing.
#
# If a user runs a session without this, the
# user session will be terminated.
#
# Ronny Becker, 09.2009
#set -x
NOT="root bin daemon adm shutdown halt mail uucp operator ftp nobody dbus avahi mailnull smmsp nscd ntp vcsa rpc rpcuser nfsnobody sshd pcap haldaemon rpm xfs gdm"
# do a dumb loop
while [ 0 == 0 ]; do
# get processlist
PSDATA=`ps a -o user,tname,pid,command | sed 's/ *//'`
# users online ?
# to get unique users, set username = username(p)tty;
for ACTUSER in `who | awk '{print $1$2}'`; do
# if the user is in NOT list - continue
if [[ $NOT =~ ${ACTUSER%pts*} ]]; then
continue
else
# get proc information
DATA=`echo "$PSDATA" | grep "pts${ACTUSER#*pts}"`
if [[ $DATA =~ script\ -c\ /bin/bash\ --rcfile\ /etc/bashrc\ -f ]]; then
# delete /dev/null if you want to have more logging
echo "$ACTUSER: Proc found" > /dev/null
else
echo "$DATA" | while read PROCDATA; do
if [[ $PROCDATA =~ \-bash ]]; then
PID2KILL=`echo "$PROCDATA" | awk '{print $2}'`
# check if proc ist running > 10 secs
TIMEDIFF=$((`date +%s` - `stat --format=%Z /proc/${PID2KILL}`))
if [ $TIMEDIFF -lt 5 ]; then logger -t script_security -p local0.notice "User: ${ACTUSER%pts*} Msg: lt 5 secs without"; continue; fi
echo "Diese Session wird nun geschlossen, da die Protokollierung nicht mehr sichergestellt ist." | write ${ACTUSER%pts*}
sleep 3
kill -9 $PID2KILL
logger -t script_security -p local0.warning "User: $ACTUSER Msg: User killed PID: $PID2KILL"
fi
done
# delete /dev/null if you want to have more logging
echo "$ACTUSER: No proc found" > /dev/null
fi
fi
done
sleep 5;
done
Das Script überprüft alle 5 Sekunden den Status der Benutzer und loggt eventuelle “Zwischenfälle” per syslog. Zusätzlich müssen Benutzer mind. 5 Sekunden lang im System angemeldet sein, bevor die Session geschlossen wird. Das kommt daher, dass ein Benutzer den script Befehl erst während der Anmeldung startet und ansonsten die Session beendet werden könnte bevor er wirklich angemeldet ist.
Dieses Script muss quasi immer im Hintergrund laufen (als root). Als Daemon überwacht es dann jede Session.
Hilfe von cfengine
Bei einigen der “tasks” kann cfengine gute Dienste leisten. z.B. wenn es darum geht die ~/.bashrc eines jeden Benutzers zu prüfen oder die Verzeichnissrechte unterhalb von /adminmon. Desweiteren kann cfengine prüfen ob das Überwachungsskript läuft.
Abspielen einer Aufnahme
Aufnahmen werden mit Hilfe von “scriptreplay” abgespielt.
scriptreplay 20090925_142228-8287-adm31.timing 20090925_142228-8287-adm31.script
Um eine Aufnahme während der Wiedergabe anzuhalten, genügt der Shortcut STRG+S (Pause); zum Fortfahren STRG-Q.
Noch offen
- Cleanup Script erstellen (die zusammengehörigen .script / .timing Dateien sollten in ein .tar gepackt werden)
- Script erstellen um größere Wartezeiten in denen nichts passiert zu minimieren. Dazu werden einfach alle Werte (z.B.) > 5 innerhalb der .timing Datei auf 5 gesetzt.


