how to access self-service interface using public IP address

[XiaoliDing]

We have a RSA SecurID 8.2 deployed on virtual machine. During installation, host name for internal access and private IP address are used for this server. But later, the client wants to allow end user to access the self-service console from Internet. And to do that, host name for external access and public IP address will be used. They don't plan to configure NAT for this situation. They only open the firewall to allow access to the server via public IP address. But the server was initially configured with private IP and internal host name, so it does not respond to the external access to the self-service console (via port 7004). What we should do about this situation? Please suggest, thanks.

And below is what the client said:

"we are not doing a NAT on the firewall. We are expecting the 169.x.x.x address (public) to be accessible and simply allowing the traffic through the firewall. The 10.x.x.x address (private, server was installed with this IP) should not be in play for the publicly accessible self service tool."

[DarrenGaunt · Accepted solution]

Hi,

   in this scenario, you should deploy a web tier. It is specifially designed for this situation.

It is never advisable to allow internet traffic to access the RSA AM appliance as it is a serious security risk. RSA developed the Web Tier to sit on either a Windows or Linux server in the DMZ. Then that Web Tier server Is allowed to communicate (via certificate based encryption) with it's associated RSA AM appliance in deployment.

Your client would then point the external IP and hostname at the Web Tier server.

Full details about deploying a Web Tier can be found in the product documentation set.

Best Regards,

Darren Gaunt, Implementation Specialist

RSA EMEA Professional Services.

[XiaoliDing]

Hi Darren,

We have discussed about this before the deployment. The client

specifically said they don't want to use a web tier. The current solution

is what they want. My question is without the web tier, how to make the

self-service console accessible from the outside. Will NAT must be used?

Or a different NIC interface should be configured for the appliance with

the external host name and public IP address?

Please advise.

Thanks,

Xiao-Li Ding

Information Security Consultant and IT Architect

MS in Computer Science, CISSP, CISA, MBA

IBM Security Services, NA

xding@us.ibm.com

(678) 248-3727

.................................................................................................

Links: IBM Security | Data Security | Emergency Response |

[EdwardDavis]

Without NAT or Web Tiers, then give the second nic a public IP, and that will allow self service login.

But this is risky to expose the actual RSA primary server network interface to 'the world'.

Risky for performance...If someone decides to DOS you, if it isn't throttled by your firewall,

it could make the Primary RSA server busier fending off the bad traffic, reducing performance

to a slight, or more significant, degree.

Web Tiers are designed to a) perform self service functions and b) only allow authorized traffic to

touch the RSA primary and c) if someone decides to DOS the web tier, it won't harm the

RSA servers themselves dealing with load fending off bad traffic. 

[XiaoliDing]

Hi Darren,

I also made changes to the alternative IP addresses settings of the RSA

SecurID appliance, with public IP addresses of the appliances, as

following:

It does not work, because the client does not configured NAT to convert

public IP (169.x) to private IP (10.x) yet.

To make the public IP or alternative IP addresses work, should they just

configure NAT to map the public IP to the private ones?

Thanks,

Xiao-Li Ding

Information Security Consultant and IT Architect

MS in Computer Science, CISSP, CISA, MBA

IBM Security Services, NA

xding@us.ibm.com

(678) 248-3727

.................................................................................................

Links: IBM Security | Data Security | Emergency Response |

[ChristopherSalv]

By setting the second interface to use a public IP address, you would not have to NAT anything on your firewall. 

[XiaoliDing]

Hi Chris,

Appreciate your suggestions.

Bests,

Xiao-Li Ding

Information Security Consultant and IT Architect

MS in Computer Science, CISSP, CISA, MBA

IBM Security Services, NA

xding@us.ibm.com

(678) 248-3727

.................................................................................................

Links: IBM Security | Data Security | Emergency Response |

[ChristopherSalv]

No problem Xiaoli, I do have a few more thoughts, suggestions on this if you want to check them out below.

1. We still say using a webtier is the best and most secure way to go ( but you know that already )

