Passive FTP traffic (TCP/30200 - 30220) causing multiple IPS false positives

[Parabol]

Hi all,

We have an unusual problem at the moment where we've had multiple different IPS false positive incidents in the past 1-month. Each time we have reactively added an IPS exception for the systems involved, but the frequency of the occurrences is very concerning. 

In all instances, the traffic involved is TCP/30200-30220. The systems involved are using vsftpd (a Unix/Linux FTP server application) to transfer data, and the passive ports are defined as such:

• pasv_min_port: 30200
• pasv_max_port: 30220

The main protection triggering has been - Malicious Payload Encoding Remote Code Execution

But it has also triggered:

• Ipswitch WS_FTP Server commands buffer overflow denial of service
• Internet Explorer FTP Response Parsing Memory Corruption (MS07-016)

Obviously we could change the protection behavior to detect or inactive, but this isn't ideal for us from a security view.

Has anybody else observed anything similar? Our solution at the moment is reactively added exceptions, but this isn't sustainable if it keeps continuing with new systems, and new protections. 

Although one thing I've noticed is that all the triggered protections have a "Medium confidence", and so is this just an expected byproduct of enabling such protections?

Thanks!

[the_rock]

Cant say I ever experienced this in R80+, but, just wondering, how is your IPS profile configured? Is it set to optimized (default) policy? Personally, in the meantime, maybe try doing below?

Andy

 

[Timothy_Hall]

Unless you can determine the precise reason for the falses you are kind of stuck, and doing so will require a TAC case.

My guess is that these Medium Confidence protections have a fairly short set of bytes they are pattern matching for and that sequence of bytes happens to be showing up in your data streams occasionally.   Not perfect from a security perspective, but you could add an IPS blade-based exception only matching your passive ports like this, I was hoping to find a way to confine this exception only to FTP protocol traffic but that doesn't appear possible (you can try setting protocol FTP on the range object but I'm pretty sure that won't work).  If you can tighten up the exception's source and/or destination to only internal networks or only those that use vsftpd that would be helpful:

[Parabol]

Thanks Timothy, I think this will be what we do. Another incident happened yesterday, this time a new protection "VMware Multiple Products NAT Service Buffer Overflow".

I've requested a list of systems from the customer that are using this vsftpd on this port range, so that we can tighten it up like you say. I was hoping to only apply it to 3 or 4 protections, for a while it seemed to be only triggering these, but as we see yesterday new ones are popping up still.

We have got a TAC case open too and have provided some pcaps, so we will see if that helps also.