RADIUS Setup

1. The RADIUS configuration is only configured in the Default domain. Once you
log into the web GUI, click Administration > Access > RADIUS Settings, as shown in
Figure 2.
Figure 2. Configuring the RADIUS settings

2. Click the AAA/RBM Servers tab (Figure 3) to add the RADIUS servers that will
be used.
Figure 3. Adding the RADIUS servers

3. Click Add to add the first primary server (if you have a primary or secondary
RADIUS server set up), as shown in Figure 4.
Figure 4. Adding the RADIUS server address/port/secret
4. Locate the correct RADIUS server for the appliance that is being assigned and
input the parameters specified, as shown in Figure 5.
Figure 5. RADIUS Server parameters entry
Assigning the static route assignment for the RADIUS
connectivity
Figure 6 shows a sample Juniper Steel-Belted RADIUS server user console.
Figure 6. Steel-Belted RADIUS client application

Notice that an IP address is specified on the RADIUS configuration. The RADIUS

administrator may choose to input all four Ethernet interfaces. However, if only one
Ethernet interface is used, then incoming authentication must be from the enlisted IP
address on RADIUS. Due to the specific IP address required by RADIUS, you need to
assign static routes on DataPower so that all outbound transactions use the IP address
used for RADIUS communication.
DataPower dynamically utilizes any of the four Ethernet interfaces that are enabled on
the appliance (least weighted connection), and might use one of the three other
Ethernet interfaces that are not specified on the RADIUS server. This will cause
connectivity failure. For example, if IP 192.168.1.52 is given to the RADIUS and
SecurID team, then "eth4" (which was assigned IP 192.168.1.52) needs the primary and
secondary RADIUS server static route input, so only eth4 communicates to the RADIUS
servers.
If you do not put a static route in place, then DataPower may choose to use one of the
other Ethernet interfaces. This is not allowed to communicate to the RADIUS server,
and RADIUS authentication on DataPower will fail. Static route assignments to the
 Ethernet interface being used to communicate to the RADIUS server are set by the
following:
1. Navigate to the Ethernet Interface section of the appliance as shown in Figure
7. Select Network > Interface > Ethernet Interface, or type in Ethernet Interface in
the search field.
Figure 7. Ethernet interface configuration

2. Select the interface that will be communicating with the RADIUS server. This is
the IP or host name given to the RADIUS and SecurID team, who will assign the
aforementioned IP or host name to RADIUS and SecurID. Click on the Static
Routes tab as shown in Figure 8.
Figure 8. DataPower static routes on the Ethernet 4 interface
3. Click Add. Enter the following parameters (see Figure 9):
o Destination: IP address of the RADIUS server with its /CIDR notation.
o Gateway: Cross reference the RADIUS server IP to its gateway IP from
the table shown in Figure 8.
o Metric: 0 as its preference value.
Figure 9. DataPower static route entry for the RADIUS Server parameters
4. Once the parameters have been entered, click Apply, then Apply your static
route configuration, and select Save Config.
Testing RADIUS
DataPower provides a testing client to test your RADIUS connection. To test:
1. Log into the appliance under the Default domain.
2. Navigate to the RADIUS Settings again (Objects > Access Settings > RADIUS
Settings, or type inRADIUS in the search field). Click Test RADIUS on the right side of
the RADIUS Settings page, as shown in Figure 10.
Figure 10. DataPower test RADIUS link
3. Once the Test RADIUS prompt opens, enter your user name and SecurID (your
PIN and SecurID), as shown in Figure 11.
Figure 11. DataPower Test Radius page

4. Click the Test RADIUS button.

5. Click Confirm as shown in Figure 12.
Figure 12. DataPower confirm test Radius execution page
6. You receive a completed successfully prompt (Figure 13) if the authentication
was passed successfully. If not, proceed to the next section on troubleshooting.
Figure 13. DataPower Test Radius action completed page

Troubleshooting RADIUS
There are a few things to consider when troubleshooting RADIUS integration for
DataPower. There are some preliminary factors that may cause your RADIUS
connection to not authenticate your username:
 SecurID: You may have forgotten to enter your PIN with your SecurID code. Do
not forget that you will need to enter your PIN and secure ID code from your key fob.
 TCP Connection Test: Make sure that DataPower can ping (TCP connection)
the RADIUS server and port (Control Panel > Troubleshooting Panel Icon > TCP
Connection Test).
Note: You may not be able to do a Remote Host ping because the firewall opened only
allows port 1812 to be opened.
 Static Route:: You may need a static route in place if you have not already
