Autor: kernel-error (Seite 24 von 48)

Am Wochenende habe ich mal wieder den Al Bundy gegeben. Damit möchte ich sagen, ich habe den Inhalt meiner Geldbörse an meine Familie verteilt. Um heute in der Mittagspause nicht am Hungertuch nagen zu müssen, wollte ich vor der Arbeit noch schnell Geld aus dem Geldautomaten der Sparkasse in der Nähe ziehen.

 

Leide präsentierte sich die Kiste mit dem unten stehenden Bild (sorry für die schlechte Aufnahme)….

 

Lustig oder? Na ja, wie man es sieht! Auf dem Automat läuft also klar ein Microsoft Windows. Dieses hat sich auf die Nase gelegt. Fehler gibt es in jeder Software, einfach nur zu lachen und auf das „dumme“ Windows zu zeigen wäre hier wohl zu einfach.

 

Warum läuft denn auf dem Automat ein Windows? Ich denke zum Teil gutes Lobbying… Dieses wird es nur nicht alleine sein. Ich denke der laufende Support wird ebenfalls ein Thema sein (wie lange hatte so ein Windows XP noch gleich Support?).

In den letzten Tagen häufen sich die Meldungen über Google bezüglich verschlüsselter Webseiten. Zugegeben… Etwas überraschend für mich! So hat Google angekündigt künftig Webseiten, die verschlüsselt HTTPS ( also per SSL / TLS ) erreichbar sind. In seinem Ranking bei den Suchergebnissen zu bevorzugen. (HTTPS as a ranking signal)

Na da werden sich wohl einige CAs die Hände reiben und die SEOs wieder viel arbeiten haben. Hoffen wir mal das inzwischen alle Hoster SNI können, sonst wird diese Aktion sicher dem IPv4 Pool noch mal ordentlich etwas abziehen. BTW. Habe ich schon gesagt das es Zeit ist sich mit IPv6 zu beschäftigen?

Jetzt lese ich gerade das Google eine kleine Liste für seinen Browser Chrome führt. Eine Liste für HTTPS only Seiten. In genau diese Liste kann sich nun jeder mit seiner Webseite eintragen, der dafür gesorgt hat, dass seine Webseite nur per HTTPS zu erreichen ist. Dazu setzt Google auf HSTS (HTTP Strict Transport Security). Das Thema Stirct Transport Security habe ich ja bereits, unter anderem, vor einigen Wochen hier beschrieben: Apache und sichere SSL / TLS Verschlüsselung

Nun kann man sich also über diese Seite https://hstspreload.appspot.com/ in die Liste eintragen. Dabei erwartet Google zum Header max-age noch includeSubDomains und preload. Ist die Seite eingetragen bedankt sich Google und verweist als nächsten Schritt zur SSLlabs Testseite um ggf. vorhandene Probleme mit seiner SSL/TLS Konfiguration zu beheben.

Google tut dieses alles ganz sicher nicht aus Nächstenliebe, denn noch wird es die allgemeine Sicherheit, vor allem aber das Theme selbst, mehr in den Vordergrund ziehen. So wird sich vielleicht der eine oder andere „Entscheider“ nun doch mit einer positiven Rückmeldung zu dem Thema bei der IT melden!

Wie sich die grafische Logfile Auswertung für, unter anderem, Postfix um Dinge wie SPF, DKIM und DMARC erweitern lässt, habe ich ja bereits vor kurzem hier gezeigt: mailgraph Graphen um SPF, DMARC und DKIM erweitern

Seit ein paar Monaten ist an meinem Mailserver DANE aktiviert, sprich es lassen sich die TLSA RECORDS für die Zertifikate am Postfix gegen einen DNSSEC gesicherten DNS Server abgleichen.

In diesem Zuge habe ich selbstverständlich die ausgehende Prüfung am Postfix aktiviert. Mein Postfix nutzt nun also auch DANE um die Verbindung zu anderen Mailserver zu prüfen. Dabei gibt es im Grunde nur vier mögliche Ergebnisse einer Prüfung der TLS Verbindung:

Verified

Der bisher seltenste aber beste Fall. Denn die ausgehende Verbindung zum anderen Server ist per DANE gesichert. Das Zertifikat ist also nicht nur gültig sondern konnte auch mit den TLSA-RECORDS abgeglichen werden.

Trusted

Der OK Fall… Das Zertifikat ist gültig.

Anonymous

Na ja… Es gibt ein Zertifikat und dieses ist passend zum Hostname, es konnte aber keine Vertrauenskette gebildet werden.

Untrusted

Schlecht! Es gibt zwar ein Zertifikat und somit auch eine verschlüsselte Verbindung, denn noch stimmt etwas mit dem Zertifikat nicht. Es ist abgelaufen, passt nicht zum Hostname oder ähnliches.

Im Logfile findet es sich wie folgt:

Aug  3 18:34:08 servername postfix/smtp[1234]: Verified TLS connection established to mx01.domain.tld[1.2.3.4]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Aug  9 12:07:28 servername postfix/smtp[1234]: Trusted TLS connection established to mx01.domain.tld[1.2.3.4]:25: TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Aug  8 22:15:34 servername postfix/smtp[1234]: Anonymous TLS connection established to mx01.domain.tld[1.2.3.4]:25: TLSv1 with cipher ADH-AES256-SHA (256/256 bits)

Aug  7 21:48:48 servername postfix/smtp[1234]: Untrusted TLS connection established to mx01.domain.tld[1.2.3.4]:25: TLSv1.2 with cipher DHE-RSA-AES256-SHA256 (256/256 bits)

Was mich nun interessiert, ist die Tendenz der einzelnen Prüfungen. Wie sicher ist die Kommunikation zu anderen Mailservern wirklich, rein bezogen auf die Vertrauenswürdigkeit der eingesetzten Zertifikate. Eine schnelle Übersicht soll mir hier wieder der mailgraph liefern.

Den Mailgraph habe ich also, wie mit SPF, DKIM und DMARC ebenfalls, erweitert. Das nötige Patchset gibt es natürlich wieder unten. Dieses Mal habe ich darauf geachtet für die TLS Auswertung ein eigenes File für die RRD-Daten anzulegen. So kann ein bestehender Mailgraph einfach erweitert werden, ohne die vorhandenen Daten zu verlieren.

Heraus kommt am Ende dieser Graph.

Für interessiere finden sich die beiden nötigen Patchfiles hier:

/usr/sbin/mailgrapht

/usr/lib/cgi-bin/mailgraph.cgi

Viel Spaß! Bei Fragen, fragen 😀

OK ok, ein altes Thema, denn noch habe ich es gerade an der Hand und somit kommt wieder ein kleiner Beitrag dazu hier 🙂

Man kann seine Server nicht zu 100% absichern. Um im Fall der Fälle einen kleinen Anhaltspunkt zu haben, lasse ich mir vom jeweiligen Server gerne eine E-Mail schicken sobald jemand eine root-shell öffnet. Selbstverständlich ist es Schlangenöl, wenn ich es als Security Feature bezeichnen würde! Warum ich es denn noch gerne einsetzte möchte ich daher kurz erklären.

Erlangt ein Angreifer (aus welchen Gründen auch immer) erweiterte Rechte auf einem System, möchte ich ungern erst später von Kunden davon hören…. Weil Mist auf der Webseite steht oder irgendwelche Abuse-Mails bei mir aufschlagen…. Hat sich ein Angreifer erweiterte Rechte auf dem Server erarbeitet, kann er natürlich seine Aktivitäten und Anwesenheit „verschleiern“.

Verschickt das System bei jeder Eröffnung einer root shell eine E-Mail an mich, habe ich zumindest einen Anhaltspunkt. Denn wenn sich auf irgendeinem Server jemand als root anmeldet ohne das ich eine solche Anmeldung erwarten würde und dann vielleicht noch von einer IP-Adresse, welche mir komisch vorkommt, ja dann habe ich meinen Anhaltspunkt dieses zu hinterfragen!

