Address temporarily blocked by active defense (IDS)

Can someone explain to me what is going on with this. Since upgrading to ESET 5 I've had issues connecting to my SQL Server on my local network. I've been through rules until I'm blue in the face, but all looks good. I'm set to interactive mode, so I'd presume I should get prompted before the address is blocked. Anyway, today I did a bit more research and spotted the following in the logs, which I must admit I hadn't realised were disabled by default:

<?xml version="1.0" encoding="utf-8" ?>
<ESET>
<LOG>
<RECORD>
<COLUMN NAME="Time">
<DATE>05/11/2012</DATE>
<TIME>17:48:56</TIME>
</COLUMN>
<COLUMN NAME="Event">Address temporarily blocked by active defense (IDS)</COLUMN>
<COLUMN NAME="Source">192.168.200.10:54415</COLUMN>
<COLUMN NAME="Target">192.168.200.2:1433</COLUMN>
<COLUMN NAME="Protocol">TCP</COLUMN>
<COLUMN NAME="Rule/worm name"></COLUMN>
<COLUMN NAME="Application"></COLUMN>
<COLUMN NAME="User"></COLUMN>
</RECORD>
</LOG>
</ESET>

I've now found the workaround, to add my server to the exclude from IDS zone, but I'd really like to understand what it happening here, as it's been a serious irritation for some time. Why is an outgoing connection I've explicitly enabled being blocked without any indication? Surely if I've specifically added a rule for this server, port and application then that should override anything like this

At the very least it would be useful if the log explained why it thought this was a threat!

Kev

 

It's necessary to see the recent firewall records for the last 5-10 minutes. Copy the recent records and copy & paste them here. There must have been an attack detected which caused all subsequent communication to get blocked.

 

Hmm, not sure I had logging switched on for long enough before that - I'd spotted the reference to this and switched logging off blocked connections on long enough to see what was happening. Looking at the logs though, I do see a port scanning attack being reported. The source is my server though, and as far as I can tell this is coming from the DNS service on my server (192.168.200.2) - 5355 is the LLMNR protocol...

I've added the server to the IDS exemption list now, but I'm a bit loathe to do so, and I'd sooner be a bit more precise in what is blocked - who's to say that the server might not be compromised at some point, after all?

Here's a chunk of the log - had to cut it down a bit as it was flagged as too complex to post:

<?xml version="1.0" encoding="utf-8" ?>
<ESET>
<LOG>
<RECORD>
<COLUMN NAME="Time">
<DATE>05/11/2012</DATE>
<TIME>17:43:22</TIME>
</COLUMN>
<COLUMN NAME="Event">Address temporarily blocked by active defense (IDS)</COLUMN>
<COLUMN NAME="Source">192.168.200.10:54215</COLUMN>
<COLUMN NAME="Target">192.168.200.2:1433</COLUMN>
<COLUMN NAME="Protocol">TCP</COLUMN>
<COLUMN NAME="Rule/worm name"></COLUMN>
<COLUMN NAME="Application"></COLUMN>
<COLUMN NAME="User"></COLUMN>
</RECORD>
<RECORD>
<COLUMN NAME="Time">
<DATE>05/11/2012</DATE>
<TIME>17:43:22</TIME>
</COLUMN>
<COLUMN NAME="Event">Address temporarily blocked by active defense (IDS)</COLUMN>
<COLUMN NAME="Source">192.168.200.10:54213</COLUMN>
<COLUMN NAME="Target">192.168.200.2:30888</COLUMN>
<COLUMN NAME="Protocol">TCP</COLUMN>
<COLUMN NAME="Rule/worm name"></COLUMN>
<COLUMN NAME="Application"></COLUMN>
<COLUMN NAME="User"></COLUMN>
</RECORD>
<RECORD>
<COLUMN NAME="Time">
<DATE>05/11/2012</DATE>
<TIME>17:40:19</TIME>
</COLUMN>
<COLUMN NAME="Event">Detected Port Scanning attack</COLUMN>
<COLUMN NAME="Source">192.168.200.2:5355</COLUMN>
<COLUMN NAME="Target">192.168.200.10:54534</COLUMN>
<COLUMN NAME="Protocol">UDP</COLUMN>
<COLUMN NAME="Rule/worm name"></COLUMN>
<COLUMN NAME="Application"></COLUMN>
<COLUMN NAME="User"></COLUMN>
</RECORD>
</LOG>
</ESET>

 

Most likely you don't have LLMNR allowed in the Trusted zone (check the IDS settings) or the server with the IP address 192.168.200.2 is not in the Trusted zone. Shouldn't that be the case, simply add the IP address 192.168.200.2 to the list of addresses excluded from active protection in the zone setup.

 

Ah, hadn't seen the LLMNR setting in the IDS settings, thanks. That ought to sort it. I think Eset could be a bit more proactive about notifying the console user that something is being blocked and why, in this case. Had me scratching my head for ages, and mucking about with rules and what not.

Kev