Nun wollen die anderen ja aber nicht immer ganz so, wie der Admin will, und deshalb muss ich auf dem neuen Ubuntu 10.10 maverick-Server natürlich Joomla (ebenfalls Krampf) supporten. Und in Ubuntu 10.10 ist PHP 5.3 an Bord.

Nun kursieren im Internet die kuriosesten Lösungen. Zum Beispiel könnte man PHP 5.2 selber kompilieren oder einfach aus den alten Repositories installieren, je nach gusto parallel zur neuen 5.3er-Version oder alleine. Beides möchte man so einfach eigentlich nicht. Ersteres könnte irgendwann die Selbstmordrate in der IT-Abteilung enorm steigern, letzteres rollt jedem sicherheitsbewussten BOFH die Fußnägel auf den Rücken.

Zum Glück hatte ich dank des Schneechaos bei der Bahn genügend Zeit, über die Problematik nachzudenken. Und kam auch tatsächlich zu einer Lösung,die ich persönlich für zwar nicht unbedingt resourcenschonend, aber sehr sauber halte: eine chroot-Umgebung mit Ubuntu karmic, darin ein Apache mit mod-php5 in der korrekten Uralt-Version. Und den dann nach außen geproxied.

Klingt kompliziert, ist aber eigentlich ganz einfach.

1. Zunächst installieren wir ein minimales Ubuntu karmic in /opt/karmic-chroot. Debian bzw. Ubuntu geben uns dafür alle nötigen Tools an die Hand. Gleichzeitig installieren wir die nötigen Webserver-Pakete mit:

   apt-get install debootstrap
   mkdir /opt/karmic-chroot<
   debootstrap --include=apache2,libapache2-mod-php5,php5-mysql karmic /opt/karmic-chroot

2. Eine kleine Stoplerfalle: Nun muss der DNS-Resolver so konfiguriert werden, dass auch Prozesse innerhalb der chroot-Umgebung Hostnamen auflösen können.

   cp /etc/resolv.conf /opt/karmic-chroot/etc

3. Nun muss der eingesperrte Apache an einen anderen Port gebunden werden als der öffentliche Server, außerdem lassen wir ihn (aus Sicherheits- und Übersichtlichkeitsgründen) nur auf dem lokalen Interface lauschen. Dazu msus die Datei /opt/karmic-chroot/etc/apache2/ports.conf editiert werden und ihr Inhalt durch diese Zeilen ersetzt werden:

   NameVirtualHost 127.0.0.1:8081
   Listen 127.0.0.1:8081

4. Als nächstes wird die VirtualHost-Konfiguration aus dem öffentlichen Webserver kopiert oder neu angelegt. Evtl. reicht auch die Standardkonfiguration, das hängt vom Geschmack und der schon vorhandenen Umgebung ab. Bei mir ist bereits ein VHost für Joomla! vorhanden, der die Seiten aus /srv/www/VHOST ausliefert. AUßerdem wird hier das mod_rewrite-Modul im chroot aktiviert:

   cp /etc/apache2/sites-available/VHOST /opt/karmic-chroot/etc/apache2/sites-available/default
   ln -s /etc/apache2/mods-available/rewrite.load /opt/karmic-chroot/etc/apache2/mods-enabled

5. Die Datei /opt/karmic-chroot/etc/apache2/sites-available/default wird nun so editiert, dass sie zum neuen Webserver-Setup passt. Das hängt wieder vom eigenen Setup ab, wichtig ist, dass die VirtualHost-Definition selber wie folgt lautet:

   <VirtualHost *:8081>

6. Das Web-Root wird in das chroot kopiert. Bei mir liegt es in /srv/www/VHOST:

   mkdir -p /opt/karmic-chroot/srv/www
   mv /srv/www/VHOST /opt/karmic-chroot/srv/www
   ln -s /opt/karmic-chroot/srv/www/VHOSTe /srv/www

   Die letzte Zeile erstellt einen symbolischen Link im alten Pfad, damit die Kollegen aus der Web-Abteilung nicht ganz so verwirrt sind …

