 |
 |
LHC Computer Grid - Rollout > [mailto:[log in to unmask]] On Behalf Of Henry Nebrensky said: > > 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. Laptops are outside firewalls a lot of the time - well, mine is currently behind one, but it's under my control. Wireless networks seem to go for two solutions; at e.g. RAL it's easy to connect and users have to protect themselves, at e.g. Brunel you have a lot of security and I for one didn't get it to work at all. In any case, so far we have mostly gone for the fixed UI solution rather than having the clients on laptops. > 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... They can, they just have to be able to ssh to e.g. lcgui.gridpp.rl.ac.uk. I suspect what you have in mind are graphical UIs, but even then it's not particularly obvious; the genius-type model has only a web browser as a client, or you can run remote x clients and send them back over ssh (err, if that isn't blocked too!) > 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! Basically it seems to me that what you're saying is that at Brunel you're no longer able to use the internet. Blocking inbound ports is one thing, but if you can't even make outbound connections you can't use it. Brunel should perhaps not have joined the grid, since your policy is apparently not to allow any use except web browsing ... that may be a bit more secure, but it's not very useful for a technology-oriented university! > I can see several options > o Shift services (esp. those accessed by UIs) to less > contentious ports. I don't believe there is any such thing. Hackers can clearly use any port, including port 80. In the past they may have picked, say, 7777 because if all ports are open it makes no difference, but if they find that those ports are generally closed they'll just move to others. > 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? Genius has been around for two years or so. > 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) And it's no more secure, it just prevents sites from blocking it - at least until we get firewalls which can filter on the content of SOAP messages! > o Deploy proxy servers for existing protocols. Long > time-scale; a lot of > effort, wasted if middleware moves to web services. Also it doesn't help if you want autonomous UIs. > 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? Certainly I'm not aware that anyone else has complained about outbound access to ports with repeating numbers, and presumably it does in fact work at all the sites in LCG. > 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. If services use https it's normally not cached or filtered because there's no point, all you can do is block specific addresses. Of course, you can't stop hackers using https themselves ... > > 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... That was of course the point, port 80 is not blocked because users would scream too much, even though the risk is pretty much the same. (Much like the fact that we don't have speed limiters in cars ...) Stephen