Hardware/firewall - your recommendations please

Dec 23 09:29 UTC 2006

When I wasn't looking, a colleague (proofreading my resume) asked me 
to do some security work on a software system he is planning to release 
soon to some clients.  The software was built principally by him, and will 
be housed/served out of a data centre.  I'm being consulted for all 
matters (hardware, software, database, network) security related to the new 
venture.  This has inspired me to start my own IT security business in my 
spare time, something I was always going to do one day - just not so soon 
or effortlessly I thought :)

Anyhow, I would like some advice from the Grex community on what 
hardware/infrastructure you would recommend.  He was originally going to 
host the application on a virtual machine share in the data center... it 
did not take rocket science thinking for me to instruct him this was a bad 
idea.  So, we are now more looking at a completely separate box (acquired, 
installed, and managed by us) to be stored in the data center.  

To give you an idea of the requirments, it is a thick-client application 
developed in Visual Basic .Net talking to a SQL Server 2005 database, with 
no (or very little application-main) server logic, except for stored 
procedures in the database.  There will be a small component utilised 
initially for securely registering (think licensing) a customer pool for a 
client organisation, but this is not the core part of the application.  

I'm not so concerned about the security requirements, but I would like 
your input on what hardware (firewalls, VPNs, and specifications for the 
server-class machine we should purchase).  At any one time there may be 
say 30 clients maximum querying the database.  He is thinking Raid-1 for 
backups.

Comments ASAP please :)

response 2 of 19:

Dec 23 14:11 UTC 2006

From a security standpoint I would recommend against your database
allowing remote connections from the internet, even if such connections
are through a VPN. I think that a compromised client having that type of
access could be disasterous. I think you should look into a way of
serving this "fat client" as a thin-client. This isn't as hard as you
think, and my recommendation to do so would be using Citrix Presentation
Server.

When a client connects to Citrix, the Citrix server will launch the
application and then serve the display and inputs in an x-terminal type
fashion. The advantage is that you only need to install the application
to one machine, the Citrix server. This also means that when it comes
time to upgrade you only have to upgrade the application on one machine,
the Citrix server.

We use Citrix where I work to provide database-driven banking
applications to end-users off-site. It has worked really well for us and
I think it would be worthwhile to check out.

response 4 of 19:

Dec 23 21:46 UTC 2006

Thanks, a couple of questions:

(1)
I like the idea of application virtualization, however I would like a 
way for the virtualized application on the server to be able to have 
some access to the client's machine (for licensing, auditing, and 
determining which database instance to connect to).  Is this possible?
If so, how does it work?  For instance, if the virtualized application 
read a MAC address - would it be grabbing the client machine's MAC 
address or the MAC address of the virtual application network connection?

(2) If the above is NOT possible, does this not just shift (and 
potentially increase) security threats to client organisations?  
Guessed/brute-force attacked/socially-engineered attained login 
credentials of another organisation's clients would allow the attacker 
full access to that other organisation's data.  Or is there a way to 
combine the security of the VPN with the application's hardcoded 
security?




  

response 6 of 19:

Dec 23 22:34 UTC 2006

What do you mean by managing the entire client?

response 8 of 19:

Dec 23 23:52 UTC 2006

One of the likely client organisations has a Cisco 837 Router already in 
place.

We have an understanding that we can ask/demand the client organisations 
to acquire a minimum-spec router/VPN to securely connect to our firewall 
router (to be acuired by us) for communication route ultimately to our 
application.

response 10 of 19:

Dec 24 07:53 UTC 2006

The thick client has no interfaces to any other applications on the 
client's OS.  We are not going down the virtualization approach (in any 
form) due to timeframe and costs; that's pretty neat anyhow (least I 
researched it quite a bit and learned a bit more about some technologies 
in that space).

This is going to be a neat little project --- security from many angles, 
and I'll get to play with .NET and SQL Server (*giggles* neither my 
preferred cup of tea normally - but great for the novelty factor and good 
experience).

response 12 of 19:

Dec 24 13:19 UTC 2006

FWIW, Citrix isn't virtualization, its terminal services. And if you are
going to go ahead and have the clients installed onto end-user
workstations, then I really think you should look into Firepass VPN. It
will sit behind the Cisco 837 router and allow external clients to
connect using a web browser. The browser initiates the VPN networking
and can check to make sure the client has proper anti-virus, etc.

response 14 of 19:

Dec 24 20:52 UTC 2006

I am going to have to agree with other posters here and suggest that it
would be better to run the client programme on a secured, controlled
server and simply export the display of it, rather than having the
client out in the wild. If that is not an option, at the very least you
do not want the client to ever have any way of reaching the database
itself, and require it to have its access to the database brokered and
mediated via a server programme that authenticates the client and
actually performs the database transactions. Consider the following
stack of tasks: 

display
client logic
communications
server logic
data access logic
data storage

You gain better control over the behaviour and expose fewer potential
vulnerabilities the higher up on that list you manage to keep
centralized. Additionally, by only exporting the display (either through
a web application like moving the client and server logic into asp.net
or by using an application service like Citrix), you can do upgrades
without having to ship CDRoms or making the customers download a new
client programme. 

Regarding moving the data access logic off of the client, consider this:
you have a legit user who fires one of their employees. This employee is
vindictive and clever and dissects the client programme and figures out
how to connect directly to your database and muddies up all of the data
for their former employer. Since you control the database, your customer
would be pissed off at you. And would probably voice their displeasure
by having their attorney send certified letters to your attorney, and
that can only end badly. 

A good rule of thumb is to keep a database isolated with only two links:
a link directly to the server application and a link into the back-end
for monitoring and for mounting SAN/NAS/CIFS shares. It should only
accept queries and whatnot from the server, which scrubs and sanity
checks everything. 

If you have to keep the client as a "fat client" programme, I would at
least recommend that you move as much of the business logic and data
access logic into the server, and also make use of some sort of
encrypted tunneling system, such as ssh or a VPN (Cisco's ASA is sexy,
and might even be better than the PIX). 

response 16 of 19:

Dec 24 22:25 UTC 2006

As long as I make this clear, get it in writing, and get client signoff 
before proceeding - I cover myself as a professional.  It is not ideal, 
but it's business I'm afraid.

response 18 of 19:

Dec 25 08:21 UTC 2006

Tell me about it :p