7. Nun geht es an den öffentlichen Webserver. Die Proxy-Module werden mit

   a2enmod proxy proxy_http

   aktiviert und dann die Konfiguration des alten VirtualHosts durch die Proxy-Konfiguration ersetzt. Der Host bekommt keine Pfad-Konfiguration mehr, die Kern-Direktiven sehen dann so aus:

   ProxyRequests Off
   
   <Proxy *>
    Order deny,allow
    Allow from all
   </Proxy>
   
   ProxyPass / http://127.0.0.1:8081/
   ProxyPassReverse / http://127.0.0.1:8081/
   ProxyPreserveHost On

   Diese Direktiven leiten alle Anfragen an den eingesperrten Apache weiter. Besonders wichtig ist die letzte Zeile: Joomla wird die Basis aller internen Links durch die Adresse des lokalen Webservers ersetzen, wenn diese Zeile fehlt. Das funktioniert natürlich nicht, da der interne Server ja an localhost gebunden ist. Mit der Direktive ProxyPreserveHost setzt der Apache den Host-Header korrekt ein, so dass Joomla auch korrekte Links baut.

8. Nun sollten wir so weit sein, den Webserver im chroot starten und den öffentlichen neu starten zu können:

   chroot /opt/karmic-chroot /usr/sbin/apache2ctl start
   apache2ctl restart

9. Hat man sich von der Funktionsfähigkeit überzeugt, muss noch dafür gesorgt werden, dass der interne Apache auch beim Booten des Systems gestartet wird. Der Einfachheit halber bedienen wir uns hier des crons und fügen in /etc/crontab die Zeile

   @reboot root /usr/sbin/chroot /opt/karmic-chroot /usr/sbin/apache2ctl start

   ein.

Das war’s! Selbst die oft gefundenen Lösungen für das Link-Problem, bei denen meistens kuriose Patches oder Plugins eine Rolle spielen, ist durch die ProxyPreserverHost-Direktive gelöst.

Bleibt also nur noch zu sagen: Viel Erfolg!

Nachtrag

Einige Joomla-Module machten dann gerade noch Stress wegen des MySQL-Sockets. Klar, Joomla selber benutzt den TCP-Socket, aber einzelne Module müssen ihr eigenes Ding drehen. Ich möchte jetzt hier keine Namen nennen, aber dieses SchoolJoomla hat eindeutig den Platz 1 der Krampf-Rangliste erreicht …

Um das Problem nun zu lösen, müssen wir mysqld seinen Socket im chroot anlegen lassen. Dafür ersetzen wir in der Datei /etc/mysql/my.cnf alle Vorkommen des Pfades /var/run/mysqld/mysqld.sock durch /opt/karmic-chroot/var/run/mysqld/mysqld.sock. mysqld wird das Verzeichnis beim Starten anlegen.

Allerdings macht es uns Ubuntu dank Novell’s AppArmor nicht ganz so eifnach, so dass wir das Erstellen des Sockets an dieser Stelle noch erlauben müssen. In /etc/apparmor.d/local/usr.sbin.mysqld werden folgende Zeilen eingefügt:

/opt/karmic-chroot/var/run/mysqld/mysqld.pid w,
/opt/karmic-chroot/var/run/mysqld/mysqld.sock w,

und dann das Kommentar-Zeichen vor folgender Zeile in /etc/apparmor.d/usr.sbin.mysqld entfernt:

#include <local/usr.sbin.mysqld>

Zuletzt wird der AppArmor-Dienst und MySQL neu gestartet:

/etc/init.d/apparmor restart
/etc/init.d/mysql restart

Damit auch Prozesse in der Host-Umgebung, die sich nicht für die Konfiguration in der my.cnf interessieren, den Socket verwenden können, müssen wir noch dafür sorgen, dass wir den Socket in seiner Original-Location finden können. Weil /var/run jedoch bei jedem Booten geleert wird bzw. in einem tmpfs liegt, müssen wir /etc/rc.local wie folgt erweitern:

rm -rf /var/run/mysqld
ln -s /opt/karmic-chroot/var/run/mysqld /var/run/mysqld

und die Datei ausführbar machen:

chmod u+x /etc/rc.local

Damit sollten nun alle MySQL-Clients glücklich sein …

Nun aber ans Eingemachte:

Leider muss ich einräumen, bei beiden Prüfungen schlechter als erwartet abgeschnitten zu haben, und auch schlechter als im letzten Jahr. DIe Ergebnisse sind leider nur durchschnittlich, was zum größten Teil wohl daran liegt, das sich meine Vorbereitung im Wesentlichen auf 30-60 Minuten am Vorabend im Hostel beschränkte .

Prüfung 201

Erreichte Punkte: 630/800

Prüfung 202

Erreichte Punkte: 640/800

Aber falls es jemanden beruhight, den man-Befehl kann ich bedienen …

Das Modul erlaubt es, das TUN/TAP-Device des Linux-Kernels als Objekt in Python zu verwenden. Dazu operiert es direkt per Filehandle auf das Kontrolldevice in /dev/net/tun und stellt Methoden zum Lesen und Schreiben auf das Interface bereit. Außerdem kann es einfache ifconfig-Kommandos für das Tun- bzw. TAP-Device ausführen, so dass das Interface sogar aus dem Script heraus konfiguriert werden kann.

Hier ein kleines Beispiel, das die aus dem Device ausgehenden Pakete bzw. Frams ausgibt (unspektakulär, aber es zeigt die einfache Verwendung des Moduls):

from pytap import TapDevice

dev = TapDevice()
dev.ifconfig(address = "10.0.0.1",
             netmask = "255.255.255.0"
            )

while 1:
    data = dev.read()
    print data

Hier ein paar Links:

• Launchpad-Homepage
• PyPI-Eintrag (Python Package Index)
• PPA mit Debian-Paket (Launchpad Personal Package Archive)

Das Modul ist die Voraussetzung eines größeren Projektes, von dem ich demnächst berichten werde.

Hallo Herr George,

soeben ging eine Beschwerde bei uns ein, dass von Ihrem 213.160.76.xxx Spam versendet wird.
Bitte überprüfen Sie dies und ändern ggfs. Ihre Zugangsdaten.

Oha, denke ich mir, da will ich doch mal nachsehen. Welcher Server ist denn das …

Und da bleibt mir doch die Schnitzeleinschuböffnung offen stehen – die Kiste wurde gestern Abend vom Provider eingerichtet; ich selber hatte noch nicht einmal die E-Mail mit den Zugangsdaten geöffnet.

Ein Log-Audit zeigte dann auch keine Aktivitäten auf dem System, auch ein MTA war nicht vorinstalliert (hatte ich auch nicht bestellt …). Bleiben also vier Möglichkeiten:

• Die Adresse wurde doppelt vergeben
• Da hat intern jemand Schindluder getrieben
• Da hat jemand was falsch gemacht …
• Da stimmt was nicht.

Ich habe den Provider nun mal unter Berücksichtigung dieser Punkte auf eine interne Nachforschung angesetzt …

• Firewalling eines LANs hinter einem Linux-Gateway an DSL
• Einstufung des Vertrauens gegen einzelne Hosts im LAN
• Dynamische Zugangskontrolle zum Internet über NAT, einen transparenten Proxy und ein Webinterface zur Authentifikation

Als Grundlage für das System dient PC-Hardware älteren Datums (500 MHz Pentium-Prozessor, 256 MB RAM, 14 GB IDE-Harddisk). Das Grundsystem ist ein Debian GNU/Linux Squeeze (wegen veralteter Software in lenny).

Zur Zeit ist das System bzgl. der Firewall-Zonen noch recht statisch. Grundlegend unterscheidet das Setup zwischen 4 Zonen:

Die Firewallregeln baut die Shorewall, ein Perl-Skript, das mit Hilfe von Tabellen iptables-Regeln baut und pflegbar macht. Die Zonen bedeuten:

LAN

In der LAN-Zone befindet sich das komplette Netzwerk hinter dem lokalen Ethernet-Interface. Es wird, wie üblich, von der Firewall restriktiv behandelt. Hosts im LAN haben keinen Zugang zum Internet, sofern sie nciht zu einer der eingebetteten Zonen gehören.

AUTHentifiziert

Authentifizierte Hosts sind Hosts, die sich erfolgreich am Webinterface angemeldet haben. Ein beliebiger Client im LAN wird per DNAT im Webbrowser auf die Loginmaske der FIrewall weitergeleitet. Dort kann sich der Benutzer einloggen, wodurch sein Host dynamisch zur AUTH-Zone hinzugefügt wird. Die Systeme haben dann eine Route ins Internet, HTTP wird jedoch durch einen transparenten Proxy geleitet.

PRIVilegiert

Privilegierte Systeme gehören zu einem bestimmten Adressbereich und werden mit einer MAC-Liste gefiltert. Prinzipiell bietet diese Maßnahme natürlich keine verlässliche Sicherheit, in usnerem Fall ist dies aber ausreichend. Privilegierte Hosts haben eine direkte Internetverbindung ohne Proxy und dürfen darüberhinaus die Administrationsoberfläche des Webinterfaces aufrufen. Die Adressen der privilegierten Systeme werden von einem ISC DHCPd verteilt.

Um der Shorewall die Arbeit mit dynamischen Zonen im NAT beizubringen, wird mindestens Version 4.4 benötigt. Außerdem verlässt sich diese Version auf die xtables-addons, welche noch nicht in der Kerneldistribution enthalten sind. In Debian squeeze können die benötigten Module jedoch mit module-assistant gebaut werden.

Mit Hilfe einiger kreativer NAT-Regeln regelt die Shorewall dann die Routen aus den verschiedenen Zonen ins Internet, zum Proxy oder zum Login:

NONAT		priv	all			all
NONAT		auth	all			tcp	443
NONAT		auth	fw:192.168.2.1		tcp	80
DNAT		auth	fw:192.168.2.1:3128	tcp	80
DNAT		lan	fw:192.168.2.1		tcp	80,443

Wichtig ist hier die kaskadierende Reihenfolge, die die Restriktionen durch DNAT von Zone zu Zone aufhebt. Die Shorewall baut daraus dann NAT-Regeln in iptables:

Shorewall 4.4.2 NAT Table at blackhawk - Do 8. Okt 21:25:08 CEST 2009

Counters reset Do 8. Okt 20:28:38 CEST 2009

Chain PREROUTING (policy ACCEPT 152 packets, 13678 bytes)
 pkts bytes target     prot opt in     out     source               destination
 2767  230K dnat       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain POSTROUTING (policy ACCEPT 173 packets, 12419 bytes)
 pkts bytes target     prot opt in     out     source               destination
 623 39249 ppp0_masq  all  --  *      ppp0    0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 164 packets, 12059 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain auth_dnat (1 references)
 pkts bytes target     prot opt in     out     source               destination
 0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:443
 0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:443
 0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:443
 0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:443
 0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:443
 0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            192.168.2.1         tcp dpt:80
 0     0 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 to:192.168.2.1:3128 

Chain dnat (1 references)
 pkts bytes target     prot opt in     out     source               destination
 2491  209K priv_dnat  all  --  eth0   *       0.0.0.0/0            0.0.0.0/0           source IP range 192.168.2.200-192.168.2.250
 0     0 RETURN     all  --  eth0   *       0.0.0.0/0            0.0.0.0/0           source IP range 192.168.2.200-192.168.2.250
 0     0 auth_dnat  all  --  eth0   *       0.0.0.0/0            0.0.0.0/0           match-set auth_eth0 src
 0     0 RETURN     all  --  eth0   *       0.0.0.0/0            0.0.0.0/0           match-set auth_eth0 src
 267 20702 lan_dnat   all  --  eth0   *       0.0.0.0/0            0.0.0.0/0           