2. By assigning the public IP to the second interface, that makes the IP fully reachable from the outside. That being said, no natting is needed, but firewall rules may need to be adjusted at the gateway to allow the traffic type in. Also tcp port 7004 needs to be open on the firewall. This poses a potential problem where a user trying to access the self service page on the outside network fails due the port being blocked on there company firewall. Typically https traffic on 443 is allowed as it's the default ssl https port. Some firewalls may say "traffic type is https, but port is 7004, block request" so as a more complete solution I would advise the following.

- Via external DNS add a new host entry for the fqdn of the primary authentication manager. If the fqdn of the primary is something like server.test.local then that will need to be changed to match the domain you normally use for external DNS. So for example if your company domain is test.com you want to set the fqdn of the primary to server.test.com. Set the A record for server.test.com to the public IP address you assigned to the second interface. Next you want to add a second rule on the firewall for port translation 443 to 7004 when accessing the ssc url from the outside. This will ensure all external users will be able to hit the site without worry of there network firewall blocking port 7004

Hope this helps.

~Chris

[XiaoliDing]

Hi Chris,

After a second NIC has been added to the appliance, we need to configure

the appliance network settings from the operation console, as in the

following, right?

As you can see, we have two NICs available now, eth1 adn eth2. The first

one eth1 has been used, it was assigned a private IP address. The second

one eth2 has not been used yet. We intent to assign a public IP like

169.47.27.x. So in this situation I do need to enable eth2 and fill the

relevant fields and just save it, right? Do I need to reboot the appliance

from the operation console or do I need to ask the VMWare admin to restart

the virtual machine from the VMWare level? Or just save will be enough?

By the way, I have done the following changes:

To be clear, there are no NAT used in this environment, so are those

changes really needed too?

Please reply.

Thanks,

Xiao-Li Ding

Information Security Consultant and IT Architect

MS in Computer Science, CISSP, CISA, MBA

IBM Security Services, NA

xding@us.ibm.com

(678) 248-3727

.................................................................................................

Links: IBM Security | Data Security | Emergency Response |

[XiaoliDing]

Hi Chris,

After making those network setting changes in the operation console and

restarting the services, the self-service console of this RSA appliance

can be reached with public IP address and can respond to the requests. But

there are still issues.

If I try to access the self-service console with this URL:

https://169.47.27.113/ssc, it will redirect me to the following URL:

https://a0001p5eapp0001.mgt.mhas.ibm.com:7004/console-selfservice/ this

URL contains the internal FQDN the appliance was installed with, this is

an internal FQDN and can not be recognized outside the internal network.

So this page can not be displayed.

If I replace the FQDN in the above URL with the public IP address

specifically, e.g.:

https://169.47.27.113:7004/console-selfservice/

I can get to the log in page (yes!):

But after clicking on OK, I will be redirected again to the following URL:

https://a0001p5eapp0001.mgt.mhas.ibm.com:7004/IMS-AA-IDP/sso/logon?RequestID=f79d2b9a17ffaa0a3617afba7373093b&MajorVersion=1&MinorVersion=2&IssueInstant=2016-12-22T20%3A32%3A13&ProviderID=urn%3Acom%3Arsasecurity%3A2004%3A10%3Asso%3Aprovider%3A48f23ac317ffaa0a0a62d3b67a881e48%3Aconsole-selfservice-.........

.

And this will fail again because it contains this part

a0001p5eapp0001.mgt.mhas.ibm.com:7004 with the internal FQDN!

We plan to use an public FQDN (e.g. selfservice.projectname.ibm.com)

outside the internal network, and that FQDN will be recognized outside the

internal network.

How to let the RSA SecurID not using the internal host name or FQDN in the

intermediate URLs, just use the public IP address or the public FQDN?

BTW, you said we can add a rule into the firewall so that any URL with

/ssc at the end will be translated to port 7004, that way from the client

environment they only need to allow port 443. But as you can see, the URL

we were redirected to has a port number 7004 specifically. This is how RSA

SecurID works. Does this mean the port 7004 has to be opened any ways?

Please suggest.

Thanks,

Xiao-Li Ding

Information Security Consultant and IT Architect

MS in Computer Science, CISSP, CISA, MBA

IBM Security Services, NA

xding@us.ibm.com

(678) 248-3727

.................................................................................................

Links: IBM Security | Data Security | Emergency Response |