White-paper on Security in Application Enablement Services for the Bundled and Software Only Solutions

White-paper on Security in Application Enablement Services for the Bundled and Software Only Solutions Document Rev: 1.0.0 Date 05/15/2008 Introduction The AE Services 4.2 Bundled Offer comes pre-packaged with several security features and packages. For the Software Only Offer, the customer is primarily responsible for providing security for the server. This document provides information about the security features available on the AE Server and security guidelines for both Bundled and Software Only solution customers. In general the areas covered include: 1. Firewall 2. Monitoring Software (Shell and Intrusion Detection software) 3. Network Access 4. Default Logins and RBAC (Role Based Access Control) 5. Password Management 6. Account Management and Access Control 7. AE Services Application Links 8. Session Inactivity Timeouts 9. Audit trails 10. Certificates 11. Jar File Security 12. Warning Banners 13. Linux Installation and Software 14. Vulnerability Tracking 1. Firewall Firewall software provides protection to a server from the network. RedHat Linux ES 4.6 (Version 4 Update 6) comes with a firewall software package called iptables. It controls the network packet filtering code in the Linux kernel. The Bundled Server comes pre-packaged and pre-configured with firewall software. AE Services has implemented the firewall using the Red Hat Linux iptables package. The firewall is always on by default. The firewall on the Bundled Server will keep only specific ports and port-ranges open. Traffic on all other ports will be disabled by default. The firewall is filtered for all INCOMING (/UDP) connections/packets only. All 1

OUTGOING (/UDP) connections/packets are not filtered for any ports. Port filtering is turned on for each NIC of the Bundled Server. For the Software Only solution, we strongly recommend enabling the firewall on the AE Services server. The firewall software should be configured to use only those ports that are absolutely required. AE Services uses the following ports by default (for the Bundled and Software Only Solutions). Where appropriate, ports only accessible via the local loopback interface are marked as Local Only. For Local Only, AES components are connecting to other internal AES components using these ports. For Inbound ports, an entity external to AES is initiating the connection. For the application protocols, this will be a client application, but for protocols like H323 and RTP, these connections are initiated during registration and call setup. For Outbound ports, AES will initiate the connection setup. Port Used For Protocol Direction 22 SSH (and SFTP and SCP) Inbound 53 DNS UDP Outbound 67 DHCP UDP 67 Outbound 80 OAM, Web Services and Licensing (disabled by default) Inbound 123 NTP UDP Local Only 162 SNMP Trap/Notification UDP Outbound 389 LDAP Local and Outbound (for authentication and authorization ) 443 OAM, Web Services, and Licensing Inbound 450 TSAPI listener Inbound 1024-1039 TSAPI Session Local TLINKS Local Only 1050-1065 1066-1081 TSAPI Session TLINKS ( 16 is max number of supported switches ) TSAPI Session Encrypted TLINKS ( 16 is max number of supported switches ) Inbound Inbound 3000-4100 H323 Signaling Outbound 4101-4116 System Management Service (SMS) Proxy (aka OSSI Proxy) Local Only 4721 DMCC XML Protocol (disabled by default) Inbound 4722 DMCC Secure XML Protocol Inbound 4723 TR87 TLS (disabled by default) Inbound 2

5000-5300 H323 RTP (DMCC Server-Side Media) UDP Inbound 5430 Database Local Only 5501 TSAPI Tserver Local Only 5502 TSAPI Driver Local Only 5503 DLG Local Only 5504 Transport Local Only 5505 ASAI Link Service Local Only 5678 DLG Listener Inbound 7000-8100 H323 RAS UDP Inbound 8080,8443 Tomcat : OAM, Web Services, Licensing (8080 disabled by default) Inbound 8081,8082 JMX (Management) Local Only 8765 Transport Protocol Outbound 9998 Secure CVLAN Listener Inbound 9999 CVLAN Listener Inbound It should be noted that some of these ports and port ranges are configurable via the OAM Ports web page. On the Bundled Server, changes to the OAM Ports screen will automatically reconfigure the firewall rules. Controlling the Firewall on Bundled Solution The Bundled Server comes pre-packaged and pre-configured with firewall software. AE Services has implemented the firewall using the Red Hat Linux iptables package. The firewall is always on by default. i. Modifying the Firewall In some instances a customer or Avaya technician may want to change the port filtering rules (port or port ranges) on the firewall. It is highly recommended that the OAM Port screen be used to perform all port changes. All port value changes applied by the OAM Port screen will cause the firewall to be automatically reconfigured to support the new rules. Firewall setting modifications for ports not listed on the port screen can be done by using various options available through the Linux iptables command. The iptables command is only available to users with root (sroot) level privileges. 3

