On Wed, 23 Mar 2005, Burke, S (Stephen) wrote (in pretty well the
opposite order!):

>  The answer may be simply that grid systems should be outside the
>firewalls and not inside

That was what we asked for... but it ain't what we _got_! Paul has already
replied in terms of why this doesn't satisfy our network people, but I
would also question whether it's a viable solution for UIs - the bits of
the system we're supposed to be carrying around on our laptops.


> What are you planning on doing about your worker nodes? At the moment,
> to be useful they are expected to have unrestricted outbound access
> ...
> of course, people have been saying for a long time that that should be
> changed, but so far it hasn't happened.

Yes, I myself have warned several times that this requirement would
conflict with Brunel's network policy. And now it has!

> What are you planning on doing about your worker nodes?...

Our plan is to have them on a private subnet, NATted through the CE[*].
I'm still not sure whether or not that complies with either the letter or
the spirit of our agreement with them.

I don't think I've really made the problem clear enough: I don't think the
issue is with the service nodes, or even WNs - we stand a chance of having
the odd hole poked in the firewall if there is going to be a specific
service on the other end of it under a reasonable level of competent
supervision.

The problem lies with the UIs - end-users are being led to expect that
they can work with the Grid from their laptop on their desk, or in a
meeting room, or in the library... Now, that may be "how things should
be", but currently implementing that the crude way over 3 DHCP'd subnets
means making ~750 holes for one user - and I don't think that's a viable
option: I don't even know what (legitimate) services other researchers in
the building are running on GLOBUS_TCP_PORT_RANGE - let alone random users
in shared areas - and I certainly can't unilaterally demand they be
suddenly exposed to the world at large!

I can see several options
o Shift services (esp. those accessed by UIs) to less contentious ports.
  Expect to have to do so again.
o Have end-users access "fixed" UIs via Web portals. This seems to be a
  common aim - but what's the timescale for deployment of usable
  general-purpose portals?
o Move the middleware to web services - everyone knows how to ship HTTP
  around. But it won't happen for a while (and bulk data transfers will
  still be an exception)
o Deploy proxy servers for existing protocols. Long time-scale; a lot of
  effort, wasted if middleware moves to web services.

I'm not actually surprised that there's opposition to the hassle of a fix
solely for Brunel's benefit, but on the other hand it's not clear that the
issues surrounding the deployment of end-user UIs have really been looked
into: is it really only Brunel that has these issues - or is it that
everyone else has their UI for testing on the same special subnet as their
resources?

It's a bit sad that experiments are currently trying to get more of their
members to use the Grid, yet here we can't accommodate them even though we
have the potential resources to do so. Note that none of the options above
provides an overnight fix, so I take it people are pretty confident that
only Brunel is affected.


Stephen Burke also wrote elsewhere:

> PS Maybe people will be happy when everything is web services and it all
> uses the same port, so nothing can be blocked ... ?

That's one fix. Of course, you've noticed that RAL has web content
filtering, and Brunel has it too... I hope someone developing
web-service-based Grids has looked at how these filters will affect
service latencies and throughput. I suppose I should really ask how
Brunel's WebSense box works _before_ I try another R-GMA "service
challenge"...


> If ports are being closed just because someone *might* use them for an
> exploit I can only assume that we have to give up on the public
> internet.

But I think that's actually a pretty common situation - how many
institutions let you SSH or telnet to an arbitrary machine? Most machines
are secure, but someone *might* have created a root account with a
password of "12345" or similar. And that does happen - and often enough
that the hassle of orchestrating all those attacks that appear in our logs
is worthwhile...

---
input_userauth_request: illegal user root
Failed password for illegal user root from 61.82.81.117 port 41833 ssh2
Received disconnect from 61.82.81.117: 11: Bye Bye
User root not allowed because not listed in AllowUsers
input_userauth_request: illegal user root
Failed password for illegal user root from 61.82.81.117 port 41905 ssh2
fatal: Read from socket failed: Connection reset by peer
input_userauth_request: illegal user slapme
Failed password for illegal user slapme from 61.82.81.117 port 40840 ssh2
Received disconnect from 61.82.81.117: 11: Bye Bye
input_userauth_request: illegal user oracle
Failed password for illegal user oracle from 61.82.81.117 port 40948 ssh2
Received disconnect from 61.82.81.117: 11: Bye Bye
---

...
> RAL has now unblocked that [web]site, so I can now see that it's a very large
> list which includes ports 80 and 8080, should we block those too?

I'm amazed no-one has pounced on the paradox inherent in that question...


Henry

* so that our network people can't see them (I never wrote that, right?
For some reason I keep thinking of the Dilbert cartoon where the project
plan involves triggering a turf war between Production and Accounting,
feeding dis-information to Marketing, etc.)

--
Dr. Henry Nebrensky                     [log in to unmask]
                             http://people.brunel.ac.uk/~eesrjjn
"The opossum is a very sophisticated animal.
 It doesn't even get up until 5 or 6 p.m."