PDA

Bekijk Volledige Versie : Backups, pull of push methode?



The-BosS
22/07/21, 18:16
Met steeds meer ransomware aanvallen ben ik eens benieuwd naar welke methodes jullie gebruiken om backups te maken, is dit push of pull en waarom heb je die beslissing genomen. En wat zijn voor jullie de pro en con's van de methodes, ik noem er zelf ook een paar op en probeer een kijk te nemen uit het perspectief van de klant en hoster.


Uit perspectief van de klant;
Ik wil geen pull methode want als jouw backups server gehackt is dan kunnen ze inloggen op mijn server en alles verwijderen.

Maar dan uit het perspectief van de hoster:
Als jouw server (klant) gehackt is dan kunnen ze ook inloggen op jouw backup account en alles verwijderen en heb je geen data en geen backups.

Ik maak zowel gebruik van pull als push afhankelijk van de situatie, servers/computers die achter een nat zitten is enkel push mogelijk zonder instellingen in de firewall aan te passen. Bij sommige diensten is het enkel mogelijk om via ftp of s3 te uploaden en dus te pushen. Uiteraard worden backups op meer dan 1 externe fysieke locatie bijgehouden en kan hier ook weer de vraag gesteld worden sync je vanuit 1 centrale server of laat je clients naar meerdere backup server pushen/pullen. Ook hier kan ik weer tal van pro/con's gaan bedenken.


Vanuit centrale server:
Als de centrale server down is komen er totaal geen backups meer binnen van klanten, dus in de periode dat de centrale server down is zijn er geen accurate backups.

Naar meerdere servers:
De klant moet X maal uploaden en heeft dus ook X maal data verbruik en overhead van client programma's die X maal verbinding maken.

Ik hoor graag jullie meningen hierover.

stefantriep
22/07/21, 18:54
Ik gebruik altijd pull, aangezien push met de gedachte van Ransomeware/Hacks inderdaad niet veilig is.
Geen servers in beheer achter NAT of waar het niet anders kan.

Backup altijd naar extern datacenter dan het hoofd DC, dan heb je iets wat je kan uitrollen bij een major issue in het hoofd DC.
Wellicht is de situatie hier redelijk eenvoudig aangezien het ook maar naar 1 externe locatie gaat.

madeitbelgium
23/07/21, 16:52
Wij gebruiken momenteel push waar alle backups naar een server worden gestuurd in een ander DC. Maar zijn wel bezig om dit aan te passen, vooral door de ransomeware aanvallen die toch meer en meer opkomen.

De opzetten welke we nu aan het uitwerken zijn:
Server pusht de backup naar een andere server in het zelfde DC. Elke server heeft een eigen login en locatie waar de backups worden naar toe gepusht. Een script gaat daar de backup ophalen en in een ander DC opslaan. De laatste 7 backups worden opgeslagen op een server in een ander DC, telkens de laatste backup van de maand wordt ook bijgehouden en de laatste backup van iedere week (tussen de backup van de laatste volledige maand en de huidige dag). Vanaf deze server kunnen we eenvoudig backups terug sturen naar de server waar de webhosting opstaat of waar de backup nodig is. Daarnaast worden alle backups ook opgeslagen op een NAS die in ons kantoor staat, deze NAS is enkel ingeschakeld wanneer het nodig is om de backups er op te plaatsen. Hier testen we ook nog met S3 of soort gelijke opslag diensten ipv de NAS.

chielsen
23/07/21, 22:05
Al jaren pull vanwege de kans op hacks. Ik vind het bizar dat dit nu pas een vraag is en men jarenlang met push dacht veilig te zijn. Een backup is iets wat een in een zeer slecht scenario je enigzins uit de brand kan helpen. Als dat uitgaat van een happy flow dan heb je daar natuurlijk niks aan.

Mark17
28/07/21, 12:39
Wij zijn momenteel bezig de backup omgeving te vervangen. Daarna hebben we eerst push naar centrale backup servers en vanaf daar doen we dan weer pull voor de langere termijn opslag. Deze laatste opslag staat in een andere plaats.

Door de mix hopen we het relatief veilig te maken tegen ransomware (maar ik weet ook dat tenzij we echte offline backups hebben het nooit 100% veilig zal zijn).

CharlieRoot
01/08/21, 07:24
Met steeds meer ransomware aanvallen ben ik eens benieuwd naar welke methodes jullie gebruiken om backups te maken, is dit push of pull en waarom heb je die beslissing genomen. En wat zijn voor jullie de pro en con's van de methodes, ik noem er zelf ook een paar op en probeer een kijk te nemen uit het perspectief van de klant en hoster.



Ik maak zowel gebruik van pull als push afhankelijk van de situatie, servers/computers die achter een nat zitten is enkel push mogelijk zonder instellingen in de firewall aan te passen. Bij sommige diensten is het enkel mogelijk om via ftp of s3 te uploaden en dus te pushen. Uiteraard worden backups op meer dan 1 externe fysieke locatie bijgehouden en kan hier ook weer de vraag gesteld worden sync je vanuit 1 centrale server of laat je clients naar meerdere backup server pushen/pullen. Ook hier kan ik weer tal van pro/con's gaan bedenken.