Note: By default, the firewall is automatically started when the Bundled Server boots up. The default rules that are implemented by the firewall are in /etc/init.d/iptables. A script /opt/mvap/bin/firewallupdater.sh runs each time the AE Service is started to regenerate the firewall rules based on the current port configuration settings. Any firewall changes made outside of the script will be discarded when the AE Service is restarted. In order to make the firewall changes persistent for ports not on the OAM port screen the firewall configuration script must be modified by the System Administrator to include the additional port values. For each of the below commands, the System Administrator must SSH into the Bundled Server first, and then su to the root (sroot) level account. ii. Listing the rules of the Firewall Use the following command: iptables --list --line-number --numeric This will list all the firewall rules including the Rule Numbers. There are three chains (table) for which rules will be listed. 1. INPUT - for incoming connections/packets 2. OUTPUT - for outgoing connections/packets 3. FORWARD - for forwarding packets from one host to another iii. Starting the Firewall Use the following command: service iptables start iv. Stopping the Firewall Use the following command: service iptables stop v. Restarting the Firewall At any point, if the iptable rules are misconfigured, then restarting the iptables will re-load the default iptable rules. Use the following command: service iptables restart vi. Allowing access to a port in the Firewall (see above Note) Use the following command: iptables modify --add (INPUT OUTPUT FORWARD) (tcp udp) xxxx, where xxxx is the port number to enable 4

For example, iptables modify --add INPUT tcp 5654 vii. Disabling access to a port in the Firewall (see above Note) Use the following command: service iptables modify --reject (INPUT OUTPUT FORWARD) (tcp udp) xxxx, where xxxx is the port number to enable For example, iptables modify --reject INPUT tcp 5660 viii. Removing a port from the Firewall (see above Note) Use the following command: iptables modify --remove (INPUT OUTPUT FORWARD) (tcp udp) xxxx, where xxxx is the port number to be removed For example, iptables modify --remove INPUT tcp 5660 ix. Allowing access to a range of ports in the Firewall (see above Note) Use the following command: iptables modify --add-range (INPUT OUTPUT FORWARD) (tcp udp) xxxx yyyy, where xxxx is the fromport and yyyy is the to-port. For example, iptables modify --add-range INPUT udp 10000 10100 x. Removing a port range from the Firewall (see above Note) Use the following command: iptables modify --remove-range (INPUT OUTPUT FORWARD) (tcp udp) xxxx yyyy, where xxxx is the fromport and yyyy is the to-port. For example, iptables modify --remove-range INPUT udp 10000 10100 2. Monitoring Software a. Software Only Solution It is strongly recommended to install intrusion detection and monitoring software on the AE Services server. There are several such software packages available like Tripwire, SNORT, etc. It is also strongly recommended to configure the Linux bash shell to log all shell command activity to Linux system logs. b. Bundled Solution i. Shell Monitoring 5

