RCS Upgrade Procedure
Upgrade to 9.2.x
Revision
Author (s)
Release Date
1.0
FAE Team
2014, March
Contents
1
2
3
Objectives ................................................................................................................4
Upgrade to RCS 9.2.x ..............................................................................................5
2.1
Prerequisites .............................................................................................. 5
2.2
Must know about 9.2.x ............................................................................... 5
2.3
Upgrade Procedure .................................................................................... 8
2.4
Anonymizer uninstallation .......................................................................... 9
2.5
Anonymizer installation ............................................................................ 10
2.6
Anonymizer security checks .................................................................... 10
2.7
Collector security checks ......................................................................... 11
2.8
Master Node security checks ................................................................... 11
Appendix ................................................................................................................12
1 Objectives
The purpose of this document is to describe the procedure to upgrade existing RCS installations with
live agents to version 9.2.x. This procedure must be considered especially in case that on the existing
system are present live agents or evidences that must be safeguarded.
2 Upgrade to RCS 9.2.x
2.1 Prerequisites
The following prerequisites must be respected to perform a successful upgrade:

Multi-Tier RCS Installation (if the system is an All-in-One configuration, stop the procedure and
notify it);

Supported Operating System Language (If the language of servers O.S. is different from all
the following: english, italian, spanish, russian. Stop the procedure and notify it);

Windows Updates: Check windows updates to the last update available on all RCS local
servers (Master Node, Collectors, Shards);

Compliancy with HT Technical Requirements: Verify to be totally compliant with the technical
requirements (attached at the end of the document);

New license file valid for version 9.2.x;

Installer executables for version 9.2.0 and for the last 9.2.x;

Two new Anonymizers (we recommend to rent them from different providers).
2.2 Must know about 9.2.x
RCS 9.2.x introduce new features with several security enhancements. For this reason all existing
agents (pre 9.2.x upgrade) that are used to communicate with a 9.1.x infrastructure are not allowed to
be considered as part of new 9.2.x deployment. As consequence new agents must sync with at least 2
new anonymizers never used with 9.1.5 and existing agent will continue to sync only with existing
anonymizers as represented on the following diagram:
Anonymizers configuration after upgrade to 9.2.x
Communication flows after upgrade to 9.2.x
NOTE:
For security reasons we recommend to keep no more than 2 of old Anons.
For fallback purposes on existing anons, we recommend to configure 2 Anonymizers on existing
agents configuration.
To do this, (assuming as example you have 1 anon in China and 1 in Germany) you have to configure
2 sync sub-task inside of the “SYNC” action of your agents configuration.
“SYNC” Action inside of agents configuration
Configure the first sync sub-task for the first Anon (more far from your collector), with the “stop on
success” flag enabled
Configuration of the main anon
Configure the second sync sub-task for the second Anon (near from your collector), with the “stop on
success” flag disabled
Configuration of the fallback anon
Existing Agents Upgrade
According to enhancements on security of 9.2.x platform, existing agents are allowed to send
evidences to RCS 9.2.x installations but could not be upgraded to 9.2.x. This means that any Scout
agent must be upgraded to Elite before the upgrade.
To do this follow the following task list:

Verify if any backdoor have to be upgraded from Scout to Elite;

Check for valid targets;

Upgrade this agents to Elite before 9.2 upgrade;

