4 ms·

Great question. I don't anymore. Decades ago when I had a 286 and knew what each file did and what all the software was, and threats were limited and crude, I h

Great question. I don't anymore. Decades ago when I had a 286 and knew what each file did and what all the software was, and threats were limited and crude, I had good confidence of controlling my machine. Today, when my laptop has millions of files and each website - even hacker news - could inject something malicious and my surface is so broad (browsers applications extensions libraries everything) and virtually anything I do involves network connections... I just don't have the confidence. FWIW, I try to segregate my machines for different categories of behaviour - this laptop is for work, this one is for photos and personal documents, this one is for porn, this one is if I want to try something. But even still my trust in e. G. software vlan on my router and access controls on my NAS etc are limited in this day and age. I feel today it's not about striving for zero risk (for 99.99 of people) , but picking the ratio of overhead and risk you're ok with. And backups. (bonus question - how to make backups safe in age of encrypting ransom ware).

jl6 4y ago
On the backup question, this is one reason why I have a set of backups that are physically disconnected and not automated.
- BLKNSLVR 4y ago
  I have a backup NAS that's normally powered off, but it's scheduled to turn on, perform backup, shut down. It doesn't wake on LAN and there should be no way of knowing it exists outside of checking DHCP static addresses reservations - and now that I mention it, maybe I should remove it from there too. This minimises the size of the window, and network-snoopable information, required to compromise this set of backups.
  - jl6 4y ago
    If your main computer has had all its files encrypted by ransomware, will the backup NAS know not to replace the good backup with a bad one? i.e. hopefully it's not doing something like `rsync --delete`.
    - 2000UltraDeluxe 4y ago
      Not the GP but I use ZFS snapshots for such things. Should the files be overwritten or deleted I can always fetch an older copy from snapshots. The trick is to make sure nothing has access to the backup storage, which is obviously easier said than done.
      - mnw21cam 4y ago
        That's not hard. On my backup server, I have an account with a restricted shell that my backed-up machine has an ssh key for. That restricted shell is simply the following script: #!/bin/bash cd ~/backups tar --restrict --keep-old-files -x So the only thing that the backed-up machine (or an attacker) can do with the ssh key is push new files onto the backup server as a tar stream - it can't overwrite any files, and it can't put any files anywhere except the correct directory.
        account42 4y ago
        For my server I went one step further and set it up so that the server being backed up has no access to the backup system at all and insteady only prepares encrypted (differential) tar archives that the backup system then grabs.
    - fbdab103 4y ago
      Restic is my current backup solution of choice and that takes snapshots by default. If you took a backup on Monday, ransomwared on Tuesday, your backup volume would double in size (file de-duplication is going to fail spectacularly), but the Monday backup will be unimpacted until a prune operation is run. Suggested prune workflow is to maintain fairly staggered snapshots eg: 1x six-months ago, 1x three-months ago, 3x from last month, whatever makes you comfortable. Which should give a pretty comfortable margin on retaining your files.
  - NikolaNovak 4y ago
    I think, perhaps ignorantly, That may prevent some human being or intelligent agent specifically targeting your nas. I don't think it would help against situations where your primary system is being encrypted for a while, and thus your backups eventually get overwritten with bad stuff.
    - conception 4y ago
      Replication isn’t backup though?
      - NikolaNovak 4y ago
        I would agree, but I feel the GP specifically talked about "Backup NAS", which is where my question pertains. I do have a set of hard drives I exchange with my friend as "off site" backup. Neither my cloud service nor NAS keep copies/snapshots of previous versions of files; and I have too much stuff to create BlueRay let alone DVD one-off backups :0/
      - stephen_g 4y ago
        Hopefully they’re taking snapshots!
    - Izkata 4y ago
      > and thus your backups eventually get overwritten with bad stuff. I use rsync's --link-dest to get Time Machine-like backups so they can't be overwritten through the backup system itself. I don't take the "shut it down" precautions with this system the other person does, though I do have a separate in-place one that's strictly manual (as in I have to physically plug it in to update).
    - BLKNSLVR 4y ago
      The data being backed up is in tiers of importance or 'frequency of change', and based on this the backups are staggered, some daily, some weekly. I wouldn't often go a full week without checking some file or other, so I think I'd know pretty swiftly if I got infected with an encrypting ransomware virus - hopefully quickly enough to minimise damage. I also do off-site backups on occasion, so I could roll back to the last full set of off-site backups - so long as I remember where/when the most recent one is. My main adversary I'm protecting against is hardware failure, however. I think I run a pretty tight ship in restricting access to data that I'd rather not lose. Maybe some hubris payback will come visit one day though...
  - deleted 4y ago
    [deleted]
