CCI through Firewall TNG 2.4 Updated April 16, 2002

Objectives  CCI Considerations for deployment in DMZ or Internet environment – Review different deployment options – Review potential Risks, primarily Denial of Service (DOS) attacks

DoS  Any software deployed in DMZ requires protection against malicious access or denial of service attacks. This requires review of security solutions to prevent these attacks which is out of scope of this presentation

Agenda  CCI Introduction  CCI Layers  DoS  Different Deployment Options

The need for CCI  Applications such as Workload, Tape, Security need to communicate with one another across various servers and platforms.

The need for CCI  Inter-Process Communications (IPC) unique to each platform.  Network programming issues centralized.  Need for a standard method to allow applications to communicate with one another.

The need for CCI  Allows applications on various platforms to communicate with applications on any other using the mechanism of CCI.

CCI is available on...  UNIX  NT  AS/400  OpenVMS  Tandem  OS/390

What CCI does….  Allows applications to communicate with one another without considering IPC / network programming issues.  Presents set of APIs that allow programmers to focus on what an application needs to do and forget about IPC / network programming issues.

And what CCI does not do….  Replace TCP/IP  Retrieve information from application databases  Replace FTP for file transfer  Perform security validation at login time  Manipulate the data

CCI Layers  QUES Layer introduced the ability to connect at send time.  RMT Layer connects at CCI start up time. – RMT has auto-connect capability – Auto-connect capability can be disabled with configuration setting

QUES Layer  Eliminates need for configuration files  New hosts may be brought into configuration with less effort  Removal of host from configuration does not affect other hosts  Connections between hosts are short lived  Bi-Directional CCI Initialization

QUES Layer  Requires 7001 port to be unblocked bi- directional  CCI Initialization from DMZ and Private Network  Potential risk for Denial of Service Attacks – Syn Flooding – Etc  Port must be unblocked for the designated TNG servers and not for all hosts  No predefined source port

QUES Layer  Transport mechanism – Connects with SYN Flag – Send Data – Disconnect – No persistent connection

RMT Layer  Persistent Connection – Connection established at start up and remains open for duration of CCI – Preferred option in Firewall deployment  Configuration Issues – Alias – defaults to first 8 characters of hostname  New hosts may be brought in with Auto Connect Feature if no alias conflict

RMT Layer  RMT connectivity – NT – Unix – Unix – NT – OS/390 – Unix – OS/390 RMT supported for Event and Workload discipline in NT –NT Environment. This support is only for Firewall Deployments and may come with some performance penalties

RMT Layer  Port Usage – Source Port can be configured by environment settings – Destination port defaults to 1721 but can be configured

Syn Three-way Handshaking DMZPrivateDMZPrivateDMZPrivate SYN SYN/ ACK ACK

How SYN Flooding Works  A TCP connection request (SYN) is sent to the target computer. The source IP address in the packet can be "spoofed," or replaced with an address that is not in use on the Internet, or that belongs to another computer. An attacker may send many of these TCP SYNs to tie up as many resources as possible on the target computer to exhaust the resources  Upon receiving the connection request, the target computer allocates resources to handle and track the new connection, then responds with a "SYN-ACK". In this case, the response is sent to the "spoofed" non- existent IP address.  No response is received to the SYN-ACK. A default-configured Windows NT 4.0 computer will retransmit the SYN-ACK 5 times, doubling the time-out value after each retransmission. The initial time-out value is three seconds, so retries are attempted at 3, 6, 12, 24, and 48 seconds. After the last retransmission, 96 seconds are allowed to pass before the computer gives up on receiving a response, and deallocates the resources that were set aside earlier for the connection. This can be configured using registry changes BLOCK 7001 port except for designated TNG servers

Firewall SYN Flood  Review Firewall solution to prevent Syn Flood attacks or DoS  Ensure, 7001 is only unblocked for the two TNG servers which requires CCI Connectivity  Review O/S Hot Fixes for DoS attacks

CCI Ports – NT  Transporter – Quenetd – TCP destination port 7001 for NT to NT communication – CCI will attempt TCP connection first – If fails, will attempt RPC connection – If RPC fails, will then attempt, RMT daemon on 1721

CCI  Transporter Service - QUES Layer – TCP 7001 – Change Transport Protocols settings to TCP to avoid attempts to open 7003 or 7004 – Transport Protocol defaults to ALL

CCI Connection Attempts Transport Protocols set to ALL – > > 1721

Testing Environment

 CA Etrust Firewall  TNG 2.4  No additional TNG fixes

Deployment Options

Client would like to forward Event exception Messages from DMZ but not willing to install SQL server in DMZ environment ? Deployment - Scenario 1

 Install Event Agent  Set Event Agent Proxy Node to TNG server inside the firewall  Open up 7001 port in both directions  Set Transport Protocol configuration setting to TCP

DMZ Event DSB  Event Agent Proxy Node – Specify the node name of Central Server Event Manager – DSB refreshed from Central Server

DMZ Event DSB  If proxy node not required, then local dsb can be pushed to DMZ by other means

Common Services DSM EVT NT -> NT TCP 7001 FIREWALL CORE 7001 Unblocked both directions – CCI may be initiated from DMZ DSM wvdbt Common Services EVT OPRDB CORE DMZ Private Network TRANSPORT PROTOCOLS = TCP TCP 7001

