[tech] Clarification of requirements and plan of action UCC
David Adam
zanchey at ucc.gu.uwa.edu.au
Fri May 1 22:21:50 AWST 2020
wireguard or similar to whatever our new public IPs are is probably the
answer here
[DAA]
On Thu, 30 Apr 2020, John Hodge wrote:
> Paul,
>
>
> After sending Tuesday's email, I was informed that our off-site backups use
> automated inbound ssh connections.
>
>
> Could you answer a few questions we still have?
>
> - How will we configure or view the contents of ucc.gu.uwa.edu.au domain under
> this new system?
>
> - How will the SSH (port 22) proxying work?
>
> John Hodge [TPG]
> UCC Wheel Member
>
> On 28/04/2020 10:17 pm, John Hodge wrote:
> >
> > Hi Paul,
> >
> >
> > Sorry (again) for the delay in answering, but thanks for the solid
> > timelines.
> >
> >
> > We have been waiting for someone to contact either James or Tim with access
> > to the cloudflare dashboard for ucc.gu.uwa.edu.au, so we can get it
> > configured with the required hostnames before the cutover date.
> >
> >
> > We are currently in the process of setting up a cloudflare account to host
> > our non-UWA domains, which should work as a temporary measure while progress
> > is made towards treating the UCC network as separate to the rest of campus.
> >
> >
> > Regarding ports to be blocked, thank you for providing the list. We do make
> > heavy use of port 22 to most hosts (often using port forwarding), so would
> > want that to continue to work in some form.
> >
> >
> > John Hodge [TPG]
> > UCC Wheel Member
> > On 22/04/2020 5:38 pm, Paul Fisher wrote:
> > > Hi John,
> > >
> > > We had a meeting to discuss the next steps for UCC, the action items to be
> > > undertaken are.
> > >
> > > * ucc.gu.uwa.edu.au and ucc.guild.uwa.edu.au delegation
> > >
> > > * ucc.asn.au domain
> > >
> > > * Inbound ports on 22, 53, 80, and port 443 to the COGLD
> > >
> > >
> > >
> > > 1) All sub delegations of the uwa.edu.au domain are being remediated and
> > > any zone records hosted outside of the main Cloudflare account will need
> > > to be updated into UWA's cloudflare zone. Completion date for this is
> > > scheduled for Friday the 1st of May. 10:30am
> > >
> > >
> > > 2) For the ucc.asn.au domain we would ask you create a free account with
> > > Cloudflare under your administrative control. UWA are accepting traffic
> > > from all affiliates via a TLS authenticated channel with Cloudflare only
> > > for https traffic on the perimeter origin F5's
> > >
> > > UCC will need to create an origin cert (15 Years) and have someone
> > > delegated to update the cert at short notice if required. I've attached
> > > the CSR for the request.
> > >
> > > You can create as many subdomains one level deep under the ucc.asn.au via
> > > api and they will be routed to a nominated IP. To support additional IP's
> > > you will need to supply a 1 to 1 url mapping of as many server IP's as you
> > > require. Additional IP's moving forward will be via a Service Request.
> > > I've given an example of how the url routing is configured on the F5 CF
> > > Origin.
> > >
> > > 3) Inbound ports on 22, 53, 80, and port 443 to the COGLD vrf will be
> > > restricted to UWA Campus and VPN on Scheduled 8th May 2020 10:30am. If you
> > > are using SSH for automated inbound data transfer, it will be reviewed and
> > > provision for proxy will be made available.
> > >
> > > For the rest of the services currently in operation a solution to maintain
> > > these inline with Cyber Security requirements of UWA is still in progress.
> > >
> > > Thanks
> > > Paul
> > >
> > >
> > >
> > > -----BEGIN CERTIFICATE REQUEST-----
> > > MIIC6DCCAdACAQAwaTELMAkGA1UEBhMCQVUxEzARBgNVBAoTCkNsb3VkRmxhcmUx
> > > HTAbBgNVBAsTFENsb3VkRmxhcmUgT3JpZ2luIENBMSYwJAYDVQQDEx1DbG91ZEZs
> > > YXJlIE9yaWdpbiBDZXJ0aWZpY2F0ZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
> > > AQoCggEBAKT9VAUpPJ7PuTuDP3Wm4yYvzUAgkRsh8sDVO1gD2V7wwqW7o6oqnAsX
> > > wuxBkPRCGY8Yv+LC2Q4HRRx8XwdxFxqQcqD175Rb4Ct9JZRb/wf+uoqZhkaldbCd
> > > ByxXMweOPYzRsNulFxpBEkIA9H8xW34Vn59GclTm+MZae7TgsfEwVry/EO0pMs97
> > > nuJg5fLjr0garXqxTL3s8m05qojdfyDhiuPjAabKsDnHfU5A2FGNZOOr8aggAFxR
> > > L/YExg86fy8YTumO/Jd2JKzaNYY+m/0+8juFJ3zCtQvj9ZoadSKi4NO6nvhRxD7H
> > > 7glrMEI1iHVhaw4mp303qPm9k5qXkw8CAwEAAaA6MDgGCSqGSIb3DQEJDjErMCkw
> > > JwYDVR0RBCAwHoIOKi5yY3N3YS5lZHUuYXWCDHJjc3dhLmVkdS5hdTANBgkqhkiG
> > > 9w0BAQsFAAOCAQEAXZobpC5a3rv6xAi8Hl9Pa0aBeJkVJglAaaD/E6XBfmFcvyWZ
> > > Qowy+19m6aIT6PSYaTuvtMpJxoog5VIcGX1vYodIEavZqp/qXJCYknDNCl8Krm8g
> > > vvycsat/9IdpbATqYvQHvEnn8C88FvH13MkKpi5xUHlwjmGrO4tD2b0pDSF8iqpa
> > > h6A9MCjkljorlFta9+RTPVMpvb1y9mW7jZ1PFJlkEiqu7pu6tHJpXgpprm6GGib/
> > > hatMTwkKgdZoOV7Fyd5BY0tLO3t/kA/78k6WNvg3FZG3GbY1i9WG/m2Icpd5BVxs
> > > yqRqCA1a1xkDBfX/dwrem+MrYABqtj1GUhQb+Q==
> > > -----END CERTIFICATE REQUEST-----
> > >
> > >
> > > "webdav.rcswa.edu.au"
> > > {
> > > pool ip_130.95.169.196_443
> > > set usessl 1
> > > }
> > > "*rcswa.edu.au"
> > > {
> > > pool ip_130.95.169.205_443
> > > set usessl 1
> > > }
> > >
> > >
> > >
> > >
> > > ------------------------------------------------------------------------
> > > *From:* John Hodge <tpg at ucc.asn.au>
> > > *Sent:* Sunday, 19 April 2020 9:29 PM
> > > *To:* Paul Fisher <paul.fisher at uwa.edu.au>
> > > *Cc:* Geoff Costello <geoff.costello at uwa.edu.au>; tech at ucc.asn.au
> > > <tech at ucc.asn.au>; wheel at ucc.asn.au <wheel at ucc.asn.au>; Jack Bryant
> > > <Jack.Bryant at uwa.edu.au>
> > > *Subject:* Re: Clarification of requirements and plan of action
> > > Paul,
> > >
> > >
> > > Sorry for the delay in answering, my small bits of free time have been
> > > taken up with adjusting to this social distancing thing (and I maybe spent
> > > too much effort on this email, trying to avoid confusion).
> > >
> > > Your email has raised some more questions, and doesn't seem to have really
> > > addressed our queries.
> > >
> > >
> > > From what I can glean, there's two primary tasks that your team is trying
> > > to address.
> > >
> > > * UWA wants central control and approval of all subdomains of
> > > .uwa.edu.au
> > > o Nick's email on 2020-04-17 12:10 covers parts of this
> > > relatively well, so I won't be addressing it in this email.
> > > * There should be no externally-accessible services on the
> > > 130.95.0.0/16 network that aren't either proxied through
> > > Cloudflare (For HTTP/HTTPS) or explicitly whitelisted.
> > >
> > > *
> > > *
> > >
> > > *Addressing your questions*
> > >
> > > *
> > > *
> > >
> > > *> You might consider the we are going to running the whole university on
> > > less than that.*
> > >
> > > Do you mean that UWA plan on exposing less than 64 hosts to the public
> > > internet? Does this count various faculty services (e.g. the computer
> > > science department's user servers).
> > >
> > >
> > > *> **/Are we in a position to alter the firewall rules from anything about
> > > 130.95.13.32/26 now? (Ed: /**/130.95.13.0/26)/*
> > >
> > > What particular changes are you referring to? As Nick covered in his email
> > > - we still don't have a working Cloudflare setup, so blocking port 443/80
> > > will break all websites hosted within the UCC network. Additionally,
> > > blocking port 53 will have similar impacts (including preventing our SSL
> > > certificates from updating).
> > >
> > >
> > > If you mean blocking any access to addresses outside 130.95.13.0/26, then
> > > that is also not yet possible as we have services scattered throughout the
> > > address range.
> > >
> > > Some context: We've separated our range into four regions: trusted hosts
> > > ("machine room" - physically isolated network), semi-trusted ("clubroom" -
> > > wired network in a semi-public space), member virtual machines, and then
> > > the upper quarter for misc services (e.g. NAT and VPN). There are public
> > > services (see the list below) that live in many parts of this range for
> > > various reasons.
> > >
> > >
> > >
> > > *> **/If you could have a look at the scan list provided and give a brief
> > > description of the hosts and there purpose from an educational purpose./*
> > >
> > > I've included at the end of this email a (maybe not too-brief) summary of
> > > each host on your list, and what services they provide. Many of those
> > > hosts were just exposing SSH (port 22), used for authenticated remote
> > > access.
> > >
> > >
> > > However - while the individual computers provide some assistance towards
> > > the club's primary objective (which, according to the constitution, is
> > > "for the advancement of computer science and technologies") by
> > > facilitating the development of interesting projects (e.g. the iodine VPN
> > > server, dropbear ssh server, and compute power for several PHD projects) -
> > > it is the role of the UCC network as a whole is the most relevant to this
> > > discussion.
> > >
> > >
> > > The UCC network in its current form (minimally fire-walled, overseen by
> > > "old guard") provides an enterprise-like environment for aspiring system
> > > administrators to develop and practice skills that would otherwise only be
> > > available via expensive training courses or years of industry experience.
> > > The services hosted by the UCC (e.g. a library catalog for the
> > > science-fiction club) assist the greater UWA community, and provide a set
> > > of clients who are (usually) understanding when things break due in this
> > > learning process.
> > >
> > >
> > > /Short version/: It's the network itself that provides the largest
> > > educational benefit, without that we're just a computer lab.
> > >
> > >
> > >
> > > *Further Questions:*
> > >
> > > * Is there any progress/possibility of UCC continuing to run a
> > > minimally fire-walled network segment (as we have done for over
> > > 20 years).
> > > o We use our own border firewall, which is rather selective in
> > > what ports are opened for each host.
> > > o Historically, it's only port 25 (SMTP) that has been blocked
> > > at the UWA border, to prevent students from sending spam.
> > > * If not: What size network segment can be left for us to firewall?
> > > You seem to be implying that a /26 is acceptable?
> > > o It'll take a few weeks to reorganize our network to move all
> > > public hosts into one block, see above comments about the
> > > network layout.
> > > * What network ports are intended to be wholesale blocked?
> > >
> > >
> > >
> > > *A summary of each host with open ports*
> > >
> > > * .1 (murasoi) is our primary router, it (like all other servers)
> > > exposes SSH for remote management. All publicly accessible SSH
> > > servers are protected by fail2ban to prevent brute-force attacks
> > > * .3 (mailauesi) is a proxy host for our mail services - exposing
> > > authenticated SMTPS, IMAPS, and POP3S
> > > * .6 (gitlab) is our source control server, running SSH (for both
> > > management and "git push") and HTTPS (for the web interface)
> > > * .7 (motsugo) is our primary user shell server (hence ssh & ident)
> > > and mail retrieval server (IMAPS and POP3S)
> > > * .8 (flame-tunnel) is firewall magic that forwards traffic on any
> > > port to the "Flame" chat service on port 4242. We're looking into
> > > decommissioning this one.
> > > * .9 (mooneye) is our DNS and mail server, also used to run our
> > > wiki (HTTP/HTTPS, it's been moved in the last few weeks).
> > > * .10 (myxine) is the machine that hosts our OCS Inventory system.
> > > This operates over HTTPS, hence that port responding.
> > > * .11 (ssh) is also firewall magic, this time forwarding all ports
> > > to SSH on port 22
> > > * .12 (ext-mx) is a legacy alias for mooneye, so responds on the
> > > same ports.
> > > * .18 (mussel) is our secondary shell server, and main web server
> > > (host user websites and the club's website)
> > > * .28 (secure) is firewall magic to distribute services to multiple
> > > computers (from before SSL certificates were free)
> > > * .34 (uccmonitor) is our monitoring dashboard, public so members
> > > can check up on system health
> > > * .36 (uccportal) is our member signup system
> > > * .38 (meetings) is our video/voice conferencing system, set up as
> > > the COVID situation evolved for use for tech talks. This server
> > > also uses UDP for video feeds.
> > > * .48 (titan) is a user server (An ARM architecture machine), hence SSH
> > > * .66 (heathred) is our general games server, often a new admin's
> > > first learning ground.
> > > * .72 (maaxen) is a Windows server (running a web server for
> > > windows-only web services)
> > > * .68 (unisfa-koha) is the library system for a neighboring club
> > > (web service)
> > > * .109 (eggman) is our clubroom music system.
> > > * .111 (evil) is a co-located machine run by a life member, does
> > > lightweight monitoring of the machine room and network (showing
> > > these results on a static webpage).
> > > * .137 (workhorse) is another shell machine (for doing heavy-duty
> > > computation)
> > > * .138 (chordata) is a member VM. Runs ssh and a web server
> > > * .146 (enemy-territory) is a game server VM, gets quite a bit of
> > > exercise now that we can't be on-campus to play together
> > > * .148 (experiments) is another member VM
> > > * .174 (diamond) is a member VM running a minecraft server
> > > * .177 (minecraft2019) is a club-operated minecraft VM
> > > * .185 (frekk-ucc) is a member VM with just ssh
> > > * .187 (james1-server) another member VM, just hosts a silly and
> > > static website (and ssh)
> > > * .189 ("Livorno") is another member VM
> > > * .190 (bluering) is another member VM.
> > >
> > > Note: We're in a flurry of upgrades and restructuring at the moment (Bored
> > > admins looking for things to do), leading to services being shuffled
> > > between hosts. (E.g. the wiki being moved off mooneye)
> > >
> > > John Hodge [TPG]
> > > UCC Wheel Member
> > > On 14/4/20 10:58 am, Paul Fisher wrote:
> > > > Hi John,
> > > >
> > > > My apologies.
> > > >
> > > > 130.95.13.0/26 is on the 64 boundary.
> > > >
> > > > Anything above 130.95.13.64 can be restricted?
> > > >
> > > > You might consider the we are going to running the whole university on
> > > > less than that.
> > > >
> > > > If you could have a look at the scan list provided and give a brief
> > > > description of the hosts and there purpose from an educational purpose.
> > > >
> > > > It doesn't have to be in great detail, just something that provides a
> > > > value proposition for education within the UWA core business setting.
> > > >
> > > > Something I can use to justify maintaining the services published in the
> > > > UWA network space.
> > > >
> > > > Thanks
> > > >
> > > >
> > > >
> > > > ------------------------------------------------------------------------
> > > > *From:* Paul Fisher <paul.fisher at uwa.edu.au>
> > > > <mailto:paul.fisher at uwa.edu.au>
> > > > *Sent:* Tuesday, 14 April 2020 10:31 AM
> > > > *To:* John Hodge <tpg at ucc.asn.au> <mailto:tpg at ucc.asn.au>
> > > > *Cc:* Geoff Costello <geoff.costello at uwa.edu.au>
> > > > <mailto:geoff.costello at uwa.edu.au>; tech at ucc.asn.au
> > > > <mailto:tech at ucc.asn.au> <tech at ucc.asn.au> <mailto:tech at ucc.asn.au>;
> > > > wheel at ucc.asn.au <mailto:wheel at ucc.asn.au> <wheel at ucc.asn.au>
> > > > <mailto:wheel at ucc.asn.au>; Jack Bryant <Jack.Bryant at uwa.edu.au>
> > > > <mailto:Jack.Bryant at uwa.edu.au>
> > > > *Subject:* Re: Clarification of requirements and plan of action
> > > > Hi John,
> > > >
> > > > It's good to hear from you, how are you?
> > > >
> > > > Things have been very busy for us working on the
> > > > https://unidesk.uwa.edu.au <https://unidesk.uwa.edu.au> solution.
> > > >
> > > > I've created the ucc.asn.au domain. I was waiting for you to give me one
> > > > or two pheme accounts that I can have access provisioned.
> > > >
> > > > I see 2 subdomains under uwa.edu.au delegated to ucc.
> > > >
> > > > ucc.guild.uwa.edu.au and ucc.gu.uwa.edu.au, I have created these as
> > > > subdomains in the account however it is unlikely from the discussion
> > > > I've had these will be able to be maintained as delegated subdomains.
> > > >
> > > > I've attached the zone files I have for these zones, if you can check
> > > > these for accuracy. I'll have the records added to the parent zone and
> > > > delegation removed.
> > > >
> > > > I will confirm a date with you before proceeding.
> > > >
> > > > Moving forward any records under uwa.edu.au are part of the corporate
> > > > brand and an approval process will be required to have names allocated
> > > > in the uwa.edu.au domain.
> > > >
> > > >
> > > > I can see additional domains registered in the 130.95.13.0/24 address
> > > > space.
> > > >
> > > > didcoe.id.au
> > > > shmookey.net
> > > > unisfa.asn.au
> > > >
> > > > Are these required moving forward?
> > > >
> > > > From out discussions we talked about 130.95.13.0/26 being route to the
> > > > perimeter firewall.
> > > >
> > > > Is this the desired outcome for UCC?
> > > >
> > > > I've attached a network scan for the 130.95.13.0/24 network. Are we in a
> > > > position to alter the firewall rules from anything about 130.95.13.32/26
> > > > now?
> > > >
> > > > Thanks
> > > > Paul
> > > >
> > > >
> > > >
> > > >
> > > > ------------------------------------------------------------------------
> > > > *From:* John Hodge <tpg at ucc.asn.au> <mailto:tpg at ucc.asn.au>
> > > > *Sent:* Thursday, 9 April 2020 8:27 AM
> > > > *To:* Paul Fisher <paul.fisher at uwa.edu.au>
> > > > <mailto:paul.fisher at uwa.edu.au>
> > > > *Cc:* Geoff Costello <geoff.costello at uwa.edu.au>
> > > > <mailto:geoff.costello at uwa.edu.au>; tech at ucc.asn.au
> > > > <mailto:tech at ucc.asn.au> <tech at ucc.asn.au> <mailto:tech at ucc.asn.au>;
> > > > wheel at ucc.asn.au <mailto:wheel at ucc.asn.au> <wheel at ucc.asn.au>
> > > > <mailto:wheel at ucc.asn.au>
> > > > *Subject:* Clarification of requirements and plan of action
> > > > Paul,
> > > >
> > > > I haven't seen an update from our discussion several weeks ago, so I
> > > > thought I'd put to paper some notes and queries about the move towards
> > > > Cloudflare proxying.
> > > >
> > > > My understanding is that UWA has decided (in response to one of the
> > > > steps in the ANU data breach) that websites hosted on 130.95.0.0/16
> > > > (UWA's IP range) should not be open to the general internet, and instead
> > > > should be protected by a reverse proxy (in this case, Cloudflare). To
> > > > this end, DNS is being pointed at Cloudflare (I assume because the DNS
> > > > service comes with the web proxy service?) and eventually ports 443 and
> > > > 80 inbound will be closed at the border firewall (with an exception for
> > > > the Cloudflare proxies).
> > > >
> > > > Queries:
> > > >
> > > > * What is the progress on getting access to the Cloudflare
> > > > dashboard? We would like to start on migration of services
> > > > before ports 443 and 80 start being blocked.
> > > > * Are there any other ports (apart from 80/443) that will be
> > > > blocked at the border?
> > > > * Is there any progress towards treating 130.95.13.0/24 as
> > > > "outside" in the core firewall (and thus side-stepping the need
> > > > to place UCC services behind Cloudflare)?
> > > >
> > > >
> > > > Examples of services that cannot work with the Cloudflare setup (running
> > > > both HTTP and non-HTTP on the same hostname):
> > > >
> > > > * GitLab (source control server): This runs both a web server (for
> > > > viewing source code, and managing permissions) and a SSH server
> > > > (used for uploading code in a secure manner). Neither of these
> > > > services support DNS "SRV" records (which would permit different
> > > > IP addresses for HTTP/HTTPS and other services).
> > > > * "Big Blue Button" (Video conferencing system): This sends its
> > > > video streams over UDP to a collection of high ports (audio is
> > > > sent over websockets). This system has been used to great effect
> > > > by the clubs impacted by the COVID-19 Cameron Hall shutdown, to
> > > > host their normal events in a virtual space.
> > > > * We currently have `secure.ucc.asn.au` that "hosts" a whole range
> > > > of encrypted services (IMAP, POP3, webmail, VPN).
> > > >
> > > >
> > > > --
> > > > John Hodge [TPG]
> > > > UCC Wheel Member
>
Cheers,
David Adam
zanchey at ucc.gu.uwa.edu.au
Ask Me About Our SLA!
More information about the tech
mailing list