ftp: use parser data direction in ftpdata

The ftpdata_command keyword assumed a fixed relationship between the FTP
command and the data-flow direction: RETR was expected to be to-client
and STOR to-server. That matches passive FTP, but active FTP reverses
the TCP data flow because the server opens the connection from port 20.
In an active download, the RETR payload is therefore seen by Suricata in
the flow's to-server direction.

For firewall rules this caused an active RETR rule on
ftp-data:request_started to miss. The firewall then applied the default
app policy to the FTP-data transaction, dropped the flow, and prevented
fileinfo from being logged.

Use the direction that the FTP parser stored in FtpDataState from the
control-channel expectation instead of deriving direction from the
command. This preserves the command check while allowing active and
passive data connections to match in their actual parser-established
data direction.

Author: jasonish

src/detect-ftpdata.c

@@ -105,17 +105,17 @@ static int DetectFtpdataMatch(DetectEngineThreadCtx *det_ctx,
     if (ftp_state == NULL)
         return 0;
 
-    if (ftpcommandd->command == ftp_state->command) {
-        /* Only match if the flow is in the good direction */
-        if ((flags & STREAM_TOSERVER) && (ftpcommandd->command == FTP_COMMAND_RETR)) {
-            return 0;
-        } else if ((flags & STREAM_TOCLIENT) && (ftpcommandd->command == FTP_COMMAND_STOR)) {
-            return 0;
-        }
-        return 1;
-    }
+    if (ftpcommandd->command != ftp_state->command)
+        return 0;
 
-    return 0;
+    /* Only match in the parser-established data direction. Active FTP
+     * reverses the data flow, so RETR/STOR don't map to fixed flow
+     * directions.
+     */
+    if ((flags & ftp_state->direction) == 0)
+        return 0;
+
+    return 1;
 }
 
 /**