Warum Göttingen ewig nur Göttingen sein wird und nie mehr

Lieber Herr Oberbürgermeister der Stadt Göttingen,
Ihr Hilferuf hat unsere kleine Familie am 24.10 im Waldweg auf dem Parkplatz des Neu Bethlehem in Form eines Strafzettels für das Fehlen eines Parkscheins erreicht. Mir war nicht klar, dass Göttingen kurz vor einer finanziellen Katastrophe steht. Leider war es mir nicht möglich morgens um 5 Uhr den Parkscheinautomat zu betätigen, da ich meine, unter starken Wehen leidende Freundin, stützen musste. Wäre ihr die finanzielle Situation Göttingens bewusst gewesen, hätte sie sich eventuell etwas mehr beherrscht. Leider kam ich erst am Nachmittag aus dem Kreißsaal und konnte Ihre Nachricht unter dem Scheibenwischer meines Autos finden.

Damit wir zusammen diese Krise durchstehen, biete ich Ihnen an einen Strafzettel für das Fehlen eines Parkscheins aufgrund einer Geburt am 24.10 einmal pro Jahr, die nächsten 4 Jahre, zu übernehmen. Neulinge in Göttingen oder junge Familien könnten sonst wohl noch denken, Göttingen sei raffgierig, Familien unfreundlich, gar auf Neugeborene nicht gut zu sprechen. Wir wissen aber von dieser finanziellen und organisatorischen Krise, da ansonsten natürlich eine kostenlose Parkmöglichkeit für Notfälle geschaffen worden wäre oder wenigstens eine andere Möglichkeit (ohne Zweifel gibt es Möglichkeiten).

Eventuell besteht auch die Möglichkeit eines unbezahlten Praktikums bei der Stadt Braunschweig. Wir könnten vielleicht einen Platz für Sie vermitteln. Dort erhalten Eltern von Neugeborenen zum Beispiel ein Überraschungspaket der Stadt Braunschweig mit vielen praktischen Dingen, dort hat zum Beispiel das Bürgerservicecenter (in Göttingen nennt man das Einwohnermeldeamt) auch Samstags auf, auch die KFZ Stelle hat eingeschränkt Samstags auf. Das mag für Göttingen alles noch Zukunftsmusik sein, aber man kann sich durchaus große Ziele stecken.
Ich habe den Strafzettel eingerahmt und hänge ihn in das Kinderzimmer unseres kleinen Schatzes, damit wir immer daran erinnert werden, wie wir der Stadt Göttingen aus der Krise geholfen haben. Allen Kritikern gegenüber werden wir berichten zu welchen drastischen Maßnahmen Sie gezwungen sind.

Liebe Grüße,

Thomas, Silvia und die kleine Selda

p.s. Um sinnlosen Verantworlichkeits-Diskussionen aus dem Weg zu gehen. Bei Linuxbenutzern herrscht eigentlich der einfache Grundsatz “Wer root hat, trägt auch die Verantwortung für das System”.

29. October 2014
1 comment

Selda Marie

IMG_20141025_141916

Am 24.10 um 11:39 kam Selda Marie zur Welt.

25. October 2014
1 comment

Kurztipp: nagios check_nfssmount

Findet man ganz einfach im Paket nagios-plugins-contrib bei Ubuntu

apt-get install nagios-plugins-contrib

Damit kommen auch eine ganze Reihe anderer nützlicher Plugins mit auf das System z. B.

check_email_delivery, check_drbd, check_cups, check_haproxy, check_backuppc, check_multipath, check_mysql_health und und und

Lohnt auf  jeden Fall, da man sich das zusammensuchen spart.

 

 

16. October 2014
Tags:
, | Leave a comment

Kurztipp: cron für einen bestimmten Benutzer deaktvieren

Eventuell will man einem bestimmten Benutzer das Recht nehmen einen cronjob zu nutzen. Dazu reicht es eine Datei /etc/cron.deny anzulegen und den jeweiligen Benutzer dort einzutragen. Beim nächsten Versuch einen cronjob zu editieren, sollte dann in etwa folgendes kommen:

$ crontab -e
You (www-data) are not allowed to use this program (crontab)

Exisitiert cron.allow wird cron.deny nicht ausgewertet.

genaueres findet man bei man crontab.

06. October 2014
Tags:
| Leave a comment

Debian&co und die lieben Updates

