-=Kernel-Error=-

IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Schlagwort: Security (Seite 11 von 15)

P-A-N-I-C Millionen E-Mail Kennwörter geknackt!!!

9. April 2014 / / Keine Kommentare

Oh Gott…. Nein was machen wir jetzt bloß?

O-o nun mal im Ernst, mich wundert an der Geschichte eher dass dieses Viele überrascht. Schauen wir uns doch mal die durchschnittlichen Kennwörter der meistern Benutzer an. Die sind nicht wirklich gut und oft haben sie ebenfalls nur ein Kennwort  für alle ihre Dienste. Natürlich haben sie ja per default nichts zu verbergen, also wird auf „Sicherheit“ nicht unbedingt Wert gelegt… Klar geht mir in diesen Fällen immer ein Schmunzeln über die Lippen. Denn man hat ja nichts zu verbergen und ist ja alles nicht SO schlimm. Nur wenn mein E-Mail Passwort von anderen geklaut wurde, ne da muss natürlich was passieren.

Ich lese und höre in den letzten Tagen immer das fiese, böse, Masken und Kapuzen tragende Hacker die E-Mail Accounts gehackt hätten. Viel eher werden wohl verseuchte Rechner die Kennwörter bei der Eingabe oder Übertragung eingesammelt und Kriminellen geschickt haben. Wenn ich mich so bei einigen Kunden umschaue sieht man schnell dass die großen drei Sicherheitslöcher Anwendungsprogramme (Java, Flash, PDF) meist in recht alten Versionen vorliegen. Die Microsoft Produkte selbst bekommen ja meist per WSUS oder direkt von Microsoft ihre Updates. Java, Flash oder der Acrobat Reader kümmern sich „selbst“ darum. Leider muss der Anwender für die Installation der Updates administrative Rechte auf dem Rechner haben. Sonst kann er die Installation kaum durchführen. Gut, es gibt auch hier Lösungen… Welche ich produktiv im Einsatz gesehen habe kann ich an einer Hand abzählen. Daher hängt es mal wieder vom Einsatz der hauseigenen IT ab. Das klappt mal gut, mal weniger gut. Gibt es keine eigene IT, sieht es schnell schlecht aus. Warum muss überhaupt jeder Anwender ins Internet und warum immer mit Flash, Java und PDF?!?!

Es lässt sich kaum ändern. Vor einiger Zeit hatten wir ja schon mal etwas ähnliches. Wie groß ist dann wohl die Dunkelziffer tongue-out ? Beim letzten mal hat unser BSI nach langem überlegen die Idee eine Webseite zur Verfügung zu stellen auf welcher man seine E-Mail Adresse eingeben kann. Die Webseite war natürlich sofort tot und nicht erreichbar. Wer hätte schon damit rechnen können dass die eingeschüchterten Benutzer es wirklich probieren könnten? *kopfschüttel*

Man hat also seine E-Mail Adresse eingegeben und hat daraufhin die Info bekommen: Wenn deine E-Mail Konto geklaut wurde, dann bekommst du von uns eine GPG signierte E-Mail mit folgendem Betreff (Zufallszeichen). Nur wenn die E-Mail auch diesen Betreff hat ist sie von uns und du hast ein Problem!

Einmal mit Profis…. Nun nehmen wir das mal eben auseinander:

1. der GPG Schlüssel vom BSI ist auf der gleichen Webseite zu saugen und ist so vertrauenswürdig wie „der dicke Mann aus der Sparkassenwerbung“…
2. GPG ist toll nur wie viele der Anwender nutzen es wohl?
3. der Betreff, auf welchen es ankommt, wird bei einer GPG signierten E-Mail NICHT signiert. Er kann also wild geändert werden…
4. die E-Mail welche den Anwender darüber informiert das sein Account ggf. von anderen missbraucht wird, geht also an diesen Account. Der Missbrauchende müsste sie also nur ?löschen?.

Worried face meme reacting to stolen passwords

Welcher Internetausdrucker hat sich dieses bitte überlegt?!?!?

Diese Kritikpunkte sind beim BSI angekommen und man könnte meinen, sie hätten es beim jetzt neuen Fall besser gemacht… Haben sie?

Unimpressed reaction meme about password security

Natürlich nicht!!!

