Donnerstag, 25. Oktober 2012

Den Vorzug geben

Manchmal ist ein kleines Detail wichtiger als man denkt. So geht es zB auch bei der Wahl der passenden Software. Für was mich sehr viele meiner Freunde und Kollegen hassen ist, ich finde man sollte die Software immer so wählen das es zu dem Szenario in der sie laufen soll auch passt. So halte ich es zB für alle Software, auch für das Betriebsystem.

Aber was ist das Entscheidungskriterium, wie wählt man eine Software. Da ich nicht sagen kann das ich hier die alleinige Weissheit besitze, stelle ich meine Ideen und Beweggründe kurz vor.

  • Einsatzsenario: Nameserver
    Ich bin ein grosser Freund von Statistik, daher ist mein bevorzugtes System hier FreeBSD, da es in allen Tests im zusammenspiel mit Bind die besten Ergebnisse liefert. Warum Bind? Die ISC welche die Entwickler hinter Bind sind sind sehr schnell, Bugs werden relativ schnell erkannt und gefixt. Grund für die schnelle Erkennung ist auch das ein paar der grössten registrys auf Bind setzen und somit Millionen von Testdomains vorliegen.
    Der Nutzung von Debian muss ich nach den geschehnissen der letzten Wochen eine klare Absage erteilen, Das letzte Sicherheitsupdate hatte eine echt lange Wartezeit
    Ubuntu: 1 Tag nach ISC Release
    Centos: 2 Tage nach ISC Release (Redhat 1 Tag)
    Debian: 14 Tage (!!!)
    ein echtes NOGO
    Ich muss auch noch eine Lanze für PowerDNS brechen. Ich mag es einfach. Vielleicht auch weil ich es angenehmer finde eine Datenbank zu manipulieren als ein Textfile. Die Grenzen sind bekannt. Mit PowerDNS schafft man gut und gerne 50.000 Verbindungen pro Sekunde bevor es Bergab geht, mit Bind sind hier gut und gerne 350.000 drin. Aber dank replikation kann man slaves einfach bedienen und muss dort nicht zuerst das Zonefile anlegen. Auch kann man ganz ohne Notifications auskommen. Positive ist auch das man DNSSEC nutzen kann und PowerDNS on the fly beim ausliefern signieren kann.

  • Einsatzszenario: Webserver
    Hier würde ich mich eindeutig für Ubuntu oder Centos aussprechen. Dies vorallem wegen dem Langzeitsupport. Ein Ubuntu LTS bietet Security Patches für ganze 5 Jahre, Centos sogar 9 Jahre. Somit kann ich mich drauf verlassen das ich Security Updates bekomme ohne den Server alle 1 bis 2 Jahre komplett updaten zu müssen. Auch kann ich für beide Varianten Kommerziellen Support bekommen wenn ich ihn benötigen sollte. Im Falle Centos sogar von zwei Seiten, durch den Switch zu RedHat oder Oracle.
    Der Webserver sollte wohl Apache sein. Der Dinosaurier unter den Systemen. Wobei hier auch das Szenario relevant ist, da Apache bei vielen kleinen und statischen Seiten eine echte Resourcenschleuder ist und man sollte überdenken ob Nginx oder Lighthttpd hier nicht besser und schneller sind.

  • Einsatzszenario Datenbank
    das OS ist in meinen Augen ganz klar ein Centos oder Redhat. Die Datenbank ist eine einzelne Anwendung und ein sicheres Centos System darunter das 9 Jahre Support hat scheint die beste Wahl, wer erneuert schon seine Datenbank alle paar Jahre oder kann sich eine Downtime leisten um das Betriebsystem zu updaten.
    Als MySQL meiner Wahl nehme ich MariaDB. Die Community um Monty ist recht gross und engagiert, ausserdme bieten sie für die meisten grossen Systeme eigene Repos an, so das man updates Zeitnah vom MariaDB selber bekommt. Also haben wir 9 Jahre Support und dann immer wieder die neusten Updates von MariaDB selbst. Eine optimale Mischung finde ich.

