[ale] Linux Ransom-ware

[DJ-Pfulio]

"Push"ed backups are less secure than "pull"ed backups from a secured,
non-public, backup server.

If the backups aren't versioned, you've already lost. You need as many
backup versions as it takes to realize there is an issue. Sometimes
that is a week and other times it might be 3+ months. High-risk systems
need more versions because attackers have learned to infect and wait,
sometimes months, before doing anything visibly bad.

The days of 2 backup versions are long gone.  We need 3-12 months for
high-risk systems.

IMHO.

There are backup solutions that need only 10% more storage for every
month retained (YMMV). That  means 60 days of versioned backups only
need 1.20x the original storage. Can you say BARGAIN!!!!?

On 11/10/2015 11:00 PM, Wolf Halton wrote:
> I have an rsync-based script that pulls specific directories, dates them and saves them to a remote host/storage. It is relatively dumb and just adds the new tarred collection to a group of them. I don't think a malware could follow this backup home. Have to test it. 
> 
> Wolf Halton
> Atlanta Cloud Technology
> Cybersecurity & Disaster Recovery Solutions 
> Mobile/Text 678-687-6104
> 
> --
> Sent from my iPhone. Creative word completion courtesy of Apple, Inc. 
> 
>> On Nov 9, 2015, at 1:48 PM, Lightner, Jeff <JLightner at dsservices.com> wrote:
>>
>> Ideally rather than having a local backup source your server pushes to, you have a remote backup server that pulls backups.   That won’t prevent a backup run AFTER the infection from containing the infection but it will keep the infection from pushing out to backups made before the backups.
>>  
>> Really, Web Servers, shouldn’t be doing much PUSHING in the first place.    Here we have a limited number of connections allowed from our DMZ to internal systems and none of it is obvious things such as ssh.  We can ssh into the web server but cannot ssh from the web server back into our internal network.  I periodically have to remind people that requests ssh trusts in from web server that we don’t even allow ssh inbound let alone setup trusts in that direction.
>>  
>>  
>> From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of Scott Plante
>> Sent: Monday, November 09, 2015 11:46 AM
>> To: Atlanta Linux Enthusiasts
>> Subject: Re: [ale] Linux Ransom-ware
>>  
>> The article says it goes after backup files too. It seems what you need is either a backup drive or media you manually connect to do backups, or a separate backup server that only accepts new backups and doesn't give the client write access to old backups. I think it might be fairly easy to script something like this, but is anyone aware of an existing backup server software that does this kind of thing? Most of the backup software I've seen assumes you have read/write access to a "backup drive" whether that's a USB, NFS, or other network accessible mount, or of course a tape or dvd that someone manually changes. For all the advantages of removable media, you always have the problem of human error or laziness fouling up your backup regime, so automated is good.
>>  
>> For a backup server, it would of course be of some limited space. You wouldn't want the push process to be able to just keep pushing junk until your good backups are pushed off. Just a thought that popped into my head in the vein of maybe a push-only backup server is more complicated than I first thought. Seems like some of the issues people have worked out for log servers that accept log messages but are extra hard for hackers to mess with.
>>
>> From: "Leam Hall" <leamhall at gmail.com>
>> To: "Atlanta Linux Enthusiasts" <ale at ale.org>
>> Sent: Monday, November 9, 2015 5:53:07 AM
>> Subject: Re: [ale] Linux Ransom-ware
>>
>> On 11/09/15 04:35, DJ-Pfulio wrote:
>>> Linux Ransom-ware is out looking for ways to attack and encrypt your
>>> systems:
>>> https://krebsonsecurity.com/2015/11/ransomware-now-gunning-for-your-web-sites/
>>>
>>> Good news: They only want 1 bitcoin as payment.
>>>
>>> Bad news: 1 BC is about US$420 and the unlock process doesn't put
>>> everything back exactly like it was.
>>
>> Good news; we're all now reminded to back up our files and sites.  :)
>>