Unfortunately it’s not that simple 
Rule 2 is all ip addresses in the network (see attached). I don’t have one right now, but I did have a rule just for the printer ip address. Still didn’t help.
[attachment deleted by admin]
I think your rules need a little bit of streamlining. So far, in your snapshots, I’m seeing at least 3 devices: your router at 192.168.1.1, your printer at 192.168.1.50, and your PC at 192.168.1.130.
Your router is doing its expected UPnP stuff, and will be doing its normal router stuff too. We’re trying to figure out what the printer is doing. And we’re tweaking CFP rules on your PC. And we’ve got a lot of cooks, and a lot of pots and pans on many burners. Just another day at the office…
In place of your first 3 (or so) rules, try these instead:
- Allow In&Out IP from 192.168.1.0/255.255.255.0 to 224.0.0.0/224.0.0.0 (no, that /224 isn’t a typo)
- Allow In&Out IP from 192.168.1.0/255.255.255.0 to 192.168.1.0/255.255.255.0
All the CFP rules are written from the perspective of your PC: what is talking to it (inbound), and what it is talking to (outbound).
The first rule 0, allows any incoming multicast traffic and allows any outgoing multicast traffic. The netmask is 224 rather than 255 because it’s keeping only the top 4 bits rather than the top 8. Multicast addresses are a range from 224.0.0.0 up to 239.255.255.255.
The second rule is just a rephrasing of your zone rule, but expressed in one rule rather than two.
The remaining rules are the CFP set that let your PC talk safely to the Internet. These two revised rules should get CFP out of the way of trying to figure out what is going on with the printer.
Correct about the pots & pans:>)
OK, I deleted the first three rules and added your suggestions. (see attached images).
Cleared the logs and rebooted. Attached is the latest log file.
In addition, I’ve attached my Advanced setup dialogs…
[attachment deleted by admin]
We’ll get there…
First up, yes I did make a tyop. That should have been 224.0.0.0 netmask 240.0.0.0. I plead late hours and tired.
I checked your snapshots. Some confusion in terms apparently. I was talking in terms of IP/netmask and it seems you read it as IP-as-a-range.
The rules should be 192.168.1.0 netmask 255.255.255.0, range 192.168.1.0 thru 192.168.1.255.
And for the multicast it’s 224.0.0.0 netmask 240.0.0.0 , range 224.0.0.0 thru 239.255.255.255.
(If you think this is fun, try it in IPv6 with 128 bit addresses in hex. Now that’s fun)
I’m going to be calling it a day in a little bit. I’ll check back, probably after 1700 GMT tomorrow.
Later…
I definitely appreciate the help. Networking isn’t my forte.
Ok, I’ve updated the rules and will also call it a night. I’ll check tomorrow sometime and let you know.
Thanks!
[attachment deleted by admin]
Checked today around noon. Log file had a huge number of Inbound Policy Violation entries. Had to clear the file and wait for a couple of minutes until the UDP Port Scan entry showed up again.
I temporarily turned off logging for the bottom most catch-all event.
Log is attached.
Thanks,
[attachment deleted by admin]
Curiouser and curiouser… That’ll be my undoing one of these days.
A couple of tweaks to the rules:
On rule 0, change the from portion to be 192.168.1.0 netmask 255.255.255.0. The ‘to’ portion is okay.
On both rule 0 and rule 1, change the protocol from ‘TCP or UDP’ to be ‘IP’.
A lot of the networking stuff is like these nesting dolls in gift shops. There is Ethernet, which contains Internet Protocol (IP), which contains TCP or UDP or ICMP or IGMP or GRE or whatever. By selecting IP as the rule protocol, it’s basically saying “any”.
Your log is showing a device at 192.168.1.118, doing a UPnP packet like your router is doing. I’m curious now as to what that device is on 192.168.1.118.
Grue155,
ip 118 is my son’s computer. Probably some on-line gaming or something.
Rules are updated. I’ll clear the logs, reboot, and check back later. Actually at the office right now. Connecting remotely to update Comodo.
Thanks.
[attachment deleted by admin]
Another forum thread is reporting the same kind port scan as your logs are showing. There are some differences, and a whole lot of similarities. I’d like to conduct a quick experiment to rule some stuff out.
First, is either turn off (as in power down), or disconnect from your LAN, your printer. If the scan goes away, then the printer is the problem.
If the scan is still showing up, then with the printer still disconnected from the LAN, disconnect your son’s machine from the LAN.
It’s the classic exercise of locating a problem, by finding out where it isn’t. If the scan still occur, keep going until the only things still connected are your router and your PC.
If the scan stops, then plug back in the last thing that was unplugged. If it comes back, and it may take a while, then we know where, but probably not why, the problem is.
Need to give me something difficult;>)
Turn the printer off, no log entries at least 20 minutes.
Viewing the log screen, turn on the printer. Immediate UDP Scan entry displays.
The IP address in the entries is my printer; it’s manually set to 192.168.1.50
I’ll probably not be back on here until tomorrow…won’t be home this evening.
That’s a real strong hint that you’ve got a printer problem. The next couple of steps will be to confirm that hint. The first is to see if there is any kind of firmware update for the printer hardware. That means finding out the current firmware version (probably from a status or diagnostics check, either in the HP Tools utility program, or printer viewscreen), and then checking the hp.com/support web site for any new versions.
If there is a new firmware version, then the “change notice” will list what the fixes are for. Then it’s time to update the firmware. That can make for some fun if something is broken in the update process.
The other step is to use a packet sniffer, like “windump”, to record the packet storm and confirm what is actually hitting the wire. CFP is properly acting as a filter, and to make a problem report back to hp, you’ll likely need the raw unfiltered stuff.
If the firmware doesn’t do it, and the sniffer confirms, then it’s time to either repair or replace the printer, or put it into its own little rubber room like a printserver I worked with once upon a time.
Grue155,
Sorry for the delay. Real life took over.
I believe that the port scan is a printer ‘feature’, not a problem. It’s hanging off the router and all the pc’s in the house can print to it fine. It’s also not too old so I won’t be replacing it any time soon.
The firmware is the latest. I guess I’ll enjoy the feature and see if the next major Comodo version has a fix for it.
Thanks again for all the help.
Real life tends to do things like that.
For something to consider at your leisure, here’s the description of the rubber room.
As I understand your current setup, it looks something like this:
Linksys ------------- printer
router ---+
|
+---------- desktop PC
It’s possible to use another router as a filter but installing it “backwards”. It doesn’t have to be an expensive router, or a terribly capable one either, so long as it can do Network Address Transaltion (NAT). It’s a Cheap NAT Box (CNB). A second-hand used product would do just fine.
It’s place in the scheme of things, is like this:
L I
Linksys ------------- CNB ----------- printer
where the Internet side of the CNB is facing the printer, and the LAN side of the CNB is facing the Linksys router. That way, anything on the Linksys LAN can talk to the printer okay, but the printer can’t get free access to the LAN because of the NAT interface.
What makes it work, is the ability of the Linksys to do some static routing. Not all home LAN routers can do this, but the Linksys products can.
First, set the IP address of the LAN side of the CNB to something new, like 192.168.1.60. Now you can access it from your regular LAN. You should be able to ping the CNB from your PC.
Second, turn off any DHCP capability in the CNB. The Linksys is doing that job already, and there should be only one DHCP server on a LAN.
Third, set the Internet side of the CNB to a static address, like 192.168.8.1. You’ll need to change the IP address of the printer to be 192.168.8.50, so the CNB and the printer can talk to each other. From the admin tools of the CNB, your should be able to ping the printer.
Fourth, on the Linksys, there is a “Advanced Routing” screen where you can define static routes. You’ll need to make the following settings:
Destination LAN IP 192.168.8.0
Netmask 255.255.255.0
Gateway 192.168.1.60
Interface “On the LAN”
If everything is working, from the Linksys admin diagnostics tools screen, you should be able to ping your printer at 192.168.8.50 thru the CNB. If that works, then you should be able to ping the printer from your PC. That means all the network routing is complete.
Then tell your PC that the printer IP address is now 192.168.8.50, and you should be good to go. Your printer can be shouting all it wants to, and your LAN will not hear it. Your PC, on the other hand, still has unrestricted access to the printer.
You likely need what is called “cross-over” cables, rather than the regular Ethernet cables. There are electrical rules on nesting hierarchies of hubs, and the CNB is doing it backwards. Some products will automatically recognize that fact and switch their internal wiring accordingly. Most won’t.
It’s kind of a weird fix, but it does work. Using second hand parts keeps it very inexpensive. And security alerts now mean something as opposed to being noise.
If you try this setup, and it works, and you still get port scans, then there is something else going on. If the scans disappear, and if the CNB has a logging facility that goes bezerk, then the printer is the confirmed culprit.
Where were you a month ago. Just replaced a Linksys wireless b with a wireless n and sold the old one on eBay :-\
I think I understand the setup; essentially a LAN within a LAN. Maybe I can find an unused router at work. They’re constantly changing things there and scrapping older equipment.
I really appreciate the amount of time you spent on this.
Thanks!
It’s the same kind of work as the day job, doing admin work on a small non-commercial site. Some of the solutions get creative when working with a shoestring budget. These little home NAT/routers can do quite a lot when used in combinations. Keeping a printserver quiet, or locking down a machine that handles sales@ email are variations of what I outlined. It’s become standard kit stuff now, here at least.
If you set this up, those port scans should disappear. My concern is, if the scans are still present, and worse, use the new IP address of the printer, then the probability of there being something unpleasant lurking around the dark corners of the LAN goes up by several orders of magnitude. Anomalous packets bother me. It’s like a bank balance differing by 0.04, and spending a half day running it down. It’s a personality quirk, which can be useful in computer security stuff.
HI;
I would like to jump in here. I have the same problem with a hp c7100. Is this an attack from the printer or something else or just a conflict between CFP and HP? Have you a solution or suggestion??
Where the scan is coming from is kind of an unknown for certain. The suggestion that I have for the moment is to use a packet sniffer to see what is on the wire. I’ll refer you to my posting a minute or so ago in this topic https://forums.comodo.com/help/comodo_firewall_and_hp_c5180_allinone_network_printer-t13643.0.html about using Wireshark to see what is going on.
Finally back.
I installed Wireshark as per your suggestion. Immediately upon starting a capture, it began displaying entries showing my printer ip talking to my pc and visa-versa. While the capture was still running, I shut off the printer and the chatter to that ip went away.
I currently have Comodo uninstalled. It is too much of a hassle for my wife if she’s needing to print something and Comodo has blocked the printer.
Interestingly, with the printer off I get these entries which I believe is the HP software on mine and other pcs in the house attempting to locate the printer (which is still off). The ip addresses are valid.
10 0.868120000 HawkingT_07:7d:ca Broadcast ARP Who has 192.168.1.50? Tell 192.168.1.118
11 3.498841000 Micro-St_7b:48:9a Broadcast ARP Who has 192.168.1.50? Tell 192.168.1.130
If I turn the printer back on, I get blasted from its ip…as a reminder, the printer’s ip is 192.168.1.50.
Attached is a pdf of Wireshark showing the traffic when the printer is turned back on. It begins around Frame 16.
If I get some time later this weekend, I’ll try to install Comodo just to see if I can get a correlation between the UDP Port Scan and the Wireshark capture information. I’ll let you know what I find.
[attachment deleted by admin]
Oh my, 240 pages of Wireshark data, in glorious detail. And it turns out that detail is necessary to understand what’s going on.
Short summary, HP wrote some ■■■■■■ code. The HP utility tool on your PC is querying printer status by doing an SNMP MIB walk, using one port per MIB query at about 0.008sec per query, and walking the ports sequentially.
Or, put another way, in a pseudocode style:
port=2000
for length(HP-status-MIB)
do
query printer SNMP port 161/udp from my(port) for HP-status-MIB::item(something)
next(something)
port=port+1
enddo
The usual way of writing that kind of code, is to allocate the port once, and keep it until all of the queries are done. This HP code is getting one word out of the MIB book, and then getting a new port for the next word, until the whole book has been read. And doing it at speed.
At 0.008sec per query. Or about 125 packets per second, walking ports sequentially. That sure does look like a port scan. A real fast one. Comodo flags it, and shuts off the LAN connection. I would too.
Just based on this Wireshark data, I’d say that Comodo UDP and Port Scan threshhold numbers would need to be at least 150 packets per second. Maybe 200/sec for good measure. But that effectively turns off the Comodo checking for UDP flooding and for port scans.
Whoever wrote the HP code needs to go back and read “TCP/IP Illustrated, Vol 1” by Stevens.
So, no malware. No stealth scans. No black helicopters (meaning I need better quality tinfoil). Just some really ■■■■■■ printer management code.
ROFLMAO!
Print driver programmers - can’t live with 'em, not allowed to chop 'em up and put 'em in pies.