cci through firewall tng 2.4 updated april 16, 2002

CCI through Firewall

TNG 2.4

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 – 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 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

DMZ Private

DMZ Private

DMZ Private

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 – 7001 ---> 7003 ---> 1721

Testing Environment

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 1Deployment - Scenario 1

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

7001 Unblocked both directions – CCI may be initiated from DMZ

DSMwvdbt

Common Services

EVT

OPRDB

CORE

DMZ

Private Network

TRANSPORT PROTOCOLS = TCP

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.



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


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

CCI Connectivity not required through firewall

DSMwvdbt

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



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 RemoteRMTHOSTS

Add NT node to RMTHOSTS settings

NT – NT RemoteRMTHOSTS

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 RemotePrivate 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 RemoteDMZ 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 RemoteSource 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

DSMwvdbt

Common Services

EVT

OPRDB

CORE

NTDMZ

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?


DMZ -> Private

Execute cawto in DMZ environment to send message to Private network

– Cawto [<private>] 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.



Implement CCI Encryption exit– cauemcc2.dll– Can validate remote hosts and reject cci

buffer User encryption not valid for

heterogeneous environment

Deployment Scenario – 5Host 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?


CCI Ques Layer

WLA EVT

Deployment Scenario 6 WLM -> WLA

FIREWALL

CORE

CCI 7001 port must be unblocked bi-directional

CCI 7001 port must be unblocked bi-directional

WLM

CCI Ques Layer

EVT

SCHDB

CORE

DMZ

Private Network

TCP 7001

NT

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!!


CCI RMT Layer

WLA EVT

Deployment Scenario 7 WLM -> WLA

FIREWALL

CORE

Persistent connectionUnblock 1721 and initiate CCI from Private Network

Persistent connectionUnblock 1721 and initiate CCI from Private Network

WLM

CCI RMT

EVT

SCHDB

CORE

DMZ

Private Network

TCP1721

NT

NT

Deployment – Scenario 7Work 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?


Typical VPN Architecture

DMZ

eTrustIntrusion Detection

PrivateNetwork

TNG COReSurviveIT

WebServer1System Agent

Web AgentVPN Client


Web AgentVPN Client


Web AgentVPN Client

Event and WLA

TNG DSMWMO (DSM)

Web Response MtrWTA

VPN Admin &ClientSurviveIT

FailoverTNG COReSurviveIT

FailoverTNG DSMWMO (DSM)

Event and WLM

Web Response Mtr

WTAVPN Admin &Client

SurviveIT

The Big BadInternet

eTrustIntrusion Detection

NoTCP/IPStack

All commsthrough 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?Any questions?

cci through firewall tng 2.4 updated april 16, 2002

Documents

data slide

cci applications

presentation slide

mechanism of cci

configuration setting

persistent connection

cci layers ques layer

alias conflict slide