1

Having just upgraded our FTP server to enforce Explicit FTP over TLS (on the standard port 21), we are experiencing connections failing sporadically, probably around 50% of the time. It's important to note that plain-text FTP is still run for one or two accounts that cannot support FTPS yet with their current setups.

When I check the IDP, it is sometimes rejecting FTPS packets, falsely identifying them as "FTP Cmd Telnet Opcode Evasion". This only occurs for FTPS (not plain-text FTP) and seems to be a lottery as to whether these packets will be rejected or allowed.

The only solution that I have been able to come up with is to disable the "FTP Cmd Telnet Opcode Evasion" rule in the IDP. Until I have more information regarding what the rule represents and why the IDP is sporadically rejecting the traffic, I have elected not to make this change.

Can anyone shed some more light for me on what this rule is protecting the network from, as well as what I might be able to do to allow the IDP to recognise FTPS as legitimate traffic?

NB (1): I set up Implicit FTPS (on port 990) and this works fine 100% of the time without the IDP thinking it's an evasion attack. I can only assume then that the IDP is expecting to see plain-text FTP on port 21 and nothing else, but then why does it work some of the time with FTPS?

NB (2): the IDP is on a Zyxel USG310.

Improve this question
2
  • The usual port for implicit FTPS (TLS from start) is port 990 (ftps). Port 21 is used with explicit FTPS, i.e. plain start with an AUTH TLS command used to upgrade to TLS. Maybe if you use the correct port the problem vanishes.
    – Steffen Ullrich
    Commented Aug 3, 2017 at 7:54
  • @SteffenUllrich, that's my mistake, I did mean explicit and not implicit
    – ryansin
    Commented Aug 3, 2017 at 8:09

1 Answer 1

Reset to default
2

I'm not familiar with Zyxel IDP but this is a known problem with other firewalls too.

My guess is that the specific IDS rule only does only a very shallow inspection at the TCP level and has no deep enough understanding of the FTP/FTPS protocol. And it will thus treat specific binary character sequences as telnet opcodes, no matter if they occur in a place where telnet opcodes could be or if they are accidentally part of the (binary) TLS handshake. Since the TLS handshake contains random data the rule might match sometimes and sometimes not.

This means that this rule has to be disabled to prevent false positives.

Improve this answer
2
  • Ok. And what level of risk am I opening up the network to by having this rule disabled?
    – ryansin
    Commented Aug 3, 2017 at 8:30
  • @Sinfieldd: as far as I understand this rule just tries to make sure that other FTP filter rules can not be bypassed. Thus, if you don't have any other rules there should be no problem but if you have any other rules they can be bypassed.
    – Steffen Ullrich
    Commented Aug 3, 2017 at 8:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .