Bits, Bytes and my 5 cents » Server

SSH von ESXi absichern

Patrick — Fri, 02 Dec 2011 07:30:18 +0000

Vor kurzem habe ich ja bereits über Syslog geschrieben. Jeder der schon mal einen Server in den weiten des Internets betrieben hat (damit meine ich nicht zu Hause im eigenen Netzwerk), der weiss, wie schnell es geht, bis die ersten Bots und Kiddies mit endlosen Versuchen probieren, das SSH-Passwort zu knacken.
Für Linux-Distributionen wie Ubuntu, Debian, RedHat oder was auch immer gibt es unzählige Tools und Applikationen, welche helfen entweder den SSH-Zugriff zu verstecken, oder aber zu verteidigen.

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:

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

Syslog Server für ESXi

Patrick — Thu, 01 Dec 2011 14:30:10 +0000

Nach dem ich entdeckt hatte, dass der ESX so intelligent ist und seine Logs standardmässig auf einer RAM-Disk speichert, musste natürlich eine andere Lösung her. Kann ja nicht sein, dass die Logs nach einem Ausfall einfach nicht mehr vorhanden sind.
Somit habe ich mich für eine zentrale Logspeicherung mit Syslog entschieden.

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:

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

Vmware Image für ESXi aufbereiten

Patrick — Mon, 05 Sep 2011 13:36:20 +0000

Für eine Analyse gab es diese Woche eine Installation von einem Kunden, welche für weitere Arbeiten in unsere ESX Umgebung eingespielt werden musste.
Noch unwissend, da ich eine solche Arbeit noch nie zuvor ausführen musste, dachte ich mir, ganz so kompliziert kann das ganze doch nicht sein, vmdk ist ja vmdk… Doch schön wärs!

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!

NAT konfigurieren unter ESX(i)

Patrick — Wed, 17 Aug 2011 12:15:15 +0000

NAT ist so eine Sache. Unter Vmware Workstation sehr einfach und sauber gelöst, unter ESX(i) leider gänzlich unbekannt. Eigentlich ist es auf einem Server ja auch gar nicht erwünscht, da jeder Server sowieso seine eigene, fixe IP bekommt, jedoch aber ist bei mir nur der undenkbare Fall eingetreten, dass ich zu Testzwecken eben doch NAT gebrauchen könnte.

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:

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

Die Updates im Griff mit MBSA

Patrick — Thu, 04 Aug 2011 16:00:38 +0000

Vor einiger Zeit mal hatte ich ein Stück Software von Microsoft verwendet, welches mir erlaubt, mit wenigen Klicks herauszufinden, welche Updates auf einem System installiert sind und welche noch nachinstalliert werden sollten. Klar Windows-Update kann das auch, jedoch gibt mir die Software neben den Namen auch gleich einen Link zur Microsoft-Seite, wo ich das entsprechende Update herunterladen kann.
Heute, auf der Suche nach einem Tool, welches mir anzeigt, welche Patches und Updates ich auf meinen Servern noch installieren muss, bin ich wieder über das altbekannte Tool Baseline Security Analyzer von Microsoft gestolpert.

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

Cobbler mit openSUSE

Patrick — Wed, 15 Jun 2011 16:50:48 +0000

Für eine Testumgebung musste ich heute 30 neue Maschinen installieren. Und da ich zu faul war, alles von Hand zu installieren, musste eine andere Lösung her.
Da ich Cobbler, ein System aus dem Hause Red Hat, bereits kenne, war dies mein erster Gedanke – auch wenn es an Vergewaltigung grenzt, schliesslich will ich ja openSUSE 11.4 installieren!

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:




  
    false
    false
  
  
    
    
      false
      true
    
    
      none
    
    
    
      true
      true
      true
      true
      true
      true
    
  
 
    true
      
        true
        true
        $hostname
      
  
 
        $SNIPPET('snippets_sles/partitioning_default_lvm_sles11')
  
  
        $SNIPPET('snippets_sles/packages_os11')
  
  
    UTC
    Europe/Zurich
  
  
    
      true
      root
      0
      /root
      
        
        
        
        
        
        
      
      /bin/bash
      0
      $rootpw
      root
    
  
  
    
      true
      true
      0
    
    
      true
      true
      0
    
    
      true
      true
      0
    
    
      true
      true
      0
    
  
  
    5
      
        sshd
        3 5
        enable

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
    
      true
      
        
          true
          false
          ext3
          true
          false
          /boot
          device
          131
          1
          false
          500M
        
        
          true
          vg00
          device
          142
          2
          false
          max
        
      
      
      CT_DISK
      all
    
    
      /dev/vg00
      true
      
        
          true
          false
          swap
          true
          false
          lv_swap
          swap
          device
          130
          false
#if $getVar("Swap","") != ""
          ${Swap}M
#else
          2048M
#end if
        
        
          true
          false
          ext3
          true
          false
          lv_root
          /
          device
          131
          false
          max
        
      
      4M
      CT_LVM
      all

Und auch noch packages_os11:


      base
      apparmor
      gnome
      file_server
      x11
    
    
      nss_ldap
      pam_ldap
## required for kdump
      kexec-tools
      kdump

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:

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

Mehr Sicherheit durch mod_security

Patrick — Wed, 18 May 2011 08:06:29 +0000

