A. Reconsider allowing all outbound TCP/IP connections. Once in place
the ircbot was able to successfully perform its function because all
outbound TCP/IP sockets were permitted by default. Would restrictions
on outbound TCP/IP sockets have enabled perfSONAR installations to
fulfil their functions with integrity, even with an exploitable
apache/bash and the ircbot software running?
B. Consider separating the perfSONAR functions. [3] already describes
how to set up a "Level 1" installation that only fulfils function # 1.
I'm guessing that "Level 1" perfSONAR installations could fulfil
their (more limited) functions even running vulnerable bash.
C. Consider using a hypervisor to isolate functions. One might not
have enough money, space, power or cooling to run separate physical
perfSONAR hosts for each function. Just as Amazon Web Services uses
Xen [4] to keep customer VMs isolated, perhaps a future generation
of perfSONAR could be a "cloud in a box"?
Even if a perfSONAR functional virtual machine kernel was compromised,
use of a Xen Driver Domain [5] could provide additional integrity
resilience:
"Because of the nature of network protocols and routing, there is a
higher risk of an exploitable bug existing somewhere in the network
path (host driver, bridging, filtering, &c). Putting this in a
separate, unprivileged domain limits the value of attacking the
network stack: even if they succeed, they have no more access than
a normal unprivileged VM."
D. Consider preferring external MySQL services for BUOY. Amazon Web
Services provides MySQL [6] in their Free Usage Tier [7]. Alternatively,
many institutions running perfSONAR might already run MySQL for
other purposes.
E. Include explicit configuration for logging events to Security Incident
Event Managers (SIEMs). Many institutional cyber security organizations
run SIEMs already, and can accept (e.g.) SYSLOG records. Integrators
of the various perfSONAR services might ensure that logging is being
fed to the platform's SYSLOG collector. perfSONAR configuration
mechanisms and training could explicitly support integration with
popular SIEMs like Arcsight [9] and Splunk [10].
F. Tripwire. The Bash exploit gained apache user level access. What
might have been compromised besides the IRC bot net dropper in /tmp?
A custom tuned Tripwire [11] configuration might have identified
the unusual files in /tmp, leveraging the fact that perfSONAR hosts
generally don't host interactive users that put unpredictable files
in /tmp.
G. Consider alternative configuration approaches. [12] is a good first
start, but its scope is limited to application configuration.
Large Linux-based cluster supercomputers don't expose Apache for
system administrators to configure each node. Instead, they use
tools like the Open Source Cluster Application Resources (OSCAR [13])
to "install[] and configure[] all required software for the selected
packages according to user input. Then it creates customized disk
images which are used to provision the computational nodes in the
cluster with all the client software and administrative tools needed
for immediate use."
SUSE's Yet another Setup Tool (YaST [14]) includes AutoYaST [15];
its control file is in XML and it includes a configuration interface
called the Configuration Management System (CMS).
See also Trey Dockendorf's survey of host configuration tools [16].
arlake228
commented
9 years ago
Original issue 1009 created by arlake228 on 2014-10-26T22:44:36.000Z:
Here are some suggestions from Bill send to the user list after 'shellshock'. https://lists.internet2.edu/sympa/arc/perfsonar-user/2014-10/msg00091.html
These should be reviewed and considered for v3.5:
A. Reconsider allowing all outbound TCP/IP connections. Once in place the ircbot was able to successfully perform its function because all outbound TCP/IP sockets were permitted by default. Would restrictions on outbound TCP/IP sockets have enabled perfSONAR installations to fulfil their functions with integrity, even with an exploitable apache/bash and the ircbot software running?
B. Consider separating the perfSONAR functions. [3] already describes how to set up a "Level 1" installation that only fulfils function # 1. I'm guessing that "Level 1" perfSONAR installations could fulfil their (more limited) functions even running vulnerable bash.
C. Consider using a hypervisor to isolate functions. One might not have enough money, space, power or cooling to run separate physical perfSONAR hosts for each function. Just as Amazon Web Services uses Xen [4] to keep customer VMs isolated, perhaps a future generation of perfSONAR could be a "cloud in a box"?
D. Consider preferring external MySQL services for BUOY. Amazon Web Services provides MySQL [6] in their Free Usage Tier [7]. Alternatively, many institutions running perfSONAR might already run MySQL for other purposes.
E. Include explicit configuration for logging events to Security Incident Event Managers (SIEMs). Many institutional cyber security organizations run SIEMs already, and can accept (e.g.) SYSLOG records. Integrators of the various perfSONAR services might ensure that logging is being fed to the platform's SYSLOG collector. perfSONAR configuration mechanisms and training could explicitly support integration with popular SIEMs like Arcsight [9] and Splunk [10].
F. Tripwire. The Bash exploit gained apache user level access. What might have been compromised besides the IRC bot net dropper in /tmp? A custom tuned Tripwire [11] configuration might have identified the unusual files in /tmp, leveraging the fact that perfSONAR hosts generally don't host interactive users that put unpredictable files in /tmp.
G. Consider alternative configuration approaches. [12] is a good first start, but its scope is limited to application configuration.