Imperva Cyber Community

When deploying SecureSphere, we had a lot of problems arise when getting the gateways to work. Rather than following the "supported" architecture, it would've been great to learn what the vast majority of other users were doing instead! So I'm curious to learn how other SecureSphere users are deploying or have deployed their product (and architecture)? 


#On-PremisesWAF(formerlySecuresphere)
#AllImperva

------------------------------
Erik Segur
Michigan State University
------------------------------

Hi Erik,

I'd be interested in which part of the deployment you had most problems, and whether an improvement in documentation might have helped.

In Support we see all different types of deployments, and they are reasonably evenly spread across Bridge and Reverse Proxy modes when acting as a WAF. Which is better really depends on your existing architecture, but with the wholesale move to HTTPS, reverse proxy modes, whether transparent or explicit, do have the benefit of offloading the SSL portion of this, and either having the connection to the backend servers in plain HTTP (not ideal of course) or having it use different cipher suites or even TLS version if the backend infrastructure is not easy to upgrade.

For DAM (DB security) use, having agents on the DB nodes is really the only game in town now, with the agents talking to the GW. The major advantage is being able to monitor local DB access too, which is crucial.

I'm sure if you share which aspects of deploying the GW you found least intuitive, others will be along to see if they agree with you.

------------------------------
Stefan Pynappels
Escalation Engineer
Imperva
------------------------------

Original Message:
Sent: 10-21-2019 16:05
From: Erik Segur
Subject: How did you deploy SecureSphere?

When deploying SecureSphere, we had a lot of problems arise when getting the gateways to work. Rather than following the "supported" architecture, it would've been great to learn what the vast majority of other users were doing instead! So I'm curious to learn how other SecureSphere users are deploying or have deployed their product (and architecture)? 


#On-PremisesWAF(formerlySecuresphere)
#AllImperva

------------------------------
Erik Segur
Michigan State University
------------------------------

We ended up going with a Reverse Proxy deployment behind a pair of load balancers for our WAF which worked well for about 90% of our apps.  Unfortunately, our more critical and complicated apps didnt work in that environment because at the time the 2MB payload limit wasnt documented and we also had bugs with data chunking and websockets.  These have all since been re mediated and documented but it meant a long and painful roll out where we really weren't sure if SecureSphere would actually work.  When reviewing the architecture at a later date, we found out that a Bridge deployment was much more common and wouldn't have had the same issues in these edge cases.  Having known that up front we would have gone with a bridge deployment and been much more successful.  

We appreciate the partnership that Imperva has had in working through these complicated issues.

Erik

------------------------------
Erik Segur
Michigan State University
------------------------------

Original Message:
Sent: 10-22-2019 14:47
From: Stefan Pynappels
Subject: How did you deploy SecureSphere?

Hi Erik,

I'd be interested in which part of the deployment you had most problems, and whether an improvement in documentation might have helped.

In Support we see all different types of deployments, and they are reasonably evenly spread across Bridge and Reverse Proxy modes when acting as a WAF. Which is better really depends on your existing architecture, but with the wholesale move to HTTPS, reverse proxy modes, whether transparent or explicit, do have the benefit of offloading the SSL portion of this, and either having the connection to the backend servers in plain HTTP (not ideal of course) or having it use different cipher suites or even TLS version if the backend infrastructure is not easy to upgrade.

For DAM (DB security) use, having agents on the DB nodes is really the only game in town now, with the agents talking to the GW. The major advantage is being able to monitor local DB access too, which is crucial.

I'm sure if you share which aspects of deploying the GW you found least intuitive, others will be along to see if they agree with you.

------------------------------
Stefan Pynappels
Escalation Engineer
Imperva

Original Message:
Sent: 10-21-2019 16:05
From: Erik Segur
Subject: How did you deploy SecureSphere?

When deploying SecureSphere, we had a lot of problems arise when getting the gateways to work. Rather than following the "supported" architecture, it would've been great to learn what the vast majority of other users were doing instead! So I'm curious to learn how other SecureSphere users are deploying or have deployed their product (and architecture)? 


#On-PremisesWAF(formerlySecuresphere)
#AllImperva

------------------------------
Erik Segur
Michigan State University
------------------------------

Hi Erik,

Thanks for elaborating on the difficulties you faced. 
It certainly sounds like your experience is something other (potential) customers could learn from, so thank you for sharing.

Bridge mode is certainly simpler to set up, but there are genuine cases where a Reverse Proxy setup is the only option, especially when working with Elliptic Curve encryption. In cases where there is doubt or confusion, an hour spent discussing what is required with a Sales Engineer or Solutions Architect is often time well spent.

Stefan

------------------------------
Stefan Pynappels
Escalation Engineer
Imperva
------------------------------

Original Message:
Sent: 10-28-2019 10:17
From: Erik Segur
Subject: How did you deploy SecureSphere?

