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

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 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

-----Original Message-----
From: [] On Behalf Of 
Keith Lofstrom
Sent: Wednesday, February 14, 2018 4:13 PM
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 Lofstrom
PLUG mailing list
PLUG mailing list

Reply via email to