-=Kernel-Error=-

Datenhaufen zu IT und Elektronik.

Autor: kernel-error (Seite 12 von 47)

Wunderbarer Kreisschneider für die Holzwerkstatt: Ein Muss für Handwerker

13. Juni 2018 / / Keine Kommentare

Heute mal etwas komplett weg von der IT, ok?

Gerne lasse ich mich von guten Werkzeug beeindrucken. Heute ist es mal wieder so weit: Mein neuer Kreisschneider ist mit der Post gekommen. Es war selbst 2018 überhaupt nicht so einfach ihn zu bekommen, denn das Teil ist immer schneller ausverkauft als der Hersteller es nachliefern kann. Eingekauft habe ich es hier: www.feinewerkzeuge.de Es gibt sehr ähnliche Kreisschneider ebenfalls bei Amazon und hier scheinen viele ebenfalls sehr zufrieden zu sein.

Möchte man ein Loch in Holz haben greift man am besten zu einem Bohrer, soll das Loch größer werden kommt man zu einem Forstnerbohrer und wenn es noch größer werden soll… Na, dann habe ich bisher zu einem Topfkreisbohrer oder ähnlichem gegriffen. Für einen ordentlichen Topfkreisbohrer zahlt man schnell 40 – 100 €. Aber selbst dann hat man ähnliche Probleme, wie mit billigen Topfkreisbohrern; Das Holz „verbrennt“ schnell, selbst bei der passenden Geschwindigkeit, es reißt aus und man bekommt das ausgeschnittene Stück nicht aus dem heißen Bohrkopf. Mit viel Übung, Mühe und gutem Werkzeug kann man diese Probleme natürlich verringern. Möchte man möglichst verschiedene Lochgrößen abdecken hat man fast ein kleines Vermögen in der Hobbywerkstatt liegen und braucht es vielleicht nur 2 – 3 mal im Jahr und natürlich hat man dann doch keine passende Größe. Es ist genau 1mm zu klein oder 1mm zu groß. Also kleiner und dann schleifen/pfeilen. So wird man die „Brandstellen“ gleich mit los, SUUUUUPPPER; nein doch nicht O_o

Irgendwann hat mir ein Bekannter mal zu diesem Kreisschneider hier geraten (STAR-M Kreisschneider Nr. 36 HSS). Er lässt sich komplett Stufenlos einstellen, ich habe also immer die passende Größe. Die Messer, der Bohrer/Zentrierspitze lassen sich jeweils einfach und günstig austauschen, wobei das ganze Teil gut bezahlbar ist. Da es nur zwei kleine Messer gibt, ist der Spanauswurf top und es gibt viel weniger Reibung. Weniger Reibung = weniger Temperatur! Zudem hängen die Messer in dicken Metallhaltern, welche zusammen mit der Bewegung die Temperatur sehr gut abführen. Die Japaner wissen einfach wie man gutes Holzwerkzeug baut 🙂

Noch ein paar Bilder für euch, ich habe hier eine 18mm Leimholzplatte aus Buche „gelocht“:

Kein TLS 1.0 mehr

8. Juni 2018 / / Keine Kommentare

Da TLS 1.0 zum 30.06.2018 aus dem PCI Support fliegt (was nach knapp 19 Jahren auch mal ok ist), habe ich bei mir gerade überall den TLSv1.0 Support deaktiviert. Nein ich möchte nicht PCI konform sein… Damit sorge ich nun wieder einmal dafür, dass man mich mit einiger alter Software/Hardware und Betriebssystemen nicht mehr erreicht. Für mich ganz persönlich kann ich damit sehr gut leben 🙂 Wer jetzt noch mit so einer „Kiste“ unterwegs ist…. Na, der ist Kummer gewohnt!

Wen es interessiert der kann mit Qualys SSL Labs alles Mögliche scannen und auch direkt sehen welche Systeme wohl bei einem selbst nicht mehr funktionieren werden.

