Linux – ISO Image brennen

Aus gegebenem Anlass heute das Thema, wie man eine ISO Datei auf einen USB Stick „brennt“.

Die einfache Antwort lautet natürlich: Genau so wie auf eine DVD, aber das ist natürlich nicht hilfreich, daher folgt eine bebilderte Anleitung.

Methode 1

Schritt 1 : Das Laufwerke Tool starten ( aka. Gnome-Disks )

Schritt 2 : Den USB Stick reinstecken und auswählen

Laufwerketool

Schritt 3 : Im Menu ( oben in der Fensterleiste ) „Laufwerksabbild wiederherstellen“ auswählen ( kommt der Kontext oben im Bild )

Schritt 4 : mit dem Dateirequester das ISO Image auswählen

Schritt 5 : Wiederherstellen anklicken

Wirklich brennen?

Schritt 6 : Die Rückfrage beantwortet und abwarten bis der Vorgang beendet ist.

Methode 2

  1. Im Nemo/Nautilus die ISO Datei rechts anklicken.

2. Öffnen mit „Schreiber von Laufwerksabbildern“ ( ganz unten )

Alternative Methode

3. Als Ziel den USB Stick auswählen

4. Wiederherstellung starten und bestätigen

5. Abwarten und Tee trinken gehen!

Amazon Phishingmails im Umlauf

Phisingmail für AmazondiensteZugegeben, diese Phishingmail ist eine der besten, die mir je unter gekommen ist. Bis auf zwei Fehler bei der Rechtschreibung „einkäufe“ statt „Einkäufe“ und am Satzanfang schreibt man alles groß Ihr Nasen, war der Text fehlerfrei. Schade für Euch Jungs, aber dafür gibt es keinen Preis. Viel Glück beim nächsten mal.

Der Link

Die URL in dem Link der Email geht dann natürlich auch nicht zu Amazon, sondern zu htttp://bit.ly/suchenkontoid***** ( damit da keiner draufdrückt, nicht als Link und unvollständig ). Nach drei Umleitungen von URL Shortdiensten, landet man dann bei dem Monster hier :

htttp://www.amazon.de.kontouberprufen.sicherheitsdaten.suchenkontoid.ml/safe/confirm/identity/

Die eigentliche Domain ist „suchenkontoid.ml“ , aber der Witz ist, daß eine von den Zwischenumleitungen tatsächlich bei Amazon gehostet ist 😀

$ curl -i http://bit.do/dV8gY
HTTP/1.1 301 Moved Permanently
Date: Mon, 11 Dec 2017 11:23:41 GMT
Server: Apache/2.2.34 (Amazon)

Natürlich haben wir die Registry gebeten, die Domain vom Netz zu nehmen. Aber da muß jemand schneller gewesen sein, denn die routet jetzt zu SEDO, als wenn den Müll jemand kaufen würde 😀

Location: http://sedoparking.com/www.amazon.de.kontouberprufen.sicherheitsdaten.suchenkontoid.ml

Die Emailheaderanalyse

Natürlich als erstes der Absender : <sicherheit@amаzоn.dе>  ja! Genau ! Ins Schwarze .. Was ist das ??? 😀

Und natürlich taucht auch nirgends das Wort amazon auf, wie man das von einer Email, die von Amazon über Amazon gemailt wird, erwarten würde 😀 Die spammende Domain habe ich mal markiert :

Return-path: <www-data@valigaher.ga>
Delivery-date: Mon, 11 Dec 2017 05:58:40 +0100
Received: from mout-xforward.web.de ([82.165.159.45])
	by XXXXXXXXXXXXXXXXXXXXXXXXX with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128)
	(Exim 4.87)
	(envelope-from <www-data@valigaher.ga>)
	id 1eOGAm-0007Bt-7m
	for XXXXXXXXXXXXX; Mon, 11 Dec 2017 05:58:40 +0100
