Linux Working Group

Meeting Date

• TEAMS: 2021-07-27

Invitees - Attendees

• Dave, Adrian, Anthony, Clayton, Lori, Nathan, Todd

Review and accept previous meeting minutes.

• accepted

Agenda Items

Updated Authentication stack for off campus accessible servers.

• review/compare requirements direct from Jason versus what was presented at IST SOC. (need references
• Mike Paterson email 2021-07-22, 10:56 a.m.:

Sorry, I was halfway through a reply and then my imac rebooted spontaneously. :| I realized I forgot to answer your secondary question, which was what's the recommendation for keys.

Long answer: https://uwaterloo.atlassian.net/wiki/spaces/ISTKB/pages/1548878163/SSH+Key+Generation - linked to from the Authman Documentation tab too.

Short answer: ed25519 keys are preferred; if RSA is required, then 4k+ keys are required.

Mike

-- Mike Patterson - pronouns he/him - Manager, Information Security Operations Information Security Services, University of Waterloo +1 519-888-4567, x47178 / mike.patterson@uwaterloo.ca Security Operations Centre x41125 / soc@uwaterloo.ca

On Thu, 22 Jul 2021 10:04:44 -0400, mpatters wrote: ... > It might help to think of the mitigation noted in the memo, in reverse
> order, as a priority list, with step 0 having been left off.
>
> 0 - if folks don't need to ssh to the system, shut off the service.
>
> 1 - if possible, restrict access to the system from off-campus
> (network+host firewall policies) and require the VPN,
>
> 2 - if off-campus access is required, decide if you
> a) want to allow passwords but enforce 2FA
> XOR
> b) want to restrict access to only keys.
>
> So keys-only is fine, passwords+2fa are fine, passwords for an on-
> campus only service are fine (consider restricting only to sources
> that require it if you can), but keyboard-interactive with no 2fa for
> off-campus is not fine. I suppose you could use keys only + 2fa if you
> liked as well.

• IST SOC:

  Due to the increasing security threats leveraging passwords, the University of Waterloo has moved to require that all SSH Servers exposed to the public Internet must enforce strong authentication by November 1st, 2021.

  The host(s) listed above appear(s) to allow password authentication. We ask that you make one of the following changes to the configuration of your SSH server(s) before November 1st:

  1. Disable all SSH authentication methods except for “publickey”.
  2. The authentication method “keyboard-interactive” may be enabled only if authentication to the host requires multifactor authentication.
  3. Prevent SSH authentication from off-campus with the use of a firewall.

• new authentication stack to the general use test machines (ubuntu2004-000.student.cs and ubuntu2004-100.cs) by the end of this month (July 2021)
• tuned stack to be deployed on all general-use systems on the morning (pre 8:00am) August 31, 2021.

CVE-2021-33909 zero day security attack: "Local user can elevate themselves to root privileges"

• RT#1166688
• need to get any host that allows interactive non-admin capable users running older than 18.04 upgraded or decommissioned ASAP.
• Also need to get kernels updated on 18.04 and newer hosts ASAP.
  • this leads to who is responsible for each system, so see next item:

Inventory missing data requirements

• Need host admins to fill in Admin Contact

• • Ask Lawrence (or Dave) to request Daniel? generate a hostname list that have null/empty fields for these two items.
  • watch for URL to this list in CSCF Linux channel and maybe new RT's for flagged systems.

Is 167 network working between DC and M3?

• Nathan to create ticket on problems he experienced WRT haproxy failover of service from DC to M3

Vulnerable/obsolete VMWare ESXi at 10.15.167.145, hostname vmserver212.cscf.uwaterloo.ca

• IST RT#1166671
• CSCF RT#1167022
  • Plan in place for Clayton to upgrade the vmware ESXi instance on hardware.
  • No services will be interupted as part of this work.