[lug] security question

[Lee Woodworth]

On 06/02/10 11:59, Kevin Kempter wrote:
> Hi all;
> 
> we're moving on a service where we'll need to have a component within our 
> clients' networks that will deliver data back to us for analysis/processing.  
> Security is a big concern.  We're thinking of something like this:
> 
> 1) setup ssh keys onto a cloud server (or a dmz box) for each client
> 
> 2) have each client's local processing ssh the data file (zipped and 
> encrypted) to the cloud server where the umask for the connecting user will 
> be 0477 thus they cannot do anything, and we'll have a process that gets 
> called that accepts data from stdin and writes to a file
> 
> We'd like to deploy reasonably sufficient security while at the same time keep 
> it as simple as possible. We're open to the delivery server being either a 
> dmz box within our network or a cloud server for security
> 
> 
> Here's my questions:
> 
> 1) thoughts on the above approach?

You haven't described the threats and requirements in much detail. Describing
them will help in evaluating any approach you use. Some questions to think
about (not that I have a good answer for how to do this well):

- The relationship between the clients - known to each other, trusting/non trusting?
  This would affect how much isolation is required between them.

- Longevity of the data and the length of time it needs to be protected?

- Scheduled data transfers, or arbitrary times? How many times a day?

- Are the data sources going to have static or dynamic ips?
  If static, you could use ip filtering and a non-standard ssh port to
  add another security layer to your scheme.

- How much will you trust the security of the clients? What is the physical
  security for them against malicious insiders? What about compromised systems on
  the client's network?

- Network topologies at the client's? Will your hardware be dual-homed? Where
  will it be relative to the client perimiter defenses?

- When using private keys, will they be pass-phrase protected or not?

- What will your receiving process do to protect itself from malicious input?

- If a client's network is compromised, how likely is it that the data sending
  machine will be compromised via a trojan/key logger or just file system snooping
  of a passphrase-less private key?

> 2) thoughts on alternate approaches?

Another way is to have the clients generate the payload, encrypt it and
store it locally in a known place with a known name (keyed by date for example). The data
processing system then does a periodic ssh to the client machines to pickup the payload
and deposit a marker file that indicates a successful fetch. A cron on the client
cleans up when it sees the marker file. The ssh account on the clients could be very
restricted - a completely isolated user/group that doesn't have permission to read or
write to anywhere but the transfer directory (definitely _not_ the nobody account).

This reverses some of the trust issues. The client's now have to trust that your data
processing/fetching machine is secure. You have fewer worries about the security
of the key on the client machines since they ony have public keys. On the other hand,
you now now reposnibility for the security of the client machine private keys which
will probably need to not have passphrases. A compromise of your data fetch machine
potentially exposes all of the private keys. You may be able to restrict the use
of the client ssh account by connecting ip. At the very least you can limit the commands.
See ForceCommand in /etc/ssh/sshd, the example in mine is:

    #Match User annoncvs
    #   X11Forwarding no
    #   AllowTcpForwarding no
    #   ForceCommand cvs server

Maybe you could setup a virtual machine per client on the data fetch server to
provide more isolation. Depends on how many clients. With a known transfer schedule,
the VMs don't even have to run all the time.

> 
> Thanks in advance...
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety