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 (TCP/UDP) connections/packets only. All
OUTGOING (TCP/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) TCP Inbound
53 DNS UDP Outbound
67 DHCP UDP 67 Outbound
80 OAM , Web Services and Licensing
(disabled by default) TCP
Inbound
123 NTP UDP Local Only
162 SNMP Trap/Notification UDP Outbound
389 LDAP TCP Local and Outbound (for authentication and authorization ) 443 OAM , Web Services, and Licensing TCP Inbound
450 TSAPI listener TCP Inbound
1024-1039 TSAPI Session Local TLINKS TCP Local Only 1050-1065 TSAPI Session TLINKS ( 16 is max number
of supported switches ) TCP
Inbound
1066-1081 TSAPI Session Encrypted TLINKS ( 16 is
max number of supported switches ) TCP
Inbound
3000-4100 H323 Signaling TCP Outbound
4101-4116 System Management Service (SMS) Proxy
(aka OSSI Proxy) TCP
Local Only 4721 DMCC XML Protocol (disabled by default) TCP Inbound
4722 DMCC Secure XML Protocol TCP Inbound
5000-5300 H323 RTP (DMCC Server-Side Media) UDP Inbound
5430 Database TCP Local Only
5501 TSAPI Tserver TCP Local Only
5502 TSAPI Driver TCP Local Only
5503 DLG TCP Local Only
5504 Transport TCP Local Only
5505 ASAI Link Service TCP Local Only
5678 DLG Listener TCP Inbound
7000-8100 H323 RAS UDP Inbound
8080,8443 Tomcat : OAM, Web Services, Licensing
(8080 disabled by default) TCP
Inbound
8081,8082 JMX (Management) TCP Local Only
8765 Transport Protocol TCP Outbound
9998 Secure CVLAN Listener TCP Inbound
9999 CVLAN Listener TCP 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.
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
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 from-port and yyyy is the to-from-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 from-port and yyyy is the to-from-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
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
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.
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
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 Group Default Password Purpose Password Naming Policy Password Change Policy cust susers
securityadmin Yes For customer use
See Password Management Section Password should be changed by customer after initial installation and periodically there after. craft susers securityadmin Yes For Avaya Technician use At least 8 chars, no dictionary words or palindromes. Will be changed periodically (every 90 days) once the system is registered with Avaya Services sroot
root Yes For Avaya
Technician use At least 8 chars, no dictionary words or palindromes. Will be changed periodically (every 90 days) once the system is registered with Avaya Services
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
Password Change Policy
craft Yes Controlled by
Avaya Services
None
avaya Yes See Password
Management Section
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.
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.
Service Name User Type Authentication Authorization DMCC (formerly CMAPI)
CTI Yes, against local LDAP or Enterprise Directory
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.
TSAPI CTI Yes, against
local LDAP or Enterprise Directory
Uses the Security Database (SDB) which specifies which devices a user is allowed to control. The SDB feature is disabled by default.
JTAPI 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.
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
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
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 Connection Between Connection Type Used By Encrypted (4.2) DMCC (Formerly CMAPI) Application and AE Services TCP DMCC service Yes by default. TR87 AES and MS LCS or
OCS TCP TR87 interface Yes
TSAPI/JTAPI CSTA 1 ASN.1 Application and AE Services TCP TSAPI/JTAPI service Yes based on config CVLAN Application and AE
Services TCP CVLAN service
Yes based on config DLG Application and AE Services TCP DLG service No H.323 Signaling AE Services and Communication Manager
TCP, UDP DMCC service Yes based on config
RTP
AE Services and Communication Manager
UDP DMCC service Yes based on config AEP Secure Transport Link AE Services and Communication Manager TCP TSAPI, JTAPI, CVLAN, DMCC Call Information Yes
OSSI AE Services and Communication Manager TCP System Management Service (SMS) Yes HTTPS Web Services Application or Web-browser and AE Services TCP Web OAM, System Management Service (SMS), Telephony Service, User Service 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) Yes (default = 30 minutes) Yes (requires root access) Web OAM 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
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 Audit Trail Locations
SSH (shell) /var/log/messages
Web OAM (CTI OAM) /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.
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 IssueBefore 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 SolutionAE 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
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
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
