Here are some thing to think about.
If you can't eliminate the ssh access, reduce it to the minimum possible.
Control the direction of traffic. Change from external pushing to internal, to
internal pulling from external. Confine ssh access to sftp only access.
Restrict who can ssh. Look into the use of command locked ssh keys
https://research.kudelskisecurity.com/2013/05/14/restrict-ssh-logins-to-a-single-command/
Rsync, for example, can be restricted with the use of a command locked ssh key.
Node lock the command locked ssh keys. Patch. Have good firewalls. Don't
run unnecessary services.
Cathy
--
Cathy L. Smith
IT Engineer
Pacific Northwest National Laboratory
Operated by Battelle for the
U.S. Department of Energy
Phone: 509.375.2687
Fax: 509.375.4399
Email: [email protected]
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Keith Lofstrom
Sent: Wednesday, February 14, 2018 4:13 PM
To: [email protected]
Subject: [PLUG] Meltdown/Spectre, older distros, virtual hosting
Meltdown and Spectre are potential security exploits of flaws in advanced CPU
architectures (Intel, ARM, probably AMD). Flaws that have been there decades,
but discovered and publicised only recently.
I am no security guru, so my strategy has been to use conservative "proven"
distros (like Red Hat Enterprise Linux clones, vetted by third parties), and
let others stick their necks out. However, RHEL7 uses the Linux
3.10 kernel, and attempted kernel fixes do not appear until the 4.14 kernel.
It may be a year or two before these new kernels become "old, tested" kernels.
On the one hand, my outward facing systems are virtuals, running as guests at
Linode and Rimuhosting, with Xen hypervisors that are being upgraded and
bulletproofed right now. I have daily backups.
On the other hand, my internal systems are older, and connected to those
world-exposed systems by VPN links, and apps like postfix and rsync and ssh.
My backups are accessable on the internal network.
As it stands today, if one of my world-exposed systems is compromised, either
directly or via the hosting company's hypervisor, the Bad Guys MAY be able to
crawl up the VPN tunnel and tamper with my internal systems, and my backups.
Is there a simple way to tweak the ssh process from the internal network so
that it cannot be exploited from the world-exposed virtual systems?
Am I worrying too much?
Keith
--
Keith Lofstrom [email protected]
_______________________________________________
PLUG mailing list
[email protected]
http://lists.pdxlinux.org/mailman/listinfo/plug
_______________________________________________
PLUG mailing list
[email protected]
http://lists.pdxlinux.org/mailman/listinfo/plug