Zusätzlich wird man nun noch von seinem Provider informiert das sein Account „gefressen“ wurde und direkt gezwungen sein Kennwort zu ändern. Klappt natürlich nur bei den großen Providern. Ja OK, die meisten abgefischten Accounts liegen dort… Macht es denn noch nicht wirklich besser, oder?

Jetzt halten einige von den Pressemenschen wieder jedem dritten ihr Mikrofon unter die Nase… Dabei ergeben sich so Ideen wie: Es muss rechtliche Regelungen für so etwas geben. Zwei Wege Authentisierung usw. usw… Ob das wirklich alles so richtig ist?

Was bringt das alles wenn man Windows XP einsetzt, Java und Flash einem Sieb ähneln und die großen Provider dir beim Login erzählen das dein Adblocker die Sicherheit deines Browsers gefährdet? Dann sind wir schon bei E-Mail Made in Germany, richtig? Die Jungs hängen gerade an die große Glocke dass sie es 2014 geschafft haben TLS für ihre Verbindung einzuschalten und für die Anmeldung voraussetzten. 2014… Ich meine 2014… Das ist knapp 20 Jahre als. 2014. Die haben ihren Werbemastschweinen Kunden bis 2014 per Plaintext (also im Klartext) ein Login gestellt. Jeder hat durch bloßes hinschauen die Zugangsdaten abschreiben können. Die kommen dann mit „Sicherheit wiederherstellen“ und E-Mail Made in Germany und jetzt ist alles sicher?

Frustrated rage meme about email credential theft

Ach ich rege mich hier schon wieder auf…

Vielleicht sollte man aufhören seine Kunden auszuquetschen und mit Müll zu füttern. Hm, setzt natürlich voraus das die Kunden es wollen und vor allem mal von ihrem „kostenlos“ Ding wegkommen. Ach, ich höre nun auf, sonst habe ich für heute wieder schlechte Laune!

Siehe auch: E-Mail-Benachrichtigung bei Root-Login

Fragen? Einfach melden.

Citrix XenServer Updates manuell über Bash installieren

2. April 2014 / / Keine Kommentare

Veraltet: Citrix XenServer wird seit 2024 nicht mehr in dieser Form angeboten. Das hier beschriebene manuelle Update-Verfahren gilt für XenServer 6.x/7.x und funktioniert mit aktuellen Versionen nicht mehr. Alternativen: Proxmox VE oder XCP-ng.

Der Citrix XenServer 6.2 ist zwar nun frei, Updates lassen sich aber nicht so einfach über das XenCenter installieren. Sie werden einem zwar noch angezeigt (so weiß man zumindest welche man installieren sollte) aber einfach durchklicken ist nicht mehr.

Über die Konsole ist es denn noch schnell erledigt, wie ich hier kurz beschreiben möchte! Um die Installation per Kommandozeile zu zeigen nehme ich folgenden Patch als Beispiel: Hotfix XS61E013 – For XenServer 6.1.0 Nun aber los zur commandline action…

Zuerst den jeweiligen Patch von support.citrix.com herunterladen.

$ wget http://support.citrix.com/servlet/KbServlet/download/33649-102-705213/XS61E013.zip

Dann das Zipfile auspacken:

$ unzip XS61E013.zip
Archive:  XS61E013.zip
  inflating: XS61E013.xsupdate       
  inflating: XS61E013-src-pkgs.tar.bz2
Als nächstes das xsupdate File auf den Server kopieren:
$ scp XS61E013.xsupdate root@10.8.4.66:/update/
XS61E013.xsupdate                                                                                                                      100% 1678KB   1.6MB/s   1.6MB/s   00:00
/update/ ist dabei ein Verzeichnis auf dem Citrix XenServer, welches ich zuvor angelegt habe.

Nun auf dem XenServer als root anmelden und in das passende Verzeichnis wechseln:

$ ssh root@10.8.4.66
Last login: Wed Apr  2 17:32:12 2014 from 10.33.45.21

XenServer dom0 configuration is tuned for maximum performance and reliability.

Configuration changes which are not explicitly documented or approved by Citrix
Technical Support, may not have been tested and are therefore not supported. In
addition, configuration changes may not persist after installation of a hotfix
or upgrade, and could also cause a hotfix or upgrade to fail.

Third party tools, which require modification to dom0 configuration, or
installation into dom0, may cease to function correctly after upgrade or hotfix
installation. Please consult Citrix Technical Support for advice regarding
specific tools.

