Vault 7: Projects

This publication series is about specific projects related to the Vault 7 main publication.
SECRET//20350112
- Master Server’s ethernet interface is down (or more severe server issue)
- Network Infrastructure is misconfigured/down
(U) Try pinging the Slave server’s “Persistent” IP address (see the network diagram of
5.1). If you cannot ping the Slave server IP, then it is more likely that the issue is related
to the network infrastructure (i.e., it is less likely that both Master and Slave server have
failed closely together in time) – contact an appropriate sponsor network engineer for
assistance. If you can ping the Slave, it is more likely that the issue is related to the CB
Master server – continue to section 8.2.2.
8.2.2 (U) Master Server Service Diagnostic
(U) Assuming you can ping the Master server, the next step is to determine if the CB
services are functioning properly. Open a “root” console (see 5.4) to the CB Master
server. If you cannot establish a “root” console to the CB Master server, then establish a
DRAC connection (a sponsor network engineer must be consulted for this step). Select
“console” from the DRAC menu, and from this DRAC console, verify that sshd is
running (ps –efal | grep sshd). If sshd is running, then the issue is likely either a Master
server iptables/firewall issue, or a network infrastructure issue. IMPORTANT: CB
servers use a special iptables configuration process – do NOT manually restart iptables –
contact an appropriate CB staff member. At this point, the best course of action is to soft
reboot (i.e., not a power-cycle / hard reset as described in section 8.4) the Master server
through the DRAC. When the server reboots, it should have the same iptables settings
that would have been comprehensively tested at the last server install/upgrade. If, once
the server reboots, you still cannot open a “root” console to the Master server, then the
problem is likely related to the network infrastructure – contact an appropriate sponsor
network engineer for assistance. If the network checks out, then it is possible that the
server has had a more severe (hardware) failure and must be taken off line – contact an
appropriate CB staff member.
8.2.3 (U) Master Server Post-Reboot Diagnostic
Once the CB Master server has been rebooted, it should be back to a state that had been
comprehensively tested during the previous server install/upgrade, so CB services should
be running. Through the DRAC console, verify that the CB services “CherryTree” and
“CherryWeb” are running. These processes will show as “java” processes – a “ps” should
show you two java processes using “CherryTree.jar” in the classpath. If this is not the
case, then there is a problem with the Master server boot/initialization/startup script –
contact an appropriate CB staff member. If you do see these processes, then reattempt
whatever initial action was causing problems. If you’re still having problems, at this point
it is best to contact a sponsor network engineer.
8.2.4 (U) Managed Switch Connecting CB Master & Slave Server
(U) Previously, a problem arose with the Managed Switch to which both the CB Master
and Slave are connected. The problem can be detected as follows. Open a “root” console
(see section 5.4) to the CB Slave server. From this console, ping the Master server and
ssh into the Master server (using PuTTY). If the ping is successful and the ssh is
unsuccessful, then there is likely a problem with the managed switch connecting the CB
SECRET//20350112
17