AE Services has configured the bash rpm to log all shell command activity to the Linux system logs in /var/log/messages. This includes any command that is typed by a user or invoked by any software within the AE Services server. System Administrators can monitor these logs for unusual system activity. ii. Tripwire AE Services uses the Tripwire software available from Fedora Linux to do system monitoring and intrusion detection. Tripwire allows System Administrators the ability to monitor for possible intrusion into a system. The Tripwire software is installed via a Linux RPM on the Bundle Server. AE Services provides an RPM to configure and start tripwire. After installation of the AE Services software, Tripwire is configured to automatically startup upon reboot. On the first startup, Tripwire builds a database of all files that it is monitoring. Thereafter periodically (once every day at 4.02 a.m.), if Tripwire detects any database changes or security violations when it runs the integrity check, it generates a report located at /var/lib/tripwire/report with any violations that were found. In addition, a SNMP Trap will be issued to each configured SNMP Trap destination. Important: It is strongly recommended to view these daily tripwire reports and clean them up appropriately. Otherwise, over time, these reports will occupy disk space. Note: It is the responsibility of the system administrator to view and delete these reports and SNMP Traps. Once the tripwire reports have been viewed, the tripwire database must be updated in order to prevent the security violation from being raised again. Since Tripwire is installed during the initial install process, a default password is generated and used to configure Tripwire. In order for Tripwire to be updated, Tripwire must be reinstalled by the System Administrator such that a valid user password is provided. This password will be used by the System Administrator to update Tripwire on all future requests. The complete set of instructions for Tripwire configuration is located in the Application Enablement Services Administration and Maintenance Guide Release 4.2, under the section titled Using Tripwire. Items 1-4 of the following command summary must be executed by a user with root (sroot) privileges. 1. Start Tripwire: Use the command: service tripwire start 2. Stop Tripwire: Use the command: service tripwire stop 6

3. Restart Tripwire: Use the command: service tripwire restart 4. View the Tripwire reports: Use the command: twprint m r -- twrfile /var/lib/tripwire/report/<filename>.twr 5. All SNMP Traps are managed from the OAM Alarm Viewer screen. This screen will allow an administrator the ability to view or clear a generated alarm. 3. Network Access a. Software Only Solution It is recommended to disable telnet, ftp, rsync and rsh as these network programs are insecure. Instead we recommend the use of SSH, SFTP and SCP. To disable telnet and the other services listed above use the chkconfig command. b. Bundled Solution The Bundled Server allows only SSH, SFTP and SCP. Telnet, ftp, rsync and rsh have been disabled. 4. Default Logins and RBAC There are 3 classes of Users on AE Services: CTI OAM Administrators User Management Administrators CTI Client Application Users The AE Services OAM web-pages provide access to CTI OAM Administrators which requires login authentication from the Linux platform or an Enterprise Directory (Active Directory, Domino, OpenLDAP, etc ). The Enterprise Directory connection from OAM supports the use of the LDAP-S (Secure LDAP) protocol. The administrator account used to access OAM is the same login that is used to access the AE server using a remote connection with a program like SSH. The OAM web-pages also provide access to User Management Administrators which requires authentication from a secure LDAP database. It is strongly recommended that all logins/passwords to the Linux platform, Web OAM (CTI and User Management) as well as the secure LDAP database (User management) be changed during first login as well as periodically. Avaya will be changing the passwords periodically (every 90 days) for all Avaya logins (craft and sroot). Customers are advised to change passwords for all customer logins. CTI Client Application Users are required by TSAPI, JTAPI, DMCC and Telephony Web Service applications in order to authenticate the application. These users may be authenticated against either the AE Services User Management LDAP database or against an Enterprise Directory. 7

CTI OAM Administrator Accounts CTI OAM Administrator accounts are administered in Linux or an Enterprise Directory. The administrative accounts for OAM access are role based. The appropriate roles are System Administrator, Security Administrator, Auditor, Maintenance, and BackupRestore. For authentication, accounts against the Linux platform are enforced by Linux while the accounts in the Enterprise Directory are enforced by the policies administered on the directory server. The following roles are used by OAM for RBAC. This table presents the RBAC mapping between an Enterprise Directory role and a Linux group. Role Linux Group AE Services OAM access privileges System_Administrator susers Read and write access to all operations in CTI OAM Administration: Administration Status and Control Maintenance Alarms Logs Utilities No access to User Management or Security Administration. Security_Administrator securityadmin Read and write access to Security Administration: Account Management PAM Management Login Reports Login Audit Read and write access to CTI OAM Administration Certificate Management Logs No additional access to CTI OAM Administration or User Management. Administrative role for User Management Not associated with Linux. Read and write access to User Management. No access to CTI OAM Administration or Security Administration. Note: To acquire the Administrative role for User Management, a user must have an administered account in the local LDAP data store with the 8