Natürlich sollte die verschickte E-Mail nicht an den gleichen Server geschickt werden, sonst frisst der Angreifer die E-Mail auf, noch bevor ich sie lesen kann. Da die E-Mail direkt mit dem Login verschickt wird, ist sie meist schon unterwegs, noch bevor der Angreifer sie aufhalten kann. Es ist und bleibt aber Schlangenöl!!!!

Die eigentliche Befehlszeile kursiert in den gängigen Suchmaschinen. Folgendes ist also copy & paste….

Das Programm mailx sorgt dabei für den Mailversand auf der Shell. Die folgende Befehlszeile tut nichts weiter als den letzten „SSH“-Login abzugreifen, den ~Absender~ des Logins heraus zu fummeln und es mir per E-Mail zu schicken. Damit es bei jedem Start der Bash des Users Root erfolgt, landet die Zeile im Home des Roots in der Datei: /root/.bashrc

echo 'ALERT - Root Shell Access (ServerName) on:' `date` `who` | mail -s "Alert: Root Access from `who | cut -d'(' -f2 | cut -d')' -f1`" root-logins@kernel-error.com

Ich darf an der Stelle noch erwähnen, das ich meinem SSH-Server verboten habe DNS Abfragen zu tätigen. So landet in meinem Fall direkt die IP Adresse in der E-Mail und kein Hostname.

/etc/ssh/sshd_config

UseDNS no

Ein Login sorgt nun also für eine E-Mail mit folgendem Inhalt:

ALERT - Root Shell Access (dlg-srv88) on: So 3. Aug 19:28:18 CEST 2014 root pts/0 2014-08-03 19:28 (1.2.3.4)

Dieses kann nun auf gleichem Wege auf andere Benutzer ausgeweitet werden. Man könnte auch zusätzlich noch die letzten und wichtigen Logdateien anhängen. Ich denke aber es sollte nur ein Hinweis bleiben und nicht versucht werden zu einer Security Lösung ausgebaut werden, denn es greift sicher nicht in jedem Fall und es lässt sich ebenfalls aushebeln.

 

Ich habe natürlich auch Wünsche 🙂

Wer mir also einen erfüllen möchte, hier mein >>Amazon Wunschzettel<<.

Oh, ich freue mich jetzt schon auf die Erfüllung meiner Wünsche!

Ich habe im März 2014 meine Stelle beim alten Arbeitgeber gekündigt und starte am 01.08.2014 in eine neue Anstellung bei einem Unternehmen in der Nähe von Bonn. Oh, ich bin schon so gespannt. Man könnte sagen ich kann es kaum abwarten! Was ich bisher gesehen und gehört habe klingt mehr als spannend. Mein letzter Tag beim alten Arbeitgeber ist der 31.07, es wird also ein flotter Übergang. Warum habe ich noch gleich meinen Resturlaub nicht eingesetzt?!?!

In diesem Zusammenhang habe ich auch dem Ruhrgebiet den Rücken gekehrt und bin nach Meckenheim gezogen. Die LUG in Bonn kenne ich bereits, fehlt mir noch ein Hackerspace in der Nähe 😀 Ich bin also für Anregungen offen!

Da hocke ich heute mal wieder im DataCenter und arbeite an den Systemen. Wie immer, im Schneidersitz auf dem Boden und mit den Notebook auf den Beinen. Nach einiger Zeit merke ich, dass mein Hintern aufgehört hat sich über die Temperatur zu beschweren. Dieses ist in der Regel ein untrügerisches Zeichen dafür, dass er eingeschlafen ist. Was nun Vor- und Nachteile hat. Vorteil, ich kann noch länger so sitzen ohne das es fühlbar unbequem wird; Nachteil, wenn ich später versuche aufzustehen, wird es lustig!

