RDP / TLS, Fail2ban, Pypy, Restic, UEBA, AuthentiCode

Finally found a way to generate persistent remote desktop (TLS) certificate so you can Trust on First Use (TOFU) it. As said, this is SAFER than using publicly trusted certificates. Public trust is weaker and pointless in case of specific trust. Interestingly there were no a single source script for this. I built my script from documentation and about random 20 forum posts after a few tests. And now it actually works. Many times when dealing with certs, it seems that the remote desktop hangs with stopping state and requires system reboot. Depending on the situation, that can be hugely annoying and a big problem. Also wrote a small script that monitors the cert and inform the key people, in case it changes. But this really shouldn't happen anymore.
Upgraded one Fail2ban code to handle efficiently larger subnets and blocking access based on ASN numbers in case of massive abuse. Earlier it did this for IPv6 addresses, only, but the IPv4 implementation was lacking. IPv4 is now handled as expected. Looks up BGP info and bans whole subnet first, and if attacks resume later from another subnet from same ASN it also bans whole ASN(s). Of course excluding addresses on whitelist and or known good hosts.
SMB shares, just noted that some people don't always use /REQUIREINTEGRITY and /REQUIREPRIVACY options which enable integrity checks and encryption for the data transport, which of course are required for secure operations.
Long interesting discussion about password hashing, sometimes attacks like pass the hash work. Because there's no challenge response approach, which would actually knowing the password.
Shortly played with PyPy, yet currently I don't have a need for it. Almost all tasks are I/O bound, not actually Python code execution time bound.
Had some talks with Restic devs about server side compaction and client side data compression. Client side compression is a must, I wonder how they have missed it, because it's also pretty trivial to implement. Server side compaction is also possible, but of course it's quite complicated. Yet I do realize it also means that encryption is implemented on block level and if single file contains multiple blocks in that case if the file is encrypted with CBC we're out of luck.
Watched a long documentary about UEBA, implementation, experiences, benefits, drawbacks and then read a few extra technical articles. Nothing new... Yet depending on factors also could be pretty invasive surveillance. Ref: UEBA (@ Wikipedia).
Joy of programming. Started again refactoring one complex logic, and after six hours of work, it ended up being 30% slower and slightly broken after refactoring... Ahah, so classic. Sometimes when people say that something is written in a stupidly simple way, yes, that's because it works. Usually optimization adds complexity and code, which means that the project can perform worse, adds complexity and on top of all, makes it a lot more complex to maintain.
Studied the requirements for AuthentiCode (@ Wikipedia) signing cx_Freeze generated MSI packets for software delivery and made a few successful tests. Also checked out how to sign .exe, .ocx and .dll files. With self-signed key, before a friend applies for official certificate. - Lot's of extremely bad instructions which basically recommend building signed programs that can do anything by loading unsigned scripts. Uh oh.
I don't personally like concepts where client software, encryption, data transfer, and storage is all handled by a single provider. I think it poses a risk. It's just same as claiming that a blockchain is distributed, if every node on runs the same source with auto updates. No, it's not distributed, it's control is still very much centralized centralized. They can change the client(s) as necessary, so there's no security provided by the "distribution", except of course data durability, if there's some physical kind of mishap. Properly distribution would mean that they don't control, encryption keys and encryption via their controlled client. Hopefully at least three totally independent teams and parallel projects, which any of the projects holds majority. Yet the question about client reliability is yet another problem. Now you're running one more program, which is having to access to your data, most likely also the data which you didn't especially mean for the application. Unless you're taking tinfoil measures, which only hardcore security guys do. No normal user ever takes such measures.

2023-05-07