===Der Artikel ist schon etwas älter, aber bevor ich ihn lösche… ===

Warum Updates und wie kann an sich informieren?

Betreibt man seinen Server im Internet kommt man um regelmäßige Updates nicht drumherum. Bei Debian stable Systemen bestehen die Updates in der Regel aus Sicherheitsupdates und bringen nur sehr selten größere Versionssprünge mit sich. Informationen zu verfügbaren Updates findet man für Debian unter http://www.debian.org/security/. Dort ist auch eine so genannte debian-security-announce mailing list verlinkt. Trägt man sich dort ein, erhält man eine Benachrichtigung per mail, falls neue Update bereitstehen. Für Ubuntu findet man diese Informationen unter http://www.ubuntu.com/usn. Jede Distribution hat in der Regel einen solchen Informationskanal. Auch das DFN bietet einen solchen Service unter https://portal.cert.dfn.de/ an, Voraussetzung dabei ist ein gültiges DFN-PKI Zertifikat, etwas umständlich, aber eh nur als Hinweis zu sehen. Es sollte vermieden werden, sich bei zu vielen Listen einzutragen, das dient weder der Übersichtlichkeit, noch erhält man zusätzliche Informationen. Sicherheitsupdates sollten, nach Möglichkeit, immer Zeit nah einspielt werden. auf etwaige Wartungsfenster sollte man dabei keine Rücksicht nehmen. Dabei ist es egal, ob es sich um so genannte “local” oder “remote” Schwachstellen handelt. Tauchen Exploits erst mal bei Seiten wie http://packetstormsecurity.org/files/ oder 1337day usw. auf, steigt das Risiko eines potentiellen Angriffs auf die ungepatchte Software enorm.
Kurz und knapp gesagt: Existieren Sicherheitsupdates, sind diese zu installieren.

Updates installieren

Unter Debian läuf das Updaten relativ einfach ab.

apt-get update; apt-get dist-upgrade

Durch apt-get update ist dem System bekannt welche Updates eingespielt werden müssen und mit apt-get dist-upgrade werden diese eingespielt. Tools wie apticron, cron-apt oder unattended-upgrades sollten auch einen Blick wert sein. Diese Tools helfen zusätzlich um Updateinformationen zu erhalten und Updates automatisch einzuspielen. Besonders unattended-upgrades ist ein einfacher Weg Updates, besonders Sicherheitsupdates, automatisiert einzuspielen. Dabei kann auch bei jedem durchgeführten Update, eine mail verschickt werden. Will man verfügbare Updates auch via Nagios überwachen, bietet sich check_apt als Plugin an.
Ein Log der eingespielten Updates findet man im Nachhinein unter /var/log/apt/history.log bzw. in /var/log/unattended-upgrades/.

Updates überprüfen

Da es in der Regel keine größeren Versionsprünge bei “normalen” Updates gibt, sollte es keine Veränderung beim Verhalten des Programms geben. Anders sieht es natürlich bei major Upgrades aus. Eine Sprung von z.B: PHP 5.2 auf 5.3 zieht etliche Veränderungen an diversen Webapplikationen mit sich. So ein Update passiert natürlich nicht beim normalen Systemupdate. Es schadet aber nicht, sich die Updates etwas genauer anzuschauen auch um eventuell neu auftretende Probleme mit den Updates in Verbindung zu bringen. Die betroffenen Dienste sollten auf jeden Fall, nach dem Update, auf ihre Funktion überprüft werden.

Wen informieren?

Bei Sicherheitsupdates kann eigentlich drauf verzichtet werden die Benutzer zu informieren. Es sei denn mit dem Update ist ein Ausfall eines Dienstes verbunden, ist es so, sollte man dem Benutzer über den Grund und die etwaige Dauer des Ausfalls informieren. Ob es den 0815 Benutzer interessiert, dass ein neuer Kernel installiert wurde und welche Lücken durch Update XY gestopft wurden? Information ist dabei das A und O, jeder Benutzer nimmt es positiv wahr, wenn er über den Grund eines Ausfalls informiert wird. Je nach Dauer und Wichtigkeit des Dienstes sollte man die Benutzer rechtzeitig informieren. Die Regel ist einfach: Lieber zu viel, als zu wenig Informationen.
Natürlich hat man immer Querulanten dabei, die sich über Ausfälle beschweren und kein Verständnis zeigen. Diese sollte man über die Folgen nicht durchgeführter Updates aufklären und aus der Freundesliste streichen ;-).