Das muss doch irgendwie besser gehen, oder? OK, ok… Es gibt in der Regel einen hässlichen Hocker, der ist aber so hässlich das man doch besser auf dem Boden sitzt, weil es dann doch bequemer ist. Dann könnte ich mir noch ein Kissen mitbringen und es unterlegen. O_o ne, doch nicht! Wenn ich so überlege dann finden sich in meiner Erinnerung nur Bilder, von auf dem Boden hockenden Technikern vor einem Schrank. Alle mit kaltem Hintern und jedem schläft dieser früher oder später ein. Da sollte mal jemand was erfinden *AUFRUF*.

Wie auch immer, wenn ich mir schon über solche Dinge Gedanken mache… Dann kann es mir nicht so schlecht gehen, oder vielleicht genau aus diesem Grund doch? Na dann werde ich wohl nun mal jemanden aufwecken, wünscht mir Glück.

Das ärgert mich aber jetzt… Es hat ja tatsächlich einige Zeit gedauert, bis ich mich überhaupt zu so einem SmartPhone habe hinreißen lassen. Zu dem Zeitpunkt habe ich mich für das Samsung Galaxy SII entschieden. Es läuft seit ein paar Jahren ganz tadellos, vor allem mit dem CM 11 CyanogenMod. Vor kurzem stellte ich dann fest, dass mein Akku nicht mehr den ganzen Tag (viel mehr war eh nie drin) gehalten hat. Warum die Batterie so schnell leer war habe ich aber nicht kontrolliert. Es ging so schleichend, dass ich es nicht direkt war genommen habe. Irgendwann war es dann so massiv, dass ich es nicht weiter ignorieren konnte. Zuerst dachte ich natürlich an den Akku selbst. Dieser hatte ja bereits zwei Jahre auf dem Rücken und das Handy wurde beim Laden besonders warm, um nicht zu sagen heiß. Ein originaler Samsung Akku (zumindest hoffe ich das er original ist), war über eBay schnell und günstig zu bekommen. Leider änderte sich mit diesem nichts.
Ich habe dann davon gelesen, dass Dreck an der USB-Buchse zu Kriechströmen führen kann und diese dann den Akku schnell leersaugen. Also die Buchse gereinigt, bracht ebenfalls nix. Netzteil getauscht => nix :-/
Ich habe also das Gerät einmal aufgeschraubt, was verdächtig einfach ging. Inzwischen verbrannte das Gerät nämlich selbst im abgeschalteten Zustand so viel Strom (in Wärme), dass es trotz angeschlossenem Ladegerät nicht mehr reichte den Akku zu laden. Ich wollte herausfinden welches Bauteil da wohl so viel Hitze erzeugt. Unter einer Schirmung mit der Aufschrift GT-I9100 #4 vermutete ich die Quelle zuerst, es zeigt sich später aber dass es der IC auf der anderen Seite des Mainboards war, mit der Aufschrift: SWB-B42. Das ist der IC für Wi-Fi, Bluetooth und FM Radio BCM4330.
Meine Hoffnung dass nur die nahe, auf dem Mainboard, verlötete CMOS Batterie ein Problem hatte, war also dahin. Was also tun? Den IC bekommt man für ca. 15$ + Porto zu kaufen. Sagen wir mal mit drei Wochen Zeit und 30€ Einsatz ist dieses machbar. Dann könnte man mit etwas Heißluft den alten IC lösen und den neuen auflöten. Viel Arbeit und gemacht haben sollte man es ebenfalls schon mal. Ich habe mich daher entschlossen einfach ein neues Mainboard zu kaufen. Neue… Nun, neu liege ich auch bei 150 bis 200€. Zu teuer! Ich habe (wieder auf eBay) ein Samsung Galaxy S2 gefunden, eines mit def. Display. Ist wohl jemand draufgetreten, oder so etwas 😛 Egal… Dieses Teil gab es für 50€. Ich habe es gekauft und einfach das Mainboard getauscht.
Tja, was soll ich sagen? Es funktioniert  😀 So bleibt mir mein Samsung Galaxy SII wohl doch noch etwas erhalten!