Mod_Security ist eine Software Firewall, welche kontrolliert, welche Eingaben auf einem Apache gemacht und was für Daten übermittelt werden. Diese werden dann mit einer Handvoll Regeln verglichen, wodurch schädliche Abfragen erkannt und geblockt werden.

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:


Include conf.d/modsecurity/*.conf

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:

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:

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

Finde die DVD!

Patrick — Fri, 07 Jan 2011 14:56:58 +0000

Heute habe ich versucht ein paar alten SunFire X4100 neu zu installieren, um darauf meinen eigenen HPC zu erstellen.
Da das ISO aber remote nicht gemountet werden ~~konnte~~ wollte, habe ich es gewagt, eine DVD in das Laufwerk einzulegen – ein grosser Fehler, wie sich gleich herausstellen sollte!

Das Laufwerk war eines von der Sorte, wie man es von der PS3 her kennt, die CD wird nur reingeschoben, bis das Laufwerk sie dann automatisch einzieht – ein klassisches Laufwerk mit Schublade gibt es dabei nicht.

Die DVD habe ich also reingehalten, bis das System sie automatisch eingezogen hatte, so weit so gut.
Doch dummerweise wurde keine DVD erkannt! Also habe ich den Auswurf-Knopf gedrückt, um die DVD wieder zu bekommen.
Doch die Maschine dachte gar nicht daran, mir mein Eigentum wieder auszuspucken. Weder über den Hardware-Knopf zum Auswerfen, noch über das eject-Kommando auf der Konsole – na toll!

Also habe ich kurzerhand schweres Geschütz aufgefahren und den Koffer mit Feinwerkzeug geholt und mich auf die Suche nach meiner verschollenen DVD gemacht.

Zuerst musste das DVD-fressende Monster aus dem Rack befreit werden.

Dann mussten die Disks dran glauben.

Nun die erste Abdeckung lösen, um endliche die passende Schraube zu finden.

Dann die Verkleidung lösen und die restliche Abdeckung entfernen.

Alle Kabel lösen und das Laufwerk hervor graben.

Dann endlich war das Laufwerk in Reichweite.

Bei diesem musste man zum Glück nur den Deckel abschrauben und voilà, da war sie!

Nun alles wieder zusammensetzen und einbauen.
Für meine nächsten Versuch, werde ich sicherlich ein externes Laufwerk verwenden…

FTP Server mit User Restriction

Patrick — Fri, 22 Oct 2010 10:45:03 +0000

Unter Linux gab es während der Informatik Schweizermeisterschaft eine Aufgabe, einen FTP Server zu installieren, über welchen sich ein gegebener Benutzer einloggen kann, und die Dateien im Webordner bearbeiten und ergänzen kann.

Diese Aufgabe lässt sich dabei relativ einfach bewerkstelligen. Als erstes muss man sich für einen der zahlreichen FTP-Server entscheiden. Ich habe mich zuerst an FTPD versucht, konnte diesen jedoch einfach mal so aus dem Kopf nicht konfigurieren, weshalb ich dann auf vsftpd umgestiegen bin.

Dieser wird über die Paketquelle installiert:

1	apt-get install vsftpd

Danach gilt es die Konfigurationsdatei zu suchen. Typisch unter Debian oder auch Ubuntu ist dabei der Ordner /etc/, in welchem ich auch die passende Datei vsftpd.conf gefunden habe.

Doch bevor spezifische Details eingestellt werden können, muss der Benutzer noch erstellt werden.
Dieser besitzt als Homeverzeichnis den Webordner:

1	adduser bmftp --home /var/www

Damit der User nun auch den Webordner verwenden kann, müssen wir diesen noch berechtigen:

1	usermod -a -G www-data bmftp

Nun kann der FTP-Server konfiguriert werden.
Dazu müssen zuerst der lokale Benutzer erlaubt werden:

1	local_enable=YES

Nun könnte man die Aufgabe theoretisch schon abschliessen, jedoch wären die Sicherheitseinstellungen viel zu schwach…

Deshalb beschränken wir noch den Zugriff auf den Benutzer bmftp:

1
2
3

userlist_enable=YES
userlist_deny=NO
userlist_file=/etc/vsftpd.userlist

In der Datei selbst wird einfach den Namen bmftp gelistet:

1	echo "bmftp" > /etc/vsftpd.userlist

Und damit der Benutzer nicht aus seinem für ihn vorgesehenen Verzeichnis verschwinden kann, wird auch das noch eingeschränkt:

1	chroot_local_user=YES

Nun nur noch den Server neustarten und gut ist es:

1	/etc/init.d/vsftpd restart

Die gesamte Konfiguration sollte nun etwa so aussehen:

anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
dirmessage_enable=YES
xferlog_enable=YES
connect_from_port_20=YES
xferlog_file=/var/log/vsftpd.log
xferlog_std_format=YES
chroot_local_user=YES
chroot_list_enable=NO
listen=YES
 
pam_service_name=vsftpd
userlist_enable=YES
userlist_deny=NO
userlist_file=/etc/vsftpd/userlist
tcp_wrappers=YES

Und schon ist ein FTP-Server installiert und die Teilaufgabe gelöst!

OpenVZ unter Debian

Patrick — Tue, 06 Jul 2010 08:20:17 +0000

Neben verbreiteten Virtualisierungslösungen wie ESX, Xen und KVM existiert noch eine weitere, weniger verbreitete Methode:

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:

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:

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:

#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:

vzlist -a

Weitere Informationen bekommt man durch die Manpages:

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.