The use of WPAD (or PAC file) is sometimes necessary for pushing the proxy address. As there are several ways to push the WPAD, it can be hard to choose the right way. In this post, I won’t be discussing what the WPAD is, or how it is created, but I will address what the differences are and hopefully, this can be helpful with your implementation decisions.
DHCP and DNS WPAD PROs
Easy to use
Both are easy to configure. DNS WPAD is set by creating an A-record within your domain (containing WPAD or WPAD.domain.local). DHCP WPAD is configured by using option 252 in your DHCP scope.
No alteration needed by the user
If a user is working from home, the user doesn’t have to alter the proxy settings to be able to connect to the internet, as is the case with configuring it manually. This is especially practical when you only use a proxy inside the (company) network.
DHCP and DNS WPAD CONs
Security
Security is becoming more standard in companies as threats are rising day by day. As it is best practice to “layer it up” (like an onion), a proxy can add another layer of defence. Proxies can be used to secure internet gateways for users by blocking certain websites or categories. Some proxies can also scan for malware and viruses and thus creating the extra barrier that we’re looking for, security wise. However, with users also taking their systems home and introducing B.Y.O.D., malware and viruses can be picked up elsewhere, which can then be brought back to the company. By using WPAD only, once a system leaves the network, it will no longer be able to access the proxy and thus it will no longer have that extra security layer.
DHCP WPAD CONs
Application
Most of the applications will share the WPAD settings for the system (or Internet Explorer). However, some applications don’t support DHCP WPAD. For example, if you’re using Mozilla Firefox, you are obligated to move to DNS WPAD, as the application will not work with DHCP WPAD.
DNS WPAD CONs
Security/Vulnerability
There are several vulnerabilities with the WPAD (one which is explained above), especially when using DNS WPAD. This is due to the way DNS WPAD works. Below is an example of how this vulnerability could be exploited.
As you need to know how DNS WPAD works for the exploit to work, here is a small summary:
First of all, the application will try to resolve “WPAD”. When this doesn’t result in a reply, it will try to resolve WPAD.domain.suffix, when that doesn’t work, it will move to WPAD.subdomain.domain.suffix, and so forth and so on.
It could happen that you’re using a different domain internally (e.g. domain.local) and the client, for some reason, resolves this with a public name server, instead of your local DNS. A person with malicious intentions could register this domain. He or she could send the WPAD.domain.local to a malicious server, and that way could look into all web traffic or redirect sites to a malicious page that will install malicious software.
Personal preference
Personally, I’d prefer an in-line deployment of the proxy, so the user (and/or system admin) doesn’t have to alter anything within the system. This way, you won’t have to use the WPAD option. Everything will be sent to the proxy anyway and there are no issues with applications that don’t support WPAD. Furthermore, users are less able to bypass the proxy altogether (and with that, are less likely to download viruses or malware).
Another option is to move to a next-gen firewall that has URL filtering and anti-malware and file-scanning capabilities, especially when you’re using the same vendor for the proxy and the firewall. However, you might want them both, if they are using different scanning techniques or engines.
Ofcource, this will not solve the issue with users that work from home or elsewhere, but you’ll have to take privacy into consideration when thinking about securing that. If you’re still looking for a solution and want to proxy traffic everywhere, you might want to look into a cloud solution.
