Also bietet sich ein Lizenzserver an. Dieser wird mit Internetverbindung hochgezogen, KMS aktiviert und von Microsoft validiert und dann in die geschützte Umgebung verschoben. Die Vista Maschinen aktivieren ihren Schlüssel von nun an nur noch über den Lizenzserver. So braucht keine der Maschinen, weder Client noch Server im laufenden Betrieb je wieder eine Internetverbindung.

Installiert ist das ganz einfach. Unter Windows 2003 lädt man sich den Key Management Service 1.1 für Server 2003 passend zur Architektur herunter und installiert diesen.
Danach wird ein Volumekey von Microsoft benötigt für Windows 2003 oder Windows 2008 mit der Option Vista als KMS zu aktivieren. Ist auch dieser aufgetrieben, so kann über das Kommando slmgr die ganze Installation durchgeführt werden. Zuerst wird der Key eingepflegt:

slmgr /ipk xxxxx-xxxxx-xxxxx-xxxxx-xxxxx

Und dann noch bei Microsoft validiert:

slmgr /ato

Sind beide Vorgänge erfolgreich, so kann die Maschine in die geschützte Umgebung verschoben werden. Idealerweise läuft auf der selben Maschine auch gleich noch ein AD / DNS, dann werden auch gleich noch die passenden DNS-Einträge generiert.

Auf allen Vista Maschinen kann nun der folgende Key eingetragen werden:

Windows Vista Business – YFKBB-PQJJV-G996G-VWGXY-2V3X8
Windows Vista Business N – HMBQG-8H2RH-C77VX-27R82-VMQBT
Windows Vista Enterprise – VKK3X-68KWM-X2YGT-QR4M6-4BWMV
Windows Vista Enterprise N – VTC42-BM838-43QHV-84HX6-XJXKV

Dies sind nur Standardkeys, welche dem Lizenzserver zur Erkennung dienen.

Auf dem Lizenzserver wiederrum kann man nun mit slmgr wiederrum sehen, wie viel Requests man schon bekommen hat:

slmgr /dli

Sobald der Count die Zahl 25 erreicht hat, also sobald 25 Maschinen sich aktivieren wollen, werden die Maschinen validiert. Vorher, und fragt mich jetzt ja nicht nach dem Sinn dahinter, gibt der Lizenzserver immer einen Fehler zurück. Wer also weniger als 25 Maschinen hat, der muss noch ein paar Virtuelle Maschinen oder ähnliches dazu aktivieren.

Das könnte dich auch interessieren:

1. Windows session credentials cannot be used to log into this server Ist der ESX-Server ans AD angebunden, so liegt es ja...
2. Syslog Server für ESXi Nach dem ich entdeckt hatte, dass der ESX so intelligent...

Die alteingesessenen Nagios-Admins kennen das Problem: Es ist keines, es ist ein Feature – so habe ich mich von der Community belehren lassen!

Es hängt zusammen mit einer Statusdatei, welche Nagios anlegt, damit nach einem Neustart des Daemons nicht immer alle Checks ohne Daten dastehen und erst alles wieder aufgebaut werden muss. Deshalb wird darin der letzte Zustand gespeichert und dann auch abgerufen.
Wieso dabei auch der Hostname gespeichert und aus dieser Datei anstelle der Konfigurationsdatei ausgelesen wird, kann ich mir leider nicht erklären. Aber eben: Das ist ein Feature, kein Bug!

Die Lösung des Problems liegt darin, dass der Name nicht nur in der offiziellen Konfigurationsdatei, sondern auch in der Statusdatei unter var/retention.dat angepasst wird. Bevor das geschieht, muss aber der Nagios-Daemon gestoppt werden.

Also (der Pfad der Nagios-Installation bitte anpassen):

/etc/init.d/nagios stop
vi /usr/local/nagios/var/retention.dat
/etc/init.d/nagios start

Verzweifelt nicht an euer Sehkraft, es ist wirklich so

Das könnte dich auch interessieren:

1. Unbekannte Systeme in Nagios Die Nagios Status Map ist ja eine ganz feine Sache,...
2. Notification von Nagios ans iPhone Auf der Suche nach einer Lösung, wie ich die Notifications...
3. Windows Updates prüfen mit Nagios Um unserer Server optimal überwachen zu können, habe ich eine...
4. Nagios als Inventory-Lösung Heute bin ich über ein interessantes Script gestossen, welches aus...
5. NRPE Module installieren Aktuell arbeite ich an einer Lösung, um mittels Nagios zu...

Heute habe ich eine interessante Seite entdeckt, die nennt sich youhavedownloaded.com. Dies ist eine Suchmaschine für eine Datenbank, welche sich an öffentliche Torrent Tracker anhängt und jeden Zugriff mit IP und Dateiname protokolliert.
Und die Datenbank kann sich echt sehen lassen:

Users in database: 52,902,000
Torrents: 113,200
Files: 1,955,000
Files size: (106.07 TB)

Die Seite ist darauf ausgerichtet, um zu sehen, ob die eigenen Downloads protokolliert wurden, doch viel interessanter finde ich es, das ganze mal in der Firma laufen zu lassen.
Da kannst du live mitverfolgen, was so alles heruntergeladen wird.
Für Private ist es eher langweilig, wegen der dynamischen IPs, welche die meisten Provider vergeben!

Und ja, ich weiss! Torrents gibt es nicht nur für illegale Downloads, aber die Statistiken von youhavedownloaded.com sprechen auch hier Bände:

Top 5 themes
Music
Movies
TV-shows
Games
Applications

Top 5 regions
China
United States
Spain
United Kingdom
Taiwan

Beides gibt es leider nicht bei meinem ESXi Server. Noch nicht mal eine anständige iptable oder hosts.deny sind vorhanden, geschweige denn von einer Firewall, wie es bei ESX Standard ist.

Um jedoch mal zu sehen, wie viele Personen versuchen, mein SSH zu knacken, habe ich ein einfaches kleines Script für Nagios geschrieben.

Ich weiss es kann noch viel optimiert werden dabei, doch es erfüllt seinen Zweck:

#!/bin/bash

# ####################################################################
# Check Syslog /var/log/SPLVS002.log for Brute Force Attacks via SSH
# by Patrick Schmid
# Version 1.0
######################################################################

export STATE_OK=0
export STATE_WARNING=1

time=`date +%H.%M.%S |cut -d'.' -f1`
time=`echo $time|sed 's/^0*//'`
time2=$(( $time - 1))
time3=$(( $time - 2))

if [ $time -lt 10 ]; then
        time=0$time
fi

if [ $time2 -lt 10 ]; then
        time2=0$time2
fi

if [ $time3 -lt 10 ]; then
        time3=0$time3
fi

compare=`tail -300 /var/log/SPLVS002.log |grep "from" |grep "root" |grep "attempt" | cut -d' ' -f3`
compare=`echo $compare | cut -d' ' -f1`

if [ $compare -lt 10  ]; then
        attackers=`tail -300 /var/log/SPLVS002.log |grep "from" |grep "root" |grep "attempt" | cut -d' ' -f4,14 |cut -d':' -f1,2,3 |sed -e 's/://' | tee -a |sed -e 's/://' |tee -a |grep "^$time\|^$time2\|^$time3" |cut -d' ' -f2 |sort |uniq`
        computers=`tail -300 /var/log/SPLVS002.log |grep "from" |grep "root" |grep "attempt" | cut -d' ' -f4,14 |cut -d':' -f1,2,3 |sed -e 's/://' | tee -a |sed -e 's/://' |tee -a |grep "^$time\|^$time2\|^$time3" |cut -d' ' -f2 |sort |uniq |wc -l`
        attemps=`tail -300 /var/log/SPLVS002.log |grep "from" |grep "root" |grep "attempt" | cut -d' ' -f4,14 |cut -d':' -f1,2,3 |sed -e 's/://' | tee -a |sed -e 's/://' |tee -a |grep "^$time\|^$time2\|^$time3" |cut -d' ' -f2 |sort |wc -l`
else
        attackers=`tail -300 /var/log/SPLVS002.log |grep "from" |grep "root" |grep "attempt" | cut -d' ' -f3,13 |cut -d':' -f1,2,3 |sed -e 's/://' | tee -a |sed -e 's/://' |tee -a |grep "^$time\|^$time2\|^$time3" |cut -d' ' -f2 |sort |uniq`
        computers=`tail -300 /var/log/SPLVS002.log |grep "from" |grep "root" |grep "attempt" | cut -d' ' -f3,13 |cut -d':' -f1,2,3 |sed -e 's/://' | tee -a |sed -e 's/://' |tee -a |grep "^$time\|^$time2\|^$time3" |cut -d' ' -f2 |sort |uniq |wc -l`
        attemps=`tail -300 /var/log/SPLVS002.log |grep "from" |grep "root" |grep "attempt" | cut -d' ' -f3,13 |cut -d':' -f1,2,3 |sed -e 's/://' | tee -a |sed -e 's/://' |tee -a |grep "^$time\|^$time2\|^$time3" |cut -d' ' -f2 |sort |wc -l`
fi

[ "$attackers" ] && echo -e "$attemps attemps from $computers attackers\n$attackers"
[ "$attackers" ] || echo "No Attack running"

[ "$attackers" ] && exit $STATE_WARNING
[ "$attackers" ] || exit $STATE_OK

Und schon sieht man in Nagios selbst, was so abgeht:

