El pestell de la porta d'un lavabo hi és perquè qui està a punt d'entrar sàpiga que hi ha algú a dins. Qualsevol que empenyi fort entra igualment, i això no és un defecte del pestell: és exactament el que un pestell fa.
La casella «Protected» dels backups de Proxmox és un pestell. A la interfície surt un cadenat, a la documentació es diu protection, i al cap de molta gent que sap el que fa s'ha traduït a «immutable». No ho és, i la diferència acaba de deixar de ser acadèmica: hi ha ransomware que la treu amb una sola crida a l'API de Proxmox abans d'esborrar la còpia.
Operem clústers de Proxmox VE amb Ceph en producció i gestionem còpies amb Proxmox Backup Server i amb Veeam, així que això ens toca de ple. El que segueix és el que diu el codi de Proxmox quan l'obres, i què fem nosaltres amb aquesta informació.
El bitxo s'ha llegit el manual
Halcyon va publicar l'anàlisi d'una variant Linux de Pay2Key: un binari ELF de 64 bits escrit en C++, detectat per primera vegada a finals d'agost de 2025. L'interessant no és el xifratge (ChaCha20 per fitxer, amb les claus protegides amb Curve25519), que és el de sempre. L'interessant és que no porta eines pròpies per tocar la virtualització: fa servir les de Proxmox.
- 1Es fa l'inventari amb
pvesh get /cluster/resources. No escaneja: pregunta. - 2Apaga les màquines amb
qm stop <vmid> --skiplocki els contenidors ambpct stop <ctid> --skiplock. Amb els discos quiets, xifrar és més ràpid i més net. - 3Treu la protecció de les còpies:
pvesh set /nodes/<node>/storage/<storage>/content/<backup> --protected 0. - 4I aleshores les esborra:
pvesh delete /nodes/<node>/storage/<storage>/content/<backup>.
Halcyon diu que, de totes les famílies de ransomware que segueixen, cap altra no havia modificat les proteccions de backup integrades de la plataforma. Aquest pas 3 és la novetat. Algú es va asseure a llegir l'API de Proxmox i va trobar la porta que estava oberta.
Convé no saltar-se un detall abans de seguir: aquestes ordres surten del mateix node ja compromès, i qui ha arribat a apagar màquines amb --skiplock té privilegis de sobres perquè cap comprovació de permisos l'aturi. L'API no s'està burlant, s'està fent servir. El que ve a continuació no explica com va entrar el bitxo, sinó per què la casella no l'anava a aturar en cap cas.
Per què cedeix el pestell: treure'l costa el mateix que esborrar
Aquí és on val la pena obrir el codi en comptes de refiar-se del titular. A pve-storage, el fitxer src/PVE/API2/Storage/Content.pm defineix les dues operacions que ens importen sobre un volum de backup.
El DELETE ho anuncia clar: «necessites el privilegi Datastore.Allocate a l'emmagatzematge (o Datastore.AllocateSpace per a volums de backup si tens VM.Backup a la VM)». El PUT que canvia atributs —el que posa i treu el protected— anuncia una cosa molt més suau: «necessites accés de lectura al volum».
Llegit així sembla un forat: el cadenat s'obriria amb permís de lectura. Però la comprovació de debò la fa check_volume_access, a src/PVE/Storage.pm, i per a un volum de tipus backup amb VM propietària demana Datastore.AllocateSpace a l'emmagatzematge i VM.Backup a la VM propietària de la còpia. Que és, lletra per lletra, el que el DELETE comprova en aquest mateix cas.
Ni forat ni cadenat. La conclusió és la incòmoda de debò: protected no és una frontera de privilegi. Treure el pestell no demana ni un permís més que esborrar la còpia, de manera que qui la pot esborrar la pot desprotegir sempre. El pestell no està pensat per aturar-lo a ell; està pensat per aturar-te a tu.
Un matís que no convé saltar-se, perquè va en la direcció contrària a la que un esperaria: això val per a l'emmagatzematge governat des de PVE. Dins del mateix Proxmox Backup Server el repartiment és diferent —treure la protecció demana Datastore.Modify, o ser el propietari del grup amb Datastore.Backup; esborrar demana Datastore.Modify o ser el propietari amb Datastore.Prune—, de manera que un token només de backup pot obrir el pestell i quedar-s'hi, sense poder esborrar res. El pestell cau; la porta, no. Que és just com hauria de ser, i la raó que la recomanació que ve ara funcioni.
I per això funciona molt bé. Evita que una política de retenció es mengi la còpia bona, evita l'esborrat a mà un divendres a la tarda, evita el prune mal calculat. Continua valent la pena tenir-lo posat a totes les còpies que t'importin.
En emmagatzematge de fitxers, el cadenat és un fitxer al costat
Hi ha un detall més, i és el que més ens va sorprendre en mirar-ho. En els emmagatzematges basats en fitxers —directori, NFS, CIFS— la protecció no viu en una base de dades ni en metadades del sistema de fitxers. Viu en un fitxer veí: protection_file_path retorna literalment ${path}.protected, i archive_remove es nega a esborrar («cannot remove protected archive») mentre aquest fitxer existeixi.
O sigui: la protecció de la còpia està guardada al mateix lloc i amb els mateixos permisos que la còpia. Qui pugui escriure en aquest directori —el mateix host, el root del NAS, qualsevol que munti el recurs NFS— no necessita ni l'API. Li n'hi ha prou amb un rm. Guardar la clau dins de la caixa forta és una decisió perfectament raonable si el que muntes és un pestell. A PBS no funciona així: la protecció la desa i l'aplica el servidor, i el client només la pot demanar per l'API. Aquesta diferència és mitja resposta al problema.
Això no és una fallada de Proxmox
Convé dir-ho, perquè el titular fàcil seria el contrari. Proxmox no ha promès en cap lloc que protected sigui immutabilitat, no hi ha CVE per reportar aquí i no hi ha cap pedaç a esperar. La casella fa el que diu la documentació que fa. L'error de lectura ha estat nostre, de manera bastant generalitzada, i el curiós és que la documentació de Proxmox Backup Server ja porta la resposta correcta escrita, en un apartat que es diu Ransomware Protection & Recovery i que gairebé ningú no llegeix fins l'endemà.
El que sí que és una frontera: permisos que l'atacant no té
Una frontera de debò no és una casella al mateix costat de la porta. És un permís que les credencials compromeses no inclouen. Sobre això sí que es pot construir, i això és el que cal aconseguir:
- ✓El clúster no pot esborrar res. El privilegi
Datastore.Backupde PBS, en paraules de la seva documentació, «permet només crear, però no esborrar ni alterar backups existents». Un token amb això i res més escriu còpies i no pot esborrar les que ja hi són. - ✓La retenció s'executa al PBS, no al client. És la recomanació de la documentació de Proxmox: no donar permisos d'esborrat i fer el prune amb tasques programades al mateix servidor de backup. Si ningú des de fora no pot esborrar, no cal un pestell.
- ✓Un token per clúster, i acotat al seu namespace. Proxmox arriba a posar l'exemple de la ruta ACL:
/datastore/tank/pve-abc-cluster. Un clúster compromès no arriba a les dades d'un altre. - ✓La sincronització no propaga esborrats. Una tasca de sync es pot configurar per no eliminar al destí allò que ha desaparegut a l'origen. És la diferència entre una còpia remota i un mirall de la catàstrofe.
- ✓Retenció llarga i un mitjà diferent. Proxmox avisa que hi ha ransomware que es queda adormit dies o setmanes abans de xifrar: si la teva finestra són 14 dies, pots tenir catorze còpies del problema. La cinta, a més, és l'únic lloc on «desconnectat» significa desconnectat de debò.
Hi ha també una propietat del disseny de PBS que juga a favor i que convé conèixer: no reescriu blocs existents. Un host de Proxmox compromès, o qualsevol client compromès que faci servir el client de backup, no pot corrompre ni modificar les còpies que ja hi ha a dins. Pot demanar que s'esborrin —si el deixes—, però no pot xifrar-les per sota.
La verificació ajuda i no n'hi ha prou (ho diu Proxmox, no nosaltres)
Les tasques de verificació comproven que les dades continuen quadrant amb els SHA-256 registrats, així que si alguna cosa comença a xifrar còpies per dins, comencen a fallar. És un senyal boníssim i barat. Però la documentació de Proxmox afegeix una frase important: un ransomware prou avançat podria eludir aquest mecanisme, i per tant la verificació és una mesura addicional, no suficient.
El mateix amb els avisos: si l'origen acaba xifrat, és probable que les tasques de sincronització fallin i salti la notificació d'error. Això és detecció per efecte secundari: arriba tard i només de vegades. Convé tenir-la i convé no recolzar-s'hi.
El que NO et direm
- ✗Que desmarquis el «Protected». Continua posat. Protegeix d'allò que sempre ha protegit: de nosaltres. I això passa molt més sovint que un atac dirigit.
- ✗Que això sigui urgent per a tothom. Si les teves còpies ja surten a un PBS amb un token sense permís d'esborrat i el prune viu al servidor, aquest post et confirma que ho tenies bé i no has de fer res aquesta setmana.
- ✗Que calgui comprar res. Tot el de la llista de dalt són permisos, un namespace i una casella en una tasca de sincronització. S'arregla en una tarda. Som part interessada —venem backup gestionat— i tot i així el que cal fer aquí és gratis.
Les quatre preguntes que fem nosaltres
Quan entrem a revisar un entorn Proxmox aliè, el bloc de backup es despatxa amb quatre preguntes. Totes quatre es responen mirant, no preguntant:
- ?Amb quina credencial escriu el clúster al destí de backup, i pot aquesta credencial esborrar? Si la resposta és «amb la de root» o «no ho sé», ja saps per on començar.
- ?Qui executa la retenció? Si el prune el llança el client, el client esborra.
- ?Existeix una còpia a la qual no es pugui arribar des del clúster? Un altre PBS que estira en comptes de rebre, cinta, una altra ubicació. Si a tot s'hi arriba des del mateix lloc, hi ha una còpia, no dues.
- ?Quan es va restaurar per última vegada, i on? Restaurar sobre l'original no és una prova, és un segon incident.
La quarta és la que més vegades es respon amb silenci. Ja vam escriure sobre el registre de la propietat de Romania, on l'atacant va entrar amb credencials vàlides i va esborrar tot el que tenia a l'abast: el patró és sempre el mateix, i el que salva no és la casella, és la distància. I si estàs muntant el clúster ara, la resta de decisions que prenem en producció són al nostre checklist de hardening de Proxmox VE 9.2.
En curt
Pay2Key no ha trencat res de Proxmox. Ha llegit la documentació i ha fet servir l'API tal com està publicada, cosa bastant més incòmoda. La lliçó és deixar de demanar-li al protected una cosa que mai no va prometre: un pestell i una porta blindada s'assemblen molt fins al dia que empenyen. La porta blindada, a Proxmox, es diu «un permís que el clúster no té».
Fonts (verificades una a una): anàlisi de la variant Linux de Pay2Key, ordres de Proxmox utilitzades, ChaCha20/Curve25519 i atribució (l'FBI, CISA i el DC3 la van valorar com a operació d'informació iraniana l'agost de 2024) — Halcyon; permisos de PUT i DELETE sobre /nodes/{node}/storage/{storage}/content/{volume}, funció check_volume_access, protection_file_path i archive_remove — codi font de pve-storage (Content.pm i Storage.pm); Datastore.Backup, prune al servidor, tokens per namespace, sincronització sense propagar esborrats, no reescriptura de blocs i límits de la verificació — documentació de Proxmox Backup Server 4.2.
Saps si el teu clúster pot esborrar els seus propis backups?
A everyWAN operem Proxmox VE amb Ceph en producció i gestionem còpies amb PBS i Veeam, amb filosofia 3-2-1. Revisem permisos, retenció i distància de les teves còpies, i també et diem quan ja ho tens bé. Mira el nostre servei de ciberseguretat i de disaster recovery.
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN