Grateful for any help with understanding these entries from my firewall log: I have the DNS client service running, and my DNS rules allow bidirectional UDP connections between svchost.exe and my ISP's two DNS servers on remote port 53. The blocked UDP connections in the log came from those DNS servers, and all within a six-second timespan. If I've got this right, then with the DNS client service, all DNS lookups are handled by svchost, so why the attempt to connect to Proxomitron? I checked my event log to see if the service had stopped running (I would guess that's unlikely), but no sign of that. I can't see that this has any security implications - after all, AFAIK I could disable the DNS client service and then individual applications would do DNS lookups themselves, rather than everything going through svchost - but I'm curious as to why it happened.
Why not just let any app send a UDP out port 53 to your dns servers since any app can access the dns service? What you are doing is not tightening up your security at all. As long as an app connects to only YOUR dns servers, that is what you want to happen. However, if you have a hijack which changes your dns servers and messes it up so all of the sites you type in(like www.google.com) will go to malware sites. So just specify only to your dns servers. On the log issue, Proxo must be trying its own lookups or might be filtering something. Alphalutra1
The most likely cause is that your ISP DNS servers were just running slow and gave a late reply. When this happens, your PC will query the secondary DNS server - your firewall may either notice this and block any subsequent reply from the first, or it may apply a general timeout value for UDP traffic blocking anything after a set time period. As for allowing any application DNS access, I would advise against this since it could be abused by the DNSTester leaktest and malware using similar technqiues (making a recursive DNS query which involves using your ISP's DNS servers to relay information to the attacker's system). Restricting DNS access to trusted applications only will prevent this.
Thanks Paranoid2000. I see in your Outpost guide that you present as one option disabling the DNS client service, and creating DNS rules for individual applications. I still don't understand why the DNS servers (the blocked inbound connections came from both of them) tried to contact Proxomitron. The DNS query would have been sent out by svchost, so wouldn't the reply have been sent to the local ports though which svchost communicates with those servers - regardless of the fact that it came late? I'm assuming that with the DNS client service running, svchost is the only application that makes DNS queries. Is that correct? Under my firewall rules it's the only application that's allowed UDP communications with the DNS servers. The rules would however have allowed Proxomitron to send TCP packets to those servers, but what I've read suggests that the use of TCP for DNS queries is rarer than hen's teeth. It might be helpful if I post my ruleset: As you can see, my outbound rules are on the lenient side. Alphaultra1 - thanks for your input, I know what you're saying, but I'm interested in learning how this works.
Here, Kerio uses TCP occasionally, so I've set up a rule for it: See: DNS over TCP Other uses: DNS uses both UDP and TCP to send messages "Key Concept:.. Conventional message exchanges are "short and sweet" and thus well-suited to the use of the very fast UDP; DNS itself handles the detection and retransmission of lost requests. For larger or more important exchanges of information, especially zone transfers, TCP is used—both for its reliability and its ability to handle messages of any size."
Yes, if the reply was for a request made by svchost, then it specify svchost's port (typically 1025). In your case, you need to check outgoing traffic from that local port to see if Proxomitron itself made a DNS request and, if so, what rule allowed it. Normally yes, but it seems at least theoretically possible for applications to "go their own way" and make DNS requests directly. I don't know enough about Windows' DNS Client Service to be any more specific than this since I never use it. That does not appear to be a complete rules list - nothing is listed for Proxomitron which would suggest that it could only access the Internet if it were able to use your P2P software as a web proxy.
I'm afraid that is my complete ruleset - the rule that allows Proxomitron access is the 'allow outbound' rule, second up from the bottom. *sheepish grin* I've been doing some more logging, which shows that svchost communicates with the DNS servers through random ephemeral ports; I've logged 1034, 1054, 1080, 1086, 1168, 1170, etc. Thanks for the links, Rmus. It looks like the only possible explanation for the log entries I posted is that when my computer wanted to use TCP for the DNS lookup, it used the process that initiated the DNS client service - in this case Proxomitron - rather than svchost. There may also have been TCP DNS requests from svchost; my ruleset already enabled the TCP connections you allow in your second 'Permit DNS' rule. I've looked through the Microsoft knowledge base to try and find out why the DNS client service would have used a process other than svchost, but haven't found anything, although I'm sure the information is in there somewhere. I've added some more rules to my ruleset; they don't permit anything new, but are purely for logging. It may take a few days to get any results. Thanks again, people.
The "allow outbound" at the bottom seems a bit permissive, IMO. You lose the feature of the firewall to control/alert you as to what is connecting out. Instead of trying to guess - why not remove that rule and let Kerio prompt for your outbound attempts. You can create each rule as you are prompted. That's how I created the TCP rule for DNS. Then you will know what is needed for all outbound connections, including Proxomitron. This would include your applications - browser, email, etc. Then you are in more control of what ports/addresses are permitted, etc.
That rule does not cover UDP which DNS uses so it should not be permitting such access. That is normal - any application that wants to send data out will have a port dynamicly assigned to it by Windows. The traffic in question is UDP, not TCP.
With my rules, the only way Proxomitron could have contacted the DNS servers would have been by using TCP. The log entries indicate that the servers tried to reply using UDP. Rmus's rules suggest the same: queries can be sent out using TCP, with UDP replies received. I can't see how else to interpret this; are there other possible explanations I'm missing?
TCP is a connection-orientated protocol - if a query is sent using it, then a reply would be made using the same connection (which would not show as a separate log entry on most firewalls). UDP is connectionless - there is nothing to link a reply with the query (though a firewall can infer this from other data) therefore a late reply using UDP will often be logged as a separate entry. This should never occur and would be completely non-standard behaviour for any DNS server. What is far more plausible is one of the following: Proxomitron did send a UDP query (if you checked your logs for outgoing traffic from local port 1414 as suggested above, then this should serve to confirm or disprove it); another application sent out a query on that port (ports can be shared or the application could have released the port allowing it to be reassigned to Proxomitron); Kerio has misreported traffic, either due to a bug or a conflict with other software; someone else sent a spoofed query using your IP address, causing the DNS server to send an unsolicited response back to you. Log entries should be present for the first 2 options while the last 2 would require further investigation perhaps including the use of a packet sniffer, should you consider it important enough to spend more time on this.
I understand now. I should have realised that. Thank you for setting out the options; that's helpful. I noted your earlier remark about checking the log; unfortunately that's not available, as at the time I'd only enabled logging for two rules in the set - the DNS alert and the final rule blocking all other outbound connections. Thanks again for your time.
