• 0 Posts
  • 14 Comments
Joined 2 years ago
cake
Cake day: June 7th, 2023

help-circle

  • The alert seems to indicate a compromised account, this can mean a lot more than “a bad IP”. Your account may have shown up in a “dump” and they took action to ensure your safety. Have you tried putting your email address into HaveIBeenPwned. While the normal recommendation would be to not put your email address in a random web form, this site is actually run by a well known security researcher and just lets you know if you have shown up in such a dump in the past.

    Another possibility would be that they have seen a major change in your IP geolocation in a short time. This is referred to as “improbable travel” and it’s something which many security departments take action on. If you login from an IP address which is associated with Paris, France and then an hour later are logging in from Dubai, UAE, this is going to be flagged. Sure, you might travel between those two locations, but you ain’t doing it in an hour. So, your account gets flagged as possibly compromised.

    even if it were a VPN, so what, your company literally runs a VPN

    Right, but they may not know that you are using another VPN. So, continuing the issue above of “improbably travel”. If you are on Proton’s VPN, they know all of their exit IP address and likely take them into account. But, if you are using a different company’s VPN, Proton likely doesn’t know all of that company’s exit IP addresses and so can’t account for them. Consider the situation from their perspective:

    1. You are using some other VPN and they force you to do a password reset.
    • Outcome - you’re a bit annoyed, but ultimately your mail account is safe.
    1. Some attacker has your password and tried to use it to access your mailbox, but Proton stopped the login and forced a password reset.
    • Outcome - you are a bit annoyed, but your mail account is safe.
    1. Some attacker has your password and tried to use it to access your mailbox, and Proton let them in.
    • Outcome - You get wrecked and are really unhappy.

    No matter what, Proton is going to lose out a bit to you being unhappy. However, if they force the password reset, the worst case is you being slightly annoyed about a password reset. By not taking action, they risk your account being fully compromised, which can be very, very bad for you. So, they are likely to be more proactive in forcing a password reset than you might like. This will be especially true if you do not have any sort of two-factor authentication setup. If the whole game is lost by one password being lost, any whiff of that password being compromised will result in a password reset.

    Ultimately, it is am annoyance but one which is actually positive for you. They take your email security seriously enough that, when their system detected something, they took action to keep you safe.



  • ever had to worry whether you’d parked your hard drive’s heads before moving it, child…?

    Yes, also you parked it before shutting down the system every time. Once the hard drive was powered down, the heads would just crash into the platters. While not instantly fatal, it wasn’t good for the drive. So, you’d park the drive before flipping the power switch.


  • Yeah… you’re gonna run out of road with that, eventually.

    It’s called runway, and as long as the VC money keeps rolling in, you cam keep extending it. Once the VC money starts to dry up you either accept a buyout offer from one of the big players in the space; or, you declare bankruptcy, loot the company for as much money as possible and start writing the next pitch to the VC firms. They don’t care how badly you bungled this one, so long as you make a good sounding case for “The Next Big Thing”. (see: Theranos 2.0)


  • It’s been a few of years since did my initial setup (8 apparently, just checked); so, my info is definitely out of date. Looking at the Ubuntu site they still list Ubuntu 16.04, but I think the info on setting it up is still valid. Though, it looks like they only list setting up a mirror or a stripe set without parity. A mirror is fine, but you trade half your storage space for complete data redundancy. That can make sense, but usually not for a self hosting situation. A stripe set without parity is only useful for losing data, never use this. The option you’ll want is a raidz, which is a stripe set with parity. The command will look like:

    zpool create zpool raidz /dev/sdb /dev/sdc /dev/sdd
    

    This would create a zpool named “zpool” from the drives at /dev/sdb, /dev/sdc and /dev/sdd.

    I would suggest spending some time reading up on the setup. It was actually pretty simple to do, but it’s good to have a foundation to work with. I also have this link bookmarked, as it was really helpful for getting rolling snapshots setup. As with the data redundancy given by RAID, it does not replace backups; but, can be used as part of a backup strategy. They also help when you make a mistake and delete/overwrite a file.

    Finally, to answer your question about hardware, my recollection and experience has been that ZFS is not terribly demanding of CPU. I ran a Intel Core i3 for most of the server’s life and only upgraded when I realized that I wanted to game servers on it. Memory is more of an issue. The minimum requrement most often cited is 8GB, but I also saw a rule of thumb that you want 1GB of memory for each TB of storage. In the end, I went with 8GB of RAM, as I only had 4TB of storage (3 2TB disks in a RAIDZ1). But, also think about what other workloads you have on the system. When built, I was only running NextCloud, NGinx, Splunk, PiHole and WordPress (all in docker containers). And the initial 8GB of RAM was doing just fine. When I started running game servers, I stared to run into issues. I now have 16GB and am mostly fine. Some game servers can be a bit heavy (e.g. Minecraft, because fucking Java), but I don’t normally see problems. Also, since the link I provided mentioned it, skip ECC memory. it’s almost never worth the cost, and for home use that “almost never” gets much closer to “actually never”.

    When choosing disks, keep in mind that you will need a minimum of 2 disks and you effectively lose the storage space of one of the disks in the pool to parity storage (assuming all disks are the same size). Also, it is best for all of the disks to be the same size. You can technically use different size disks in the same pool; but, the larger disks get treated as the same size as the smaller disks. So long as the pool is healthy, read speeds are better than a single disk as the read can be spread out among the pool. But, write speeds can be slower, as the parity needs to be calculated at write time. Otherwise, you’re pretty free to choose any disks which will be recognized by the OS. You mention that 1TB is filling up; so, you’ll want to pick something bigger. I mentioned using spinning disks, as they can provide a lot more space for the money. Something like a 14TB WD Red drive can be had for $280 ($20/TB). With three of those in a RAIDZ1 pool, you get ~28TB of storage and can tolerate one disk failure , without losing data. With solid state disks, you can expect costs closer to $80/TB. Though, there is a tradeoff in speed. So, you need to consider what type of workloads you expect the storage pool to handle. Video editing on spinning rust is not going to be fun. Streaming video at 4k is probably OK, though 8k is going to struggle.

    A couple other things think about are space in the chassis, drive connections and power. Chassis space is pretty obvious, you gotta put the disks in the box. Technically, you don’t have to mount the disks, they can just be sitting at the bottom of the case, but this can cause problems with heat shortening the lifespan of the drives. It’s best to have them properly mounted and fans pushing air over them. Drive connections are one of those, you either have the headers or you don’t. Make sure your motherboard can support 3 more drives with the chosen interface (SATA, NVMe, etc.) before you get the drives. Nothing sucks more than having a fancy new drive only to be unable to plug it into the motherboard. Lastly, drives (and especially spinning drives) can be power hungry. Make sure your power supply can support the extra power requirements.

    Good luck whatever route you pick.


  • Probably the easiest solution would be to just chuck a larger disk in the system and retain the original drive for the operating system. If you do not need the high speed of an SSD, you may be able to get more storage space for the money by going with a spinning disk. 7200RPM drives are fast enough for most applications, though you may run into issues streaming 4K (or higher) resolution video.

    Another option would be to start building out a storage pool using some type of RAID technology. On my own server, I use ZFS for the data partition. It is basically a software RAID. I use a RAID-Z1 configuration, which stripes the data over multiple disks (three in my case) and uses a parity calculation to provide data redundancy. It also has the advantage that it can be expanded to new disks dynamically and does not require that all disks are the same size. Initial setup does require more work and you are now monitoring multiple physical disks, but having a unified storage pool and redundancy is a nice way to go.

    Any way you go, just make sure you have good backups. Drives fail, and sometimes even early in their life. Backblaze reports can be an interesting read when looking at drive options, as they really do put the drives through the wringer.





  • I think it’s less about the tech picked and more about developers with no sense of security and a poor understanding of networking. I’ve seen far too many web applications where the developer needed some sort of database behind it (MySQL, PostGres, MSSQL) and so they stood up either a container or entire VM with a public IP and whatever the networking layer set to allow any IP to hit the database port. The excuse is almost always something like, “we needed the web front end to be able to reach the database, so we gave the database server/container a public IP and allowed access”. Which is wonderful, right up until half of the IP addresses in Russia start trying to brute force the database.