AE Services 3.1.

x Security Whitepaper

Document Rev: 2.0.4

Date: 09/08/2006

White-paper on Security in Application Enablement Services for Bundled and Software only solutions
Document Rev: 2.0.4 Date 09/08/2006

1. Introduction
The AE Services 3.1 Bundled Offer comes pre-packaged with several security features and packages. For the Software Only solution, the customer is primarily responsible for providing security for the server. This document provides security guidelines for both Bundled and Software only solution customers. In general the areas covered include: 1. 2. 3. 4. 5. 6. 7. Firewall Monitoring Software (Shell and Intrusion Detection software) Network Access Logins, Passwords, Authentication and Authorization AE Services Link Inactivity timeouts and Audit trails Warning Banners

2. Firewall
Firewall software provides protection to a server from the network. RedHat Linux 3.0 comes with firewall software called iptables. It controls the network packet filtering code in the Linux kernel. The Bundled solution 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 Bundled systems 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 both NICs of the Bundled system. For the Software only solution, we strongly recommend turning on the firewall software on the AE Services server. The firewall software should be configured to use only those ports that are absolutely required.

AE Services 3.1.x Security Whitepaper

Document Rev: 2.0.4

Date: 09/08/2006

AE Services uses the following ports by default (for 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 4721 4722 8081, 8082 5000-5300 3000-4100 7000-8100 450 Used For DMCC XML Protocol DMCC Secure XML Protocol JMX (Management) Protocol TCP TCP TCP UDP TCP UDP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP UDP Direction Inbound Inbound Local Only Inbound Outbound Inbound Inbound Inbound Local Only Local Only Inbound Inbound Local Only Local Only Local Only Local Only Local Only Outbound Inbound Inbound Inbound Outbound Local Only Outbound (for remote authentication against enterprise)

Media H323 Signaling H323 RAS TSAPI listener TSAPI session, need X where X is number of 1050-1065 switches 5501 TSAPI Tserver OA&M port 5502 TSAPI Driver OA&M port 9999 CVLAN listener 5678 DLG 5503 DLG OA&M port 5504 Transport OA&M port 5505 ASAI Link Service OA&M port 4001 OSSI proxy 5430 Database 8765 Transport protocol 8080 Licensing 8080,8443 Tomcat : Admin Web Pages, Web Services 80, 443 SMS 161, 162 SNMP Trap/Notification Ports

389

LDAP

TCP

AE Services 3.1.x Security Whitepaper 22 67, 68 53 123 SSH (and SFTP and SCP) DHCP DNS NTP

Document Rev: 2.0.4 TCP TCP TCP TCP

Date: 09/08/2006 Inbound 67 Outbound, 68 Inbound Outbound Outbound

It should be noted that some of these ports and port ranges are configurable via the OA&M web page. If changes are made to the port configuration, the firewall rules need to be updated accordingly. Controlling the Firewall on Bundled Solution The Bundled solution 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 would want to change the port filtering (port or port ranges) on the Firewall. This can be done by using various options available through the iptables command. By default, the firewall is automatically started when the Bundled system 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 Services are started to regenerate the firewall rules based on the current port configuration settings. For all commands below, SSH into the Bundled server first. 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

AE Services 3.1.x Security Whitepaper

Document Rev: 2.0.4

Date: 09/08/2006

To start the firewall: 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 messed up, 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 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 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 Use the following command: iptables modify --remove (INPUT | OUTPUT | FORWARD) (tcp|udp) xxxx , where xxxx is the port number to remove for e.g. iptables modify --remove INPUT tcp 5660 ix. Allowing access to a range of ports in the Firewall 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 Use the following command: iptables modify --remove-range (INPUT | OUTPUT | FORWARD) (tcp|udp) xxxx yyyy , where xxxx is the from-

AE Services 3.1.x Security Whitepaper

Document Rev: 2.0.4

Date: 09/08/2006

port and yyyy is the to-port. for e.g. iptables modify --remove-range INPUT udp 10000 10100

3. 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 AE Services has configured the bash rpm to log all shell command activity to 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 to monitor for possible intrusion into a system. The Tripwire software is installed via a Linux RPM on the server. AE Services provides an rpm (mvap-security) 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.), an e-mail is sent to root (sroot login on the bundled server) with any violations that were found. It is the responsibility of the system administrator to view and delete these e-mails. If the administrator wants to reset the tripwire database, then they can use the restart command. 1. To Stop Tripwire: Login as root (sroot). Use the command: service tripwire stop 2. To Restart Tripwire: Login as root (sroot). Use the command: service tripwire restart 3. To Start Tripwire: Login as root (sroot). Use the command: service tripwire start 4. To view Tripwire reports: In order to view the daily tripwire reports, login as root (sroot). All e-mails are delivered in /var/spool/mail/sroot. You can use the Linux "mail" program to view the e-mails. Simply type the command: mail. You will be

