Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Our primary DNS server (as dictated by our DHCP configuration) is running Windows Server 2008 R2 and is also one of our Domain Controllers.

In its Security event log we can see that there are hundreds of Failure Audits in the Filtering Platform Packet Drop category where client machines seem to be "spamming" our server with NetBIOS packets and also bizarre high-number-port UDP packets.

When using CurrPorts, I can see that the local ports the high-number-port UDP packets are directed at are registered to the DNS service. The strangest thing about them though is that the destination is 255.255.255.255.

One such example is:

The Windows Filtering Platform has blocked a packet.

Application Information:
    Process ID:     0
    Application Name:   -

Network Information:
    Direction:      Inbound
    Source Address:     <a client/workstation address>
    Source Port:        51515
    Destination Address:    255.255.255.255
    Destination Port:       51515
    Protocol:       17

Filter Information:
    Filter Run-Time ID: 69825
    Layer Name:     Transport
    Layer Run-Time ID:  13

This is a NetBIOS one:

The Windows Filtering Platform has blocked a packet.

Application Information:
    Process ID:     0
    Application Name:   -

Network Information:
    Direction:      Inbound
    Source Address:     <a client/workstation address>
    Source Port:        137
    Destination Address:    <DNS server's address>
    Destination Port:       137
    Protocol:       17

Filter Information:
    Filter Run-Time ID: 69825
    Layer Name:     Transport
    Layer Run-Time ID:  13

I'm not sure why NetBIOS name resolution is being blocked...

I haven't done any packet captures to see what the above packets destined for DNS contain yet as I would have to disable the firewall to be able to do so.

As far as I can see I have the following options:

  • Add a firewall exception to allow the traffic (but why are we getting it in the first place?)
  • Investigate the client machines to see why and what they are sending out
  • Ignore the traffic?

There are more failure audits containing this network spam in the Security log of our DC than actual authentication logging from its AD role...

Has anyone seen anything similar to this before?

EDIT 2011-07-26: We're also experiencing the following on the same server which could be related. I'm not sure why outbound ICMP packets would be being blocked, especially at the Layer Name "ICMP Error"...

The Windows Filtering Platform has blocked a packet.

Application Information:
    Process ID:     0
    Application Name:   -

Network Information:
    Direction:      Outbound
    Source Address:     10.2.0.240
    Source Port:        0
    Destination Address:    10.2.1.46
    Destination Port:       0
    Protocol:       1

Filter Information:
    Filter Run-Time ID: 69827
    Layer Name:     ICMP Error
    Layer Run-Time ID:  32
share|improve this question
    
I have to say that neither log entry makes sense. In the first one the destination address is the layer 2 broadcast address (255.255.255.255) not the DNS server address, and the destination port is not DNS. So how is it that the DNS server is listening for incoming DNS queries on port 51515? In the second one the destination port is NBNS but surely the source port wouldn't be the same? –  joeqwerty Jul 25 '11 at 12:55
    
Im glad you share my confusion. DNS on both our DNS/AD servers are listening on high numbered ports, but why computers are attempting to broadcast to it is beyond me... –  Ashley Steel Jul 25 '11 at 19:07

2 Answers 2

up vote 1 down vote accepted

I've enabled the Windows Firewall policy to allow traffic on 137 and 138, as those should be allowed - after doing some investigation it doesn't seem like there's anything untoward going on.

As for the other higher ports, I've discovered the applications on the network which are sending the other traffic I mentioned and will look at blocking them at the client-side.

Firstly, there was a lot of traffic coming from UDP port 17500 - this is used by Dropbox to discover other Dropbox clients in the network to perform network sync, thereby eliminating Internet transfer between users within the same network. We have a few staff members who use Dropbox for personal things, hence the network noise from that.

The other, 51515 was coming from Winamp on one machine. I'm yet to discover what Winamp is broadcasting like that for, but I'll post/edit soon if I figure it out.

As for removing the noise from the event log, I'll be using this command:

  auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:disable /failure:disable

How failure auditing got turned on in the first place - I'm not sure!

share|improve this answer

It's probably the AjaxAMP plugin for Winamp.

Even when the AjaxAMP server is disabled and stoped, it sends out broadcasts every second or so:

01:16:28.361965 IP 192.168.1.77.51515 > 255.255.255.255.51515: UDP, length 38

Remove the AjaxAMP plugin completely (Winamp will restart) and it should all go away.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.