Sonderfall Reboot

Benötigt das Update einen Reboot, wie z.B. ein neuer Kernel wurde installiert, ist es wichtig vorher zu klären ob z.B. ein Dateisystem Check ansteht. Je nach eingesetztem Dateisystem und Größe des Devices kann so ein Check viel Zeit in Anspruch nehmen. Ob ein solcher Check ansteht, kann man mit Hilfe von tune2fs überprüfen, z.B:

$ tune2fs -l /dev/sdc1
...
Mount count:              4
Maximum mount count:      25
Last checked:             Fri Nov 25 09:48:18 2011
Check interval:           15552000 (6 months)
Next check after:         Wed May 23 10:48:18 2012
...

Wie sinnvoll ein Check ist oder nicht, ist eine andere Frage. Viele neigen dazu diese Checks beim anlegen des Devices abzuschalten, ich tue dies nicht.

Letzte Worte

Man sollte sich generell bei Updates immer darüber im klaren sein, wie viel Zeit ein Update einspielen kostet und wie viel Zeit man benötigt um einen Eindringling wieder vom System zu entfernen bzw. den angerichteten Schaden zu beheben.

01. October 2014
Leave a comment

nfs cachen mit cachefilesd

Ein kleiner Test zum NFS cachen. Genutzt habe ich cachefilesd dafür.

apt-get install cachefilesd

Konfigurationsdateien sind

/etc/default/cachefilesd

dort

RUN=yes

auskommentieren

und /etc/cachefilesd.conf wo man z.B. den Ort des Caches einstellen und diverse Limits setzen kann.

dir /cache
tag mycache
brun 10%
bcull 7%
bstop 3%
frun 10%
fcull 7%
fstop 3%

Informationen zu den Variablen findet man unter man cachefilesd.conf.
Als nächstes muss das Filesystem auf dem der Cache liegt die user_xattr Option bekommen, z.B.

UUID=4d6b8fab-95f1-49e1-9651-16cbcb611ae6 / ext4 errors=remount-ro, user_xattr   0 1

Ebenso muss der mount Eintrag des nfs shares um die Option fsc ergänzt werden

123.123.123.123://web nfs defaults,rsize=32768,wsize=32768,intr,hard,rw,vers=3,fsc 0 0

in der fstab.

Danach noch ein reboot und nach dem reboot prüfen ob der cachefilesd Daemon läuft

/etc/init.d/cachefilesd status

fertig.

————-
Ein kurzer Exkurs wie man eine Ramdisk als Device nutzt

Nun könnte man natürlich auch eine Ramdisk als cache Device nutzen.
Das bringt noch ein paar Prozent an Geschwindigkeit.
Das fasse ich mal in kurz zusammen:

In der fstab /etc/fstab

tmpfs /media/tmpfs default,tmpfs size=10%	0 0

Wir nutzen 10% des RAMs für unseren Cache.

Einmounten unserer Ramdisk

mount /media/tmpfs

Erstellen eines Files in der Größe der Ramdisk

dd if=/dev/zero of=/media/tmpfs/cache bs=1024

Wir legen uns ein Device an und mounten es auf unseren Cache Ordner, den wir in der /etc/cachefilesd.conf angegeben haben

losetup /dev/loop0 /media/tmpfs/cache
mkfs.ext4 /dev/loop0
tune2fs -m0 /dev/loop0]
mount -o user_xattr /dev/loop0 /cache/

und mit

/etc/init.d/cachefilesd start

starten wir den Daemon.

Das findet ihr alles noch etwas besser beschrieben unter http://bopinions.de/?p=127.
Dort steht auch noch wie man das ganze persistent macht.
Das geht bestimmt auch irgendwie ohne den containerfile. Werde ich mir nochmal anschauen.
————-

Mit

$ cat /proc/fs/nfsfs/volumes
NV SERVER PORT DEV FSID FSC
v3 0a6c2008 801 0:21 58be8694:0 yes

kann man prüfen ob fsc auch genutzt wird.