AE Services 3.1.x Security Whitepaper

Document Rev: 2.0.4

Date: 09/08/2006

taken to an interactive menu. Type help to know about the list of available commands. Saved e-mails are stored in ~/mbox. You can also view the e-mails by using the vi editor. For e.g. vi ~/mbox or vi /var/spool/mail/sroot. 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.

4. 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 AE Services Bundled solution allows only SSH, SFTP and SCP. Telnet, ftp, rsync and rsh have been disabled on the AE Services server.

5. Logins and Passwords

There are 3 classes of Users on AE Services: CTI OA&M Administrators User Management Administrators CTI Client Application Users The AE Services OAM web-pages provide access to CTI OA&M Administrators which requires login authentication from the Linux platform. This is the same login that is used to access the server using 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 (See Appendix A for recommendations on configuring Linux to provide stronger password management capabilities for Linux accounts). CTI Client Application Users are required by TSAPI, JTAPI and DMCC applications in order to authenticate the application. These users may be authenticated against either the AE Services User Management LDAP database or against the Enterprise directory. CTI O&M Administrator Accounts

AE Services 3.1.x Security Whitepaper

Document Rev: 2.0.4

Date: 09/08/2006

CTI OA&M Administrator accounts are administered in Linux. Authentication is against the Linux platform and thus account policies are enforced by Linux. Account Name cust Default Password Password Naming Policy At least 6 chars, no dictionary words or palindromes. Password Change Policy

Group

Purpose

avaya

Yes

For customer use

craft avaya Yes For Avaya Technician use

sroot root Yes For Root access

rasaccess avaya Yes

For remote modem access. Only provides access to PPP, still need to use one of the above accounts to access the system.

By default, password changes are not required. Password should be changed by customer after initial installation and periodically there after. See Appendix A for recommendations on configuring linux to enforce a password change policy for cust account. At least 6 Will be changed chars, no periodically (every 90 dictionary days) once the system is words or registered with Avaya palindromes. Services At least 6 Will be changed chars, no periodically (every 90 dictionary days) once the system is words or registered with Avaya palindromes. Services At least 6 None. chars, no dictionary words or palindromes.

Note: Direct root login is disabled both via SSH or Web OAM. The above platform logins provide specific access to resources on the AE Services server. A root level login will be allowed to restart AE Services on the platform. All logins belonging to group avaya can restart AE Services using the "sudo" command. From the Web OAM, any login belonging to the group avaya can restart AE Services. All logins will have access to the AE Services logs under /opt/mvap/logs.

AE Services 3.1.x Security Whitepaper

Document Rev: 2.0.4

Date: 09/08/2006

By default the root account is disabled on the bundled service and the sroot account is used by Avaya Services to obtain root level access. Be aware that the root account may be re-enabled for integration and support purposes after the product is configured. Passwords 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 avaya Default Password Yes Password Naming Policy none Password Change Policy None, should be changed by customer after initial installation and periodically there after

User Management uses roles for authorization purposes. User Administrators must have 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. CTI Client Application User Accounts Certain AE Services authenticate the connecting client application. This includes TSAPI, JTAPI, Telephony Web Service and DMCC. These users can be authenticated either against the local User Management LDAP (default) or an Enterprise Directory (like Active Directory). See Chapter 5, Alternative AE Services Authentication Methods of the Avaya MultiVantage Application Enablement Services Administration and Maintenance Guide Release 3.1.1 for details on configuration of the various authentication options. The following table outlines the services that perform administration and authorization or the AE Services Server. Service Name DMCC (formerly CMAPI) User Type CTI Authentication Yes, against local LDAP or Enterprise Authorization No explicit authorization however the client must provide the password for each CM extension registered on this connection

AE Services 3.1.x Security Whitepaper TSAPI CTI Yes, against local LDAP or Enterprise Yes, against local LDAP or enterprise No No

Document Rev: 2.0.4

Date: 09/08/2006

JTAPI

CTI

CVLAN DLG Telephony Web Services User Management Web Services System Web Services

CTI CTI CTI