So dann weiter im Konzept! Es gibt zwar keine Möglichkeit, Angreifer aussperren oder ähnliches, jedoch aber kann man verhindern, dass das Passwort erraten werden kann, indem man das Login mit einem zusätzlichen Zertifikat schützt. Wie das geht, lest ihr in den folgenden Zeilen!

Zuerst wird ein Key generiert, mit ssh-keygen.
Nun kann der Public-Key kopiert werden, denn dieser muss auf den ESX wie folgt eingefügt werden:

mkdir /.ssh
touch /.ssh/authorized_keys
chmod 0600 -R /.ssh
echo "ssh-rsa KEY_HIER_EINFÜGEN" >> /.ssh/authorized_keys

Nun kann man das Login schon mal prüfen. Hier sollte man bereits mit dem Key einloggen können.

Jetzt wird das ganze noch abgesichert, damit es auch einen Reboot übersteht. Einfach den obigen Part in die Datei /etc/rc.local einfügen und abspeichern.
Und zu guter Letzt wird noch das Login ohne Zertifikat deaktiviert. Dazu wird in der Datei /etc/inetd.conf den beiden Punkten “ssh” der Parameter -s angefügt:

ssh      stream   tcp   nowait   root   /sbin/dropbearmulti   dropbear ++min=0,swap,group=shell -s -i -K60
ssh      stream   tcp6  nowait   root   /sbin/dropbearmulti   dropbear ++min=0,swap,group=shell -s -i -K60

Von nun an ist ein Login nur noch mit Zertifikat möglich, wodurch auch die lästigen Bots ausgebremst werden.

Das könnte dich auch interessieren:

1. Syslog Server für ESXi Nach dem ich entdeckt hatte, dass der ESX so intelligent...
2. ESXi sichern auf FTP Vor einiger Zeit hatte ich die Aufgabe ein Backup-Konzept für...
3. Vmware Image für ESXi aufbereiten Für eine Analyse gab es diese Woche eine Installation von...
4. DNS-320 mit fun_plug zu SSH Ganz cool an meinem NAS DNS-320 ist die Funktion des...
5. NAT konfigurieren unter ESX(i) NAT ist so eine Sache. Unter Vmware Workstation sehr einfach...

Da ich sowas noch nie eingerichtet hatte, war ich mir nicht ganz sicher, was auf mich zu kommen würde. Nun aber kann ich sagen, schreckt nicht davor zurück! Das Einrichten geht schnell und einfach und der Gewinn daraus ist enorm.

Auf meinem Ubuntu Server habe ich mich für syslog-ng entschieden, welches problemlos über die Paketquellen installiert werden kann:

apt-get install syslog-ng

Nun muss die Konfiguration unter /etc/syslog-ng/syslog-ng.conf angepasst werden.
Eingefügt habe ich die folgenden Punkte für jeweils einen ESX und einen normalen Ubuntu-Server:

source s_udp
{
        udp(port(514));
};

destination d_server1 {
        file("/var/log/server1.log");
};

filter f_server1 {
        host("192.168.1.45");
};

log {
        source(s_udp);
        filter(f_server1);
        destination(d_server1);
};

destination d_server2 {
        file ("/var/log/server2.log");
};

filter f_server2 {
        host("192.168.1.23");
};

log {
        source(s_udp);
        filter(f_server2);
        destination(d_server2);
};

Somit sei es den beiden Hosts mit der Adresse 192.168.1.23 und 192.168.1.45 über den Port UDP/514 erlaubt, Daten an den Syslog-Server zu senden, welche jeweils unter /var/log/server1.log und server2.log abgelegt werden.

Noch neustarten und gut ist:

/etc/init.d/syslog-ng restart

Nun geht es weiter auf den zu überwachenden Servern!
Hier fügt man folgende Zeile in die Konfiguration unter /etc/syslog.conf ein:

*.* @192.168.1.25

192.168.1.25 ist dabei natürlich die IP des Syslog-Servers. Aktuell wird hier alles geloggt, was so auf der Maschine abgeht. Wer das ganze noch genauer spezifizieren will, der findet entsprechende Parameter bei Google.
Auch hier ist noch ein Neustart nötig und schon sind die entsprechenden Infos auf dem Syslog-Server ersichtlich:

/etc/init.d/sysklogd restart

Auf dem ESX Server kann der Syslog-Server über den vSpehre-Client gesetzt werden. Einfach unter “Configuration” > “Advanced Settings” > “Syslog” > “remote” IP und Port eintragen.

Und nun dürft ihr auch schon all die Kiddies und Bots bewundern, welche versuchen euer SSH-Passwort zu knacken

