Comodo Firewall and HP C5180 all-in-one network printer

Hello,

I just discovered the following with the most recent Comodo Firewall Pro and my HP C5180-all-in-one network printer.
After booting my pc, I looked in the firewall’s ‘Activity | Logs’ and saw that my printer had been blocked because of its multiple port connection requests to my computer interpreted by Comodo as port scans. I already had set the various ‘Intrusion detection settings’ to the maximal number allowed. I had hoped that would more or less disable these kind of checks because there is no real way to tell the firewall not to apply intrusion checks. However, that does not do the trick.
And the printer’s tcp/ip address is in the zone I defined as trusted. And tcp/udp traffic is also fully allowed within the zone.

Does someone know a way to allow these printer actions or to suppress port scan checks?

Henk Wissink.

Another one…

See this topic https://forums.comodo.com/help/udp_port_scan_on_hp_allonone_printers-t10605.0.html

We don’t know the result of it yet, and it isn’t confirmed it is actually the printer, but possibly something that is spoofing the address of the printer.

My first question, is what is your LAN configuration? A PC, a router, a printer, and anything else? Are you on a wireless LAN?

Hello grue155,

I had a look at the topic you mentioned. Despite all the posts, I did not see a clear solution yet.

Although my router has wireless capabilities, both the printer and computer are connected by wire to it (so the printer is available to all computers).

I have a trusted zone in CFP, I added the .exe files of HP as trusted applications. But the log file keeps on showing the flood after each so many time.

I tried to set all parameters that have to do with attacks such that CFP would wait as long as possible before it would ever conclude a flood is going on. But that does not help too. As far as I can see there is no single switch to (de)activate this feature. Am i right?

Thanks for helping.

Dayjob work tends to make me suspect a lot things. In the case of scans from printers, or other such inanimate objects, it makes me think of indirect network scans by malware.

The only way that I know of to run this down, is to physically isolate the actual source of the scan. You find where the problem is, by where it isn’t. Right now, on your LAN, there are three things that probably are not the source of the scan: your PC with CFP reporting the scans, the printer being made the scapegoat, and your router (presuming you have the typical NAT/router setup).

How the scan works, is that a machine, infected with some malware that is trying to find a new home, forges the IP address and MAC of something on the LAN that doesn’t care about being bombarded by ICMP “port unreachable” traffic. The malware is running a packet sniffer, and can see that ICMP traffic, and so effectively and invisibly port scan any machine on the LAN. The ‘nmap’ security tool can do this very easily. The scan done against TCP ports is called an "idlescan’, detailed at TCP Idle Scan (-sI) | Nmap Network Scanning. The UDP scan is similar, but a lot simpler.

Physically isolating the source is tedious with many machines, as in an office environment. With a home LAN and a couple of machines, it’s much easier. It’s unplug each machine in turn to see if the scan disappears, or put an extra NAT/router in front of the machine to undo the IP address and MAC forgery. That’s the situation in the other topic, which isn’t resolved in so far as I know of.

If the physical isolation isn’t giving results, then some weird hardware or firmware problem could be the case. But searching outside the Comodo forums, I’m not finding anything that says HP printers as having any problems.

Hello grue155,

thank you for your hints. Because of too many other problems between the Comodo firewall and a san drive (that I tried to get solved with the help of others on this forum) I had to decide to uninstall the Comodo firewall.

Because I do not have some other tool (yet) that tells me about these udp scans of the printer I cannot find out whether or not it really comes from the printer.
All kind of runs of anti-virus tools and spyware tools on the computers in my network did not reveal any malware. And I always try to keep perfectly updated with all these tools.

For now I will cease my investigation. However, if you can tell me where I can find a free tool to monitor these udp scans then I can try to make sure that it is the printer.

Regards,
Henk.

Got a tool for you: Wireshark. It’s a packet sniffer, and will show you exactly what is showing up on the wire. It is available at wireshark.org (not the .com site - that looks like a doppelganger trap site).

The Wireshark download comes with a number of command line tools, including tshark as a command line version of the Windows sniffer. For log term monitoring, you can run tshark and capture basic traffic information and watch for anomalies, like overnight and not overwhelm yourself with data.

Wireshark can probably help in getting your san drive set up also. If there is some unexpected protocol running around on the wire, then you’ll see it.

If you try Wireshark, and have any questions, let me know.

Hello Grue155,

sorry for my late reply. I will use it (from wireshark.org) and see what kind of info I get from it.

Thank you so far.

Regards,
Henk

A lot has happened since last we posted…

If you look at the earlier thread https://forums.comodo.com/help/udp_port_scan_on_hp_allonone_printers-t10605.0.html you’ll find that HP printers and their PC based software do some very atypical things. One, is the network management package seems to constantly query the printer at full network speed. This causes CFP to see all that traffic as a flood. On top of that, there seems to be a bug in CFP in that it isn’t reporting the proper port numbers when reporting a flood.

Two support tickets have been entered. The response was “upgrade to v3”, as was kind of expected. The workaround for v2.4, is to crank up the flood threshold to something around 300 packets/sec.
All the gory details are in that other thread, including a lot of wireshark data.

If your wireshark data turns up something other than a bunch of traffic to and from UDP port 161, then you’ve got something different, and I’ll ask you to post your wireshark results. If it is UDP port 161, then it is SNMP network management stuff, and the HP network software is the source.

Hello Grue155,

during my attempts to avoid these blocking decisions by Comodo Firewall, I had already increased the thresholds to the maximum but they still came in sometimes…

Unless I find some other internet security package that does not show this blocking, I probably give v3 a try. (See also my other more severe problem in https://forums.comodo.com/help_for_v2/comodo_and_netgears_zsan_service-t13573.0.html).

Thank you again.
Henk.

That’s kind of the same situation in that other topic. It doesn’t seem that that there is a v2.4 solution other than the threshold workaround.

If there’s no objection, I’ll mark this topic as closed/resolved, and lock it for future reference.

I got the same problem with 2.4 with my 1350 all in one and turning off auto update fixed it. I don’t know if that will work for you?

Quick question: Auto-update of what? I’m presume you’re talking about the HP Director software, but I want to make sure.

Think i’ve got your cure.

I’ve got a c6100 which is in the same family, and was having the same prob. Heres your fix…

Add these files to the trusted applications list VIA the firewall button on the top right of CFP

C:\WINDOWS\system32\HPZinw12.exe
C:\WINDOWS\system32\HPZipm12.exe
C:\WINDOWS\system32\spoolsv.exe

The first two are necessary processes for HPs pain in the ■■■ software to transmit its data, the third is the windows print spooler, also needed. Once you add them, if a popup for CFP comes up about spoolsv make sure to allow it permanently.

Enjoy…

Hello,

I have given up, also after trying Comodo firewall v3.x. After uninstall (of course) no problem anymore.
For all who replied: thank you for your support.

Best regards
Henk