OpenVZ ist eine Virtualisierungstechnik für Linux. Damit lassen sich mehrere so genannte Virtual Private Server einrichten, die alle den Kernel und die Hardware des Host-Systems nutzen. Das Konzept ähnelt also anderen Techniken wie FreeBSD Jails und Solaris Zones. Auch als Gastsystem unterstützt OpenVZ ausschließlich Linux. Durch eine detaillierte Ressourcenaufteilung soll es möglich sein, sehr viele virtuelle Maschinen parallel auf einem physischen Computer zu betreiben, die alle streng voneinander isoliert sind. [golem.de]

Installieren kann man OpenVZ auf viele Linux basierten Betriebssysteme direkt aus den Paketquellen; im folgenden habe ich als Beispiel ein Debian (32bit) auf meinem DL380 G3 verwendet.

Zuerst müssen die passenden Kernel und Pakete installiert werden:

1

apt-get install linux-image-openvz-686 vzctl vzquota cstream

Leider ist das Tool vzdump nicht mehr in den Paketquellen enthalten, ist aber essentiell um eine virtuelle Maschine im laufenden Betrieb zu sichern:

1
2
3

cd /tmp/
wget http://download.openvz.org/contrib/utils/vzdump/vzdump_1.2-4_all.deb
dpkg -i vzdump_1.2-4_all.deb

Danach müssen in der Datei /etc/sysctl.conf folgende Punkte ergänzt werden:

1
2
3
4
5

net.ipv4.conf.default.proxy_arp = 0
net.ipv4.conf.default.forwarding=1
kernel.sysrq = 1
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.eth0.proxy_arp=1

Nach dieser Anpassung darf nicht vergessen worden, die Konfiguration neu einzulesen:

1

sysctl -p

Nun muss der Server neugestartet werden, damit der OpenVZ-Kernel auch verwendet wird.

Nun ist OpenVZ soweit eingerichtet und die ersten “virtuellen” Maschinen können eingerichtet werden.
Hier zeigt sich aber auch schon die erste Schwäche von dieser Virtualisierungslösung, denn entgegen anderen Methoden lassen sich mit OpenVZ nur genau das Betriebssystem mit dem Kernel für Guests verwenden, welcher auch der Host benutzt.

Nun da alles eingerichtet ist, können die ersten Templates heruntergeladen werden.
Dazu müssen zuerst die Paketquellen angepasst werden:

1

echo "deb http://download.openvz.org/debian-systs lenny openvz" >> /etc/apt/sources.list

Das der neue Eintrag problemlos funktioniert, muss noch der passende Schlüssel nachgeladen werden:

1
2

wget -q http://download.openvz.org/debian-systs/dso_archiv_signing_key.asc -O- | apt-key add -
apt-get update

Nun sollten auch die passenden Templates in den Paketquellen gelistet werden:

1

apt-cache search openvz | grep vzctl

Damit ein Guest mit diesem Template eingerichtet werden kann, muss er vorher natürlich noch heruntergeladen und installiert werden:

1

apt-get install vzctl-ostmpl-debian-4.0-i386-minimal vzctl-ostmpl-debian-5.0-i386-minimal

Nun kann auch schon mit dem Einrichten des ersten Guests begonnen werden.

Die dazu zur Verfügung stehenden Templates sind unter /var/lib/vz/template/cache/ gelistet.
Hier zeigt sich nun ein Vorteil von OpenVZ gegenüber den alternativen Virtualisierungslösungen. Das einrichten eines neuen Guest dauert hier gerade mal ein paar Sekunden, während bei ESX oder Xen normalerweise stets die gesamte Installation durchlaufen werden muss. Das eintippen eines einfachen Befehls reicht schon aus:

1

vzctl create 1 --ostemplate debian-5.0-i386-minimal --config vps.basic

Erhält man danach eine Ausgabe, wie die folgende, so war die Aktion erfolgreich:

1
2
3

Creating VE private area (debian-5.0-i386-minimal)
Performing postcreate actions
VE private area was created

Nun hat man die Möglichkeit direkt Einstellungen für einen Guest vorzunehmen:

1
2
3
4
5
6
7
8
9
10
11

#Beim Booten aufstarten
vzctl set 1 --onboot yes --save
 
#Hostname setzen
vzctl set 1 --hostname tux1.linux.ch --save
 