Yes, against local LDAP or enterprise User Yes, against Admin local LDAP or Enterprise LDAP CM User Yes, against CM. Must provide OSSI username and password

Uses security database which specifies which devices a user is allowed to control. If user is not administered in SDB, then no access is provided. Uses security database which specifies which devices a user is allowed to control. Only accepts connections from an administered set of clients Only accepts connections from an administered set of clients Uses security database which specifies which devices a user is allowed to control. Users must have userservice.useradmin roles set to perform User Management Administration.

The DMCC service uses Communication Manager Station extension and password to login DMCC extensions on behalf on the application. It is strongly recommended that each DMCC extension have its own unique password in Communication Manager. Communication Manager allows up to 8 digit passwords. Internal Unprivileged Linux Accounts For security reasons, services on the AE Services server run as unprivileged linux users. Direct access to these unprivileged accounts is disabled, however the services run as the unprivileged user and thus only have access to what the unprivileged user has permissions for. 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).

6. AE Services Links (Bundled and Software Only solution)

The AE Services server uses several links to communicate with Applications as well as Communication Manager. In the 3.1 release some of these links are not encrypted. Because of this, we recommend that traffic on these links is not exposed outside of a well protected VLAN. In future, these links will be encrypted for secure communication.

AE Services 3.1.x Security Whitepaper

Document Rev: 2.0.4

Date: 09/08/2006

Link Name DMCC (Formerly CMAPI)

Connection Between

Connection Used By Type DMCC service

Encrypted (3.1) Yes by default. No, but password is encrypted when sent across the link

Application and AE TCP Services

TSAPI/JTAPI CSTA 1 ASN.1

Application and AE TCP Services

TSAPI/JTAPI service

CVLAN DLG H.323 Signaling

RTP

Application and AE Services Application and AE Services AE Services and Communication Manager AE Services and Communication Manager AE Services and Communication Manager AE Services and Communication Manager

TCP TCP

CVLAN service No DLG service No Yes based on config Yes based on config

TCP, UDP DMCC service

UDP

DMCC service

AEP Secure Transport Link

TCP

OSSI

TCP

HTTPS

Web Services Application or WebTCP browser and AE Services

TSAPI, JTAPI, TSAPI, CVLAN, Yes DMCC Call Information System Management No Service (SMS) Web OAM, System Management Service (SMS), Yes Telephony Service, User Service

Important: It is strongly recommended that the applications using Telephony Services, User Service and System Management Services use the HTTPS link for maximum security.

7. Session Inactivity, Audit Trails and Account Lockouts

10

AE Services 3.1.x Security Whitepaper

Document Rev: 2.0.4

Date: 09/08/2006

Inactivity timeouts are implemented for users logged into a Linux shell via SSH or into the OA&M web page. The following table summarizes the inactivity timeouts for these connections. Service Name Session Inactivity Customizable Yes (default = 30 minutes) Yes (requires root access) SSH (shell) Yes (default = 30 minutes) Yes (requires root access) Web OA&M See Appendix B for details on modifying the default timeout values. AE Services has configured the bash rpm on the bundled server to log all shell command activity to 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. Service Name SSH (shell) Web OA&M (CTI OA&M) Web OA&M (User admin) Audit Trail Yes, in /var/log/messages No (planned for future release) Partial, cus logs in /opt/mvap/logs/tomcat contain partial information

Currently the services do not perform account lockouts in the event of consecutive failed login attempts. Appendix A provides details on configuring Linux to perform account lockouts for Linux accounts (CTI OA&M administration accounts) after a certain number of successive failures.

8. Warning Banners
Administrators logging into SSH and Web OA&M are provided with legal warning banners (disclaimers). The banners may be modified by an Administrator with root level access. Service Name SSH (shell) Web OA&M Banner Yes Yes (in release 3.1.2 or later) Customizable Yes (requires root access) Yes (requires root access)

9. Linux Installation and Software

a. Software Solution

11

AE Services 3.1.x Security Whitepaper

Document Rev: 2.0.4

Date: 09/08/2006

AE Services 3.1.x requires RedHat Linux ES 3.0 operating system. We recommend that a minimum installation be performed while installing Linux. This will ensure only the minimum software rpms for Linux are installed which will greatly lessen security risks. b. Bundled Solution The Bundled solution comes pre-packaged with RedHat Linux ES 3.0 along with AE Services software. The Bundled solution 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 ingres software ports have been enabled that are really needed. This reduces the security risk significantly.

