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
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.
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
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
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
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.
Deployment - Scenario 2Deployment - Scenario 2
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
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
Deployment - Scenario 3Deployment - Scenario 3
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 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?
Deployment - Scenario 4Deployment - Scenario 4
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
Client would like to introduce user encryption for CCI traffic and also wish to implement host authentication.
Deployment - Scenario 5Deployment - Scenario 5
Deployment - Scenario 5
Implement CCI Encryption exit– cauemcc2.dll– Can validate remote hosts and reject cci
buffer User encryption not valid for
heterogeneous environment
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 6Deployment - Scenario 6
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!!
Deployment - Scenario 7Deployment - Scenario 7
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
Typical VPN Architecture
DMZ
eTrustIntrusion Detection
PrivateNetwork
TNG COReSurviveIT
WebServer1System Agent
Web AgentVPN Client
WebServer2System Agent
Web AgentVPN Client
WebServer3System Agent
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