Slashdot Mirror

The Office that spreads virus-filled documents far and wide across the 'net?

The Office that is not/barely compatible with other versions of itself?

The only thing they've done "right" with Office is to monopolize the market, enslaving people to a document format of negligent design.

How about a little wrap up:

Part I - Using ssh

Part II - ssh suite: Sftp, scp and ssh-agent

Part III - Using ssh-agent for SSH1 and OpenSSH

Abbreviated Version

The authoritative source

Mmmnnkay? Mnnnkay.

This one is a little bit dated, but it is still pretty good. It is written by Jay Beale, from the Bastille Linux project.

Stupid, Stupid Protocols: Telnet, FTP, rsh/rcp/rlogin

This isn't a problem with Outlook, it's a problem with idiot users clicking on every damn thing they're emailed.

WRONG! Outlook Express reads html in mailbox as local file - it's a serious mistake that they should have fixed long time ago!!

HELP.VBS hides itself in html files, and infect other files if open with full local privilege. I just got a user who sweared never opening any attachment has his computer infected with this. He just looked at a HTML mail that's all!

So stay away from Outlook Express for GOD's Sake! I know Outlook does have some improvement, but I've already lost my confidence....

It's like hell supporting users who never take your advises.

last time one of my user having his outlook infected with HELP.VBS virus and called me during my vacation.

I were having problem instructing him to fix it over the phone(e.g. after 15 mins in searching for the 'Start' menu I realized that the screensaver was in fact activated). I offered to fix his problem personally once i got back next week. He said he couldn't wait that long.

Since the virus would only delete files on dates when the day and month total 13. I told him not to power up his computer when the total of day and month is 13.

However, regardless of the fact that he's a CFO, he has problem with simple addition....

been a long time (3+ years) since I have seen a Linux as stable as Windows

Uhh... Windows 3.1? I have yet to see a properly-configured Win32 (sic) machine hold it's own against a properly-configured Linux machine. Especially considering that any Win32 machine put under any sort of actual use tends to get unstable after, oh, I'll give it 48 hours max.

I get security announcements and patches from Microsoft when problems are discovered. I read about them months after the fact for Linux - and if an RPM patch isn't available oh well.

It all depends on where you go looking for information. There are plenty of security related sites out there that cover Linux.

And what's this bullshit about RPM patches? Have you ever heard of just compiling your own and being done with it? That is why such things are provided for download -- if something goes wrong, you can fix it.

And as far as the level of expertise, I can hire Microsoft engineers all day long. Finding a competent Linux person is near impossible - make sure you add that cost into your evaluation.

I can hire MS engineers all day long too. Can I hire competent engineers of any sort all day long? I highly doubt it. MCSE's are a dime a dozen, but if something just happens to go wrong on that W2k server over there, what are they going to do to fix it? "Oh, reboot the machine, it'll all be fine." Er.. stability?

proper url

check out This Article Should be just what you're looking for.

updated article.

• At last week's IEEE Symposium on Security and Privacy Bill Arbaugh presented a very interesting paper on trend analysis of exploitation, as represented by CERT incident reports. Summary: most attacks exploit known security vulnerabilites that a site admin did not patch.
• Jim Reavis at Securityportal.com did this great study examining the "days of recess" for each of Red Hat, Solaris, and Windows NT. "Days of recess" is the total number of days that an exploit was known but no patch available, summed over all vulnerabilities for that platform.
• At WireX, we are working on a related concept that we call "Relative Invulnerability". Here, the idea is to consider the number of vulnerabilities for a "base" system (e.g. unpatched Red Hat 7.0) that appear over a period of months, and then consider how many of those unpatched vulnerabilities are successfully mediated by some protective technology such as SELinux or Immunix. The fraction of vulnerabilities stopped is the "relative invulnerability" of the defensive technology. This is written up in a paper that is currently being reviewed.