Zusätzlich spiele ich schon länger mit dem Gedanken bei meinem Mailserver Übertragungen ohne Transportverschlüsselung komplett zu verbieten. Für mich selbst kann ich es ja frei entscheiden. Lieber keine E-Mail als eine ohne Krypto! Ich werde mal auswerten wie denn das Verhältnis ist und welche E-Mails mich nicht mehr erreichen würden. Dann sehen wir mal weiter! Ich bin nur deswegen etwas zögerlich, weil mir in der Vergangenheit immer mal wieder Gegenstellen unter die Nase gekommen sind, bei welchen ich fest davon ausgegangen wäre, dass sie TLS einsetzten. Städte, Krankenhäuser, Ärzte, Schulen, IT-Security Dienstleister usw. usw… Hier scheint noch immer Unverständnis darüber zu herrschen, für was man denn wohl bitte dieses TLS braucht. Der Dienstleister meiner Heimatstadt begrüßt mich zumindest inzwischen mit einem Cisco Demo Zertifikat. *kopfschüttel* da hat der Admin nach meinen letzten Fragen zu dem Thema wohl den „security ON Button“ in seiner GUI gefunden O_o

Wobei… Mein Brötchengeber setzt auf einen eigenen Exchange Server bei welchem zuletzt 3DES Cipher abgeschaltet werden mussten. Das macht keinen Spaß und keinen Sinn. Windows-Admins scheinen hier schmerzfrei zu sein, hm?

TLS 1.3, das wäre ja mal was 🙂 ich warte schon mit schwitzigen Fingern. Zumindest sind wir schon mal bei Beta 5 (29.05.2018). Die Beta 1 vom 20.03 habe ich mir zuletzt in einer Jail angesehen und damit sehr zufrieden etwas herumprobiert. Für so etwas bin ich einfach zu ungeduldig. Ist das bei euch anders? Wollt ihr lieber noch TLSv1.0 haben?

TLS 1 ist tot und damit ist es dann jetzt weg, egal ob im stunnel:

;/usr/local/etc/stunnel/conf.d/tls.conf
[...]
options = NO_SSLv3
options = NO_TLSv1
ciphers = ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DHE-RSA-AES256-SHA256
[...]

Oder unter Postfix:

#/usr/local/etc/postfix/main.cf
[...]
smtp_tls_protocols = TLSv1.2, TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtp_tls_ciphers = high
smtp_tls_mandatory_exclude_ciphers = MD5, DES, ADH, RC4, PSD, SRP, 3DES, eNULL, aNULL
smtp_tls_exclude_ciphers = MD5, DES, ADH, RC4, PSD, SRP, 3DES, eNULL, aNULL
smtp_tls_security_level = dane
smtp_dns_support_level = dnssec
smtp_tls_loglevel = 1
smtp_tls_mandatory_protocols = TLSv1.2, TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtp_tls_mandatory_ciphers = high
tls_preempt_cipherlist = yes
tls_random_source = dev:/dev/urandom
smtpd_tls_loglevel = 1 
smtpd_tls_received_header = yes
smtpd_use_tls = yes
smtpd_tls_security_level = may
smtpd_tls_auth_only = yes
smtpd_tls_key_file = /usr/local/etc/postfix/postfix.key
smtpd_tls_cert_file = /usr/local/etc/postfix/postfix.pem
smtpd_tls_session_cache_timeout = 3600s
smtpd_tls_mandatory_exclude_ciphers = MD5, DES, ADH, RC4, PSD, SRP, 3DES, eNULL, aNULL
smtpd_tls_exclude_ciphers = MD5, DES, ADH, RC4, PSD, SRP, 3DES, eNULL, aNULL
smtpd_tls_mandatory_ciphers = high
smtpd_tls_ciphers = high
smtpd_tls_mandatory_protocols = TLSv1.2, TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtpd_tls_protocols = TLSv1.2, TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtpd_tls_dh1024_param_file = /usr/local/etc/postfix/dh2048.pem
[...]

Oder auch im Dovecot:

#/usr/local/etc/dovecot/conf.d/10-ssl.conf
[...]
ssl = required
ssl_dh_parameters_length = 4096
ssl_protocols = !SSLv3 !SSLv2 !TLSv1
ssl_cipher_list = AES128+EECDH:AES128+EDH
ssl_prefer_server_ciphers = yes
[...]