specified the correct Ethernet interface to communicate with the specific RADIUS
server.
 Firewall: Check with the SecurID administrator or team on whether they see
authentications hitting their servers if you still cannot ping the IP and port. If they cannot
see any transaction coming from any of the DataPower Ethernet interfaces, then you
might need to open a firewall.
Configuring basic XML firewall with RADIUS AAA
After completing the RADIUS client setup, the service may be developed for
applications that will be authenticating SecurID users. To create a basic level XML
firewall with AAA authentication for a RADIUS service:
XML firewall configuration with RADIUS AAA
1. Select the Access Control (AAA) as shown in Figure 14 and click Next.
Figure 14. DataPower XML Firewall Wizard

2. Name the firewall service and click Next as shown in Figure 15.
Figure 15. DataPower Create AAA Firewall Service page
3. Select loopback-proxy as shown in Figure 16 and click Next.
Figure 16. DataPower AAA firewall type

4. For the purpose of simplifying network bottlenecks, use the dynamic IP

address 0.0.0.0 for the Device Address (which is not advised to be used in production)
and choose a port that is opened on the appliance to be used. For the example, we are
using port "1234" as shown in Figure 17.
Figure 17. DataPower AAA firewall front end and port assignment
5. In the "Create an AAA Firewall Service" section, click the plus sign (+) Create a
new AAA Policyicon as shown in Figure 18.
Figure 18. DataPower AAA firewall policy

6. Enter a name for the AAA Policy and click Create. The example uses RADIUS­
Demo­AAA­Policy as shown in Figure 19.
Figure 19. DataPower AAA firewall policy name assignment
7. Select Password-carrying UsernameToken Element from WS-Security
Header as shown in Figure 20 and click Next.
Figure 20. DataPower AAA firewall access control policy identification method selection

8. Select Use specified RADIUS Server as shown in Figure 21 and click Next.
Figure 21. DataPower AAA firewall access control policy method selection
9. Select Local Name of Request Element as shown in Figure 22 and click Next.
Figure 22. DataPower AAA firewall access control policy resource identification method selection
10. Select Allow Any Authenticated Client as shown in Figure 23 and click Next.
Figure 23. DataPower AAA firewall access control policy to allow any authenticated client selection
11. Ensure that the defaults are used in the last page, click Commit (Figure 24), and
click Done on the page that follows.
Figure 24. DataPower AAA firewall commit page
12. Click Next in the AAA Information page as shown in Figure 25. Ensure that the
AAA policy you just created is selected in the field. Click Commit and Done on the
pages that follow.
Figure 25. DataPower AAA firewall policy information page
Note: Ensure you select Save Config after you complete this step.
Your completed XML firewall with RADIUS AAA authentication should look like Figure
26.
Figure 26. DataPower XML firewall completed sample page

The Processing Policy for the AAA Policy should look like Figure 27.
Figure 27. DataPower XML firewall completed AAA processing policy page
 Testing the SecurID key fob code
After creating the AAA XML firewall, you can conduct an authentication test:
1. Figure 28 shows an RSA SecurID key fob with the secure token displayed.
Figure 28. RSA SecurID key fob containing code to be authenticated

2. Figure 29 shows a sample WS-Trust SOAP file to enter your username and
password to authenticate against the service. You see that a username and
the PIN and securID token code presented on the key fob were saved in the file.
Figure 29. Sample WS-Trust XML file
 Create the aaa.xml file as shown in Listing 1.
Listing 1. aaa.xml file to be used as the client side authentication and executed by cURL
1
2 <?xml version="1.0" encoding="UTF­8"?>
3 <soapenv:Envelope xmlns:wsse=http://docs.oasis­open.org/wss/2004/01/
4  oasis­200401­wss­wssecurity­secext­1.0.xsd
5 xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
6 <wsse:Security>
7 <wsse:UsernameToken>
8 <wsse:Username></wsse:Username>
9 <wsse:Password></wsse:Password>
10 </wsse:UsernameToken>
</wsse:Security>
11 </soapenv:Header>
12 <soapenv:Body>
13       <msg>Authentication Passed</msg>
14 </soapenv:Body>
15 </soapenv:Envelope>
16
3. Once you have saved the aaa.xml file, you are ready to run the file against the
DataPower service. By executing curl –data­binary @aaa.xml 
http://<IP_of_appliance>:1234, a successful authentication returns the full SOAP
message as shown in Figure 30.
Figure 30. cURL execution sample
4. If the authentication is successful, you can see the results of the complete
transactions in the system logs from the DataPower WebGUI as shown in Figure 31.
Figure 31. DataPower log of completed transactions

