Einigen sehr aufmerksamen Bloglesern ist es ja inzwischen aufgefallen. Ja ich habe meine Schlüssel getauscht.
Fragen? Einfach melden.
IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.
Server selbst betreiben — Erfahrungen mit FreeBSD-Jails, Nginx, Postfix, Dovecot, Matrix und der eigenen Infrastruktur.
Einigen sehr aufmerksamen Bloglesern ist es ja inzwischen aufgefallen. Ja ich habe meine Schlüssel getauscht.
Fragen? Einfach melden.
Upgrade von Piwigo 2.8 auf 2.9 geklickt, schien sauber durchgelaufen zu sein. Danach zeigte die Galerie nur noch eine Fehlermeldung.
Warning: [mysql error 1054] Unknown column 'last_visit' in 'field list'
UPDATE piwigo_user_infos
SET last_visit = NOW(),
lastmodified = lastmodified
WHERE user_id = 1
Die Spalte last_visit existierte nicht. Ein Blick ins Nginx-Error-Log zeigte, dass der Fehler schon während des Upgrades auftrat:
ALTER TABLE `piwigo_user_infos`
ADD COLUMN `last_visit` datetime default NULL,
ADD COLUMN `last_visit_from_history` enum('true','false') NOT NULL default 'false'
;
Das ALTER TABLE war beim Upgrade aus irgendeinem Grund fehlgeschlagen. Die Datenbank-Migration ist abgesoffen.
Die fehlenden Statements aus dem Upgrade-Script herausgesucht und von Hand auf die Datenbank losgelassen:
ALTER TABLE `piwigo_comments` CHANGE `date` `date` datetime NOT NULL default '1970-01-01 00:00:00';
ALTER TABLE `piwigo_history` CHANGE `date` `date` date NOT NULL default '1970-01-01';
ALTER TABLE `piwigo_images` CHANGE `date_available` `date_available` datetime NOT NULL default '1970-01-01 00:00:00';
ALTER TABLE `piwigo_old_permalinks` CHANGE `date_deleted` `date_deleted` datetime NOT NULL default '1970-01-01 00:00:00';
ALTER TABLE `piwigo_rate` CHANGE `date` `date` date NOT NULL default '1970-01-01';
ALTER TABLE `piwigo_sessions` CHANGE `expiration` `expiration` datetime NOT NULL default '1970-01-01 00:00:00';
ALTER TABLE `piwigo_upgrade` CHANGE `applied` `applied` datetime NOT NULL default '1970-01-01 00:00:00';
ALTER TABLE `piwigo_user_infos` CHANGE `registration_date` `registration_date` datetime NOT NULL default '1970-01-01 00:00:00';
ALTER TABLE `piwigo_user_infos`
ADD COLUMN `last_visit` datetime default NULL,
ADD COLUMN `last_visit_from_history` enum('true','false') NOT NULL default 'false'
;
Danach lief alles wieder. Lektion: Nach einem Piwigo-Upgrade immer prüfen, ob die Datenbank-Migration vollständig durchgelaufen ist. Im Zweifel ins Error-Log schauen.
Siehe auch: Umzug auf FreeBSD/Nginx
Fragen? Einfach melden.
Ich teste im Moment matrix als Basis für die Kommunikation. Client ist dabei Riot auf Android und iOS und als Server probiere ich im moment Synapse aus. Alles unter der Domain: https://matrix.kernel-error.com
Beim Identiy Server bin ich einfach mal bei https://matrix.org geblieben! Alles ist noch sehr beta. Dafür tut es aber schon ganz ordentlich. Schreiben und Dateien verschicken funktioniert problemlos. Videocalls gehen so mäßig. Das Bild hängt halt immer mal wieder. Einfache Voicecalls klappten dafür richtig gut, sowohl zu zweit als auch in der Konferenz.
Etwas hakelig war das Einfügen von E-Mail Adresse und Rufnummer über den Andoid Client… Das war etwas verwirred. Hier ist der Workflow und die UI auf dem iOS besser. Insg. tut es aber….
Zuletzt habe ich nun den nginx als proxy for den matrix-synapse Server gesetzt. Dem vertraue ich an der Stelle einfach etwas mehr. Oh es läuft in einer FreeBSD 11 jail und dort auch recht Problemlos.
Sobald es mehr zu berichten gibt schreibe ich mehr! Wer es ebenfalls nutzt und mich anschreiben möchte: @kernel:matrix.kernel-error.com
So long…
Siehe auch: Eigenen Jabber-Server betreiben
Fragen? Einfach melden.
Sobald man einen standard Dienst im Netz stehen hat wird dieser auch von verschiedenen Bots abgegrabbelt. Diese testen nach ungepatchten Versionen mit nutzbaren Sicherheitslöchern oder gehen Rainbow Tables durch. Gegen Sicherheitslöcher hilft ein Patchmanagement gegen Rainbow Tables helfen gute Kennwörter und ein Schutz gegen Brute-Force…. Einfach ist hier zum Beispiel der fail2ban Ansatz. Einfach mit zählen wie viele Fehlerhafte Logins in einem gewissen Zeitraum von einer IP-Adresse kommen und dann direkt die IP-Adresse für einen gewissen Zeitraum sperren.
Jetzt sind die Entwickler der Bots nicht dumm… Zuerst haben diese Bots genau so angefangen. Erstmal alle möglichen Kennwörter durchprobieren. Als ersten Schutz natürlich fail2ban, dann haben die Bots angefangen nicht mehr als genau drei Anfragen von einer IP Adresse zu stellen, etwas warten und dann wieder drei Anfragen. Man musste also im fail2ban „nachstellen“. Nun sind wir schon beim Punkt das diese Anfragen nicht mehr gebündelt als Dreierblock kommen sondern immer nur eine Anfrage von einer Adresse und 2 – 3 Stunden später erst wieder von dieser Adresse. Der einzelne Bot würde also Jahrzehnte brauchen um einige Versuche durch zugehen! Wenn er sich mit vielen anderen Abspricht, werden in kurzer Zeit noch immer sehr viele Kombinationen durchprobiert. Also wieder nachrüsten… Zwei Faktor, „Lebenderkennung“, Zertifikatslogin usw… Damit hat man sicher erst mal etwas Ruhe. OK, hier gibt es ebenfalls Möglichkeiten nur gibt es sicher genug schlechter gesicherte Ziele die zuerst angegangen werden können!
Siehe auch: SSH-Server absichern mit MFA
Fragen? Einfach melden.
Wie angekündigt habe ich nun meinen Apachen in den Ruhestand geschickt… Damit ist nun also ebenfalls mein Webserver auf FreeBSD und ebenfalls auf NGINX.
Siehe auch: HTTP/3 und QUIC
Fragen? Einfach melden.
Ihr erinnert euch doch sicher noch an meinen Bla zum BSI und nextcloud, oder? ==> Die Jungs vom BSI und nextcloud
Inzwischen ist der Scanner wohl für jeden einfach nutzbar… So wie man es von Qualys oder ähnlichem kennt. Einfach mal hier klicken: https://scan.nextcloud.com/ und fröhlich scannen.
Solche Scanner haben ja auch schon irgendwie etwas für sich, oder? Ein A+ sollte wohl für den Moment jeder ohne weitere Probleme erreichen können!
So long…
Siehe auch: MTA-STS einrichten
Fragen? Einfach melden.
Tach zusammen,
StartSSL ist ja aktuell einfach tot 🙁 Eine für mich sinnvolle Alternative konnte ich aber nicht finden. Eine Wildcard Zertifikat für meine Domains und dann einfach überall das gleiche *grusel* aber 10000 € ausgeben um sonst meine Wünsche zu erfüllen macht auch keinen Sinn. Tja bleibt Let’s Encrypt…. Gott, ich will nicht alle drei Monate neue Zertifikate bauen. Das ist Käse, vor allem mit TLSA/DANE, HPKP usw. *brech*
Für jetzt bin ich dennoch dazu gezwungen auf Let’s Encrypt zu wechseln. Es wird also ein solches Zertifikat hier geben. Ich hoffe nun einfach darauf, dass StartSSL wieder in die Browser kommt. 01.06.2017 soll es da wohl weiter gehen, hm?
https://bugzilla.mozilla.org/show_bug.cgi?id=1311832
https://startssl.com/NewsDetails?date=20160919
Klar ist jetzt dieser China CA zu vertrauen? Nö… Nur bis zu einem gewissen Punkt und ab dann halt HPKP, TLSA/DANE, DNS CAA. Was mir so gut gefällt ist die Möglichkeit für einen vertretbaren Preis so viele unterschiedliche Zertifikate raus zu hauen, wie ich es für richtig halte.
Also kommt nun Let’s Encrypt als „hoffentlich Übergang“ und dann wieder StartSSL oder jemand von euch hat eine gute Idee für mich?
So long…
Siehe auch: Von RSA zu ECDSA
Fragen? Einfach melden.
Inzwischen bin ich etwas weiter. Ich nutze nun einen sauberen Filter um SPAM von meinem Jabberserver fern zu halten. \o/ Somit habe ich die Block der besonders auffälligen xmpp-server zurückgezogen. So gefällt mir die Lösung schon viel besser.
Siehe auch: Eigenen Jabber-Server betreiben
Fragen? Einfach melden.
Aktuell beobachte ich sehr für SPAM mit teils russsichem Inhalt zu Exploits und ähnlichem, der von vielen verschiedenen Domains bei meinem Server ankommt.
Die Admins dieser Server kommen zum Teil aktuell nicht mit dem Aussortieren der Spamaccounts nach. Ich selbst habe ebenfalls schon viele Anmeldeversuche dieser Spamaccounts bewundert. Diese werden automatisch erstellt, dann etwas später wird darüber ein einem riesigen Schwung versucht Spam zu verteilen und nach knapp 1Stunde verstaubt der Account wieder. Dagegen hilft fast nur die einfache Benutzeranmeldung über xmpp zu deaktivieren.
Derzeit bei mir also nur möglich über (Gott ist das hässlich): https://jabber.kernel-error.de:9091/plugins/registration/sign-up.jsp
Oh ja, die Spamserver habe ich aktuell geblockt. Im Moment sind es die folgenden:
ajabber.me
anonymitaet-im-inter.net
codingteam.net
exploit.im
igniterealtime.org
jabber.co.za
jabber.no
jabber.zerties.org
jabbim.cz
jclub.pw
jumbo.li
justnet.pl
km-net.pl
lih.im
pandion.im
qip.ru
svnet.fr
sync-hv.de
talkers.im
tigase.im
xmpp.svnet.fr
Siehe auch: Eigenen Jabber-Server betreiben
Fragen? Einfach melden.
Kaum geht mein Artikel zur erweiterten Sicherheit meiner Webseite online >>TLS Sicherheit weiter verschärft….<< schon kommen Fragen. Eine habe ich nun schon vier mal bekomme, daher hier direkt die Antwort. Ach ja, die Frage:
Wie habe ich meinen Apache dazu überredet DHE-Keys mit 4096bit zu benutzen?
Also… Der Apache beherrscht seit Version 2.4 Diffie Hellman mit mehr als 1024bit. Um dieses nutzen zu können, muss der Apache die passenden dh-params haben. Der Apache nutzt dabei automatisch die ihm gegebene Key stärke.
Ich generiere den DH Teil gerne direkt mit dem jeweiligen Zertifikat und verbinde dieses. Beschrieben habe ich es hier: >>Sicheres SSL / TLS Zertifikat<<
Wer gerne nachträglich generieren möchte macht es mir:
$ openssl gendh 4096 > dh_4096.pem
Dieses lässt sich nun einfach wie ein normales Zertifikat mit in die Konfiguration des Apachen einbinden. Im Grunde nichts besonders und nachdem man es gelesen und absolut einleuchtend, man sucht aber dann doch zuerst etwas.
Viele andere Dienste (Postfix usw…) bringen ja meist einen eigenen Konfigurationspunkt dafür mit. Im Apache liegt es ohne große Konfiguration in Zertifikatsnähe.

So long….
Fragen? Einfach melden.
© 2026 -=Kernel-Error=- — RSS
Theme von Anders Norén — Hoch ↑