question about rule 2002 Web Application Attach

carboncow · 11-10-2011, 08:34 AM

We have developed a new PHP based website (custom code from them and it's not Joomla or any other open source...) with our development company and we noted photos were not get pushed to test server. This had everyone scratching their heads as it worked on their side and at remote locations, so I looked at the firewall. Found out turning off Intrusion Prevention solved our need and thus went into the log...to find the rule taking issue with the code.

By turning off rule 2002 "Web Application Attach (remote include path)" we now have a functionality beta site.

Question:

1. I believe this was a default rule...does turning off this one rule leave us vulnerable for anything really common out there?
2. Does anyone have an inkling why this is getting triggered as the coders are scratching their heads at the moment since our "old" site didn't have this issue. I understand you guys don't know their code but was hoping there is a common error on their side or bug on the rule side that is known.
3. Any other comments would be appreciated including saying "just turn it off" and don't worry about it! Then again I'd assume the default rules are "on" for a reason!

Thanks.
Shawn

sky-knight · 11-10-2011, 08:37 AM

Intrusion Prevention generates false positives... That's just the way that it is.

I wouldn't say you're doing anything wrong unless that module you're playing with is in your default rack.

carboncow · 11-10-2011, 08:39 AM

Quote:

Originally Posted by sky-knight

Intrusion Prevention generates false positives... That's just the way that it is.

I wouldn't say you're doing anything wrong unless that module you're playing with is in your default rack.

SK, thanks I figured FP were posible as I'm not looking through the log and seeing some other 'interesting" things that should not be a concern on our end.

This is a default rule in the default rack setup, so I'm not sure what you are stating with your last sentence.

sky-knight · 11-10-2011, 08:42 AM

I'm saying that if you're forwarding TCP 80 or TCP 443 to a web server that is accessed publicly AND you haven't defined a policy to route that traffic into a rack specifically configured to handle it.

YOU ARE DOING IT WRONG!

Just wait until your AV modules get ahold of all that general traffic... build some actual traffic going to that server. And you're using UT to protect the world from your own web content.

Nothing, in my experience brings a UT to its knees faster.

carboncow · 11-10-2011, 08:48 AM

I understand you now...I think. You mean a physical rack then.

The webserver we are having issues with (in regard to this rule) is external to our firewall and hosted with RackSpace via our development company. So if I'm understanding your point we are not doing anything wrong.

sky-knight · 11-10-2011, 09:35 AM

No, I mean virtual rack within Untangle.

If you have an Untangle server protecting a production web server you have to be very careful what defenses you put in place. Untangle's rack modules aren't directional, they will scan whatever traffic transits the server. So if you put a UT server in front of a web server, unless Untangle is specifically configured otherwise, the web traffic terminating on the web server is subject to the Untangle filters.

This is very bad... very very bad. It leads to UTs randomly falling over at odd times. It takes a BEAST of a box to be able to forward TCP 80 through the default rack and not fall over.

Just think about it, each and every web request hitting that server... going through the web filter, av modules, etc.

However if your UT isn't between the web server and the world then this conversation in your case is purely academic.

In your case I'd simply suggest bypassing traffic bound for your web resource. Why scan it? Do you not trust your own server?

miw · 11-16-2011, 07:00 AM

A different approach is to create a new UT rack and have the incoming traffic still subject to the Firewall, Intrusion Prevention, and Attack Blocker. By configuring it that way incoming web traffic will not be subject to all of UTs modules - consequently not hitting your unit as hard while still ensuring inbound TCP 80 and 443 traffic is monitored and controlled according to your firewall, IPS, and Attack Blocker. Additionally, this allows you to monitor incoming web traffic and serves as another form of web server log.

11-10-2011, 08:37 AM	#2 (permalink)
sky-knight Join Date: Apr 2008 Location: Phoenix, AZ URLs submitted: 8 Posts: 15,457	Intrusion Prevention generates false positives... That's just the way that it is. I wouldn't say you're doing anything wrong unless that module you're playing with is in your default rack. __________________ Rob Sandling, BS:SWE, MCP Intouch Technology Phone: 480-272-9889 rob@intouchtechllc.com UntangleAppliances.com Phone: 866-794-8879

11-10-2011, 08:42 AM	#4 (permalink)
sky-knight Join Date: Apr 2008 Location: Phoenix, AZ URLs submitted: 8 Posts: 15,457	I'm saying that if you're forwarding TCP 80 or TCP 443 to a web server that is accessed publicly AND you haven't defined a policy to route that traffic into a rack specifically configured to handle it. YOU ARE DOING IT WRONG! Just wait until your AV modules get ahold of all that general traffic... build some actual traffic going to that server. And you're using UT to protect the world from your own web content. Nothing, in my experience brings a UT to its knees faster. __________________ Rob Sandling, BS:SWE, MCP Intouch Technology Phone: 480-272-9889 rob@intouchtechllc.com UntangleAppliances.com Phone: 866-794-8879

11-10-2011, 09:35 AM	#6 (permalink)
sky-knight Join Date: Apr 2008 Location: Phoenix, AZ URLs submitted: 8 Posts: 15,457	No, I mean virtual rack within Untangle. If you have an Untangle server protecting a production web server you have to be very careful what defenses you put in place. Untangle's rack modules aren't directional, they will scan whatever traffic transits the server. So if you put a UT server in front of a web server, unless Untangle is specifically configured otherwise, the web traffic terminating on the web server is subject to the Untangle filters. This is very bad... very very bad. It leads to UTs randomly falling over at odd times. It takes a BEAST of a box to be able to forward TCP 80 through the default rack and not fall over. Just think about it, each and every web request hitting that server... going through the web filter, av modules, etc. However if your UT isn't between the web server and the world then this conversation in your case is purely academic. In your case I'd simply suggest bypassing traffic bound for your web resource. Why scan it? Do you not trust your own server? __________________ Rob Sandling, BS:SWE, MCP Intouch Technology Phone: 480-272-9889 rob@intouchtechllc.com UntangleAppliances.com Phone: 866-794-8879

Protect

Filter

Perform

Connect

Manage

Add-Ons

11-10-2011, 08:48 AM	#5 (permalink)
carboncow Untangler Join Date: Aug 2011 Location: Central Ohio Posts: 94	I understand you now...I think. You mean a physical rack then. The webserver we are having issues with (in regard to this rule) is external to our firewall and hosted with RackSpace via our development company. So if I'm understanding your point we are not doing anything wrong.

11-16-2011, 07:00 AM	#7 (permalink)
miw Untangler Join Date: Jun 2008 Posts: 32	A different approach is to create a new UT rack and have the incoming traffic still subject to the Firewall, Intrusion Prevention, and Attack Blocker. By configuring it that way incoming web traffic will not be subject to all of UTs modules - consequently not hitting your unit as hard while still ensuring inbound TCP 80 and 443 traffic is monitored and controlled according to your firewall, IPS, and Attack Blocker. Additionally, this allows you to monitor incoming web traffic and serves as another form of web server log.