Using ASM in a forward-http proxy scenario?

I have never done this but I find the idea very interesting.

 

 

So first off I think the only thing you will want to enable in ASM is Attack Signatures because almost everything else is really designed solely for reverse proxy. Within the Attack Signatures you then need to figure out which signatures sets you want to use or if you want to use all of them. Then you need think about if you just want to log/alert on tripped signatures or if you want to hard block people. If your goal is to eventually hard block, I would plan on doing a lengthy staging period for the signatures because I am going to guess you are going to see some false positives here and there.

 

 

Another thing to consider is SSL and how to handle that, are you going to just ignore that traffic or will you be doing a man in the middle with the ASM?

 

 

Those are my initial thoughts on this, post back how this goes as I am sure other would interested to hear as well.

 

 

Mike

Hi Mikand,

 

What would be the the problem you are trying to solve with this kind of setup?

 

You mentioned that you would like to protect the client, which specific client attacks you are concerned about?

 

ASM, like you said is designed to protect the servers. In my opinion, ASM wouldn't be an effective tool to protect the client.

Ido,

 

I don't know what Mikand's original need for this is, however the thought that popped into my head when I first read this was as a use to find infected/owned clients on your network. Obviously as you said that is not what ASM is geared for and there are other products out there in the market that will be more effective in doing this sort of work. I would never purchase ASM for this purpose, but if I already had ASM licensed on a device I was doing load balancing for some proxy servers it might be an interesting use of the Attack Signatures in the product. What are you thoughts about that?

The short answer to Ido's question is: because I can :-)

 

 

In this particular setup I will use F5 devices which will also be loaded with the ASM-module (for other reasons) so I thought "hey, why not also inspect client-traffic?".

 

 

Of course there are other devices that deep inspect the traffic on the road (idp, antispyware, antivirus etc) but anything that doesnt bring (major) impact negatively on the performance and can (in total) bring a better hitrate regarding protecting the clients (but also protect rest of the world from the clients :-) is of interrest in my case.

 

 

Regarding the SSL question im thinking of SSL-terminate both in the F5 and in the application firewall which sit behind the forward-http proxies (from the F5 point of view). Not only in order to be able to use ASM on the flows but also to be able to use oneconnect for the SSL traffic (but this will be investigated further - some docs says oneconnect with /32-mask should work when SSL-termination is being used in F5, others says it doesnt).

 

 

The particular setup uses two vservers: VS_FORWARD-HTTP and VS_FORWARD-HTTPS along with a oneconnect profile set to /32-mask (so even if the client uses lets say 10 connections towards the VS_FORWARD-HTTPS ip the idea is that only a single tcp-session (per client) will reach the forward-http proxy which the traffic loadbalances to).

 

 

And since F5 is a FPGA platform (if we take VIPRION 2400 as example) I assume that the performance impact enabling ASM wont be that large compared to if one does this on a x86 based platform?

 

 

I also hope that F5 in future will expand the IDP capabilities so this test is simply if this can be done and how well it works (both in quality but also performance).

Hey Mike,

 

This would be a bit of a stretch but yes, potentialy one could detect internal clients that are being used used to launch application layer attacks over HTTP.

It seems that settng a http profile and later a http class (to connect to the ASM) works fine in the VS_FORWARD-HTTP but not for the VS_FORWARD-HTTPS.

 

 

It seems that the http profile doesnt support CONNECT which is the command used in "SSL Proxy" situations (SSL Proxy is the setting used in the webbrowser which is pointed towards the ip:port for the VS_FORWARD-HTTPS). Since http profile doesnt work it also means that the http class (which connects to ASM) doesnt work either along with analytics (AVR) :-(

 

 

Any ideas on how to modify the http profile so it will support CONNECT?

 

 

The effect is that the F5 sends FIN-ACK as soon as it gets a CONNECT cmd (and not forward the traffic to the https-proxy server).

 

 

The difference between the two cases (regarding what the client sends):

 

 

forward http-proxy:

 

 

GET http://www.example.com:80/

 

 

forward https-proxy:

 

 

CONNECT https://www.example.com:443/

I have posted a test-setup in http://devcentral.f5.com/Community/GroupDetails/tabid/1082223/asg/52/aft/1171329/showtab/groupforums/Default.aspx (OneConnect and Proxy/Squid Load Balancing) in case someone is interrested in taking a look at the https problem :-)

Mikand hi,

 

 

How did your test go on the ASM protecting the proxy server? I have the same problem. My proxy servers are being attacked both from client side and WWW side.Currently hitting about 80% performance impact. I'm thinking of ASM to protect from L4 to L7 attacks.