Am 19 und 20.08 ist es wieder so weit. Die FrOSCon öffnet ihre Türen. https://www.froscon.de/
Ich bin in diesem Jahr auch wieder dort wer noch? 😀
Autor: kernel-error (Seite 14 von 48)
Das es auch mal in einer CPU Fehler geben kann ist nicht jedem bewusst. Da es aktuell sehr durch die Presse geht, inzwischen vielleicht schon einigen Menschen mehr als vorher. Das diese Fehler in CPUs sogar recht oft vorkommen, daran denken die wenigsten. Ich kann mich noch an einen Intel Prozessor erinnern bei dem man einfach mit dem Windows Taschenrechner testen konnte ob ein bestimmte Bug vorliegt. Diese CPU durfte man sogar zurückgeben weil es sich nicht durch ein simples Update fixen lässt.
Update? Ja man kann den sogenannten Microcode der CPU updaten. Ja der Microcode ist fest in der CPU „eingebrannt“ ein solches Update muss also jedes mal gemacht werden, wenn die CPU erneut eingeschaltet wird. Daher lösen es die meisten Mainbordhersteller über ein Bios Update. Wenn ihr also mal die Changelogs eurer Bios Updates durchgeht werdet ihr immer mal wieder etwas von CPU und oder Microcode lesen. Das ist dann genau so etwas. Setzt man ein älteres Mainboard ein gibt es auch kein Update 😀 Setzt man Linux ein installiert man sich die Microcode Updates und bei jedem Start bekommt die CPU so ihr Update. Bei FreeBSD geht dieses natürlich ebenfalls. Da diese Frage bei mir schon ein paar mal angekommen ist, dieser Beitrag.
Das Paket nennt sich devcpu-data und findet sich in der Ports und ebenfalls auch als Binary:
$ pkg install devcpu-data
Damit es aktiviert ist und beim Booten geladen wird, ja ihr erratet es… Folgendes muss in die /etc/rc.conf :
microcode_update_enable="YES"
Dann lässt sich alles einmal anstarten und direkt sehen ob es erfolgreich ist:
$ /usr/local/etc/rc.d/microcode_update start Updating cpucodes... /usr/local/share/cpucontrol/m12206a7_00000029.fw: updating cpu /dev/cpuctl0 from rev 0x28 to rev 0x29... done. /usr/local/share/cpucontrol/m12206a7_00000029.fw: updating cpu /dev/cpuctl2 from rev 0x28 to rev 0x29... done. /usr/local/share/cpucontrol/m12206a7_00000029.fw: updating cpu /dev/cpuctl4 from rev 0x28 to rev 0x29... done. /usr/local/share/cpucontrol/m12206a7_00000029.fw: updating cpu /dev/cpuctl6 from rev 0x28 to rev 0x29... done. Done.
Wie man sieht, er konnte ich ein Update vom Microcode durchführen und es gab auch eines. Es kommt immer mal wieder vor das Fehler gefunden werden daher dieses immer aktuell halten.
Einigen sehr aufmerksamen Bloglesern ist es ja inzwischen aufgefallen. Ja ich habe meine Schlüssel getauscht 🙂
Mir ist in der letzten Zeit an ein paar Systemen ein kleines „Problem“ im Zusammenhang mit DNSSEC, IPv6 und UDP Paketgrößen aufgefallen. Wobei aufgefallen hier nicht ganz korrekt ist, ich bin durch http://dnsviz.net darauf gestoßen worden. Die Jungs kommen mir nämlich mit der folgenden Warnung entgegen:
domain.tld/A: No response was received until the UDP payload size was decreased, indicating that the server might be attempting to send a payload that exceeds the path maximum transmission unit (PMTU) size. (2001:210:5000:bbbb::aaaa:1, UDP_0_EDNS0_32768_4096)
Diese Meldung besagt das es vom jeweiligen DNS Server erst eine Antwort gegeben hat, nachdem die UDP Größe verringert wurde. Dieses fällt einem im normalen Tests mit dig / drill oder ähnlichem nicht wirklich auf. Denn hier wird absolut automatisch die Paketgröße weiter verringert bis es klappt. Es „dauert“ nur etwas länger….
Der DNS-Server, in diesem Fall ein bind9.11, versucht auf die Frage mit einem IPv6 UDP Paket zu Antworten und schickt dieses mit 4096 Byte raus. Aus irgendeinem Grund (Firewall, Einstellungen im OS, Filter auf dem Netzwerk….) wird dieses Paket auf seinem Weg aber verworfen und erreicht sein Ziel nicht. Da wir hier über UDP sprechen merkt das der Server nicht und glaubt er habe seinen Job gut gemacht. Woher soll bind auch wissen das sein Paket nicht angekommen ist oder irgendwas auf dem Weg sein Pakete mit dieser Größe nicht mag?
Um als Admins herauszufinden wie groß die Pakete von seinem System denn werden können kann man folgenden einfachen Test nutzen:
$ dig +short rs.dns-oarc.net txt rst.x490.rs.dns-oarc.net. rst.x499.x490.rs.dns-oarc.net. rst.x457.x499.x490.rs.dns-oarc.net. "2001:310:6000:f::1fc7:1 sent EDNS buffer size 512" "Tested at 2017-07-05 08:23:52 UTC" "2001:310:6000:f::1fc7:1 DNS reply size limit is at least 499"
Wie zu erkennen ist endet es auf diesem System bei 512 Byte. Wenn wir uns jetzt nicht weiter um den Grund kümmern wollen oder können, müssten wir also unserem bind sagen das er bitte immer nur mit maximal 512 Byte arbeitet, wenn er UDP nutzt. Dieses geht wie folgt im Options Block:
options {
[....]
edns-udp-size 512;
max-udp-size 512;
[....]
};
edns-upd-size ist hier für das Empfangen und max-udp-size für das Senden von Paketen. Ab dem Moment probiert es bind nur noch mit 512 Byte und die Clients werde auf ihre erste Frage hin direkt eine Antwort bekommen, ohne die Frage so oft wiederholen zu müssen, bis sie schrittweise zurück auf 512 Byte sind.
So long…
Nutzt man auf seinem FreeBSD das WLAN so funktioniert es in der Regel ohne Probleme. Wenn man aber an ein WLAN gerät das Kanal 12 oder 13 benutzt, so funktioniert das irgendwie nicht. Warum? Ganz einfach… im Standard kommt ein FreeBSD mit dem Ländercode US für USA hoch. Dort ist leider essig mit Kanal 12 und 13. Daher muss man seinem FreeBSD erstmal sagen das es sich in Deutschland befindet. Dieses geht wie folgt:
$ ifconfig wlan0 list channel $ ifconfig wlan0 down $ ifconfig wlan0 ecm $ ifconfig wlan0 regdomain ETSI $ ifconfig wlan0 country DE $ ifconfig wlan0 up $ ifconfig wlan0 list channel
Zeile 1 zeigt einem dabei die aktuellen Kanaleinstellungen, Zeile 2 schaltet das die Karte für die Umstellungen ab, Zeile 3 bis 5 bringen uns nach Europa und Deutschland, Zeile 6 schaltet das wlan wieder ein und Zeile 7 gibt uns nun die aktuellen Kanäle einmal aus.
Möchte man dieses nun nicht immer einstellen sondern fest bei jedem Start mit eingebaut haben hilft folgende Zeile in der /etc/rc.conf:
create_args_wlan0="ecm regdomain ETSI country DE"
Möchte man mehr erfahren kann man sich die Datei: /etc/regdomain.xml anschauen oder besser noch:
$ ifconfig wlan0 list regdomain
Dieses geht natürlich ebenfalls mit dem country:
$ ifconfig wlan0 list countries
Tjo… Viel Spaß wa?
Da klicke ich doch gestern das Upgrade meiner Piwigo Bildergalerie von 2.8 auf 2.9 und es scheint sauber gelaufen zu sein. Leider findet sich ab dem Moment auf der Seite die folgende 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
in /pfad/bilder.kernel-error.de/include/dblayer/functions_mysqli.inc.php on line 845
Was ist da wohl passiert? Im nginx Logfile findet sich dabei folgendes:
UPDATE piwigo_user_infos
SET last_visit = NOW(),
lastmodified = lastmodified
WHERE user_id = 2
in /pfad/bilder.kernel-error.de/include/dblayer/functions_mysqli.inc.php on line 845" while reading upstream, client: 2001:aaaa:aaaa:aaaa:eef4:bbff:fe47:c54c, server: bilder.kernel-error.de, request: "GET / HTTP/2.0", upstream: "fastcgi://unix:/var/run/php-fpm.sock:", host: "bilder.kernel-error.de"
2017/05/30 15:53:29 [error] 97077#100936: *1 FastCGI sent in stderr: "PHP message: PHP Warning: [mysql error 1054] Unknown column 'last_visit' in 'field list'
Also schaue ich mir mal die Logmeldungen zum Zeitpunkt des Upgrades von Version 2.8.x auf Version 2.9.0 an und finde diesen Eintrag:
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'
; in /pfad/bilder.kernel-error.de/include/dblayer/functions_mysqli.inc.php on line 845" while reading response header from upstream, client: 2001:aaaa:aaaa:aaaa:eef4:bbff:fe47:c54c, server: bilder.kernel-error.de, request: "GET /upgrade.php?now= HTTP/2.0", upstream: "fastcgi://unix:/var/run/php-fpm.sock:", host: "bilder.kernel-error.de"
2017/05/30 15:53:28 [error] 97076#100895: *48 FastCGI sent in stderr: "PHP message: PHP Warning: [mysql error 1054] Unknown column 'last_visit' in 'field list'
Tja… Da ist beim Upgrade aus irgendeinem Grund also wirklich das Upgrade an der Datenbanke abgesoffen 🙁 Ich habe mir dann aus dem Upgradescript die passenden Einträge für die Datenbank herausgesucht und sie noch einmal von Hand auf die DB log gelassen:
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'
;
Scheint zu passen 🙂
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…
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!
Ihr erinnert euch daran das man bei GlobalSign keine Sonderzeichen im Kennwort für die Zertifikatsverwaltung nutzen kann? Nun ratet doch mal was man beim Kennwort für p12 auch nicht nutzen kann! ….Richtig… Sonderzeichen im Kennwort 😛
Wie angekündigt habe ich nun ein neues S/MIME Zertifikat.
SHA1: 0C B9 00 A9 C7 C9 EF B0 15 57 4F E0 1F D8 57 BD B6 31 CC BD
Ganz brav habe ich direkt SMIMEA mit dem Zertifikat zusammen in Aktion versetzt. Es ist zwar noch ein draft aber man kann es ja mal probieren:
https://tools.ietf.org/wg/dane/draft-ietf-dane-smime/
Jetzt könnte ich also auch mal Dinge wie smilla: https://github.com/sys4/smilla oder https://github.com/letoams/openpgpkey-milter angehen, oder?
In diesem Sinne!