Nov 30 12:17:17 server1 sshd[11775]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=180.227.218.245  user=root
Nov 30 12:17:19 server1 sshd[11775]: Failed password for root from 180.227.218.245 port 34035 ssh2
Nov 30 12:17:22 server1 sshd[11777]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=180.227.218.245  user=root
Nov 30 12:17:23 server1 sshd[11777]: Failed password for root from 180.227.218.245 port 34311 ssh2
Nov 30 12:17:26 server1 sshd[11779]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=180.227.218.245  user=root
Nov 30 12:17:28 server1 sshd[11779]: Failed password for root from 180.227.218.245 port 34525 ssh2
Nov 30 12:17:30 server1 sshd[11784]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=180.227.218.245  user=root
Nov 30 12:17:33 server1 sshd[11784]: Failed password for root from 180.227.218.245 port 34770 ssh2
Nov 30 12:17:35 server1 sshd[11795]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=180.227.218.245  user=root
Nov 30 12:17:37 server1 sshd[11795]: Failed password for root from 180.227.218.245 port 35037 ssh2
Nov 30 12:17:39 server1 sshd[11800]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=180.227.218.245  user=root
Nov 30 12:17:42 server1 sshd[11800]: Failed password for root from 180.227.218.245 port 35313 ssh2
Nov 30 12:17:44 server1 sshd[11805]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=180.227.218.245  user=root
Nov 30 12:17:47 server1 sshd[11805]: Failed password for root from 180.227.218.245 port 35591 ssh2
Nov 30 12:17:49 server1 sshd[11807]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=180.227.218.245  user=root
Nov 30 12:17:51 server1 sshd[11807]: Failed password for root from 180.227.218.245 port 35809 ssh2
Nov 30 12:17:54 server1 sshd[11842]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=180.227.218.245  user=root
Nov 30 12:17:56 server1 sshd[11842]: Failed password for root from 180.227.218.245 port 36091 ssh2
Nov 30 12:17:58 server1 sshd[11848]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=180.227.218.245  user=root
Nov 30 12:18:00 server1 sshd[11848]: Failed password for root from 180.227.218.245 port 36361 ssh2
Nov 30 12:18:02 server1 sshd[11850]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=180.227.218.245  user=root

Wer auch dem Abhelfen will, der soll sich mal das Tool denyhosts ansehen! Ansonsten ein sicheres Passwort, Zertifikate oder was ihr gerade lustig seid. Ideen gibts genug!

Das könnte dich auch interessieren:

1. ESXi sichern auf FTP Vor einiger Zeit hatte ich die Aufgabe ein Backup-Konzept für...
2. Vmware Image für ESXi aufbereiten Für eine Analyse gab es diese Woche eine Installation von...
3. Windows session credentials cannot be used to log into this server Ist der ESX-Server ans AD angebunden, so liegt es ja...
4. DNS-320 mit fun_plug zu SSH Ganz cool an meinem NAS DNS-320 ist die Funktion des...
5. NAT konfigurieren unter ESX(i) NAT ist so eine Sache. Unter Vmware Workstation sehr einfach...

Importieren ging gut und schnell, beim ersten Starten dann das ernüchternde Ergebnis:

Unable to create virtual SCSI device for scsi0:0, ‘/vmfs/volumes/datastore1/test/old.vmdk’ Failed to open disk scsi0:0: Unsupported or invalid disk type 7. Make sure that the disk has been imported.

Die Fehlermeldung produziert zwar viel Text, sagt aber nicht wirklich etwas aus… Ein einfaches “Falsche Vmware Version des vmdk” wäre weit aufschlussreicher gewesen.
Wie auch immer schlussendlich aber, konnte ich dank der 7 im Namen, welche sehr wahrscheinlich auf die Virtual Maschine Version: 7 verweist, den Fehler auf eine veraltete Version eingrenzen, worauf auch die Lösung sehr schnell gefunden war:

~ # vmkfstools -d thin -i "/vmfs/volumes/datastore1/test/old.vmdk" "/vmfs/volumes/datastore1/test/new.vmdk"
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/datastore1/test/old.vmdk'...
Clone: 100% done.
~ #

Und seither läuft die Maschine wunderbar!

Also gilt es, das manuell einzurichten, was Vmware Workstation mir sonst abnimmt: Mit einem weiteren virtuellen Switch und einer Installation von pfSense.

Rein logisch sollte das so funktionieren: Der Client bezieht von pfSense eine interne IP, da er am selben Switch hängt, wie der DHCP. Ein Paket geht nun vom Client über den Switch zum LAN-Interface von pfSense und dann über das WAN-Interface auf den öffentlichen Switch ins Internet. Ganz einfach oder?

Als erstes wird der virtuelle Switch zugefügt. Jedoch wird dieser nicht an ein virtuelles Interface gebunden, schliesslich soll da ja nichts nach draussen gehen.
Nun wir eine VM erstellt mit zwei Netzwerkkarten, eine ans “VM Network”, welches über das Netzwerk erreichbar ist, und eine an das eben erstellte Netzwerk, nennen wir es “NAT Network”. Darauf wird nun pfSense installiert. Die Konfiguration ist gänzlich normal, es muss nur darauf geachtet werden, dass das WAN Interface der Karte mit Anbindung an das “VM Network” und das LAN Interface der Karte mit Anbindung an das “NAT Network” entspricht.