Received: from [212.227.17.8] ([212.227.17.8]) by mx-ha.web.de (mxweb112
 [212.227.17.8]) with ESMTPS (Nemesis) id 1M9Gnd-1eRH6j47wF-006MDM for
 <XXXXXXXXXXX> ; Mon, 11 Dec 2017 05:58:35 +0100
Received: from valigaher.ga ([212.24.99.45]) by mx-ha.web.de (mxweb112
 [212.227.17.8]) with ESMTPS (Nemesis) id 1MP0X0-1eh1TK3wlg-00PO6Z for
 <XXXXXXXXXXXXXXX>; Mon, 11 Dec 2017 05:58:34 +0100
Received: from valigaher.ga (localhost.localdomain [127.0.0.1])
	by valigaher.ga (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id vBB4wY2P031333
	for <XXXXX>; Mon, 11 Dec 2017 06:58:34 +0200
Received: (from www-data@localhost)
	by valigaher.ga (8.14.4/8.14.4/Submit) id vBB4wYUn031331;
	Mon, 11 Dec 2017 06:58:34 +0200
Date: Mon, 11 Dec 2017 06:58:34 +0200
Message-Id: <201712110458.vBB4wYUn031331@valigaher.ga>
To: XXXXXXXXXXXX
X-PHP-Originating-Script: 0:ind.php
From: =?UTF-8?B?QW3Nj2HNj3rNj2/Nj24uzY9kzY9l?= <sicherheit@amаzоn.dе>
MIME-Version: 1.0;

Nicht mal jwhois weiß, was .GA für eine TLD sein könnte 😀 Nicht mal die whois.ga funktioniert richtig, behauptet aber es gäbe nur 911 Domains für .ga .. Woran das wohl liegt 😀

Wenn Cinnamon ständig crashed

Warum immer in der Weihnachtszeit ? Die sollte doch so friedlich sein. Mein Laptop war anderer Meinung. Vor zwei Wochen erst auf Fedora 26 aktualisiert und seit Mittwoch crasht Cinnamon in Endlosschleife in seinen Rückfallmodus, ohne irgendeine brauchbare Spur zu hinterlassen. Na gut, Challenge Accepted!

Die Versuchsreihe

Zunächst mal sollte man checken, ob man vielleicht ein neues Update bekommen hat und dies das Problem löst. Tat es nicht, weil keines kam.

Ok, jetzt müßte man doch mal nachsehen, was da unter der Haube los ist. Also „journalctl -xe | grep -i cinnamon“ eingegeben und … nichts.

Ok, versuchen wir es ohne den Filter : „journalctl -xe“ und siehe da, jede Menge rote Crashmeldungen in diversen Libs, aber leider kein Hinweis, was da der Auslöser sein könnte. Auch 1 Stunde später, und diverse andere Logs und Webseiten später, senkte sich vom Baum der Erkenntnis die rote Kartenfrucht herab.

Der Reinstall

Ein klares Signal, einen Reinstall durchzuführen, also als Root eingegeben:

dnf reinstall „cinnamon*“

Und wieder in Cinnamon einloggen… args.. gleiches Ergebnis. Hmm.. da hat es wohl noch mehr zerlegt… uff. Also, ‚ dnf reinstall „*“ ‚ eingegeben, also die ersten 80 Pakete bereits runter geladen waren, wollte ich aber doch noch mal etwas anderes austesten.

adduser -s /bin/bash testuser
passwd testuser

Und dann mal als Testuser einloggen. Oh… Das geht ja … Da ist dann wohl doch nur die Session defekt. Dann hauen wir die halt weg:

rm -rf ./.config/cinnamon-session ./.local/share/cinnamon ./.cinnamon

Danach ist der Account so jungfräulich, daß Cinnamon alles wieder sauber anlegt und oh Wunder, dann geht es auch wieder mit dem Login 😀

Man muß natürlich alles neu einstellen,aber das ist ein kleiner Preis. Was meine Session/Einstellungsdaten genau getroffen hatte, wird man wohl nie erfahren 😉