IPv6, Logs, Phishing, PowerShell, Interception, SSL, Security
IPv6, Logs, Phishing, PowerShell, Interception, SSL, Security
- IPv6 "user" reputation - Lot's of discussion with friends and colleagues about IPv6 address reputation management and subnetting. What's the sane policy for coalescing addresses. Without some prefix database it's really hard to tell, if single customer is operating subnet prefix 32, 48, 56, 64 or 128 number address. Why does it matter? Well, let's say you're abuser, and you want to abuse some service. IP address based limiting doesn't work at all, because you happen to have your own 32 which you can use for abuse. Yet in some cases, banning /32 would lead whole ISP to get blocked. I'm pretty sure that at some point (if it doesn't yet exist) there will be some kind of database which will indicate what kind of subnets are being allocated from subnets. Allowing more presice IP address based reputation. For now I would like to use 64 prefix, but I'm very aware about the potential problems. Some users might not be sufficiently blocked by it, and in some cases it would lead whole data centers to be blocked by single abuser. Not a perfect solution by far.
- After long consideration and thinking, I'll ended up with solution where addresses are intelligently merged into subnets after specific threshold and if required, subnets and masks are computed so that the white listed addresses are still excluded from being blocked. Yep, this is perfect example where efficiency adds lots of complex code which can easily malfunction, and this is the reason why this logic wasn't implemented in the very beginning.
- It's also way annoying that some Windows Event logs only contain first 64 bits off IPv6 address, which of course is full 128 bits. That's not enough in all the use cases, I described above. This isn't really big problem in real world, but everything which isn't perfect in theory annoys me greatly. I love logically perfect solutions. Over something that "about roughly works".
- Today received amazingly well crafted phishing mail, all SSL certs were correct from the IT department as AS number was correct etc. Only thing that gave it bit off, was strange URL which isn't being usually used, but it was good enough not to immediately alert user. As well as the fact that SSO didn't work. Why they're asking for password, when I'm already signed in. Classic sign of phishing. I would say that the attacker made very well job, and my guess is that 99% of users would fall for their scam.
- PowerShell Get-FileHash - this is very handy tool for IT department & guys. Makes it easy to verify files as well as sign files using shared keys and so on.
- There has been lots of discussion about lawful interception and lawful access. Where service providers purposefully weaken their encryption so it's trivial to break when required. This very clearly shows once again the need to use the concept I've mentioned so many times. Encrypt data, and transport / store it separately. Do not ever think that it's valid that the service / application provider says that data is encrypted. That doesn't mean anything, whatever they claim, they still have trivial ways of breaking that encryption. No amount of lies can remedy the problem, as long as it's single or closely related entity doing encryption, software development, data transport and storage. It's just simply no go. As example, many IM programs are extremely great example, as well as "secure email providers" or backup vendors. They do have access to your data, whatever they claim, it just requires a few extra steps if needed.
- SSL certs, so classic. I just received an email from one larger authority, saying that they got issues with their certificates. Just go and ignore all warnings and continue. I wonder why they didn't provide new certificate and mention the fingerprint which is acceptable. Well, that would have been too smart. It's just simpler to say that "ignore all warnings" and continue. Aww, so normal.
- Studied "Security Guidelines for Transport Layer Security v2. pdf". Long guide, and absolutely nothing new in it. It's nice that they mentioned 0-RTT, OCSP stapling, Forward secrecy (ephemeral keys), Session tickets, Post-quantum security, Certificate pinning & DANE, Client certificate based authentication.
2020-06-28