Questions and Answers

Bjorn Satdeva

I have heard about a package used by hackers which uses IMCP echo return records to create connections to systems where more traditional methods are blocked in the firewall. Do you know anything about this?

It is a pair of server and client software programs called "pinsh" and "ponsh," which use an otherwise unused field in the ICMP echo reply packet. Many sites allow IMCP packets through their firewall, and are not much concerned with the IMCP return packages, which on the surface are quite harmless. This allows a cracker to establish a backdoor connection between a system inside the firewall and somewhere else on the Internet. The only effective protection is to block IMCP return packages in your firewall. The lesson to be learned is not new, and is, simply stated, do not allow anything through your firewall that is not absolutely needed.

I have set up an anonymous ftp server but now I would like to create an "incoming" directory that people can upload their files to while preventing others from reading or listing the files in the incoming directory.

I have created an "incoming" directory that has access permission set to write-only and owner to root. Visitors to our ftp site now can write to the "incoming" directory but are unable to see the contents of that directory. However, if someone knows the name of a file in the "incoming" directory, this person could download the file and read it.

You are correct in your analysis of the situation. It is in fact a common method between crackers to upload a file to an incoming directory such as yours, and then broadcast the name and location of the file with some other means. This is not a problem that can easily be managed by just setting permissions. However, if you create a small Perl script which checks for new incoming files and moves them to a location not accessible by the ftp server, then you have solved the problem. You can also use that script to check for large files, alerting you to incoming files, or any other action you would like to take.

I have, from time to time, heard discussions about using a CD-ROM drive instead of a disk drive in systems that require good security. This sounds like a good idea, but is this practically possible?

Yes, it is a practical possibility, however, it takes a bit of preparation. As CD-ROM drives with writing capabilities come down in price, and as traditional CD-ROM drives become much faster, it is also becoming economically feasible. However, you cannot get rid of the writeable disk drive. Apart from the user data that most systems need to have, you also need to be able to modify a number of configuration files, specially in the /etc directory. Unfortunately, most systems have still not come clean with the separation of data and executable files, so just mounting a writeable /etc directory on the CD-ROM might not work, without opening some of the holes you are trying to close.

If you use symbolic links to a writeable partition elsewhere, then some of programs that are offering services or that are used to maintain the system will break. For example, vipw and inetd will break (at least that was what happened in the version of UNIX for which I tried this), Unfortunately, if you do not have the sources to the operating system, it might be difficult to patch these programs to look for their configuration files in their new location. Nevertheless, for systems where you are especially concerned about security, such as servers living outside your security perimeter, it might be a good idea to do this.

If you decide to use this method more generally, then there is a less obvious payoff, which is the ease of performing updates. Although you will need to burn a new CD in order to perform an upgrade, the upgrade itself will consist of shutting the system down, replacing the CD-ROM, and then rebooting the system. This simplifies the update procedure and ensures much better version control of the systems. This payoff might be of value for systems in remote locations without much local support.

Oh, and one more word on security, when all executables are located on the CD-ROM, then it is impossible for an intruder to modify those executables. However, that does not mean that the system cannot be modified, and that it is bulletproof against intrusions. While it becomes vastly more difficult, it is still possible to make modifications that affect the security of the system. For example, in a demo I once did for a company, showing a weakness in their CD-ROM based firewall, I built a trojan horse, which broke the system, using the overlay and memory filesystems to hide it. So, while using a CD-ROM definitely increases security and makes it more difficult to modify the system, it does not make such modifications impossible.

I have heard about a new kind of encryption, called "Steganography." What is it, and do you think it is better than DES?

Steganography is not really an encryption method. Rather, it is a process of hiding a message within another message. With the possibility of encryption becoming restricted in the United States, this process has become more interesting in recent months.

For example, you can use this process to hide the fact that you are using PGP from automatic detection systems that are looking to somehow act upon your message if it contains the tell-tale BEGIN PGP MESSAGE delimiter or other attributes of a typical PGP message. Steganography does this by converting the PGP-encrypted binary file into nonsense English sentences, such as those below (truncated due to space constraints):

My forthright hatchet won't flinch unless I flub. Let's glitter near the customary birminghams, but don't countervail the customary concords. I countervail mawkish layups near the adjoint earnest shenandoah. I'd rather clatter aborning than traject with a colicky nasturtium. Tell the fluid admiralty it's aborning abolishing against a limpet. Many rapt duplex northerners will bemoan edgeways to rollbacks. Have a nervy blot. Many drunk amatory papaws will engraft horribly to hints. Where is the grill for the wobbly discovery? The chits, ploughs, and concords are all burglarproof and foolproof....

If you are in search of more information about steganography, take a look at these URLs:

http://www.iquest.net/~mrmil/stego.html
http://adams.patriot.net/~johnson/html/neil/stegdoc/stegdoc.html
http://adams.patriot.net/~johnson/html/neil/sec/sbib00.htm"
http://www.voicenet.com/~markm/crypt.html#stego

I am currently looking to replace our in-house backup scripts with an off-the-shelf solution. Do you know of any recent comparative studies of available options that would provide me with a short list? Thanks in advance!

I do not know of any independent studies in this regard. Almost all the white papers I have seen have been provided by vendors, which of course have hidden agendas - mostly in terms of having their product appear the most favorable solution to your problems. As you mentioned, there are many vendors that now offer backup solutions, some better than others.

I will not, in this space, recommend a specific vendor, as I only do so when I have recent experience that indicates a recommendation or honorable mention is appropriate. I will go as far as to recommend choosing a company that provides a tape management system that also is a frontend for the UNIX dump command, rather than one which uses its own proprietary solution. A few years back I had a funny experience with a well-known backup software vendor, which uses a proprietary solution. After I had demonstrated a major problem in their implementation, I was told by one of their staff that "it was OK, it was still the fastest solution around." Backups are done for one reason only, so we can retrieve the information at a later time. If a given backup solution cannot retrieve the information, or if, as in this case, it is possible to destroy the tape index library, making it very difficult to retrieve data, the solution is not much different from not doing the backup in the first place.

If you are looking for a freeware solution, there are two excellent packages, amanda and deejay, both of which are available from the ftp archives:

ftp://ftp.sysadmin.com/pub/admin/backup

Here you will also find the backup torture program. This program tests the reliability of backups and was the killer of the commercial package mentioned above.

About the Author

Bjorn Satdeva is the president of /sys/admin, inc., a consulting firm which specializes in large installation system administration. Bjorn is also co-founder and former president of Bay-LISA, a San Francisco Bay Area user's group for system administrators of large sites. Bjorn can be contacted at /sys/admin, inc., 2787 Moorpark Ave., San Jose, CA 95128; electronically at bjorn@sysadmin.com; or by phone at (408) 241-3111.