#IP Adresse setzen
vzctl set 1 --ipadd 192.168.0.1 --save
 
#DNS Server setzen
vzctl set 1 --nameserver 145.253.2.75 --nameserver 213.191.92.86 --save

Alle nun gemachten Einstellungen werden in der Datei /etc/vz/conf/1.conf gespeichert.

Nun kann der Guest das erste mal gestartet und gleichzeitig auch noch das Rootpasswort angepasst werden:

1
2

vzctl start 1
vzctl exec 1 passwd

Will man den Guest direkt auf der Kommandozeile ansprechen, so kann dies entweder per SSH oder direkt über den Host passieren. Dazu kann folgendes Kommando verwendet werden:

1

vzctl enter 1

Eine List mit allen virtuellen Maschinen erhält man mit dem Befehl vzlist:

1

vzlist -a

Weitere Informationen bekommt man durch die Manpages:

1

man vzctl

oder dem offiziellen Wiki

Was ich bisher noch nicht finden konnte ist eine Möglichkeit mit vzctl set 1 … den Guest zu einer dynamischen IP Adresse zu zwingen.

Insgesamt ist es eine gute Möglichkeit um schnell und unkompliziert zu virtualisieren, jedoch wer viele Ansprüche hat und nicht immer das selbe Betriebssystem / die selbe Distribution verwendet, wird nie seinen Spass an OpenVZ haben.

Natürlich lässt sich alles problemlos auch auf andere Distributionen und Architekturen portieren, wobei die Namen, besonders für die Templates, angepasst werden müssen.

1
2
3

Erreichte Punkte: 620
Erforderliche Punktzahl: 500
Status: Pass

Diese Prüfung habe ich, im Vergleich zu LPI 101, als viel einfacher empfunden.
In 102 geht es Hauptsächlich um Shell-Scripting, Cron und X11, wobei das Hauptgewicht in meiner Prüfung klar auf Scripting lag:

1
2
3
4
5
6

80% Shells, Scripting and Data Management
80% User Interfaces and Desktops
50% Administrative Tasks
80% Essential System Services
78% Networking Fundamentals
66% Security

Vorbereitet habe ich mich neben dem offiziellen Script auch noch mit dem Buch LPIC-1 von Harald Maassen aus dem Galileo Computing Verlag.
Für LPIC 101 habe ich zwar noch ein anderes Buch verwendet, aber wenn ich heute einen Vergleich machen und eines der beiden Bücher empfehlen müsste, so würde ich mich klar für LPIC-1 entscheiden, da es in meinen Augen den Stoff besser abdeckt und realistischere Testfragen vorweisen kann.
Die Testfragen waren sogar teils so realistisch, das sie mit exakt dem Wortlaut an der Zertifizierungsprüfung vorkamen

Mit bestandener LPIC-1 Zertifizierung konnte ich auch gleich das Novell CLA beantragen, da Novell vor etwa einem Jahr gemerkt hat, dass sich die Prüfungsinhalte von CLA mit denen von LPIC-1 überschneiden, und seither jeder mit bestandenem LPIC-1 das Novell CLA geschenkt bekommt.

Nun bleibt nicht mehr viel übrig, als auf meine Zertifikate zu warten und dann auf zu LPIC-2. Und natürlich auch meinem Mitstreiter zu gratulieren

Dieses Blog habe ich vor zwei Jahren gegründet, um über tägliche Probleme und Situationen aus meine täglichen Leben als Informatiker zu berichten. Zu Beginn waren meine Beiträge noch hauptsächlich über Windows und haben sich dann immer mehr und mehr zu den Themen Linux und OpenSource entwickelt. Und besonders seid ich auch auf der Arbeit dem Linux / Unix-Team unterstellt bin, werden Windows-Probleme immer rarer, was ich aber nicht als besonders schlimm befinde

Nun bleibt mir nicht mehr viel übrig als euch für eure Treue und Unterstützung zu danken und mich auf viele weitere erfolgreiche Jahre mit euch zu freuen!!

Nun das ist so meine Geschichte.

Und nun zu euch!
Folgend kannst du die Distributionen auswählen, die du regelmässig verwendest. Interessant wäre auch noch, wieso ausgerechnet diese?

Sollte ich eine vergessen habe, sorry

Für jemand, der das schon ein paar mal gemacht hat, mag das einfach klingen, ich weiss – für mich war es aber alles andere als das

