• 6 Posts
  • 106 Comments
Joined 2 years ago
cake
Cake day: July 19th, 2023

help-circle

  • The idea of having them send an e-mail to an address containing their IP is clever, however you need to authenticate that the person who sent the e-mail is either somebody who queried your site, or somebody that got the address from somebody who queried your site or else you could just figure out how to generate that base64 yourself and impersonate somebody else’s IP address which could have catastrophic results if you then fed these IPs into something like a block list and suddenly you’ve blocked Microsoft/Office 365. To be fair, I doubt anybody is going to try and reverse engineer one person’s code to then figure out how to impersonate who sent spam, but if this became a widely distributed program you could just pull off Github then it would be more concerning.

    A couple ways to solve this:

    1. Sign the information before encoding it in Base64 so you can verify it came from your site and wasn’t just spoofed. This has the upside of being stateless since you don’t need to keep a record of every e-mail you’ve generated but comes with the disadvantage of spending CPU time signing the text which could be exploited as a DDoS.
    2. Spit out a random e-mail address and record which e-mail address was given to each IP. Presumably you wouldn’t hold on to this list forever since IPs change owners frequently and so an IP that was malicious 1 month ago could be used by a completely different person now and so you can trim this list down once a month to avoid wasting disk space. You’d probably also want to keep some amount of these requests in memory (maybe 10Mb or so) to avoid ruining your IOPS.

    All this said, I think your time is better spent with the using unique e-mail aliases as the author suggested but with 2 changes: 1) use aliases which are not guessable to prevent somebody from making it look like somebody else was hacked (e.g. me+googlecom@ gets compromised, but the spammer catches on and sends from me+microsoftcom@ instead to throw off the scent) and 2) don’t use me+chickenjockey@, use chickenjockey@ or else the spammer can just strip “+chickenjockey” from the address to get the real e-mail address.


  • Eh it depends. I’m fortunate enough to be in a good IP block so I don’t get my e-mails dropped purely on that. It’s been a good learning experience and I’ve leaned on my own server a number of times for troubleshooting at work since I can see the whole mail flow. The only problem I have is the free Outlook/Hotmail will not accept my e-mails. Everybody else seems fine. All that said, I don’t host anybody else’s e-mail so I haven’t had any spam come out of my IP, and I would never in a million years host e-mail for a customer.






  • I’m curious if this was going to apply to content on non-Chinese Facebook. Another part of the article referring to hiring a “chief editor” explicitly says that the editor part would apply to the Chinese version only, but at the same time, Facebook removed content posted by a person in New York from Facebook at the request of the Chinese government, so it could go either way.

    If somebody is decrying the state of free speech in their podcast, show or in the campaign trail you can be pretty confident it’s an empty platitude. That said, you probably won’t find many examples of people willing to defend free speech or any civil liberties the moment their freedom is on the line. That’s not Zuck though. He’s just full of it.








  • They don’t need to be interested though. You could conceivably dump all the password you collect in an attack and just start trying them automatically like you would any other breach. Find a bunch of bank accounts and your chances you getting away with millions are high. Not to mention: a breach like this means changing all your saved passwords to re-secure them which is a multi-day affair.



  • I don’t think ZFS can do anything for you if you have bad memory other than help in diagnosing. I’ve had two machines running ZFS where they had memory go bad and every disk in the pool showed data corruption errors for that write and so the data was unrecoverable. Memory was later confirmed to be the problem with a Memtest run.




  • The OOM killer is particularly bad with ZFS since the kernel doesn’t by default (at least on Ubuntu 22.04 and Debian 12 where I use it) see the ZFS as cache and so thinks its out of memory when really ZFS just needs to free up some of its cache, which happens after the OOM killer has already killed my most important VM. So I’m left running swap to avoid the OOM killer going around causing chaos.