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

IPS exceptions not working - UDP flood detected

Sam Malone

We are having an issue with our UTM 9.605-1 device. We have user reports of poor connection quality when using video conference and web-browser based phone calling services (Twilio).

We have the IPS enabled globally, and we have UDP flood protection enabled with settings:

We were experiencing some logging of "name="UDP flood detected" action="UDP flood" fwrule="60013" in the logfile, so I made the decision to enter an exception for inbound and outbound traffic using these various TCP and UDP ports:

But the UDP flood detected messages were still appearing in the log file.  So then I attempted to disable the offending UDP flooding rule, specifically: fwrule="60013" as follows:

But even after that I am still seeing UDP flood detected messages in the log file regarding that same fwrule:

2020:02:06-10:16:13 utm-2 ulogd[17598]: id="2105" severity="info" sys="SecureNet" sub="ips" name="UDP flood detected" action="UDP flood" fwrule="60013" initf="eth4" srcmac="64:64:9b:56:44:00" dstmac="00:1a:8c:f0:6e:e4" srcip="173.194.162.140" dstip="209.131.229.254" proto="17" length="1378" tos="0x00" prec="0x00" ttl="61" srcport="443" dstport="49277"
2020:02:06-10:16:13 utm-2 ulogd[17598]: id="2105" severity="info" sys="SecureNet" sub="ips" name="UDP flood detected" action="UDP flood" fwrule="60013" initf="eth4" srcmac="64:64:9b:56:44:00" dstmac="00:1a:8c:f0:6e:e4" srcip="173.194.162.140" dstip="209.131.229.254" proto="17" length="1378" tos="0x00" prec="0x00" ttl="61" srcport="443" dstport="49277"
2020:02:06-10:16:14 utm-2 ulogd[17598]: id="2105" severity="info" sys="SecureNet" sub="ips" name="UDP flood detected" action="UDP flood" fwrule="60013" initf="eth4" srcmac="64:64:9b:56:44:00" dstmac="00:1a:8c:f0:6e:e4" srcip="173.194.162.140" dstip="209.131.229.254" proto="17" length="1378" tos="0x00" prec="0x00" ttl="61" srcport="443" dstport="49277"

in the above example, 209.131.229.254="External (WAN) - Jaguar Comm (Address)" so it should be in my exception list AND the rule 60013 should be disabled anyway.  It appears as though the exceptions listed, as well as completely disabling the rule in the advanced section have no effect.

Can someone shed some light on my situation? Thanks.



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

    This is not a bug, Sam.

    Start with internalizing #1 and #2 in Rulz (last updated 2019-04-17).

    20/100 for UDP flood protection is very aggressive.  I would set that back to the factory default of 200/300.  If you're still seeing "UDP flood detected" between 173.194.162.140 and 209.131.229.254, you will want to make an Intrusion Prevention to allow that traffic.

    Any better luck?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Thanks for your response Bob. I had changed the packets/second in the past and was unable to see what the default values were, so thanks for that.

    As for the exceptions, please see the image above, where my appliance is essentially allowing any src/dst networks to bypass TCP/UDP flooding, when using TCP/UDP port 443 to communicate.  I do believe the issue has been reduced to lowest terms, and that is that the UTM exception is not applying to packets with a SRC port of 443, only a DST port of 443.

    Since UDP is not stateful, the UTM thinks that the SRC port 443 traffic is initializing a connection, when in fact port 443 is replying via UDP to the NAT's ephemeral port.

Reply
  • 0 in reply to BAlfson

    Thanks for your response Bob. I had changed the packets/second in the past and was unable to see what the default values were, so thanks for that.

    As for the exceptions, please see the image above, where my appliance is essentially allowing any src/dst networks to bypass TCP/UDP flooding, when using TCP/UDP port 443 to communicate.  I do believe the issue has been reduced to lowest terms, and that is that the UTM exception is not applying to packets with a SRC port of 443, only a DST port of 443.

    Since UDP is not stateful, the UTM thinks that the SRC port 443 traffic is initializing a connection, when in fact port 443 is replying via UDP to the NAT's ephemeral port.

Children
  • 0 in reply to Sam Malone

    The firewall is stateful, Sam, but Intrusion Prevention is not.  You need to add a "HTTPS Response" (443->1:65535) service to the Intrusion Prevention Exception.

    By the way, great job of documenting!  Since I go through dozens of threads some days, I've gotten pretty good at speed-reading posts.  I should have seen that Response issue and commented on it in my first post in your thread.

    I think your Exceptions may be unnecessarily broad.  I would make a new, limited Exception in addition and allow "HTTPS Response" going to "External (WAN) (Address)" and "External (WAN) - Jaguar comm (Address)" if applicable.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Thanks again for the quick response.  I've updated my exception by adding a newly created service that switches around the SRC and DST ports, and this should now work for my situation!

    Cheers,

    Sam Malone

  • 0 in reply to Sam Malone

    Hi Sam,

    Please update the post with the results once you have tested this thoroughly.

    Regards

    Jaydeep

Unfiltered HTML