10. 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

12

AE Services 3.1.x Security Whitepaper

Document Rev: 2.0.4

Date: 09/08/2006

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 needs to be performed by Avaya Services technician running as sroot. There are 3 areas that are covered: 1. Linux PAM configuration for enhanced password management 2. Configuration options for changing inactivity timeouts for shell and OA&M access 3. Customizing SSH and OA&M warning banners

APPENDIX A Linux PAM Configuration

This section provides details on how linux may be configured to ensure stronger password policies for customer accounts on the Bundled solution. It should be noted that the recommendations for forcing password changes on 1st login, forcing periodic password changes and locking out accounts after certain periods of inactivity should not be applied to the Avaya Services accounts (craft and sroot) since Avaya Services already implement a policy for these accounts. In addition, internal unprivileged accounts (like apache, tomcat5 etc) which are not directly logged into, should not have policies set for them. 1) Forcing a password change for cust account on 1st login (via SSH). In order to do this issue the following command (as sroot) chage d 0 cust Note: If the user logs in via the OA&M web page, they will not be prompted to change their password, rather authentication will fail. Therefore, the user must first login via SSH to set their password. 2) Forcing periodic password changes on account cust. For instance to force a password change every 60 days do the following: chage M 60 cust By default the user will see warnings 7 days prior to their password expiring. The warnings are seen when logging in via SSH. No warnings are displayed on OA&M login screens 3) To lockout an account after a period of inactivity (after their password has expired). For instance to lockout cust account if there are 14 days of inactivity after the password expired: chage I 14 cust 4) To provide more precise password naming rules, the /etc/pam.d/system-auth files needs to be updated. For instance to ensure the minimum password policy meets a 1

13

AE Services 3.1.x Security Whitepaper

Document Rev: 2.0.4

Date: 09/08/2006

digit, 1 lowercase character, minimum length of 6 chars, modify the cracklib line as follows: password required /lib/security/$ISA/pam_cracklib.so retry=3 minlen=6 dcredit=-1 lcredit=-1 It should noted stricter policies other than this one should not be enforced otherwise it might cause passwords generated by the Avaya Services Password Change System (for craft and sroot) to fail.
5)

To lock out an account after a certain number of failed login attempts. Again this requires modification to the /etc/pam.d/system-auth file. Add the following (highlighted lines) to the system-auth file.|
auth auth auth auth required required sufficient required /lib/security/$ISA/pam_env.so /lib/security/$ISA/pam_tally.so onerr=fail no_magic_root /lib/security/$ISA/pam_unix.so likeauth nullok /lib/security/$ISA/pam_deny.so

account required /lib/security/$ISA/pam_unix.so account required /lib/security/$ISA/pam_tally.so per_user deny=5 no_magic_root reset password required /lib/security/$ISA/pam_cracklib.so retry=3 minlen=6 dcredit=-1 lcredit=-1 password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow password required /lib/security/$ISA/pam_deny.so session session required required /lib/security/$ISA/pam_limits.so /lib/security/$ISA/pam_unix.so

This will cause an account to be locked out after 5 consecutive failed login attempts. To check for locked out accounts run faillog. Its possible we want to have certain accounts that are not locked out (like craft and sroot for instance). To do this use the following: faillog u craft M -1 faillog u sroot M -1 6) Remembering password history. To allow the system to remember password history (so that passwords cant be re-used), you must again edit the /etc/pam.d/system-auth file. Edit the password line for pam_unix and add the remember attribute.
password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow remember=10 NOTE: If the /etc/security/opasswd doesn't exist, create the file. # ls -l /etc/security/opasswd -rw------- 1 root root 0 Dec 8 06:54 /etc/security/opasswd

The above example, the system will remember the last 10 passwords for each user, so they cant be reused.

14

AE Services 3.1.x Security Whitepaper

Document Rev: 2.0.4

Date: 09/08/2006

APPENDIX B 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

APPENDIX C Warning banners / Disclaimers

User logging in via the SSH are presented with a warning banner, basically legal disclaimers about illegal use of the system. Web users (in release 3.1.2) will also be presented with a warning banner. Customers may have requirements to modify these banners with specific legal text. This section outlines how each banner may be modified. 3) To modify the OA&M disclaimer banner, do the following: a. Edit or replace "$CATALINA_HOME/webapps/ROOT/disclaimer.html". 4) To modify the SSH disclaimer banner, do the following: a. Edit or replace /etc/banner.

15