Best practices for private server deployment on LAN

[dan]

Leonard Isham wrote:
> On Wed, 23 Mar 2005 15:56:59 -0700, dan <info at hostinthebox.net> wrote:
> 
>>Hello, all -
>>
>>I'm trying to do some research on some of the best practices to
>>deploying a server that would be on a private LAN.  This server would
>>not have any Internet connectivity - it would be used to facilitate the
>>workings of a proprietary client program that would contact this server
>>for specific information.
>>
>>I have managed to bring down the install of a FC3 release to just under
>>500M.  Although I am not satisfied with this yet, that is pretty small
>>compared to what I've done and seen in the past.  I'll keep working on
>>that one.
>>
>>The problem that I'm faced with is that no one should be allowed to
>>tamper with this server.  No one should be able to log in, change
>>settings, or anything of the like.
>>
> 
> 
> Let's start with the basics:
> 
> 1. How valuable is the information and how much can be spent protecting it?
> 
> 2. Physical security have it locked in a room secure room or get/build
> a secure locked enclosure. Don't have any ports exposed so nothing can
> get connected to it.
> 
> 3.  Disable all that is not necessary including removing the keyboard,
> mouse and display.
> 
> 4. Use iptables to lock down remote connections.  ! would use ssh for
> remote administration.  lock down ssh (this has been covered many
> times search the archives).
> 
> Remember if any physically steals the computer that have all the time
> in the world to crack any encryption, physically remove the hard drive
> and put it in another machine...
> 

I'm a bit beyond basics at the moment, I'm more concerned with the 
"if"'s - "If someone takes the drive out...", "If someone tries to boot 
off of a CD...", "If someone tries to boot it in a funny manner..."

The reason why I did not address physical security, is because we cannot 
guarantee that.  The system is to be delivered to said organization, who 
in effect leases the hardawre and software on it.

They use it, and if it breaks, send it back, and we send them a 
replacement.  With that being said, my organization has to be able to 
access this machine, be it via serial, swapping hard drives, booting off 
of special media, or otherwise.

The reason why I did not address network security is because this 
machine will not be connected to a "live" network, and all necessary 
precautions would be taken by utilizing iptables, along with a tight 
SELinux policy, to ensure sanity within the operating system and 
userland itself - again, the problem lies ahead of that, protecting the 
system from access in the first place.

I appreciate the time that you've taken to respond, but what I'm looking 
for is pretty much beyond the four points that you have mentioned.

Thanks
-dant