[tech] Clarification of requirements and plan of action

Sun Apr 19 22:59:51 AWST 2020

Hi John,

How are you?

"If not: What size network segment can be left for us to firewall? You seem to be implying that a /26 is acceptable?"

The 130.95.13.0/26 is what was requested from the UCC in our first meeting and I am  championing that on your behalf however there are no guarantees, it will be firewalled.

Certainly the intent of the communication was all services inbound would require inbound proxy and Splunk logging feeds in the current network configuration.

There may be an opportunity for the UCC to continue to operate with layer 2 segregation direct connected to the perimeter firewalls as per your conversation with Craig Williams however that is not in my scope and you will need to pursue that if it is to become a reality.

As a network and application security professional you may recall my recommendation was 1 ip address inbound should be sufficient.

In retrospect this doesn't give you much latitude, if you are asking my opinion a /29 should be more than sufficient and it should be outside the 130.95.0.0/16, everything proxied.

That's what you should be planning for. I am limited in the resource allocation I have and I want to maximise what I have available to achieve the best outcome for the UCC in this transition.

Start with a /29 as a plan, if you need more explain it.

"several PHD projects", can you list the PHD projects that UCC are currently championing and what inbound network services these may require. Anything that you are doing that aligns with Universities Core Values and Champions learning will assist the UCC's cause.

Thanks
Paul

________________________________
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
     *   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).
     *   We use our own border firewall, which is rather selective in what ports are opened for each host.
     *   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?
     *   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 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/20200419/34ce8c89/attachment-0001.htm 