[3.8.65951.477] Firewall allows broadcast udp packet

CIS 3.5.5.57173.439, Win32 XP SP3 all patches

My app has 3 rules:

Block And Log UDP In From 172.16.1.131 To IP Any Where Source Port Is Any And Destination Port Is Any Allow And Log UDP In From IP In [172.16.1.0/255.255.255.0] To IP Any Where Source Port Is Any And Destination Port Is Any Block And Log UDP In/Out From IP Any To IP Any Where Source Port Is Any And Destination Port Is Any

my ip is 172.16.1.1
When 172.16.1.131 sends udp packet to my ip, the first rule is triggered and works fine but when 172.16.1.131 send broadcast udp packet to all - 255.255.255.255 my app receives this packet, but the first rule doesn’t work and event viewer doesn’t show this broadcast packet in firewall logs

Tested on another app and anothet port, the udp server still receives broadcast udp packet even when Ip of udp client is blocked.

Does it change if you change dst ip to 255.255.255.255 ?

Hi,

Once, a long time ago, i’v found this happening with my system too.
My PC is connected to a cable modem without any router.
Resolved when i created some global rules to explicity block incoming connections TO “ip” 255.255.255.255
In my case, those annoying connections was from my ISP, using the range 10.xxx.xxx.xxx
After all, i was with these 3 global rules added:

  • Block UDP In From IP In [10.0.0.0 - 10.255.255.255] To IP Any Where Source Port Is Any And Destination Port Is Any

  • Block UDP In From IP Any To Ip Any Where Source Port Is 67 And Destination Port Is 68

  • Block UDP In From IP Any To IP 255.255.255.255 where Source Port Is Any And Destination Port Is Any

Now everything is OK.

THIS WORKED FOR ME and maybe don’t work for another system.

I hope this helps.

(:WAV)

No.
The test is now simplifiest:
app is “Blocked Application” and listens some udp port - those packets with dst address 255.255.255.255 are passed in and succesfully displayed

the global rules works, but this is a bug

What app are we talking about ?

any usermode app that uses WinApi to listen udp port as server without kernel-mode drivers
for example svchost.exe (dhcp service)

This will be handled on the “Windows Operating System” level, try to put the block/log rule in there and see if that helps.

choose any udp client/server app what you want.
Apply to UDP server policy “Blocked application” that represents “Block and log ip in/out from ip any to ip any where proto is any”

on a remote machine by UDP client sends 2 packets to network, 1st with dst address of udp server, 2nd to all IPs

Src Dst Action(from cfp log) Received by app?
(client ip) (server ip) Blocked No
(client ip) 255.255.255.255 not present in log Yes

can you tell me why in first case the firewall works properly and logs that it was blocked this packet, but passes second packet to app and logs nothing about this? simply changing dst address to 255.255.255.255 and this is a hole in filtering

It has something to do with Application less traffic, CIS will handle this kind of traffic at the OS level and not block or alert this on “Application level” a Limited broadcast (255.255.255.255) will be handled at “System” level and there for is not to be blocked by any application.

Try this, add an new rule to the application rules, select from running process and take “Windows Operating System”
now for this rule try to “block” the limited broadcast and let’s hear if that works for you.

having “Windows Operating System” with rule
block ip in from ip 172.16.1.131 to ip any where protocol is any

and app with policy “blocked application”(it moved lower that 1st rule) - the broadcast traffic from this ip doesn’t blocked, only global rules can does those but this isn’t right solution

The only devs can answer on this strange behaviour

and silence…

3.8.65951.477 : THIS BUG STILL EXIST

:cry: up up up up up up up up up up up up …

Hi, alxpython:

Sorry, I forget about this question was already posted and did another about the same question.

Please, see: https://forums.comodo.com/firewall_help/blocking_incoming_from_isp_to_255255255255_broadcast-t43426.0.html

You will notice that maybe some help will come from Ronny, and a workaround to block incoming TO 255.255.255.255 is, if you already have the rules, just leave CIS in “Block All” for some time (in my system, it worked with at least 3 min) and then return to your normal operation (Custom, Safe, Trainning…)

Regards,

Edit by EricJH: fixed url