• At last week's IEEE Symposium on Security and Privacy Bill Arbaugh presented a very interesting paper on trend analysis of exploitation, as represented by CERT incident reports. Summary: most attacks exploit known security vulnerabilites that a site admin did not patch.
• Jim Reavis at Securityportal.com did this great study examining the "days of recess" for each of Red Hat, Solaris, and Windows NT. "Days of recess" is the total number of days that an exploit was known but no patch available, summed over all vulnerabilities for that platform.
• At WireX, we are working on a related concept that we call "Relative Invulnerability". Here, the idea is to consider the number of vulnerabilities for a "base" system (e.g. unpatched Red Hat 7.0) that appear over a period of months, and then consider how many of those unpatched vulnerabilities are successfully mediated by some protective technology such as SELinux or Immunix. The fraction of vulnerabilities stopped is the "relative invulnerability" of the defensive technology. This is written up in a paper that is currently being reviewed.

• 1. LinuxNewbie -- They've got tutorials on just about everything.
  1. The Linux Security Portal
  1. The raQ3 download site -- security patches here
  1. CommuniTech's satisfaction ratings with EOpinions - looks like you're not the only dissatisfied customer
  1. A bunch of Linux security stuff here
  
  
  Hope this helps...

I wish they werent so expensive so then i could use a java ssh thing on my companys website. I am baseing my companys website eventually on Slashcode and going to use java ssh with a digtal security certificate. (Though i don't know how to do that :-0) They said that to not be vunerable to man in the middle attacks and I don't want that to happen to my ssh server.

I'm trying to figure out how to go beyond Jay Beale's SOHO firewall article and to set up a DMZ for a number of servers - more than just the one he gives in his example. What I can't figure out is how to map a multihomed external interface to multiple IPs on the internal network.

Could anyone help explain the additional steps needed to make this work? Or tell me where to find this on the web/docs/faqs/etc? Even Rusty's guides don't cover this.

Goal:
184.220.142.10:80 --> 10.0.0.11:80
184.220.142.10:8080--> 10.0.0.13:80
184.220.142.10:25 --> 10.0.0.12:25
184.220.142.11:443 --> 10.0.0.11:443
(and once those work I can make anything go...)


Thanks!

I thought we had already discussed that we should all move away from SSH1 and use SSH2... As advised by SecurityPortal, I upgraded my server and clients to SSH2. I for one am feeling safe, now, at least for the few next weelks/months...

I wrote a follow up article that addresses many more problems in the implementations.

http://www.securityportal.com/seifried/sslssh-foll owup20001222.html

OpenBSD has had remote holes, for example in their ftp server and the DHCP client, they however claim that since these are not turned on by default, they are "Secure by default". Realistically however most people using OpenBSD that need an ftp server were using the default one, and presto, they were vulnerable. Ditto for anyone using DHCP, which is extremely common on workstations, however the OpenBSD people argued that "no sane admin uses DHCP, it has to many security problems", while this is true to a degree (a "rogue" DHCP server can do quite a bit of damage) realistically unless you want to waste a lot of time configuring and maintaining network settings you use DHCP.

OTOH OpenBSD does have by far the best track record when it comes to exploits in the core distro, I should know, I write a weekly Linux digest and a weekly BSD digest, the BSD one takes a lot less effort.

BTW there is an all Linux security mailing list available now; Click here to sign up via the web form

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"

By: Kurt Seifried, seifried@securityportal.com, for http://www.securityportal.com/

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.

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 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 :

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:

If someone has fiddled with the file or signature you will see something like:

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:

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:

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):

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.

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:

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:

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):

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.

Once the file is formatted you should be able to mount it:

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 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:

At this point you should be ready to use it, however I would recommend running the tests with:

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).

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).

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 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/.

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 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/.

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"

By: Kurt Seifried, seifried@securityportal.com, for http://www.securityportal.com/

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.

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 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 :

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:

If someone has fiddled with the file or signature you will see something like:

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:

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:

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):

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.

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:

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:

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):

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.

Once the file is formatted you should be able to mount it:

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 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:

At this point you should be ready to use it, however I would recommend running the tests with:

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).

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).

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 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/.

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 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/.

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"

By: Kurt Seifried, seifried@securityportal.com, for http://www.securityportal.com/

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.

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 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 :

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:

If someone has fiddled with the file or signature you will see something like:

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:

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:

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):

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.

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:

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:

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):

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.

Once the file is formatted you should be able to mount it:

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 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:

At this point you should be ready to use it, however I would recommend running the tests with:

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).

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).

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 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/.

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 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/.

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"

By: Kurt Seifried, seifried@securityportal.com, for http://www.securityportal.com/

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.

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 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 :

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:

If someone has fiddled with the file or signature you will see something like:

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:

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:

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):

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.

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:

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:

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):

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.

Once the file is formatted you should be able to mount it:

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 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:

At this point you should be ready to use it, however I would recommend running the tests with:

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).

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).

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 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/.

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 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/.

FYI the slashdot post was here and the article it pointed to is here.
--

Is there a reasonable article around on this which explains more about the problem and it's concepts as well as how proper and careful coding can avoid it? :/

The best introduction is Pascal Bourchariene's original paper on writing Format exploits .. its probably available all over the web .. theres a copy here, for example.

This paper is to format string bugs what Aleph One's "Smashing the stack for fun and profit" is to buffer overflows.

I have to wonder if the release of RSA into the public domain has anything to do with this development I saw headlined at Securityportal about another (um, proprietary, too) encryption algorithm, NTRUE

I would love it if a new legal finding was made that US Patent Law had to be reinterpreted because the original specification had a faded decimal point - that the intent was to provide patents for 1.7 years instead of 17 years.

Here is one of his articles that ended up in a printed mag. It discusses PAM and attempts to discredit shadowed passwords in the process. The information is misleading and inaccurate. The article sounds more like it was released from a marketing dept instead of a self-proclaimed security expert.

When he discribes limiting access to ftp, he is basically saying only a good password will limit who can access the system. What about, /etc/ftpaccess or /etc/login.access. Not to mention using tcp wrappers and /etc/hosts.deny.

When he discribes using limits on users, he tries to imply only PAM can do this. Yet he fails to mention /etc/limits. If you 'man limits', you will see the available options are EXACTLY the same the ones he mentions are in PAM.

I see Kurt post to a few security mailing lists, Suse , BUGTRAQ, Linux Security Auditing Project, Bastille, etc. For the most part, his posts are worthless. Claiming PAM is the greatest thing since sliced bread, flaming others for off topic posts, repeating well known information, etc. His new project, LSKB lacks any kind of useful information and is more of a waste of time than anything else.

I have no respect for him and try to ignore him as much as possible.

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.

This article I read the other day on Security Portal was a good read. It was mostly about using ssh but gives some examples of how to use it to automate some sys admin work and do it all securely as well.

Here's an article at SecruityPortal that looked at the same bugtraq data and came to the conclusion that Linux had superior security to NT and showed fewer total advisories and a fewer hacker recess days per advisory.

It seems obvious that ABC is full of crap and has fabricated their results by deliberately misrepresenting factual data.

Now why would ABC (A Bunch of Crap) News do such a thing?

Kurt Seifried has always disregarded the Debian/GNU Linux and Slackware distributions for as long as I've started reading his material. Just digging up a past hard-copy of the Linux Administrator's Security Guide from last year, it is interesting to note he provides the following distribution notes in his guide:

Debian

Debian 2.1

Not tested yet.

Slackware

Slackware Linux 4.0

Not tested yet

