Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 2 subscribers
  • Views 4368 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How to Stop UDP 14675 waterfall

HMaster
After months and months of teethgrinding and not finding a good solution, I now realy want to know what to do about a few problems I find in my UTM.

I have a NAS disk in my network configured with static IP / DNS / Gateway ip's . 
But something in this system is is continiously poking on the 255.255.255.255 broadcast adress. And this is driving me crazy.
 I would like to know what can be done about the constant flow of UDP pokes on port 14675 ??? There are pokes on the UDP 137 and 138 also. 

I tried firewall rules but this didn't help. 
I have NO WINS server installed (on windows2008) and the DHCP setting in my UTM (UTM is DHCP server) 
has wins on 0.0.0.0 and WINS Node type: B-Node (no WINS)

Here are the results of Network Protection on my UTM dashboard.
Source:
Total dropped packets: 28 226 
host: 192.x.x.x 
packets: 27130 
percentage: 96.12%

Destination:
Total dropped packets: 28 226 
dest1: udp/14675
destination: 255.255.255.255
packets: 25656
percentage: 90.89% 

dest2: udp/137
destination:  Internal (LAN) (Broadcast)
packets: 1080
percentage: 3.83 %
 
UTM Version: 9.105-9


This thread was automatically locked due to age.
  • 0
    UDP 137 and 138 are netbios ports. Probably your NAS is attached to your AD Domain. It may be looking for a domain controller and therefore generate this traffic.
  • 0
    If 192.x.x.x is your NAS device, then it wants something that it's not getting.  I bet there's an incomplete configuration at 192.x.x.x.

    Cheers - Bob
  • 0

    I tried firewall rules but this didn't help. 


    Hi,

    The firewall is already dropping the traffic; that's why you see it in the logs.
    If you don't want it to be logged, you need to create a new firewall rule (with logging off) and a new Network HOST Defintion for the global broadcast address (255.255.255.255)

    There's an example at:
    https://community.sophos.com/products/unified-threat-management/astaroorg/f/51/t/20791

    I don't know what port 14675 is, but you can drop it anyways.

    Barry
  • 0
    Well this is a little grab out out the life log from the firewall.

    The IP is from the NAS which is causing troubles. The dstmac's are both NIC's of the UTM firewall.  

    12:30:34 Spoofed packet UDP 192.168.x.x : 50342 

     → 255.255.255.255 : 14675 

     len=74 ttl=64 tos=0x00 srcmac=0:a[:D]8:2:c:38 dstmac=0:2:55:b7:20:e7 

     

    12:30:34 Default DROP UDP 192.168.x.x : 50342 

     → 255.255.255.255 : 14675 

     len=74 ttl=64 tos=0x00 srcmac=0:a[:D]8:2:c:38 dstmac=0:2:55:b7:20:e8 

     

    12:30:38 Spoofed packet UDP 192.168.x.x : 37816 

     → 255.255.255.255 : 14675 

     len=74 ttl=64 tos=0x00 srcmac=0:a[:D]8:2:c:38 dstmac=0:2:55:b7:20:e7 

     

    12:30:38 Default DROP UDP 192.168.x.x : 37816 

     → 255.255.255.255 : 14675 

     len=74 ttl=64 tos=0x00 srcmac=0:a[:D]8:2:c:38 dstmac=0:2:55:b7:20:e8 

     

    12:30:41 Spoofed packet UDP 192.168.x.x : 45315 

     → 255.255.255.255 : 14675 

     len=74 ttl=64 tos=0x00 srcmac=0:a[:D]8:2:c:38 dstmac=0:2:55:b7:20:e7 

     

    12:30:41 Default DROP UDP 192.168.x.x : 45315 

     → 255.255.255.255 : 14675 

     len=74 ttl=64 tos=0x00 srcmac=0:a[:D]8:2:c:38 dstmac=0:2:55:b7:20:e8 

     

    12:30:44 Spoofed packet UDP 192.168.x.x : 45909 

     → 255.255.255.255 : 14675 

     len=74 ttl=64 tos=0x00 srcmac=0:a[:D]8:2:c:38 dstmac=0:2:55:b7:20:e7 

     

    12:30:44 Default DROP UDP 192.168.x.x : 45909 

     → 255.255.255.255 : 14675 

     len=74 ttl=64 tos=0x00 srcmac=0:a[:D]8:2:c:38 dstmac=0:2:55:b7:20:e8 

     

    12:30:47 Spoofed packet UDP 192.168.x.x : 40523 

     → 255.255.255.255 : 14675 

     len=74 ttl=64 tos=0x00 srcmac=0:a[:D]8:2:c:38 dstmac=0:2:55:b7:20:e7 

     

    12:30:47 Default DROP UDP 192.168.x.x : 40523 

     → 255.255.255.255 : 14675 

     len=74 ttl=64 tos=0x00 srcmac=0:a[:D]8:2:c:38 dstmac=0:2:55:b7:20:e8 

     

    12:30:50 Spoofed packet UDP 192.168.x.x : 46999 

     → 255.255.255.255 : 14675 

     len=74 ttl=64 tos=0x00 srcmac=0:a[:D]8:2:c:38 dstmac=0:2:55:b7:20:e7 

     

    12:30:50 Default DROP UDP 192.168.x.x : 46999 

     → 255.255.255.255 : 14675 

     len=74 ttl=64 tos=0x00 srcmac=0:a[:D]8:2:c:38 dstmac=0:2:55:b7:20:e8 

     

    12:30:53 Spoofed packet UDP 192.168.x.x : 41945 

     → 255.255.255.255 : 14675 

     len=74 ttl=64 tos=0x00 srcmac=0:a[:D]8:2:c:38 dstmac=0:2:55:b7:20:e7 

     

    12:30:53 Default DROP UDP 192.168.x.x : 41945 

     → 255.255.255.255 : 14675 

     len=74 ttl=64 tos=0x00 srcmac=0:a[:D]8:2:c:38 dstmac=0:2:55:b7:20:e8 

     

    12:30:56 Spoofed packet UDP 192.168.x.x : 59583 

     → 255.255.255.255 : 14675 

     len=74 ttl=64 tos=0x00 srcmac=0:a[:D]8:2:c:38 dstmac=0:2:55:b7:20:e7 

     

    12:30:56 Default DROP UDP 192.168.x.x : 59583 

     → 255.255.255.255 : 14675 

     len=74 ttl=64 tos=0x00 srcmac=0:a[:D]8:2:c:38 dstmac=0:2:55:b7:20:e8 

     

    12:30:59 Spoofed packet UDP 192.168.x.x : 51239 

     → 255.255.255.255 : 14675 

     len=74 ttl=64 tos=0x00 srcmac=0:a[:D]8:2:c:38 dstmac=0:2:55:b7:20:e7 

     

    12:30:59 Default DROP UDP 192.168.x.x : 51239 

     → 255.255.255.255 : 14675 

     len=74 ttl=64 tos=0x00 srcmac=0:a[:D]8:2:c:38 dstmac=0:2:55:b7:20:e8 

     


    I created a new firewall rule:

    Source: 192.168.x.x 
    Service: 1:65535 dest 14675
    Destination: Broadcast 255.255.255.255 / 255.255.255.255
    Top 
    No Log
  • 0
    The message spoofed packet seems to indicate that your nas either has an (extra) ip-address in a different subnet or maybe you have another host with the same mac and/or IP-address.
    Spoofing means that the host is trying to imitate being someone else.
  • 0
    Hmzzz.... Well I have something to check at home I think. 
    MAC and or IP's are easy to check. I don't have that many systems running, so this will be not so difficult. 

    Ik zal eens ruzie maken met de zut thuis ;-)
  • 0
    Is it possible that you have bound the network definition to an interface? I recall Bob's rule #1 to never bind an object to an interface unless ... (I don't know a use case ....)

    Regards
    Manfred
  • 0
    OT, but one use case example is the 'Internet' definition; it is bound to the WAN interface, iirc.

    Barry
  • 0
    Right, Barry, that's one of the few valid uses.  If you don't have spoof protection enabled, you can use bound definitions for source definitions to prevent spoofed IPs from gaining access they shouldn't have.  For all other uses, I think that an Additional Address on an Interface is the correct solution.

    @HMaster - It also appears that your physical network has a problem.  Each broadcast hits two UTM interfaces.  This means the Ethernet segments are not isolated from each other.  This will cause strange problems.

    Cheers - Bob