Jedoch, da ich auch schon mal für Windows paketiert habe, kann ich auch gleich einen Vergleich anstellen: Es ist viel unkomplizierter und einfacher unter Linux, wenn das SPEC-File mal steht… wenn

Doch nun zum Vorgehen!
Der Kern des Paketieren stellt das Programm rpmbuild und eine selbst erstellte SPEC-Datei dar.
Die SPEC-Datei kann man dabei wie eine Art Anleitung ansehen, wo aufgeschrieben wird, wann was getan werden soll. Anhand dieser Anleitung erstellt rpmbuild dann ein Paket.

Die allgemeine Funktionsweise habe ich mir aus dem Internet angeeignet. Besonders geholfen dabei hat mir diese Anleitung.

Das Problem aber, all diese Anleitungen basieren darauf, dass der Source aus dem Internet nachgeladen wird. Mein Paket musste aber alle Dateien lokal zur Verfügung haben.

Nun die erste Herausforderung: Wie mach ich das?
Nach viel probieren und testen hatte ich endlich eine Lösung… Unter dem Punkt %files werden die Dateien so aufgelistet, wie sie danach beim Zielsystem kopiert werden:

1
2
3
4
5
6

%files
/opt/itc/bin/soe-rootadd
/opt/itc/bin/soe-updatepubkeys
/opt/itc/prepost/install_post.sh
/opt/itc/prepost/remove_post.sh
/opt/itc/.sshsoe_id

Während dem Erstellen des Paketes mussten die Dateien aber im Ordner ~/rpmbuild/BUILDROOT/Paketname/opt/itc/../ liegen, damit es korrekt in das RPM integriert wird.

Die zweite Herausforderung war das Script: Unter %pre, wo ich auch alle Ordner erstellen liess, konnte ich das Script nicht starten, da zuerst %pre und danach erst %files abgearbeitet wird, wodurch das Script beim Starten noch gar nicht an seinem Platz ist.
Also habe ich es kurzerhand unter %install abgelegt. Doch aus welchem Grund auch immer – da wurde es nie gestartet…
Darauf habe ich ohne noch lange weiterzuprobieren, das Script unter %post abgelegt, welcher nach der Installation abgearbeitet wird.

Das die Dateien dann beim Deinstallieren wieder gelöscht werden, war ein kleines Problem. Einfach alles unter %preun eintragen und gut ist.

Mein SPEC-File sah am Schluss so aus:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

...
%pre
mkdir -p /opt/itc/bin/
mkdir -p /opt/itc/ssh/pubkeys/
mkdir -p /opt/itc/prepost/
 
%post
/opt/itc/bin/install_post.sh
 
%preun
/opt/itc/bin/remove_post.sh
rm -f /opt/itc/bin/soe-rootadd
rm -f /opt/itc/bin/soe-updatepubkeys
rm -f /opt/itc/bin/install_post.sh
rm -f /opt/itc/bin/remove_post.sh
rm -f /opt/itc/.sshsoe_id
 
%prep
%build
%install
%clean
rm -rf $RPM_BUILD_ROOT
 
%files
/opt/itc/bin/soe-rootadd
/opt/itc/bin/soe-updatepubkeys
/opt/itc/prepost/install_post.sh
/opt/itc/prepost/remove_post.sh
/opt/itc/.sshsoe_id

Beim erstellen des Paketes zeigt sich dann die Stärke von Linux. Auf dem 32Bit System, welches ich zur Erstellung verwendet habe, habe ich ohne Probleme mit dem Parameter –target x86_64 ein Paket für 64Bit Systeme erstellt.
Das Begeistert mich deshalb so, denn unter Windows konnte ich auf einem 32Bit-Host auch nur ein Paket für dessen Architektur machen.
Und da ich schon damit gerechnet hatte, für jede Architektur ein eigenes Hostsystem aufzusetzen, war ich umso erfreuter

Nun ist aber schon einige Zeit vergangen und es ist mal an der Zeit um eine Bilanz zu ziehen.
Wie sieht es denn bei euch so aus?

Und interessant wäre auch noch wieso?

Auch wenn NIS als älter und unsicherer gilt als LDAP, hat es für mich ein klarer Vorteil: es ändert sich nicht immer komplett!
Wer schon mal ein LDAP auf einem Ubuntu Server 8.04 und 8.10 installiert hat, kann nachvollziehen was ich meine. So und damit genug, ich will hier nicht über LDAP herziehen, sondern NIS vorstellen

