Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 16 replies
  • Subscribers 3 subscribers
  • Views 13709 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

Log dropped broadcasts

Alvin
Hi all

Just want to check if it is fine to Disable

Log dropped broadcasts which is under Packet Filter -> Advance

On one hand, it seems wise to simply log everything and there is no downside since there are tons of HDD Space Available. (I never even fill 3% after entire year)

The reason I am thinking of disabling it now is because I realized it is because of this setting that causes the Packet Filter Logs ( Live) shows a lot of broadcast traffic and this makes it hard for troubleshooting since 90% of the page is the same dropped broadcast. (There is tons of broadcast due to a media stream device known as HAVA, think of it as slingbox)

Thus seek your advice

1) Simply can leave it OFF, not a issue.
2) OR I should keep it ON and turn off only when I need to troubleshoot as disabling this can cause me to lose important information. (Well the way I see is there must be a reason it exist right)


This thread was automatically locked due to age.
  • 0
    Hi,

    OR
    3) leave it off, and only turn it on when troubleshooting broadcasts [:P]

    I keep it off personally.

    Another option is to just use the shell and GREP the logs; e.g. use grep -v to filter out the broadcast entries.

    You might be able to create a rule to drop the broadcasts from the HAVA device:
    source: hava
    dest: LAN broadcast address
    service: any
    drop

    Barry
  • 0 in reply to BarryG
    Thank You BarryG

    - Glad to know / assured it is fine to disable.
    - I kept other FTP and DNS Logging Enabled.

    - I don't think there is a need for the packet filter rule right because right now it is being dropped by default rule.
    It is just the massive logs scrolling across that "live log" when doing troubleshooting that was the issue with so many broadcast covering 90% of the screen and moves too fast.
  • 0 in reply to Alvin

    - I don't think there is a need for the packet filter rule right because right now it is being dropped by default rule.

    Barry is a genius I tell ya. That rule he is suggesting is not to actually drop the packets that are being dropped by default. If you create a rule, you have the option of turning the logging on/off. So if you create a deny rule and leave logging off, technically you shouldn't see it in the live logs. 

    Try and let us know if it works[;)]
  • 0 in reply to Billybob
    Billybob

    - Thank You for highlighting to me that I missed BarrG point that I can disable the logging by creating a rule even when it is currently dropped.

    - Yes BarryG is a genius, he replied to every of my questions which I really appreciate.

    Well I did the test

    1) This is what Live Logs shows when Log Broadcast is Enabled,
    HAVA IP:1778 →255.255.255.255  :  1778

    2) I created a UDP 1778
    3) I created a rule on top.
    HAVA IP UDP1778 -> LAN Broadcast = Drop and do not log.
    The Live logs still shows.
    I noted the LAN Broadcast is not the 255.255.255.255
    Thus I changed it to
    HAVA IP UDP 1778 -> ANY = Drop and do Not Log.
    It will still appear in the live logs.

    4) I personally think it would still appear in the live logs because in the live logs, it is the Default Drop Rule that applies first and not my rule.
  • 0
    If Barry's trick doesn't work, try replacing the broadcast address with 'Internal (Address)'.

    I also tried a DNAT to quit logging some persistent hackers: '{group of hacker ip networks} -> Any -> {group of all External (Address)} : DNAT to {non existant IP}'.  The "group of all External (Address)" includes "External (Address)" and "Exterrnal [OWA] (Address)" and not just the numerical IPs.  This is so the traffic is handled in the Forward chain instead of the Input chain.  When I used the IPs, the traffic was shown in the log as dropped by a default rule.

    Cheers - Bob
  • 0
    Hi, your LAN broadcast address would normally look like 192.168.1.255 or similar, but it sounds like HAVA is using the Global Broadcast address, 255.255.255.255.

    Create a new Network Definition for that Global Broadcast,  255.255.255.255, and use it in the PF rule.

    Barry
  • 0 in reply to BarryG
    Balfson

    - Top Rule
    - HAVA Device -> LAN Network ***.***.***.0/24 -> UDP 178 Drop = Do not Log
    This does not work, the default drop rule would still appear in the live logs.

    BarryG

    I do not know how to definite Global Broadcast
    I assume the Mask would be 255.255.255.255
    But the Network Portion, I should put 255.255.255.255 or 0.0.0.0
  • 0
    HAVA Device -> LAN Network ***.***.***.0/24 -> UDP 178 Drop

    I meant, for the traffic selector, assuming the HAVA device is in "Internal (Network)," use:

    Source: {HAVA device}
    Service: {UDP 1778}
    Destination: Internal (Address)


    Cheers - Bob
  • 0 in reply to BAlfson
    Balfson

    Thanks for clarifying.

    HAVA is on LAN Network

    Top Rule.
    Source: HAVA Device Internal Static IP via Static DHCP
    Service: UDP 1778
    Destination: LAN Network Address
    Action: Drop
    Logging: Unchecked.
    Enabled the rule.

    Confirmed that I do see it in the Live Logs if Logging Broadcast is Enabled.
    The drop rule is the Default Rule, not the rule I specified thus it seems there is this "invisible" rule that take higher priority than the rule I specified.
  • 0 in reply to Alvin

    I do not know how to definite Global Broadcast
    I assume the Mask would be 255.255.255.255
    But the Network Portion, I should put 255.255.255.255 or 0.0.0.0


    Hi, the global broadcast would be 255.255.255.255 / 255.255.255.255 (both network and mask are 255.255.255.255)

    Barry