Selbstverständlich auch im Nginx:

#/usr/local/etc/nginx/nginx.conf
[...]
ssl_stapling on;
ssl_stapling_verify on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
ssl_ecdh_curve secp521r1:secp384r1:secp256k1;
ssl_dhparam /usr/local/etc/nginx/ssl/dhparam.pem;
ssl_protocols TLSv1.1 TLSv1.2;
[...]

Und so weiter und so weiter 🙂

BGP und wie sicher ist das Internet?

31. Mai 2018 / / Keine Kommentare

Das Internet funktioniert nicht, wie euer normales Netzwerk zuhause. Es basiert in den weitesten Teilen auf BGP, dem Border Gateway Protocol. Natürlich kann es auch dabei zu Problemen kommen, mal macht ein Mensch einen Fehler, mal Hardware oder Software oder eine Regierung möchte etwas „blockieren“… Naja, oder die bösen Hacker halt.

Unter folgendem Link, werden BGP Probleme visualisiert und mit einer Historie versehen:

https://bgpstream.com/

Klickt unbedingt auch mal auf „More detail“ bei einem Event und schaut euch das Replay an, das ist nicht nur interessant, sondern auch lehrreich. Viel besser zu verstehen, als wenn man nur die BGP Events im Log fliegen sieht!

So long..

Jabber / XMPP R.I.P.

31. Mai 2018 / / Keine Kommentare

Ich habe gerade eben meinen Openfire abgeschaltet und werde ihn nicht mehr einschalten. Jabber / XMPP war eine wirklich schöne Möglichkeit der Kommunikation. Der Aufwand SPAM zu filtern und das Teil selbst zu betreiben steht aber inzwischen einfach in keinem Verhältnis mehr. Zudem hat sich Jabber nur minimal weiterentwickelt. Inzwischen ist es von vielen schönen Lösungen überholt worden.

Meine Kommunikation läuft inzwischen mehr über Matrix/Riot oder Slack Chat als über Jabber.

TLS 1.0 nur noch bis 30. Juni 2018 im PCI-Support: Was du wissen musst

15. Mai 2018 / / Keine Kommentare

Hallo zusammen,

sicher ist das schon bekannt aber damit ich es auch einmal geschrieben habe. Das PCI hat eine Deadline zum 30 Juni 2018 für den Support von TLS 1.0 gesetzt.

TLS 1.0 ist ab dem Moment „noch“ so gut wie vorher und es sollte kein Problem für uns alle sein aber alles was PCI konform sein möchte darf ab dann kein TLS 1.0 mehr einsetzten.

https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls

Nicht das ich PCI konform wäre *lach* aber es ist bei mir deaktiviert:

https://www.ssllabs.com/ssltest/analyze.html?d=www.kernel%2derror.de&latest

https://www.htbridge.com/ssl/?id=Cq6PBF3g

So long….

Screenshot der RackTables-Seite zur IP SLB-Konfiguration

Loadbalancer IP (SLB) in RackTables anlegen: Schritt-für-Schritt-Anleitung

22. März 2018 / / Keine Kommentare

Racktables ist zur Dokumentation seiner Assets im Rack nicht das schlechteste Tool. Es hat ganz klar seine Grenzen aber oft erfüllt es die Anforderungen.

Wie füge ich in Racktables einen Load Balancer hinzu? Vor dieser Frage stand ich vor einiger Zeit. Mein erster Anlaufpunkt war natürlich das Racktables Wiki. Leider wurde ich daraus nicht wirklich schlauer. Die google Suche: „How to add LoadBalancers to racktables“ hat mir ebenfalls nicht geholfen. Irgendwann bin ich auf den Hinweis zur User Interfaceconfiguration „IPV4LB_LISTSRC“ gestoßen. Ab da öffneten sich meine Augen 🙂

