Rules for Internal Web Server Clarification

[MrBryce2000]

Greetings,

I am planning to enable the Threat Prevention app for one of my schools, however the testing I did first revealed that the IPs of some residential connections were randomly being blocked from the websites that are hosted on-prem. I asked this question during a Brighttalk webinar about Threat Prevention, and two rules were shown to create: using the public IP as both the destination and source address. This is a problem since the public IP is the address of my External interface.

If I pass traffic to and from that IP, then won't I essentially nullify Threat Prevention? Should I instead use the internal IPs of these servers? Or should I use the HTTP Hostname variable and enter in the domain of the website that my servers are hosting?

Thank you for your advice!

[sky-knight]

Yes, and that's exactly what you should be doing and yes you're turning that module off. Threat Prevention is not designed to defend hosted assets, it's designed to protect clients.

The only modules you should have inspecting ingress web traffic is firewall, and perhaps intrusion prevention... anything else and you will have problems.

Your hosted asset should be defending itself, if it's not nothing you do otherwise will make up for that. If it's vulnerable, VPN it.

[MrBryce2000]

Thank you for your reply, however why use Threat Prevention at all if I have to pass the IP of my external interface?

I do have an IP alias added for a second server, which allowed me to create these rules using that public IP. It is starting to look like I will need to do the same for my primary web server and update the domain to point to an additional alias.

And yes, I use firewalls on my servers. I even use a reverse proxy for my on-prem web servers.

[sky-knight]

None of that is relavant, you're attempting to use a module to defend the world from your server. It's simply not doing what you think it's doing.

All hosted assets should be Policy Ruled into a dedicated Policy with a very curated list of modules. Fail to do this at your own peril.

[MrBryce2000]

I don't know if you're just having a bad day or something, sky-knight, because you used to not respond in this manner. Please know that I have used Untangle in complex environments for many years. I am not new at this.

I want to use Threat Protection as it is intended, to protect my clients. However I need to make sure it doesn't interfere with critical services that this school has to run for the students on-site and remote.

You did, though, give me an idea. I am over thinking this. I already have a Server policy. I will just install Threat Prevention in the default policy, then add it to my server policy and disable it. That will be the simplest solution without having to worry about pass rules.

[sky-knight]

Yep! I'm not being short... so I'm not sure where that's coming from. It is Friday though... and the Windows Updates this week haven't been kind so perhaps there some sort of bleed over happening here.

My point still stands though, you don't want Threat Prevention monitoring ingress connections from the world to ANYTHING. Every residential IP on the planet has crap reputation, if you put it there it's going to start blocking everyone.

That module must only be used for EGRESS traffic, stuff leaving your network. Your clients, getting at the world. If you have an Untangle in a place where it's protecting such clients, against a web service you own somewhere else... bypass traffic destined to your own web server. But that should be an easily manageable short list of special cases.

Don't even port forward to enable a game server without bypassing it first if you only have 1 policy and Threat Prevention is in it...

That is unless you want your Minecraft buddies to be randomly booted.

I think... you know how I learned this...