Avaya role set to userservice.useradmin. Auditor users Read-only access to the following functions in CTI OAM Administration: Administration > Security Database > CTI Users: List All Users and Search Users Certificate Management Status and Control Alarms Logs Backup_Restore backuprestore Read and write access to the following Maintenance functions: Backup Database Restore Database Avaya_Maintenance avayamaint Read and write access to the following CTI OAM Admin functions: Maintenance, Logs Utilities The following Linux accounts exist on the AES server by default. Account Name cust craft sroot Group susers securityadmin susers securityadmin root Default Password Yes Yes Yes Purpose For customer use For Avaya Technician use For Avaya Technician use Password Naming Policy See Password Management Section At least 8 chars, no dictionary words or palindromes. At least 8 chars, no dictionary words or palindromes. Password Change Policy Password should be changed by customer after initial installation and periodically there after. Will be changed periodically (every 90 days) once the system is registered with Avaya Services Will be changed periodically (every 90 days) once the system is registered with Avaya Services 9

rasaccess remote Yes For remote modem access. Only provides access to PPP, still need to use one of the above accounts to access the system. At least 8 chars, no dictionary words or palindromes. None. Note: Direct root login is disabled for both SSH (only on the Bundled Server) and Web OAM. The above platform logins provide specific access to resources on the AE Services server. For example, a root level login will be allowed to restart AE Services on the platform. While from OAM, any login belonging to the group susers can restart AE Services. All logins will have access to the AE Services logs under /var/log/avaya/aes. Note: By default the root account is disabled on the Bundled Server and the sroot account is used by Avaya Services to obtain root level access. Be aware that the root account may be re-enabled by setting the root password.. Passwords for all Linux accounts are stored securely by the Linux platform. User Management Administrator Accounts User Management Administrators are authenticated against a Local LDAP store on the AES server. Account Name Default Password Password Naming Policy craft Yes Controlled by Avaya Services avaya Yes See Password Management Section Password Change Policy None None, should be changed by customer after initial installation and periodically there after User Management uses roles for authorization purposes. User Administrators must have the userservice.useradmin role set. A User Administrator can create other user accounts and then assign them a userservice.useradmin role to create other User Administrators. Passwords are stored MD5 encrypted by the LDAP server backing User Management. 10

CTI Client Application User Accounts The AES services TSAPI, JTAPI, Telephony Web Service and DMCC each authenticate a connecting client application and authorize the control of devices by the client application. The CTI user directly associated with the client application can be authenticated either against the local User Management LDAP (default) or an Enterprise Directory (like Active Directory). Authorization is performed on the AES server using the Secure Database (SDB) feature. The SDB can be optionally enabled or disabled. By default the SDB is disabled. In the disabled state, a user has the ability to control any device registered on AES including devices belonging to another user. In the enabled state, a user must be authorized in the SDB to control a device. The user may be optionally categorized as having Unrestricted Access or Restricted Access. By default a user is granted Restricted Access Note: A user with Unrestricted Access has the ability to control any device registered on AES. In order to add a user into the SDB, the user must be created in User Management as a CTI user. If the SDB is disabled and an Enterprise Directory is used for authentication, a user does not have to be created in User Management. The DMCC service uses a Communication Manager (CM) Station extension and password to register a DMCC device on behalf of the client application. It is strongly recommended that each DMCC device have its own unique password administered in CM for a corresponding extension (station). CM allows up to 8 digit passwords for each extension. A possible configuration exists where a user application may not have to be aware of a device s password for registration. If the SDB is enabled and a user is configured in the SDB for Unrestricted Access, the registration process will succeed when a password is not supplied as long as the extension s class of restriction (COR) on CM has the options Can Be Service Observed: and Can Be A Service Observer: set to yes. This feature is only available on CM 5.1 and higher. Otherwise the user application must be aware of the password for each device for the registration process to succeed. See the chapter titled The Security Database, of the Application Enablement Services Administration and Maintenance Guide Release 4.2 for details on configuration of the various authentication options. The following table outlines the services that perform administration and authorization on the AE Services server. 11