Ik hoor graag jullie meningen hierover.

Ik gebruik altijd pull, waarbij de productieservers nooit toegang kunnen krijgen (op welke manier dan ook) met de backup server. Vanaf de backup server data ophalen, data los in de backup (gescheiden) van het OS, altijd een week- maand- kwartaalbackup bewaren. De laatste twee punten zijn met name in geval van ransomware handig. Waar mogelijk de data natuurlijk ook op twee locaties bewaren (maar hoe dan ook off-site).

geckotools
12/08/21, 13:14
Wij hebben er eigenlijk voor gekozen om onze backups enkel dmv snapshots te doen. In het geval van een ransomware aanval kunnen we deze dan direct restoren. afhankelijk van het systeem en de eisen op redundancy wordt deze ook naar een andere (geografische) locatie gesynced.

bibawa
12/08/21, 16:50
Ik ben dan even benieuwd hoe maken jullie je backup? dmv custom scripts neem ik aan dan aangezien backup software (R1/Acronis/..) altijd toch via pull werkt..

Mark17
13/08/21, 09:20
Ik ben dan even benieuwd hoe maken jullie je backup? dmv custom scripts neem ik aan dan aangezien backup software (R1/Acronis/..) altijd toch via pull werkt..

Burp werkt met push.

Zoals al aangegeven hebben wij een combinatie van push en pull en we gebruiken voor een groot deel eigen scripts.

Wat voor retentie vinden jullie redelijk?

geckotools
13/08/21, 12:05
Ik ben dan even benieuwd hoe maken jullie je backup? dmv custom scripts neem ik aan dan aangezien backup software (R1/Acronis/..) altijd toch via pull werkt..

Snapshot gebeurt altijd via de storage systemen (dus bijv. netapp maakt netapp snapshots) geen scripts gewoon software die dat instelt en regelt. Wij maken gebruik van VPS'sen bij TransIP en die heeft deze funciotnaliteit out of de box met ZFS.


Wat voor retentie vinden jullie redelijk?

onze back-ups worden elke 4 tot 6 uur gemaakt met een totale retentie van maximaal 36 tot 54 uur (verspreid over 9 back-ups). Plus een backup die een week bewaard wordt. evt. zou je daar een maandelijkse tot 6 maanden oud bij kunnen bewaren. Maar dat is afhankelijk van de classificatie van je systeem en hoe verouderd de informatie van 6 maanden oud kan zijn. Zou zo maar kunnen zijn dat je daar niks meer aan hebt.

The-BosS
14/08/21, 00:32
Ik ben dan even benieuwd hoe maken jullie je backup? dmv custom scripts neem ik aan dan aangezien backup software (R1/Acronis/..) altijd toch via pull werkt..

Ik kan tal van software noemen waar push (en/of pull) mogelijk is hoor, zoals eerder al aangegeven burp maar ook backup.ninja, pbs, borg, lbackup, ... zelfs als je gebruik maakt van git om bvb je configs op te slaan en te gebruiken op andere servers/pc's is dit push en geen pull vanuit het opzicht van de server/pc waar je de configs bewerkt ;).

The-BosS
14/08/21, 00:46
Wij hebben er eigenlijk voor gekozen om onze backups enkel dmv snapshots te doen. In het geval van een ransomware aanval kunnen we deze dan direct restoren. afhankelijk van het systeem en de eisen op redundancy wordt deze ook naar een andere (geografische) locatie gesynced.

Snapshots zijn net zoals raid geen backups, het woord zegt het zelf al het is een momentopname op een bepaald tijdstip van de volledige omgeving, hoe ga jij uit je snapshot 1 of 2 bestanden halen. Zonder die snapshot op een compleet nieuwe omgeving te booten (waar mogelijks als randsomeware op staat, maar nog niet actief is), daar die bestanden te zoeken, deze te kopieren naar de originele server/pc om vervolgens de omgeving die je geboot hebt van de snapshot terug te stoppen.

Waar snapshots dan wel weer enorm goed in zijn is om deze te maken voor een upgrade en als er iets fout gaat vliegensvlug een rollback te kunnen doen naar de toestand van voor de upgrade. Maar in het geval van randsomeware heb je geen benul wanneer de server/pc geinfecteerd is en kun je net zo goed een rollback doen naar een moment waar de randsomeware al aanwezig was maar nog niet geactiveerd was. En blijf je dus achter de feiten aan lopen aangezien je geen clean install kunt doen en gewoon de data terug zetten.

En ja ik weet dat je zfs snapshots kunt gebruiken over samba shares naar windows servers/pc's door middel van vss voor snapshots op file basis, maar ook vss is geen backup en al zeker niet met de laatste exploits.