Wait until every existing agent perform a synchronization to the server and becomes Elite.
NOTE:
No further changes will be possible to pre-9.2 agents/anons after upgrade to 9.2. Agents
deployed before the upgrade will sync only to anons used before the upgrade and pre-9.2
backdoors will not be upgradable after 9.2 upgrade
2.3 Upgrade Procedure
1. Check that Windows Firewall is running on on all your servers (Master Node, Collectors,
Shards);
2. Check windows updates to the last update available on all your servers (Master Node,
Collectors, Shards);
3. Upgrade Master Node, Shards and Collectors as usual to 9.2.0 using the new license file;
4. Check that the Master Node folder C:\RCS\DB\cores is empty and no zipfile is there;
5. Check in RCS Console / Monitor that following Versions are reported:
Core
Version
Console
Android
BlackBerry
Linux
iOS
OSX
Symbian
Windows
WinMo
WinPhone
2014022401
2014022401
2013103101
2014022401
2014012001
2014022401
2013103101
2014022401
2012092801
2014022401
6. For each anonymizer already configured in the system, follow the steps in 2.4 Anonymizer
uninstallation
7. If the anonymizer can be removed from the system (no agent synchronizes on it), delete it;
8. If hostnames are used instead of IP addresses for anonymizers configuration, drop the
existing domains and use new ones;
9. Create the entities for the new anonymizers to be added (check that they're from different
providers);
10. Create the chain;
11. Click on Apply configuration (this time the procedure will fail);
12. For each anonymizer in the system, follow the steps in 2.4 Anonymizer uninstallation;
13. Check that everything is working flawlessly;
14. Upgrade to the last 9.2.x on both all your servers (Master Node, Collectos, Shards);
15. For each anonymizer in the system, follow the steps in 2.6 Anonymizer security checks;
16. Follow the steps in 0
17. Collector security checks;
18. Follow the steps in 2.8 Master Node security checks;
19. Create a new agent, infect a test target and check that the synchronization occurs flawlessly;
20. Remember that all the new agents should have the main synchronization action on the first
anon, and the fallback on the second as described in 2.2 Must know about 9.2.x;
2.4 Anonymizer uninstallation
NOTE:
DO NOT DELETE THE ANONYMIZER FROM THE CONSOLE
1. Login via ssh to the vps
2. Execute: /etc/init.d/rcsanon stop
3. Execute: /etc/init.d/bbproxy stop
4. Execute: chkconfig --del rcsanon
5. Execute: chkconfig --del bbproxy
6. Execute: rm -rf /opt/bbproxy /opt/rcsanon /etc/init.d/bbproxy /etc/init.d/rcsanon
2.5 Anonymizer installation
NOTE:
THE INSTALLATION PACKAGE IS SPECIFIC FOR EACH ANONYMIZER, DO NOT REUSE
IT
1. Login to the console;
2. Go to System / Frontend;
3. Select the anonymizer;
4. Click on Download Installer (different for each anonymizer);
5. Copy via scp/sftp the anon_install.zip to the vps;
6. Login via ssh to the vps;
7. Execute: Unzip anon_install.zip
8. If you want to monitor the anonymizer, execute: sh install <public ip of network controller>
9. If you don’t want to monitor the anonymizer, execute: sh install none
10. Reboot the vps.
2.6 Anonymizer security checks
1. Login via ssh to the vps
2. Change password if not strong (min. 8 char, 1 symbol, 1 number, mixed case letters) with the
command passwd
3. Check that bbproxy is running executing: ps axu | grep bbproxy
4. Check firewall rules executing: iptables -L
5. Connect from an external machine to vps IP on port 80 (http) with a browser, it must report an
error (connection reset - no data);
6. Connect from an external machine to vps IP on port 443 (https) with a browser, it must report
an error (connection failed - timeout);
7. If you specified the network controller IP during the installation, check the monitor status in the
console;
NOTE:
be used
Firefox Browser error messages are self-explaining and could be much more comfortable to
2.7 Collector security checks
1. Check that boarder firewall (network device) rules allow only incoming connections on port 80
from IP addresses of anonymizers in the chain, DROP EVERYTHING ELSE;
2. Scan Collector public IP with nmap for TCP/UDP, expect no reply (ports: 135/tcp, 442/tcp,
443/tcp, 444/tcp, 445/tcp, 1947/tcp, 49154/tcp must report as "filtered");
3. Connect from an external machine (from the Internet) to Collector on port 80 (http) with a
browser, it must report an error (connection failed - timeout);
4. Connect from an external machine (from the Internet) to Collector on port 443 (https) with a
browser, it must report an error (connection failed - timeout);
5. Check that there are no other public services (webservers, databases, remote desktops, etc...)
in the same network block.
2.8 Master Node security checks
1. Check that all the application users (or at least ADMIN, SYSADMIN and TECH users) have a
strong password;
2. Check log files (C:\RCS\DB\logs\err\*) for 'controller' and 'console' suspicious entries.
3 Appendix
RCS Technical Requirements v.2.3.1
Adobe Acrobat
Document