So please don't let Seifried's lack of experience (and credibility) in dealing with Debian and Slackware be influential in your decision to use them.

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 it being a year before woody ships with a 2.4 kernel, it may be a year before 2.4 is remotely stable. 2.4 may not even be feature frozen yet, despite claims to the contrary; Linus seems to be adding a new feature a week. IMHO shipping 2.4 as the default kernel in any distribution would be irresponsible at this point.

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

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

Different scary attack thoughts: Samhain (mirrors - linux-list, Red Rock Eater, bugtraq).

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

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

• Moving all networked computers off Windows (will viruses eventually do this job?)
  
• Securing all (restricted) networks with Open SSH
  
• Developing/studying systems that can be proved secure (buffer overflow wrapper where?)
  
• Packaging all software in a safe default installation.
  

...but it's not me. Kurt Seifried, the security expert from securityportal.com writes in his article Do you trust your software? that Linux backdoors COULD and probably DO exist because, despite the fact that the source is open, almost nobody is actually reading it. He also claims that many of the exploits found in common open-source software such as BIND and wu-ftpd are placed there intentionally, like by the US government.

Notice: do not flame me. I do not believe in this fairy tale; I'm just reporting on it. I have personally spoken to Kurt on IRC and made him explain himself. He had some good arguments but I still think he's wrong :)

...but it's not me. Kurt Seifried, the security expert from securityportal.com writes in his article Do you trust your software? that Linux backdoors COULD and probably DO exist because, despite the fact that the source is open, almost nobody is actually reading it. He also claims that many of the exploits found in common open-source software such as BIND and wu-ftpd are placed there intentionally, like by the US government.

Notice: do not flame me. I do not believe in this fairy tale; I'm just reporting on it. I have personally spoken to Kurt on IRC and made him explain himself. He had some good arguments but I still think he's wrong :)

And it was so well received that they decided to sell it to CheckFree:

Here's the link

Not only do you go with a more reliable company like Microsoft, which will be able to make deals with far more companies for online bill paying because of it's size, but you get to benefit from microsoft's experience and the superior security of it's operating system.

From SecurityPortal.com:

Red Hat did a better job of handling the "full disclosure" bug releases, usually solving these problems in under 2 weeks, with 67 days being the extreme case. Microsoft usually took over 3 weeks to patch "full disclosure" bug releases, with a worst case of 146 days.

Here's the link

--
Where do you want to go, toady?

The following is a rant I wrote on Saturday, when I first found out about Mattel being awarded the injunction. Anybody may feel free to copy or reproduce parts of it.

My mirror does not include any of the program files, but only the published analysis, Mattel's complaint, and an English translation of the Swedish copyright law 1960:729. I have no relation to the defendants in this case, and am only an interested third party.

- David Michael Turover(Perpetual Newbie)

(begin rant)

I am not in a good mood right now.

I've just had to troubleshoot NT's braindead permissions scheme, I've taken a test where several of the "correct answers" are wrong, my right wrist is aching(not good for a CS student), and it's barely noon. On my lunch break I crack open Netscape to read the news, and find that a United States federal judge has ordered two cryptology researchers to remove an essay that they had published on a Swedish website.

The two researchers in question are Matthew Skala, a Canadian, and Eddy L. O. Jansson, a Swede. They have reverse-engineered a program called Cyber Patrol, and described in detail the cryptography and computer file formats used by the program.

Cyber Patrol is a product made by Microsystems Software, which is a subsidiary of Mattel. The purpose of the product is to prevent any user of a computer where it is installed from accessing any of a list of several Internet web sites, ostensibly to prevent children from viewing pornography. As part of their report, Skala and Jansson offered a Win32 binary named cphack.exe, a utility which decodes Cyber Patrol's list of blocked URLs(website addresses).

Mattel promptly sued the authors of the report, charging them with copyright violations and ordering them to remove their program, report, and all supporting and related documents and materiel, claiming that the report and software will cost them over $75,000 in lost sales. On Friday March 17th, two days after Mattel's complaint was registered, Judge Edward F. Harrington awarded Mattel a preliminary injunction against the two. Jansson's internet service provider, though in Sweden and not subject to U.S. law, has removed his account and deleted the documents.