Service Name DMCC (formerly CMAPI) User Type CTI Authentication Yes, against local LDAP or Enterprise Directory TSAPI CTI Yes, against local LDAP or Enterprise Directory JTAPI CTI Yes, against local LDAP or Enterprise Directory Authorization Uses the Security Database (SDB) which specifies which devices a user is allowed to control. The SDB feature is disabled by default. The client must provide the password for each CM extension (device) registered on this connection. Uses the Security Database (SDB) which specifies which devices a user is allowed to control. The SDB feature is disabled by default. Uses security database which specifies which devices a user is allowed to control. The SDB feature is disabled by default. CVLAN CTI No Only accepts connections from an administered set of clients DLG CTI No Only accepts connections from an administered set of clients Telephony Web Services CTI Yes, against local LDAP or Enterprise Directory Uses security database which specifies which devices a user is allowed to control. The SDB feature is disabled by default. User Management Web Services User Admin Yes, against local LDAP or Enterprise Directory Users must have userservice.useradmin roles set to perform User Management Administration. SMS (System Management Web Services) CM User Yes, against CM. Must provide OSSI username and password Internal Unprivileged Linux Accounts For security reasons, services on the AE Services server run as unprivileged Linux users. Since each service execute as an unprivileged user, each service will have access permissions equivalent to that of the unprivileged user. Direct login access to these unprivileged accounts is disabled. Examples of these internal unprivileged accounts 12

include apache (used by Apache web server), tomcat5 (used by Tomcat web server) and avaya (used for AES services like TSAPI, Transport etc ). 5. Linux Password Management Password management is the enforcement of a set of rules or laws that govern the creation and lifecycle of a password. This includes the combination of characters that will be allowed to be composed together to form a password, the life expectancy of a valid password before a new one has to be created, and the lockout period for invalid login attempts among other password usage items. This feature requires role privileges for a Security Administrator. The following table specifies the configurable password rules provided by the OAM interface. Password Rules Default Value Minimum password length. 8 Minimum digits required for password complexity. 1 Minimum upper characters required for password complexity. 1 Minimum lower characters required for password complexity. 1 Minimum special characters required for password complexity. 1 Minimum number of character difference between passwords 2 Number of times a user is prompted for a valid password 3 Max invalid consecutive logins before account is locked 3 Lockout account duration after reaching max invalid logins 60 seconds Max number of days a password maybe used. 60 Minimum number of days between password changes. 1 Number of days warning given before a password expires. 10 Once a user account enters the password expiration warning period, an indication will be provided from the OAM interface listing the number of days left. A Change Password screen will be available from OAM once this message is displayed to allow a user the ability to change their password. A remote SSH connection to the AES server will only inform the user of the number of days left before the account is locked. The user will have to use the Linux command passwd in order to change their password. 6. Account Management and Access Control Using the OAM interface, a Security Administrator has the ability to create, modify, delete, lock or unlock a Linux based user account. In addition, the Security Administrator has the ability to view a login report of all the Linux accounts available on the AE Server 13

