BUG: ESS firewall mistakes file sharing as an intrusion

Discussion in 'ESET Smart Security' started by mauricev, Sep 14, 2009.

Thread Status:
Not open for further replies.
  1. mauricev

    mauricev Registered Member

    Joined:
    Apr 15, 2008
    Posts:
    43
    On a client, 129.98.90.137, trying to be a file server, ESS complains

    Code:
    9/9/2009 6:20:41 PM	Packet blocked by active defense (IDS)	129.98.90.11:139	129.98.90.137:1036	TCP			
    
    9/9/2009 6:18:41 PM	Packet blocked by active defense (IDS)	129.98.90.11:139	129.98.90.137:1036	TCP			
    
    9/9/2009 6:16:56 PM	Packet blocked by active defense (IDS)	129.98.90.44:139	129.98.90.137:1158	TCP			
    
    9/9/2009 6:16:56 PM	Packet blocked by active defense (IDS)	129.98.90.177:139	129.98.90.137:1160	TCP	
    
    9/9/2009 6:10:10 PM	Packet blocked by active defense (IDS)	129.98.90.168:445	129.98.90.137:1155	TCP
    Tech support advised me to turn off tcp port scanning, which works.

    tcp_port_scanning_attack.jpg

    But why? Shouldn't these ports, 139 and 445 be allowed in the trusted zone due to

    1) a custom rule to allow all TCP/UDP in both directions for the trusted zone, which includes the 129.98.90.x subnet.

    2) an internal rule to "allow file and printer sharing in the Trusted zone"
    filesharingrule.jpg
     
  2. WayneP

    WayneP Support Specialist

    Joined:
    Apr 9, 2009
    Posts:
    339
    Hello mauricev,

    Many users do not see this type of false attack detection. Sometimes older hardware or drivers can cause the ESET firewall to see regular traffic as a possible attack. Try upgrading the network drivers on your machines to see if these stop showing up in the firewall log. I would also suggest upgrading the firmware on your router for the same reason.
     
  3. mauricev

    mauricev Registered Member

    Joined:
    Apr 15, 2008
    Posts:
    43
    Thank you for your response. Are you trying to suggest that the NIC driver is going to alter Ethernet packets? The NIC driver should be operating at layer one (e.g, MAC) and we're talking layer three. And there is no routing involved; we're on one subnet. While I don't know why everyone is not seeing the same problem, I'm very skeptical of your explanation. A bug in the firewall module makes more sense to me.
     
  4. robis

    robis Registered Member

    Joined:
    Mar 21, 2009
    Posts:
    149
    ESET not supporting or not garanting functionality for older LAN drivers? I have 2 years old computer with latest drivers but same problem.
    I think system requirements are:
    OS
    memory: 48MB
    disk space 32 and 46MB
    CPU: Intel or AMD
    there is not record with older drivers (what is for you older? as I type 2 years old PC P35 chipset and latest drivers)

    From my opinion functionality is BUGgy. ESET wrong evaluating what attack is or not. But of course you may tell "TURN OFF" this functionality. If you buy car with climatization and clima will be broken. Ofcourse Car seller tell you "TURN OFF". But ESET is not Car seller :)

    Not everyone I have same problem.

    checked tcp port scanning - logging
    unchecked tcp port scanning - not logging (but problem is still there but ESET didnt see problem - no logs no problem )

    I suggest you unchecking this scanning. If you want to solve it I think that you will be fighting with wind mils :) .
     
    Last edited: Sep 17, 2009
  5. cham

    cham Registered Member

    Joined:
    Feb 27, 2008
    Posts:
    9
    Same problem here, neighter homegroup nor folder sharing in win7 64bit is working with ESET (newest version)
     
  6. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
     
  7. mauricev

    mauricev Registered Member

    Joined:
    Apr 15, 2008
    Posts:
    43
    Thanks for your reply, but this looks to me like another red herring. There is no port scan attack. There are no routers involved. This is file sharing being wrongly detected by NOD32 as an attack. It's a bug in your firewall code.
     
  8. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    So please create 2 logs with the network communication captured using Wireshark; one with firewall enabled when sharing is blocked and one with firewall disabled when it works fine. Make sure that you have "Log all blocked connections" enabled in the IDS section of the firewall setup when reproducing the problem.

    Finally put the stuff in one package together with a log from SysInspector, your ESS configuration as well as the firewall log exported to a text file. Let me know when done so that I can provide you further instructions.
     
  9. mauricev

    mauricev Registered Member

    Joined:
    Apr 15, 2008
    Posts:
    43
    I installed wireshark and turned off the firewall and rebooted. Then I ran wireshark for the first test and then turned the firewall back on and rebooted to prepare for the second test. But on reboot, the network stack got stuck, no packets could get in. I uninstalled wireshark and NOD32 and reinstalled NOD32 to get the network working again. So somehow there was some odd interaction between wireshark and NOD32's firewall that hung up the network.
     
Thread Status:
Not open for further replies.