Active Directory Servers and SOCKS 5 blocking

[KevinM]

Worried. This one could cause me some seroius AD/DNS issues.

I am on a fully-meshed network, 7 offices, 1 point of ingress/egress to the Internet which is handled by a firewall at that point.

Currently however, I've got Untangle 5.4 in bridging mode sitting behind my router and in front of my switch in just one office, the one I reside in, to do some testing and not subject the entire organization to the testing. About 65 nodes here.

Anyhow, it's all been going pretty well for me. Because of the web blocking, I noted a few users then attempting to hit proxy sites with the intent of getting around the web filtering I've put in place with Untangle. So I implemented Protocol Control, and have chosen to log/block a number of services, including all IM protocols listed, and of course, SOCKS 5 I've also chosen to log/block.

So, I immediately busted a few of these clowns who were using proxies to get to their servers on :80. However, as I said, I have 7 offices, and AD/DNS servers in each which need to replicate to each other, etc, as we're all one domain.

The problem: I'm seeing one of my AD servers in my local office, behind Untangle, being "blocked in block list" for all sorts of communications. I see one attempt for 172.16.8.4 (AD/DNS server behind Untangle) that was blocked to another AD/DNS server in another office on 1025, presumably for replication (BAD NEWS!). This particular server also performs DNS lookups for external sites via port 53, and I'm seeing the same behavior for a few of these attempts, "blocked in block list".

I figured the first thing I'd do is just eliminate that particular IP (172.16.8.4) from the list, give it a "pass", whitelist it, etc, and sort it out later. However, there seems to be no way to do this, and as a result I'm VERY concerned that this is going to escalate and cause some replication issues.

To top it off, this particular AD/DNS server happens to hold the FSMO roles for all the domain controllers throughout the organization.

I'm also seeing one of my application servers (hosts most print queues and also hosts my Insight Manager, and SNMP monitoring program for HP) getting "blocked in block list" when attempting to talk to other servers, on the local subnet, on port 161.

Any ideas, help? I don't want to turn off SOCKS 5 blocking, because it's working great and it really shoudln't be blocking legitimate AD/DNS traffic and legit SNMP traffic.

I'm stuck and thoroughly confused at this point about why it would be catching any of this legit traffic as SOCKS 5 and block it. Any assistance would be greatly appreciated!

Thanks,
K

[sky-knight]

I'm afraid the answer is to not block SOCKS5. I've tried to get around this one myself but you quickly learn that the process of identifying SOCKS5 traffic in the way the protocol control module does it frequently hits false positives.

Then there are other cases where it is working correctly with unforeseen consequences... For example, yahoo.com's login page uses SOCKS5 on the back end. So if you turn on that block, none if your users can get into the customized portions of yahoo.

[KevinM]

Heya sky-knight,

Thanks for the prompt response! I had a feeling that would be the actual solution, at least at this point in time. For now I've turned off blocking and just implemented logging. At least this way I have a record of the offenders, evidence of "intent" to violate policy and circumvent processes intended to protect the network, and can throw these guys under the bus with that data if they continue their blatant disrespect and violations.

Do you suppose it's a "bug" per se that developers could work on, or do you know enough about it at this point that "it is what it is, and there's no way to improve on the detection and determination between valid and invalid blocks"? Interesting note on yahoo.com too. Who'da thunk it? For my environment, fortunately I can tell these guys "tough s**t, save your yahoo.com login for your OWN network.", but I understand that's just one example and it could just as easily be a project management site they need to log into or something else, so, blocking is now off and it's just logging. :(

Thanks again, I really appreciate the assist and quick reply!

K

[sky-knight]

To be honest I'm not sure if any improvement is possible in the current mechanism. I can say that I'm completely clueless when it comes to regular expressions. I am, however, annoyingly aware of the difficulties in separating SOCKS5 traffic from HTTP on the wire...

There is an alternate solution if you're willing to make the jump...

If you have purchased the policy manager you can create new virtual racks within your untangle configuration. With a second rack you could configure it to not have the protocol control rules that are giving you grief. Then, using a custom policy you can route traffic into the alternate rack based on the IP address of the system. Given the major problems you're having are with the DCs on your network, those units I'm assuming all have static addresses. ;) This way you can impose the SOCKS5 block on the clients of your network while freeing the servers of the limitation. Also, for that matter you can use another policy rule to reroute only traffic destined for a particular IP to go through the same alternate rack. Giving you the ability to enable that project management site as well.

[KevinM]

Brilliant!!! Just one more bullet in my clip when I go in to sell this product to the "powers that be" here!

That sounds like a perfect solution, and indeed, all the DCs IP stacks are statically assigned, so this solution would do the trick without "kludging" it together.

Thanks for the input and the great suggestion! I'm going to spend some time today and put this together, I'll let ya know how I fare!

Thanks again sky-knight, MUCH appreciated!

K

[sky-knight]

I forgot..

Given you're running an AD environment I should also point out with the AD integration script running you can use the AD username as a criteria for policies... meaning you can have different racks based on username. Unfortunately, it doesn't work with groups... so with your environment's size that feature may or may not have value.