Very Strange Firewall Activity

Don’t know if this related but I also have seen two IGMP broadcasts today. See attached.

I know of no reason for a router broadcast since I am on a stand alone PC.

[attachment deleted by admin]

May be, it could be useful to re-read the last answer of this post https://forums.comodo.com/firewall-help-cis/win7-system-igmp-2240022-connection-t46978.0.html;msg338365#msg338365 :wink:

I would imagine this is just a standard IGMPv3 membership query/report message, however, you’d have to check the message type in the header for confirmation. Please see RFC 3376

Insert Quote Quote from: DonZ on Today at 04:40:27 PM Don't know if this related but I also have seen two IGMP broadcasts today. See attached.

I know of no reason for a router broadcast since I am on a stand alone PC.

May be, it could be useful to re-read the last answer of this post https://forums.comodo.com/firewall-help-cis/win7-system-igmp-2240022-connection-t46978.0.html;msg338365#msg338365 Wink

UPnP doesn’t use IGMP in this way, it does, however, use a multicast over 239.255.255.250. With regard to 224.0.0.22 this address is also used by IGMPv3 to initiate group joins, so if UPnP is enabled on the router, this message could be related. If so, I’d expect to see some UPnP/SSDP activity. either in the router logs or perhaps the firewall logs.

As I mentioned earlier, check the ‘type’ in the header of the IGMP message in Wireshark, it will tell you what the message was doing.

Making some progress.

Found out that AOL webmail appears to be the culprit for my port 137 dial outs to non LAN addresses. So I created a rule for System restricting ports 137 - 138 outbound to LAN only. Also added a rule for IGMP there to only allow outbound to IP 224.0.0.1.

Also saw and entry for ping.exe in my prefetch folder and got rid of that ■■■■■■. After I got rid of that, my Avast auto def. update starting working again that wasn’t working yesterday. BTW - ping.exe did not reappear in prefetch proving nothing at boot was triggering it.

Looks like I will be going back to custom policy for the firewall. Things way to loose now.

AOL Webmail doesn’t use ports 137 - 139, they are NetBIOS ports. Depending on how you access Webmail, you will connect using ports 80 and 443, or if you use POP/IMAP/SMTP, you will use 110/143/587 (unencrypted) or 995/993/465 (encrypted)

Looks like I will be going back to custom policy for the firewall. Things way to loose now.

Sounds like a good move :slight_smile:

AOL Webmail doesn't use ports 137 - 139, they are NetBIOS ports. Depending on how you access Webmail, you will connect using ports 80 and 443, or if you use POP/IMAP/SMTP, you will use 110/143/587 (unencrypted) or 995/993/465 (encrypted)

I access AOL mail via my IE8 web browser so it would be using TCP ports 80 and 443; or that is what it should be using. What I have observed in my firewall log are port 137 dial outs to non-LAN IPs. I verified that by immediately checking the log before signing on and after I had signed off of AOL web mail.

BTW - this is not the first instance I have seen of NetBIOS ports 137 - 138 dialing out. I had a lengthly discussion with Symantec on why was NIS 2011 doing so on my WIN XP installtion.

As far as PC software goes, trust no one my friend …

Typically, NetBIOS over TCP/IP uses what are referred to as b-node broadcasts - in a command prompt run ipconfig /all and look at the node type near the top. B-node broadcasts are local and are usually constrained by routers to prevent flooding the network. If your router is allowing NetBIOS name resolution/registration (137) as well as NetBIOS datagrams (138) requests out, you really need to close those ports.

My node type is Hybrid.

So far no dial outs today on port 137.

I did get rid of WOT. It was periodically crashing IE8. Also more strange, it was preventing the lock symbol from appearing on my HTTPS logon page for AOL Web Mail. I checked the page and it showed it was SSL but no lock. I believe WOT was also having problems co-existing with Avast’s web shield and MBAM Pro real time and IP blocker.

Hybrid simply means name resolution/registration etc. will first be attempted against a WINS server and if that fails, use broadcasts. The WINS server(s) address can be listed on the WINS tab of the network adapter. As it’s unlikely, you have a WINS server on your LAN, NetBIOS communication will take place using b-node broadcasts.

So far no dial outs today on port 137.

Because you confined the communication to the LAN, which is as it should be.

As it's unlikely, you have a WINS server on your LAN, NetBIOS communication will take place using b-node broadcasts.
Recent TCPView testing confirms what you have said in a dramatic way. Because I have the option "resolve IP addresses on" when I fire up TCPViiew, I now get over ten blocked outbound port 137 firewall long entries just connecting to my AT&T home page.

Actually the system rule should onlly allow inbound from LAN and outbound to LAN - correct? I hesitated doing this on my WIN 7 configuration due to possible conflicts. Comodo Network LAN definition might have to be expanded to include APIPA range, 169.254.1.1 - 169.254.255.254, and misc. activity 224.0.0.1 - 239.255.255.255.

Since NetBIOS is set on by default in all versions of WIN OSes, Comodo really should provide a default application system rule to block all non-LAN oubound NetBIOS port activity. I know this rule is auto is generated in the non-stealth option but I think it should also be generated for stealth configurations.

I guess this is something to do with your ISP. If you want you can change the node type to broadcast only, which will then be restricted to your LAN, assuming your router is configured correctly. To change the node type:

  1. Open Regedit
  2. Go to - HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netbt\Parameters
  3. If the Key NodeType exists, change the value from 8 (Hybrid) to 1 (Broadcast)
  4. If the NodeType key doesn’t exist, create a DWORD called NodeType with a value of 1
Actually the system rule should onlly all inbound from LAN and outbound to LAN - correct?

