Blocking non internet hostname not working

[DanielUK]

Hi,

We have a bunch of (badly configured) machines that are continually trying to do HTTP Connects to a hostname that isn't valid on the internet (something like ec2amaz-h4wk4eu). This is just filling up our global error log with NXNAME failures and presumably tying up sockets on the Wingate server while the connection waits for the DNS timeout so that Wingate can send the client a 504 timeout.

When I try to add a manual classifier with 'ec2amaz-h4wk4eu' as the site name and add it to our 'banned' category Wingate never seems to match/deny these requests. I've tried pattern match with *ec2amaz-h4wk4eu* or adding a '.' to the end (ec2amaz-h4wk4eu.) but still nothing.

Any help on how we can just short circuit the processing of these requests until our developers work out how to stop the process continually make these requests.

Daniel

[adrien]

Hi Daniel

for various reasons (legacy mainly) the way matching works in the manual classifier is slightly different to how it works for the entries in the web access control rules.

We added the functions in the web access control rules later, and it's probably simpler to use those to block these requests.

If you need those computers to do other things and succeed at that, you can't just block them by IP.

Do these computers use proxy auto-detection? If so, you can possibly alter the WPAD.DAT file that WinGate sends back to prevent the clients using the proxy for attempts to this site (in the FindProxyForURL function you could return a direct connection, or proxy that doesn't exist so it fails in the client rather than in WinGate).

Yes, the connections to WinGate will consume sockets. the DNS failure shouldn't really be causing any problems, but the connection will consume a license, which can be a problem if these are in short supply.

But the primary issue seems matching. Did you try adding a site in a new web access rule to deny access to this site?

If using the manual classifier, be careful what you choose to match on. If matching on URL, then the matching will expect to see http://something or https://something. If matching on site, then it doesn't expect to see the http:// and/or https://, and so including or omitting these incorrectly can prevent a match.

Regards

Adrien de Croy