Ich habe mir also mit NIS und NFS innert wenigen Minuten eine zentrale Benutzerverwaltung mit zentralem Homeverzeichnis eingerichtet. Und wie das geht, folgt hier:

Ich habe mit dem NIS Server begonnen und dazu die Pakete für NFS und NIS aus den Paketquellen installiert.

1

apt-get install nfs-kernel-server nis

Während der Installation, nachdem man einen Namen für die Domäne eingegeben hat, versucht apt automatisch den NIS Daemon zu starten, was auf Grund mangelnden Einstellungen aber nie funktionieren wird. Also zurück lehnen, und auf den Fehler warten

Nun beginnt die Konfiguration. In der Datei /etc/default/nis wird die NIS-Installation von Client zum Server umgebogen:

1
2
3
4

# Are we a NIS server and if so what kind (values: false, slave, master)?
NISSERVER=true
# Are we a NIS client?
NISCLIENT=false

Dann geben wir in der Datei /etc/exports unser Homeverzeichnis frei:

1

/home	*(rw,async,no_subtree_check)

Wer es gern sicherer hat, kann den Stern durch einen Computernamen oder eine IP mit Subnet ersetzen, wodurch dann nur der Zugriff von diesen Maschinen aus gestattet ist.

Nun kann man den Daemon neu starten:

1

/etc/init.d/nis restart

Und zum Abschluss muss man noch die Maps generieren lassen. Dazu ruft man folgenden Befehl auf:

1

/usr/lib/yp/ypinit -m

Nun ist der NIS Server soweit fertig. Es können nun normal User hinzugefügt werden, die bereits bestehenden werden im NIS aufgenommen.
Wichtig jedoch, nach einer Änderung an einem User oder einer Gruppe, also Änderungen, welche die passwd, group, shadow oder gshadow datei verändern, folgender Befehl ausgeführt wird, um die Maps zu erneuern:

1
2

cd /var/yp/
make

Nun noch alle benötigten Daemons neu starten:

1
2
3

/etc/init.d/portmap restart
/etc/init.d/nfs-kernel-server restart
/etc/init.d/nis restart

Und zum Schluss die Verwendung des NIS Servers starten:

1
2

ypbind
ypserv

Ein Aufruf von ypwhich sollte nun den Namen oder die IP des NIS Masterserver und ypdomainname den Namen der NIS Domäne ausgeben.

Nun muss der Client, welcher NIS verwenden soll, noch vorbereitet werden!
Auch hier wird das Paket NIS aus den Paketquellen installiert:

1

apt-get install nis nfs-common

Im Gegensatz zu vorher sollte sich hier der NIS Daemon nach Eingabe der selben Domäne erfolgreich starten, da der NIS Server über Broadcast-Pakete gesucht wird.

Trotzdem sollte der NIS Server noch fest in die Datei /etc/yp.conf eingetragen werden:

1

ypserver nismaster.ch

Nun müssen noch die passwd, group, shadow und gshadow angepasst werden und jeweils folgenden Zusatz als letzte Zeile haben:
/etc/passwd:

1

+::::::

/etc/group:

2

+:::

/etc/shadow:

3

+::::::::

/etc/gshadow:

4

+:::

Nachdem der Client nun die Userinformationen vom NIS Server verwenden kann, muss noch das Homeverzeichnis konfiguriert werden.
Dazu wird die Datei /etc/fstab mit folgender Zeile ergänzt:

1

nismaster.ch:/home  /home  nfs  rsize=8192,wsize=8192,hard,intr  0  0

Nun sollte auch hier noch der NIS Daemon neugestartet werden:

1

/etc/init.d/nis restart

Wird nun ypwhich und ypdomainname ausgeführt, so sollten deren Ausgaben mit denen vom Server übereinstimmen.
Wenn nun der Client nun gestartet wird, so sollte beim Start zuerst das home-Verzeichnis vom Server gemountet werden und danach eine Verbindung zum NIS Server mit der konfigurieren Domäne hergestellt werden, worauf man sich dann mit jedem auf dem Server zugefügten Benutzer auch auf dem Client einloggen kann.

