Do you have files on your computer that you wouldn't want your
spouse to read, or perhaps your main competitor. Chances are if
you use your computer for work or general usage the answer is
yes. Also what happens if you want to send a file to someone, or
let them download it from you, but you only have access to a
public site (like a free web hosting company). The answer is to
encrypt the file, and fire it off. For UNIX you have several
choices, PGP, and GnuPG, as well as Guardbot for web based file
transfers. If you work with files that are sensitive (such as
spreadsheets containing sensitive financial data) the constant
hassle of encrypting and decrypting the file (as well as the fact
a decrypted copy will be stored on the filesystem, leaving a
window of opportunity for an attacker) can get tedious. If this
is the case you will want to use software such as, BestCrypt
(commercially licensed but free for Linux with source code), or
PPDD (Private and Top Secret, GPL licensed) which are both very
similar in execution and general usage.
Encrypting files and drives
PGP
Pretty Good Privacy is available as a command line driven
program for most UNIX platforms, and there are a variety of front
end GUI programs for it. I would not recommend using PGP on a
UNIX platform since a completely OpenSource, and compatible
replacement is now available, in the form of GnuPG.
GnuPG
GnuPG is a GPL licensed (a.k.a. completely free in every
respect), written in Germany (a very pro-crypto and pro-privacy
country). Since it is available in full source code chances are
it has been ported to your UNIX platform (and if not try
compiling it, it might work). You can download GnuPG as a compressed tarball of
source code, and there are links to a number of source and binary
packages for various UNIX platforms. Once installed GnuPG behaves
very similarly to PGP. The first thing you'll probably want to do
is generate a new keypair, simply use the command "gpg
--gen-key", it will create a ".gnupg" directory in
which to store your keys, option files and so on and exit, you
then run it again and it will lead you through the key creation
process. Choosing the defaults during key generation is a pretty
safe bet, although you may want to use a 2048 bit keysize
(realistically if someone manages to crack 1024 bit keys, chances
are they can get at your 2048 bit key, however if they are only
trying to brute force it a longer key is a good way to reduce the
chances of that). For personal keys the expiry is typically set
to "0" (that is to say they do not expire), however if
these keys are for corporate use, or for really sensitive
information it is a good idea to expire keys and rotate them
(every month, year, decade, whatever your security policy
dictates). The most important thing when generating a key (in my
opinion) is the passphrase. This is a string of characters which
should consist of letters (upper and lower case) numbers and
punctuation marks, the longer the better (I'd say the bare
minimum is 10 characters). This controls access to the private
key, which is used to sign items (and if compromised means an
attacker could easily impersonate you), and to decrypt data
(meaning an attacker could access all your data). Keep your
private key secure! If an attacker gains access to this key they
only have to brute force the passphrase, which is typically a lot
weaker then a random 1024 bit (or longer) key. Worse yet they may
steal your passphrase, with a keyboard sniffer or similar attack,
resulting in a compromise of your key. If the attacker does not
have access to your private key they will be forced to guess it,
which takes a brutally long time (on average however, there is a
chance they may guess the key correctly on their first try).
Signing files is useful if you want to distribute a file to
someone, and be able to prove that you sent it, and it was not
tampered with. Internally GnuPG takes a hash sum (such as MD5 or
SHA1) of the file (basically it reduces the file to a shorter,
unique string of data) which it then encrypts with your private
key, generating a signature. This signature can then be decrypted
with your public key, resulting in possession of the hash sum of
the file, simply take the hash sum of the file in question, and
if the they match, then obviously the file is what it claims to
be. This signature file can be a binary file, or converted into
text (for example signing email, or distributing file signatures
via email). To sign a file with gpg simply use:
$ gpg -b file
which will create a detached signature of the file.
To verify the signature use "gpg --verify file.sig
file". If all is well you should see something like:
$ gpg --verify file.sig file
gpg: Signature made Sat 15 Jan 2000 05:23:31 AM MST using DSA key ID 47D0D9A8
gpg: Good signature from "Kurt Seifried <seifried@securityportal.com>"
If someone has fiddled with the file or signature you will see
something like:
$ gpg --verify file.sig file
gpg: Signature made Sat 15 Jan 2000 05:23:31 AM MST using DSA key ID 47D0D9A8
gpg: BAD signature from "Kurt Seifried <seifried@securityportal.com>"
Encrypting files is also relatively simple, a person uses your
public key to run the data through a one way algorithm which
results in a seemingly random mishmash of data, you can then use
your private key to recover what the original data was, thus
decrypting it. To encrypt a file to someone you first need their
public key, you can download it from their homepage (if they have
it online of course), or you can go to a public key server, of
which there are many:
Once you have their key it is simply a matter of signing and
encrypting the file (just encrypting the file is rare as there is
no proof of who the data is from, unless you use some other
method, like physically handing them a floppy disk with the
encrypted file). The following is an example of me signing a file
and encrypting it with my public key:
$ gpg -s -e file
You need a passphrase to unlock the secret key for
user: "Kurt Seifried <seifried@securityportal.com>"
1024-bit DSA key, ID 47D0D9A8, created 2000-01-15
You did not specify a user ID. (you may use "-r")
Enter the user ID: seifried@securityportal.com
The user ID can either be the key ID (such as: 47D0D9A8), the
email address associated with the key (seifried@securityportal.com)or
the name (not recommended as these are not unique, there are many
John Smith's). You will end up with a "file.gpg" that
is binary, if you wish to send the file via email it is advisable
to use the "-a" ("--armor") option which will
result in "file.asc" and is ASCII text, so you can read
it straight into an email, or print it out, mail it, and let them
OCR and decrypt it at their end. To decrypt a file sent to you
simply:
$ gpg --decrypt file.asc
You need a passphrase to unlock the secret key for
user: "Kurt Seifried <seifried@securityportal.com>"
1024-bit ELG-E key, ID 47D0D9A8, created 2000-01-15 (main key ID 39B0D9A8)
and it will display the file (hopefully a text file) to your
screen, followed by the veracity of the signature (if you have
the persons public key):
gpg: Signature made Sat 15 Jan 2000 06:06:19 AM MST using DSA key ID 47D0D9A8
gpg: Good signature from "Kurt Seifried <seifried@securityportal.com>"
if you want to save the decrypted file simply use
"--output filename" and it will dump the content to
"filename". You can also use shell commands such as
"|" or ">" to further mangle the output
(this is useful if you have automated systems such as a reporting
mechanism which sends encrypted emails to a central repository).
BestCrypt
BestCrypt is a disk encryption program available for Windows
and Linux. The nice thing is you can create an encrypted
container (a file that is then mounted as a filesystem), and use
it in Windows or in Linux (as long as it resides on a partition
accessible to both, so putting it on your Windows partition is
fine since Linux reads almost all Windows partition types).
BestCrypt consists of some kernel modules (so your kernel will
need to support loadable kernel modules obviously, and it helps
if you are using tools like depmod, modprobe and the kernel
module loader), and a userspace utility called
"bctool". This program is however officially in
"beta testing" for Linux, and probably should not be
used for critical data (if it is, make sure you have backups).
After testing BestCrypt for Linux I am satisfied that even though
the software is officially beta, it is probably stable enough for
most users, however your mileage may vary, all sales final, and
don't blame me for any lost data. The only real problem with
BestCrypt is a severe lack of documentation, while there is a man
page that explains basic options, there is not a single example
of how to create and mount a container (I suspect the release
will have documentation, their Windows version documentation is
quite good, a half meg helpfile). You need to download the
software first, available as a source tarball, and source rpm
(very easy to install on an RPM based system). Simply download
either one, I would recommend the source rpm if you can.
#rpm -Uvh/usr/src/redhat/RPMS/i386/BestCrypt-0.3b-1.i386.rp m
BestCrypt ##################################################
If you do not have an RPM based system, or the source RPM
doesn't work for you, compiling the source code directly from
it's tarball should be possible. Simply download the file, unpack
it to an appropriate place (such as/usr/local/src) and issue the
commands:
#make
#make install
And you should be up and running. The first step is to create
a container (a file that is encrypted and mounted as a
partition):
# bctool new -a blowfish -s 10M file
Enter password:
Verify password:
You can of course use the "gost" or "des"
algorithms, I would not recommend them as gost is less tested
then the "twofish" and "blowfish" algorithms
that BestCrypt supports, and single des is to easy to brute
force. The next step is to format the container, you'll probably
want to use msdos if sharing with Windows (i.e. a dualboot Linux
and Windows machine), or if just Linux then ext2 is a good bet.
You can also specify the size, if you make it so small this can
be a problem, but because it is a file and not a true partition
you can easily create a new, larger file, move all the data to it
and use it instead of the older smaller one.
# bctool format -t ext2 file
Enter password:
mke2fs 1.15, 18-Jul-1999 for EXT2 FS 0.5b, 95/08/09
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
2560 inodes, 10238 blocks
511 blocks (4.99%) reserved for the super user
First data block=1
2 block groups
8192 blocks per group, 8192 fragments per group
1280 inodes per group
Superblock backups stored on blocks:
8193
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
Once the file is formatted you should be able to mount it:
# bctool mount file/root/crypt/
Enter password:
# df
Filesystem 1k-blocks Used Available Use% Mounted on/dev/hda1 3122956 70596 2893720 2% //dev/hda2 2917360 24224 2744940 1%/crypto/root/file 9909 13 9385 0%/root/crypt
As you can see it is mounted as a part of the filesystem, just
like a floppy disk would be for example. Remember to control
access to the directory hosting the encrypted files carefully, no
matter how good the encryption, if you have it set world readable
you won't have gained any security. Also remember that as a user,
root owns the / and can take ownership of any file or directory
and see what's in it. Alternatively if an attacker gains root
access they can log your keystrokes (or terminal traffic) and
gain your password (and access to your files). As always your
security is only as good as the weakest link.
PPDD
PPDD is similar to
BestCrypt, but instead of creating a file, encrypting that and
mounting it, it actually uses a partition which is encrypted and
mounted using the PPDD driver, because of this it can do a few
additional things BestCrypt can't. If you only want to encrypt a
few directories then I advise compiling PPDD as a kernel module,
but if you want to encrypt the entire file system (including what
you boot from) you will need to compile PPDD directly into the
kernel (although as of 1.0 it's not to hard). Unless you have a
GPL only policy I would recommend using BestCrypt if you are new
to this (it is easier to install and use, and you can buy
support). PPDD does have one enormous advantage over BestCrypt
however, you can encrypt all of the system, including the boot
drive and swap partition, making it ideal for situations such as
laptops with sensitive data and minimizing the risk (to zero if
need be) of accidentally leaving sensitive data in an unencrypted
location (such as the swap file,/tmp, and so on) so if you need
a higher security level I would recommend PPDD over BestCrypt
(simply because you can encrypt everything). Another advantage of
PPDD is that is uses two passwords instead of just one for each
encrypted filesystem, so you can give one administrator one
password, and another administrator the other password, meaning
no single person can gain access to the data. Unfortunately as of
the writing of this chapter PPDD is not available for kernel
2.2.13 or 2.2.14, so you will have to run the older 2.2.12 kernel
(which is the stock kernel on many distributions in any case).
Download PPDD, and unpack it in a suitable location, such as/usr/local/src/, there are several files you should read, most
notable the README file, and once done install I would recommend
reading the PPDDHow.txt file. Installation is rather simply with:
This will first test the kernel source to make sure it's the
right version and so on, then it will test the patches, then
apply the patches proper, and then create the devices needed
(similar to what BestCrypt does). At this point you need to
recompile your kernel, first make sure you go into the
configuration (via make config or make menuconfig or make
xconfig), and enable the PPDD driver (in the Block devices
section). Then save the config file and recompile the kernel as
your normally would. Once that is done you will have to install
the new kernel (copy it to/boot typically, edit lilo.conf and
rerun lilo). Once you have rebooted you will want to build the
tools for PPDD and install them with:
#make
#make install
At this point you should be ready to use it, however I would
recommend running the tests with:
#make test
They take a while to run, but it will save frustration later
on if something is broken. Using PPDD is relatively simple, there
are a number of utilities for creating, managing, encrypting file
systems, and so on. You will also want to set the permissions and
ownership on the/dev/xxxx that contains your encrypted data so
that only root has access to it, PPDD will complain otherwise
At this point you should have a directory called/crypt which
is/dev/hda3 (although on df and the like it will show up as/dev/ppddx). I will cover how to encrypt you entire filesystem
with PPDD, at a later date however (it is extensively documented
though).
Guardbot
Another new possibility is Guardbot,
which password protects www pages. Essentially there are two
components, an applet that encrypts the data, using DES (56 bit
keyspace), and an applet that will decrypt the data with the
password you provide. The advantage of this over traditional
server based methods of control (such as htaccess in Apache) is
that the user manages it fully, and can protect each file
individually without much setup. To fully take advantage of the
keyspace available your password must contain upper and lower
case letters, numbers (and punctuation marks, but this can
confuse users) of around 10 letters, however since people tend to
choose less then random passwords a longer password then this is
advisable. This program would be useful for getting files to
other people cheaply (simply sign up for some free web space,
post the file up, and get the password to the other person
securely).
Hiding files and data on your computer
It is no longer enough in some countries to encrypt your data
to prevent access to it. Recently in Britain a law was created
making it a criminal offence to refuse to give up encryption keys
or plain text versions of encrypted data.
StegHide
StegHide hides data in files such as sound and picture files
where not all of the bits in a byte are used. Since the data is
encrypted it will appear random, and proving that the data is
actually there is difficult. The only downside is to store a one
megabyte file you need a sound/picture file of several megabytes,
which can be cumbersome (but hard drives and high speed access
are becoming cheap so it's a moot point). You can get StegHide
at: http://www.stego.com/.
StegFS
Steganographic File System actually hides data on your
harddrive, making it difficult to prove that it even exists. This
can be very useful as the attacker first has to find the data,
let alone break the strong encryption used to protect it. You can
get StegFS from: http://ban.joh.cam.ac.uk/~adm36/StegFS/& lt;/a>.
OutGuess
OutGuess hides data in image files, meaning you can send files
in a way that won't attract to much attention (and can't really
be prooved either). You can get it from: http://www.outguess.org/.
Sure you can do web hosting with named virtual hosts, several hundred sites per IP, and it works fine. But what happens when sites start hosting more and more SSL secured websites (i.e. https://store.example.org/)? SSL works at the transport layer, you cannot host multiple domains off of one IP address. Will an exemption be made for this (i.e. I need a CIDR because I want to host a lot of secure websites?). Making it harder for people to implement SSL secured websites will only hurt the Internet, making it a much less secure place to do business, and ultimately stifle growth (well a little bit anyways). Thank you for your consideration.
Wow, got slashdotted, this is pretty nifty (and our servers are handling it well this time which is nice). Anyways there's a lot of comments I feel I should respond to, so here goes:
The debian/Slackware issue: Debian has "official" releases like every 2 years, thus generating stats on it are near impossible. I know the distro is maintained (read: http://www.securitypo rtal.com/lskb/articles/kben10000078.html, I am well aware of how dpkg/etc works. Here's the thing, you will never release a bug free software package, especially something like Debian which has a lot of packages. Like kernel 1.0 it's sometimes just best to shove it out the door and give users something a lot better then the last "officially stable" release. Side note: looks like Debian will release the next major one before 2.4, meaning it'll be another year or two before "stable" gets a 2.4 kernel, sigh). As for slackware I don't know anyone using it in a production environment anymore (there probably are..). I used Slackware for.. about 2 years when I started out, it is not something I'd want to put on 10 machines and maintain.
As for default installs, guess what, most admins do leave the defaults. Many people simply don't realize how dangerous these services are, or that they really need to be kept up to date. A default install like OpenBSD, secure by default, requires the admin to do things to make it less secure, (admitedly OpenBSD 2.7 with no security patches has a number of holes that are pretty serious). SOmething like %50 of machines on the Internet are insecure, why? A lot of them are simply because the default OS install was done and very few (or no) updates. Taking care of one machine at home isn't to bad, I have to care and feed 6 linux servers for my personal network, and sometimes I forget to do things, I'm only human (and I like to sleep 8 hours a day).
Good response for what? Red Hat isn't a distro for the people who want the latest and greatest updates as soon as possible. It's a distro for those who require a very tested solution. That's why Red Hat is often behind on the technology by the time it gets to.2, because they're focusing on the testing.
Leaving your users hanging in the wind for 2 weeks with a local root exploit is not good. Yes I know 2.2.16 has a ton of problems, but you should be giving customers the choice, not just leaving them in the lurch with no update.
As for Caldera/Turbo, Caldera is a pretty popular corporate distro, and Turbo is huge in asia (remember, there's more to the world then just the US market).
Note to slashdot: make the *******ing text entry box bigger!!!!! like 80 by 40 would be nice.
Slashdot Mirror
That HOWTO is good, but severely out of date. To quote Cha pte r 10 - Encrypting files and drives in Linux, BSD, and other Unices"
Chapter 10 - Encrypting files and drives in Linux, BSD, and other UnicesBy: Kurt Seifried, seifried@securityportal.com, for http://www.securityportal.com/
; OverviewDo you have files on your computer that you wouldn't want your spouse to read, or perhaps your main competitor. Chances are if you use your computer for work or general usage the answer is yes. Also what happens if you want to send a file to someone, or let them download it from you, but you only have access to a public site (like a free web hosting company). The answer is to encrypt the file, and fire it off. For UNIX you have several choices, PGP, and GnuPG, as well as Guardbot for web based file transfers. If you work with files that are sensitive (such as spreadsheets containing sensitive financial data) the constant hassle of encrypting and decrypting the file (as well as the fact a decrypted copy will be stored on the filesystem, leaving a window of opportunity for an attacker) can get tedious. If this is the case you will want to use software such as, BestCrypt (commercially licensed but free for Linux with source code), or PPDD (Private and Top Secret, GPL licensed) which are both very similar in execution and general usage.
Encrypting files and drives PGPPretty Good Privacy is available as a command line driven program for most UNIX platforms, and there are a variety of front end GUI programs for it. I would not recommend using PGP on a UNIX platform since a completely OpenSource, and compatible replacement is now available, in the form of GnuPG.
GnuPGGnuPG is a GPL licensed (a.k.a. completely free in every respect), written in Germany (a very pro-crypto and pro-privacy country). Since it is available in full source code chances are it has been ported to your UNIX platform (and if not try compiling it, it might work). You can download GnuPG as a compressed tarball of source code, and there are links to a number of source and binary packages for various UNIX platforms. Once installed GnuPG behaves very similarly to PGP. The first thing you'll probably want to do is generate a new keypair, simply use the command "gpg --gen-key", it will create a ".gnupg" directory in which to store your keys, option files and so on and exit, you then run it again and it will lead you through the key creation process. Choosing the defaults during key generation is a pretty safe bet, although you may want to use a 2048 bit keysize (realistically if someone manages to crack 1024 bit keys, chances are they can get at your 2048 bit key, however if they are only trying to brute force it a longer key is a good way to reduce the chances of that). For personal keys the expiry is typically set to "0" (that is to say they do not expire), however if these keys are for corporate use, or for really sensitive information it is a good idea to expire keys and rotate them (every month, year, decade, whatever your security policy dictates). The most important thing when generating a key (in my opinion) is the passphrase. This is a string of characters which should consist of letters (upper and lower case) numbers and punctuation marks, the longer the better (I'd say the bare minimum is 10 characters). This controls access to the private key, which is used to sign items (and if compromised means an attacker could easily impersonate you), and to decrypt data (meaning an attacker could access all your data). Keep your private key secure! If an attacker gains access to this key they only have to brute force the passphrase, which is typically a lot weaker then a random 1024 bit (or longer) key. Worse yet they may steal your passphrase, with a keyboard sniffer or similar attack, resulting in a compromise of your key. If the attacker does not have access to your private key they will be forced to guess it, which takes a brutally long time (on average however, there is a chance they may guess the key correctly on their first try).
Signing files is useful if you want to distribute a file to someone, and be able to prove that you sent it, and it was not tampered with. Internally GnuPG takes a hash sum (such as MD5 or SHA1) of the file (basically it reduces the file to a shorter, unique string of data) which it then encrypts with your private key, generating a signature. This signature can then be decrypted with your public key, resulting in possession of the hash sum of the file, simply take the hash sum of the file in question, and if the they match, then obviously the file is what it claims to be. This signature file can be a binary file, or converted into text (for example signing email, or distributing file signatures via email). To sign a file with gpg simply use :
$ gpg -b filewhich will create a detached signature of the file.
To verify the signature use "gpg --verify file.sig file". If all is well you should see something like:
$ gpg --verify file.sig file gpg: Signature made Sat 15 Jan 2000 05:23:31 AM MST using DSA key ID 47D0D9A8 gpg: Good signature from "Kurt Seifried <seifried@securityportal.com>"If someone has fiddled with the file or signature you will see something like:
$ gpg --verify file.sig file gpg: Signature made Sat 15 Jan 2000 05:23:31 AM MST using DSA key ID 47D0D9A8 gpg: BAD signature from "Kurt Seifried <seifried@securityportal.com>"Encrypting files is also relatively simple, a person uses your public key to run the data through a one way algorithm which results in a seemingly random mishmash of data, you can then use your private key to recover what the original data was, thus decrypting it. To encrypt a file to someone you first need their public key, you can download it from their homepage (if they have it online of course), or you can go to a public key server, of which there are many:
http://pgp.ai.mit.edu/ - PGP key server
http://www.keyserver.net/ - OpenPGP key server
Once you have their key it is simply a matter of signing and encrypting the file (just encrypting the file is rare as there is no proof of who the data is from, unless you use some other method, like physically handing them a floppy disk with the encrypted file). The following is an example of me signing a file and encrypting it with my public key:
$ gpg -s -e file You need a passphrase to unlock the secret key for user: "Kurt Seifried <seifried@securityportal.com>" 1024-bit DSA key, ID 47D0D9A8, created 2000-01-15 You did not specify a user ID. (you may use "-r") Enter the user ID: seifried@securityportal.comThe user ID can either be the key ID (such as: 47D0D9A8), the email address associated with the key (seifried@securityportal.com)or the name (not recommended as these are not unique, there are many John Smith's). You will end up with a "file.gpg" that is binary, if you wish to send the file via email it is advisable to use the "-a" ("--armor") option which will result in "file.asc" and is ASCII text, so you can read it straight into an email, or print it out, mail it, and let them OCR and decrypt it at their end. To decrypt a file sent to you simply:
$ gpg --decrypt file.asc You need a passphrase to unlock the secret key for user: "Kurt Seifried <seifried@securityportal.com>" 1024-bit ELG-E key, ID 47D0D9A8, created 2000-01-15 (main key ID 39B0D9A8)and it will display the file (hopefully a text file) to your screen, followed by the veracity of the signature (if you have the persons public key):
gpg: Signature made Sat 15 Jan 2000 06:06:19 AM MST using DSA key ID 47D0D9A8 gpg: Good signature from "Kurt Seifried <seifried@securityportal.com>"if you want to save the decrypted file simply use "--output filename" and it will dump the content to "filename". You can also use shell commands such as "|" or ">" to further mangle the output (this is useful if you have automated systems such as a reporting mechanism which sends encrypted emails to a central repository).
BestCrypt
BestCrypt is a disk encryption program available for Windows and Linux. The nice thing is you can create an encrypted container (a file that is then mounted as a filesystem), and use it in Windows or in Linux (as long as it resides on a partition accessible to both, so putting it on your Windows partition is fine since Linux reads almost all Windows partition types). BestCrypt consists of some kernel modules (so your kernel will need to support loadable kernel modules obviously, and it helps if you are using tools like depmod, modprobe and the kernel module loader), and a userspace utility called "bctool". This program is however officially in "beta testing" for Linux, and probably should not be used for critical data (if it is, make sure you have backups). After testing BestCrypt for Linux I am satisfied that even though the software is officially beta, it is probably stable enough for most users, however your mileage may vary, all sales final, and don't blame me for any lost data. The only real problem with BestCrypt is a severe lack of documentation, while there is a man page that explains basic options, there is not a single example of how to create and mount a container (I suspect the release will have documentation, their Windows version documentation is quite good, a half meg helpfile). You need to download the software first, available as a source tarball, and source rpm (very easy to install on an RPM based system). Simply download either one, I would recommend the source rpm if you can.
# rpm -Uvh BestCrypt-0.3b-1.src.rpm BestCrypt #################################################followed by a lot of text while it unpacks, compiles and assembles the source RPM and binary RPM. You should then have a:
Simply install the binary RPM with a:
#rpm -UvhIf you do not have an RPM based system, or the source RPM doesn't work for you, compiling the source code directly from it's tarball should be possible. Simply download the file, unpack it to an appropriate place (such as /usr/local/src) and issue the
commands:
#make #make installAnd you should be up and running. The first step is to create a container (a file that is encrypted and mounted as a partition):
# bctool new -a blowfish -s 10M file Enter password: Verify password:You can of course use the "gost" or "des" algorithms, I would not recommend them as gost is less tested then the "twofish" and "blowfish" algorithms that BestCrypt supports, and single des is to easy to brute force. The next step is to format the container, you'll probably want to use msdos if sharing with Windows (i.e. a dualboot Linux and Windows machine), or if just Linux then ext2 is a good bet. You can also specify the size, if you make it so small this can be a problem, but because it is a file and not a true partition you can easily create a new, larger file, move all the data to it and use it instead of the older smaller one.
# bctool format -t ext2 file Enter password: mke2fs 1.15, 18-Jul-1999 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 2560 inodes, 10238 blocks 511 blocks (4.99%) reserved for the super user First data block=1 2 block groups 8192 blocks per group, 8192 fragments per group 1280 inodes per group Superblock backups stored on blocks: 8193 Writing inode tables: done Writing superblocks and filesystem accounting information: doneOnce the file is formatted you should be able to mount it:
# bctool mount fileAs you can see it is mounted as a part of the filesystem, just like a floppy disk would be for example. Remember to control access to the directory hosting the encrypted files carefully, no matter how good the encryption, if you have it set world readable you won't have gained any security. Also remember that as a user, root owns the / and can take ownership of any file or directory and see what's in it. Alternatively if an attacker gains root access they can log your keystrokes (or terminal traffic) and gain your password (and access to your files). As always your security is only as good as the weakest link.
PPDDPPDD is similar to BestCrypt, but instead of creating a file, encrypting that and mounting it, it actually uses a partition which is encrypted and mounted using the PPDD driver, because of this it can do a few additional things BestCrypt can't. If you only want to encrypt a few directories then I advise compiling PPDD as a kernel module, but if you want to encrypt the entire file system (including what you boot from) you will need to compile PPDD directly into the kernel (although as of 1.0 it's not to hard). Unless you have a GPL only policy I would recommend using BestCrypt if you are new to this (it is easier to install and use, and you can buy support). PPDD does have one enormous advantage over BestCrypt however, you can encrypt all of the system, including the boot drive and swap partition, making it ideal for situations such as laptops with sensitive data and minimizing the risk (to zero if need be) of accidentally leaving sensitive data in an unencrypted location (such as the swap file, /tmp, and so on) so if you need
a higher security level I would recommend PPDD over BestCrypt
(simply because you can encrypt everything). Another advantage of
PPDD is that is uses two passwords instead of just one for each
encrypted filesystem, so you can give one administrator one
password, and another administrator the other password, meaning
no single person can gain access to the data. Unfortunately as of
the writing of this chapter PPDD is not available for kernel
2.2.13 or 2.2.14, so you will have to run the older 2.2.12 kernel
(which is the stock kernel on many distributions in any case).
Download PPDD, and unpack it in a suitable location, such as /usr/local/src/, there are several files you should read, most
notable the README file, and once done install I would recommend
reading the PPDDHow.txt file. Installation is rather simply with:
#make check_linux #make trial_patch #make apply_patch #make devicesThis will first test the kernel source to make sure it's the right version and so on, then it will test the patches, then apply the patches proper, and then create the devices needed (similar to what BestCrypt does). At this point you need to recompile your kernel, first make sure you go into the configuration (via make config or make menuconfig or make xconfig), and enable the PPDD driver (in the Block devices section). Then save the config file and recompile the kernel as your normally would. Once that is done you will have to install the new kernel (copy it to /boot typically, edit lilo.conf and
rerun lilo). Once you have rebooted you will want to build the
tools for PPDD and install them with:
#make #make installAt this point you should be ready to use it, however I would recommend running the tests with:
#make testThey take a while to run, but it will save frustration later on if something is broken. Using PPDD is relatively simple, there are a number of utilities for creating, managing, encrypting file systems, and so on. You will also want to set the permissions and ownership on the /dev/xxxx that contains your encrypted data so
that only root has access to it, PPDD will complain otherwise
#chown root:rootAt this point you should have a directory called /crypt which
is /dev/hda3 (although on df and the like it will show up as /dev/ppddx). I will cover how to encrypt you entire filesystem
with PPDD, at a later date however (it is extensively documented
though).
GuardbotAnother new possibility is Guardbot, which password protects www pages. Essentially there are two components, an applet that encrypts the data, using DES (56 bit keyspace), and an applet that will decrypt the data with the password you provide. The advantage of this over traditional server based methods of control (such as htaccess in Apache) is that the user manages it fully, and can protect each file individually without much setup. To fully take advantage of the keyspace available your password must contain upper and lower case letters, numbers (and punctuation marks, but this can confuse users) of around 10 letters, however since people tend to choose less then random passwords a longer password then this is advisable. This program would be useful for getting files to other people cheaply (simply sign up for some free web space, post the file up, and get the password to the other person securely).
Hiding files and data on your computerIt is no longer enough in some countries to encrypt your data to prevent access to it. Recently in Britain a law was created making it a criminal offence to refuse to give up encryption keys or plain text versions of encrypted data.
StegHideStegHide hides data in files such as sound and picture files where not all of the bits in a byte are used. Since the data is encrypted it will appear random, and proving that the data is actually there is difficult. The only downside is to store a one megabyte file you need a sound/picture file of several megabytes, which can be cumbersome (but hard drives and high speed access are becoming cheap so it's a moot point). You can get StegHide at: http://www.stego.com/.
StegFSSteganographic File System actually hides data on your harddrive, making it difficult to prove that it even exists. This can be very useful as the attacker first has to find the data, let alone break the strong encryption used to protect it. You can get StegFS from: http://ban.joh.cam.ac.uk/~adm36/StegFS/& lt;/a> .
OutGuessOutGuess hides data in image files, meaning you can send files in a way that won't attract to much attention (and can't really be prooved either). You can get it from: http://www.outguess.org/.
My letter to Arin:
Sure you can do web hosting with named virtual hosts, several hundred sites per IP, and it works fine. But what happens when sites start hosting more and more SSL secured websites (i.e. https://store.example.org/)? SSL works at the transport layer, you cannot host multiple domains off of one IP address. Will an exemption be made for this (i.e. I need a CIDR because I want to host a lot of secure websites?). Making it harder for people to implement SSL secured websites will only hurt the Internet, making it a much less secure place to do business, and ultimately stifle growth (well a little bit anyways). Thank you for your consideration.
Kurt Seifried, Senior Analyst
SecurityPortal, your focal point for security on the net
http://www.securityportal.com/
Fred Moody was nice enough to quote me and completely take them out of context/etc. My response to him: http://www.securityportal. com/topnews/moody20000821.html.
Wow, got slashdotted, this is pretty nifty (and our servers are handling it well this time which is nice). Anyways there's a lot of comments I feel I should respond to, so here goes:
The debian/Slackware issue: Debian has "official" releases like every 2 years, thus generating stats on it are near impossible. I know the distro is maintained (read: http://www.securitypo rtal.com/lskb/articles/kben10000078.html, I am well aware of how dpkg/etc works. Here's the thing, you will never release a bug free software package, especially something like Debian which has a lot of packages. Like kernel 1.0 it's sometimes just best to shove it out the door and give users something a lot better then the last "officially stable" release. Side note: looks like Debian will release the next major one before 2.4, meaning it'll be another year or two before "stable" gets a 2.4 kernel, sigh). As for slackware I don't know anyone using it in a production environment anymore (there probably are..). I used Slackware for .. about 2 years when I started out, it is not something I'd want to put on 10 machines and maintain.
As for default installs, guess what, most admins do leave the defaults. Many people simply don't realize how dangerous these services are, or that they really need to be kept up to date. A default install like OpenBSD, secure by default, requires the admin to do things to make it less secure, (admitedly OpenBSD 2.7 with no security patches has a number of holes that are pretty serious). SOmething like %50 of machines on the Internet are insecure, why? A lot of them are simply because the default OS install was done and very few (or no) updates. Taking care of one machine at home isn't to bad, I have to care and feed 6 linux servers for my personal network, and sometimes I forget to do things, I'm only human (and I like to sleep 8 hours a day).
Good response for what? Red Hat isn't a distro for the people who want the latest and greatest updates as soon as possible. It's a distro for those who require a very tested solution. That's why Red Hat is often behind on the technology by the time it gets to .2, because they're focusing on the testing.
Leaving your users hanging in the wind for 2 weeks with a local root exploit is not good. Yes I know 2.2.16 has a ton of problems, but you should be giving customers the choice, not just leaving them in the lurch with no update.
As for Caldera/Turbo, Caldera is a pretty popular corporate distro, and Turbo is huge in asia (remember, there's more to the world then just the US market).
Note to slashdot: make the *******ing text entry box bigger!!!!! like 80 by 40 would be nice.
Kurt Seifried
If you need security then encrypting the data is your best bet.
Chapte r 10 - Encrypting files and drives in Linux, BSD, and other Unices
and
Chapte r 9 - Encrypting files and drives in Windows 95, 98, NT and 2000.
As well I have 2+ gigs of OpenSource cryptographic software at CryptoArchive