[tech] Clarification of requirements and plan of action UCC
John Hodge
tpg at ucc.asn.au
Thu Apr 30 20:40:12 AWST 2020
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ucc.gu.uwa.edu.au/pipermail/tech/attachments/20200430/f5b08c2b/attachment-0001.htm
More information about the tech
mailing list