Щасливого нового року! — Frohes neues Jahr! — Happy new year!
З Рiздвом Христовим − Merry Christmas − Frohe Weihnachten
Available for new Projects in 2023
I am available for new projects starting April 2023.
I can support you for SW-architecture, SW-development, Linux, databases and security.
See IT Sky Consulting to see for more details on what I can offer.
Just a reminder:
Articles that are published on April 1st in this blog are always April-jokes.
Goodware: Russian BOT-Networks
The FSB in Russia has an increasing demand for computing power and storage. On the other hand it is getting more difficult to import computers or parts into Russia due to the sanctions.
So now an innovative Russian IT work group has developed a software stack, that allows reliable storage and computing on bot nets.
- It is possible that a whole bot net is taken down and all the data is lost
- Since the confidential data is distributed across millions or billions of nodes all over the world, good encryption is needed all the way
- Transfer of data needs to be obfuscated
The work group came up with solutions. They develop malware, which is actually called „goodware“, because it serves a good purpose, that installs the software on millions of computers all over the world. This malware is constantly changed and updated, in order to create multiple independent botnets.
The crucial data is encrypted. Advanced Russian technology allows to perform the calculations on encrypted data, so the real content is never revealed on the node.
The FSB-IT-team creates virtual networks, again based on botnets of goodware, with many hops that change rapidly to transfer data and goodware to and from the nodes and to control them.
Data is stored and processed redundantly. Since there is a huge surplus of computing power and storage volume, it is possible to store data with such high multiplicity that recovery is possible even if multiple complete goodware-botnets are taken down.
A positive side effect is that the FSB learns what is going on on the devices where they have positioned their goodware.
So let’s buy more and better computers and help the FSB to get more computing power.
To all my readers:
I am way to upset about the invasion of Ukraine by Russian fascists and the atrocities they are committing there. I am at the moment not able to write useful articles about IT topics.
This is something from mainstream Russian TV by a super star who gets medals of honor from Putin:
I hope that this nightmare can be finished soon and we can invest some of our energy into building positive things. I will come back…
Typical software development environments have several systems running the software. While usually each developer runs it on his machine, there is a continuous integration server running and versions of the software that succeed there go to an artifactory and are immediately, during the night or manually installed on a system that is called „staging“, „development“, „dev“, „dev-test“ or something like that. Then it goes to a system called „test“, where the test team can work with it. They only get versions that are actually of interest to them, so it makes sense to separate it from „dev“. When successful, it might go to production, but usually there is just another system, with whatever name, that is supposed to be identical to production and is used for final release tests, before the software actually goes to production.
This kind of works, as long as the software is done by one team. Now we observe cases, where many teams work on the software. They develop their part of the software and kind of need a stable version of everything else. This is especially true for external remote teams.
Now we live in a time where virtual servers are the normal way to work. So getting a new set of servers is no longer an issue of buying hardware, but it is just a matter of running a few scripts. Good organizations can set up whole systems automatically in a matter of minutes. So it should be possible, to just provide within reason a few test systems more when needed and discard them again when done. Abusing an existing system for different purposes rarely works out smoothly.
So it is a good idea to select a technology that allows to setup a system or a whole landscape automatically. This can be virtual servers, docker containers or even physical hardware. It is a lot of work to set this up, but then it becomes easier to add just one more test system to run special tests or to have a stable release to develop against for other teams.
Everyone who uses Linux (or some Unix) knows the normal file permissions that are administered with chmod, at least to some extent.
It is worth noting, what permissions of a file and the underlying directory mean.
In order to read the file, one needs read rights for the file and also read and executable rights for the directory in which the file is located and all super-directories.
Having the write right for the file means being able to change its contents. Which could mean deleting all content leaving a zero byte file.
But the right to delete a file requires write access to its directory, because it changes the contents of the directory. Same with creating files. rm actually checks if you have write access to the file as well, unless you use rm -f, which is just enforced by rm, not by the system.
Now there is another bit that comes in. ACL-rights, which can override the settings of the normal permissions and for example get specific users read or write access. These are read using getfacl and changed using setfacl. I think it would be desirable that ls had an option to show these ACL-rights as well, but it does not yet have that, at least not the version that I am using. What ls at least does: it shows a ‚+‘ after the normal permissions string, which indicates that acl-rights are actually in use.
So, if you do file operations and observe something works or does not work, which cannot be explained by the normal file permissions, check the ACL.
Now things can get even a bit more hairy, if you mount remote directories from a file server, because now accessing them requires that your computer and the file server allow it. And the network including firewalls.
Yet another bit can come in, it is called „SELinux“. Linux supports security modules and if a security module is present, all system calls are checked against the security module and may end up with „permission denied“. AppAmor is an example and the most well know security module is SELinux. It allows fine granular permission policies what is allowed and what is not allowed. In the end we get „permission denied“ although there is no visible obstacle. You can find out if that is the case by running
Now on productive systems it may not be allowed to turn off security features just for the fun of it, because they should protect from certain attack scenarios and we must expect that these attacks happen exactly when we turn them off for a minute to check something. But of course we do have test systems and there we can try out things. If after
the same command works and after
it does not work, than SELinux is stopping it. Which means you have to fix your SELinux settings or file attributes which are observed by SELinux.
We have been using the term „certificates“ for a long time for files that are used to encrypt or sign data or to prove identity.
Now „certificates“ have become something that we use in our daily life to show that we are vaccinated or tested against Covid-19.
Because they are provided as QR-codes and people are used to thinking of QR-codes as a way to encode an URL in a machine readable way, many people think that this means that the certificates are actually stored on a server and just retrieved from there. Which again causes a lot of resistance against the certificates and the requirement to have them and to show them. They suggest using the „yellow book“ instead, which has worked just fine for providing proof of vaccinations.
But things have changed. Today a lot depends on being vaccinated and some people are really scared of the vaccinations, for example some internet stars spread the rumor that people will die a few years after the vaccination. How do they know less than that number of years after the first person has been vaccinated? I guess it is their secret. But today there are millions of people who are really willing to pay good money for a falsified yellow vaccination book and it is not really that hard to do that. So in the end of the day, the yellow book cannot be trusted any more.
Now, what is it with the certificate?
Just think of a text file that contains the relevant information. JSON, XML or something like that.
- valid until?
- what (test/vaccination/…)?
- count of vaccinations (1/1, 2/2, 3/3…)
- type of vaccine (mRNA…)?
- Product (Moderna/BionTech/SputnikV/…)?
- Country (last) of vaccination?
- Date of (last) vaccination?
- Serial number of shot
More or less something like this…
Now this file is digitally signed by a universally trusted entity, like the ministry of health. So the person who performs the vaccination creates this file, transmits it to the ministry of health, where it is cryptographically signed and then it is transmitted back as a binary file, whose integrity can be verified by the signature, using the public key of the ministry, but it cannot be changed or created without the private key of the ministry, which needs to be kept safe in the ministry. A lot of really important things rely on this public key cryptography, so it should be OK for this purpose as well.
Now this binary file is just encoded as QR-code. Not the URL of the file, the actual contents. When we show the certificate and the person checking it is serious about it, they use an app that can read the QR-code and decode it to show the contents of the original text file in a nice format and ensure that it is exactly what has been signed by the ministry.
Now the ministry promises that it does not store a „backup“ of the certificate that it signed, once it is done. So the data is deleted shortly after having been signed. We can believe this or not. If we assume that they store data about our vaccinations and tests etc., then yes, they do that. But they do not need the certificate for that. They can get the information anyway without creating a certificate for us.
So I guess it is a pragmatic approach to use these certificates as a relatively fraud safe method to prove that one has been vaccinated or tested or gone through a Covid-infection. The yellow books should not be accepted any more and actually they are less and less. And of course the certificate with the QR-code on the phone or on a piece of paper is only better than the yellow book, if they really verify it with an app and if they check some ID as well.
This technology has a lot of interesting applications that we might make use of in the time after Covid-19.
Tickets for Railroad, Flight, Theater, Cinema, Museum,… can be personalized and done in a way that is hard to forge. We actually see this already today. Now there could be a digitalized passport on the phone as well, which is signed by the issuing authority. For many purposes that could work as well as the paper passport. Now think that this passport and the ticket can be matched, i.E. one trusted person checks that the passport and the ticket and the person travelling match and from than on the combined certificate containing the passport and the ticket can be shown, which would make things easier and more efficient and more relyable than having to show ticket and passport again and again.
2022 Happy New Year
¡Próspero año nuevo! — うれしい新しい年 — Shnorhavor nor tari! — Selamat tahun baru! — Честита нова година! — Gelukkig nieuwjaar! — สวัสดีปีใหม่ — Lokkich nijjier! — عام سعيد — Среќна нова година! — Un an nou fericit! — Happy New Year! — Срећна нова година! — Feliz año nuevo! — С новым годом! — Srechno novo leto! — Sugeng warsa enggal! — Feliĉan novan jaron! — Próspero ano novo! — Godt Nyttår! — 새해 복 많이 받으세요 — Boldog új évet! — Godt nytår! — Frohes neues Jahr! — Laimingų naujųjų metų! — Felice Anno Nuovo! — Gleðilegt nýtt ár! — Hääd uut aastat! — 新年好 — Sala we ya nû pîroz be! — Sretna nova godina! — Szczęśliwego nowego roku! — السنة الجديدة المبتهجة — Gott nýggjár! — Cung chúc tân xuân! — Щасливого нового року! — Naya barsa ko hardik shuvakamana! — Feliz ano novo! — Bun di bun an! — Akemashite omedetô! — Een gelukkig nieuwjaar! — Laimīgu Jauno gadu! — FELIX SIT ANNUS NOVUS! — Bonne année! — Gott nytt år! — Yeni yılınız kutlu olsun! — سال نو مبارک — Šťastný nový rok! — Καλή Χρονια! — Onnellista uutta vuotta! — Весёлого нового года! — Laimīgu jauno gadu! — Ath bhliain faoi mhaise! — Subho nababarsho! — Nav varsh ki subhkamna!
This was created by a Ruby-program:
# encoding: utf-8
# coding: utf-8
texts = [ 'Akemashite omedetô!', 'Ath bhliain faoi mhaise!', 'Boldog új évet!', 'Bonne année!', 'Bun di bun an!', 'Cung chúc tân xuân!', 'Een gelukkig nieuwjaar!', 'FELIX SIT ANNUS NOVUS!', 'Felice Anno Nuovo!', 'Feliz ano novo!', 'Feliz año nuevo!', 'Feliĉan novan jaron!', 'Frohes neues Jahr!', 'Gelukkig nieuwjaar!', 'Gleðilegt nýtt ár!', 'Godt Nyttår!', 'Godt nytår!', 'Gott nytt år!', 'Gott nýggjár!', 'Happy New Year!', 'Hääd uut aastat!', 'Laimingų naujųjų metų!', 'Laimīgu Jauno gadu!', 'Laimīgu jauno gadu!', 'Lokkich nijjier!', 'Nav varsh ki subhkamna!', 'Naya barsa ko hardik shuvakamana!', 'Onnellista uutta vuotta!', 'Próspero ano novo!', 'Sala we ya nû pîroz be!', 'Selamat tahun baru!', 'Shnorhavor nor tari!', 'Srechno novo leto!', 'Sretna nova godina!', 'Subho nababarsho!', 'Sugeng warsa enggal!', 'Szczęśliwego nowego roku!', 'Un an nou fericit!', 'Yeni yılınız kutlu olsun!', '¡Próspero año nuevo!', 'Šťastný nový rok!', 'Καλή Χρονια!', 'Весёлого нового года!', 'С новым годом!', 'Срећна нова година!', 'Среќна нова година!', 'Честита нова година!', 'Щасливого нового року!', 'السنة الجديدة المبتهجة', 'سال نو مبارک', 'عام سعيد', 'สวัสดีปีใหม่', 'うれしい新しい年', '新年好', '새해 복 많이 받으세요' ];
shuffled_texts = texts.shuffle(random: SecureRandom);
str = shuffled_texts.join(' — ');
replace no-break-spaces by spaces…