This codelab shows how web application vulnerabilities can be exploited and how to defend against these attacks. The best way to learn things is by doing, so you’ll get a chance to do some real penetration testing, actually exploiting a real application.

Für alle die, welche dem Englisch nicht so mächtig sind: Jarlsberg ist eine Webapplikation von Google zum Thema Web Application Security. Basierend auf Python wird jedem Benutzer in einer eigenen Session eine Webseite präsentiert voll mit Sicherheitslücken von XSS über DOS bis hin zu XSRF und Path Traversal.

Neben dieser Webseite gibt es auch noch eine sehr ausführliche und gut erklärte Dokumentation zu jedem Exploit mit einer Erklärung wie man diesen auch beheben könnte (verfasst in Englisch).
Nachdem ich die Dokumentation nun mal komplett durchgearbeitet habe, muss ich sagen, es lohnt sich wirklich die 5 Seiten komplett zu lesen!
Jedoch muss ich auch sagen, in meinen Augen sind ein paar der vorgestellten Exploits ein wenig Realitätsfremd, da man z.B bei einem Pentest nur sehr wenig direkten Zugang zum Sourcecode hat.

Nichts desto trotz, wer es selbst mal ausprobieren will, und das kann ich wirklich jedem empfehlen, der klickt nun hier:

Anmerkung: Es handelt sich hier nicht um Braindumps, sondern um eine Zusammenfassung der Materie!!

Doch interessanter als das Protokoll ist was man damit machen kann
Ist in einem Netzwerk ARP freigegeben (was auch häufig der Fall ist), so kann man dies in Kombination mit einem Switch zu einer Man-in-the-Middle-Attacke verwenden.

Doch von vorne! Es gibt zwei “Probleme”:
Problem 1…
Der Client führt eine Cache, wo er eine IP- einer MAC-Adresse zuordnet. Dies wird verwendet, dass nicht vor dem Versenden eines Datenpaketes jedes mal zuerst noch eine neue Abfrage der MAC-Adresse gemacht werden muss.
Dieser Cache kann aber von einem anderen Client mit den nötigen Mitteln verändert werden. D.h. ich als Angreifer kann den Cache des Opfers so verändern, dass der IP-Adresse eines z.B. gerade eben besuchten Servers nicht mehr die tatsächliche MAC-Adresse des Servers, sondern eine beliebige zugeordnet wird.

Das alleine wäre ja noch nicht so schlimm, wäre da nicht noch Problem 2…
Hier kommt dann der Switch ins Spiel. Ein Switch hat gegenüber einem Hub einen grossen Unterschied. Ein Hub sendet den Traffic von einem Port einfach an alle anderen aktiven Ports, in der Hoffnung, dass nur derjenige den Traffic liest, welcher ihn auch angefragt hat.
Der Switch hingegen; damit der Traffic nicht jedes mal an alle Ports versandt werden muss, führt eine Zuordnungsliste, wo festgelegt wird, welches Gerät (anhand der MAC-Adresse) an welchem Port angeschlossen ist.

Auch Problem 2 wäre alleine kein Problem, doch zusammen!!
Ein Angreifer manipuliert den Cache eines Clients nun so, das die IP-Adresse des Server nicht mehr der MAC-Adresse des Server, sondern der des Angreifers zugeordnet ist.
Da der Client davon nichts mitbekommt, nimmt er die MAC-Adresse des Angreifers aus seinem Cache, in der Meinung es wäre die Adresse des Servers und schickt diese mit seinem Datenpaket zum Switch.
Der Switch nun liest die MAC-Adresse aus und erkennt die MAC-Adresse des Angreifers. Beim Vergleich mit seiner Zuordnungsliste wird das ganze Paket nun nicht mehr an den Switchport des Servers, sondern an den des Angreifers versandt.
Macht der Angreifer das gleiche nun auch noch mit dem Server, so kann er jeden Traffic zwischen einem Client und einem Server mitlesen und beliebig manipulieren.

Man sagt ja, in der Theorie ist es meistens einfacher, als in der Praxis. Das Problem von ARP Spoofing ist aber, dass dies hier nicht stimmt!!
Mit nur wenigen Klicks und einem Paket aus den Ubuntu Paketquellen lässt sich mittels ARP Spoofing eine komplette Man-in-the-Middle-Attacke durchführen.
Wie genau – das soll jeder alleine herausfinden, doch das Paket dsniff könnte helfen