LM or soyabeaner, any comments on loopback events not being logged?
Hilmi
Thanks hilmi ! What you say about the rules for blocking only local ports makes sense to me.
Using a small tool from nirsoft called Current Ports, some of these ports are shown as “listening” (but with remote address 0.0.0.0), whether or not a block rule is present. See screenshot.
I forgot to mention that I have Client for Microsoft Networks and File and Printer Sharing disabled. Am behind a router. Have also now disabled RPC Locator in Services which was always on ‘Manual’ anyway. Still listening on 445 though ?
Regards.
[attachment deleted by admin]
For the above rule questions, I’m not certain :-[ so I won’t answer. Ports 135-139 is blocked by the last block all rule for me…Then again, I don’t have Netbios and all those Windows services running. Some Windows services are part of CFP’s certified apps database, so…
If you’re not on a network, the WWDC tool will disable netbios and such.
For the loopback not being logged, I think it’s because they occur too often and some don’t want a big log? Here’s one thread that references the request for them being logged.
Do you have the two boxes unchecked under Security/Advanced/Miscellaneous? One’s for TCP, the other UDP; one is checked by default, but I don’t remember which…
With the combined In/Out rule, it can get a little tricky (IMO); you’ve got a destination of 127.0.0.1, but that will change according to whether it’s In or Out. Thus, this may cause weirdness with logging; I personally don’t use combined rules as I think it’s easier to track by keeping them separate.
With Rule 17, I can understand that, as all your other rules appear to be Port/Protocol specific. That makes it all a lot tighter, but then you’ve got nothing “generic” to allow unspecified traffic (such as you might have with Messenger). If you know which Live server(s) you connect to, you could always create an IP address rule just for that (and include w/your Messenger application rule).
LM
ocky,
It looks like hilmi’s pointed you in the right direction for port-blocking. The thing to remember when creating network rules (and this is why I keep In and Out as separate rules) is that Destination & Source are going to reverse each direction…
for example…
On Inbound traffic the Source is remote to your computer (which could even be another computer on a Network), and Destination is your computer.
For Outbound traffic, Source is your computer, Destination is remote. So if you keep that in mind, that should help. It can be a bit mind-boggling, I know. 
hilmi,
regarding the dll injections; the thing to remember is that CFP only monitors that in regards to applications trying to connect to the internet. The HIPS will monitor that in general. I’m thinking that it’s theoretically possible that a malware could inject something, but not be using that to try to connect. I don’t know if that happens, but with malware I generally consider anything to be possible… IF they play well together, then no problem. However, it’s possible that they would conflict, but I think you’d know if they did.
Regarding what’s using your CPU time, have you checked with something like Process Explorer from sysinternals?
LM
- Yes I have loopbacks unchecked,AAMOF,I only have [enable alerts] checked with alert level at very high. That’s what I meant with “I don’t skip loopback check”.
- I am working on tightening MSN messenger as it uses alot of destinations and ports, but, I am almost there. Rule 17 (Blocking tcp/udp out for all destinations and ports) makes me aware of any applications using ports other than (in my case 21,80 and 443), then I create a rule for that application on specific port(s). This is how I found out that cpfsubmit now using TCP out on higher ports along with ftp port 21 with the recent update (that wasn’t the case prior to recent update)
- I wished the loopback events were logged so that in a way you could’ve checked which applications were up to. Initially (when you get the first pop-up) you can but once you remembered and allowed you cannot.Anyone who does not want them logged could stop them by a rule like mine ID 0.
4.Ocky, mine shows as listening (checking with netstat) but in my logs they are blocked. So I assume they all are being blocked.
5.I have not noticed any conflicts with SpyWall as yet.
6.Yes I checked with Process Explorer. cmdagent is always almost 0%, cpf seems OK. iexplore is the one mainly using a lot.
BTW, I am from Australia. You guys?
Take care
Hilmi
My inbound connections to ports 135-139 are also blocked (default block rule), so I have only blocked them outbound for what it’s worth. So far only outbound via port 137 was blocked (Microsoft name servers according to whois lookup).
CPU usage is negligible, 0% for both processes when tray shield inactive. Memory usage here is between 18-27000K for cpf.exe and about 8900K for cmdagent.exe
Anyway thanks to all for your much appreciated advice. Am from Sedgefield in South Africa. Can you please beam me over to Oz ? - not only because of our lousy rugby and cricket performances against the mighty Aussies ! ;D
Regards.
No worries Ocky, I am already working on beaming you here,but, may be create a new wish list for Melih about a beaming machine,lol. This COMODO team can do anything.
Take care buddy.
Reading thru GRC website, I don’t know how up to date they are, but, they say port 445 is required for DHCP and Dcom. I get asked by CPF about svchost on 135 and system on 445 only on reboot, but I get logged for both as coming in (none for outward) and as denied. I disabled Dcom service but my system did not function properly, obviously some programs using Dcom services (most probably Microsoft Office). So as long as they are blocked, I will not worry about them. Nothing else I can do at this stage and I am safe I hope. I need to have DHCP service running as well.
Thanks for your contributions.
Bother you soon
Hilmi
You said you have disabled RPC Locator service in Services, if you are not on a network, also untick Client for Microsoft Networks and File and Printer Sharing in Local Area Connections>Internet Protocol>Properties.
Apparently,(I have not done this), you can try to completely close 135 as per below guide:-
Disabling DCOM does not close TCP port 135. To close it, one solution
is to remove IP-based RPC protocols sequences from the list that can be used by
DCOM. In our case, the sequence ncacn_ip_tcp (transport on TCP/IP) can be
removed.
The simplest solution for this is to use the dcomcnfg tool and to remove
‘Connection-oriented TCP/IP’ in the ‘Default Protocols’ tab.
Under Windows 2000, dcomcnfg directly shows the DCOM properties of the local
system, in particular, the ‘Default Protocols’ tab. Under Windows XP, dcomcnfg
launches an MMC console showing three nodes. The ‘Default Protocols’ tab appears
in the properties of the My Computer node, under the Computer node.
The list shown in the ‘Default Protocols’ tab is stored in the registry, under
the following value:
Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc
Value: DCOM Protocols
Type: REG_MULTI_SZ
Thus, it is also possible to directly edit the registry and remove ncacn_ip_tcp
from the DCOM Protocols value.
After a reboot, all ports should be reported as closed, except one UDP port on
Windows XP.
Backup the registry first. I use ERUNT, which has saved my bacon a few times.
Regards, and looking forward to the beaming up date. ;D