[tech] Clarification of requirements and plan of action

[John Hodge]

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>
> *Sent:* Tuesday, 14 April 2020 10:31 AM
> *To:* John Hodge <tpg at ucc.asn.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
> 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>
> *Sent:* Thursday, 9 April 2020 8:27 AM
> *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>
> *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/e79e4471/attachment-0001.htm