It has been noticed by some people that some Windows 2000, (and Windows XP, and Windows Server 2003) etc machines send a multicast packet to group address 239.255.2.2. I have some information on this subject... I hope it will be of use.
In summary I do not believe that these packets create any security risk.
Alan J. McFarlane
It is a UDP packet destined to IP Group Address 239.255.2.2 and port 9753. The data content of the UDP packet is "Hostname=" followed by the PC's hostname (and then a LF and a NUL). The multicast address 239.255.2.2 is registered at IANA's Multicast Addresses list as "rasadv" i.e.
... 239.255.000.000-239.255.255.255 Site-Local Scope [Meyer,RFC2365] 239.255.002.002 rasadv [Thaler]Note also that the address is within the "IPv4 Local Scope" range [RFC2365], that is the range 239.255.0.0 to 239.255.255.255 (i.e. 239.255.0.0/16). Traffic destined to destinations should be kept within a 'local' area, and certainly within a physical site.
Port 9753 is defined in the Port Numbers list also as "rasadv" i.e.
... rasadv 9753/tcp rasadv rasadv 9753/udp rasadv # Dave Thaler <dthaler@microsoft.com> ...
A packet as captured by Netmon (on my PC's LAN interface) is shown here:
Frame Time Src MAC Addr Dst MAC Addr Protocol Description Src Other Addr Dst Other Addr Type Other Addr
3 1136.811782 LOCAL USC IN7F0202 UDP IP Multicast: Src Port: Unknown, (1034); Dst Port JYRAALAN2K 239.255.2.2
+ Frame: Base frame properties
ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ ETHERNET: Destination address : 01005E7F0202
+ ETHERNET: Source address : 100000112233
ETHERNET: Frame Length : 63 (0x003F)
ETHERNET: Ethernet Type : 0x0800 (IP: DOD Internet Protocol)
ETHERNET: Ethernet Data: Number of data bytes remaining = 49 (0x0031)
IP: ID = 0x1F4D; Proto = UDP; Len: 49
IP: Version = 4 (0x4)
IP: Header Length = 20 (0x14)
IP: Precedence = Routine
IP: Type of Service = Normal Service
IP: Total Length = 49 (0x31)
IP: Identification = 8013 (0x1F4D)
+ IP: Flags Summary = 0 (0x0)
IP: Fragment Offset = 0 (0x0) bytes
IP: Time to Live = 15 (0xF)
IP: Protocol = UDP - User Datagram
IP: Checksum = 0x6A9E
IP: Source Address = 192.105.90.102
IP: Destination Address = 239.255.2.2
IP: Data: Number of data bytes remaining = 29 (0x001D)
+ UDP: IP Multicast: Src Port: Unknown, (1034); Dst Port: Unknown (9753); Length = 29 (0x1D)
00000: 01 00 5E 7F 02 02 10 00 00 11 22 33 08 00 45 00 ..^...........E.
00010: 00 31 1F 4D 00 00 0F 11 6A 9E C0 69 5A 66 EF FF .1.M............
00020: 02 02 04 0A 26 19 00 1D BE 38 48 6F 73 74 6E 61 ....&...¾8Hostna
00030: 6D 65 3D 74 68 65 70 63 73 6E 61 6D 65 0A 00 me=thepcsname..
(Personal information in the trace has been changed i.e. source MAC and IP address and hostname).
Monitoring shows that a packet is send once per hour.
It is presumed that the packets are sent to advertise that the local machine is running RAS/RRAS (that is "[Routing and] Remote Access Server" for any non-Microsoft aware readers). No documentation of this has been found however.
This behaviour is useful in a corporate network where it will allow administrators to detect any Windows machines that are running RAS. Unauthorised RAS devices create a very dangerous security risk, no use in having that super-duper firewall if people can dial-in to your network through some unprotected RAS device.
It appears that the netsh tool within Windows
can be used to show the advertising RAS servers. It has a command
show activeservers within the ras context that
will display any advertisements received. It listens on the multicast
address and will thus receive any of these advertisements sent on the
'Local Scope' network. For instance:
C:\>netsh netsh>ras ras>show activeservers Timestamp Sender ------------------------ ---------------------------------- Tue Dec 10 18:36:49 2002 192.105.90.102 (thepcsdnsname.example.com) Hostname=thepcsname
There is a tool in the Resource Kit called raslist.exe
that serves a similar purpose. When run, it produces initially:
C:\>"\Program Files\Resource Pro Kit\raslist.exe" RASLIST - list of RAS servers on the net press <ESC> to exit Initializing... Ready to receive RAS announces on LANA0
The LANA0 identifier suggests to me NetBIOS use, which is
odd. Anyway on my machine when I use it I do not see the IGMP Report
appear on my active LAN card, this is likely due to the machine having
multiple NIC and dial-up connections defined (if not active).
It is probably best to use the netsh version.
Note: As for all Multicast receive usage, if you are running a packet sniffer or a personal firewall that logs such outgoing traffic, when you run either of the commands you will (should) see an IGMP Membership report packet for the group (i.e. 239.255.2.2) being sent. This is the Internet Group Management Protocol being used to tell the network that this machines wants to receive traffic on the 239.255.2.2 multicast group. If your network is multicast enabled then your machine will start to receive the advertisement from the machines running RAS on your network. You also will continue being sent regular IGMP Membership Query packets from the elected Multicast router on your network, your machine will send the same Report in reply to each. If your network is not multicast enabled then you will only receive advertisement from machines on the same LAN segment.
If you are connected directly to the Internet, whether through dial-up, CableModem, xDSL, you may be worried that the sending of this packet poses some security risk to you.
Firstly I do not hold to the idea that a device is safer if arbitrary machines on the Internet cannot detect its presence. If an attacker is going to run an attack, he just runs the attack on the given service on a large arbitrary set of addresses. He does not bother to attempt to find which machines are active by Pinging etc. Nor is it worth trying to find out by secondary means whether a particular service is active, just attack the service and see if it responds or fails...
As this packet is being sent to a group address it requires that a Multicast enabled network exists to forward it. A router that does not have special multicast configuration applied will not forward such packets. I personally know of no ISPs that have multicast enabled their network. If any have it is likely that they are set up to deliver multicast to the clients but not allow them to send multicasts. You would have to be specifically authorised to send multicast packets through its network. Usually the first router (remote access device, CMTS, DSLAM etc) will not forward multicasts and will just drop them. As noted in the What section the group address used by these packets should restrict the delivery of them to within the local site. The only receiver of these packets could thus be the ISP itself and only then if they have carried out special configuration on the first hop router.
Now lets look at what information the packets might expose. There are four pieces of information possibly exposed
The first three pieces of information will be provided already to your ISP at connect time; for dial-up though PPP negotiation and on Cable Modem etc through DHCP. So it does not provide any new information.
The information that RAS is running is the only piece of new information being exposed to your ISP. The fact that you are running RAS is not terribly useful anyway, to try an attack dial-in they will have to know the phone number of the attached modem.
I thus feel that the risk created by these packets is low to non-existent.
It has also been pointed out to me that RRAS could be being used to accept VPN connections from the Internet. This creates a different risk from when only modems are being used: there is no need to know the phone number that the modem is attached to...
For a long while I was not seeing any of these packets from RRAS even though RRAS was running. At the time I had no modem devices configured, but was just using the IrNet ("Infrared Port") connection type. So, does RRAS only send the rasadv packets when a modem is configured, or was I just not seeing them because I wasn't looking hard enough..., or was something else at play...? Anyway they have returned now.
Later. Of course, after all that waffling about them disappearing and reappearing, they have now disappeared again.
This feature also exists in Windows XP, and I've had a report that this feature exists in Windows Server 2003 (thanks).