or a detailed login report of an individual account. Each individual detailed report will include the users associated Linux groups, RBAC roles, account lock status, shell access privileges, and their password management statistics. The following table represents additional capabilities available using OAM and their default values. Additional Account Mgmt and Access Control Features Default Value Allow user access to the Linux shell Disabled Force password change on first login. No Limit the number of simultaneous logins. 10 Restrict server access based on the time/day of the week. None Enable a login audit process to disable unused Linux accounts. Disabled 7. AE Services Application Links (Bundled and Software Only solution) The AE Services server uses several links to communicate with applications as well as Communication Manager. Link Name DMCC (Formerly CMAPI) TR87 TSAPI/JTAPI CSTA 1 ASN.1 CVLAN DLG H.323 Signaling RTP AEP Secure Transport Link Connection Between Application and AE Services AES and MS LCS or OCS Application and AE Services Application and AE Services Application and AE Services AE Services and Communication Manager AE Services and Communication Manager AE Services and Communication Manager Connection Type Used By DMCC service Encrypted (4.2) Yes by default. TR87 interface Yes TSAPI/JTAPI service CVLAN service DLG service No, UDP DMCC service UDP DMCC service TSAPI, JTAPI, CVLAN, DMCC Call Information Yes based on config Yes based on config Yes based on config Yes based on config Yes 14

OSSI HTTPS AE Services and Communication Manager Web Services Application or Webbrowser and AE Services System Management Service (SMS) Web OAM, System Management Service (SMS), Telephony Service, User Service Yes Yes Important: It is strongly recommended that the applications using Telephony Services, User Service and System Management Services (SMS) use the HTTPS link for maximum security. 8. Session Inactivity Inactivity timeouts are implemented for users logged into a Linux shell via SSH (Bundled Server only) or into the OAM web interface. The following table summarizes the inactivity timeouts for these connections. Service Name Session Inactivity Customizable SSH (shell) Web OAM Yes (default = 30 minutes) Yes (requires root access) Yes (default = 30 minutes) Yes (requires root access) See Appendix A for details on modifying the default timeout values. 9. Audit Trails An audit trail/log is a chronological sequence of records showing who has accessed a computer system and what operations a user performed during a given period of time. Audit trails in AES are recorded in reference to two basic areas, Linux based shell commands and any OAM based changes. AE Services has configured the bash rpm on the Bundled Server to log all shell command activity to the Linux system logs in /var/log/messages. This includes login attempts (success and failure) and any command that is typed by a user or invoked by any software within the AE Services server. This provides an audit trail for all shell activity. Any configuration changes using the OAM interface will be logged including all login attempts into the web interface. The OAM interface is mainly backed by a relational database. As part of the OAM logging process, the logs will contain the login name of the 15

individual making the change, the date/time of the change, the IP address of the connecting system, and a synopsis of the before and after data changes. The following is a summary of the log file locations. Service Name SSH (shell) Web OAM (CTI OAM) Audit Trail Locations /var/log/messages /var/log/avaya/aes/oam-admin Web OAM (User Admin access) /var/log/avaya/aes/tomcat/ws_cus_authentication.log 10. Certificates Certificates are used on the AE Server to provide a secure form of communication with remote hosts using the SSL/TLS protocol. Before the AES 4.2 release, a separate certificate, either one self-signed or signed by a CA, was used by Apache, Tomcat, DMCC and TR87. With the use of the OAM Certificate Management web pages these services are now able to use the same server-side certificate provided by and signed by a customer s CA. The Host Authentication and Authorization (AA) feature available on the AE Server is used to provide an additional layer of validation for connecting remote hosts that want to communicate with the AE Services DMCC or TR87. The Host AA feature is configurable using the OAM web interface. This feature validates the client certificate received by the server against a set of credentials. Two areas of validation exist. The first area of validation, which is focused on authentication, verifies that the certificate received from the client is valid. For instance, the certificates Not Valid Before and Not Valid After Date are checked against the server s current date/time. In addition, the certificate is verified to be signed by a trusted CA. The second area of validation, which is focused on authorization, determines if the Common Name (CN) in the client certificate matches one of the CN s listed on the server as a trusted host. If the client certificate fails the basic certificate validation or if the CN does not match any of the specified trusted hosts, the connection will be refused and a log message will be created. By default this feature is disabled for DMCC. TR87 has the authorization feature disabled and the authentication feature enabled by default. On the client application server, the DMCC Java SDK only has the ability to validate the received AES server certificate is signed by a trusted CA and the certificates Not Valid Before and Not Valid After Date is valid. The ability to verify a certificate s CN against a trusted host list is not provided by the SDK. The client side validation feature is controlled with the use of a SDK property. By default this feature is displayed. 16