Reverse-engineering is the process of examining a product to see how it works. In almost every industry it is not only expected to occur but considered an integral part of the free market. In the software industry, however, products are often sold with "shrinkwrap licenses" that restrict reverse-engineering. A shrinkwrap license is a contract describing terms of use for a product, in which these terms cannot be read until after the product has been purchased, can not be disputed, and must be agreed to for the consumer to use the product which they have already paid for and in most cases cannot return. In most Western countries these shrinkwrap contracts are unenforcable, and in the U.S. their legality is disputed, although the upcoming UCITA bill will make them law.

In most Western countries, including Sweden, reverse-engineering of software is a right explicitly allowed by law that cannot be taken away by a contract(1960:729 26 g). Legal protections against reverse engineering can be obtained; they are called "Patents". Furthermore, an action undertaken in Canada and Sweden should be out of the United States' jurisdiction; However, the U.S. court did not refuse to hear the case as it should have done, and instead granted the injunction by weighing the action under U.S. law.

To make the situation more repugnant, Cyber Patrol doesn't work. And not just Cyber Patrol. It is well known that all content-blocking programs such as Cyber Patrol have a high rate of failure, and a high rate of erroneously blocking acceptable content despite any claims by their marketing departments of being 100% accurate.

This is not the first time Microsystems/Mattel's lawyers have been aggressive. A Microsystems software engineer who was fired from his job for seeking medical attention for his sore wrists has since been sued by Mattel for documenting his experiences. Outrageous lawsuits such as this have been happening often lately, and what is frightening is that in the United States' court culture, they have a good chance of succcess.

I've written an article on this topic:

UNIX (and Linux especially) viruses - the real story

A DDoS FAQ is available here.

Kurt Seifried - Senior Analyst http://www.securityportal.com/ http://www.cryptoarchive.net/ http://www.seifried.org/

Being the nice guy I am I wrote another book last month that is online for free:

Cryptographic software solutions and how to use them.

It is available at: http://www.securitypo rtal.com/research/cryptodocs/basic-book/

Chapter 8 - Encrypting email in Linux, BSD, and other Unices

Chapter 9 - Encrypting files and drives in Windows 95, 98, NT and 2000

Chapter 10 - Encrypting files and drives in Linux, BSD, and other Unices

And so on and so forth, you get the idea.

Kurt Seifried - Senior Analyst
http://www.securityportal.com/
http://www.cryptoarchive.net/
http://www.seifried.org/

The Distributed DOS is pretty ugly - there are very few things you can do to help yourself if you are the target, but there are more things you can do to prevent yourself from being the source of the problem, like ports like 31337 and others so machines under your control won't fall for stacheldraht. http://securitypor tal.com/direct.cgi?/topnews/yahoo20000208.html

Go to this url. It is from SecurityPortal, and it is worth it.

You also have this one from ZDNet, a little less geek-ish but much more formal.

Ok I'm biased since I wrote this article, but it covers the Yahoo! DOS (I took a look at their network/etc) and goes over what you can do to prevent being DOS'ed, and what you can do to "be a good neighbour".

Yahoo! - Why denial of service (DOS) attacks work (http://www.securityportal.com/)

Kurt Seifried

One of the better sites for security related issues is: http://securityportal.com. Definitely check it out and get on the mailing list.

----------------

"Great spirits have always encountered violent opposition from mediocre minds." - Albert Einstein

First off.. Do not just "Scrub" the system. Wipe the HD, LLFing if possible. Backup data files first, via the network to a known good server first (via anon FTP so any remaining sniffers, etc, will not read any important password).

Then go and reinstall a recent Linux distro. I recommend Slackware. It may not have the bells & whistles of Red Hat, but its BSD-style init scripts are easy (easy as config.sys and autoexec.bat) to learn, and tends to ship with reasonably secure daemons. Of course, OpenBSD is another possible solution :-)

