David – if time permits, I wonder if it would be more efficient to have a short Teams meeting in the next few days, prior to your meeting on the 30th, to make sure we have the correct focus. I’m not sure “Services” = “Software packages” but clearly this is how it is being interpreted – and if this is what is required, then wow what a task to collate all the information. Rich From: Will Pearse <will.pearse@imperial.ac.uk> Sent: 23 November 2022 17:06 To: Colling, David J <d.colling@imperial.ac.uk>; Bantges, Richard J <r.bantges@imperial.ac.uk>; Thomas, Andy D <andy.thomas@imperial.ac.uk> Cc: Bresme, Fernando <f.bresme@imperial.ac.uk>; French, Paul (PHOT) M W <paul.french@imperial.ac.uk>; Keaveny, Eric E <e.keaveny@imperial.ac.uk>; Sternberg, Michael J E <m.sternberg@imperial.ac.uk>; Staffell, Iain L <i.staffell@imperial.ac.uk>; Pengelly, Ellen <e.pengelly@imperial.ac.uk>; Buchaca-Domingo, Ester <e.buchaca-domingo@imperial.ac.uk>; Michalickova, Katerina <k.michalickova@imperial.ac.uk>; physics-departmental-computing <physics-departmental-computing@imperial.ac.uk>; Bryce, Craig T <c.bryce@imperial.ac.uk>; Bearpark, Michael J <m.bearpark@imperial.ac.uk>; Cucinotta, Clotilde <c.cucinotta@imperial.ac.uk>; David Colling <david.colling@gmail.com> Subject: Re: [Physics-Departmental-Computing] Services needed on a research computing desktop and laptop Hello everyone, I do hear what you're saying, and perhaps I am missing something here, but if I were to list every program that a member of my lab uses as part of their research the list would be long and ever-growing. Off the top of my head, today someone in my lab will have used: * GRASS * QGIS * ArcGIS * Libre Office * Word equivalent * Excel equivalent * Powerpoint equivalent * Office 365 * ...as above * R * Python * Ruby * Julia * RAxML * BEAST * MrBayes * WoK cloud API * Google Maps API * Twitter API (...for how much longer I don't know :p) * AREAData automated build and distribution API we manage * Tyrell (in-house automation and COVID data API) * Raven bioacoustics data * Pendant Loggers software ...I could keep going, I'm sure you see the point I'm trying to make. Some of these have exposed APIs and ports, some of them are 'just' programs that we need to be able to install. You might think the list would be smaller for people in DoLS who are less computational than my lab, but actually the problem would be worse because they use lots of bespoke software for weird bits of kit (DNA sequencers, microclimate loggers, bioacoustic sensors, ...). Fundamentally, I worry the tail may be wagging the dog here. If I were to put this provocatively, and I think unfairly but hopefully by reducing to the absurd I can make my point clearer, why should we have to demonstrate that our research is no danger to systems that are set up to support our research? Thanks, Will --- Measuring phylogenetic structure? Try install.packages('pez') Will Pearse (pearselab.com)<http://pearselab.com/> (he/him) Senior Lecturer, Imperial College London Department of Life Sciences LGBTQ+ champion On 23/11/2022 16:14, David Colling wrote: Hi Will, To some extent I agree with you, but I can quite imagine that there are plenty of college systems that I have never heard of that I don't need access to. I have no idea what systems HR use (and don't want to know) but I do know that I have never needed access to them. So if we can set up a list of what we do need and show that we are no danger to any central systems then I don't see how they can complain. Best, david On 23/11/2022 14:25, Will Pearse wrote: Hello everyone, I think we should compile a list of what people /shouldn't/ be able to do on research computers rather than what they /should/. I think such a list would be much shorter, and doing the opposite will massively hinder research. I think this is similar to what others have proposed below. Pragmatically, if ICT remove user control over the machines the users will jailbreak them to do their research. That would presumably be the worst case scenario from the perspective of security, and so I think it's in everyone's interests to give people control of their own computers. Cheers, Will --- Measuring phylogenetic structure? Try install.packages('pez') Will Pearse (pearselab.com) <http://pearselab.com/><http://pearselab.com/> (he/him) Senior Lecturer, Imperial College London Department of Life Sciences LGBTQ+ champion On 23/11/2022 11:20, Bantges, Richard J wrote: Hi Andy, ( & David) The College's Unified Access is another angle perhaps to consider for Imperial College users. I'm not qualified to comment how robust that is, but that opens up the entire Imperial College network from outside of the College, providing access to mapped network drives, shared windows directories and SSH access to all of our servers. We still maintain a couple of externally visible Linux SSH servers comparable to your "bastion" hosts (running fail2ban, etc.) to allow collaborators external to the College to access some of our systems / data albeit with restricted privileges. I'm trying to understand the scope / reach of ICT's aim here. I'd imagine for it to be effective, as any changes will only be as good as the weakest link, it'll be all encompassing - i.e. anything connected to the Imperial College network is to be scrutinised. I recall many years ago a printer being "hacked" and was printing reams of rubbish until it was fixed.. Rich -----Original Message----- From: Thomas, Andy D<andy.thomas@imperial.ac.uk><mailto:andy.thomas@imperial.ac.uk> Sent: 23 November 2022 11:02 To: Colling, David J<d.colling@imperial.ac.uk><mailto:d.colling@imperial.ac.uk> Cc: Bresme, Fernando<f.bresme@imperial.ac.uk><mailto:f.bresme@imperial.ac.uk>; French, Paul (PHOT) M W<paul.french@imperial.ac.uk><mailto:paul.french@imperial.ac.uk>; Keaveny, Eric E<e.keaveny@imperial.ac.uk><mailto:e.keaveny@imperial.ac.uk>; Sternberg, Michael J E<m.sternberg@imperial.ac.uk><mailto:m.sternberg@imperial.ac.uk>; Staffell, Iain L<i.staffell@imperial.ac.uk><mailto:i.staffell@imperial.ac.uk>; Pengelly, Ellen<e.pengelly@imperial.ac.uk><mailto:e.pengelly@imperial.ac.uk>; Buchaca-Domingo, Ester<e.buchaca-domingo@imperial.ac.uk><mailto:e.buchaca-domingo@imperial.ac.uk>; Bantges, Richard J<r.bantges@imperial.ac.uk><mailto:r.bantges@imperial.ac.uk>; Michalickova, Katerina<k.michalickova@imperial.ac.uk><mailto:k.michalickova@imperial.ac.uk>; physics-departmental-computing<physics-departmental-computing@imperial.ac.uk><mailto:physics-departmental-computing@imperial.ac.uk>; Bryce, Craig T<c.bryce@imperial.ac.uk><mailto:c.bryce@imperial.ac.uk>; Bearpark, Michael J<m.bearpark@imperial.ac.uk><mailto:m.bearpark@imperial.ac.uk>; Cucinotta, Clotilde<c.cucinotta@imperial.ac.uk><mailto:c.cucinotta@imperial.ac.uk>; Pearse, Will<will.pearse@imperial.ac.uk><mailto:will.pearse@imperial.ac.uk>; David Colling<david.colling@gmail.com><mailto:david.colling@gmail.com> Subject: Re: [Physics-Departmental-Computing] Services needed on a research computing desktop and laptop In CMTH access to all internal systems in the CMTH cluster from other parts of the College network, for example others parts of Physics, Maths, etc, and from outside the College is only possible via 3 "bastion" hosts which act as firewalls with in-bound ssh being the only service exposed to the network. They also run fail2ban to discourage repeated break-in attempts and these systems are kept up to date with security patches. In Maths, the situation is rather different - while nearly all systems are not directly accessible from outside College, they are accessible from other depts in College since their users often use Maths facilities. For access from outside, Maths has 3 ssh gateways similar to CMTH & running fail2ban and they accept external connections on the non-standard port 10022. Also users being what they are - especially UGs and MSc students who tend to hate the CLI and demand GUI coding interfaces such as Jupyter Notebook, R Studio server, VScode, Spyder 5, PySpark, etc, - we have a few dedicated compute servers that support direct ssh connections from outside College and users working remotely can then use ssh port forwarding and/or tunnelling to run GUI programming environments from home, halls of residence, etc over ssh without having to rely on the College VPN services which don't work for many Mac users (eg, MSc students based in China often find port 1194 used by OpenVPN is blocked by "state actors"). For an example of the documentation available for MSc students in the Stats section on hoe to do this, seehttps://sysnews.ma.ic.ac.uk/stats/MSc_compute_servers.html#GUI_setup So in reality, ssh is the Swiss army knife for a lot of research users ;) Andy On Wed, 23 Nov 2022, David Colling wrote: Hi Andy, Thanks for these. ssh access to remote servers is not controversial, but if you want ssh access to your machines in college, how do you ensure that your machines are fully patched and not providing a way into college for hackers? Or rather how do you persuade ICT that this is the case? In my group we have a team of three people who manage things like this (along with much much more) and these people are sufficiently respected and reliable for ICT to trust them. Best, david On 22/11/2022 23:45, andy thomas wrote: A plan by the Firedrake software development group in Maths to use four rackmounted Mac Minis in a build farm to help develop a Mac version of this software has been completely scuppered to date by ICT's insistence that all Macs - even those used as servers only accessible via ssh on isolated networks not connected to any College network - must be remote-managed by ICT via Apple DEP. With hindsight Maths should have bought these Macs from, say, PC World in Kens High St, not through an "authorised Apple dealer". Regarding services - and speaking for both the Maths dept and the Condensed Matter Theory group in Physics (CMTH) - almost all these research users use Linux or Mac desktop/laptop systems for whom the most important services are ssh (including services that rely on ssh such as scp & sftp) and https-based network connectivity. Most Linux/Mac applications use (or can easily be configured to use) ssh & https transports and ssh itself can also be used to create VPNs, using its tunneling & port forwarding features. Access via ssh to external services, institutions, etc is vital for these users as is the ability to use ssh for remote access into Maths & CMTH systems. Maths research IT is server-based & independent of central ICT services although for backwards compatability, login services on a few systems do access a subset of the College user account authentication maps via the central LDAP servers and central ICNFS home directory storage is used by some users with low storage space requirements. On the other hand, the workstation-based CMTH cluster is entirely independent of ICT with its own LDAP and user storage servers. With departmental facilities like these, many research users have no real need to use central services other than the network and DNS look-up servers, and there should be no need for research systems to be policed in the way ICT envisage. The College has a perimeter firewall and ICT are at liberty to run penetration/security tests on any systems they are unhappy about. Andy On Tue, 22 Nov 2022, David Colling wrote: Hi All, I am sending this to the Physics Departmental Computing Committee and to the departmental members of the FRCC so that they can gather information from their departments. As some of you know ICT are increasingly confining what people can do on college machines, even those bought on research grants and used by individual researchers. This has been most noticed by the change in the management of Macs. In my years involved in departmental computing, no issue has annoyed more people. Behind this is the increased number of attacks on university computing system which is visible both at Imperial and elsewhere. Some universities have been badly hit and have ended up paying £Ms to ransomware attackers. Apparently this is one of the things that keeps our President awake at night. This is clearly a threat that we have to take seriously, but it is also not clear how much damage could be done to college systems by a laptop or desktop used by a single (or team of) researcher(s). In discussions with ICT the most sensible approach seems to be that we define a class of machine that is a research desktop or laptop that ICT don't manage but which also has limited access to college central systems. Most of us have no reason to access payroll (say) and in fact would view it as a security breach if we could. We have a meeting on the 30th November where we will discuss this proposed set up. What I need going into is the list of services that researchers would need access to from these research machines, how that access would them + any other thoughts/comments. For example the sort of thing that occurred to me are: service: Office365 (including sharepoint, email, OneDrive teams etc) Access: Is access through the secure web portal enough for most of these plus a mail client providing secure access the the email. [I use Office365 much less than almost anybody to whom this email is going so am the least qualified to answer this one] Service: ICIS (Payslips, expenses claims etc) Access: Secure web access should be enough. Service: Starfish Access: Secure web access is sufficient. What other services are needed and how? Other comments: - I don't think that it is unreasonable to have a requirement that the disks of all research laptops are encrypted in case they are lost when travelling. The performance hit is minimal and if that is important then running on a laptop might not be ideal. So please do send me your thoughts (on services mainly) and comments. For once I would not be against you sending to everybody as I would welcome debate on this. Best, david _______________________________________________ Physics-Departmental-Computing mailing list Physics-Departmental-Computing@imperial.ac.uk<mailto:Physics-Departmental-Computing@imperial.ac.uk> https://mailman.ic.ac.uk/mailman/listinfo/physics-departmental-compu ting