What is this stuff in my logs?

I've got a Windows 2000 computer and a Windows XP computer (both of which are running CHX), as well as a Windows 98 computer on my home network.

Over the last week the CHX log on the XP computer has been showing quite a few instances of ICMP packets (type:10 code:0) from the 98 computer to IP address 224.0.0.2 (with destination MAC set to 01:00:5E:00:00:02). They are always sent in groups of 6 (3 pairs at a time, and each pair is sent 3 seconds apart). The really strange thing is that I have the same CHX rules on my 2000 and XP computers, but the CHX log on the 2000 computer doesn't show these packets. Only the XP log is showing them. Is CHX on my 2000 computer allowing them to come in? And why is the 98 computer all of a sudden sending them (it never did this before last week)?

Also, the CHX logs are showing that sometimes the 2000 and XP computers send packets from seemingly random ports to 255.255.255.255 port 67. It's anywhere from 1 to 3 packets at the exact same time, and the source ports are close together -- like 1597, 1598, 1599... or 1835, 1836, 1837... or 1094, 1096. Are these DHCP packets (since they are being sent to port 67)? But then why aren't they coming from port 68 instead of these random ports?

 

224.0.0.2 is an IGMP multicast address used for sending routing updates or finding out what routers are available. If your systems are on a single LAN then you can block this if you wish - it most likely started due to a change in your PCs routing setup (e.g. if you enabled RRAS - see Microsoft: ICMP Router Discovery).

Looks like a DHCP broadcast and should be normal. It is sent to the limited broadcast address (255.255.255.255) in cases where the PC doesn't know what the address of the local DHCP server is (normally on power-on).

Typically, DHCP broadcasts should have source IP address 0.0.0.0 and source port 68 (BootPC) as noted in Microsoft: Windows NT Appendix D: DHCP Packets. However there have been extensions added to DHCP since (e.g. Proxy DHCP for the Preboot Execution Environment) so if your systems support something like this, that may be the reason.

 

Thanks for the reply, Paranoid. The only thing that I'm still puzzled about is why those packets to 224.0.0.2 get logged by my XP machine, but not my 2000 machine. They have the same rules.

 

Hi delerious,
I can confirm that win2000 setup, IGMP is allowed through (with CHX3) unless a specific rule is in place to block these.
Place a rule on the NIC to block these, if they are of concern.

 

Hi

One remark:

IGMP packets to IP IGMP.MCAST.NET=224.0.0.22 are used by SSDP but also by applications like : VideoLan Player (VLC) and Azureus ...

 

@delerious,

I have setup on XP to check against what I have seen for IGMP in W2K. I currectly have the same result, where IGMP is being allowed in without a specific rule to deny.

What is showing in the logs of XP_PC for IGMP, are these outbound or inbound that are logged?(please post a log entry showing this).

 

Hi Climenole,
I did not mean to ignore your post, I am just looking at the logging/packets allowed/blocked by CHX, not what may be making these comms (at this time),

Regards,

 

Is this a bug in CHX? It should not be allowing these unsolicited packets if I have the ICMP stateful inspection turned on. And actually, those packets shouldn't even get to the SPI, because my Allow ICMP rules do not allow type 10 coming in.

EDIT: I notice you guys are saying that they are IGMP packets, but CHX on my XP machine says the protocol is ICMP?

The log entries on the XP machine are all the same. Each one looks like this:

direction: Incoming
source MAC: my 98 machine
destination MAC: 01-00-5E-00-00-02
protocol: ICMP
flags: Type:10 Code:0
source IP: my 98 machine
source port: blank
destination IP: 224.0.0.2
destination port: blank
packet size: 42
reason: Does not match allow policy

 

If the W2K_PC is allowing these in, then it looks more of a rules problem. I have checked with the ICMP tpye, and these are blocked on my W2K and XP setup as "Unsolicited".
I will need to look at your ruleset, as it looks like the problem may be with you filtering in both directions with various rule types.

 

Here are my rules. All of them are set to "Lowest" priority. All of the ICMP rules are set to "Any" for the MACs, IPs, and Ports. Let me know if you need more details.