Chain lan_dnat (1 references)
 pkts bytes target     prot opt in     out     source               destination
 124  7440 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           multiport dports 80,443 to:192.168.2.1 

Chain ppp0_masq (1 references)
 pkts bytes target     prot opt in     out     source               destination
 469 28140 MASQUERADE  all  --  *      *       192.168.2.0/24       0.0.0.0/0           

Chain priv_dnat (1 references)
 pkts bytes target     prot opt in     out     source               destination
 2491  209K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0
 0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0
 0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0
 0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0
 0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0

In einer MySQL-Datenbank werden Benutzer verwaltet, die sich auf der Firewall einloggen können. Das Webinterface bietet diese Möglichkeit nur Clients aus dem AUTH-Adressbereich an, wenn diese sich noch nicht authentifiziert haben. Nach erfolgtem Login legt das Webinterface einen Session-Eintrag in der Datenbank an, der im Admin-Teil gesteuert werden kann.

Zusätzlich prüft ein von cron aufgerufenens Backend-Script regelmäßig, ob die in der Datenbank hinterlegten Sessions noch aktiv sind (Ping-Probe) und terminiert sie bei Bedarf, indem es die zugehörige IP-Adresse wieder aus der dynamischen AUTH-Zone entfernt und den Datenbankeintrag abschließt.

Das System wird bei Gelegenheit noch ein bisschen aufgeräumt und erweitert, so dass es “benutzbar” wird.

Ein paar Zahlen:

• Arbeitsstunden: 13
• PHP-Code (Webinterface): 580 Zeilen
• iptables-Regeln: ca. 400
• Benötigter Festplattenplatz (vor dem Aufräumen): 1,4 GB

Heute blieb mir dann nur ein Provisorium, da Mainboard, Prozessor und Netzteil den Geist aufgegeben haben.

Alter ausgeschlachteter Server

Provisorium

Netzwerkkarten

Notfallsystem

Festplatten

Nur ein Kommentar dazu: “Will haben!” …

http://royal.pingdom.com/2008/11/14/the-worlds-most-super-designed-data-center-fit-for-a-james-bond-villain/

Nun steht in sämtlichen Dokumentationen zu hdparm ja nicht umsonst, dass man neue Einstellungen doch bitte nicht auf rw-gemountete Geräte schreiben soll, weil es sosnt zu erheblichen Dateisystemschäden kommen könnte. Doch was wäre das Leben ohne Risiko …

Das Resultat war jedenfalls, dass die Systemplatte wegen eines schon länger bekannten Hardwareschadens, den ich aus finanziellen Gründen bisher nicht beheben konnte, sich bem Setzen des DMA-Modus verabschiedete und der Kernel über den Reset locker weiter schrieb. Und plötzlich stand ich da mit einem Server, der mich erst aus der su-Umgebun schmiss und dann auch noch aus der SSH-Session, weil das root-Dateisystem plötzlich leer war und das anscheinend systembedingt ungünstig ist.

Also ab nach Wermelskirchen und die Sache ansehen – das System haut mich nach dem Booten des kernels in eine Shell im initramfs raus, weil das Rootdateisystem nicht gemountet werden kann und Init damit nicht gestartet werden kann. Also schnell mal Damn Small Linux brennen und sämtliche Dateisysteme prüfen. e2fsck meckert zwar erstmal, dass es zu alt sei und die Dateisysteme nicht prüfen könne, ist aber doch noch motiviert genug mir Tausende kaputte Inodes um die Ohren zu schleudern, die ich auch gleich mal alle bereinigen lasse, was bleibt mir auch Anderes übrig. Unnötig zu sagen, dass dabei natürlich ein paar Dateien draufgehen, aber hey, wozu haben wir denn ein ordentliches System .