Type "xsconsole" for access to the management console.
[root@dom0-sdb35 ~]# cd /update
[root@dom0-sdb35 update]#

Ich schaue nun gerne immer zuerst welche Patches bereits installiert wurden:

[root@dom0-sdb35 update]# xe patch-list
uuid ( RO)                    : 7fd1ba20-1582-4b02-a61d-c251ad0b637c
              name-label ( RO): XS61E001
        name-description ( RO): Public Availability: fix for ISCSI multipathing
                    size ( RO): 862376
                   hosts (SRO): 427c6c42-a193-4740-8ed7-c664b5ace02c
    after-apply-guidance (SRO):

uuid ( RO)                    : c5354c77-4643-4e79-8cdf-fac914fc6c85
              name-label ( RO): XS61E003
        name-description ( RO): Public Availability: Xapi fixes
                    size ( RO): 6631433
                   hosts (SRO): 427c6c42-a193-4740-8ed7-c664b5ace02c
    after-apply-guidance (SRO): restartXAPI

uuid ( RO)

Wie man sehen kann sind auch bereits Patches eingespielt, was daran zu erkennen ist das sie dem host „zugewiesen“ sind. Um nun zuerst den gerade kopieren Patch in die Liste zu packen reicht folgender Befehl:

[root@dom0-sdb35 update]# xe patch-upload file-name=XS61E013.xsupdate
55aa7129-a5ff-4e90-899b-f89248d1182e
Und noch kontrollieren ob er in der Liste ist:
[root@dom0-sdb35 update]# xe patch-list
uuid ( RO)                    : 55aa7129-a5ff-4e90-899b-f89248d1182e
              name-label ( RO): XS61E013
        name-description ( RO): Public Availability: security fixes to Xen and xenstored
                    size ( RO): 1717976
                   hosts (SRO):
    after-apply-guidance (SRO): restartHost

Perfekt… Nun kann der Patch schon eingespielt werden. Dabei ist immer der Punkt: after-apply-guidance (SRO): zu beachten. In diesem Fall restartHost. Also am besten vorher brav alle VMs abschalten, Patch wie noch folgt einspielen und die Kiste einmal durchstarten.

[root@dom0-sdb35 update]# xe patch-apply uuid=55aa7129-a5ff-4e90-899b-f89248d1182e host-uuid=427c6c42-a193-4740-8ed7-c664b5ace02c
Preparing...                ##################################################
xen-hypervisor              ##################################################
Preparing...                ##################################################
xen-tools                   ##################################################

Etwas aufwendiger als mit dem XenCenter, denn noch gut und problemlos machbar! Ist der Patch eingespielt kann die Patch-Datei natürlich wieder vom Server gelöscht werden. Wenn sein Server direkt ins Internet darf, kann man ebenfalls direkt auf der Kiste den wget ausführen. Auf was man aber immer achten sollte ist der freie Plattenplatz. Denn wenn man so viele Updates auf die Kiste legt das dem dom0 plötzlich ein Platz mehr bleibt… Tja, dann hat man andere Probleme.

Noch Fragen?

Siehe auch: Citrix XenServer local storage größer >2TB, XenServer mit Nagios überwachen, XenServer Linux Softwareraid, Local ISO Repository

He’s Dead Jim

13. März 2014 / / Keine Kommentare

Liebe Admingemeinde, auch wir müssen hin und wieder Verluste beklagen. Heute ist wieder ein solcher Tag.
Heute hat uns ein ganz besonders lieber Freund und langjähriger Kollege verlassen. Er ist ruhig gegangen, von allen unbemerkt.
Ich bin mir sicher, er wird uns allen sehr fehlen!
Viele werden sich nun fragen… Warum er und warum so ungeöffnet?

Vergesst nie, wie sind in unserer Trauer nicht alleine.

Fragen? Einfach melden.

Postfix SSL / TLS Cipher Suite Auswertung

18. Februar 2014 / / Keine Kommentare

Nachdem ich nun am Postfix hinsichtlich der SSL / TLS Sicherheit einige Einstellungen vorgenommen habe und sogar die nutzbare Cipher Suite eingeschränkt habe, da interessiert mich natürlich welche von den Clients genutzt werden. Daher fische ich für meinen Testzeitraum einfach mal per Regex (Regular expression) und egrep ein paar Infos aus dem Logfile und lege es hier zur Begutachtung hin.