Client would like Event Messages from DMZ but not willing to unblock CCI 7001 for Inbound traffic. Thus stop CCI Initialization to take place from DMZ. Deployment - Scenario 2

 Install Event Management in DMZ  Block 7001 for inbound and outbound traffic  Unblock Agent Technology port 7774  For exception messages to be forwarded to TNG server inside the firewall, generate a trap and forward it local DSM

Deployment - Scenario 2  Update local DSM policy to listen for user generated Event Traps  From the local dsm policy write trap messages to remote host  Update %AGENTWORKS_DIR%\services\config \aws_nsm\aws_nsm.cfg – Set wtotargethost and wtotargetaddress

DSM Remote Host

Common Services DSM EVT Deployment Scenario 2 NT -> NT CATRAP FIREWALL CORE CCI Connectivity not required through firewall DSM wvdbt Common Services EVT OPRDB CORE DMZ Private Network TCP 7774

Client would prefer persistent connection and wish to open CCI port just for outbound traffic ? Thus prevents CCI Initialization to take place from DMZ Deployment - Scenario 3

 RMT daemon provides persistent connection  Customize ccirmtd.rc and ccirmtd.prf to start up connection from private network  Add the NT servers to RMTHOSTNAME entries

NT – NT Remote RMTHOSTS Add NT node to RMTHOSTS settings

NT – NT Remote RMTHOSTS  Update RMTHOSTS on both NT nodes.  If only one updated, the other NT node will still use QUES layer. For example – RMTHOSTS entry on WLA node not updated to use RMT layer for WLM – WLM RMTHOSTS entry updated to use RMT layer for WLA. – All requests from WLM to WLA will use RMT. – Jobterm from WLM will use QUES layer

NT – NT Remote Private ccirmtd.rc Add NT node to ccirmtd.rc to prevent potential first autoConnect attempt failure. The CCIRMTD.rc in the private network must be updated to startup RMT connection

NT – NT Remote DMZ ccirmtd.rc  CCIRMTD.rc file on the DMZ must have entry with nostart and retry=0 (no retry).  This is to prevent CCI initialization from DMZ environment

NT – NT Remote Source Port  To pre-define source port for RMT connection, add environment variable CAI_CCI_PORT1  Set this on both NT nodes

Common Services DSM EVT NT -> NT Remote FIREWALL CORE 7001 Blocked - Persistent Connection and traffic initiated from Private network 7001 Blocked - Persistent Connection and traffic initiated from Private network DSM wvdbt Common Services EVT OPRDB CORE NT DMZ Private Network TCP 1721

Client would like to use QUES Layer but wish to block 7001 port from DMZ to private network. What are the implications? Deployment - Scenario 4

DMZ -> Private  Execute cawto in DMZ environment to send message to Private network – Cawto [ ] Sending message from DMZ to Private – Message will be denied by Firewall  Exception messages cannot be forwarded from DMZ to Private Network

DMZ -> Private with 7001 Blocked

Client would like to introduce user encryption for CCI traffic and also wish to implement host authentication. Deployment - Scenario 5

 Implement CCI Encryption exit – cauemcc2.dll – Can validate remote hosts and reject cci buffer  User encryption not valid for heterogeneous environment

Deployment Scenario – 5 Host Authentication

Client would like Workload Manger running in Private Network to be able to schedule jobs to Workload Agent running in DMZ environment. What are the considerations? Deployment - Scenario 6

CCI Ques Layer WLAEVT Deployment Scenario 6 WLM -> WLA FIREWALL CORE CCI 7001 port must be unblocked bi- directional WLM CCI Ques Layer EVT SCHDB CORE DMZ Private Network TCP 7001 NT

Client would like Workload Manger running in Private Network to be able to schedule jobs to Workload Agent in DMZ but wishes to block CCI 7001 from DMZ to Private Network What are the implications and will it work? No!! Deployment - Scenario 7

CCI RMT Layer WLAEVT Deployment Scenario 7 WLM -> WLA FIREWALL CORE Persistent connection Unblock 1721 and initiate CCI from Private Network Persistent connection Unblock 1721 and initiate CCI from Private Network WLM CCI RMT EVT SCHDB CORE DMZ Private Network TCP1721 NT

Deployment – Scenario 7 Work Load Management  Recap – Work Load Manager in Private Network – Wish to submit jobs to DMZ work load agent with CCI 7001 blocked from DMZ to Private Network – Work Load events such Job Termination should be sent from the DMZ using the persistent connection

Deployment – Scenario 7  Ques layer cannot be used in this environment  NT->NT RMT only supported in Firewall Environment  This requires use of RMT layer for WLM to successfully submit jobs to DMZ Work Load Agent and provide correct status  CCI initialization from Private Network

What is a typical VPN architecture? Deployment - Scenario 8

Typical VPN Architecture DMZ eTrust Intrusion Detection Private Network TNG CORe SurviveIT WebServer1 System Agent Web Agent VPN Client WebServer2 System Agent Web Agent VPN Client WebServer3 System Agent Web Agent VPN Client Event and WLA TNG DSM WMO (DSM) Web Response Mtr WTA VPN Admin &Client SurviveIT Failover TNG CORe SurviveIT Failover TNG DSM WMO (DSM) Event and WLM Web Response Mtr WTA VPN Admin &Client SurviveIT The Big Bad Internet eTrust Intrusion Detection No TCP/IP Stack All comms through port 509

Summary  For NT – NT, use Ques Layer with 7001 unblocked for the selected TNG servers only. CCI Initialization from DMZ and Private environment  For NT –> Unix or UNIX -> NT (including Linux), RMT layer provides persistent connection

Questions and Answers Any questions?