I never noticed this before, but the log is showing Windows Operating System blocked several connection attempts UDP protocol from CIS servers source port 4447.
I created an allow rule for this, but I don’t understand what that traffic is for.
I never noticed this before, but the log is showing Windows Operating System blocked several connection attempts UDP protocol from CIS servers source port 4447.
I created an allow rule for this, but I don’t understand what that traffic is for.
The traffic is for the cloud look ups CIS does. It uses ports:
TCP 4446
UDP 4447
What IP addresses is the traffic coming from?
Yeah, I’ve noticed cmdagent initiated TCP/UDP traffic going out to 208.116.56.20/208.116.56.26 on dest port 4446/4447
I’ve never seen that traffic inbound though. This is the first time I’ve seen any inbound traffic from Comodo. Windows Operating System blocked UDP from 4447 from those servers.
After creating the allow rule for UDP in from CIS servers, it became necessary to create rules for ICMP in t8, c0 from modem, t3, c3 out to modem & to CIS servers. Its been running fine since April w/only global rules for ICMP; now I need 'em also for Windows Operating System. Ya gotta do what ya gotta do, but still.
Does this mean that my PC is part of the cloud computing?
I’m also now getting the same UDP In traffic from those servers coming from port 4447. It tends to happen when I turn the computer on for the day, 3 to 8 attempts and then slows down to one every couple of hours or so.
CIS isn’t showing an alert for it. How are we supposed to respond to them because obviously the CIS servers are sending these request for a purpose?
There’s no point allowing for it in the rules because it isn’t stateful, no application is expecting it as far as I can see.
Any inbound connection would be statefull once established. Moreover, setting up the allow rules from CIS servers eliminates the messages from showing up in the log. Its just that the additional ICMP rules wree necessary to duplicate for ‘Windows Operating System’; they previsously lived as global rules and ‘Windows Operating System’ didn’t exist as a network security policy. This must be a result of some program update that recently occurred. I’d been running v1135 and recently seen the ‘updates available’ icon in the sytem tray which I clicked on. The versoin didn’t change, but this behaviour is new.
If it was stateful then one of my rules would catch it and ask permission to allow or not. That’s how CIS is set up here.
If it is in response to the UDP outgoing events to CIS servers ports 4448 then my CIS rules would ask when the UDP incoming events are received. But this isn’t happening so CIS reports it as “Windows Operating System” which is their default fall back when it can’t find any program that is responsible.
I’ve added a rule to the Comodo Internet Security Firewall rules allowing these and logging just to see. But no, same as before as expected.
So I don’t see how they are stateful unless (and I’ve reported these issues for months now) there is such a delay between the outgoing UDP and incoming events that the ‘connection’ between them gets disconnected.