So lässt sich nun gut verfolgen, welche Cipher, wie oft genutzt wird.

 

 

Siehe auch: TLS-Infos im E-Mail-Header

Fragen? Einfach melden.

Apache: Sichere SSL/TLS-Verschlüsselung einrichten

16. Februar 2014 / / Keine Kommentare

Ich habe vor kurzem etwas über sichere SSL / TLS Einstellungen beim Mozilla Firefox geschrieben. Dabei habe ich etwas die Serveradmins in die Pflicht genommen, dafür zu sorgen dass ihre Seite so konfiguriert wird, dass erst überhaupt keine unsicheren Verfahren angeboten werden. Inzwischen sind ein paar Fragen bei mir angekommen wie ich es umgesetzt habe.

Begonnen habe ich mit dem Strict-Transport-Security Header. Sind diese gesetzt, und ein Client verbindet sich verschlüsselt (SSL / TLS) mit dem Webserver sagt ihm der Server: „Schön das du da bist. Ach ja, verbinde dich bitte die nächsten X Tage nur noch verschlüsselt mit mir, ok?“.

Normalerweise richten sich Webbrowser an diese „Bitte“ des Servers. Damit wird verhindert das ein Angreifer den Client überredet sich unverschlüsselt mit einem anderen Server zu unterhalten oder von der verschlüsselten Übertragung zur unverschlüsselten zu wechseln. Denn würde ein solcher Wechsel klappen, könnte der Angreifer ja ab dem Moment mitlesen!

Damit ich nun also die Strict-Transport-Security nutzen kann muss zuerst das Apache Modul headers aktiviert werden. Dieses erledige ich mit:

$ a2enmod headers

 Fehlt nur noch eine weitere Zeile in der vhost Konfiguration:

Header always set Strict-Transport-Security "max-age=15552000"

max-age gibt einen Zeitwert in Sekunden vor. Dieser darf/sollte nicht kleiner als 180 Tage sein. 15552000 entspricht dabei genau 180 Tagen.

Damit wird also schon mal jeder Client für die kommenden 180 Tag versuchen verschlüsselt mit mir zu sprechen. Natürlich ist an dieser Stelle zu bedenken, wenn ich mich plötzlich dazu entscheiden sollte SSL/TLS nicht mehr anzubieten, werden es die Clients denn noch weiter so probieren. Also aufpassen….

Auf zu ssl crime attack… Dieser Angriff ist möglich wenn die SSLCompression aktiviert ist. Ich erweitere also meine Konfiguration des vhosts im Apache um folgende Zeile:

SSLCompression off

Um direkt die unsicheren und veralteten Protokolle zu deaktivieren folgt auf dem Fuße:

SSLProtocol +ALL -SSLv3 -SSLv2

Damit sich gleich alle an die Reihenfolge meiner zugelassenen Cipher Suite halten, gebe ich dieses noch einmal expliziet vor:

SSLHonorCipherOrder On

Fehlen nur noch die zu verwendenden Cipher Suites…. Dabei beginne ich mit den gewünschten Favoriten und gehe Stück für Stück weiter runter. Am Ende verbiete ich noch diese, welche ich auf keinen Fall nutzen will (alles vor dem ein Ausrufezeichen „!“ steht).

SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4

 Nur noch den Apache neu starten und den aktuellen Zustand testen: https://www.ssllabs.com/ssltest/analyze.html?d=kernel-error.de

Noch Fragen? Na dann fragen!

Fragen? Einfach melden.

Unsichere SSL/TLS-Verschlüsselungen im Firefox deaktivieren

14. Februar 2014 / / Keine Kommentare

Veraltet: Die hier beschriebenen about:config-Einstellungen existieren in aktuellen Firefox-Versionen nicht mehr in dieser Form. Moderne Browser deaktivieren unsichere Protokolle und Cipher automatisch. Dieser Beitrag ist veraltet.

Nach der NSA „Geschichte“ sollte klar sein dass man mehr denn je darauf achten sollte eine möglichst sichere Verschlüsselung zu nutzen. Als Benutzer kann man leider nicht immer Einfluss auf die Gegenseite, den Server nehmen. Um denn noch etwas mehr steuern zu können, dass eine „sichere“ Verschlüsselung benutzt wird kann jeder etwas an seinem Client schrauben.

Warum? Nun ja….. Nehmen wir als Beispiel den Firefox Web Browser. Dieser unterstützt viele verschiedene Protokolle, diese noch in vielen verschiedenen Version und noch mehr Chiffrensammlungen. Die Gegenseite sollte ebenso mehrere Verfahren unterstützten. Der Hintergedanke dabei ist dass sich beide Seiten so auf ein Verfahren einigen können welches beide unterstützen. Wenn man also nun seinen Client nur Verfahren anbieten lässt, welche man als sicher erachtet… Tja, dann können sich beide nur auf ein sicheres Verfahren einigen. OK, wenn der Server nun nichts „sicheres“ anbietet, werden sie sich nicht einig werden. An dem Punkt muss man sich dann fragen ob man wirklich „unsicher“ mit der Gegenseite sprechen möchte oder nicht!

Es ist doch hin und wieder erschreckend, welche Seite nur ~schlechte~ Chipher anbieten. Hier ist wohl, wie so oft per IPv6, ein Weg zur Lösung… Nachfragen. Also den Betreibern einer solchen Seite die Frage stellen, warum geht das nicht?!?! Manche Antworten sind echt lustig.

Ich denke es gibt drei große Punkte an denen man ansetzten kann:

1. Als kleinstes Protokoll TLS1
2. RC4-Stromchiffren komplett deaktivieren
3. Perfect Forwad Secrecy (PFS) vorschreiben

1. Sorgt dafür das der Browser nur noch als sicher bekannte Protokolle nutzt.
2. Wirft die als unsicher geltende RC4 Cipher Suite raus.
3. Sorgt dafür das selbst aufgezeichnete SSL/TLS Verbindungen in der Zukunft nicht so schnell gebrochen werden können, selbst wenn die Rechenleistung deutlich zunimmt.

Im Firefox lässt sich alles schnell und sehr einfach über die Seite: about:config einrichten.

B.t.w.: TLS (Transport Layer Security) ist der Nachfolger, die Weiterentwicklung von SSL (Secure Sockets Layer). Wir sprechen also besser nur von TLS, oder? Zurück zum Text…

1. TLS Version 1.0 als kleinstes unterstütztes Protokoll.
Unter der about:config Seite in der Suche nach security.tls.version suchen. Hier den Wert security.tls.version.max auf 3 und den Wert security.tls.version.min auf 1 setzten.

2. RC4 Cipher Suite deaktivieren.
Wieder über die Suche der about:config Seite nach rc4 suchen. Nun bei allen angezeigten Zeilen den Wert auf false setzten.

3. Perfect Forwad Secrecy (PFS) vorschreiben
Erraten, about:config und die Suche benutzen. Gesucht wird security.ssl3…. Bei den Suchergebnissen nun alle Werte auf false setzten bei denen nicht ECDHE, DHE oder RC4 (wobei die RC4 „Jungs“ sollten ja bereits aus sein) in der Bezeichnung steht.

Seine Einstellungen kann man nun am besten prüfen auf: https://www.ssllabs.com/ssltest/viewMyClient.html

Ach ja…. Die Seite https://www.ausweisapp.bund.de/ kann spannenderweise nicht mehr aufgerufen werden, wenn man diese sicheren Einstellungen in seinem Browser vorschreibt. Lustig, hm?

U-P-D-A-T-E

Wem das alles etwas zu hart ist, der kann bei security.ssl3 den Wert: security.ssl3.rsa_aes_256_sha auf true lassen/setzten. Dieses würde sich zwar vielleicht mit steigender Rechenleistung entschlüsseln lassen. Ist aber aktuell noch recht sicher und wird von mehr Webseiten angeboten als nur auf Diffie Hellman zu setzten.

Oh ja, was man Serverseitig tun könnte findet sich hier…

 

ownCloud

30. Januar 2014 / / Keine Kommentare

Veraltet: ownCloud wird nicht mehr aktiv weiterentwickelt. Der Nachfolger ist Nextcloud.

Zur kurzen Beschreibung von ownCloud greife ich jetzt einfach mal ganz faul auf den ersten Absatz aus dem passenden Wikipediaartikel zurück:

### schnipp ###

