9 Replies Latest reply on Jun 20, 2012 12:15 PM by elj

    Deny all vs Drop all

      Can someone give an explanation why we should not use a drop all at the end of our sidewinder rules and that we should use deny all? Traditionally most firewalls just drop all unwanted packets instead if responding to them.

       

      Thanks

      Eric

        • 1. Re: Deny all vs Drop all
          PhilM

          It's a diificult one for me, Eric, as while I have seen the "drop" behaviour on other Firewalls, I have worked with Firewall Enterprise (and its predecessors) longer than anything else - and they've always used Deny instead of Drop.

           

          None of the customer's I have worked with have commented about this to me, so I leave it as it is.

           

          Maybe one of the McAfee guys can provide you with a more educated response.

           

          -Phil.

          • 2. Re: Deny all vs Drop all
            georgec

            Not sure how the MFE does it as my experience with it is limited, but usually the deny rule sends back an ICMP notification of the connection being aborted. This allows applications to take action immediately (try another connection, or prompt a user notification), instead of waiting for a time-out as in the case of drop (black hole-ing packets).

            • 3. Re: Deny all vs Drop all

              Thanks Phil. I was hoping the McAfee guys could respond. I know the McAfee lets you use DROP on individual rules/services, but its a lot more work to set them up individually. Also when using a deny all at the end a port scan against our McAfee sends back a response instead of dropping the packets. This of course is not ideal.

              • 4. Re: Deny all vs Drop all

                George. Agreed. The issue I have with the ICMP being sent back is it lets the person attacking/scanning know there is a host at the IP where as if it dropped its as if there is no host there at all.

                • 5. Re: Deny all vs Drop all
                  PhilM

                  Have you considered editing the Deny All rule on your Firewall and simply changing the action from "Deny" to "Drop"?

                  • 6. Re: Deny all vs Drop all

                    Hello,

                     

                    The problem with changing the Deny All rule to Drop is that it prevents some communication from working. DNS, NTP, Ping (from the firewall) and HA communications are examples. If you would like to create a drop rule so that the firewall does not respond at all, you can create a packet filter service on all ports (except TCP/UDP 53 and UDP 123) and create a drop rule that excludes the heartbeat burb (to prevent HA problems).

                     

                    -Matt

                    • 7. Re: Deny all vs Drop all

                      Thanks Matt. I had done some Google searches that indicated in might break DNS and NTP, but was unaware it could affect HA.

                      • 8. Re: Deny all vs Drop all
                        sliedl

                        There is this KB article about upgrading from TSP to SW which talks about Drop All vs Deny All:  KB64684.  It mentions that DNS, HA, and ping will no longer work with a Drop All rule.  It talks about how to setup rules just like Matt was explaining, but it doesn't look like you can get DNS to work correctly if you have a Drop All rule.

                         

                        There is also this KB article:  Why do TCP ports show as open when traffic is denied? (KB64111)  It might explain what you're seeing.

                         

                        What you have to do is do a tcpdump on the firewall to see exactly what it is replying with.  A 3-way-handshake, a FIN, an ICMP unreachable?

                        • 9. Re: Deny all vs Drop all

                          According to a collegue here at work it is replying with a 3-way-handshake. I have not tested it yet myself. I actually came across that KB article earlier and read it. I think our auditors would like it if the MFE's default behavior (at least with our setup) is not to do a 3-way-handshake but instead drop (blackhole), but of course we are looking for best practice and of course we need DNS to work properly. I appreciate all the info and feedback.