Réponses:
Utilisez la find
commande pour exécuter shred
récursivement:
find <dir> -type f -exec shred {} \;
man shred
.
srm
la réponse de @ Cookie tentera au moins de résoudre ce problème).
-exec shred {} +
pour le rendre plus rapide car shred accepte plusieurs arguments.
Attention aux lambeaux!
De la page de manuel shred:
ATTENTION: notez que shred repose sur une hypothèse très importante: le système de fichiers écrase les données en place. C'est la manière traditionnelle de faire les choses, mais de nombreux systèmes de fichiers modernes ne répondent pas à cette hypothèse. Voici des exemples de systèmes de fichiers sur lesquels shred n’est pas efficace ou n’est pas toujours efficace dans tous les modes de système de fichiers:
Systèmes de fichiers journalisés, tels que ceux fournis avec AIX et Solaris (et JFS, ReiserFS, XFS, Ext3, etc.)
Systèmes de fichiers qui écrivent des données redondantes et continuent même si certaines écritures échouent, tels que les systèmes de fichiers basés sur RAID
systèmes de fichiers qui créent des instantanés, tels que le serveur NFS de Network Appliance
systèmes de fichiers en cache dans des emplacements temporaires, tels que les clients NFS version 3
systèmes de fichiers compressés
Dans le cas des systèmes de fichiers ext3, la clause de non-responsabilité ci-dessus s'applique (et l'efficacité de shred est donc limitée) uniquement en mode data = journal, journal qui enregistre des données en plus des métadonnées. Dans les modes données = ordonné (par défaut) et données = écriture, shred fonctionne normalement. Les modes de journalisation Ext3 peuvent être modifiés en ajoutant l'option data = quelque chose aux options de montage d'un système de fichiers particulier dans le fichier / etc / fstab, comme indiqué dans la page de manuel de mount (man mount).
De plus, les sauvegardes du système de fichiers et les miroirs distants peuvent contenir des copies du fichier qui ne peuvent pas être supprimées et qui permettront de récupérer ultérieurement un fichier déchiqueté.
Solution: Utilisez un système de fichiers chiffré et supprimez simplement vos fichiers.
shred
et le cryptage des données empêchent la lecture des données sur un périphérique de stockage hors connexion (pensez vol ou police), le cryptage des données offrant l'avantage supplémentaire de protéger tous les fichiers, pas seulement ceux qui ont été supprimés (correctement). Une fois le système de fichiers monté, nous retrouvons de bonnes anciennes autorisations Unix dans les deux cas, et la protection des données redevient une tâche de la sécurité du système d'exploitation et de la bonne administration du système. Le chiffrement de système de fichiers d'Upfront n'est certainement pas pire en termes de protection des données au repos que d'utilisation stratégique shred
!
Utilisez plutôt la suppression sécurisée.
sudo apt-get install secure-delete
srm -r pathname
Terminé. La suppression sécurisée est beaucoup plus paranoïaque que shred, avec 38 passages au lieu de 3. Pour effectuer un passage rapide, utilisez
srm -rfll pathname
fll vous fournit un générateur de données moins aléatoire, et un seul passage.
find
méthodes proposées qui essaieront également d’effacer les noms de fichiers stockés en renommant les fichiers avant de les tronquer et de les dissocier.
En combinant cette réponse avec les options les plus connues pour le déchiquetage, utilisez ce lien de débordement de pile " Suppression de fichiers de manière permanente et sécurisée sur CentOS ":
find <directory> -depth -type f -exec shred -v -n 1 -z -u {} \;
Éditer: Sachez que la meilleure solution pour détruire un fichier unique impose une synchronisation qui enregistre les modifications sur le support avant de supprimer le fichier car certains systèmes de fichiers journalisés, voire tous, disposent d’un tampon.
Si possible, la commande find devrait appeler un script shell sur le fichier qui s'exécute:
shred -v -n 1 /path/to/your/file #overwriting with random data
sync #forcing a sync of the buffers to the disk
shred -v -n 0 -z -u /path/to/your/file #overwriting with zeroes and remove the file
sur chaque fichier.
rm -rvf $1
au script shell (où $ 1 est le fichier / path / to / votre / fichier transmis à partir de l' {}
extension find... -exec
)
depth
ici? Aussi incertain à propos de la barre oblique inverse de fin
find /your/directory -exec shred {} \;
find [dirname] -depth -type f -exec shred -n1 {} \;
Ceci effectue une recherche en profondeur des fichiers dans le répertoire [nom du répertoire], puis exécute la shred -n1
commande sur chaque fichier. Lors de la suppression de fichiers et / ou de répertoires, l'ajout -depth
par défaut est une bonne habitude, même si cela n'est pas strictement nécessaire dans ce cas. Lors de l'exécution de ce type de commande avec, rm -rf
au lieu de shred
, il -depth
est nécessaire de s'assurer que les répertoires ne sont pas supprimés avant que le contenu des répertoires ne soit supprimé (ce qui provoque des erreurs).
shred -N 1
, car la valeur par défaut, le déchiquetage 3 fois, est l'huile de serpent. Soit une fois suffit, soit 30 fois ne fonctionnent pas.
La shred
méthode la plus complète que j'ai trouvée, qui inclut également la suppression de répertoire, consiste à find
appeler un script pour avoir shred
:
Cette méthode gère également correctement les noms de fichiers contenant des espaces.
Tout d'abord - le shred
script (j'ai nommé le mien dirShredder.sh
et je l'ai stocké dans le /root
répertoire:
shred -v -n 1 "$1" #overwriting with random data
sync #forcing a sync of the buffers to the disk
shred -v -n 0 -z -u "$1" #overwriting with zeroes and remove the file
rm -rvf "$1" # call rm to remove the directories
Ensuite, appelez le script comme suit:
find /volume1/pathToShred/ -mindepth 1 -depth -exec /root/dirShredder.sh "{}" \;
Assurez-vous de marquer le killit.sh
fichier executable ( chmod +x
) et bien sûr de mettre à jour le chemin du répertoire que vous voulez déchiqueter et dirShredder.sh
si vous le stockez ailleurs.
NOTA BENE - shred
présente des problèmes liés aux systèmes de fichiers de copie sur écriture (ZFS, BTRFS, etc.) et même aux systèmes de fichiers journalisés. Il n’existe pas de véritable "meilleur" moyen de traiter ce problème que j’ai trouvé, à part les "systèmes de fichiers cryptés", mais je ne suis pas sûr de l’efficacité de ce système après coup.
Le plus proche possible semble être d’écraser tous les espaces vides du disque avec des données aléatoires après vos opérations de destruction (pas de zéros, cela ne semble pas toujours fiable). De plus, les disques SSD peuvent également prendre en compte d’autres facteurs (comme TRIM).
Je n'entre pas dans ceux-ci, il y a d'autres réponses de Stack (la réponse de @user unknown dans cette question, par exemple) et de nombreuses discussions à travers le réseau qui couvrent ces sujets afin de les rechercher si vous avez besoin de ce niveau de sécurité.