IHS setup

WebSphere® Application Server Network Deployment (ND) can be deployed either

standalone or as part of a WebSphere cluster. In both cases, a typical deployment
environment includes an IBM® HTTP Server (IHS) that is positioned between the
WebSphere server and external connections, such as those that come through a
firewall or demilitarized zone (DMZ).
 Deployment of the IHS typically includes configuration of Secure Socket Layer (SSL)
connections, to secure both external connections and internal connections to the
WebSphere servers. Successful deployment of a Tivoli® Federated Identity
Managerenvironment that use WebSphere as a point of contact server requires that
SSL is enabled on the IHS server.
Enablement of SSL on IHS requires the generation of an SSL key database and key.
You can use the ikeyman utility to generate the necessary keys. If you have not enabled
SSL on the IHS server, you must complete this task before configuring Tivoli Federated
Identity Manager.
For instructions, consult the information center for your IBM HTTP Server for
WebSphere Application
Server: http://publib.boulder.ibm.com/infocenter/wasinfo/v8r0/index.jsp. See the topics
that describe how to secure an IBM HTTP Server, including:
 Working with key database
 Securing with SSL communications
Adding an SSL port for a SOAP backchannel
Tivoli Federated Identity Manager single sign-on federations support configuration of
certificate authentication or basic authentication between federation partners. When the
deployment environment includes IHS, you must configure a SOAP backchannel to
support these authentication methods.
You must add a virtual host to the IHS configuration. The configuration settings are
typically located in the standard IHS configuration file. For example, on Linux or UNIX:
/opt/IBM/HTTPServer/httpd.conf
For instructions, consult the information center for your IBM HTTP Server for
WebSphere Application
Serverhttp://publib.boulder.ibm.com/infocenter/wasinfo/v8r0/index.jsp. See the topics
that describe how to secure an IBM HTTP Server, including:
 Securing with SSL communications
Updating federation configuration for SOAP
connection
When the IBM HTTP Server is configured to listen on both the default port and the
SOAP backchannel port, you must define and configure your federations using those
ports for the federation URLs.
Federation URLs must use port 443. This port is the default HTTPS port, so there is no
need to include the actual port in the URL syntax. The SOAP backchannel port is
typically 9444.
Since the SOAP backchannel security involves a connection with the IHS server, the
typical configuration steps when defining a federation does not include specifying client
authentication on the SOAP backchannel.

MQ setup
Are you using MQ Internet Pass-Thru?
gwydiontudur | June 21 2017 | 7,436 Views

MQ Internet Pass-Thru (MQIPT) is an IBM MQ product extension that helps you connect MQ
queue managers or clients that are not on the same network securely. It’s free to download
from the IBM MQ SupportPac website, and is fully supported when used with a supported
version of IBM MQ.
As MQIPT fix pack 2.1.0.3 has just been released, I thought I’d take this opportunity to briefly
highlight what this SupportPac offers.

What can MQIPT do?

MQIPT listens on one or more TCP ports and forwards MQ connections that it receives. These
connections can be between two MQ queue managers, or an MQ client and a queue manager.
The presence of MQIPT is completely transparent to the clients and queue managers.
It runs as a standalone service and doesn’t need to run on the same system as a queue
manager or client. In a basic configuration MQIPT just forwards connections to a queue
manager, as shown in this diagram.

As MQIPT understands the MQ network protocol it can perform various transformations on the
connection, such as TLS encryption or decryption, and wrapping the connection in HTTP to
enable MQ connections to be tunnelled through the firewall using existing HTTP proxies.
For more flexibility, you can use a pair (or more if you need to!) of MQIPT instances. In this
example a pair of MQIPT instances is used to secure a connection with TLS between the two
instances. The queue managers are unaware that MQIPT or TLS is in use.
Note that you don’t have to use a pair of MQIPT instances to use TLS. MQIPT can also
communicate directly with MQ using TLS.

Why would I use MQIPT?

There are two main benefits to using MQIPT - improved security, and easier network
administration. Let’s look at an example of how you could use MQIPT.
A common use of MQIPT is to place it in the DMZ, so that it acts as a single point of access to
your MQ network from the internet. External queue managers or clients connect to MQIPT
rather than directly to the queue manager, as shown in this diagram.

This has the benefit of pushing security checks out to the edge of your network, as MQIPT can
apply rules to connections, such as checking the client TLS certificate, before the channel can
connect to the queue manager.
If the MQ channels are using TLS, then MQIPT will also provide a break in the TLS session in
the DMZ, which is something that many organizations require.
The other benefit of this configuration is that it reduces the number of firewall rules needed to
allow connections to the queue manager, as all external connections to the queue manager
will now come from the machine where MQIPT is running.