We ended up going with a Reverse Proxy deployment behind a pair of load balancers for our WAF which worked well for about 90% of our apps.  Unfortunately, our more critical and complicated apps didnt work in that environment because at the time the 2MB payload limit wasnt documented and we also had bugs with data chunking and websockets.  These have all since been re mediated and documented but it meant a long and painful roll out where we really weren't sure if SecureSphere would actually work.  When reviewing the architecture at a later date, we found out that a Bridge deployment was much more common and wouldn't have had the same issues in these edge cases.  Having known that up front we would have gone with a bridge deployment and been much more successful.  

We appreciate the partnership that Imperva has had in working through these complicated issues.

Erik

------------------------------
Erik Segur
Michigan State University

Original Message:
Sent: 10-22-2019 14:47
From: Stefan Pynappels
Subject: How did you deploy SecureSphere?

Hi Erik,

I'd be interested in which part of the deployment you had most problems, and whether an improvement in documentation might have helped.

In Support we see all different types of deployments, and they are reasonably evenly spread across Bridge and Reverse Proxy modes when acting as a WAF. Which is better really depends on your existing architecture, but with the wholesale move to HTTPS, reverse proxy modes, whether transparent or explicit, do have the benefit of offloading the SSL portion of this, and either having the connection to the backend servers in plain HTTP (not ideal of course) or having it use different cipher suites or even TLS version if the backend infrastructure is not easy to upgrade.

For DAM (DB security) use, having agents on the DB nodes is really the only game in town now, with the agents talking to the GW. The major advantage is being able to monitor local DB access too, which is crucial.

I'm sure if you share which aspects of deploying the GW you found least intuitive, others will be along to see if they agree with you.

------------------------------
Stefan Pynappels
Escalation Engineer
Imperva

Original Message:
Sent: 10-21-2019 16:05
From: Erik Segur
Subject: How did you deploy SecureSphere?

When deploying SecureSphere, we had a lot of problems arise when getting the gateways to work. Rather than following the "supported" architecture, it would've been great to learn what the vast majority of other users were doing instead! So I'm curious to learn how other SecureSphere users are deploying or have deployed their product (and architecture)? 


#On-PremisesWAF(formerlySecuresphere)
#AllImperva

------------------------------
Erik Segur
Michigan State University
------------------------------

Hi Erik,
 My company runs KRP mode either, I'm having issue connection with websockets application. Would you mind showing me the solution, please?

------------------------------
tu dong
FIS
Hanoi
------------------------------

Original Message:
Sent: 10-28-2019 10:17
From: Erik Segur
Subject: How did you deploy SecureSphere?

We ended up going with a Reverse Proxy deployment behind a pair of load balancers for our WAF which worked well for about 90% of our apps.  Unfortunately, our more critical and complicated apps didnt work in that environment because at the time the 2MB payload limit wasnt documented and we also had bugs with data chunking and websockets.  These have all since been re mediated and documented but it meant a long and painful roll out where we really weren't sure if SecureSphere would actually work.  When reviewing the architecture at a later date, we found out that a Bridge deployment was much more common and wouldn't have had the same issues in these edge cases.  Having known that up front we would have gone with a bridge deployment and been much more successful.  

We appreciate the partnership that Imperva has had in working through these complicated issues.

Erik

------------------------------
Erik Segur
Michigan State University

Original Message:
Sent: 10-22-2019 14:47
From: Stefan Pynappels
Subject: How did you deploy SecureSphere?

Hi Erik,

I'd be interested in which part of the deployment you had most problems, and whether an improvement in documentation might have helped.

In Support we see all different types of deployments, and they are reasonably evenly spread across Bridge and Reverse Proxy modes when acting as a WAF. Which is better really depends on your existing architecture, but with the wholesale move to HTTPS, reverse proxy modes, whether transparent or explicit, do have the benefit of offloading the SSL portion of this, and either having the connection to the backend servers in plain HTTP (not ideal of course) or having it use different cipher suites or even TLS version if the backend infrastructure is not easy to upgrade.

For DAM (DB security) use, having agents on the DB nodes is really the only game in town now, with the agents talking to the GW. The major advantage is being able to monitor local DB access too, which is crucial.

I'm sure if you share which aspects of deploying the GW you found least intuitive, others will be along to see if they agree with you.

------------------------------
Stefan Pynappels
Escalation Engineer
Imperva

Original Message:
Sent: 10-21-2019 16:05
From: Erik Segur
Subject: How did you deploy SecureSphere?

When deploying SecureSphere, we had a lot of problems arise when getting the gateways to work. Rather than following the "supported" architecture, it would've been great to learn what the vast majority of other users were doing instead! So I'm curious to learn how other SecureSphere users are deploying or have deployed their product (and architecture)? 


#On-PremisesWAF(formerlySecuresphere)
#AllImperva

------------------------------
Erik Segur
Michigan State University
------------------------------

Tu Dong,

You likely need to set the WAF up to let the connections through. See pg. 227 in the web admin guide titled "Enabling WebSocket Communication " 