Now, if you want to just give them FTP access (and nothing else), ProFTPD provides a nice solution. Granted, earlier versions had some interesting security holes (poke), recent versions have been a lot better security wise. Set it up with mod_linuxprivs (which uses the POSIX.1e interface of 2.2.x and later kernels to drop all root privs except for the ability to bind to ports less than 1024). (For the configure impaired, try "./configure --prefix=/usr --with-modules=mod_linuxprivs").. This lets them have ftp access (I'd also recommend you setup ProFTPD to chroot the various users to their homedirs). Disable telnet. Install SSH or OpenSSH and only allow your own login to use it (login.access allows this). Only allow your user to execpt su (perhaps as part of the wheel group), and have your root password as something other than your normal account password. At this point, you will have a secure system, FTP access for normal users, and secure remote access for your own administration. Of course, this doesn't get you out of your duties to monitor Bugtraq for possible advisories. I also recommend (very much so) that you read LASG -- the Linux Administrator's Security Guide. It's very good :-)
---

Lest the Slashdot community get too holier-than-thou when it comes to security, let us remember that GNU/Linux has had its share of security problems over the years.

VMS has had it's share of security problems too. So what? A more interesting metric is not whether an OS, or any underlying apps, present security holes, but how quickly they are fixed. See this Securityportal cover story for a comparison of time from announcement to vendor fix between Redhat Linux, Windows NT, and Sun Solaris (see, I can add gratuitous links as well!) I note that Redhat Linux won hands down in this competition, and that's only security updates from a vendor supplied source! I don't know about you, but when I hear about a serious security hole in lpd (for example), I don't wait around for Redhat to go recompile the fix. However, the Securityportal article makes a reasonable assumption that most small to medium sized businesses would probably rely on vendor supplied fixes rather than trying to find a hot Linux guru to compile up to the minute security fixes.

Now, of course, GNU/Linux developers are generally faster than Microsoft when it comes to fixing security holes and they don't, as a rule, engage in the same coverups and spin control as the Microsoft's PR flaks, but the question remains, why are there so many bugs in the first place?

DUH. Because C doesn't bounds check during compilation or run time. That's just ONE reason. Look, I'm no security "expert", but if you're uptight about security, and don't consider yourself competent at securing your own code, then either hire a professional to go through your C code with a fine tooth comb, or write it in some interpreted language like perl, LISP, Scheme, Python (whatever) and let the LANG developers deal with security.

Not that this will make your application any more secure, but it will pass the buck to the likes of Larry.

Other open source operating systems, such as FreeBSD, NetBSD and OpenBSD have had security problems, but not in such numbers as the various GNU/Linux distributions.

This is bogus. And I run OpenBSD, the BSD distribution tailored for security, on my cablemodem gateway and consider it an excellent secure distribution out of the box (CD). But, so what? Can you give me ANY specific examples of userspace application security holes present in Linux that were not present in BSD? Hell, most of the networking kernel holes seemed ubiquitous across just about every OS and networking stack, BSD sockets and streams based.

On the kernel side I seem to remember that both BSD and Linux (and NT!) were vulnerable to the Ping of Death, various Tear Drop attacks and fragmented TCP attacks, and those lovely smurf DOS attacks. Don't see a significant difference here... both the BSD's and Linux kernel groups figured the problems out and posted solutions in record time, while the commercial vendors picked their butts and didn't post fixes for their products I might add.

On the userspace side of things, this is managed project by project. Since much our application software is ported between the BSDs, Linux, and most any other commercial UNIX, there's little difference. A bug in one version of lpd on Linux is almost surely the same bug on BSD

Rather than making fun of Microsoft for its own failings in the security realm, GNU/Linux users and developers could better spend their time improving the security of their OS of choice.

There. Now you said something rational.