WDP setup
When and How to Setup DMZ Host
for Home Use
DMZ host for home routers is a fairly easy option to setup. However, the usual
routers options or tooltip do not usually tell you how dangerous it can be when you
are setting up DMZ host. In this simple to understand guide, we will go over
everything that you need to know about DMZ and when to set up your common
DMZ host for regular home use.

What is DMZ and DMZ Host and their Difference

A true DMZ is basically a section of your network that is exposed to the internet but
do not connect to the rest of your internal network. However, most of the home
routers offer DMZ setting or DMZ host settings. These settings allow you to just
expose one computer or one device to the internet.

The problem is that this specific computer can still talk to the rest of your internal
network. This means that if the “DMZ host” has been broken into and infected with
computer virus or internet malware, it may affect the rest of the devices on your
home network.

Thus, when you are setting up a “home” DMZ or DMZ host, you have to be really
careful. In fact, you generally should not use the home router’s DMZ function at all
if you can avoid it.

It should be noted that DMZ or DMZ Host does not improve the performance speed
or latency of your router’s connection to the server. It is simply a security measure
(or lack of) that decides whether or not the devices is completely open to the
internet.

Being a DMZ host means that it will have all its router ports open and respond to
internet queries and pings. Although your PC or server machine may have other
software firewall, the router acts as your first line of defense. By being a DMZ host,
you are open to attacks that your router would have other wise blocked with the
usual router firewall.

Alternative to DMZ Host

Instead of using the DMZ host function with your router, setting up port forward is
a much better alternative than a straight cut DMZ Host. This is because the DMZ
host setting on your router for a regular PC or MAC is generally considered NOT
safe nor secure.

When to Actually Use Router DMZ Host

1. Use DMZ Host as a last measure as a troubleshooting tool.
If you simply cannot get port forwarding or your router setup correctly to allow
certain kind of tunneling or connections. You may want to use DMZ temporarily to
see if the router is causing the issue or your server’s setting. However, you should
make sure the DMZ machine is up to date with all the security patches before doing
so.

2. Use DMZ Host for applications that requires random port to be opened.
You may be stuck with DMZ host if you are dealing an application that requires all
ports to be opened. Make sure your DMZ device has all security updates in place.

3. When you need to host a home based web server

Although it is better to host webservers and only port forward the needed ports for
the web server. You can consider putting your web server under router’s DMZ. But
you may want to use two home routers to separate your web server and your
internal network to achieve a “true DMZ”. However, the setup is outside the scope
of this general DMZ guide.

4. Use DMZ Host for gaming consoles

Although in most cases a proper port forwarding and router NAT settings can allow
perfect connection for your gaming consoles such as Xbox One, Xbox 360, ps3, ps4,
or Nintendo. Sometimes you may still have issues. Put your gaming consoles as a
DMZ when all else fails to see if it will make a difference.

Actually Setting Up DMZ Host with your Router

Use Static IP
Assign Static IP to the device that you want to become the DMZ Host. This is
important so that your router does not assign a random IP to a machine that you
do not wish to be the DMZ.

Make Sure the Devices is Updated with latest security patches

Putting your device as DMZ can pose as a serious security risk if you do not know
what you are doing. Make sure to upgrade that device with all the latest patches to
fend off the most common attacks.

Input the Static IP assigned as DMZ Host

With the DMZ host setting, input the local IP for the machine that you wish to be the
DMZ. With it, you should be done with most of the basic Router DMZ host setups.

Consider Setting Up “True DMZ”

If you are setting up a personal game server or web server that requires you to use
DMZ, consider getting two routers and setup a “true DMZ” zone so that your server
machine is blocked away from internal network. This may help you with your
network’s security in most cases

Firewall rules

Firewall Rules
A management client will need to be installed on a PC to manage the firewall and create
the configurations needed. See the documentation from your firewall (or other NVA)
vendor on how to manage the device. The remainder of this section will describe the
configuration of the firewall itself, through the vendors management client (i.e. not the
Azure portal or PowerShell).

Instructions for client download and connecting to the Barracuda used in this example
can be found here: Barracuda NG Admin

On the firewall, forwarding rules will need to be created. Since this example only routes
internet traffic in-bound to the firewall and then to the web server, only one forwarding
NAT rule is needed. On the Barracuda NextGen Firewall used in this example the rule
would be a Destination NAT rule (“Dst NAT”) to pass this traffic.

