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

Drop or reject

Hi,

I have a DNAT with blackhole IP and FW rule that Drop connections from some bed IP address, now when check the firewall logs I can see from one of those IPs has almost 200000 Drop packages,Tthis is good news, but this means that our UTM still must process the incoming packages from this bed IP and I think this will use valuable resources of the device.

If we use reject instead of Drop at the FW rule, does the UTM still will process the incoming connections from these IPs? or it will just rejrct them without process anything?

Thanks



This thread was automatically locked due to age.
Parents
  • In which time do you see the 200000 packets? Per day / hour / minute / second?

    What you should keep in mind is the load of your connection. If you reply to a packet with a reject you have more load in upload direction. Instead a drop you just have the inbound load of the bad IP datastream.

    PS Try to get in touch with the provider of the source IP.

    Best

    Alex

    -

  • Alex is right.   "Reject" sends a "please go away" packet.   Well-behaved systems will honor the reject, but this source certainly will not.  Also, some Denial of Service attacks are able to spoof the sender address.   For this reason, you do not want to reply to the attack because you might be inadvertently attacking someone else.

    I have done a little bit of research into defending against these attacks, and here is what I think I have learned:

    If you have BGP routing with a dedicated 24-bit IPv4 address range, you can get a content delivery network like Akamai to use BGP to redirect the hostile traffic from you to them.   This type of service carries a hefty monthly charge to have the service in place, and probably an uplift when it is used.   Great for big companies, not so great for smaller ones.   It is the best solution, because it intervenes at the routing layer.   The downside is that, at least for Akamai, it only works for web traffic.   In theory, it could be done for any port and protocol, but I do not know of a vendor who does so.   Akamai's primary business is hosting big websites, so a variant of this approach is to have somebody like them take over your public web completely.

    The lower-budget alternative is a third party WAF front-end.   You configure your traffic for www.mycompany.com to reference a vendor's IP address instead of your own.   The vendor's WAF software separates good traffic from bad, and then forwards the good traffic to you.  By design, it can only protect against attacks that target your published IP address at the vendor.   Your IP address is still on the Internet, so it is still possible for someone to attack your address directly.   The WAF service may allow you to configure a firewall rule that identifies and drops all unauthorized traffic, but you are doing that already for this specific problem.   Similar offerings are available for third-party email proxy. 

    Another option is a device at your perimeter that identifies problem packets and drops them.  The best tools are self-learning and adaptive, so that you don't have to know all of the hostile sites in advance.  PacketFilter seems to be the leading brand in that space.  The problem is that a device at your perimeter cannot prevent your internet connection from being overwhelmed, since the packet has to get to you before it can be dropped.

    You might benefit from contacting your ISP, but this has its own challenges.   They may decide that the best way to fight the problem is to disable all traffic to and from your IP address until the problem goes away.  This either puts you off the Internet or forces you to change to a new address.  Changing IP addresses might be a good solution if you can tolerate the disruption.   If you change addresses and the problem moves with you, then the bad guys are attacking you based on your DNS information or based on inside information.  Discouraging, but useful to know.

     

Reply
  • Alex is right.   "Reject" sends a "please go away" packet.   Well-behaved systems will honor the reject, but this source certainly will not.  Also, some Denial of Service attacks are able to spoof the sender address.   For this reason, you do not want to reply to the attack because you might be inadvertently attacking someone else.

    I have done a little bit of research into defending against these attacks, and here is what I think I have learned:

    If you have BGP routing with a dedicated 24-bit IPv4 address range, you can get a content delivery network like Akamai to use BGP to redirect the hostile traffic from you to them.   This type of service carries a hefty monthly charge to have the service in place, and probably an uplift when it is used.   Great for big companies, not so great for smaller ones.   It is the best solution, because it intervenes at the routing layer.   The downside is that, at least for Akamai, it only works for web traffic.   In theory, it could be done for any port and protocol, but I do not know of a vendor who does so.   Akamai's primary business is hosting big websites, so a variant of this approach is to have somebody like them take over your public web completely.

    The lower-budget alternative is a third party WAF front-end.   You configure your traffic for www.mycompany.com to reference a vendor's IP address instead of your own.   The vendor's WAF software separates good traffic from bad, and then forwards the good traffic to you.  By design, it can only protect against attacks that target your published IP address at the vendor.   Your IP address is still on the Internet, so it is still possible for someone to attack your address directly.   The WAF service may allow you to configure a firewall rule that identifies and drops all unauthorized traffic, but you are doing that already for this specific problem.   Similar offerings are available for third-party email proxy. 

    Another option is a device at your perimeter that identifies problem packets and drops them.  The best tools are self-learning and adaptive, so that you don't have to know all of the hostile sites in advance.  PacketFilter seems to be the leading brand in that space.  The problem is that a device at your perimeter cannot prevent your internet connection from being overwhelmed, since the packet has to get to you before it can be dropped.

    You might benefit from contacting your ISP, but this has its own challenges.   They may decide that the best way to fight the problem is to disable all traffic to and from your IP address until the problem goes away.  This either puts you off the Internet or forces you to change to a new address.  Changing IP addresses might be a good solution if you can tolerate the disruption.   If you change addresses and the problem moves with you, then the bad guys are attacking you based on your DNS information or based on inside information.  Discouraging, but useful to know.

     

Children
  • Thank you so much for your detailed reply,

    Do you mean execpt Black hole filtering for incoming connection from these bad IPs we cannot do anything else with our UTM!? did I understood you correctly?

    Thanks

  • The best fix is to block the traffic further upstream, which cannot be done by UTM or any other perimeter device.

    You might work to minimize overhead by disabling logging off the blacklisted traffic.

    If the traffic is causing a resource problem on UTM, that change might help.

    If the traffic is causing a bottleneck on your network bandwidth, you might negotiate with your ISP for a temporary bandwidth boost.

  • Hi Douglas,

    Thanks again for your update,

    The logging at the NAT and Firewall Rule  that bolck access for the problematic IPs is disabled , but still we see the drop connections at the Firewall logs.

    What is a bit strange for me is, when I go to the network usage logs and search for those IPs I cannot find anything. Shouldn't we see the network useage for all of those drop connections?

     

    Thanks