> Unfortunately these machines are not behind a firewall -- they are
> public access workstations that we use for cycle-scavenging in the
> off-hours. I'll see how the sysadmin feels about opening up just the
> high user ports on these servers. Can you point me at the code which
> handles the TCP/UDP socket communication, just in case?
As Bogdan Costescu pointed out, the best (and easiest and most elegant)
way to go might be have a firewall for the entire cluster of nodes (a
router for example) and not worry about how individual nodes talk to each
other i.e. all non-priveleged ports can be open for intra-cluster nodes
without any security threat. I say elegant because it also makes it easier
to manage, your sys-admin would need to mess with one set of firewall
rules at the router level and not worry about a whole bunch of rules being
defined to allow intra-cluster-node communication (not to forgot the HUGE
overhead that will create as well).
> Dont want to have node public keys in the open
Why is letting all nodes know intra-node public keys a problem?? How could
this be a security threat?? I don't see any benefit from hiding node
public keys from cluster nodes. In fact, most production clusters (and
grids too), that I've used, don't worry about this.
Cheers, Arvind
On 2005-07-01 12:55 (-0400), Beth Kirschner had pondered:
> >> We have a cluster of Mac OSX G5s that are used during the daytime in
> >>classrooms and labs, but are left idle in the evenings and weekends.
> >>We are using PBS and Globus to submit jobs to run during these
> >>off-hours, and we'd like to offer MPI jobs as well. We'd like to open
> >>up a specified range of ports for use by LAM/MPI, without opening
> >>access to all TCP ports (which the sysadmin would rightfully never
> >>allow). SSH is used to communicate between nodes.
> >>
> >
> >This could be done in LAM, but there is no code currently to support
> >this model (i.e., only use a specific range of TCP ports). Right now,
> >when we open sockets (both TCP and UDP), we get whatever port the OS
> >gives back to us. Remember that LAM is user-based, so we'll never be
> >connecting to or from privileged ports. Those can certainly still be
> >blocked (which is where most of your problems will come from, anyway).
> >Allowing random, non-privileged connections from one machine, IMHO, is
> >not much of a security risk -- it allows software that is already
> >installed on two machines to communicate data.
> >
> >If your workstations are already behind a firewall or some other kind
> >of port-blocking protection, this may be a suitable model for you...?
> >
> >Is there any chance that TCP/UDP ports could be opened only between
> >those machines? For cluster usage, this is relatively common.
> >Specifically, you have some measure of trust between your cluster
> >machines, but not anywhere else.
> >
> Unfortunately these machines are not behind a firewall -- they are
> public access workstations that we use for cycle-scavenging in the
> off-hours. I'll see how the sysadmin feels about opening up just the
> high user ports on these servers. Can you point me at the code which
> handles the TCP/UDP socket communication, just in case?
>
> >> Additionally, we'd like each of the execute nodes to only need to
> >>hold the public key to the head node, while the head node would hold
> >>the public keys to each individual exeecute node. Right now we're just
> >>testing with two nodes, so I'm not sure if this is possible as well.
> >>
> >>
> >
> >I assume you're talking about ssh keys...?
> >
> >There's two kinds of keys -- node keys and user keys.
> >
> >For node keys, it's easiest (and there are few negative security
> >implications) to initially setting up a list of known node keys to all
> >your nodes. Hence, every node knows the public key of every other
> >node.
> >
> >For user keys, it's up to you. If your user private keys are protected
> >by passphrases, there's little harm in distributing them far and wide
> >(e.g., all the nodes in your cluster). If they're unprotected, then
> >you need to take reasonable measures to protect them. This kindo f
> >issue hits at the heart of what many people hold religiously to be
> >"truth" in security, so lots of people have different opinions here.
> >:-)
> >
> >
> >
> I was refering to node keys -- and the reason I asked is our very
> security concious sysadmin does not like the idea of having a list known
> node keys distributed to every other node. You mention this is the
> 'easiest' route -- what are the other options?
>
> Thanks!
> - Beth
_____________________________________________________________________
Arvind Gopu | High Performance Computing Group| (UITS-RAC-HPC) @ IU
HPC website: http://www.indiana.edu/~rac/hpc | Work: (812) 856-0187
My website: http://cs.indiana.edu/~agopu | Cell: (812) 361-4054
|