ownCloud ist eine Software-Suite, die einen ortsunabhängigen Speicherbereich für Daten zur Verfügung stellt. Das Projekt wurde im Januar 2010 vom KDE-Entwickler Frank Karlitschek ins Leben gerufen, um eine freie Alternative zu kommerziellen Cloud-Anbietern zu schaffen. Im Gegensatz zu kommerziellen Speicherdiensten kann ownCloud auf einem privaten Server ohne Zusatzkosten installiert werden. Somit können gerade bei sensiblen Daten die Bedenken gegenüber einer Datenweitergabe und der damit einhergehenden Abgabe der Kontrolle über die Daten zerstreut werden.

Als Grundlage setzt das Projekt auf PHP und einer angebundenen SQLite-, MySQL- oder PostgreSQL-Datenbank. Die ownCloud kann über eine Weboberfläche bedient werden und ist dadurch nicht an ein bestimmtes Betriebssystem gebunden. Aber auch andere Anwendungen, wie beispielsweise Dateimanager oder Groupwares, können die ownCloud über eine Schnittstelle ansprechen und Dateien und Daten lokal bereitstellen.

### schnapp ###

Im Grunde lässt sich ownCloud also mit recht kleinen Grundvoraussetzungen ownCloud in Betrieb nehmen. Selbst die einfache Installation ist nicht weiter aufwendig. Natürlich hängt es immer etwas davon ab, welche Systeme man noch anbinden möchte und wie groß es am Ende wirklich werden soll.

Inzwischen gibt es für alle möglichen Clients auch Software, welche sie an ownCloud anbindet. Evolution, Thunderbird, Kmail (und Anhang), Sync-Clients für Windows/Linux/… Man kann einfach auf seine Dateien per WebDAV zugreifen usw. usw…

Man hat also seine Daten wirklich unter der eigenen Kontrolle und würfelt sie nicht irgendwo hin. Dabei ist die nötige Basis so gering dass es alles sogar über einen Raspberry Pi läuft.

OK… Es hat natürlich einen Haken. Denn es ist wie immer, wenn man selbst dafür verantwortlich ist, dann ist man auch selbst dafür verantwortlich. Alles ist dann nur so sicher wie man es selbst abgesichert hat, sich um die Patchstände kümmert und die Konfiguration vorgenommen hat.

Denn noch bietet man natürlich selbst in der Regel ein nicht ganz so attraktives Ziel wie ein großer Clouddienstleister (ich mag das Wort cloud nicht…).

Siehe auch: ownCloud und Kalender / Kontakte synchronisieren, ownCloud News-App, ownCloud und Mozilla-Sync, Davdroid ownCloud sync

Fragen? Einfach melden.

Contabo VPS

26. Januar 2014 / / Keine Kommentare

Lange habe ich nach einem ordentlichen Anbieter für einen neuen vServer gesucht. Dabei galt es folgende Kriterien zu erfüllen:

– Min. 2 IPv4 Adressen
– Ein kleines IPv6 Netz
– Unbegrenzter Traffic
– Min. 100Mbit/s Anbindung
– Min. 2 CPUs
– Min. 4 GB RAM
– Min. 200 GB HDD
– Linux als OS

Natürlich habe ich zuerst die Großen abgeklappert.

– 1und1 kein IPv6 (warum nicht? Ich meine 2014 HALLO!?!?)
– Strato nur EINE IPv6 Adresse (Ö_ö eine IPv6 Adresse…. eine?)
– Host Europe kein IPv6 bei den vServer nur bei den Root Server EINE (tz..)
– 1blue kein IPv6
– Server4you kein IPv6 beim vServer, sonst soll es wohl gehen…
– Serverloft… Joar, die Kosten sind mir zu hoch. Sind aber auch keine vServer.
– usw. usw. usw…

IPv6 scheint noch immer ein größeres Problem zu sein, ist nicht voll integriert oder ist (wie auch meherer IPv4 Adressen) hochpreisigen Produkten vorbehalten.

Dann bin ich auf Contabo gestoßen. Ich war Opfer der Werbung im Linux Magazin 🙁 Preis/Leistung sah dabei einfach zu gut aus. Daher habe ich angerufen. Ohne lange Hoteline sprach ich mit einem Menschen. Diesem stellte ich direkt meine Fragen und er konnte sie überraschenderweise direkt und sicher beantworten. Mit sicher meine ich, dass man nicht das Gefühl hatte er würde es irgendwo nachlesen oder wäre nach einer kurzen Schulung auf die Hotline losgelassen worden. Nein, es war wirklich gut!

