firewall aes

AE Services 3.1.x Security Whitepaper Document Rev: 2.0.4 Date: 09/08/2006

1

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. Firewall 2. Monitoring Software (Shell and Intrusion Detection software) 3. Network Access 4. Logins, Passwords, Authentication and Authorization 5. AE Services Link 6. Inactivity timeouts and Audit trails 7. 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.


2

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 Used For Protocol Direction 4721 DMCC XML Protocol TCP Inbound 4722 DMCC Secure XML Protocol TCP Inbound 8081, 8082 JMX (Management) TCP Local Only

5000-5300 Media UDP Inbound 3000-4100 H323 Signaling TCP Outbound 7000-8100 H323 RAS UDP Inbound 450 TSAPI listener TCP Inbound

1050-1065 TSAPI session, need X where X is number of switches TCP Inbound

5501 TSAPI Tserver OA&M port TCP Local Only 5502 TSAPI Driver OA&M port TCP Local Only 9999 CVLAN listener TCP Inbound 5678 DLG TCP Inbound 5503 DLG OA&M port TCP Local Only 5504 Transport OA&M port TCP Local Only 5505 ASAI Link Service OA&M port TCP Local Only 4001 OSSI proxy TCP Local Only 5430 Database TCP Local Only 8765 Transport protocol TCP Outbound 8080 Licensing TCP Inbound 8080,8443 Tomcat : Admin Web Pages, Web Services TCP Inbound 80, 443 SMS TCP Inbound 161, 162 SNMP Trap/Notification Ports UDP Outbound

389 LDAP TCP

Local Only Outbound (for remote authentication against enterprise)


3

22 SSH (and SFTP and SCP) TCP Inbound

67, 68 DHCP TCP 67 Outbound, 68 Inbound

53 DNS TCP Outbound 123 NTP TCP 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


4

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 from-port 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-


5

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


6

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


7

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 Group

Default Password Purpose

Password Naming Policy

Password Change Policy

cust

avaya Yes For customer use

At least 6 chars, no dictionary words or palindromes.

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.

craft

avaya Yes For Avaya Technician use


Will be changed periodically (every 90 days) once the system is registered with Avaya Services

sroot

root Yes For Root access


Will be changed periodically (every 90 days) once the system is registered with Avaya Services

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.


None.

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.


8

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 Default

Password Password Naming Policy

Password Change Policy

avaya Yes 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 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 User

Type Authentication Authorization

DMCC (formerly CMAPI)

CTI Yes, against local LDAP or Enterprise

No explicit authorization however the client must provide the password for each CM extension registered on this connection


9

TSAPI CTI Yes, against local LDAP or Enterprise

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.

JTAPI CTI Yes, against local LDAP or enterprise

Uses security database which specifies which devices a user is allowed to control.

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

Uses security database which specifies which devices a user is allowed to control.

User Management Web Services

User Admin

Yes, against local LDAP or Enterprise LDAP

Users must have userservice.useradmin roles set to perform User Management Administration.

System Web Services

CM User Yes, against CM. Must provide OSSI username and password

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.


10

Link Name Connection Between

Connection Type Used By Encrypted

(3.1) DMCC (Formerly CMAPI)

Application and AE Services TCP DMCC service Yes by

default.

TSAPI/JTAPI CSTA 1 ASN.1

Application and AE Services TCP TSAPI/JTAPI

service

No, but password is encrypted when sent across the link

CVLAN Application and AE Services TCP CVLAN service No

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, TSAPI, CVLAN, DMCC Call Information

Yes

OSSI AE Services and Communication Manager

TCP System Management Service (SMS)

No

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 use the HTTPS link for maximum security.

7. Session Inactivity, Audit Trails and Account Lockouts


11

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 SSH (shell) Yes (default = 30 minutes) Yes (requires root access) Web OA&M Yes (default = 30 minutes) Yes (requires root access) 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 Audit Trail SSH (shell) Yes, in /var/log/messages Web OA&M (CTI OA&M) No (planned for future release)

Web OA&M (User admin) 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 Banner Customizable SSH (shell) Yes Yes (requires root access) Web OA&M Yes (in release 3.1.2 or later) Yes (requires root access)

9. Linux Installation and Software a. Software Solution


12

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


13

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


14

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 Service’s 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 required /lib/security/$ISA/pam_env.so

auth required /lib/security/$ISA/pam_tally.so onerr=fail no_magic_root auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok auth required /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 required /lib/security/$ISA/pam_limits.so session required /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”. It’s 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 can’t 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 can’t be reused.


15

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.

firewall aes

Documents

retry 3 minlen 6 dcredit

daily tripwire reports

web oa

perform account lockouts

cti oa

forcing periodic password

restart ae services

ae services server