Comodo hates Network Printer

Help for v2
#1

I have issues between Comodo Firewall and an HP C5180 network printer. I would appreciate an expert second opinion. Issue summary:

  1. UDP Port Scan and DOS Attacks
  2. Excessive chatter on port 161
  3. Weird stuff on port 427
  4. Consequences of OLE Automation confusion
  5. system.exe tries nbname lookup on pop3 server

We have a small local area network with a population of PCs and users of various ages and abilities. Internet access is through a Netgear DG824Gv2 router. The router protects us against external attacks so our main interest in a Personal Firewall is to control/stop applications getting out without our knowledge/consent. Comodo has an excellent reputation in this regard so a couple of months ago we switched to it.

This was fine until we got the new printer. We have tried the HP printer s/w on two PCs so far. Both are running Windows 2000 Profession SP4 with up-to-date security patches etc. Comodo is the latest 2.4.18.184.

  1. UDP Port Scan and DOS Attacks

It seems the printer scans the PCs every six minutes. Increasing the UDP Flood threshold to 160 packets / second avoids DOS alerts. The incidence UDP Port Scan alert is also reduced. We’ve blocked outgoing connections while booting.

The alerts now only occur when the user logs in or the PC comes out of hibernation etc. Even with the Port Scan probing rate set to the maximum of 500 ports / second we can’t eliminate these alerts.

It looks like there is some start-up race condition that Comodo loses. Is there anything further we can do to avoid these alerts ?

  1. Excessive chatter on port 161

It seems the PC uses UDP port 161 on the printer for bi-directional communication. This isn’t needed for printing but is for scanning and device control such as checking ink levels.

We are astounded to observe that the HP s/w on the PC is continuous polling the printer. The s/w successively establishes short lived connections on ports 1000 through 4999 on a cycle of roughly 10 minutes.

We can stop the chatter by stopping the PML service. This isn’t Comodo’s fault but it is hardly convenient.

The Connections window in Comodo does not handle this very well. Connections are coming and going so fast that we can’t even estimate how many are active at any one time. The window update chews up a significant proportion of CPU.

  1. Weird Stuff on Port 427

UDP port 427 seems to be used by a Network Device Rediscovery Service. The HP s/w that handles this is hpqnrs08.exe. It needs both UDP Out and UDP In.

In addition to hpqnrs08.exe, Comodo reports that spoolsv.exe also uses port 427 to talk to the printer. We wonder how and why this is.

If we turn the printer off, the PC gets no response to its polls and so it tries an Internet address instead. Comodo reports both hpqnrs08.exe and spoolsv.exe sending UDP packets to 224.0.1.60:427 - an IANA mcast-net address.

We have defined our LAN as a trusted network and are prepared to give pretty much any program access to the LAN but not to the Internet proper. We now think Comodo does not actually support this idea very well.

Are we correct in deducing that once Comodo has blocked an attempt by some program (spoolsv.exe) to access the Internet (224.0.1.60:427 UDP out) it blocks all network access to and from the program (192.168.0.254:427 UDP in) ?

Are we correct in thinking the only way to unblock hpqnrs08.exe or spoolsv.exe again is to reboot the PC ? Once blocked we get four alerts per minute. This soon makes the Logs window awkward to use (we’ve had Comodo crash while trying to scroll down to the bottom of the log). A filter on the logs would be nice - one that ignored all repeats so we could more easily find the alert that was the origin of the blockage.

To work round these problems, we added rules allowing hpqnrs08.exe and spoolsv.exe access to any IP address on port 427. For good measure, we then blocked this traffic in the Netgear router. We are disconcerted to find the Netgear routing isn’t logging any blocked traffic. Is it that 224.0.1.60:427 isn’t a real IP address at all so the router does something special with it ?

  1. Consequences of OLE Automation Confusion

It would seem (from browsing the Comodo forums) that Comodo incorrectly reports programs trying to use OLE Automation to access the network indirectly.

We have found that the inbound traffic on port 427, where hpqnrs08.exe is acting as a server, leads to an OLE Automation alert for practically any program we run on the PC, including those we know damn well don’t use the network.

These alerts are crying wolf - we tend to just allow the traffic without paying much attention to precisely what we are allowing.

We think we’ve had both Internet browser and e-mail client blocked because of this. Killing the program and restarting seems to workaround the problem but this isn’t satisfactory for background programs that naive users don’t even know are there.