- allow incoming ARP
- allow incoming ICMP (type: 3, code: any)
- allow incoming ICMP (type: 0, code: 0)
- allow incoming ICMP (type: 11, code: 0)
- allow incoming TCP without SYN flag
- allow incoming UDP
- deny incoming UDP from non-router addresses to 192.168.1.255 on ports 137/138
- deny incoming UDP from the router address to 192.168.1.255 on port 520
- deny outgoing ICMP (type: any, code: any)
- force allow incoming UDP from the router address port 67 to port 68 (only on the condition that there was an outgoing UDP connection from port 68 to port 67)
- force allow outgoing ICMP (type: 8, code: 0)

 

Hi delerious,

Sorry for delay in reply.

I have not been able to reproduce your exact problem, but from checks/tests I have made today, I am seeing some anomalies, most are blocked packets (in/out) shown as illegal flags (but flags correct) and out of connection (when not). These do not normally show on my setups as I only normally use the internet for browsing.(I have been looking at how CHX handles 200+ connections)
I have also seen that CHX is not reacting the same, with the same rulesets between W2K and XP, so as you have mentioned, there may be a bug/problem.

I am now testing with later drivers, copies of which where posted here, the first hour of testing shows good results, but I still need to check them out fully. You could try them on your W2K setup (but keep the old drivers as backup).

We do still need to change your rules, but please try those drivers first.

 

I will try the updated drivers within the next couple days and let you know if I still see that problem.

 

We can go through your ruleset first if you prefer. As you can simplify the rules, and I cannot understand the 2 rules:-

as these rules are blocking ports to a broadcast address. Are you filesharing on LAN?

 

Stem: the first rule you quoted I think is for Netbios packets that my Windows 2000 and XP machines broadcast over the network. I am not using filesharing, so I have that rule to block those packets.

The second rule is for RIP packets broadcast by my router. I don't think I need to respond to those, so I block those too.

Were you able to see the anomalies that you mentioned with the latest drivers? Or did the latest drivers fix those?

 

I think we need to take some time to go through how CHX SPI fuctions. As example, netbios would be allowed out from your PC with your current ruleset, but inbound would be blocked as unsolicited (even without the rule to block the inbound broadcasts), so basically, if you have netbios enabled on your pc, then it can connect out to other PC`s.

I have seen some improvements due to replacing the drivers, but I did find that I had a conflict with another ndis driver I had installed, so I need to start my tests again (without my own ndis driver installed)

 

Oh yeah, you're right. Even if I didn't have those 2 rules, those packets would be blocked as unsolicited. The reason I put those rules in is because I don't want them to fill up the log (each rule has the "disable log" box checked).

 

Stateful logging is in the "Properties" of the NIC interface(or global), Have you enabled this?

 

Yes I have enabled stateful logging. I want to be aware of traffic that might be getting sent to my computer. Even if it's not malicious, at least I can learn more about networking that way. And if there's too much of something, I can add rules to block it without logging.

 

Hi Stem, I've finally updated those 2 .sys files in my CHX installation. I did that on both my Windows 2000 and XP machines.

I still have the same problem - the XP log shows that it is blocking ICMP packets (type 10 code 0) from my 98 machine going to 224.0.0.2. The 2000 log doesn't show those packets.

Also, did you redo those tests to see if the latest CHX drivers would fix the anomalies you mentioned?

 

Hello delerious,

I have still been unable to reproduce this. It could be a conflict/problem on that PC. You could try changing your ruleset to see if that helps (try the Wan_start). Save your own ruleset first of course

It did help, but the problem was really due to some drivers I had installed (my own fault)

 

So there are no anomalies? That's good to hear. It had sounded like CHX had a lot of bugs.

 

On my setup, the problems I had where certainly due to the software I am writing/testing (I now know). My drivers where in conflict with the CHX drivers (some packets intercepted by CHX first, other by my drivers, and tagged,.. the taggs making CHX block the packets as out of connection. We live and learn.