DNS cache poisoning Attack

What is it with ESS and the DNS?? I keep getting this alert on the logs about a DNS cache poisoning attack every 2 to 4 seconds!!!! I have a fixed DNS thru a Home ADSL router so there is no way this is a real attack, at least I had never seen this with Sunbelt/kerio which also has IDS....
Is it a bug? is there any way arround this?? I contacted Eset Support a week ago and I never had an answer!!!!

 

Maybe they're delayed DNS responses.

 

Hello lucas1985

Possibly. But on such a delay, such replies should be seen as unsolicited inbound.

I would be curious as to what this firewall sees as a possible "DNS cache poisoning", I know in the past (from some IDS) that any inbound from remote port 53 to a closed port is seen as this (incorrectly).

If ESS ever allow me to set up this firewall with my own ruleset, I would then test for such problems.

 

Yep, the firewall in ESS does some weird things.

Agreed. A custom ruleset will expose flaws in the SPI, the filtering engine and the interception of normal outbound attempts (not leaktests).

 

Well what ever it is, the real answer should come from Eset, but as I said before it`s been a week since I first saw this and no response from Eset Support yet.

 

Mainly from the posts made I have seen this. My time with ESS as been very limited up to now, due to hard_coded rules.

Any implimentaion of SPI can be checked, regardless of hard_coded rules. Its just my personal choice never to test or use any firewall that forces firewall rules against a user (in this case, a user who will have to pay for this)

I think you will already know, I am not interested in leaktests. Yes, I do run these against the firewalls that place such features. I will also say, that I can see this from both points of view.
For view of a firewall should have such features~
Some will say a firewall should control all comms, so this can imply that any comms made should be intercepted,... these comms are possible via hooks etc/. So this is a case of direct/indirect comms.
For view of a firewall not having this~
I still think, that if an implimentation of "leak" prevention is to be made, then this would need to be system wide (for it to fully work correctly). I prefer to have a stanalone firewall with my own option of a 3rd party HIPS for this.

Of course, this is IMHO.

 

I agree, but as you post onto open forum, then expect replies/comment from members.

 

I'm not concerned about leaktests too. But I think that some tampering protection is needed against commonly used techniques (launching of hidden window of trusted app, launching trusted app with commandline parameters)
I like firewalls which resemble Kerio 2. A firewall should have good SPI, good logging (to audit and/or make rules), speedy filtering, basic and advanced rule making, an OK default ruleset without hard-coded rules, basic leaktest protection, some resistance to termination attempts and basic IDS (abnormal DNS traffic, mass mailing behaviour, etc). Firewalls shouldn't do web filtering, malware scanning (excepting those in a suite) , HIPS-like system control and other superfluous things better suited to other apps.

 

I contacted ESET on a similar firewall log issue a couple months ago. (see post 10 on the following thread)

https://www.wilderssecurity.com/showthread.php?t=183610

Their response to me was to use ethereal and provide them with the data from the communication. I didn't follow through at the time as I have no working knowledge of ethereal.

 

Yes, of course, I'm just saying it would be nice to hear from them on this
I really appreciate your imputs, specially because I'm not an expert and any help is more than wellcome.

 

I think if the firewall is going to have any outgoing application network restrictions at all then it should cover all possible leaktests. I do not expect the firewall to actually control the interprocess communications unless they are directly related to a blocked application trying to use the internet when it is not supposed to.

A good example of this would be the way Comodo's current stable release (2.4?) works in it's simplest mode (if I remember correctly): It simply asks once per application if you want to allow internet access or not and takes care of the rest behind the scenes. I think this would be the absolute best decision for ESET especially when considering how many of their prospects read matousec and firewalleaktester.

I am hoping the SPI in ESET SS will blow the others away

 

Well as a request from Eset Support: (("thank you for your report. Could you please send me a log from Wireshark (http://www.wireshark.org/download.html). It is a network protocol analyzer. Let it run for a short while when the DNS cache poisoning attack appears in ESS, then stop it and save the log in the Wireshark /tcpdump format (default). Thank you." ))

I did capture some packets using wireshark and sent them to Support, now I'm waiting for there answer so ... let's see what's wrong.

 

I have the same problem

I posted a similar post about a month ago and was advised to use ethereal to capture packets as per earlier poster and send them in.

10 mins on google and I was able to download and do what was asked

I never got a response but I never expected to, I just hope they address the problem as I believe this problem is associated with limited LAN connectivity as well.

 

Well I got an answer from Eset, I'll paste it here so there are no mistakes:

"Hello,
thank you for the log. Could you please create a new one with DNS poisoning attack detection turned off - first have a look at the ESS firewall log to be sure that it is constantly filled with DNS poisoning attack messages, then turn the DNS p. a. detection off and run wireshark for a while. According to the existing investigation, it seems that something is wrong with your router, however, from the next log we will be able to obtain more info. Thank you.
Matus Smid"

So seems the problem is not ESS after all, in fact if they can prove that it is my router it would seem that ESS is doing fine with the inbound IDS