Natürlich habe ich abschließend die Frage gestellt wie es klappt dass die angegebene Leistung so gut ist, der Support so schön zu funktionieren scheint und die Ausstattung und Randbedingungen ebenfalls so gut erscheinen. Nach hörbarem Schmunzeln bekam ich die Antwort: Das würde oft gefragt…. Ich müsse es so sehen. Contabo selbst stellt wirklich nur die Hardware und die Infrastruktur. Für das System selbst ist man selbst verantwortlich. Wenn es da mal Probleme gibt, könnte der Support zwar helfen diese wäre dann aber Kostenpflichtig (er meinte damit wenn man seine Kiste mal zerfriemelt hat). Man müsse schon wissen was man tut, dieses würden Contabo bei seinen Produkten einfach voraussetzten.

Schien also genau das zu sein was ich gesucht habe! Daher habe ich bestellt… Wobei ich genau eine solche Antwort von jedem Root-Server erwarten würde.

Alles ging schnell und für mich verständlich online. Ich bekam eine E-Mail mit der Bitte Geld zu überweisen (wer konnte damit nur rechnen. ). Kurz nach meiner Überweisung flatterten bereits die Zugangsdaten in mein Postfach.

Wie bei der Bestellung angeklickt hatte ich schon eine zweite IPv4 Adresse und konnte die PTR-Records flott im Webmenü eintragen. Um die PTR-Records der IPv6 Adressen zu ändern musste ich kurz den Support per E-Mail bemühen. Freitags um 23:36 Uhr habe ich ihn angemailt als ich morgens aufgewacht bin hatte ich schon die Bestätigung in meinem Postfach. Das System selbst ist genau wie bestellt und hat mehr Leistungsreserven als erwartet. Ich habe 8GB Arbeitsspeicher, 400Gb Festplattenplatz und zwei CPUs mit 3,4GHz. Auf der Webseite war nur etwas von 3,2GHz zu lesen. Ok ok… die paar MHz machen den Braten jetzt nicht fett, das es Core I7 CPUs sind hat mich denn noch überrascht!

Ich habe natürlich Speicher und CPU mal mit Arbeit beworfen um zu testen ob es nicht nur Schein ist. Alles prima…. Die Storage Anbindung ist ja gerne mal etwas zu genau auf den Punkt dimensioniert. Bei meinem System kann ich nicht klagen. Performance und I/Os sind wunderbar und mehr als ausreichend.

100Mbit/s sind auch 100Mbit/s… Wobei man hier auf das „Kleingedruckte“ achten muss: Keine zusätzlichen Kosten durch Traffic (bei einem Durchschnittsverbrauch über 40 Mbit/s in einem zusammenhängenden Zeitraum von mindestens 5 Tagen erfolgt eine Umstellung der Anbindung auf 10 Mbit/s).

Zu dem Thema muss ich dann wohl mal eine kleine Auswertung vom Support anfordern. Sollte doch machbar sein, oder?

Ob mich dieses noch ärgert, werde ich herausfinden. Ob mich noch mehr ärgert wird sich zeigen!

Fragen? Einfach melden.

Ping6 funktioniert nicht auf fe80-Adresse: Fehlerbehebung

15. November 2013 / / Keine Kommentare

Ja, die liebe fe80 Adressen! Wer schon mal ganz unbedarft folgendes in seine Konsole hämmert:

$ ping6 fe80::20c:42ff:fe72:2ba6
connect: Invalid argument

Wundert sich sicher im ersten Moment über die freche Antwort: „connect: Invalid argument“. ABER das ist absolut richtig. Denn wenn man mehrere Netzwerkkarten in seinem Rechner verbastelt hat, dann hat man ebenfalls mehrere fe80 link local Adressen. Nämlich mindestens eine pro Netzwerkkarte. Damit sollte es jetzt schon klingeln, hm? Noch nicht? Na woher soll das Paket den bitte wissen über welche der Netzwerkkarten es denn den Weg zur angepingten Adresse nehmen soll?!?!? Genau überhaupt nicht! Daher muss das Interface welches als „Ausgang“ genutzt werden soll immer mit angegeben werden.

