IPS Exception not working

Hi,

I have problems with IPS in UTM, the UTM handles IPSEC traffic with VEEAM backup and Replication, and triggers this:

2019:09:10-02:55:51 mail-2 snort[13000]: id="2101" severity="warn" sys="SecureNet" sub="ips" name="Intrusion protection alert" action="drop" reason="MALWARE-OTHER Ransomware SamSam variant detected" group="500" srcip="192.168.11.20" dstip="192.168.10.31" proto="6" srcport="902" dstport="53906" sid="48814" class="A Network Trojan was Detected" priority="1" generator="1" msgid="0"
2019:09:10-02:58:23 mail-2 snort[13000]: id="2101" severity="warn" sys="SecureNet" sub="ips" name="Intrusion protection alert" action="drop" reason="MALWARE-OTHER Ransomware SamSam variant detected" group="500" srcip="192.168.11.20" dstip="192.168.10.31" proto="6" srcport="902" dstport="53946" sid="48814" class="A Network Trojan was Detected" priority="1" generator="1" msgid="0"
 
192.168.11.20 is a VMWARE ESXi server
192.168.10.31 is a Veeam Server (Windows)
 
I have added this exception in the affected UTM:
 
But nothing helps :-(
 
  • What happens if you create a second exception list for the other subnet (to destination)?

  • In reply to ThorstenSult:

    ThorstenSult

    What happens if you create a second exception list for the other subnet (to destination)?

     

     
    Already tried that, still no cheddar :-O
     
    Thanks for writing ;)
  • Hi Martin,

     

    If this is a specific rule that is always triggered (48814 given this log), you could try to modify this rule to either disable it or change it to alert in the advanced tab. 

     

    Regards,

     

    Karl-Heinz

  • In reply to Karl-Heinz van Hardeveld:

    Hi Karl-heinz,

     

    Thanks for pointing out ;-)

    Only thing is, that if another host/server behind the UTM, get's the SAMSAM attack, then it would just ignore it, therefore I hoped for the host exception to work, but there is a problem with UTM in that matter I see.

    Tried to change from IPSEC to RED Site-2-site, just for fun, but of course, the issue remains :-)

  • Hi  

    I assume the network definition is not bound to any interface. With that in mind, would you please try changing the condition from AND to OR and see if that helps? (I know it sounds funny).

  • In reply to Jaydeep:

    Hi  

    Just tried, but still an issue, this one helps, but will drop the ID's permanently for all networks...

     

     

    Not working:

  • In reply to twister5800:

    Hello Martin,

     

    Just a silly thought... does VEEAM backup keep connections open all the time or does it start new connections everytime? IPS exceptions are applied to new connections, not existing ones.

    If not sure, I think you can force it by disabling one of the interfaces, then re-enable.

     

    Regards,

     

    Karl-Heinz

  • In reply to Karl-Heinz van Hardeveld:

    Hi,

     

    Sorry the delay :-)

    No unfortunately it's still the same. I rebooted veeam server also, with no effect, only thing that do work it the "advanced" pane and change the way it should report. 

    I will commit to support ticket :-)

     

  • In reply to twister5800:

    Hi Twister,

     

    I'm experiencing the same issue at the moment.

    Did you open a support ticket and find out anything?

     

    Thanks in advance.

  • In reply to HermannO:

    Hi Hermann0,

    Yes, support tried a lot, but finally found out, that when making IPS exceptions, I could not choose the service,but only the device, and to be sure with my traffic, we had to add them as here:

     

    It did not look that it was something they would fix, as this works as designed, I was told :-)

    I just needed to know it first:-)

  • In reply to twister5800:

    Hi Martin,

     

    very interesting. do you know if that concerned only IPS exception or maybe tcp/udp syn flood exception also?

     

  • In reply to zaphod:

    Hey guys,

    before I create a new Topic I will add my question here because it should fit.

    We have the same issue what seems a bit weird. The configuration is for me really easy to understand but it doesnt work.

     

    Our example:

    2020:05:13-10:55:36 sophos-1 ulogd[29081]: id="2105" severity="info" sys="SecureNet" sub="ips" name="UDP flood detected" action="UDP flood" fwrule="60013" initf="eth1" srcmac="Extern MAC" dstmac="Our MAC" srcip="Extern Public IP" dstip="Our Public IP" proto="17" length="132" tos="0x00" prec="0x00" ttl="59" srcport="691" dstport="27270"

     

    In Short:

    [...]name="UDP flood detected" [...] srcip="Extern Public IP" dstip="Our Public IP" [..] srcport="691" dstport="27270"

     

    So for my understanding I have to set a rule like:

    --------------------------------------------------------------------------------------------

    Action -> Skip UDP Flood Protection

    Coming from these source... -> Extern Public IP

    AND

    Going to these destination... -> Our Public IP (Tried without this, too)

    AND

    Using these services -> 691

    ---------------------------------------------------------------------------------------------

     

    For my understanding it's exaclty what the IPS is tend to block. But it doesnt seems to be better.

    When I now add the "destination port" 27270, it start to work. But the problem is, that in some cases the destination port can vary.

     

    Is that behaviour correctly "by design" that it only works while adding source "and" destination ports?

     

    Thanks.

    Flo

  • In reply to Florian Bartsch:

    Hallo Flo,

    It look like you need a single, new Service definition like msexch-routing response = UDP 691->1:65535.

    Did that work for you?

    Cheers - Bob

  • In reply to BAlfson:

    Hey Bob,

    I believe I never noticed the exatly description of the single entries in a service defination because "source port" is always fixed in a new Definition to "1:65535". So I dont cared about it cause it works. -.-'

    Do you mean (yeah I know its what the logging is saying after you gave me the hint xD) when I switch both entries, it should work?

     

     

     

  • In reply to Florian Bartsch:

    Genau so, Flo !

    Cheers - Bob