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: cathy.sm...@pnnl.gov -----Original Message----- From: plug-boun...@pdxlinux.org [mailto:plug-boun...@pdxlinux.org] On Behalf Of Keith Lofstrom Sent: Wednesday, February 14, 2018 4:13 PM To: plug@pdxlinux.org 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 kei...@keithl.com _______________________________________________ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug _______________________________________________ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug