Need Secure Server Advice

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
Hi All,

A customer has asked me to set up a secure Sugar CRM
( /) server.  (Sugar CRM is a Customer
Relations Manager.)  The idea is to allow all his widely
dispersed salesmen access to the Sugar CRM database.

My plan is to do this with Cent OS, only because I
am familiar with it.  (I also set up the customer's
firewall using iptables.)

Okay, so far so good.  But I am freaking out a bit here
on the security of the thing.  If the Sugar CRM database
were to be compromised, or any of the other data inside
the firewall,it would be a DISASTER, as in several hundred
people loosing their jobs, etc..

I am thinking of three routes to secure the thing:

1) build a new server that has no access to any of
the company's other internal networks

2) employ a VPN such as OpenVPN ( /).
Again, only because I am familiar with it.  It also
has a great mailing list with lots of helpful members.
Only accept SYN's for the VPN's port.

3) use nasty passwords that the users can not change

Now for some freaking out.  Things I see going wrong:
How in the world do you protect the information on the
server if a laptop gets stolen?

If I use a secret key at both ends, the bad guys will have
a direct pipe to the database.

If I use pki/tls, the users will write his password down on a
label and stick it on the back or inside cover of the laptop.
in which case the bad guys have another direct pipe
right back into the database.  (I may not have a complete
understanding of how pki/tls works here.)

Any and all advice/recommendations/wisdom will be greatly

Many thanks,

Re: Need Secure Server Advice

Quoted text here. Click to load it
Quoted text here. Click to load it
Quoted text here. Click to load it

As a bit of general advice, try to become comfortable with
the thought that at the optimal point in the tradeoff
between cost and security, there will be some Biggest
Remaining Threat that isn't worth eliminating. There will
always be some scenario that begins with "If X happens,
and then Y happens . . ." and ends with the escape or
corruption of your data. For perspective, you'll always face
the threat of a disgruntled salesman. Don't spend a lot
of money plugging holes that are less likely and less
damaging than that.

You probably want to consider confining each user to data
that he's likely to need, so that one rogue user (or lost
laptop) won't spill all your beans.

One high-security approach gives each user a small token
that displays a password that changes once a minute. Any
lost token gets deauthorized.

To email me, substitute nowhere->spamcop, invalid->net.

Site Timeline