Network defence, Event Logs, TRIM, BitTorrent, OPSEC, Megolm
Network defence, Event Logs, TRIM, BitTorrent, OPSEC, Megolm
- Improved edge defense system as well as added central coordination. Naturally can't go into details, but generic description is fine. To summarize it up, we've got independently operating edge, which also utilizes centrally managed information like white lists and IP reputation data. Leading to very efficient networked defence. In case the central management system is unreachable (for whatever reason) the edge defence can still operate completely independently mitigating threats. Following Endpoint Detection & Response (EDR) principle.
- It pays to pay attention. Once again, I've got so much disinformation from Microsoft. Event log timestamps UTC timestamps. Nope, that's not true. It's local time. Almost everyone claims it's UTC and many documents say so. But that's not true. The TS used, is local. Digging around event logs reveal this detail: <Data>-120 FLE Standard Time</Data> That's -120 minutes which means +2 hours. Confirmed. Again one thing, which is obvious when you know it, but can lead to confusion before you have figured it out. Especially when lot of documentation conflicts with the facts.
- Wrote a little utility tool to check if TRIM / ZRAT actually works. And whoa, it seemed to actually work. The software reads the whole disk / volume through and lists percentage of full zero blocks. When ZRAT works, it should be at least as high as disk free for that volume. But to my amazement it worked on all but one of my SSDs. Of course traditional disks do return stale deleted data just as the one failed SSD, and the end result is very different. It's also good indication that the controller return zero for empty blocks that read latency for empty space is lower than for areas which do contain data. This of course can be also caused by the internal data compression of SSD. On the failed disk trimming didn't clear the "empty" blocks but overwriting with zero did. So ZRAT clearly isn't working.
- Transmission BitTorrent client doesn't seem to use async I/O the whole client blocks if there's any slow disk I/O operations bringing it to the halt. This is classic software problem, everyone thinks they can get away with bad implementation, because "something else" in the stack will fix the problem. Well, in many cases that does work, but in this case it wont. Combination, Slow USB device, exFAT, Linux, Transmission. Slow USB device totally hangs with random I/O, exFAT doesn't do efficient delayed allocation / sparse files, on Linux and Transmission doesn't have efficient internal I/O scheduler / cache like Deluge does. End result is system doing lots of extremely slow I/O bringing it to complete halt I/O wait time over 98% basically stopping everything. As well as the device controller only allows very small number of "block groups" to be modified at a time, before running whole block group garbage collection, causing excess write amplification on random writes. Excellent example of "stacked" naive implementations. -> Really awesome combination.
- "Limiting Your Digital Footprints In A Surveillance State" - I just read a long article about the topic. Of course it contained nothing new. Most important part of it was that encrypting communication alone isn't nearly enough, as we know. Metadata pays a key role in the OPSEC. It's enough to know whom you're communicating with to get you in serious trouble.
- Debugged interesting problems with Megolm key delivery when using Riot.im client on Matrix.org network. There was a situation where single recipient couldn't decrypt my messages when others were able to. It clearly seems that the key management isn't working properly in multi user chats always. When I initiated separate also encrypted chat with the affected party with it worked flawlessly. So it's clearly session / device / key distribution related problem. In Matrix encrypted chats every sender generates own encryption keys and all recipients need to have that key to decrypt the chat. That's why it's possible that some users can and some users can't decrypt the messages at the simultaneously. kw: unable to decrypt (utd)
- Riot.im uses -----BEGIN MEGOLM SESSION DATA----- for end2-end enryption (e2ee) key storage, but the row length is strange 128 characters on line ASCII (base64)? Interesting choice.
2020-05-24