Let suppose i trap this in my syslog,

[**] [1:1384:2] MISC UPNP malformed advertisement [**]
[Classification: Misc Attack] [Priority: 2]
12/01-15:25:21.792758 192.168.1.1:1901 -> 239.255.255.250:1900
UDP TTL:150 TOS:0x0 ID:9 IpLen:20 DgmLen:341
Len: 321
[Xref => cve CAN-2001-0877][Xref => cve CAN-2001-0876]

what does that means, 192.168.1.1 is trying to exploit some machine or that machine is vulnerable to this? my personal guess is, 192.168.1.1 is trying to exploit.

Another question, most of the expert mentioned on different forums about mis reporting, especially the example i mentioned, while Microsoft give it "Risk Level: High". So what would be the next step, would you deploy the patch on all of your machines, & investigate about this attempt or remove this from the rule?

OK, let's review what you know (or at least my best guesses-IANAE!):

[QUOTE=Fracker;3507027][**] [1:1384:2] MISC UPNP malformed advertisement [**]
[Classification: Misc Attack] [Priority: 2]
[QUOTE]
So, something is advertising a UPNP service and the packet is malformed.

The packet is going from your network (193.168.1.1; is this your router, or something?) to 239.255.255.250 (probably a universally-used address for UPNP; I don't know about UPNP, but mdns and icmp do something similar).

Note that it is going from port 1900 to 1901, which sounds like an organised pair of ports for the interaction; you may be able to get somewhere by looking up what that pair of ports is traditionally used for.

My guess is not. My guess is that there is some service that is supposed to run on, eg, your router that is part of UPNP that is putting out some packets that are being recognised as malformed. Now whether this means the packets are actually bad/malaevolent is another matter; it could just be one of those circumstances in which there are different interpretations of the specification and some supplier has come up with some variant definition of how it is supposed to work. Err, quasi-monopoly proprietary suppliers who like to 'embrace and extend' are particularly likely to encourage this kind of nonsense, as are suppliers of networking gear who think that the whole world uses one operating system and therefore are happy to put out kit that 'works without error messages' when used with the majority OS rather than 'kit that meets the publically available specifications'.

So, while I can't be sure, and while it does seem worth further investigation I wouldn't jump to the conclusion that there is something 'mal' going on until you have investigated further. My guess is that this is unlikely to be an exploit, but that is only a guess and you really should find something better than a guess.

And note that this traffic is occuring on your internal network (even though it doesn't sound like it should be there; think about it, you wouldn't be seeing this packet unless it was on your network; if I understand what you have written, you aren't snooping the external network), so you might be advised to block off this port as a temporary measure if you are still concerned about it. And have you tried anything other than Snort to check whether the consensus is that this is a malformed packet? If, eg, wireshark, doesn't recognise it as malformed, I would then be trying to find out whether Snort is getting this right (is this the latest and greatest' Snort, for example?).

What patch??? You didn't mention a patch until now.

To know what's going on you should dissect the loglines. At least then you've got something to work with. So tell us:
- What clues does the warning title give? (protocol, terms)
- What is the flow of the traffic? (>ingress, egress>, host to host, host to b'cast)
- What do the references say about the warning? ([1], [2] might help)
- Can this type of traffic reach machines you admin unfiltered?

There are several references you can use to attempt to gain some knowledge of this specific signature:

What you're seeing is a networked machine that is polling for other UPNP-enabled network devices. This alert is specific to Windows-based operating systems. It is usually seen within internal networks. The danger is that if an internal machine is somehow infected with Zotob, the infection could spread to other internal machines via UPNP as a vector.

If your router has this enabled and you know that you don't have UPNP devices within your LAN, disable this feature. If you do have UPNP devices on the network, then mitigate the risk by ensuring you don't allow such inbound polling (that is, drop all external UPNP traffic that is directed to your network). Also, turn off this feature on all Windows-based machines unless you absolutely need it.

Note that there are some network devices such as gaming consoles (Xbox/PS3) that utilize UPNP to simplify network connectivity. Turn off those features unless you absolutely need them.

You can also disable this rule if you deem that it is unnecessarily spamming you with alerts or if you know that you've secured your network against real UPNP threats.

If you don't want to disable, you can look into thresholding the alerts (for instance, instead of getting 1000 alerts in a 24-hr period, you'll get, for example, one alert that may triggered based on a setting of 1 alert for every 10 triggers of the signature).