The manager-proof database
Many companies run a database of some sort, often on a mini or mainframe host and increasingly on a server platform. And most database users work through well defined clients such as those with forms style interfaces. A good example is a bank teller front-end.

Such users are of no threat to the integrity of the system because what they do is controlled by the screen forms they can access, nor are such users a threat to system performance because the system is ordinarily provisioned to cope with their normal load. Managers on the other hand can inflict lethal blows on their systems, whether intentionally or not.

A typical manager has two sorts of interfaces to the database open to them: canned reports and freehand query interfaces. A canned report is basically a query that many managers run periodically to produce reports, such as current stock levels, transaction records by customer, etc.

One common, and unwitting problem is timing. Many managers tend to run such reports just before they go to lunch, probably because it takes so long to generate. But this is also the time when most customers choose to do their banking. The result: unnecessarily high data traffic that can be avoided.

But that is not the worst. Freehand query interfaces, because they pretty much let managers query as they please, are even more lethal. This is because even the slightest crack in the server-enforced integrity rules can allow a manager to completely scramble the database.

So what can be done?
It is important to realize that most managers do not need real time data. With mainframe systems, an organization can easily dispatch canned reports offline by running them as a batch job as part of the day end processing routine. The down side to this approach is that the reports may not be used every day so you end up doing a lot of processing for nothing. Nor does this approach address the freehand query interface problem.

What you can do every night is to export a data set representing the day's transactions. You probably do this already for backup. The process is usually to export the day's data to a file, back up the file, and then delete the file.

Now, instead of deleting the file, simply move the file to a NAS device and export it to say, a SQL server. This will be your repository that you may allow managers to do as they wish. And if they scramble the database, you can always rebuild it by reloading data from the NAS device.

But that is not all. Having a buffer system is useless if you continue to allow managers access to the "live" database. In order to hide the live database and NAS device from those using the SQL server, put two network interfaces in the SQL server and make sure there is no route between them.

This way, users can see the SQL server but not the devices attached to it, and none but the system administrators will be able to log on to the SQL server host as a general user.

Having a shadow database also increases the responsiveness of your actual database. Your live database, stripped of the reporting load, is likely to be much more responsive to those users who must deal with it, such as staff who are dealing directly with your clients. Managers also benefit since the SQL servers that they are using can be configured specifically to support their requirements and thus be more responsive than the live host.

Making an idiot-proof firewall
Most companies have relatively basic Web and e-mail requirements. This requires no more than a publicly-accessible Web server and a simple SMTP server. You can do this for even the largest company with low cost Linux-based appliances. The challenge is to find a safe way to connect your public servers to your internal network without giving access to hackers or unauthorized users. This is where most companies would install a firewall.

Most organizations tend to think "firewall" in the likes of Raptor or Check Point. A simpler, and cheaper category that can be also considered is the Internet access device (IAD), that is typically aimed at the SOHO market.

IADs are usually intended to connect to a DSL modem on the public side and a small LAN on the other. Generally they provide a small 10Base-T hub, NAT, DHCP and an imbedded HTTP server so you can configure them with a Web browser.

IADs are usually feature-strapped, and quite "stupid". Even the smartest ones which run imbedded Linux are built so that they can't be configured from the public side, that is, the HTTP server just cannot see the public interface. By default, they are set up so that clients on their private side can make a connection to the Internet any way they wish, but connections from the public (Internet) side are blocked (you can change the default configuration so that, say, an external SMTP connection is allowed but you don't need to).

Simpler better?
The fact that IADs are so simple can make them a powerful security device. While IADs are intended for DSL connections, you can just as easily plug them into a standard router's Ethernet port. This works as the IAD makes a simple PPP connection over a direct Ethernet link to the router every time an internal device such as an internal mail server wants to connect to one of your public servers.

Even if the router is compromised, all the intruder sees is that the router is set to accept a PPPoE connection on a given Ethernet port, that is all. And if an intruder is watching when a link is established, what do they see? A PPPoE session from a single IP address (which is issued by the router anyway) and nothing on the end of it because the IAD will not respond to any attempt to connect to it.

In short, the IAD presents no path into your internal network. Figure 1 illustrates this arrangement.

Of course your public mail server can still be attacked and your Web server hijacked, but that can happen anyway. Any mail on your public mail server is compromised anyway as its going across the Internet. In any case, your public Web server should be backed up and therefore can be restored anytime.