UDP IN/OUT transfers to/from port 4480, related to 2nd instance of SVCHOST.EXE

Hi,
Since this week I have been checking the Active Connections feature of Comodo CIS (free ed), and have noticed a number of UDP connections to a second instance of the SVCHOST.EXE process. The first one, which is only and always listening to port 135 with TCP, I have never seen get a single bit, in all these days of on and off checking.

At first the UDP traffic was made up of port 1021? attempts at using the notorious non-MSN Windows Messenger, which were easily blocked, and now never appear, even without a rule explicit banning them. But now I keep getting these connections to/from my port 4480, which is not assigned to any application or service according to the IANA official list at
http://www.iana.org/assignments/port-numbers

But by Googling, I found that this port is associated with a proxy called Forteproxy, that I am not using - I only use privoxy, which is not a real proxy, as it only filters out ads and pop up window code out of webpages. Using Wireshark to check on the packets going through there, I found that there’s a lot of Teredo IPv6 traffic from IP’s that a whois shows to be from Microsoft. These packets are all echo requests and “Malformed packets”… I suppose the latter means the data is corrupted. Googling on this I found that these are requests related to “4to6” IP address translation, so I suppose there’s no harm there. But there are plenty of packets with data that are not IPv6, not Teredo, and come from IP’s in Europe. I confess I am using bittorrent, but these non-MS port 4480 IP’s don’t match with those connected to by bittorrent client - they are only within the same domain. There’s no way of deciphering what kind of data is being transmitted on each of these packets, at least not according to the raw ASCII WS lets me see.

I have tried banning UDP traffic and banning port 4480 for the SVCHOST using CIS app rules, but every time COMODO adds two rules allowing all traffic, rendering my own rules useless. I have also checked the processes behind the SVCHOST using the MS TASKLIST cmd line app, but googling them, I found all of them are all legit MS Win procs. Any idea about what is going on?

MS Win XP Home SP 3 (with all latest WinUpdt patches)
Pentium 4 2.80 Ghz
1 GB RAM, 40 Gb HDD
NVIDIA GEFORCE FX 5200
D-LINK DFE-530TX PCI Fast Ethernet Adapter (rev C)

apps I have running: µTorrent 1.8.2
Privoxy 3.0.6
Firefox 3.0.11
Comodo CIS 3.9.95478.509 Virus Sign. DB. V.: 1381
World Community Grid - BOINC client v. 6.2.28
Spybot 1.6.4.26
Daemon Tools: 4.30.4.0027

Welcome to the forum.

The first one, which is only and always listening to port 135 with TCP, I have never seen get a single bit, in all these days of on and off checking.

Port 135 is the Microsoft RPC Endpoint mapper also known as DCOM. On Windows client OS, unless you are part of a Domain, this has very little use and can be safely blocked in the firewall.

At first the UDP traffic was made up of port 1021? attempts at using the notorious non-MSN Windows Messenger, which were easily blocked, and now never appear, even without a rule explicit banning them. But now I keep getting these connections to/from my port 4480, which is not assigned to any application or service according to the IANA official list at

It’s likely the traffic you are seeing on 1021 is standard stuff. Windows messenger spam tends to be on much higher ports. Disable the service and create a block rule without logging to hide the events.

I found that there's a lot of Teredo IPv6 traffic from IP's that a whois shows to be from Microsoft

Teredo uses port 3544. Do you have the XP IPv6 stack installed?

I confess I am using bittorrent

What port number is uTorrent assigned to use?

I have tried banning UDP traffic and banning port 4480 for the SVCHOST using CIS app rules, but every time COMODO adds two rules allowing all traffic, rendering my own rules useless

Create an entry for svchost, add the allow rules at the top and block rules at the bottom, with or with out logging. CIS reads the rules from the top down and responds to the first match. You could, alternatively, create a Global rule to block the packets, again with out logging.