If you haven’t changed the defaults, the System process, which is responsible for NetBIOS communication, is covered by the Windows System Applications rule, which simply allows all outbound traffic.

I hesitated doing this on my WIN 7 configuration due to possible conflicts.

To take control of the System process, simple use the Stealth Ports Wizard, option 1, to create two rules that allow inbound and outbound LAN traffic - assuming you have an LAN, or need file and printer sharing. You can of course create these rules manually. Once created, add an additional rule that blocks TCP/UDP Out on ports 137 to 139 and 445.

Comodo Network LAN definition might have to be expanded to include APIPA range, 169.254.1.1 - 169.254.255.254, and misc. activity 224.0.0.1 - 239.255.255.255.

There’s really no significant reason to worry about APIPA addresses, unless you want to use auto-configuration. With regard to multicast addresses, on a typical home LAN, the requirements are minimal. For the System process 224.0.0.1 and 224.0.0.2 (all hosts and all routers) and 224.0.0.22 are more than enough. For svchost.exe, 224.0.0.252 for LLMNR (Link Local Multicast Name Resolution) and 239.255.255.250 for Network discovery and UPnP will generally do the trick. Of course, if you access services such as IPTV or other media sources, these requirements may need to be re-evaluated.

Since NetBIOS is set on by default in all versions of WIN OSes, Comodo really should provide a default application system rule to block all non-LAN oubound NetBIOS port activity. I know this rule is auto is generated in the non-stealth option but I think it should also be generated for stealth configurations.

An option to contain NetBIOS and Direct hosting, via a generated rule, would probably be useful for some…

OK Radaghast, here is where I stand.

Did the Registry hack to Netbt/Parameters to add key NodeType with a DWORD value of 1. Did ipconfig /all to verify node type was Broadcast.

Did my routine of firing up TCPView and IE8 and looking for blocked port 137 outbound activity. Same result. Port 137 leaking like a sieve. Said enough is enough and turned off NetBIOS for my LAN connection. Rebooted and verified no more blocked port 137 activity when TCPView was active. There was none. Will keep an eye on port 445 for activity since that is what Windose will attempt to connect out on now. So far have seen no activity.

I am thinking of setting up my WIN 7 Comodo firewall with these rules Saul Luizaga wrote a while back for XP: https://forums.comodo.com/firewall-help-cis/dhcp-again-t40294.30.html. Let me know what you think of these. I ran with these rules a while back when I had Comodo installed on my XP installation.

Do you run any dialer/connectivity applications from your ISP?

I am thinking of setting up my WIN 7 Comodo firewall with these rules Saul Luizaga wrote a while back for XP: https://forums.comodo.com/firewall-help-cis/dhcp-again-t40294.30.html. Let me know what you think of these. I ran with these rules a while back when I had Comodo installed on my XP installation.

Unfortunately, those rules are slightly broken. As far as the Network zones go, by all means group IP addresses that are relevant to the LAN under one heading, but as I said before, the APIPA address range is really quite useless, unless your entire LAN is using auto-configured addresses. Also, as you’re using a router, the IP address of this device, which I assume is your DHCP/DNS server, is already covered by the LAN range.

In the Application rules section, the rules for System and svchost.exe allow traffic to and from the LAN, directly followed by a rule that allows IP out to everywhere. Whilst allowing greater outbound connectivity for svchost is necessary - Windows updates, clock sync etc - it’s really unnecessary, for most normal home LANs, with the possible exception of a VPN, for the System process to need more than local access.

In addition, the System and svchost rules have a block IP ‘In’ form everywhere, directly followed by an allow ‘In’ from the LAN, which will never be seen. Remember, the rules are read from the top down. Incidentally, the rule that bocks IP ‘In’ is unnecessary, as there is already a Global rule that does the same thing. It would be better if the rule were changed to an block ‘Out’ rule proceeded by the appropriate allow rules.

On a final note regarding Application rules, for most home networks, allowing lsass.exe is unnecessary, however, if you do have a LAN where authentication between nodes is required, of you have a server, which requires authentication by all means create a rule.

The Global rules are ok, although the third rule allowing IP out to everywhere for the LAN is pointless.

For the umpteenth time, I wrote a lengthly reply and Comodo flushed it when I timed out of the forum. I really hate that!

Do you run any dialer/connectivity applications from your ISP?
No.

Anyway the inbound block rules Saul added were to facilitate the stateful inspection of the prior outbound rule. I beleive application rule stateful inspection overides the global inbound block all IP rule.

As far as the subsequent allow IP In From … rule. He just left that in place to show what Comodo originally generated,

I don’t know about IE, which I believe you use, but with firefox there are several addons that prevent that kind of thing from happening.

No.

Well, if you were seeing the System process making connections on ports 137/138 to an address other than the local subnet broadcast (eg. 192.168.1.255) something must have been causing them.

Anyway the inbound block rules Saul added were to facilitate the stateful inspection of the prior outbound rule. I beleive application rule stateful inspection overides the global inbound block all IP rule.

Stateful inspection doesn’t need any help, that’s why it’s called stateful inspection.

As far as the subsequent allow IP In From .... rule. He just left that in place to show what Comodo originally generated,

The auto-generated (Stealth Ports Wizard) LAN rules are the top two, the last rule was manually created.

I think I found the culprit. The Protect ARP settings in Firewall Behavior settings.

I have been getting malformed DNS alerts in my event logs for some time. Not a lot but they always seemed to occur at boot time. Entries looked like something from a failed RARP command. IPs once unreversed always were valid and legit IP address.

Anyway Comodo’s Protect ARP setting is now tuned off.