- deleted 4y ago
  [deleted]
hdjjhhvvhga 4y ago
> (bonus question - how to make backups safe in age of encrypting ransom ware). This is actually a solved problem, with many solutions. In a nutshell, you need a system that has enough space to make many enough copies without overwriting the ones that are too fresh. It also must not be controllable by the host that you backup but this is kind of obvious.
damagednoob 4y ago
> how to make backups safe in age of encrypting ransom ware. Versioned, offsite backups. For instance, if you have a database in an AWS account: * Give the backup process write only (I.e. no delete permissions) to a GCP account. * Create the backup in AWS and timestamp it * Copy the backup to GCP using the above permissions. * If you want to be more secure, copy the backup to a USBHDD (daily/weekly) and unplug it.
- deathanatos 4y ago
  > Give the backup process write only (I.e. no delete permissions) to a GCP account. I've looked into this before, and it is just not that easy. "Write" is delete, for most cloud storage systems, for the practical purposes of trying to keep a backup safe. (I.e., you might not be able to delete a blob in some bucket, but if you can write to it, you can just overwrite it with 0s.) "WORM" (write-once read-many) tends to be the term to search / gets the right documentation from most providers. In GCP's case, it appears to be "set up a retention policy", and that's similar to my experience with other providers. These bring their own set of problems. That said, encrypting ransomware isn't going to magically determine where your backups are, and for most orgs, having the backup at all (and having it tested) is the priority, not the whole WORM thing. (Orgs, IMO, also tend to get really uppity about having "database" backups, where "database" == {MySQL, Postgres, etc.}. But then there will be an S3 bucket that also has a bunch of data in it, and that never gets backed up, and nobody even questions that. And half the time it seems impractical to back up, too, due to a mix of cost and S3's design.)
fsflover 4y ago
> Today, when my laptop has millions of files and each website - even hacker news - could inject something malicious and my surface is so broad (browsers applications extensions libraries everything) and virtually anything I do involves network connections... I just don't have the confidence. It doesn't matter how many files your computer has and how many millions of lines of code it runs. There is a concept of Trusted Computing Base (TCB), which is the part of the code that you have to trust. In Qubes OS it's only about a hundred thousand lines, and doesn't include any browser. The key is security through isolation. You run your browser and network in virtual machines and assume that they are compromised. You keep your sensitive files in an offline VM.
GoblinSlayer 4y ago
You mean the case when ransomware encrypts your backups themselves? Normally they skip encryption of executable files, so you can hide backups like that.

jl6 4y ago

On the backup question, this is one reason why I have a set of backups that are physically disconnected and not automated.

BLKNSLVR 4y ago
I have a backup NAS that's normally powered off, but it's scheduled to turn on, perform backup, shut down. It doesn't wake on LAN and there should be no way of knowing it exists outside of checking DHCP static addresses reservations - and now that I mention it, maybe I should remove it from there too. This minimises the size of the window, and network-snoopable information, required to compromise this set of backups.
- jl6 4y ago
  If your main computer has had all its files encrypted by ransomware, will the backup NAS know not to replace the good backup with a bad one? i.e. hopefully it's not doing something like `rsync --delete`.
  - 2000UltraDeluxe 4y ago
    Not the GP but I use ZFS snapshots for such things. Should the files be overwritten or deleted I can always fetch an older copy from snapshots. The trick is to make sure nothing has access to the backup storage, which is obviously easier said than done.
    - mnw21cam 4y ago
      That's not hard. On my backup server, I have an account with a restricted shell that my backed-up machine has an ssh key for. That restricted shell is simply the following script: #!/bin/bash cd ~/backups tar --restrict --keep-old-files -x So the only thing that the backed-up machine (or an attacker) can do with the ssh key is push new files onto the backup server as a tar stream - it can't overwrite any files, and it can't put any files anywhere except the correct directory.
      - account42 4y ago
        For my server I went one step further and set it up so that the server being backed up has no access to the backup system at all and insteady only prepares encrypted (differential) tar archives that the backup system then grabs.
  - fbdab103 4y ago
    Restic is my current backup solution of choice and that takes snapshots by default. If you took a backup on Monday, ransomwared on Tuesday, your backup volume would double in size (file de-duplication is going to fail spectacularly), but the Monday backup will be unimpacted until a prune operation is run. Suggested prune workflow is to maintain fairly staggered snapshots eg: 1x six-months ago, 1x three-months ago, 3x from last month, whatever makes you comfortable. Which should give a pretty comfortable margin on retaining your files.
- NikolaNovak 4y ago
  I think, perhaps ignorantly, That may prevent some human being or intelligent agent specifically targeting your nas. I don't think it would help against situations where your primary system is being encrypted for a while, and thus your backups eventually get overwritten with bad stuff.
  - conception 4y ago
    Replication isn’t backup though?
    - NikolaNovak 4y ago
      I would agree, but I feel the GP specifically talked about "Backup NAS", which is where my question pertains. I do have a set of hard drives I exchange with my friend as "off site" backup. Neither my cloud service nor NAS keep copies/snapshots of previous versions of files; and I have too much stuff to create BlueRay let alone DVD one-off backups :0/
    - stephen_g 4y ago
      Hopefully they’re taking snapshots!
  - Izkata 4y ago
    > and thus your backups eventually get overwritten with bad stuff. I use rsync's --link-dest to get Time Machine-like backups so they can't be overwritten through the backup system itself. I don't take the "shut it down" precautions with this system the other person does, though I do have a separate in-place one that's strictly manual (as in I have to physically plug it in to update).
  - BLKNSLVR 4y ago
    The data being backed up is in tiers of importance or 'frequency of change', and based on this the backups are staggered, some daily, some weekly. I wouldn't often go a full week without checking some file or other, so I think I'd know pretty swiftly if I got infected with an encrypting ransomware virus - hopefully quickly enough to minimise damage. I also do off-site backups on occasion, so I could roll back to the last full set of off-site backups - so long as I remember where/when the most recent one is. My main adversary I'm protecting against is hardware failure, however. I think I run a pretty tight ship in restricting access to data that I'd rather not lose. Maybe some hubris payback will come visit one day though...
- deleted 4y ago
  [deleted]
deleted 4y ago
[deleted]

hdjjhhvvhga 4y ago

> (bonus question - how to make backups safe in age of encrypting ransom ware). This is actually a solved problem, with many solutions. In a nutshell, you need a system that has enough space to make many enough copies without overwriting the ones that are too fresh. It also must not be controllable by the host that you backup but this is kind of obvious.

damagednoob 4y ago

> how to make backups safe in age of encrypting ransom ware. Versioned, offsite backups. For instance, if you have a database in an AWS account: * Give the backup process write only (I.e. no delete permissions) to a GCP account. * Create the backup in AWS and timestamp it * Copy the backup to GCP using the above permissions. * If you want to be more secure, copy the backup to a USBHDD (daily/weekly) and unplug it.

deathanatos 4y ago
> Give the backup process write only (I.e. no delete permissions) to a GCP account. I've looked into this before, and it is just not that easy. "Write" is delete, for most cloud storage systems, for the practical purposes of trying to keep a backup safe. (I.e., you might not be able to delete a blob in some bucket, but if you can write to it, you can just overwrite it with 0s.) "WORM" (write-once read-many) tends to be the term to search / gets the right documentation from most providers. In GCP's case, it appears to be "set up a retention policy", and that's similar to my experience with other providers. These bring their own set of problems. That said, encrypting ransomware isn't going to magically determine where your backups are, and for most orgs, having the backup at all (and having it tested) is the priority, not the whole WORM thing. (Orgs, IMO, also tend to get really uppity about having "database" backups, where "database" == {MySQL, Postgres, etc.}. But then there will be an S3 bucket that also has a bunch of data in it, and that never gets backed up, and nobody even questions that. And half the time it seems impractical to back up, too, due to a mix of cost and S3's design.)

fsflover 4y ago

> Today, when my laptop has millions of files and each website - even hacker news - could inject something malicious and my surface is so broad (browsers applications extensions libraries everything) and virtually anything I do involves network connections... I just don't have the confidence. It doesn't matter how many files your computer has and how many millions of lines of code it runs. There is a concept of Trusted Computing Base (TCB), which is the part of the code that you have to trust. In Qubes OS it's only about a hundred thousand lines, and doesn't include any browser. The key is security through isolation. You run your browser and network in virtual machines and assume that they are compromised. You keep your sensitive files in an offline VM.

GoblinSlayer 4y ago

You mean the case when ransomware encrypts your backups themselves? Normally they skip encryption of executable files, so you can hide backups like that.