11. JAR File Security AE Services digitally signs each of the jar files provided by the AES platform. Digitally signed jars provide a way to protect jar files from tampering which include modification or deletion of existing files in the jar or the addition of new files after the jar has been created. If this remained unchecked the ability for someone to rewrite or remove a file as a way to circumvent a security feature or obtain sensitive data remained plausible. For example, if someone is able to replace a piece of code that handles incoming digits, the user will be able to rewrite and replace the existing file to capture all the entered digits and send them off to another server or email address for retrieval. When a jar file security violation is detected, AE Services will not start and a security violation message will be logged. In addition, the OAM CTI Administration main page will list the name of each jar file which failed validation. 12. Warning Banners a. PAM Issue Before a user logs into the AES server using a SSH connection or the web OAM interface they are presented with a legal warning banner (disclaimer). The issue banner may be disabled or modified by an administrator using the OAM interface with a login role of a Security Administrator. The issue banner is enabled by default and a default message is displayed. b. PAM MOTD (Message of the Day) After a user logs into the AES server using a SSH connection or the web OAM interface they are presented with an MOTD message banner. The MOTD banner may be disabled or modified by an administrator using the OAM interface with a login role of a Security Administrator. The MOTD banner is disabled by default. Service Name Banner Customizable via OAM SSH (shell) Yes Yes Web OAM Yes Yes 13. Linux Installation and Software a. Software Only Solution AE Services 4.2 requires RedHat Linux ES 4.6 operating system. We recommend that a minimum installation of RedHat Linux be performed. This will ensure 17

only the minimal required software RPMS are installed which will greatly lessen security risks. See the Application Enablement Services Installation and Upgrade Guide for a Software-Only Offer Release 4.2 for further details. b. Bundled Solution The Bundled Server comes pre-packaged with RedHat Linux ES 4.6 along with AE Services software. The Bundled Server has only the minimum Linux software RPMs that are required for the proper functioning of the OS. This also means that only those Linux services that are absolutely needed by AE Services have been enabled on the box. This way only those ingress software ports have been enabled that are really needed. This reduces the security risk significantly. See the Application Enablement Services Installation and Upgrade Guide for a Bundled Server Release 4.2 for further details. 14. Vulnerability Tracking (Bundled and Software Only solution) Avaya has an active organization which tracks security advisories and susceptibility of Avaya products to vulnerabilities described in those advisories. This organization coordinates these advisories issued by vendors who supply operating systems or software components to Avaya. To sign up for advisory notification, please go to http://support.avaya.com and Select "My e-notifications". For more detail on Avaya tracking policies and practices, please see: Avaya's Product Security Vulnerability Response Policy http://support.avaya.com/elmodocs2/security/security_vulnerability_response.pdf Avaya's Security Vulnerability Classification Policy http://support.avaya.com/elmodocs2/security/security_vulnerability_classification.pdf 18

APPENDICES These following appendices outline some potential options for configuration changes that may help make the AE Services Bundled Server more secure. This configuration changes require root access and would typically need to be performed by Avaya Services technician running as sroot. 1. Configuration options for changing inactivity timeouts for shell and OA&M access APPENDIX A Inactivity timeouts Both Shell and OA&M access provide default 30 minute inactivity timeouts. Sometimes customers may have requirements for lower timeouts. The following shows how these inactivity timeouts can be modified. 1) To modify the OA&M inactivity timeout, do the following: a. cd $CATALINA_HOME/webapps/MVAP/WEB-INF b. edit web.xml c. Modify the session-timeout element (this value is in minutes). The default entry (30 minutes) looks like. <session-timeout>30</session-timeout> d. Restart tomcat for the change to take effect 2) To modify the bash shell inactivity timeout, do the following: a. cd /etc/profile.d b. Edit mvap.sh c. Change TMOUT value. This value is seconds. The default entry looks like export TMOUT=1800 to change to 15 minutes for instance do the following: export TMOUT=900 d. Changes will take effect for all subsequent shell logins 19