Montag, 22. Oktober 2012

Sicherheit

Irgendwie hat es sich in den letzten Wochen und Monaten so ergeben das ich vermehrt über das Thema Sicherheit, genauer IT Sicherheit nachdenke.

Also, was ist diese Sicherheit eigentlich? Vielleicht eine Definition die ich für mich gefunden habe

  • IT Sicherheit ist der Schutz der Unternehmens relevanten Daten, gemessen an Ihrem Risikofaktor.


Vielleicht eine relativ einfache Definition, aber in meinen Augen spiegelt sie alles wieder auf das es wirklich ankommt.

Ein grosses Problem, gerade wenn ein Unternehmen aus mehreren Abteilungen besteht, ist das jede Person Daten auf die eine oder eine andere Art besitzt und verwaltet und diese in in einem eigenem Licht was die Sicherheit dieser Daten betrifft behandelt. So ist das Passwort welches an dem Monitor in einem kleinen Büro hängt für diese Person genau richtig. Es ist wahrscheinlich ein Passwort das man mehr als einmal am Tag verwendet und für das es umständlich wäre es in einem Tresor oder einem sicheren Passwort Server zu verwahren.

Das schlimme ist, wenn ich drüber nachdenke stimmt dies Teilweise sogar. Wir müssen davon ausgehen das jede andere Person in diesem Raum und dieser Abteilung dieses Passwort bereits kennt, oder einen ähnlichen Postfix am Monitor kleben hat. Hier sollte also keine Gefahr drohen. Und wenn es eine böse fremde Person, durch die Eingangshalle bis in dieses Büro, an diesen Monitor geschafft hat, dann müssen wir ehrlich sein, dann haben alle Sicherheitsmechanismen bereits versagt.

Erster Schritt aller (sicherheits-) Bemühungen sollte es daher sein seine Daten und Dienste und wie einzelne Personen damit Umgehen zu kennen und einen "Regelgerechten Umgang" zu definieren. Diese Definition ist dann eine Security Policy. Beim kochen einer solchen Policy ist es wie bei allen anderen Gerichten auch, die genaue Würze muss gefunden werden und eventuell das Rezept überarbeitet bis es schmeckt, den meisten zumindest.

In einem reinen IT Unternehmen sind die Ansätze einer Policy natürlich weit gefächert, da es unter Umständen eine Vielzahl an Systemen gibt die über viele Abteilungen verteilt sind. Was in meinen Augen hilft ist

  1. Entscheiden Sie sich für ein einheitliches Betriebssystem das einem gewissen Mass an Sicherheit mit sich bringt. Lassen Sie sich hier von den Adminsitratoren und Entwicklern beraten, denn diese sind es welche das System warten müssen, und man kümmert sich wohl am liebsten um etwas das man nicht einfach so aufs Auge gedrückt bekommen hat. Entscheidend sollte sein das es weit verbreitete Software ist, welche von einem Unternehmen oder einer recht grossen Community getragen wird, dann kann man sehr sicher sein das es Zeitnahe Bugfixes zu aktuellen Problemen gibt.

  2. Reden Sie mit den Abteilungen. Nehmen Sie die Abteilungsleiter beiseite und lassen Sie sie Teil des Processes sein. Fragen Sie nach den Daten die der Abteilungsleiter für Schützenswert hält.

  3. Machen Sie Self Assesments. Also hinterfragen Sie Ihre Sicherheit in einem festgelegten Intervall. Testen Sie Ihr System, dafür gibt es unzählige Software, und geben Sie die gewonnen Informationen an die betreffenden Abteilungen weiter.


Abschliessend noch ein paar Links die helfen könnten:

  1. heise Security Online eine gute Quelle für Sicherheitsthemen

  2. Ubuntu Security aktuelle Bugfixes von Ubuntu

  3. OpenVas ein Security Scanner


 