In ESX(i) würde das nun etwa so aussehen:

Nun kann eine neue Maschine einfach dem “NAT Network” zugefügt werden, und bezieht via DHCP eine IP Adresse! So schwer ist das ja gar nicht

Das könnte dich auch interessieren:

1. Installation von Moodle unter Debian Moodle ist eine Lernplattform auf Basis von Opensource, welche bereits...

Das Tool ermöglicht es mir, auf einfache und bequeme Art und Weise eine Maschine (auch remote) mit einer von Microsoft gepflegten Datenbank mit allen Updates querzuvergleichen. Nach dem Vergleich erhalte ich eine Liste, mit allen Updates die mir noch fehlen. Als Bonus prüft es auch noch weitere, mögliche Sicherheitslücken, wie Passwörter ohne Ablaufdatum u.ä.:

Doch beim Versuch meine Server zu prüfen habe ich den Fehler erhalten, dass eine Prüfung nicht möglich sei, weil die Windows Firewall blocken würde. Doch ganz ausschalten war für mich auch nicht wirklich eine Option, weshalb ich mich auf die Suche nach den verwendeten Ports gemacht habe. Fündig wurde ich schlussendlich bei Microsoft Technet:

TCP 135
TCP 139
TCP 445
UDP 137
UDP 138

Also habe ich bei der Windows-Firewall auf den Servern eine Ausnahme zugefügt:

Das selbe natürlich nochmals für UDP und schon können die Server geprüft werden

Also habe ich ein System von Hand aufgesetzt und darauf Cobbler samt Webinterface und TFTP installiert:

zypper ar http://download.opensuse.org/distribution/11.4/repo/oss/ oss
zypper ar http://download.opensuse.org/update/11.4/ updates
zypper ar http://download.opensuse.org/repositories/systemsmanagement/openSUSE_11.4/ cobbler
zypper ref -s
zypper install apache2-mod_python
zypper install cobbler cobbler-web atftp dhcp-server

Da ich während dem Installieren nicht ungebetene Besucher in meinem System will, aktiviere ich die Authentifizierung für das Webinterface:

sed -i 's/module = authn_denyall/module = authn_configfile/' /etc/cobbler/modules.conf

Dann muss ich noch die passende IP einfügen:

IP="192.168.1.10"
sed -i "s/^server: 127.0.0.1/server: $IP/" /etc/cobbler/settings
sed -i "s/^next_server: 127.0.0.1/next_server: $IP/" /etc/cobbler/settings

Da meine Maschinen auch gleich via Netzwerk booten sollen, muss ich den DHCP noch an Cobbler übergeben:

sed -i 's/^manage_dhcp: 0/manage_dhcp: 1/' /etc/cobbler/settings

Nun darf die dhcpd.conf-Datei nicht mehr direkt bearbeitet werden. Dazu gibt es nun das Template unter /etc/cobbler/dhcpd.template:

# ******************************************************************
# Cobbler managed dhcpd.conf file
#
# generated from cobbler dhcp.conf template ($date)
# Do NOT make changes to /etc/dhcpd.conf. Instead, make your changes
# in /etc/cobbler/dhcp.template, as /etc/dhcpd.conf will be
# overwritten.
#
# ******************************************************************

ddns-update-style interim;

allow booting;
allow bootp;

ignore client-updates;
set vendorclass = option vendor-class-identifier;

subnet 192.168.1.0 netmask 255.255.255.0 {
     option routers             192.168.1.1;
     option domain-name-servers 192.168.1.9;
     option subnet-mask         255.255.255.0;
     range dynamic-bootp        192.168.1.150 192.168.1.254;
     filename                   "pxelinux.0";
     default-lease-time         21600;
     max-lease-time             43200;
     next-server                $next_server;
}

#for dhcp_tag in $dhcp_tags.keys():
    ## group could be subnet if your dhcp tags line up with your subnets
    ## or really any valid dhcpd.conf construct ... if you only use the
    ## default dhcp tag in cobbler, the group block can be deleted for a
    ## flat configuration
# group for Cobbler DHCP tag: $dhcp_tag
group {
        #for mac in $dhcp_tags[$dhcp_tag].keys():
            #set iface = $dhcp_tags[$dhcp_tag][$mac]
    host $iface.name {
        hardware ethernet $mac;
        #if $iface.ip_address:
        fixed-address $iface.ip_address;
        #end if
        #if $iface.hostname:
        option host-name "$iface.hostname";
        #end if
        #if $iface.subnet:
        option subnet-mask $iface.subnet;
        #end if
        #if $iface.gateway:
        option routers $iface.gateway;
        #end if
        filename "$iface.filename";
        ## Cobbler defaults to $next_server, but some users
        ## may like to use $iface.system.server for proxied setups
        next-server $next_server;
        ## next-server $iface.next_server;
    }
        #end for
}
#end for

