Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 71 replies
  • Subscribers 37 subscribers
  • Views 139854 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

Clean Up rule "from any, to any, drop" that's allowed on the Internet anyway !!! WTF ?

Big_Buck

Hello  Can anyone explain that to me ?

I have a clean up rule (no 3) "from any, to any, drop" that allows traffic on the Internet anyway !!!.  See the rule and the log below.

Is it me, or this is a very serious issue ?



This thread was automatically locked due to age.
Parents
  • 0

    Hi,

    Thank you for the feedback.

    We have gone through the details and confirmed that traffic is always getting denied.

    However, we suspect such logging event(s) are getting generated when, a connection initially passes through "ACCEPT" Firewall rule and later on from the "DROP" Firewall rule.

    Possible reasons ( for such ESTABLISHED/ONGOING connection ) are,

    - User(s) logout

    - Add/Update/Delete/Enable/Disable/Move in Firewall Rule Table

     

    Also note that,

    - When traffic is allowed, firewall logs the traffic when connection termination happens ( via client, server or timeout )

    - When traffic is denied, firewall logs all the denied packets

     

    Ex:- Consider below scenario where rules are configured in given order,

    Rule 1: User based rule with action 'ACCEPT' and 'Logging Enabled'

    Rule 2: Non-user based rule with action 'DROP' and 'Logging Enabled'

    In this case,

    - When user logs in and initiate a connection, it will match with Rule 1

    - User logs out ( by him/herself or logged out by firewall ), ongoing connection will start following Rule 2

    - Traffic is now getting denied due to "DROP" action and denied packets will be logged immediately with correct rule id and action

    - Issue happens, when firewall gets the connection termination event ( due to timeout ), it logs it with new rule id ( i.e Rule id 2 ) and "Allowed" action ( We identified this as an issue in the product )

    Regards,

    Deepti

Reply
  • 0

    Hi,

    Thank you for the feedback.

    We have gone through the details and confirmed that traffic is always getting denied.

    However, we suspect such logging event(s) are getting generated when, a connection initially passes through "ACCEPT" Firewall rule and later on from the "DROP" Firewall rule.

    Possible reasons ( for such ESTABLISHED/ONGOING connection ) are,

    - User(s) logout

    - Add/Update/Delete/Enable/Disable/Move in Firewall Rule Table

     

    Also note that,

    - When traffic is allowed, firewall logs the traffic when connection termination happens ( via client, server or timeout )

    - When traffic is denied, firewall logs all the denied packets

     

    Ex:- Consider below scenario where rules are configured in given order,

    Rule 1: User based rule with action 'ACCEPT' and 'Logging Enabled'

    Rule 2: Non-user based rule with action 'DROP' and 'Logging Enabled'

    In this case,

    - When user logs in and initiate a connection, it will match with Rule 1

    - User logs out ( by him/herself or logged out by firewall ), ongoing connection will start following Rule 2

    - Traffic is now getting denied due to "DROP" action and denied packets will be logged immediately with correct rule id and action

    - Issue happens, when firewall gets the connection termination event ( due to timeout ), it logs it with new rule id ( i.e Rule id 2 ) and "Allowed" action ( We identified this as an issue in the product )

    Regards,

    Deepti

Children
No Data