Brochettes de Sécurité
Ah, François. Come here and take a look at this. The theme of this issue is security, and I have developed a menu around that very theme. Quoi? But of course it is not about networks. Do you know, mon ami, what the most important part of running a successful restaurant is? Bien sûr, a well-stocked wine cellar is important—I agree with you, but I was thinking about the food, François. You see, our guests, they hunger for many things, and it is our duty as restaurateurs to make sure that their taste buds are constantly stimulated in ways they do not expect.
Qu'est-ce que tu dis? François, security is a many-faceted aspect of cooking with Linux. Network security is but one such item, and everyone no doubt will be thinking network security. By selecting different ingredients, we keep the palate alert and refreshed. For instance, look at this first item. You cannot deny its security implications and yet—François, why are you not paying attention? Eh? Ah, mais pardon, I see our guests have arrived. Please, everyone, sit down. I shall have François fetch some wine immédiatement.
François! We have a 1998 Clos de Vougeot in the cellar that I think will satisfy everyone's taste buds tonight and add a special air of je ne sais quoi. A lovely Burgundy, mes amis. Vite, François. Vite!
François and I were discussing different ways to look at the concept of security. When we cook with Linux, we have all gotten used to thinking of “security” as network security but, as a visit to Monsieur Roget and his famous thesaurus will tell you, security can mean many other things. You will find words like bond, debenture, deposit, bail, hostage, plight, authentication and receipt, just to name a few. And what about the security you enjoy in knowing that you make regular backups? You do make regular backups, non? Then, we have job security, the kind of security you experience knowing you make regular backups. A little joke, non?
In all seriousness, losing a file can still happen, and what if your last backup was last night or even two hours ago? Despite good habits and a healthy attraction to job security, you still have lost your file. What can you do? Common wisdom, as they say, informs us that if we delete a file from our Linux systems, that is all, mes amis. It is gone forever. However, that is only partially true. It is possible to bring back a file. Observe.
On my test system, I have a small drive mounted on /mnt/tinydrive. If I use the command
I get the following information:
/dev/hdd6 42913 9063 31634 22% /mnt/tinydriveI told you that it was small, non? On this small drive, I created some directories and files. One file is called cabernet, and it contains my family's Cabernet secrets. Actually, it does not contain any such thing, but it sounds so mysterious. Speaking of Cabernets, François has returned with the Burgundy.
Now, if I list this file, it shows up like this:
$ ls -l -rw-r--r-- 1 marcel wines 77 Jun 21 04:38 cabernet
At 77 bytes, you know the secret is elegant. Now, if I remove this file with rm cabernet, it is gone for good, and it cannot be read. And yet, with a little perseverance and luck, you can bring the file back as I will show you. It is important to unmount the drive in question immediately (or shut down if the file is on your root drive):
umount /mnt/tinydriveThe more time that elapses (and consequently, the more data that gets written to the disk) from the time you delete a file, the slimmer your chances of recovering it completely.
In order to attempt a rescue of the data in question, I use a program called debugfs. Have no fear, mes amis. You will find this command on your system. It is part of the e2fsprogs package:
# debugfs /dev/hdd6 debugfs 1.14, 9-Jan-1999 for EXT2 FS 0.5b, 95/08/09 debugfs:
If I type lsdel at the debugfs prompt, I will get a listing that looks something like this:
7665 0 100644 5248 6/ 6 Thu Apr 19 18:05:30 2001 32 500 100600 12288 12/ 12 Thu Jun 21 04:38:39 2001 158 500 100644 78 1/ 1 Thu Jun 21 04:38:39 2001 157 500 100644 77 1/ 1 Thu Jun 21 04:40:25 2001The first column is the file's inode. The second column is the UID of the owner. Since my UID was 500, and my accidental deletion occurred on Thursday the 21st, it is starting to look like my file might be one of those listed. Furthermore, I recall that my file was 77 bytes long. There are no filenames listed so as you can imagine, the more details you know about the original file, the better. Still at the debugfs: prompt, I enter the following:
debugfs: dump <157> /home/marcel/cabsThe 157 is the inode number, and /home/marcel/cabs is a file on another (still) mounted filesystem. By using the dump command to debugfs, I can redirect the contents of inode 157 to a new file called cabs. Now, let us look at the results of this operation:
$ cat /home/marcel/cabs Why try making fine Cabernets when you can buy them from Henri's Fine Wines?Mais non! The secret is out!
Another tool you might find useful to restore those lost files is a little program called recover. Written by Tom Pycke, recover makes the whole process of trying to work your way through what can be an incredibly long list of deleted inodes quite a bit easier, one might say virtually painless. To get a copy of recover, head on over to recover.sourceforge.net/linux/recover. Download the latest source, then extract and build it. It is all very easy:
tar -xzvf recover-1.3.tar.gz cd recover-1.3 make make install
To use the program, you can simply type recover, and it will scan for the various filesystems available on your system. You can also have it start with the appropriate filesystem by specifying it on the command line. What follows is a question-and-answer session designed to narrow down your deleted file without having to go through a huge listing. The recover program massages the data for you. Here is an example:
# recover /dev/hdd6 Recover v1.3 by Tom Pycke <Tom.Pycke@advalvas.be> Getting inodes (this can take some time)... debugfs 1.14, 9-Jan-1999 for EXT2 FS 0.5b, 95/08/09 In what year did you delete the file? (eg. 1999): 2001The program then asks for the month followed by a date and time range as well as a range of possible file sizes. When everything had been answered, I received the following output:
=> 158 78 JUN THU 21 4:38:39 2001 => 157 77 JUN THU 21 4:40:25 2001 2 inodes found. Where shall i dump them? (directory): /tmpThe files will get named dump157 and dump158. All that is left is to view their contents with cat. On the off chance that these may be binary files, it might make sense to use the file command first.
Security has another side as we well know (and as Monsieur Roget figured out as well). We may be secure in the knowledge that we can recover a deleted file from our ext2fs filesystem, but what of the other side? What if the information in the file was of a top-secret nature, and I did not want to risk having anyone ever see this file again? What if I would rather have this file disappear into some dark region completely inhospitable to proper viticulture? There could be implications of international security should this information get out.
If your system contains a recent version of the fileutils package (which contains programs like cp, mv, etc.), the solution is at hand. You will find a program called shred that will take your file and, ahem, shred it:
$ shred secret_instructions
If I use the command as above, the file secret_instructions will be secret indeed, but it will not be deleted. It will, however, be scrambled, much like a well-whisked omelette. For the truly security-conscious, it may be better to use this version of the command:
$ shred -z -u secret_instructionsIn addition to scrambling, the program will overwrite the file with null characters (the -z flag), then remove it completely (-u). Your secrets are safe, mes amis.
We started today's culinary exploration with a slight hint of backups. Let us say then, that you archive your data to tapes regularly (a very good idea—I must commend you, mes amis). Those tapes are then moved safely to off-site storage. You may well have backed up those secret files that you so desperately wish to remove from your system. Let us pretend that I have archived the /etc/profile file using tar:
tar -cvf /tmp/profile.tar /etc/profile
That simple tar file is quite transparent:
$ more /tmp/profile.tar etc/profile01006440000000000000000000001163072353 262310117170 ustar rootroot # /etc/profileAs you can see, the contents of the file or files that exist are visible on the archive. But of course, mes amis, I know that I could simply extract the files with a little
tar -xvf filename.tarbut I wish to illustrate a point. What if all our tar archives were encrypted? This is the idea behind sectar, a secure extension to GNU tar written by Brian Wagener and Katrina Illari. You can pick up the latest sectar from sourceforge.net/projects/star.
You will need two packages. One is a patched version of the GNU tar release. The second is sectar. Start by extracting the tar package and building it:
tar -xzvf tar_sectar.tar.gz cd tar-1.13 make make install
This is almost identical to the original tar package you have on your system, except for a very interesting option. If you type
/usr/local/bin/tar --helpyou will notice the following:
-e, --encrypt filter the archive through encryptorAh, the mystery...but to use this feature, you must first build the sectar package. Using the latest source, I followed these steps:
tar -xzvf sectar-1.02.tar.gz cd sectar-1.02 make make installUsing this newfound power of encryption, I will re-create my top-secret archive:
$ tar -ecvf /tmp/profile.tar /etc/profile The 256 bit key created is keyfile.993515072I can now take this keyfile (which is located in my working directory) and save it to a diskette or secure location for the day when I need to restore my file. If the keyfile is in place, then extracting data from the tar file is a breeze. However, in the absence of the keyfile, your information remains secret. When we look through this archive again (sans keyfile of course), what we see is garbled, unreadable and certainment unprintable.
Once again, mes amis, the time, she is late and we must all start thinking about going to our respective homes. You too, François. But before you do, please refill our guests' glasses. All this intrigue has no doubt done little to slake their thirsts. Unlike Monsieur Bond, pour the wine gently, neither stirred nor shaken. Wonderful. Merci, François.
Mes amis, it has been a pleasure once again to serve you here at Chez Marcel. Do remember to join us again next time. François will have your table waiting.
A votre santé! Bon appétit!
Webinar: 8 Signs You’re Beyond Cron
11am CDT, April 29th
Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.Join us!
|Android Candy: Intercoms||Apr 23, 2015|
|"No Reboot" Kernel Patching - And Why You Should Care||Apr 22, 2015|
|Return of the Mac||Apr 20, 2015|
|DevOps: Better Than the Sum of Its Parts||Apr 20, 2015|
|Play for Me, Jarvis||Apr 16, 2015|
|Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites||Apr 15, 2015|
- Tips for Optimizing Linux Memory Usage
- "No Reboot" Kernel Patching - And Why You Should Care
- DevOps: Better Than the Sum of Its Parts
- Return of the Mac
- Android Candy: Intercoms
- Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites
- Non-Linux FOSS: .NET?
- Play for Me, Jarvis
- Designing Foils with XFLR5