Und damit die Maschinen auch nicht ewig neustarten, wird noch eine letzte Anpassung durchgeführt:

sed -i 's/^pxe_just_once: 0/pxe_just_once: 1/' /etc/cobbler/settings

Nach dem neustarten der Services und einer letzten Einstellung ist die Installation schon abgeschlossen:

insserv apache2
insserv cobblerd
insserv dhcpd
rcapache2 restart
rccobblerd restart
rcatftpd start
insserv atftpd
sed -i 's/^DHCPD_INTERFACE=""/DHCPD_INTERFACE="eth0"/' /etc/sysconfig/dhcpd
cobbler get-loaders
cobbler sync
rm -f /etc/dhcpd.conf
ln -s /etc/dhcp/dhcpd.conf /etc/dhcpd.conf
rcdhcpd restart
rccobblerd restart
cobbler sync

Einloggen kann ich mich nun unter http://192.168.1.10/cobbler_web mit dem Benutzername “cobbler” und dem Passwort “cobbler”.

Nun muss ich openSUSE zu Cobbler zufügen. Dazu lade ich zuerst das Image herunter und mounte es unter /mnt:

wget http://mirror.switch.ch/ftp/mirror/opensuse/distribution/11.4/iso/openSUSE-11.4-DVD-x86_64.iso
mount -o loop -t iso9660 openSUSE-11.4-DVD-x86_64.iso /mnt

Dann kann ich das Image hinzufügen im GUI über den Punkt “Import DVD” und unter “Profile” ein neues Profil anlegen:

Doch bevor das geht, muss ich eine Kickstart-Datei erstellen. Diese wird unter /var/lib/cobbler/kickstart angelegt. Eine solche Datei kann mit autoyast2 generiert werden. Am Schluss würde alles dann etwa so aussehen:

<?xml version="1.0"?>
<!DOCTYPE profile>
<profile xmlns="http://www.suse.com/1.0/yast2ns" xmlns:config="http://www.suse.com/1.0/configns">
  <firewall>
    <enable_firewall config:type="boolean">false</enable_firewall>
    <start_firewall config:type="boolean">false</start_firewall>
  </firewall>
  <general>
    <ask-list config:type="list"/>
    <mode>
      <confirm config:type="boolean">false</confirm>
      <final_reboot config:type="boolean">true</final_reboot>
    </mode>
    <mouse>
      <id>none</id>
    </mouse>
    <proposals config:type="list"/>
    <signature-handling>
      <accept_file_without_checksum config:type="boolean">true</accept_file_without_checksum>
      <accept_non_trusted_gpg_key config:type="boolean">true</accept_non_trusted_gpg_key>
      <accept_unknown_gpg_key config:type="boolean">true</accept_unknown_gpg_key>
      <accept_unsigned_file config:type="boolean">true</accept_unsigned_file>
      <accept_verification_failed config:type="boolean">true</accept_verification_failed>
      <import_gpg_key config:type="boolean">true</import_gpg_key>
    </signature-handling>
  </general>
 <networking>
    <keep_install_network config:type="boolean">true</keep_install_network>
      <dns>
        <dhcp_hostname config:type="boolean">true</dhcp_hostname>
        <dhcp_resolv config:type="boolean">true</dhcp_resolv>
        <hostname>$hostname</hostname>
      </dns>
  </networking>
 <partitioning config:type="list">
        $SNIPPET('snippets_sles/partitioning_default_lvm_sles11')
  </partitioning>
  <software>
        $SNIPPET('snippets_sles/packages_os11')
  </software>
  <timezone>
    <hwclock>UTC</hwclock>
    <timezone>Europe/Zurich</timezone>
  </timezone>
  <users config:type="list">
    <user>
      <encrypted config:type="boolean">true</encrypted>
      <fullname>root</fullname>
      <gid>0</gid>
      <home>/root</home>
      <password_settings>
        <expire></expire>
        <flag></flag>
        <inact></inact>
        <max></max>
        <min></min>
        <warn></warn>
      </password_settings>
      <shell>/bin/bash</shell>
      <uid>0</uid>
      <user_password>$rootpw</user_password>
      <username>root</username>
    </user>
  </users>
  <report>
    <errors>
      <log config:type="boolean">true</log>
      <show config:type="boolean">true</show>
      <timeout config:type="integer">0</timeout>
    </errors>
    <messages>
      <log config:type="boolean">true</log>
      <show config:type="boolean">true</show>
      <timeout config:type="integer">0</timeout>
    </messages>
    <warnings>
      <log config:type="boolean">true</log>
      <show config:type="boolean">true</show>
      <timeout config:type="integer">0</timeout>
    </warnings>
    <yesno_messages>
      <log config:type="boolean">true</log>
      <show config:type="boolean">true</show>
      <timeout config:type="integer">0</timeout>
    </yesno_messages>
  </report>
  <runlevel>
    <default>5</default>
      <service>
        <service_name>sshd</service_name>
        <service_start>3 5</service_start>
        <service_status>enable</service_status>
      </service>
  </runlevel>
  <scripts>
    <post-scripts config:type="list">
      <script>
        <debug config:type="boolean">false</debug>
        <feedback config:type="boolean">false</feedback>
        <feedback_type></feedback_type>
        <filename>post_install</filename>
        <interpreter>shell</interpreter>
        <location><![CDATA[]]></location>
        <network_needed config:type="boolean">true</network_needed>
        <notification>Bitte warten ...</notification>
        <source><![CDATA[/etc/init.d/sshd restart
echo 'search encodingit.ch' >> /etc/resolv.conf
chkconfig sshd on
zypper update -y
zypper dist-upgrade -y
cd /root
mkdir --mode=700 .ssh
cat >> .ssh/authorized_keys << "PUBLIC_KEY"
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC/tGYAdCxqFs8xuryisenGmk4ChEutd3Xi7WfMZsafMyGrvtBBFWUInKeF7G3GE85AxP4G4wOdn2Au3k23jSpfvbP5O/NIEMNizlzMFChu7NDC57NwMm/n+/Y6HMgHZs+LVavKrVP9MUMfif3+odOUYVxK+8BwP8So1K21UJcIgYhd48Fqw9aBYd+jXvg/QFAnXGCIARNsn51kkWYci9LuoApVg0ktJjnHIvxgs75hZsmiXH/VqU/MCv90oe0OBN1C4vABN5XIPjzOZ0HX8MQBITAdujjWqdqzictkz5vk6O0QWDVxzsxz4wgJgnF7fEGxd7t/8mInzEqMbJe4C/iJ root@cobbler
PUBLIC_KEY
chmod 600 .ssh/authorized_keys]]></source>
      </script>
    </post-scripts>
  </scripts>
</profile>

ACHTUNG: Wer wie ich kein DNS im Netzwerk hat, der muss unter dem Punkt “Distro” bei “Kernel Options” den Hostnamen von Cobbler durch die IP ersetzen, damit alles klappt.

Damit auch alles problemlos durchläuft, müssen noch ein paar Snippets eingefügt werden unter /var/lib/cobbler/snippets/snippets_sles. So partitioning_default_lvm_sles11:

# requires: ksmeta Swap : (optional) containing the size of swap in megabytes
    <drive>
      <initialize config:type="boolean">true</initialize>
      <partitions config:type="list">
        <partition>
          <create config:type="boolean">true</create>
          <crypt_fs config:type="boolean">false</crypt_fs>
          <filesystem config:type="symbol">ext3</filesystem>
          <format config:type="boolean">true</format>
          <loop_fs config:type="boolean">false</loop_fs>
          <mount>/boot</mount>
          <mountby config:type="symbol">device</mountby>
          <partition_id config:type="integer">131</partition_id>
          <partition_nr config:type="integer">1</partition_nr>
          <resize config:type="boolean">false</resize>
          <size>500M</size>
        </partition>
        <partition>
          <create config:type="boolean">true</create>
          <lvm_group>vg00</lvm_group>
          <mountby config:type="symbol">device</mountby>
          <partition_id config:type="integer">142</partition_id>
          <partition_nr config:type="integer">2</partition_nr>
          <resize config:type="boolean">false</resize>
          <size>max</size>
        </partition>
      </partitions>
      <pesize></pesize>
      <type config:type="symbol">CT_DISK</type>
      <use>all</use>
    </drive>
    <drive>
      <device>/dev/vg00</device>
      <initialize config:type="boolean">true</initialize>
      <partitions config:type="list">
        <partition>
          <create config:type="boolean">true</create>
          <crypt_fs config:type="boolean">false</crypt_fs>
          <filesystem config:type="symbol">swap</filesystem>
          <format config:type="boolean">true</format>
          <loop_fs config:type="boolean">false</loop_fs>
          <lv_name>lv_swap</lv_name>
          <mount>swap</mount>
          <mountby config:type="symbol">device</mountby>
          <partition_id config:type="integer">130</partition_id>
          <resize config:type="boolean">false</resize>
#if $getVar("Swap","") != ""
          <size>${Swap}M</size>
#else
          <size>2048M</size>
#end if
        </partition>
        <partition>
          <create config:type="boolean">true</create>
          <crypt_fs config:type="boolean">false</crypt_fs>
          <filesystem config:type="symbol">ext3</filesystem>
          <format config:type="boolean">true</format>
          <loop_fs config:type="boolean">false</loop_fs>
          <lv_name>lv_root</lv_name>
          <mount>/</mount>
          <mountby config:type="symbol">device</mountby>
          <partition_id config:type="integer">131</partition_id>
          <resize config:type="boolean">false</resize>
          <size>max</size>
        </partition>
      </partitions>
      <pesize>4M</pesize>
      <type config:type="symbol">CT_LVM</type>
      <use>all</use>
    </drive>