$ cat /proc/fs/fscache/stats
FS-Cache statistics
Cookies: idx=9 dat=3553 spc=0
Objects: alc=2610 nal=0 avl=2610 ded=51
ChkAux : non=0 ok=0 upd=0 obs=0
Pages : mrk=60574 unc=20
Acquire: n=3562 nul=0 noc=0 ok=3562 nbf=0 oom=0
Lookups: n=2610 neg=2610 pos=0 crt=2610 tmo=0
Invals : n=0 run=0
Updates: n=0 nul=0 run=0
Relinqs: n=53 nul=0 wcr=0 rtr=0
AttrChg: n=0 ok=0 nbf=0 oom=0 run=0
Allocs : n=0 ok=0 wt=0 nbf=0 int=0
Allocs : ops=0 owt=0 abt=0
Retrvls: n=3027 ok=0 wt=1796 nod=2967 nbf=60 int=0 oom=0
Retrvls: ops=2967 owt=2389 abt=0
Stores : n=60571 ok=60571 agn=0 nbf=0 oom=0
Stores : ops=10392 run=70963 pgs=60571 rxd=60571 olm=0
VmScan : nos=0 gon=0 bsy=0 can=0 wt=0
Ops : pend=2389 run=13359 enq=70963 can=0 rej=0
Ops : dfr=61 rel=13359 gc=61
CacheOp: alo=0 luo=0 luc=0 gro=0
CacheOp: inv=0 upo=0 dro=0 pto=0 atc=0 syn=0
CacheOp: rap=0 ras=0 alp=0 als=0 wrp=0 ucp=0 dsp=0

bringt Statistiken zum Vorschein.

Ob ich das weiter betreibe und wo die Probleme und Vorteile liegen kann ich noch nicht abschätzen. Das wird sich aber im Laufe der nächsten Tage/Wochen zeigen.
Ein wichtiger Punkt ist natürlich wie Änderungen an Dateien erkannt werden bzw. was sie kosten. Eine expire time wie beim nginx cache kann man nicht einstellen.

An Erfahrungen damit bin ich sehr interessiert.

Update 1: noatime und nodiratime sollte man eventuell aus den Mountoptionen nehmen, da diese für das culling genutzt werden.
Update 2: Nach ein paar Tagen hängen sich die Webserver mit cachefilesd aktiviert auf. Der Zusammenhang ist noch nicht klar.

Links:
http://bopinions.de/?p=127
http://blog.lastlog.de/posts/ubuntu_cachefs_experiments/
http://chase-seibert.github.io/blog/2014/03/09/vagrant-cachefilesd.html
http://www.cyberciti.biz/files/linux-kernel/Documentation/filesystems/caching/cachefiles.txt
http://www.cyberciti.biz/faq/centos-redhat-install-configure-cachefilesd-for-nfs/
https://blog.yrden.de/2013/10/13/setting-up-nfs-cache-on-debian.html
http://ispire.me/nginx-over-nfs/
http://blog.spekschoor.nl/2012/08/effective-caching-with-nginx-over-nfs.html

22. September 2014
Tags:
| Leave a comment

OMV 1.0

Heute wurde OMV 1.0 (Kralizec)  offiziell veröffentlicht.  Mal abwarten ob mein Update von 0.5>1.0 auch problemlos von statten geht.

 

Update: Der Sprung von 0.5.58 auf 1.0 verlief extrem langweilig und problemlos.

15. September 2014
Leave a comment

N54L Fazit

…nach drei Monaten.

Unser TV weckt das Teil jedes mal auf wenn er angeschaltet wird. Das liegt am aktivierten WOL vom N54L. Kann man verkraften und eigentlich ist das sogar in 95% der Fälle sehr praktisch. OMV ist super. Meiner Meinung nach gibt tatsächlich nichts zu beanstanden.

Fazit Ende.

05. September 2014
Tags:
, | Leave a comment

N54L als NAS

Die Überlegung war Qnap, Synology oder selbst was bauen. Das Ergebnis der Überlegung war ein HP ProLiant N54L. Für die Entscheidung habe ich relativ lange gebraucht. Qnap (219 und 469) setze ich schon seit Jahren beruflich als zweit Backupsystem ein und war eigentlich immer sehr zufrieden. Ich wollte auch aus diversen Gründen kein System in das ich viel Zeit investieren muss, um es zum Laufen zu bringen. Eigentlich suchte ich nur ein flexibles, wartungsarmes und unabhängiges System auf Linuxbasis und mehr nicht. Der N54L als NAS ist genau das was ich wollte, flexibel unabhängig und günstig.  Günstig bedeutet dabei 177 €. Dafür bekommt man einiges: 2,2 GHz dual Core, 4 GB Speicher, DVD Brenner (wozu auch immer), 4 Bay Gehäuse usw.