Montag, 15. Oktober 2012

MySQL/MariaDB Replikation

Heute beschäftigen wir uns kurz mal mit dem Thema "MySQL Replikation".
Kurz?
Ja! Lange dauert das ja nicht :-)

Nehmen wir mal die Ausgangssituation
Einen Debian Server MASTER mit MySQL
Auf die Installation von Debian bzw MySQL muss man wohl nicht mehr im Detail eingehen, diese ist bei Debian ja so schön automatisiert das nichts schief gehen sollte, und
Einen Debian Server SLAVE mit MySQL
Wenn man die beiden Server zufällig in einem Rack haben sollte, so bevorzuge ich es an eth1 einfach ein Crosskabel anzuschliessen (Anmerkung!: Ein Crosskabel braucht man eigentlich nicht mehr, neue Neztwerkkarten sind so toll das sie dies alleine tun können).
Somit konfigurieren wir uns auf beiden Servern ein Netz, zB
auto eth1
iface eth1 inet static
        address 10.0.1.X
        netmask 255.255.255.0
        network 10.0.1.0
        broadcast 10.0.1.255

10.0.1.X sollte hierbei das X als 1 auf dem Master und 2 auf dem Slave gesetzt sein. Nach einem  /etc/init.d/networking restart sollte eine ping Probe möglich sein
root@mysql-master:~# ping 10.0.1.2
PING 10.0.1.2 (10.0.1.2) 56(84) bytes of data.
64 bytes from 10.0.1.2: icmp_req=1 ttl=64 time=3.95 ms

Nun beginnen wir mit der Arbeit auf dem Master
Als erstes editieren wir die /etc/mysql/my.cnf, hier suchen wir die Zeile

  • #server-id            = 1

  • #log_bin              = /var/log/mysql/mysql-bin.log


und kommentieren sie ein, danach

  • mysql -p


um in das MySQL Interface zu gelangen
 
GRANT SUPER, RELOAD, REPLICATION SLAVE ON *.* TO 'repl'@'10.0.1.2' IDENTIFIED by '<ANYPASSWORD>';flush privileges;

 

Nun brauchen wir noch den Grunddatensatz, hierzu packen wir uns einfach das data_dir welches wir in /etc/mysql/my.cnf finden. Im Falle von Debian sollte dies /var/lib/mysql sein

  • cd /var/lib/mysql

  • tar cfz /tmp/mysnap.tar.gz .

  • scp mysnap.tar.gz 10.0.1.2:


Letzter Punkt auf dem Master, wir brauchen das aktuelle Logfile
mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 |      106 |              |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)



UPDATE!!! Zu den letzten zwei Schritten gibt es auch noch etwas sehr einfaches das dies ersetzt
mysqldump -c --single-transaction --master-data -p  > /rootdump.sql

In diesem Dump merkt sich MySQL dann auch die Binlog Position etc.



ACHTUNG! Debian hat einen eigenen Systemnutzer, mit dieser Methode wird auch sein Passwort überschrieben, was dazu führt das MySQL auf dem Slave gleich nicht mehr gestartet werden kann. Workaround ist relativ simple, man kopiere sich die Passwörter aus /etc/mysql/debian.cnf und ersetze diese auch auf dem Slave.

Nun machen wir auf dem Slave weiter
Auch hier suchen wir den server-id Eintrag, setzen ihn aber auf 2

  • server-id            = 2


Nun entpacken wir unser Archiv, wenn Sie unsicher sind können Sie hier auch im my.cnf File nachsehen welches das data dir ist

  • tar xfz mysnap.tar.gz -C /var/lib/mysql/


Im letzten Schritt
mysql -p
CHANGE MASTER TO
MASTER_HOST="10.0.1.1",
MASTER_USER="repl",
MASTER_PASSWORD="<ANYPASSWORD>",
MASTER_LOG_FILE="mysql-bin.000001"; 
START SLAVE;