Die Option ist im default mit einem false deaktiviert. Aktiviert man sie mit einem einfachen true, tauchen einfach alle Hardwareserver als Load Balancer unter IP SLB ==> Load balancers auf. Das ist fast gut. Fast… ja fast weil dort eigentlich nur die Load-Balancer auftauchen sollten. Da kam mir die Funktion der Tags in den Sinn. Nach diesen lässt sich bei Racktables nicht nur filtern, sondern man kann darauf aufbauend auch Dinge im Interface umorganisieren. Einfachstes Beispiel ist sicher der Tag „Poweroff“, welcher ausgeschaltete Systeme in der Rackübersicht andersfarbig darstellt, wenn man dem Tag eine andere Farbe zugewiesen hat.

Genau so bekommt man nun ebenfalls die Load balancers ins IP SLB von Racktables. Als erstes legt man also einen Tag an, der jedem Load balancer zugewiesen wird: Configuration ==> Tag tree ==> Edit tree

Nun weißt man dieses Tag dem jeweiligen Load Balancer Object zu.

Screenshot der RackTables-Seite zur IP SLB-Konfiguration - View

Nun geht es weiter unter Configuration ==> User Interface ==> Change

Screenshot der RackTables-Seite zur IP SLB-Konfiguration - User Interface

Dort muss die Option IPV4LB_LISTSRC so geändert werden, dass unser neues Tag in geschweiften Klammern steht. In meinem Beispiel ist es das Tag LoadBalancer und dieses findet sich wie folgt in der Konfiguration:

Screenshot der RackTables-Seite zur IP SLB-Konfiguration - IPV4LB_LISTSRC

Das war es auch schon. Ab jetzt wird jedes Object unter Racktables ==> IP SLB ==> Load balancers auftauchen, welches das Tag LoadBalancer bekommen hat.

Screenshot der RackTables-Seite zur IP SLB-Konfiguration - Load balancers

Wenn man es einmal verstanden hat, ganz einfach oder? Viel Spaß 😀

IT Trends Sicherheit 2018 in Bochum

21. März 2018 / / Keine Kommentare

Ich bin heute der Einladung von TMR zu den IT Trends Sicherheit 2018 ins Stadion nach Bochum gefolgt.

Nach der Begrüßung und den Keynotes sitze ich nun im zweiten Vortrag meiner Wahl. Bisher alles ok, was mir aber wieder im direkten Vergleich zu einem Vortrag in Club oder einer OpenSource Messe auffällt ist dieser doch starke Eindruck einer Verkaufsveranstaltung. Ok das ist zu erwarten und auch in Ordnung. Auf vielen OpenSource Messe wandert es ebenfalls immer mehr in diese Richtung, es fällt mir nur gerade sehr auf.

Viele Informationen sind dennoch wertvoll und neue Kontakte können ebenfalls nicht schaden.

SSD Secure Erase mit FreeBSD: So löschst du deine SSD sicher

20. März 2018 / / Ein Kommentar

Um alle Daten einer SSD möglichst sicher zu löschen gibt es im ATA die Funktion: „ATA Secure Erase“. Möchte man nun seine SSD schnell und einfach von allen Daten befreien (dd mit Nullen ist ja eher eine schlechte und nicht funktionsfähige Möglichkeit bei SSDs), nutzt man einfach diese Funktion.

Bei einem FreeBSD sieht dieses unter optimalen Bedingungen wie folgt aus:

root@sun-wks:/usr/home/kernel # camcontrol security ada4 -s Erase -e Erase
pass7: <OCZ-AGILITY3 2.15> ATA8-ACS SATA 3.x device
pass7: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)

You are about to ERASE ALL DATA from the following device:
pass7,ada4: <OCZ-AGILITY3 2.15> ATA8-ACS SATA 3.x device

Are you SURE you want to ERASE ALL DATA? (yes/no) yes
Issuing SECURITY_SET_PASSWORD password='Erase', user='master', mode='high'
Issuing SECURITY_ERASE_PREPARE
Issuing SECURITY_ERASE_UNIT password='Erase', user='master'

Erase Complete

Optimale Bedingungen?

Das eine oder andere BIOS „schützt“ die Festplatten vor dieser Funktion und sorgt dafür das sie nicht genutzt werden kann. Hier hilft es die Platte erst nach dem Boot anzuschließen. Um die Funktion nutzen zu können muss der SSD ebenfalls erst ein Kennwort gegeben werden. Ohne gesetztes Kennwort kann die Funktion ebenfalls nicht genutzt werden. Ich habe dieses in einem Abwasch erledigt indem ich erst das Kennwort und dann direkt die Funktion mit dem gesetzten Kennwort aufrufe (-s Erase -e Erase) Erase ist also in meinem Beispiel das gesetzte Kennwort.

Da wir gerade dabei sind… Viele SSDs habe eine Art „Selbstheilungsmodus“… Ist diese aktiviert prüft sich die SSD selbst und repariert sich, soweit möglich. Dieser Modus wird aktiviert wenn die SSD am Strom aber nicht am Datenbus angeschlossen ist. Bedeutet. SATA/SAS Kabel abziehen. Strom anschließen/einschalten und warten. In der Regel sollten SSDs nach knapp 4 Stunden mit ihrer „Selbstheilung“ fertig sein. Dieses lässt sich natürlich im Anschluss noch einmal wiederholen. Funktioniert die SSD nach zwei Durchläufen noch nicht wie gewünscht, wird sie wohl wirklich kaputt sein.

Fragen? Dann Fragen 😀

Telekom SmartHome: Firmware-Updates für Homematic-Geräte von EQ-3

12. Januar 2018 / / Keine Kommentare

Da sich mit der Homebase von Qivicon die Geräte von eQ-3 nicht mit neuer Firmware betanken lassen hatte/habe ich noch immer gewisse Bedenken was Updates angeht. Gestartet habe ich meinen Test nur mit den einfachen HomeMatic Geräten, einfach weil es die IP-Geräte noch nicht gab. Auf der Webseite von eQ-3 habe ich dabei immer geprüft welche Firmware-Updates es für die jeweiligen Geräte gibt. Es gab bisher extrem wenige Updates und diese lösten keine „spannenden“ Probleme. Inzwischen habe ich mehr von den neuen HomeMatic IP Geräten im Einsatz. Hier sieht es schon etwas anders aus… Die Firmware dieser Geräte ändert sich oft und macht ganz schöne Sprünge. Einmal werden die Funktionen immer mehr erweitert. So fungiert zum Beispiel ein Zwischenstecker als eine Art Repeater/Router. Dieses erst ab einem bestimmten Firmwarestand…. Dann werden Bug gefixt welche oft für einen reibungsloseren Betrieb sorgen sollen.

Zum Updaten gibt es zwei brauchbare Lösungen. Einmal einen Funk-Konfigurationsstick USB und natürlich über die eigene Zentrale von eQ-3. Dieses CCU2 habe ich mir nun besorgt und habe angefangen den HomeMatic IP Geräten eine neue Firmware zur Verfügung zu stellen. Das Update sieht dabei immer so aus:

Gerät vom Telekom SmartHome System ablernen ==> Gerät an der CCU2 Basis anlernen ==> Firmware Update durchführen ==> Geräte von der CCU2 Basis ablernen ==> Gerät am Telekom SmartHome System anlernen.

Das liest sich nicht nur sehr aufwendig, dieses ist es ebenfalls. Warum jetzt nicht gleich komplett auf die CCU2 Basis und einfach irgendeine andere Lösung wie Orbylon / EASY App oder pocket control HM? Einmal weil das Geräteangebot um die einzelnen Lösungen für mich nicht ausreichend/passend ist und weil der woman acceptance factor nicht immer getroffen wird. Das System von Qivicon / Telekom hat „leider“ noch immer den großen Vorteil, dass man die verschiedensten Hersteller von SmartHome Geräten miteinander kombinieren kann :-/

Leider benötigt das Update der Firmware auf den HomeMatic IP Geräten zwischen 8 und 42 Stunden!!!! Die Firmware liegt dabei immer knapp über 100KB…. Bei den einfachen HomeMatic Geräten hat die Firmware eine ähnliche Größe, das Update der Firmware ist hier aber in 5 Min erledigt. 8 bis 42 Stunden O_o Ich muss doch mal lesen warum das SOOOOO langsam ist. Oder kann es mir schnell jemand erklären?

« Ältere Beiträge Neuere Beiträge »

© 2025 -=Kernel-Error=-

Theme von Anders Norén — Hoch ↑