IDS/IPS automatically block attempting IP after X number of alerts

Any day now is good, looking forward to it. As for keeping with the facts, I feel it was clearly demonstrated by @DN3092 and @ebuckland81 that the IPS capability is not working. Threats were passed by the Route10 to the endpoint (as evidenced by Bitdefender detecting it at the end-point) and where the conntrack -D call failing due to the queue being saturated. These are the facts.

1 Like

My last post was deleted - let me try one more time.

Any day now is good, looking forward to it. As for keeping with the facts, it has been clearly outlined by @DN3092 and @ebuckland81 that the current IPS does not, in fact, work at least not reliably. As @DN3092 has shown, end points are receiving the threat (as evidenced by Bitdefender detecting it on the end point). As @ebuckland81 has shown, conntract -D does not reliably delete the session (as evidenced by the log files showing failure of conntract and saturated queue). These are the facts.

3 Likes

It wasn’t actually flagged by any humans, just our spam bot, so I removed the flag.

3 Likes

Hi Alta Members! Been looking at Alta Route10 device and thinking of obtaining one for testing purpose. Which is on hold for now, as from my understanding IPS is not blocking all hits.

Does it mean, that IPS up to this day is still allowing traffic to pass even though it is detected?

1 Like

The initial/first connection attempt / traffic may sneek through, from my testing and understanding, as the IPS application is reacting to the event that Suricata/IDS detected, rather than filtering the event inline. Please feel free to correct me there.

Then, after some short time, the IPS application should be able to delete the connection. For how long this initial/first traffic may go on I am not sure of.

Also, worth noting, one of the later firmware upgrades introduced a configurable block duration for which any further traffic is temporarily blocked between the two IPs involved. :flexed_biceps::+1:

2 Likes

Well after a couple weeks im convinced that there has been no improvement to IDS/IPS on this product unfortunately.

I took a chance and got a ucg fiber, and not a single threat touched the device requiring bitdefender to stop the threat.

Meanwhile on the route10

2 Likes

“No improvement” is certainly a stretch as you yourself confirmed that the number of threats went down immediately after enabling the Block Duration option.

As we and @ebuckland81 noted, the first threat detection cannot be blocked due to the current passive architecture of our IDS/IPS, but subsequent attempts that match the IP address pair will be blocked, as you have confirmed this yourself.

We may consider adding support for inline operation which should be able to block even the first attempt, but it severely limits the amount of throughput that can be handled by the device (and this is the case with any vendor that performs inline operation - it depends solely on CPU processing power and bypasses any advantageous hardware acceleration).

2 Likes

Is there a way to do that now manually? I only have 500down and 20 up so i don’t need super fast speeds.

2 Likes

Perhaps, but it requires modifying core iptables/firewall rules, and the suricata config, as outlined here: 23.2. Setting up IPS/inline for Linux — Suricata 9.0.0-dev documentation

This right here is my issue, I personally don’t want to sacrifice security for speed.

Sure, we’re definitely looking into it.

2 Likes

Wow….just wow…

@DN3092 this is great feedback after giving it some time to see how it performs. I’m a little put off by the reaction it has received which is unfortunate.

Our team works incredibly hard to improve the product directly based on feedback given here, so I hope you can understand the frustration when we receive mixed messages. We are already looking into adding a fully inline option even though the Blocking Duration option has been proven to block credible threats after the first attempt, but once again, your patience will be appreciated.

3 Likes

Yeah, not too much to add aside from being generally fine with the current tradeoff myself, but I think a combination of the ability to switch between the current mode and an inline mode plus documentation and tooltips stating the expected behavior and tradeoffs between the modes would probably nip most of this in the bud :slight_smile:

3 Likes

Noting that the IDS/IPS solution used is passive and not inline should be noted in their documentation imo. I bought the product expecting inline, which unfortunately isn’t the case.

4 Likes

I completely understand the frstration around receiving mixed messages. I work incredibly hard for my money and when I buy a router that states it has an Intrusion Protect System only to then be told, well, it doesn’t really block everything, but we fixed it, well, it still doesn’t actually block the initial attack, yea, I get the frustration around mixed messaging very well. I don’t know that there is any patience left at this point.

2 Likes

We’re going to keep asking for it, nonetheless! While the current implementation may not meet your specific needs, it definitely meets others’. We’ll keep working towards meeting your needs, as well.

2 Likes

@DN3092 @ebuckland81 @jmszuch @ecs-solutions

Sorry to spam you all, but was hoping you could revisit your testing after the recent 1.4t update. Time permitting of course. Thanks!

I’m no longer using Alta equipment.

We’ve listened to everyone’s feedback here specifically and delivered inline IPS, as promised.

PBR (IP, subnet, and domain-based) is coming along quickly, as well. We’re committed to improving Route10 with free updates.

1 Like