[lug] security question

[Kevin Kempter]

On Wednesday 02 June 2010 20:07, Lee Woodworth wrote:
> 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.
non-trusting, they have no relationship other than they all happen to be our 
clients

>
> - Longevity of the data and the length of time it needs to be protected?
it will only be there for a short time

>
> - Scheduled data transfers, or arbitrary times? 
 Scheduled 

> How many times a day? 
configurable

>
> - 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.
most likely static

>
> - How much will you trust the security of the clients? 
pretty well

> What is the physical 
>   security for them against malicious insiders? What about compromised
> systems on the client's network?
its a risk but a small one


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

our collection box will be outside of any of the clients networks

>
> - When using private keys, will they be pass-phrase protected or not?
not sure, I suspect pass-phrase protected but we'll need the client networks 
to push data to the collection box in a fully automated fashion, i.e. no 
interactive password prompts

>
> - What will your receiving process do to protect itself from malicious
> input?
validate gpg signatures, checksums, etc...


>
> - 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?

not likely - for one we'll not ever be pulling binaries of any kind from the 
clients, only text based data files.

>
> > 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
>
We've considered this, we suspect that this would be a more difficult sell to 
the clients...


> 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.

we do plan to use local VM's but they will be collecting data 24/7 generally 
in 5minute intervals, then we'll want to get daily payloads from the VM to 
our network



>
> > 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
>
> _______________________________________________
> 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