Und auch noch packages_os11:

<patterns config:type="list">
      <pattern>base</pattern>
      <pattern>apparmor</pattern>
      <pattern>gnome</pattern>
      <pattern>file_server</pattern>
      <pattern>x11</pattern>
    </patterns>
    <packages  config:type="list">
      <package>nss_ldap</package>
      <package>pam_ldap</package>
## required for kdump
      <package>kexec-tools</package>
      <package>kdump</package>
    </packages>

Nun kann ich alle Systeme erfassen und zufügen. Da dies mehrere sind, habe ich das ganze über die Konsole gemacht:

hostname=Node1
mac=00:14:4F:20:03:08
ip=192.168.1.21
cobbler system edit --name=$hostname --hostname=$hostname.encodingit.ch --netboot-enable=true --dhcp-tag=$hostname --dns-name=$hostname --ip-address=$ip --mac-address=$mac

Zum Glück starten alle Maschinen direkt ab Netzwerk, wodurch ich die Maschinen nur via iLO neustarten musste. Dazu wiederrum habe ich das folgende Script mit expect geschrieben, wo ich nur noch den Hostnamen oder die IP vom iLO übergeben muss:

#!/usr/bin/expect
#
# Version 1.0
# by Patrick Schmid
#
spawn ssh root@[lindex $argv 0]

expect "Password:" {send "password\r"}

expect "> " {send "reset /SYS -script\r"}

expect {
        "Performing" {puts stdout "\nDone"}
  default {puts stdout "\nError"}
}

Doch vorher noch das System synchronisieren:

cobbler sync

Nach etwa 20 Minuten sind alle Systeme installiert und konfiguriert. Voilà

Vielen Dank an Gavin und Uwe für die Hilfe!

Das könnte dich auch interessieren:

1. OpenSUSE mit ASP.NET-Unterstützung Für einen Kunden habe ich letzthin ein OpenSUSE installiert. Neben...
2. Dynamic Host Configuration Protocol Ein anderer Bestandteil von LPIC 201 ist DHCP. Doch bevor...

Unter Debian und Ubuntu heisst das benötigte Paket libapache-mod-security:

apt-get install libapache-mod-security -y

Nach dem Installieren aus den Paketquellen wird eine Datei unter /etc/apache2/conf.d/modsecurity2.conf angelegt und mit folgendem Inhalt ergänzt:

<ifmodule mod_security2.c>
Include conf.d/modsecurity/*.conf
</ifmodule>

Danach werden die nötigen Ordner erstellt und verlinkt:

sudo mkdir /var/log/apache2/mod_security
sudo ln -s /var/log/apache2/mod_security/ /etc/apache2/logs

Und die aktuellsten Regeln heruntergeladen:

sudo mkdir /etc/apache2/conf.d/modsecurity
cd /etc/apache2/conf.d/modsecurity
sudo wget http://www.modsecurity.org/download/modsecurity-core-rules_2.5-1.6.1.tar.gz
sudo tar xzvf modsecurity-core-rules_2.5-1.6.1.tar.gz
rm -f CHANGELOG LICENSE README modsecurity-core-rules_2.5-1.6.1.tar.gz

Nun noch das Modul aktivieren und Apache neustarten:

sudo a2enmod mod-security
sudo /etc/init.d/apache2 restart

Und von nun an wird der Apache durch Mod_Security geschützt.
Prüfen kann man das ganz einfach! Es muss eine Datei erstellt werden, mit folgendem Inhalt:

<?
        $secret_file = $_GET['secret_file'];
        include ($secret_file);
?>

Nun ruft man die Datei auf unter http://localhost/index.php?secret_file=/etc/passwd. Erhält man anstelle der /etc/passwd Datei die folgende Ausgabe, so arbeitet mod_security richtig:

Method Not Implemented
GET to /index.php not supported.

Doch Vorsicht: mod_security ist nicht überall geeignet. So hat zum Beispiel auch mein Hoster das eingesetzt, und musste es für meinen Blog deaktivieren, dass ich all die Code-Schnipsel posten kann

Wer von euch hatte denn schon mal wirkliche Angriffe auf seinem Webserver? Konntet ihr standhalten oder seid ihr eingebrochen? Und in welcher Art lief der Angriff ab?

Das könnte dich auch interessieren:

1. Mehr Sicherheit durch OpenVPN Sicherheit wird ein immer wichtigeres Thema in der IT. Klar...
2. OpenSUSE mit ASP.NET-Unterstützung Für einen Kunden habe ich letzthin ein OpenSUSE installiert. Neben...