Abschliessende Kontrolle:
So, eigentlich sollte unsere Arbeit hiermit erledigt sein, wir testen unser tun natürlich noch, ich kopiere mit Absicht nicht die ganze Zeile der Ausgabe, aber so ungefähr sollte sie aussehen

Auf dem Master
show processlist;
35 | repl | 10.0.1.2:36874 | NULL | Binlog Dump |  914 | Has sent all binlog to slave; waiting for binlog to be updated | NULL

Auf dem Slave, so etwas wie
show processlist;
Waiting for master to send event | 10.0.1.1    | repl        |        3306 |            60 | mysql-bin.000001 |                 106 | mysqld-relay-bin.000002 |           251 | mysql-bin.000001

ACHTUNG! Fast hätte ich es vergessen. Was mir auch sehr spät bei der Kontrolle aufgefallen ist, ist das Debian standardmässig nur auf 127.0.0.1 hört daher muss die bind-adresse noch angepasst werden.

  • bind-address = 0.0.0.0


Danke das wars :-)

Mittwoch, 10. Oktober 2012

Ioncube Loader

Ioncube Loader
Der Ioncube Loader. Wird immer beliebter. Er ermöglicht es zwar php Anwendungen an einen Kunden herauszugeben, verhindert aber das dieser Kunde den Quelltext sehen kann.
Somit ist er Ioncube Loader natürlich für Unternehmen interessant die primär mit ihren Webentwicklungen Geld verdienen wollen.

Nun haben wir auch vorgesehen dieses beim nächsten Update unserer Web_Skeletons diesen endlich mal fest einzubauen, bis dahin ist aber immernoch ein wenig Handarbeit von Adminseite nötig.
Aus diesem Grund beschreibe ich doch nun mal kurz das allgemeine Vorgehen um einen Ioncube Loader in Betrieb zu nehmen.

Also erstmal zum Abgleich die Grundlagen

  • Apache/2.2.16 (Debian)

  • PHP 5.2.6-1 with Suhosin-Patch 0.9.6.2


Wir laden von der oben genannten Seite das passende Linuxpaket

  • http://downloads2.ioncube.com/loader_downloads/ioncube_loaders_lin_x86.tar.gz


oder

  • http://downloads2.ioncube.com/loader_downloads/ioncube_loaders_lin_x86-64.tar.gz


nach dem entpacken haben wir folgende Verzeichnisstruktur

home01:~/ioncube# ls
ioncube_loader_lin_4.1.so ioncube_loader_lin_5.1_ts.so
ioncube_loader_lin_4.2.so ioncube_loader_lin_5.2.so
ioncube_loader_lin_4.3.so ioncube_loader_lin_5.2_ts.so
ioncube_loader_lin_4.3_ts.so ioncube_loader_lin_5.3.so
ioncube_loader_lin_4.4.so ioncube_loader_lin_5.3_ts.so
ioncube_loader_lin_4.4_ts.so LICENSE.txt
ioncube_loader_lin_5.0.so loader-wizard.php
ioncube_loader_lin_5.0_ts.so README.txt
ioncube_loader_lin_5.1.so

natürlich kann man an dieser Stelle den loader-wizard in den Webspace verschieben, die seite aufrufen und der Anleitung folgen, da es aber nun schon ein paar mal getan wurde, geht es so weiter:
Wir verschieben alle Dateien nach /usr/local/ioncube (wahlweise auch nur die die wir wirklich brauchen in unserem Falle also die ioncube_loader_lin_5.2.so)
Wir erstellen folgenden Eintrag in der /etc/php5/apache2/php.ini am besten direkt ganz am Anfang der Datei, da es sonst (zumindest bei mir) öfter zu Problemen kommt
zend_extension = /usr/local/ioncube/ioncube_loader_lin_5.2.so

Apache neustarten und Thats it!