Und nach dem Reboot zeigte sich dann auch gleich, wo der Haken hängt: Init-Scripte beschwerten sich über fehlende Kommandos wie head, tr und Ähnliches und BIND vermisste seine Binary auch irgendwie. Zm Glück konnte ich das mit einem aptitude reinstall coreutils bind9 reparieren, und nun ist alles wieder in Butter.

Was lernen wir daraus?

• manche Warnungen hat man mit Verstand verfasst, nicht nur zur Benutzerabschreckung
• Mache niemals kritische Sachen wenn du keien Lust hast kilometerweit zu fahren
• Es ist gut, alle wichtigen Daten auf separate Partitionen auszulagern und nicht alles auf eine Root-Partition zu packen. Denn so sind mein Mailspool, die Datenbank und noch einiges Anderes unbeschädigt geblieben und wären es auch, hätte sich das Root-Dateisystem gar nicht mehr retten lassen

Die Entwickler der Shorewall haben da übrigens einen netten Kommentar in ihre Konfigurationsdatei gepackt:

#
# FOR ADMINS THAT REPEATEDLY SHOOT THEMSELVES IN THE FOOT
#
# Normally, when a "shorewall stop" command is issued or an error occurs during
# the execution of another shorewall command, Shorewall puts the firewall into
# a state where only traffic to/from the hosts listed in
# /etc/shorewall/routestopped is accepted.
#
# When performing remote administration on a Shorewall firewall, it is
# therefore recommended that the IP address of the computer being used for
# administration be added to the firewall's /etc/shorewall/routestopped file.
#
# Some administrators have a hard time remembering to do this with the result
# that they get to drive across town in the middle of the night to restart
# a remote firewall (or worse, they have to get someone out of bed to drive
# across town to restart a very remote firewall).
#
# For those administrators, we offer ADMINISABSENTMINDED=Yes. With this
# setting, when the firewall enters the 'stopped' state:

Genau so ist es nämlich

Die Zonen, die isch bisher in einem Netzwerk befanden, nämlich LAN, PPTP-VPN und OpenVPN, sind nun in drei Netze aufgeteilt und alssen sich so firewalltechnisch besser verwalten. Wegen der geringen Sicherheit wird PPTP ab jetzt als “Gast-Netzwerk” behandelt, für Benutzer, die nur vorübergehend und möglichst schnell Zugang zum Netzwerk benötigen (Ferndiagnose per VNC, etc.). Im Gegensatz dazu wird OpenVPN bis auf wenige Ausnahmen genauso behandelt wie das LAN.

Im Diagramm (klicken, um zu vergrößern) werden die grundlegenden Firewallregeln deutlich. Die Pfeile beschreiben, wie nicht näher spezifizierter Traffic behandelt wird (“Policies”). Grüne Pfeile stellen die Policy “ACCEPT” dar, Traffic wird also grundsätzlich erlaubt, rote Pfeile zeigen die Policy “REJECT”, es wird also jede Verbindung abgelehnt. Gepunktete Linien sind Routen durch die Firewall, die VPN-Netze sind natürlich durch die WAN-Zone getunnelt, worauf ich hier aber der Übersichtlichkeit halber verzichtet habe.

Auffallen sollte, dass grundsätzlich kein Traffic auf die Firewall erlaubt ist – der gesamte Zugriff auf das Serversystem wird mit Ausnahmeregeln gesteuert. Ferner ist der Zugriff auf die LAN-Zone sehr restriktiv und die PPTP-Zone darf überhaupt keine Verbindungen ins Netzwerk aufnehmen.

Außerdem dürfen die VPN-Netze nicht durch den Tunnel auf das Internet zugreifen, umd unnötigen Netzwerkoverhead zu vermeiden.

Natürlich ist es nicht Sinn der Sache, die Firewall auf einem Server zu betreiben, da diese normalerweise Netzwerke voneinander trennen soll. Aber es funktioniert auch mit diesem einzelnen DMZ-Host …