Transcript CCI In DMZ Environment

TNG
2.4
CCI through Firewall
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 bidirectional
 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
–
–

Configuration Issues
–

Connection established at start up and remains
open for duration of CCI
Preferred option in Firewall deployment
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 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
SYN
Private
DMZ
SYN/
ACK
Private
DMZ
ACK
Private
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
Deployment - Scenario 1
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
NT -> NT
Private
Network
CORE
DSM
wvdbt
EVT
OPRDB
TRANSPORT PROTOCOLS = TCP
Common Services
TCP 7001
DSM
DMZ
EVT
Common Services
TRANSPORT PROTOCOLS = TCP
FIREWALL
Deployment - Scenario 2
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
Deployment Scenario 2
NT -> NT
Private
Network
CORE
DSM
wvdbt
EVT
OPRDB
Common Services
TCP 7774
FIREWALL
DSM
DMZ
EVT
CATRAP
Common Services
Deployment - Scenario 3
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
NT -> NT Remote
Private
Network
CORE
DSM
wvdbt
EVT
OPRDB
Common Services
TCP 1721
NT
DMZ
DSM
EVT
Common Services
FIREWALL
Deployment - Scenario 4
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
Deployment - Scenario 5
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
Deployment - Scenario 6
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
WLM -> WLA
CORE
WLM
Private
Network
EVT
NT
CCI Ques Layer
SCHDB
TCP 7001
FIREWALL
CCI Ques Layer
DMZ
WLA
EVT
NT
Deployment - Scenario 7
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
WLM -> WLA
CORE
Private
Network
EVT
WLM
NT
CCI RMT
SCHDB
TCP1721
FIREWALL
CCI RMT Layer
DMZ
WLA
EVT
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
Deployment - Scenario 8
What is a typical VPN architecture?
Typical VPN Architecture
The Big Bad
Internet
TNG CORe
SurviveIT
Failover
TNG CORe
SurviveIT
TNG DSM
WMO (DSM)
No
Web Response Mtr
TCP/IP
WTA
Stack
VPN Admin &Client
eTrust
SurviveIT
Intrusion Detection
Private
Network
Failover
TNG DSM
WMO (DSM)
Event and WLM
WTA
VPN Admin &Client
SurviveIT
Web Response Mtr
WebServer1
System Agent
Web Agent
VPN Client
All comms
through port
509
eTrust
Intrusion Detection
WebServer2
System Agent
Web Agent
VPN Client
DMZ
WebServer3
System Agent
Web Agent
VPN Client
Event and WLA
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?