WebSocket is a protocol providing full-duplex communication channels over a single TCP connection. By default,
SecureSphere blocks WebSocket communications.
To enable WebSocket communication:
1. Login to SecureSphere.
In the Main workspace, select Policies > Security. The Security window appears.
2. In the Policies pane, under the Web Service Custom policy group, locate the Websocket Upgrade policy and
click it.
3. Under the Policy Configuration section, clear the Enabled check box.
4. In the Policies pane, under the HTTP Protocol Validation policy group, locate the Web Protocol Policy and click
it.
5. Locate the HTTP WebSocket Violation policy rule and check the Enabled check box.
6. Apply Severity (should be severity of none), Action (should be action of none) and Followed Action values as necessary.

Adam Brown
Rackspace Hosting

------------------------------
Adam Brown
Rackspace Hosting
San Antonio TX
------------------------------

Original Message:
Sent: 03-30-2020 06:28
From: tu dong
Subject: How did you deploy SecureSphere?

Hi Erik,
 My company runs KRP mode either, I'm having issue connection with websockets application. Would you mind showing me the solution, please?

------------------------------
tu dong
FIS
Hanoi

Original Message:
Sent: 10-28-2019 10:17
From: Erik Segur
Subject: How did you deploy SecureSphere?

We ended up going with a Reverse Proxy deployment behind a pair of load balancers for our WAF which worked well for about 90% of our apps.  Unfortunately, our more critical and complicated apps didnt work in that environment because at the time the 2MB payload limit wasnt documented and we also had bugs with data chunking and websockets.  These have all since been re mediated and documented but it meant a long and painful roll out where we really weren't sure if SecureSphere would actually work.  When reviewing the architecture at a later date, we found out that a Bridge deployment was much more common and wouldn't have had the same issues in these edge cases.  Having known that up front we would have gone with a bridge deployment and been much more successful.  

We appreciate the partnership that Imperva has had in working through these complicated issues.

Erik

------------------------------
Erik Segur
Michigan State University

Original Message:
Sent: 10-22-2019 14:47
From: Stefan Pynappels
Subject: How did you deploy SecureSphere?

Hi Erik,

I'd be interested in which part of the deployment you had most problems, and whether an improvement in documentation might have helped.

In Support we see all different types of deployments, and they are reasonably evenly spread across Bridge and Reverse Proxy modes when acting as a WAF. Which is better really depends on your existing architecture, but with the wholesale move to HTTPS, reverse proxy modes, whether transparent or explicit, do have the benefit of offloading the SSL portion of this, and either having the connection to the backend servers in plain HTTP (not ideal of course) or having it use different cipher suites or even TLS version if the backend infrastructure is not easy to upgrade.

For DAM (DB security) use, having agents on the DB nodes is really the only game in town now, with the agents talking to the GW. The major advantage is being able to monitor local DB access too, which is crucial.

I'm sure if you share which aspects of deploying the GW you found least intuitive, others will be along to see if they agree with you.

------------------------------
Stefan Pynappels
Escalation Engineer
Imperva

Original Message:
Sent: 10-21-2019 16:05
From: Erik Segur
Subject: How did you deploy SecureSphere?

When deploying SecureSphere, we had a lot of problems arise when getting the gateways to work. Rather than following the "supported" architecture, it would've been great to learn what the vast majority of other users were doing instead! So I'm curious to learn how other SecureSphere users are deploying or have deployed their product (and architecture)? 


#On-PremisesWAF(formerlySecuresphere)
#AllImperva

------------------------------
Erik Segur
Michigan State University
------------------------------

Erik,

We deploy and maintain a very large fleet of Imperva WAFs for our customer base. The most effective deployments I would recommend are:

• Bridge mode
• Transparent Reverse Proxy (TRP) mode

I would highly recommend staying away from KRP because of the UI design, for KRP is frankly terrible for day-to-day management if you have a large deployment of sites. If your architecture allows for it, choose the other 2 options. If you have development time, it might be easier to get around these issues by designing your own management system.

As for Bridge and TRP mode, I would recommend deployment of the solution behind a strong load balancer to allow for future proofing the solution as it comes to ciphers and protocols with your end clients. Imperva is working on improving the issue with the latest code releases, but they lag behind in on-premises in supporting the latest HTTP and TLS protocols at this point in time. The Cloud WAF due to a different code base has been able to far out pace the on-prem WAF in this department. 

Bridge and TRP mode complement each other as bridge can be run, and then TRP can be turned on if the need arises without re-architecting the entire environment. An example arhitecture would be:

Load balancer - Gateway - Switch

Adam Brown
Rackspace Hosting

------------------------------
Adam Brown
Rackspace Hosting
San Antonio TX
------------------------------

Original Message:
Sent: 10-21-2019 16:05
From: Erik Segur
Subject: How did you deploy SecureSphere?

When deploying SecureSphere, we had a lot of problems arise when getting the gateways to work. Rather than following the "supported" architecture, it would've been great to learn what the vast majority of other users were doing instead! So I'm curious to learn how other SecureSphere users are deploying or have deployed their product (and architecture)? 


#On-PremisesWAF(formerlySecuresphere)
#AllImperva

------------------------------
Erik Segur
Michigan State University
------------------------------