Where can I find more information on AOS Security?
Resolving the problem
Assist On-Site Security
Security and privacy are fundamental concerns when granting remote access to corporate IT assets. Assist On-Site uses the latest security technology to ensure that the data exchanged between IBM Support engineers and our customers is completely secure. Identities are verified and protected with industry-standard authentication technology, and Assist On-Site sessions are kept secure and private with the use of randomly generated session keys and advanced encryption.
Assist On-Site allows IBM Support engineers to remotely access customers' computers to identify and resolve technical issues in real time. Assist On-Site facilitates problem determination and remediation by providing a powerful suite of tools that enables IBM Support engineers to quickly complete root cause analysis and take appropriate corrective action.
How Assist On-Site Works
When a customer contacts IBM Support via ESR or 800-IBM-SERV and opens a PMR with an issue or question, an IBM Support engineer can initiate a screen-sharing session in order to facilitate problem determination. An IBM Support Engineer will refer the customer to the Assist On-Site URL- http://www.ibm.com/support/assistonsite where the customer will need to enter their name, customer number, PMR number, and a connection code (supplied by the IBM Support Engineer). The connection code is a one time use, seven digit, randomly generated code that is only valid for five minutes. The Support Engineer can extend the code time-out for ten additional minutes if necessary in order to accommodate slow network connectivity. The connection code is validated via a relay server, session keys are generated and the connection is established. On average, the length of time to fill out the form and begin the session is about one minute. There is no installation of software required, the plug-in downloads automatically via the customers’ web browser and is less than 600kb in size. The plug-in is kept secure and virus free on IBM’s Relay Servers and must be downloaded each time a session is established.
Once a screen-sharing session has begun, the Support engineer is connected to the customers’ computer via a relay server. Large, randomly generated session keys are issued to both participants to ensure that only the designated parties are connected. During the session, all transferred information, including screen views, file-transfer data and identities, are encrypted. Encryption and decryption are from end to end, so data can not be intercepted during transit and can only be viewed via the Assist On-Site console.
Authorization and Access Control
Assist On-Site sessions can only be initiated by a customer. During the initiation of a session, the customer can refuse receipt of the browser plug-in, thus refusing the download. If the customer accepts the connection, they can choose chat only, view only, or shared control modes of operation. During the session, the customer can retake control of the mouse and keyboard or end screen sharing altogether. Once a session has ended, the Support engineer can no longer connect to the customers’ computer. Any future sessions will require new session keys and can only be initiated by the customer.
Strong Password Protection
Assist On-Site sessions are protected by strong password authentication. Support engineers are authenticated using a challenge and response password exchange. IBM administrators can view audit reports detailing log-in failures associated with incorrect IDs or passwords via the Management Center.
Assist On-Site implements outbound connections protected by state-of-the-art 128-bit MARS encryption over an HTTPS browser session to prevent intruder access to the information exchanged during all Assist On-Site sessions. Chat, screen viewing, screen sharing and file transfer data is encrypted end to end, and packets are never decrypted in transit by the communication servers.
Assist On-Site works seamlessly with most firewalls. Usually, Assist On-Site connections are possible without any firewall reconfiguration. Assist On-Site requires access to outbound ports at both ends of a connection, so there is normally no need to open holes in firewalls.
Manual Proxy Configuration
Manual proxy configuration is supported via a configuration file- proxy_ibm.txt. This file requires the following format->
Where “1234” is the port defined on the customers’ outbound proxy.
The file should then be placed on c:\ directory or in the user Home directory
Ports, Relay Hosts, and IP Information
If additional configuration is required with a customers’ firewall or proxy, the following table describes required IP and port configuration->
|Hostname / GEO||IP||Ports|
|aos.us.ihost.com||184.108.40.206||8200 or 80 or 443|
|Americas Relay||220.127.116.11||8200 or 80 or 443|
|EMEA Relay||18.104.22.168||8200,443 or 80|
22.214.171.124 on port 8200 443, or 80
In order to leverage geographically specific relay servers and realize improved throughput, the customer should also allow encrypted non-SSL (MARs encryption) outbound traffic to one of the geographically specific relay servers - for either port 8200, 443, or 80:
126.96.36.199 aos.us.ihost.com (hosted in North America, best for most geographies)
188.8.131.52 aosback.us.ihost.com (hosted in North America, best for most geographies)
184.108.40.206 aosrelay1.us.ihost.com (hosted in North America, best for most geographies)
220.127.116.11 aoshats.us.ihost.com (hosted in North America, best for most geographies)
18.104.22.168 aos.uk.ihost.com (hosted in Europe, best for European, African, and some of Asia)
Assist On-site will automatically choose the relay server and port which will provide the best end-to-end performance. All relay servers are available from all geographies, with performance typically better from the relay server closest to the client system.
Logging and Auditing
Server side logging captures session information to include customer name and number, Support engineer name and number, customer and Support engineer IP and MAC address, and connection and disconnection time stamps. In addition to server side logging, customers’ can choose to audit the session locally. The logging is initiated from the customer and must be explicitly activated by the customer upon accepting the support session. To start the logging, the customer has to select the checkbox in the session acceptance dialog, as shown below.
Assist On-Site events are then written to the Windows Application log. Events stored are:
- Connection and disconnection
- Initial session mode and subsequent changes to different connection modes
- Names of files received and transferred
- When the system information is requested from the console
The following is an example of the events captured in the system application log during a session viewable via the Windows Event Viewer->
The screenshot of the first event is below. The additional events are illustrated via the text logged from the oldest event to the newest
--> INFO, Agent AgentX started Shared Control from 127.0.0.1[00:00:00:00:00:00] (Secure) (Linux),
--> INFO, System information sent to 127.0.0.1 (requested by user AgentX),
--> INFO, File MANUAL.TXT started to be received,
--> INFO, File MANUAL.TXT was received successfully,
--> INFO, File LotusInstall.log started to be sent,
--> INFO, File LotusInstall.log was sent successfully,
--> INFO, Session changed to Shared View,
--> INFO, System information sent to 127.0.0.1 (requested by user AgentX),
--> INFO, Agent AgentX's session closed normally,
The main driver is ibmaos.exe and it bundles forthook.dll, tgrab.sys and aosdel.exe.
Forthook.dll is used to put hooks on the mouse and keyboard so the program is aware of mouse position coordinates, its shape, and has the ability to inject (or reject) events into the windows event queue, and detect when the pause key is pressed to finish the session, etc.
Tgrab.sys is used to support full screen text mode windows.
Forthook.dll and tgrab.sys are deleted by the main executable (ibmaos.exe) when the session ends.
Aosdel.exe is tasked with deleting ibmaos.exe. Aosdel.exe is marked for removal so windows will automatically delete it on the next reboot.
Lastly, if the customer user is an administrator and system information is requested, a driver (egathdrv.sys) is copied to system32 and loaded in order to get system information such as the serial number of the machine. This driver is unloaded and deleted automatically once this operation finishes.
If you require assistance from Support, follow the information on this link:
This link is also accessible from the AOS-Admin portal:
login and then click on "Get Support"