In App Mon, I have two rules. I was asked for it and I had allowed. Would someone explain to me what they are for. Shall they be blocked or allowed? Both are TCP in and I don’t have any corresponding rules in network mon. Do I need to create those rules in net mon?
Here they are:
svchost,services,0.0.0.0,135 TCP In
system,system,0.0.0.0,445 TCP In
No TCP In rules for these ports in my net mon.
It may be a silly question, but as Ewen’d say only silly question is the one not being asked.
They’re both part of the operating system. Although I think those ports are related to Remote Procedure Call (RPC) which can be exploited (another Windows vulnerability). You can always remove them, to see if they return. If you’re not using RPC, I see no reason to allow the communication there. It may just be the result of having the RPC (or Locator) Service active… I believe you need RPC Service, but not the RPC Locator.
Here’s something you can do, if you want to try to track it down… Add a rule in the Network Monitor:
Block (and Log), TCP, In, Any, Any, Any, Destination Port: A set of ports, 135,445. Be sure to place it above any rule that would explicitly allow TCP In (if you have such a rule).
Then in the Application Monitor, change those two rules (with the Port info) to Block instead of Allow. Now you’ll generate a log entry each time they try to connect. The network rule will also block anything there as well, and you’ll see it in the logs.
LM
However, what version of the FW are you running?
That 0.0.0.0 IP address was a glitch that came up during the recent Beta testing; I thought it was supposed to be fixed with the final release of 2.4. If I remember correctly, for some reason CFP was showing that address instead of either the localhost or network/router.
Thanks for the replies. In my logs I noticed there were logs for TCP In on port 135 as denied by the default rule in net mon. I do not have any In rules in my net mon other than the default ICMP In’s and one UDP In for 255.255.255.255 on dest port 67 since I don’t have a fixed IP.
Since you say port 445 is for rpc (which is an essential service), shall I need a rule in net mon as TCP In (or TCP/UDP In),any,445??? Would yous please let me know.
LM, I have the latest version of FW which was automatically updated (so no fresh install for the latest version). So all my rules are as from the previous version. But I will delete those 0.0.0.0 entries in my app mon and try again see if they turn up as 0.0.0.0. Although I do not know what 0.0.0.0 is to be honest. But in the connections window I still get (svchost.exe 0.0.0.0(68),255.255.255.255(67))???
Let you know the result.
[I deleted those two entries and restarted. Fw asked for them and I allowed them and they both show 0.0.0.0 still.]
Thanks LM and soyabeaner
Hilmi
By the way soyabeaner, your new animated image causing lots of ripples on the cpu at around 20%.
LOL.
No, no, no.
RPC Locator = port 445 = not needed service because it’s vulnerable.
RPC = port 135 = vital service but it should not need incoming or outgoing connections
Go this page for more info. I even used the WWDC tool myself to get rid of 445. I didn’t have to create any rules for these. The blocked rpc (135) alerts you get are normal I think, since I also get those from time to time.
My animated avatar caused which process [ at ] ~ 20%? cmdagent.exe, cfp.exe, or your browser? I checked my Task Manager didn’t see any cpu usage.
soyabeaner’s correct - you don’t need RPC Locator Service running, but you do need RPC. Also in that respect, RPC shouldn’t need internet access.
By creating a Block rule with logging, you’ll see exactly when it happens, which (if you were so inclined) could help you track down the offending application. On the other hand, on the presumption that these alerts are related to those services, you can create the Block rule, without logging, and your logs won’t be filled with the “clutter.”
Tools like WWDC, (or other similar ones) are good for helping users “plug” vulnerabilities in Windows. Some will plug the holes only while you tell the program to, so that if you find you’ve blocked something your system needs (all systems are a little different, unfortunately), you can reverse the changes very easily.
soyabeaner, I have no problem with your latest avatar… other than it goes so fast it makes me dizzy, lol.
Disabled rpc locator service
I changed my app rules to svchost,0.0.0.0,135, TCP In BLOCK and system,0.0.0.0,445, TCP In BLOCK
Created one network rule in net mon as BLOCK&LOG TCP In,Any,Any,Any,IN[135,445].
I will try WWDC later.
Soyabeaner, when your avatar is on the screen my CPU usage goes up to around 20% mainly iexplore.exe(I use IE7). When I scroll the page down to loose your avatar on the screen CPU goes down to 0% so as iexplore.exe. Look it does not worry me, I just wanted to tell you for a laugh.
I appreciate your advice greatly. Thanks guys. If you could confirm my above rules that will be great.
I don’t know if NetMon rules are even necessary if you have disabled the RPC Locator service (445). The reason is due to the last, default block all rule (IP In/Out). LM, do you know if RPC (135) makes any outgoing connections? If not, there’s no need to create any NetMon rules for this.
I haven’t specifically seen it do so, but I have all “remote” features turned off, that can be for my system, as this is considered to be a great vulnerability in Windows. I do not intrinsically trust some of these services (thus I turn them off… ). However, it would be pretty easy to tell…
Just add a Network rule (at the top; ID 0 ), to Block & Log TCP Out… Port 135. Then you’ll see if it does…
BTW, hilmi, the connections for port 67 & 68 should be related to obtaining your DHCP lease, and not a cause for concern. I could swear that the 0.0.0.0 IP address thing was fixed, though. I’ll have to look at that a little more…
After disabling rpc locator, I deleted these two rules and then restart. But I was still asked for those so I denied them both. So I still have those two rules in app mon but as blocked. I put the other rule as per LM’s advice so that I can easily track it by letting only this rule to log and then i will remove it.
That needs to be changed to TCP out as per LM’s last post. To be honest I have not noticed any outgoing logs regarding 135 and 445. The only ones I noticed were a few TCP Ins for 135 but they were blocked by the default rule. (I don’t have any TCP In rules)
My screenshot of the network rules attached (I hope)
It’s 3.30 in the morning here. Need to go to bed. I’ll read your replies tomorrow
I don’t skip the loopback check. But I don’t think CPF logs these loopback events because I am yet to see one logged. Is that normal (cpf not logging loopback events)? That was the main reason I started this thread as I have not seen any logs in or out on port 445. And since cpf was not logging any loopback events (rule 0) I thought those two events (on port 135 and 445) must be loopback events and wanted to know more about it. Now I can get rid of it since it does not log anything.
Hilmi
P.S. Rule 17 - I change it to allow when i am using windows live messenger otherwise it is blocked.
Soyabeaner, I use Trlokom’s SpyWall anti-spyware (cost only $15 per year for license) and AFAIK it has HIPS. It also monitors DLL injections. Reading your suggestions on other thread about CPU usage being so high, would it be OK to cancel this on either SpyWall or CFP to lower the CPU usage,although, I do not have that excessive CPU usage. I do get spikes at 50-100%??? on total CPU not much on cmdagent.exe though.
Also, is it OK to have two applications doing the same DLL monitoring?
Instead of raising a new thread, I thought I might ask here.
I honestly don’t know. An anti-spyware that covers DLL injections might work differently and have different scopes/levels of protection than CFP. Only someone more knowledge or also has SpyWall can accurately answer you on that. If there was a way to test them both… :THNK. If your cmdagent.exe has spikes of 50%+, that can’t be normal. You might be experiencing the same problem as others. Actually, monitor dll injections has been stable for my computer ever since this incidence. If you want to continue on this, a new thread should be created because it’s a different topic.
hilmi, is there a reason why you have rule 18 (Block In & Out for TCP & UDP) when the last default rule (Block In & Out for IP) already covers everything? I thought the IP protocol already covers everything, including TCP & UDP.
I do get spikes at 50-100%??? on total CPU not much on cmdagent.exe though.
Maybe, I phrased above quote wrongly!! No, it’s only my total CPU usage spikes high, but cmdagent is very low indeed.
For rule 18: What you say is quite right. I sometimes create temporary rules just to have logging on specific events only for easy tracking of logs. Rule 18 is one of them, it will be wiped out soon.
After reading through this thread I have made a block rule with logging (ID=0) for the port range 135-139; both directions TCP and UDP; Source and Dest. IP = Any.
The connections are now logged as blocked (Checked after visit to Windows Update).
My Question: Is it really necessary to create this block rule seeing that the connections were not logged before creation of the rule, and in view of all ports showing stealth status at Shields Up ?
Why did the default block rule not appear to be doing it’s job ?
Second Question: Being ‘firewall challenged’ please advise how to block only say a TCP local port(s) (not remote). Would I do it like this …
For eg:
Block TCP In/Out
Source IP = Any
Dest. IP =Any
Source (local) Ports: A set of ports (eg. 1025,1026)
?? Dest. (remote) Ports: ?? Exclude?? A set of ports (eg. 1025,1026) :-\
To my understanding of network rules (anyone correct me if I’m wrong) to block local ports only I would have two separate rules one for inwards one for outwards:
Block (&log)
TCP/UDP In (or IP In)
any
any (or your IP or zone)
any
local port(s) to block
Block (&log)
TCP/UDP Out (or IP Out)
any (or your IP or zone)
any
local port(s) to block
any
For the first part of your question I will let the experts comment on. But again,to my understanding, the default IP Block rule should have done the trick.
). However, it would be pretty easy to tell…