HELP INTERPRETING LOG FILE

Help for v2
#1

Hi Folks,

Not very good at understanding what the problem is that I am having. I am not sure if it is an external “attack” or just something not properly configured in one of my installed programs.

Here is an excerpt of a log file to look at (sorry it’s so much):

Date/Time :2007-02-13 18:22:01
Severity :Medium
Reporter :Network Monitor
Description: Inbound Policy Violation (Access Denied, IP = 169.254.1.157, Port = upnp(5000))
Protocol: UDP Incoming
Source: 169.254.1.157:5056
Destination: 169.254.1.255:upnp(5000)
Reason: Network Control Rule ID = 7

Date/Time :2007-02-13 18:22:01
Severity :High
Reporter :Network Monitor
Description: Blocked by Protocol Analysis (Fragmented IP Packet)
Direction: IP Incoming
Source: 169.254.1.75
Destination: 255.255.255.255
Protocol : UDP
Reason: Fragmented IP packets are not allowed

Date/Time :2007-02-13 18:22:00
Severity :High
Reporter :Network Monitor
Description: Blocked by Protocol Analysis (Fake or Malformed UDP Packet)
Direction: UDP Incoming
Source: 169.254.1.75:21302
Destination: 255.255.255.255:21302
Reason: UDP packet length and the size on the wire(1483 bytes) do not match

Date/Time :2007-02-13 18:21:55
Severity :Medium
Reporter :Network Monitor
Description: Inbound Policy Violation (Access Denied, IP = 169.254.1.75, Port = upnp(5000))
Protocol: UDP Incoming
Source: 169.254.1.75:5056
Destination: 169.254.1.255:upnp(5000)
Reason: Network Control Rule ID = 7

Date/Time :2007-02-13 18:21:55
Severity :Medium
Reporter :Network Monitor
Description: Inbound Policy Violation (Access Denied, IP = 169.254.1.161, Port = upnp(5000))Protocol: UDP Incoming
Source: 169.254.1.161:upnp(5000)
Destination: 169.254.1.255:upnp(5000)
Reason: Network Control Rule ID = 7

Date/Time :2007-02-13 18:21:50
Severity :Medium
Reporter :Network Monitor
Description: Inbound Policy Violation (Access Denied, IP = 169.254.1.157, Port = upnp(5000))Protocol: UDP Incoming
Source: 169.254.1.157:5056
Destination: 169.254.1.255:upnp(5000)
Reason: Network Control Rule ID = 7

I am not on this address scheme in my home network (169.254.X.X). Therefore, this seems like some sort of attack to me, trying to compromise UPNP. Would anyone agree with this assessment? Anything I can do to stop it?

Thanks,
rjw57

#2

G’day,

I think you’re correct in your assumption (hopefully someone else can confirm this). The source address range (169.254.X.X) is not a valid routable address and is usually assigned (to XP PCs at least) when a DHCP IP address cannot be obtained.

These inbound requests are addressed to 169.254.X.255, which is the broadcast address for that subnet. To me, it smells like someone is sniffing for a upnp hole.

Hope this helps,
Ewen :slight_smile:

#3

Ewen’s probably right about the UPNP sniffing…

I wouldn’t be surprised to see the 169.x.x.x IP IF you were using ICS, as that seems to happen sometimes for the client machine. But even that’s not in the 5000 port range…

LM

#4

Hello rjw57,

I have had a similar problem ever since I updated to Comodo 2.4 (From V2.3). See my post at the time which went unanswered:

https://forums.comodo.com/index.php/topic,5478.0.html

I had no such warnings for the 6 weeks of Comodo use prior to upgrading to V2.4 and these warnings began immediately after reboot with V2.4.