Mastje
14/08/21, 22:00
De servers die ik backup werken met een push script richting dezelfde server of een server in hetzelfde datacenter. Vervolgens worden de backupbestanden gepullt vanaf een server in een extern datacenter.

Deze backups bewaar ik 7 dagen. Daarnaast wordt de backup van zondag bij mij thuis opgeslagen.

Ik maak iedere dag een volledige backup. Hoe doen jullie dat? Ik zit wel eens te twijfelen om te gaan experimenteren met een differential backup voor de files of bijvoorbeeld de email.

stefantriep
15/08/21, 11:56
Ik maak iedere dag een volledige backup. Hoe doen jullie dat? Ik zit wel eens te twijfelen om te gaan experimenteren met een differential backup voor de files of bijvoorbeeld de email.

Full backups kost heel veel schijfruimte, op een gegeven moment overgegaan op 1 full backup en daarna incrementals voor files / e-mail, databases altijd full backup en dan 30 tot 60 dagen retentie

Mastje
15/08/21, 13:23
Full backups kost heel veel schijfruimte, op een gegeven moment overgegaan op 1 full backup en daarna incrementals voor files / e-mail, databases altijd full backup en dan 30 tot 60 dagen retentie

Ik loop er inderdaad tegenaan dat ik flinke backupservers nodig heb. Maak je eenmalig een full backup of doe je dit wekelijks / maandelijks?

stefantriep
15/08/21, 13:36
Ik loop er inderdaad tegenaan dat ik flinke backupservers nodig heb. Maak je eenmalig een full backup of doe je dit wekelijks / maandelijks?

Eenmalig full bij start en daarna incrementals dagelijks, maar bij sommige servers ook per uur.

Tuxis_IE
01/09/21, 12:24
Ik redeneer ook even hardop: Het enige waar je echt rekening mee moet houden:
a) Kun je vanaf de back-up server de live server onklaar maken?
b) Kun je vanaf je live server de back-ups weggooien?

De horror scenario's
Geval a). Backup server is lek. Hacker heeft 100% toegang tot die server. Hij gooit de back-ups allemaal weg. Kan hij dan ook inloggen op de live server waar de back-ups van gemaakt worden? Hou daarbij er ook rekening mee dat in de back-up mogelijk informatie staat waardoor dat mogelijk gemaakt wordt. VPN configuraties, credentials.

Geval b). De liveserver is lek. Hacker heeft 100% toegang tot die server. Kan hij dan back-ups weggooien die eerder gemaakt zijn? Dan lijkt pull weer een stuk veiliger dan push al is het niet weg kunnen gooien makkelijk op te lossen. Wel schrijven, niet wissen bijvoorbeeld of verplaatsen.

Dus veilig zou zijn: Push back-ups naar de back-up server. Zorg dat eerdere back-ups niet verwijderd kunnen worden vanaf de live server. Push de back-ups vanaf de back-up server naar een 2e back-up server of pull back-ups naar een 2e back-up server.

Een andere (de beste?) oplossing is door niet IN je live OS te back-uppen maar eronder. Ook dan moet je zorgen dat de laag eronder veilig is maar je hebt in die laag nauwelijks kans op ransomware (geen gebruikers, browsers, mail of zelfs maar een desktop). Dan maak je back-ups met Proxmox Backup Server. Dat kan meerdere keren per dag en dat wordt versleuteld verzonden naar de back-up server. Dan wil je nog steeds niet dat je back-up server lek is natuurlijk maar vanaf de back-upserver kan je niet naar de live servers én je kan de data op de back-up server niet lezen omdat die op de live server al versleuteld is.

The-BosS
01/09/21, 13:23
Een andere (de beste?) oplossing is door niet IN je live OS te back-uppen maar eronder. Ook dan moet je zorgen dat de laag eronder veilig is maar je hebt in die laag nauwelijks kans op ransomware (geen gebruikers, browsers, mail of zelfs maar een desktop). Dan maak je back-ups met Proxmox Backup Server. Dat kan meerdere keren per dag en dat wordt versleuteld verzonden naar de back-up server. Dan wil je nog steeds niet dat je back-up server lek is natuurlijk maar vanaf de back-upserver kan je niet naar de live servers én je kan de data op de back-up server niet lezen omdat die op de live server al versleuteld is.

Dan ga je er wel automatisch vanuit dat je klant toegang heeft tot de hypervisor of dat het OS niet op barebone hardware geinstalleerd is, voor workstations kun je dit dus al vergeten.

Maar inderdaad zoals je in je vorige punten aangeeft kun je een hoop doen om bepaalde zaken te voorkomen, zoals read-only of in omgekeerde richting write-only (no delete), maar voor de meeste zal het toch een ei/kip verhaal blijven.

Tuxis_IE
01/09/21, 13:28
Dan ga je er wel automatisch vanuit dat je klant toegang heeft tot de hypervisor of dat het OS niet op barebone hardware geinstalleerd is

Assumptions, daar was wat mee :-)