n54lEin wichtiger Entscheidungspunkt war auch der Stromverbrauch. Dabei liege ich zur Zeit mit 5 HDs (4 normale + 1 SSD für OS) bei ca. 20 Watt im Idle, 40-50 bei Last und 1 Watt im WOL Zustand. WOL funktioniert außerdem wunderbar, dabei lässt sich das NAS mit jedem Device problemlos aufwecken. Bei XBMC 13 ist WOL direkt integriert und man braucht “eigentlich” kein Extra Addon. “Eigentlich” deshalb weil es bisher nur beim ersten mal wecken funktioniert innerhalb einer “Session”. Als Kernel hab ich den  3.14er (http://alexanderduss.de/Share/Kernel/HP_Mircoserver/ danke nochmal) installiert. Als OS nutze ich bisher Openmediavault oder einfacher OMV.  OMV ist gut, es bietet eine überschaubare Weboberfläche und tut was es tun soll. Installation ist ein Kinderspiel und es gibt ein Pluginsystem wie bei anderen NAS Systemen auch. Dabei stehen Plugins für Autoshutdown, Plex, DLNA, rsnapshot, virtualbox, virtualhosts usw. zur Verfügung. Durch Einbinden zusätzlicher Repositories, kann man auf noch mehr  Plugins  zugreifen. Ein Vergleich zu FreeNas und Nas4free fehlt mir, aber ich wollte auch ein Debian basiertes System haben. Darin liegt auch der große Vorteil von OMV. Ein normales Debian (noch squeeze in der 0.5er Version) was man eigentlich nach belieben anpassen kann, aber nicht muss. Sollte das Anpassen überhand nehmen, kommt da einfach ein Debian Wheezy drauf und gut ist, die paar NFS, Samba, DLNA Dienste bekommt man auch via Konsole hin.  Bisher bin ich sehr zufrieden und denke ich werde eine Weile bei OMV bleiben. Ansonsten kann man sogar XPEnology (Synology DSM 5.0) auf dem Teil laufen lassen. Auch die Hardare lässt sich problemlos erweitern: Remote Access Karte, zusätzliche Grafikkarte mehr Speicher (max 16GB).

Nachteile gibt es natürlich auch. Das Teil ist ein bisschen lauter als ein Qnap oder Synology. Es fehlt, jedenfalls bei OMV, eine zeitgesteuerte Startfunktion und  z.B.

rtcwake -m no -t $(date -d 'tomorrow 8:15' +%s)

funktioniert nicht wie erwartet beim N54L (geht zwar an aber nicht wann er soll)  nun auch. Hat mich anfangs etwas gestört, aber eigentlich soll das Teil angehen wenn man es braucht und nicht zu einer bestimmten Uhrzeit und das funktioniert einwandfrei. Die Bootzeit beträgt bei mir ca. 45 Sekunden.
Es gibt keinen Audioausgang, aber das ist zu verkraften.
Der Stromverbauch bei z.B. Qnap (412) ist noch um ein paar Watt niedriger.

Das war es auch schon an Nachteilen aus meiner Sicht. Wer sich auch nur etwas mit Linux auskennt wird  mit dem N54L als NAS keine Probleme haben. Der Durchsatz ist mir relativ egal, aber schaffen tut er mit NFS  locker 100mb/s bei mir.

Ich werde mal versuchen im Laufe der nächsten Monate ein paar Erfahrungen mit dem N54L aufzuschreiben.

 

05. June 2014
Tags:
, , | 4 comments

Die neue Wohnung mit Open Source planen

Da ich bald mit Frau K. in eine gemeinsame Wohnung ziehe, habe ich eine Open Source Lösung zur Planung gesucht. Genauer gesagt zur Innenraum Planung. Relativ schnell bin ich bei Sweet Home 3D gelandet und bin nun seit ein paar Tagen ein Fan dieser Anwendung. Bisher hatte ich nur vor einigen Jahren mal was mit SketchUp gemacht, fand ich ok mehr aber auch nicht.

SweetHome3DLinux

Das Bild ist von der Homepage und zeigt eine Übersicht über die Möglichkeiten des Programms. Sweet Home 3D ist bei Ubuntu 12.04 / 14.04 in den Repositories dabei.

apt-get install sweethome3d

In der 14.04 sind noch weitere Texturen und Modelle dabei. Es macht wirklich Spaß damit die neue Wohnung zu planen und eine Vorstellung über den verfügbaren Platz und Größenverhältnisse zu bekommen. Optimalerweise hat man einen eingescannten Grundriss der Wohnung, den man als Hintergrundbild verwenden kann. Einfach mal anschauen und versuchen die eigene Wohnung nach zubauen. Das Programm ist wirklich eins der Programme wo man ruhig mal donaten sollte.

05. May 2014
2 comments

neulich in Rom

 

“Da sollten Sie auf keinen Fall durchgehen….”

25. April 2014
Tags:
| Leave a comment

Kurztipp: Greylisting unter Postfix aktivieren

Unter Debian/wheezy ist postgrey in einer Minute eingerichtet.

apt-get install postgrey

Die /etc/postfix/main.cf um “check_policy_service inet:127.0.0.1:10023″ ergänzen, sieht bei mir dann so aus:

smtpd_recipient_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_unauth_destination
check_policy_service unix:private/policy-spf
check_policy_service inet:127.0.0.1:10023

Bei Debian Wheezy läuft postgrey default auf 10023.
Postfix neu starten

/etc/init.d/postfix restart

Prüfen ob postgrey läuft mit

$ps aux|grep postgr
postgrey 32421  0.0  0.1  67932 14804 ?        Ss   21:51   0:00 /usr/sbin/postgrey --pidfile=/var/run/postgrey.pid --daemonize --inet=10023

Will man die Verzögerungszeit von default 300 Sekunden anpassen, kann man dies in der /etc/default/postgrey tun z.B.

POSTGREY_OPTS="--inet=10023 --delay=120"

Schaut man in /var/log/mail.info nach postgrey, sollte man bald Einträge in der Art

...postgrey[32421]: action=greylist, reason=new...

finden.

Will man wissen, wer alles so erfolgreich abgelehnt wurde, kann man z.B. einfach mal

cat /var/log/mail.info|postgreyreport

oder etwas übersichtlicher

cat /var/log/mail.log | postgreyreport --nosingle_line --check_sender=mx,a --show_tries --separate_by_subnet=":===============================================================================================\n"

ausführen.

Es gibt noch die Möglichkeit Ausnahmeregeln zu definieren (whitelist_clients, whitelist_recipients).

Links:
http://de.wikipedia.org/wiki/Greylisting

http://www.debuntu.org/postfix-and-postgrey-a-proactive-approach-to-spam-filtering-page-2/

16. April 2014
Tags:
, , | 1 comment

Kurztipp: nmap range scan heartbleed

Mit nmap lässt sich relativ unkompliziert ein range scan auf den heartbleedbug durchführen, dazu ist aber eine aktuelle nmap Version nötig:

wget http://nmap.org/dist/nmap-6.45.tar.bz2
bzip2 -cd nmap-6.45.tar.bz2 | tar xvf -
cd nmap-6.45/
./configure
make

wer es dann noch installieren will kann ein

make install 

ausführen, womit nmap nach usr/local/bin/ installiert wird, ansonsten liegt die nmap binary direkt im Ordner und kann z.B. mit

./nmap -sV -p 443,10000 --script=ssl-heartbleed.nse 123.123.123.1/24 

aufgerufen werden. Ein Scan durch ein ganzes Subnetz kann schon ein paar Minuten dauern und treibt die Last der Maschine recht hoch. Also am besten auf parallele Prozessese verzichten. Die Portliste kann man natürlich noch um diverse Ports erweitern (443, 993, 25, 465 usw.).
Bei Erfolg sieht das Ergebnis in etwa so aus:

...
Host is up (0.0014s latency).
PORT    STATE SERVICE
443/tcp open  https
| ssl-heartbleed:
|   VULNERABLE:
|   The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. It allows for stealing information intended to be protected by SSL/TLS encryption.
|     State: VULNERABLE
|     Risk factor: High
|     Description:
|       OpenSSL versions 1.0.1 and 1.0.2-beta releases (including 1.0.1f and 1.0.2-beta1) of OpenSSL are affected by the Heartbleed bug. The bug allows for reading memory of systems protected by the vulnerable OpenSSL versions and could allow for disclosure of otherwise encrypted confidential information as well as the encryption keys themselves.
|
|     References:
|       http://cvedetails.com/cve/2014-0160/
|       https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160
|_      http://www.openssl.org/news/secadv_20140407.txt
...

Noch ein Hinweis…liebe Webmin Benutzer denkt daran Webmin neu zu starten, denn das ist natürlich auch vom Bug betroffen.

Links:

http://nmap.org/download.html

http://www.cirgan.net/scanning-openssl-heartbleed-bug-with-nmap/

15. April 2014
Tags:
, , | Leave a comment

Kurztipp: Heartbleed und kein Ende

Denen, die NAS Systeme zu hause betreiben und das Webinterface aus Bequemlichkeit von 0/0 erreichbar gemacht haben, sei gesagt: Euer NAS ist höchstwahrscheinlich auch vom Heartbleed Bug betroffen.

Getestet habe ich bisher nur ein altes QNAP 219 mit Version 4.05 und ein QNAP 469L mit 4.06. Ich denke aber, dass so ziemlich jedes QNAP NAS (Synology & co sicherlich auch) mit der 4er Firmware betroffen ist. Updates habe ich bisher noch keine dafür gesehen. Am besten also den Zugriff beschränken oder komplett von außen sperren. Problematisch wird es bei billig NAS Systemen, wo Softwareupdates eher die Ausnahme sind. Das gleiche gilt natürlich auch für eure Raspberry Pis & co. Bei Raspbmc ist ein komplettes upgrade/ dist-upgrade eher nicht zu empfehlen. Da sollte ein

apt-get update && sudo apt-get --only-upgrade install openssl

reichen. Da kommt sicherlich noch viel mehr und das Netz wird zur Zeit voll von Scans sein. Mich würde interessieren ob ein massiver Scan auf verwundbare Systeme irgendwelche Auswirkungen zeigt, also Anstieg der Load zum Beispiel.
Ist man neugierig wer so alles den Heartbleed Bug bei seinen Systemen versucht kann folgendes versuchen:

# Log rules
iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 "52=0x18030000:0x1803FFFF" -j LOG --log-prefix "BLOCKED: HEARTBEAT"

# Block rules
iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 "52=0x18030000:0x1803FFFF" -j DROP

Die erste Regel logt Versuche nach syslog (oder /varog/warn bei Suse), die zweite sperrt 443 für Exploit Versuche (via https://plus.google.com/+MatthewSummers/posts/jiZdHvuHq69 und zu finden unter http://seclists.org/fulldisclosure/2014/Apr/109)

….ach da kommt bestimmt noch viel mehr in naher Zukunft.

update: Mittlerweile gibt es die FW4.07 für das QNAP 469L, damit ist die Lücke geschlossen. Für das QNAP 219 gibt es leider nichts.

 

10. April 2014
Tags:
, | 4 comments

Kurztipp: PHP Variablen pro Vhost anpassen

Viele Apache Admins neigen dazu, alle PHP Einstellungen in der globalen php.ini (/etc/php5/apache2/php.ini default bei Debian) zu machen. Das ist einfach und überschaubar. Die einzelnen Vhosts haben dann in der Regel nur noch ein php_admin_value open_basedir in der jeweiligen Konfiguration und mehr nicht. Das führt dazu, dass bei einer größeren Anzahl von Vhosts, die Limits eventuell unnötig hoch sind, z.B. will man vielleicht für einen eigenen Phpmyadmin Vhost eine höhere upload_max_filesize als für einen einfachen Webauftritt. Trägt man die Werte direkt in die globale php.ini ein, gelten die Werte natürlich für alle Vhosts. Will man die Werte aber nur für einen bestimmten Vhost anpassen, kann man das auch z.B. direkt in die jeweilige conf eintragen:

<VirtualHost *:80>
...
php_value max_execution_time 120
php_value upload_max_filesize 128M
php_value post_max_size 129M
...
</VirtualHost>

Das kann auch für bestimmte “Locations” und “Directories” einzeln eingetragen werden. Je nach Möglichkeit (AllowOverride Options) geht das auch mit .htaccess, aber das führt zu unnötiger Last (vielleicht übertreibe ich) und ist meiner Meinung nach auch ein Sicherheitsrisiko. So das wars, sonst ist es kein Kurztipp mehr ;-).

07. April 2014
Leave a comment

← Older posts