After receiving no help, I uninstalled Comodo and began a trial of ZAP V7 and had no problems and no logged intrusion attempts with that program. I recently uninstalled ZAP because of a conflict with spysweeper and reinstalled Comodo V2.4. Again, immediately after installing Comodo, the warnings began again. I have concocted a network rule which I am not confident is the most optimum - but it does keep the log clear (see attached rules - #5). I have also entered a ticket with Comodo support but the only replies to date are:

“Thank you for your order and for continuing to give Comodo the opportunity to serve your online needs. These are UPNP broadcasts. If this is a local network with a router, this may happen. There is no attack or something.
Should have any queries do not hesitate to write to us.
HAVE A GREAT DAY !
Regards
Karl
Technical Support”

“We are looking in to this issue and will get back to you shortly.
Regards
Dean
Technical Support”

It remains unclear to me what this really is - i.e. is it real and what is the source of the intrusions, or is it merely a V2.4 bug.

Oldshep

[attachment deleted by admin]

#5

Hi Oldshep,

Thank you for your reply. I agree with you completely in that an attack like this (if one) doesn’t seem likely to be coming from this address space making me think, like yourself, that this is more like a bug than a genuine external attack. I will submit my bug report shortly with these folks. The only reason I care is that it seems as though a significant amount of processor time is being intermittently sucked up by XP’s “system” process, which I do not recall being an issue since, as you alluded to, the installation of V2.4. Hope to find a solution as this is a real pain. I love this software, and as they say, beggars can’t be choosers…

BTW, Ewen & LM (thanks for the replies), I am NOT using ICS. Each computer in my home network gets its address via DHCP from my router which is restricted to a range of 192.168.1.1 - 192.168.1.100. I have confirmed that they were all properly set up for the network before I wrote here.

Thanks,
rjw57

#6

rjw57 - for your home network, is your router wired, or wireless? And what make/model? Perhaps we can do some looking to determine if it makes UPNP broadcasts, or is known to generate this sort of traffic…

oldshep - I’m sorry that no one responded to your other post, and that the response from Support was not what you were hoping for. Have you perhaps followed up on that ticket, to let them know the difference between using ZAP and CFP? CFP has a strong Stateful Packet Inspection engine, which is unusual for a software firewall; this is normally only found on hardware firewalls. This may be why you don’t see such traffic with the other firewall.

Regarding your network rule ID 5, no problem there that I can see. That will block the connection and not take up logspace, since it happens with such frequency. You’re very much on top of things there…

LM

#7

rjw57 - Thanks for raising this issue and following thru with a support ticket. Hopefully, the developers will get time to address this in the near future. I agree that just preventing logging (by adding a network rule) is only a band aid and that CPU usage can still be problem.

I don’t want to abandon this software either. Since its free, I don’t feel like I have any right to complain. So I guess I’ll just keep pestering…

Little Mac - Thanks for your comments. I rattled the chain a bit on the support ticket for this issue. I found that the ticket had been closed by Tech support but I have reopened it now. As far as the network rule I’m using, I feel better now that you see no major problems with it. It does seem to fulfill the intended purpose. I was just afraid it might be a little too broad and prevent logging of “legitimate” network warnings.

Oldshep

#8

oldshep,

Yes, the rule would block and not log all UDP In; that’s a good point, if you still want to see everything else. If you can see from the logs (you can always turn logging back on for that rule) that you’re dealing with a clearly defined range of IP addresses, you can add that range to your UDP Block rule, then it will only block that aspect of it; the rest will filter down to the bottom Block All & Log rule.

For example, with rjw57’s situation, he could create a rule as such:

Block UDP In, Source (IP range) 169.254.1.1 - 169.254.1.161, Destination Any, Any, Any.

This would block only that IP range, as taken from the logs. If further logs showed it needed to be expanded, that’s easy enough to do; he could also put the entire range, up to 169.254.1.255 in there from the get-go, since it may very well go over the .161…

Hope that helps, and thanks for stickin’ in there… it can only help make the product better.

LM

#9

Hey Little Mac,

Many thanks on the rule improvement suggestion (Source: IP range instead of any). I changed the rule to IP range (169.254.1.1 - 169.254.1.255) and its still properly preventing the excessive logging while it should now allow logging for other UDP in warnings. Cool…

Oldshep

#10

Hi Oldshep,

I did a little more investigating and think I may have discovered the source of this problem - Verizon FIOS. The STB’s are able to talk to one another via coax within the house. I noticed the mac address of the IP/UDP source which had the 169.254 IP address (I was using a netwrok packet sniffer) and an internet search indicated that it was most likely a motorola device. My FIOS STB’s are the only motorola devices on my network (at least I think I know this now :o). So I guess what I would like to know is do you have Verizon FIOS also?

rjw57

#11

Hey rlw57,

The IP address range 169.254.X.X is used by Windows XP to allocate an IP address to a device that doesn’t have a static IP and isn’t allocated one by a DHCP server. It does this to preserve the IP connection to the device, otherwise it wouldn’t conect.

Cheers,
Ewen :slight_smile:

#12

Hi Ewen,

I know about windows assignment of 169.254.x.x adresses already. It’s just not this. This device has a mac id that just isn’t anything that I have physically residing on the network that I am in control of. I’ve literally checked every conceivable device on the network for its mac id. I have three desktops, a laptop, an xbox360, a Sony PSP and a dlink wireless media server. It is NOT any of these. I can’t even ping the address either, which I find most interesting. The only way I see it is with Comodo’s log file or a packet sniffer (which is how I found the mac id). The info the packet sniffer gives is in the attached zip file if you are interested (I stopped the capture after it saw these adresses, which the router apparently reports immediately). I really suspect Verizon here, since I have IP based set top boxes to permit communication between stb’s. Hoever, the confusing thing to me is that I would think I would only have this IF I had DVR service. Since I don’t, then???. If you have any other ideas, I’m all ears…

Thanks,
rjw57

[attachment deleted by admin]

#13

Hi again rjw57,

The traffic is, as you pointed out, caused by the STB’s communicating between each other. They appear to arbitrate between themselves The traffic you’re seeing is leakage across an ethernet bridge point. There’s a good forum posting on this exact problem at http://www.dslreports.com/forum/remark,16308944. The key was to search for “hmanetconfig”, as shown in your sniffer log.

Looks like it’s a Verizon/STB issue.

Cheers,
Ewen :slight_smile:

#14

Thanks Ewen. Great link. I’m glad it was what I thought it was. Now, down to business. Since this is the “noise” I was complaining about, is there anyway to stop it from being logged. I know it’s more of a nuisance than anything, however, if the log is written to so often, I might not see a real problem. Is there any way to prevent this traffic from being logged? However, more importantly, is there any problem with the fact that Comodo is blocking and logging this info? It looks to be all local traffic. That is, I should be able to allow all of this traffic, even if it is a “Ffragmented IP Packet” or “Fake or Malformed UDP Packet” as reported by Comodo, wouldn’t you agree? If so, any suggestions on what the rules look like? It would appear though that the rules normally recommended by Comodo will ALWAYS log this noise, true?

Thanks,
rjw57

#15

Yeah, it will always log it because it is irregular traffic. Malformed or Faked packets should ALWAYS be logged, regardless of the source. Standards are there for a reason. :wink: I can’t see a way clear of the logging occuring short of disabling malformed packet checks and this is definitely NOT recommended.

Maybe Verizon could stick to standards for a change. :wink:

ewen :slight_smile:

#16

Ewen,

It would be nice indeed. Oh well, at least the problem is solved. I hope that oldshep sees this thread. I’ll bet dollars to donuts that he has fios also. Thanks for all of your input. You’ve been very helpful.

Bob

#17

NP Bob, glad to be of assistance.

ewen :slight_smile:

#18

Trying to track this down myself - just switched over to FiOS today and noticed these packets. Fired up a netcat listener on the ports and caught this config file on the 21302 port:

2 3 0 0 001xxxxxxxxx 169.254.1.126 Master 00xxxxxxxxx 2 1 1 1 02.69 Yes SDonly 0

The FiOS router is using my existing coax - plugged in via the MoCA (Multimedia over Coax) port. Seeing the “MocaNodeID” in the config file leads me to believe it’s all tied into together…

Not sure why the IP address is showing up from 169.254.x.x range - this is the range generally assigned to a NIC when it can’t get an IP from a DHCP server or some such (APIP - Automatic Private IP range).

Haven’t caught anything on the UDP port 5000 yet.

Still doing some research - will post more if I find more.

#19

Ok - another link here: http://www.usbjtag.com/bdmjtagbb/viewtopic.php?t=871 refers to this type of config as being used between a Verizon STB (Set Top Box) and a DVR box. I only have the one STB (no DVR), so I can only assume the STB is trying to contact a DVR and pass it’s config info.

Going to let this rest for now, but it is annoying to see yet more worthless traffic on my lines…

#20

Read thru this fairly fast so forgive me if you have already posted the info about having a router.

If you have a router w/built-in dhcp server then you might try adding the MAC addresses from those devices to the router allowed MAC address list and it might let them get an IP.

Just something to try.

jasper