$ ping6 fe80::20c:42ff:fe72:2ba6%eth0
PING fe80::20c:42ff:fe72:2ba6%eth0(fe80::20c:42ff:fe72:2ba6) 56 data bytes
64 bytes from fe80::20c:42ff:fe72:2ba6: icmp_seq=1 ttl=64 time=0.323 ms
--- fe80::20c:42ff:fe72:2ba6%eth0 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.323/0.323/0.323/0.000 ms

Unter Linux gibt man einfach %NIC-Name an und unter Windows einfach %NIC-ID:

C:\>ping -6 fe80::20c:42ff:fe72:2ba6%3

Ping wird ausgeführt für fe80::20c:42ff:fe72:2ba6%3 mit 32 Bytes Daten:
Antwort von fe80::20c:42ff:fe72:2ba6%3: Zeit<1ms
Antwort von fe80::20c:42ff:fe72:2ba6%3: Zeit<1ms

Ping-Statistik für fe80::20c:42ff:fe72:2ba6%3:
Pakete: Gesendet = 2, Empfangen = 2, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms

C:\>

Wobei ich die Meldung eines Microsoft Windows doch schnell etwas verwirrend finde. Denn hier gibt es nur die Rückmeldung dass das Zielnetz nicht erreichbar ist. Was ja im Grunde korrekt ist, nur grenzt es leider den Fehler nicht so schön ein!

C:\>ping -6 fe80::20c:42ff:fe72:2ba6

Ping wird ausgeführt für fe80::20c:42ff:fe72:2ba6 mit 32 Bytes Daten:

Zielnetz nicht erreichbar.
Zielnetz nicht erreichbar.
Zielnetz nicht erreichbar.
Zielnetz nicht erreichbar.

Ping-Statistik für fe80::20c:42ff:fe72:2ba6:
Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4 (100% Verlust),

C:\>

Japp, so einfach kann es sein.

Siehe auch: IPv6 Grundlagen

Fragen? Einfach melden.

Unsichere Protokolle und Prüfsummen am Apache2 deaktivieren

9. November 2013 / / Keine Kommentare

Im Grunde könnte es mir ja fast egal sein, welche Protokollversion und/oder Prüfsumme der Client verwendet um mit dem Server zu sprechen. Ist es denn noch nicht. Der Client verbindet sich mit dem Server. Dabei teilt der Client dem Server mit was er kann, der Server tut dieses ebenfalls. Dann einigen sich beide auf ein Protokoll und eine Prüfsumme. Dabei kann der Server wie auch der Client sagen welches ihm denn am liebsten wäre. Wenn sich nun beide für etwas unsicheres entscheiden, gehen die Daten unsicher über die Leitung 🙁

Warum also nicht dem Server sagen er soll nur die „sicheren“ Protokolle anbieten? Dieses lässt sich recht schnell erledigen, indem man in seine Apache 2 Serverkonfiguration folgendes aufnimmt:

SSLProtocol -ALL +SSLv3 +TLSv1  
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:!LOW:!SSLv2:!EXPORT

Die einzelnen Optionen sind so schön benannt, dass man sich nicht mal mehr erklären muss, oder? Denn noch verlinke ich natürlich gerne hier hin: http://httpd.apache.org/docs/2.2/mod/mod_ssl.html

Nachteile hat das ganze natürlich auch… Ältere Clients oder Systeme welche dummerweise kein passendes Protokoll / Chipher unterstützen, können keine verschlüsselte Verbindung mehr aufbauen. Meine Erfahrung zeigt aber, wenn man den Menschen die Möglichkeit gibt einfach durch die Sache zu kommen, machen sie es auch! Ich meine damit: „Solange es irgendwie funktioniert.“ Kümmert sich kaum jemand um ein Upgrade auch die Entwickler komme nicht aus dem Quark. Natürlich darf man nicht nach der Verabschiedung des neusten Standards die vorherigen fallen lassen…. Nur klar unsichere und seit Jahren überholte, die darf man dann schon mal los lassen (Windows XP *hust*).

Ach ja, möchte man einen Server testen gibt es mehrere Möglichkeiten. Am einfachsten ist sicher: https://www.ssllabs.com/ssldb/index.html Wer es lieber selbst auf der Konsole machen möchter, der freut sich sicher über sslscan http://sourceforge.net/project/showfiles.php?group_id=204329

 

 

 

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