10.5. Genius/Paranoia Ideas - what you could do

This is probably the most unstable and funny section, since I hope that some of the "duh, that sounds crazy" ideas might be realized. The following are just some ideas for increasing security - maybe genius, paranoid, crazy or inspired depending on your point of view.

Playing around with Pluggable Authentication Modules (PAM). As quoted in the Phrack 56 PAM article, the nice thing about PAM is that "You are limited only by what you can think of." It is true. Imagine root login only being possible with fingerprint or eye scan or cryptocard (why did I use an OR conjunction instead of AND?).
Fascist Logging. I would refer to all the previous logging discussion above as "soft logging". If you want to perform real logging, get a printer with fanfold paper, and send all logs to it. Sounds funny, but it's reliable and it cannot be tampered with or removed.
CD distribution. This idea is very easy to realize and offers pretty good security. Create a hardened Debian distribution, with proper firewall rules. Turn it into a boot-able ISO image, and burn it on a CDROM. Now you have a read-only distribution, with about 600 MB space for services. Just make sure all data that should get written is done over the network. It is impossible for intruders to get read/write access on this system, and any changes an intruder does make can be disabled with a reboot of the system.
Switch module capability off. As discussed earlier, when you disable the usage of kernel modules at kernel compile time, many kernel based back doors are impossible to implement because most are based on installing modified kernel modules.
Logging through serial cable (contributed by Gaby Schilders). As long as servers still have serial ports, imagine having one dedicated logging system for a number of servers. The logging system is disconnected from the network, and connected to the servers via a serial-port multiplexer (Cyclades or the like). Now have all your servers log to their serial ports, write only. The log-machine only accepts plain text as input on its serial ports and only writes to a log file. Connect a CD/DVD-writer, and transfer the log file to it when the log file reaches the capacity of the media. Now if only they would make CD writers with auto-changers... Not as hard copy as direct logging to a printer, but this method can handle larger volumes and CD-ROMs use less storage space.
Change file attributes using chattr (taken from the Tips-HOWTO, written by Jim Dennis). After a clean install and initial configuration, use the chattr program with the +i attribute to make files unmodifiable (the file cannot be deleted, renamed, linked or written to). Consider setting this attribute on all the files in /bin, /sbin/, /usr/bin, /usr/sbin, /usr/lib and the kernel files in root. You can also make a copy of all files in /etc/, using tar or the like, and mark the archive as immutable.
This strategy will help limit the damage that you can do when logged in as root. You won't overwrite files with a stray redirection operator, and you won't make the system unusable with a stray space in a rm -fr command (you might still do plenty of damage to your data - but your libraries and binaries will be safer).
This strategy also makes a variety of security and denial of service (DoS) exploits either impossible or more difficult (since many of them rely on overwriting a file through the actions of some SETUID program that isn't providing an arbitrary shell command).
One inconvenience of this strategy arises during building and installing various system binaries. On the other hand, it prevents the make install from over-writing the files. When you forget to read the Makefile and chattr -i the files that are to be overwritten, (and the directories to which you want to add files) - the make command fails, and you just use the chattr command and rerun it. You can also take that opportunity to move your old bin's and libs out of the way, into a .old/ directory or tar archive for example.
Note that this strategy also prevents you from upgrading your system's packages, since the files updated packages provide cannot be overwritten. You might want to have a script or other mechanism to disable the immutable flag on all binaries right before doing an apt-get update.
Play with UTP cabling in a way that you cut 2 or 4 wires and make the cable one-way traffic only. Then use UDP packets to send information to the destination machine which can act as a secure log server or a credit card storage system.

10.5.1. Building a honeypot

A honeypot is a system designed to teach system administrators how crackers probe for and exploit a system. It is a system setup with the expectation and goal that the system will be probed, attacked and potentially exploited. By learning the tools and methods employed by the cracker, a system administrator can learn to better protect their own systems and network.

Debian GNU/Linux systems can easily be used to setup a honeynet, if you dedicate the time to implement and monitor it. You can easily setup the fake honeypot server as well as the firewall ^[67] that controls the honeynet and some sort of network intrusion detector, put it on the Internet, and wait. Do take care that if the system is exploited, you are alerted in time (see Section 4.13, “The importance of logs and alerts”) so that you can take appropriate measures and terminate the compromise when you've seen enough. Here are some of the packages and issues to consider when setting up your honeypot:

The firewall technology you will use (provided by the Linux kernel).
syslog-ng, useful for sending logs from the honeypot to a remote syslog server.
snort, to set up capture of all the incoming network traffic to the honeypot and detect the attacks.
osh, a SETUID root, security enhanced, restricted shell with logging (see Lance Spitzner's article below).
Of course, all the daemons you will be using for your fake server honeypot. Depending on what type of attacker you want to analyse you will or will not harden the honeypot and keep it up to date with security patches.
Integrity checkers (see Section 4.17.3, “Checking file system integrity”) and The Coroner's Toolkit (tct) to do post-attack audits.
honeyd and farpd to setup a honeypot that will listen to connections to unused IP addresses and forward them to scripts simulating live services. Also check out iisemulator.
tinyhoneypot to setup a simple honeypot server with fake services.

If you cannot use spare systems to build up the honeypots and the network systems to protect and control it you can use the virtualisation technology available in xen or uml (User-Mode-Linux). If you take this route you will need to patch your kernel with either kernel-patch-xen or kernel-patch-uml.

You can read more about building honeypots in Lanze Spitzner's excellent article http://www.net-security.org/text/articles/spitzner/honeypot.shtml (from the Know your Enemy series). Also, the http://project.honeynet.org/ provides valuable information about building honeypots and auditing the attacks made on them.

^[67] You will typically use a bridge firewall so that the firewall itself is not detectable, see Section B.4, “Setting up a bridge firewall ”.