Highlighted
Contributor.. Contributor..
Contributor..
839 views

RUM monitoring in firewalled zones

Jump to solution

Hi, currently we have separate RUM Probe and RUM Engine servers deployed on our internal network, and are capturing traffic via network taps attached to our internal load balancers.  So we're able to monitor our internal-facing applications only currently.

 

We'd like to now look at what it would take to start capturing traffic with RUM for our externally-facing applications in a firewalled (DMZ) zone.  I believe we'd use the same method of attaching network taps to the load balancers in this firewalled environment.

 

Is the standard practice to install a a RUM Probe in the firewalled zone, and then open port 2020 (which is used for communication between the Probe and the Engine) on our firewalls?

 

Any feedback or suggestions are appreciated.

 

Thanks!

Labels (1)
0 Likes
1 Solution

Accepted Solutions
Highlighted
Micro Focus Expert
Micro Focus Expert

In 8.x world you create RUM Application under RUM Engine. Hence for 2 different RUM Engines there will be 2 different applications for which you cannot see combined data. In 9.x world it won't be a problem.

 

Placing a GW server in DMZ is a bad idea from architecture point of view. If you indeed have any external data collectors that cannot access GW server located in internal secure zone, you'd better consider using reverse proxy server in DMZ (for details please see BAC/BSM Hardening guide).

View solution in original post

5 Replies
Highlighted
Micro Focus Expert
Micro Focus Expert

Yes, that would be one option.

Another option is to have a dedicated RUM Engine in DMZ that will work with RUM Probe in DMZ.

Depends on whether you monitor the same application or not (i.e. do you need to see data from both places together?) and the version of BAC/BSM in use.

Highlighted
Contributor.. Contributor..
Contributor..

Thanks Dmitry.

 

Can you clarify this statement a little further, I'm not sure I understand what you mean by this:

 

"Depends on whether you monitor the same application or not (i.e. do you need to see data from both places together?)"

 

My version of BAC is 8.07 currently in production, but we're in the process of moving to BSM 9.12 (in test now).

 

Are there advantages (aside from capacity) to having a dedicated Gateway server in the DMZ?

 

Thanks!

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

In 8.x world you create RUM Application under RUM Engine. Hence for 2 different RUM Engines there will be 2 different applications for which you cannot see combined data. In 9.x world it won't be a problem.

 

Placing a GW server in DMZ is a bad idea from architecture point of view. If you indeed have any external data collectors that cannot access GW server located in internal secure zone, you'd better consider using reverse proxy server in DMZ (for details please see BAC/BSM Hardening guide).

View solution in original post

Highlighted
Contributor.. Contributor..
Contributor..

Thanks again.  My question should have read, are there advantages to having a dedicated ENGINE server in the DMZ (not GW), sorry, either way I think I understand now given your explanation of BAC vs BSM RUM config's.

0 Likes
Highlighted
Honored Contributor.. Honored Contributor..
Honored Contributor..

Hi Dmitry,

Hope you are doing fine.

I am bit confused, we are working on RUM 9.50 we want to place our RUM sniffer probe in DMZ, how rum sniffer probe and rum engine will communicate? do we need a reverse proxy or something? looking for help, kindly guide.

Regards

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.