If Comodo claims avgcc is using OLE Automation to access the Internet through the svchost as parent of hpqnrs08 and the access is automatically denied after 120 seconds while the user is on a caffiene maintenance break, which of avgcc, svchost and hpqnrs08 are thereafter denied network access ?

If the user sees the alert and allows the traffic, the checking of the remember-this-setting box appears to have no effect. Is this observation correct ?

  1. system.exe tries nbname lookup on old ISP’s pop3 server

Since adding the printer to the LAN we have twice has a PC drop off the LAN completely after Comodo has blocked all network access to system.exe.

On the second occasion we found system.exe had tried to access the Internet while we had only given it permission to access the LAN. It had tried to access port 137, which is nbname and sounds a reasonable thing for system.exe to do. However the Internet address was that of the pop3 server of an old ISP that we still check because occasionally we get messages sent to the old e-mail address.

This is system.exe with parent system.exe and no OLE Automation funny business so it looks pretty suspicious to us but we wonder if Comodo isn’t mistaken.

#2

[
[/quote]
i dont know if this will be related to your problem…but anyway you might pick up an idea…i used to have zone alarm in my pc and then i switch to comodo and now i cant print to the network printer, i was able to fixed it my going to the main server with comodo and and going to the task section, then to the add/remove/modify zone, and add a new zone and specify the ip address rra ge you want to access the network printer, i hoped this make sense

#3

I’m not sure where you have the Alert Frequency set (security/advanced/miscellaneous) but given that you have various users of various levels, you may want to set it to Very Low - which will engender one alert per application - allowed, or not allowed.

Without seeing individual Application Monitor rules, Network Monitor rules, and Log Entries, it’s hard to say precisely what’s happening, and what would be needed to address it. I’ll take a general stab at, though.

  1. If the printer is truly networked, does it have its own IP address? If so, it needs to be included in the Zone that you’re using to define your Trusted Network, so that the Network Monitor will allow unimpeded traffic to/from the printer. Sounds like a lot of this is due to the HP software clutter. You may also find it helpful to (one at a time) turn off “Do Protocol Analysis” and “Block Fragmented Packets”.

  2. In Application Monitor, set each executable used by the HP software to “Allow All Activity” (instead of “Apply the following…”) and probably even “Allow Invisible Connections”, “Skip Advanced Security Checks” (given some of the other issues you are having).

  3. See #2 (including spoolsv.exe!). The 224.x.x.x is a non-routable address; it does not exist outside of the LAN, so it’s not captured by your router. It’s trying that multicast as a “shout out” to the network to try to see if the printer will respond that way. Yes, once CFP blocks an application due to a lack of response from the user, etc, the application is blocked; typically restarting the application will reset, but sometimes exiting/restarting the firewall or rebooting is needed.

  4. CFP isn’t incorrectly reporting OLE Automation, but the fact that it does report it shouldn’t be a cause for concern - as long as you know/recognize the applications in question. Based on that caveat, it is safe to Allow w/Remember so that you won’t see that specific alert combination again. There are ton of OLE complaints, that have been explained multiple times by the developers - it is perfectly normal for applications/components/etc to communicate behind the scenes, where the user is not aware of what’s occurring. A line of communication can be opened and remain open (or set to reopen) even after an application is closed. Naturally, this type of communication and sharing resources is used by malware to try to exploit the system. CFP monitors such, but cannot distinguish between “good” and “bad” except for the encrypted Safelist (security/advanced/miscellaneous/do not show alerts for applications certified by comodo) - if both apps are on the safelist, you wont’ see such an alert. If one or both are not on the safelist, you will see said alert, and need to respond. A deny response, or no response, will result in both being blocked for that session (see the final line of #3). The only time to be concerned is if you do not know one, or both, applications involved…

  5. There’s possibly something set somewhere (an old setting, for example) that creates a call to an ISP. System is always going to do NetBIOS stuff on a network, even when NetBIOS is disabled, so you’re always going to see some sort of access on ports 137, 138. I’m not sure what the relationship would be to the old ISP pop3 server, but there must be a setting somewhere that related to it. In my experience, if system processes are blocked, they frequently try to use any method possible to regain access. As long as you haven’t disabled Application Behavior Analysis (and it doesn’t sound like you have), then you would be alerted if system.exe were hijacked in some way. My question would be, was system.exe blocked under Application Monitor, or Network Monitor? This makes a difference…

LM

PS: Comodo doesn’t hate your printer; it’s incapable of such emotion… :wink:

#4

Thank you Litte Mac for your full reply. It really is appreciated. It has taken a long time to try your suggestions one by one. How long do you wait before deciding a problem has gone away when you can’t reproduce it at will ?

None of your suggestions worked any great magic. Subjectively, the “Allow All Activity” has reduced, but certainly not eliminated, the COM / OLE Automation alerts.

For issue 5, the traffic was blocked by the Application Monitor. We added an application rule so Comodo allows the traffic and blocked the traffic in the Netgear router. In two weeks or so the Comodo alert has not recurred and the Netgear router had blocked the traffic once.

We have had other alerts for system.exe but they have not been logged. Is that because the traffic was ‘allowed’ each time ? It is difficult to help people since the logs don’t record their response to alerts but if Comodo does not log all alerts the user sees then it is impossible for us to see what they’ve done and so give the correct advice as to what to do next time. We have also noted that when a PC is rebooted, recent log entries are lost.

I can well believe they thought through COM / OLE Automation long before they ‘invented’ PC security and the result is a gift to malware writers and a challenge to firewall designers. I can understand that Comodo cannot distinguish between good and bad use of COM / OLE Automation to access the Internet and so the user has to decide. I can just about explain this to our users.

What Comodo does not seem able to do is distinguish between actual use of COM / OLE Automation to get to the Internet and the mere coincidence of two events that are symptomatic of such access.

I cannot believe that software that has been running satisfactorily for years on our systems has been waiting all this time for us to install Network Rediscovery Service software in order to access the Internet. Not when this software includes not only our Internet browser but also their mmc.exe.

I cannot explain to users why they can get these alerts when all three applications concerned have been granted network access explicitly in the Application Rules. That the alerts do not occur in direct response to actions on their part and can occur when they are out of the room brewing a cuppa. That when they come back they may find their Internet browser is blocked. That even though the Network Rediscovery Service is now also blocked, it keeps on trying and so may well lead to more alerts. That now matter how many alerts they see and how many times they ‘allow with remember’, they cannot unblock the Network Rediscovery Service without logging off and back on again and that by doing so Comodo will forget all the ‘allow with remember’ responses to COM / OLE Automation alerts.

When these alerts occur, Comodo claims that the Network Rediscovery Service is trying to act as a server. It is beyond our comprehension how a client on the PC can use a server on the PC to access the Internet, but we suppose malware can do this. Once blocked, the Network Rediscovery Service is blocked several times a minute. It it blocked trying to act as a server even with the printer turned off and unplugged from the LAN. Unplugging other PCs running the service from the LAN had no effect either. Only unplugging the PC itself stopped the blocking. Since the service is blocked, it can’t be talking to itself. Something is not right here.

#5
What Comodo does not seem able to do is distinguish between actual use of COM / OLE Automation to get to the Internet and the mere coincidence of two events that are symptomatic of such access.
CFP isn't watching for OLE events that "connect" to the internet. It simply watches for OLE events involving applications that ARE connected to the internet. Just like with components used in applications (like in a browser), doesn't mean that component is creating a connection; it's only a part of an application that is.

Think of it like you driving a taxi down the road. You stop at a traffic light, and someone jumps in the back seat. The police officer seeing this happen doesn’t know if it’s legitimate or not, although with a taxi it’s not unexpected; it’s his job to make sure you’re okay, and not being hijacked, so he has to follow you, stop you, etc, to make sure.

It’s not that your computers have never acted this way before; it’s that you have never had a firewall monitor this type of behavior before. This is part of the reason why CFP is the #1 firewall against leaktests, according to tests by www.matousec.com.

Based on what you are explaining, I have to ask: At what level do you keep the Alert Frequency? (security/advanced/miscellaneous)

LM

#6

Little Mac,

Thanks again for your reply. I like your analogy, but first to answer your question.

Of the two systems on which we have so far installed the printer software, one has the alert level set low, the other has been set to very low.

We weren’t too sure what to expect when we changed the alert level to very low. Here’s what we have observed. Yesterday there was one alert for the Network Rediscovery Service. This claimed the spreadsheet application might be doing something suspicious. Fighting the natural temptation to deny, the user allowed the suspicious behaviour.

Inspecting the log some hours later, we found no record of that alert but there were three alerts for suspicious behaviour involving the e-mail client. The user remembers only using the e-mail client once (to look up my 'phone number) and remembers no alerts.

Was there no alert because of the very low setting ? Did the e-mailer get blocked ? The log doesn’t say.

There were also four alerts round about the same time (4 minutes later each time) concerning the Network Rediscovery Service. Before we used to get four alerts a minute. Is this too a result of lowering the alert level ?

We presume the Network Rediscovery Service is now blocked. On the connections screen we can see it is still connected (or wants to be). It would be nice if the next release of Comodo had a visual indication that the connection is blocked or otherwise.

As I said, I like your analogy. I am happy that the Comodo policeman is officious. What I am less happy with is his draconian behaviour. The suspicious passenger is sent home and must start his journey all over again (close and restart application) while poor me, the taxi driver, has his licence suspended (log off or reboot to get it back).

In some countries it is illegal to hail a cab but you don’t get sent to jail. I’d be much happier if Comodo the policeman simply hauled my passenger out of my cab and told him to go to the nearest taxi rank and otherwise let both of us get on with our legitimate business. That is discard the blocked traffic but not block all traffic to and from both applications involved. I’m sure I’m not the first to make this request.

We are involved with a voluntary group that helps Silver Surfers get started withe PCs and the Internet. They are as deserving of real security as much as any other group but the Comodo user interface is a real challenge. Apart from having grown up and had families in the world before PCs, many cannot abstract as well as they once did and so learning is slow. Distractions such as pop-ups confused and they make mistakes. Much as I would like to, I can’t recommend Comodo to them.

Where should I make suggestions ? It would be nice if one could go to the activity log and select any entry and call up the pop-up alert that would have appeared if there had been an ask rule (and say to one self next time I see this one …). It would also be nice to then and there to allow / deny w/ remember overriding whatever the current status is (so as to not have to close applications or reboot).

#7

Hijacking alerts will be a somewhat separate issue from regular application-based alerts; as long as Application Behavior Analysis (ABA) is enabled, the various hijacks will be announced via popup. It does coordinate, however, with the Alert Frequency for applications, though.

Aside from that, the Alert Frequency (which is slightly misnamed, IMO) involves the level of detail associated with each application rule (a global setting). If you move the slider up & down the scale, you’ll see that it tells you what info will be included. The higher the level, the greater the level of detail, and the more alerts you will get.

ABA & AF tie in together in details, though. For example, if your AF is set to High, this will create rules to include Application, Direction, Protocol, and Port. Let’s say application abc.exe uses OLE Automation to access the browser TCP Outbound to Destination Port 80. You Allow w/Remember, so as not to see that alert again. You won’t. Then later, the same abc.exe uses OLE on the browser TCP Outbound to Destination Port 443. You will see another alert, because the Port has changed.

I know the logs leave something to be desired, and I think all of these “somethings” have been requested in the firewall WishList - probably multiple times. Feel free to add yours as well… :wink:

I think that if you Allow a hijack alert, it won’t be in the log. I could be wrong on that, though. At any rate, CFP logs those based only on the victim (taxi driver), not the hijacker (passenger). So in order to make the best use of those, the user has to pay attention to the alert.

If both applications are on Comodo’s safelist, you won’t see hijack alerts for their behind-the-scenes communications. If one or both apps are not on the safelist, or if you’re not using the safelist, you will see these alerts. If you respond Deny on any of these hijack-type alerts, CFP blocks both offending and offended applications for that session (provided you don’t select “Remember” as well; which would create a rule). This is because it works from the basis of Block unless Allowed, and the presumption is that if you blocked that connection involving multiple applications, the security must have been breached; therefore, neither application is safe to Allow. Generally, closing & reopening the offended application (taxi driver) will reset it; in my experience the caveat to that is OLE, which seems to want a reboot (at least for some; but not for everyone).

It sounds like you want a Set & Forget setup. As it happens, there is a tutorial on doing just that… You may find it in this thread: https://forums.comodo.com/index.php/topic,6167.0.html

At present, the Safelist is not that large, and mostly includes Windows componentry. But if you’re not using alternative softwares, you should be fine. I don’t know about the silver surfers, though; it may be a bit out of the question on them as yet. I understand that dilemma; there are a number of folks I hesitate to recommend CFP to, simply because I don’t think they can handle it easily. If you turn off ABA, you still have a strong firewall, just without the leak protection. Will the SSers be shopping the porn or warez sites? If not, maybe that’s still relatively safe for them…

LM