To create the following rule (or verify existing default rules), starting from the Barracuda
NG Admin client dashboard, navigate to the configuration tab, in the Operational
Configuration section click Ruleset. A grid called, “Main Rules” will show the existing
active and deactivated rules on the firewall. In the upper right corner of this grid is a
small, green “+” button, click this to create a new rule (Note: your firewall may be
“locked” for changes, if you see a button marked “Lock” and you are unable to create or
edit rules, click this button to “unlock” the ruleset and allow editing). If you wish to edit
an existing rule, select that rule, right-click and select Edit Rule.

Create a new rule and provide a name, such as "WebTraffic".

The Destination NAT rule icon looks like this:

The rule itself would look something like this:

Here any inbound address that hits the Firewall trying to reach HTTP (port 80 or 443 for
HTTPS) will be sent out the Firewall’s “DHCP1 Local IP” interface and redirected to the
Web Server with the IP Address of 10.0.1.5. Since the traffic is coming in on port 80 and
going to the web server on port 80 no port change was needed. However, the Target
List could have been 10.0.1.5:8080 if our Web Server listened on port 8080 thus
translating the inbound port 80 on the firewall to inbound port 8080 on the web server.

A Connection Method should also be signified, for the Destination Rule from the
Internet, "Dynamic SNAT" is most appropriate.

Although only one rule has been created it's important that its priority is set correctly. If
in the grid of all rules on the firewall this new rule is on the bottom (below the
"BLOCKALL" rule) it will never come into play. Ensure the newly created rule for web
traffic is above the BLOCKALL rule.

Once the rule is created, it must be pushed to the firewall and then activated, if this is
not done the rule change will not take effect. The push and activation process is
described in the next section.
http://cs.lewisu.edu/mathcs/msis/projects/msis595_KevinKeay.pdf

http://www.redbooks.ibm.com/redbooks/pdfs/sg247620.pdf

https://www.draytek.com/en/faq/faq-connectivity/connectivity.nat/how-to-set-dmz-host/

https://community.cisco.com/t5/firewalls/nat-for-dmz-access-from-the-inside-network-8-3-and-higher-
on-asa/td-p/2221190

https://sc1.checkpoint.com/documents/R77/CP_R77_Firewall_WebAdmin/6724.htm

http://www.brighthub.com/computing/windows-platform/articles/101914.aspx

https://forums.iis.net/t/1178765.aspx

https://www.networkworld.com/article/2268579/security/lab-10--setting-up-a-dmz.html -------
important

https://infosecwriters.com/Papers/jwebb_network_demilitarized_zone.pdf

https://community.spiceworks.com/topic/400484-so-i-ve-been-asked-to-set-up-a-dmz-but-allow-access-
to-the-internal-network

https://www.techrepublic.com/forums/discussions/dmz-dns-configuration-best-practice/
This is part of POC activity related to expose Web Services to the Internet world using DMZ IP in
WebSphere Datapower SOA Appliance (XI52).

We have two WebSphere Datapower XI52 Appliances in production environment with the Application
Optimization feature in place for the services load balancing between two datapower boxes.

Now there is new requirement to host new web services application in datapower appliance and
publish over the internet using DMZ IP to access from outside (public internet)...
This new web service will be load balance between two datapower boxes using Application
Optimization feature....

I need some clarification on below mentioned points before moving forward with the correct
approach :-

1) Network team will provide one DMZ IP and two Production IP's - DMZ and Production IP's are in
different network segment.
2) I will configure the production ip's on Eth10 Interface on both datapower boxes..
3) For Datapower ETH10 interface - Standby Control - Virtual IP Address will be the DMZ IP.
5) Firewall will be open between DMZ IP and Production IP for new web services SOAP/HTTP listner
port.
6) The web services will be expose to public internet using DMZ IP and this IP will be configure as
application optimizer to distribute the load on both the boxes
6) The DNS name will be register to the DMZ IP.

The overall flow like it is -

Internet -----> Firewall---> DMZ IP (port 9443) ------> Firewall -----------------> Datapower ETH10
interface IP on both boxes.....

Kindly suggest the correct approach to publish the new web service over the internet using DMZ in
WebSphere Datapower XI52 Appliances...

https://drupal.stackexchange.com/questions/2364/how-to-migrate-from-test-environment-to-
production-environment

https://www.ibm.com/support/knowledgecenter/SS2L6K_6.0.4/com.ibm.jazz.install.doc/topics/t_prep
are_sandbox_server_rename.html