FTP session logged as 2 TCP sessions

[santonic]

Hello.

I have a problem with the way PA handles FTP sessions. I have a general rule which allows privileged user groups to have full access to a certain network. So application and service in this rule is 'any'. One of the applications users will be using is FTP.

When I look at traffic logs i see 2 TCP session for each use of FTP application. Let's say client is at 1.1.1.1 and FTP server at 2.2.2.2.

Every time a client starts FTP session i see 2 TCP sessions in logs:

- TCP session from 1.1.1.1:yyyy to 2.2.2.2:21

- followed by TCP session from 2.2.2.2:xxxx to 1.1.1.1:20

I know FTP application consists of 2 TCP session. But shouldn't PA as an application firewall match DATA session with CONTROL session and regard them as single use of FTP application?

This will be a big issue when the traffic from the mentioned network towards user segment will be set to 'deny'. I don't think having to open port 20 towards user segment is the way to go on application firewall.

Best regards,

Simon

[HULK]

Hello Simon,

Could you please confirm the session type in both directions:

For an example:

vsys1                                          199.167.52.5[4501]/Untrust-ISP  (199.167.52.5[4501])

63320        ssh            ACTIVE --------------- FLOW--------------------  ND   199.167.52.5[4030]/Untrust-ISP/6  (199.167.52.5[4030])  >>>>>>>>>>>>>>>>>>>>> this is a flow session.

I hope the TCP session from 2.2.2.2:xxxx to 1.1.1.1:20 is not a flow session, it's a PRED ( predict session). So, the firewall is expecting a connection from the server on that port. This is part of ALG ( application layer gateway) functionality.

Hope this helps.

[hshah]

Hi Santonic,

Kindly provide us output for "show session all filter source 1.1.1.1 destination 2.2.2.2:21". Make sure you have just started the FTP application.

As per issue, this output will generate two sessions. Then provide us output for "show session id <>" for both the sessions.

This will help us to determine root cause precisely.

Regards,

Hardik Shah

[santonic]

Thanx for the tip, i'll try to catch such session live.

Do predicted sessions go into traffic log as a seperate (TCP) session?

[HULK]

Hello santonic,

As per my understanding, predict session will be not logged under traffic logs. It will be only appear in the session table.

Thanks

[dreputi]

Hello Santonic,

It looks like you are describing Active FTP where the client first initiates a connection on Command port 21 to server and the server responds to it. Then server will initiate a connection from its side to client for data connection using port 20.

https://live.paloaltonetworks.com/docs/DOC-6936

But PAN uses its ALG(Application Layer Gateway) to inspect the layer 7 packets of the FTP connection ie from client to server's port 21 and its response from server. PAN then sees what ports the client and server's are negotiating, it will open a predict session of type PRED from server's side to Client's side on those specific ports. This is done dynamically so you DON'T have to open up those ports explicitly. When the firewall sees traffic coming from the server matching those ports, then it will convert this PRED session into ACTIVE session. This also means you DON'T have to create new security or NAT rules to allow traffic in the reverse direction. The other alternative is to use a Passive FTP where client only initiates connections in both the directions.

Moreover the second session doesn't appear to be correct in your example since the client will not serve anything on its port 20.

Regards,

Dileep

[hshah]

Hi Santonic,

Predict session do not appear in traffic log because there is no actual data exchange.

if there is any packet exchange than its seen as FTP log in traffic log rather than FTP-data. Kindly refer following document.

Cannot Use 'ftp-data' as a Valid Application Selection for a Security Rule

Regards,

Hardik Shah

[santonic]

dreputi

Yep, I copied it wrong. It should be like this:

Every time a client starts FTP session i see 2 TCP sessions in logs:

- TCP session from 1.1.1.1:yyyy to 2.2.2.2:21 application ftp

- followed by TCP session from 2.2.2.2:20 to 1.1.1.1:xxxx application ftp

I agree that I shouldn't be opening session for the DATA traffic in the other direction. But that means 2nd session will always be blocked when we implement the drop rule. Will FTP still work?

hshah

Yes, I agree that predicted sessions aren't logged and that there is no such application as ftp-data needed.

But I do see a TCP session in other direction in traffic log, it's recognised as ftp application, there was some data transfered through it and it always appears after a ftp session from client to server. And that means I need to explicitly open everything from source port 20 in the other direction?

[dreputi]

Yes, it should work even if you have a drop rule. This is because the ALG is tracking the session based on its prediction. Like I mentioned earlier, ALG opens a predict session on for the second connection and when it receives that traffic, PAN will match the traffic to PRED session and convert it to ACTIVE session.

Let us know if you have any questions.

[HULK]

Hello santonic,

The ALG should take care about the predict session from the opposite direction and you need not to open port/policy in the other direction. The FW should be intelligent enough to match packets from the same session.

Thanks

[hshah]

Hi Santonic,

Return connection " 2.2.2.2:20 to 1.1.1.1:xxxx application ftp" may be for future ftp-data. And that is expected behavior. Can you provide us show session id output for both the sessions.

Regards,

Hardik Shah

[santonic]

Ok, I understand about PREDICT sessions, but we all agree those shouldn't be seen in traffic logs?

And I agree I shouldn't have to create a rule for traffic back, but in that case the session back in logs will be blocked?

And Session IDs for pair of such connections are different.

Here is the screenshot of such sessions for easier understanding:

Another thing: for the security zone where the FTP server is we have a zone protection profile which doesn't reject Non-SYN TCP sessions and bybasses Asymmetric Paths.

But the mentioned FTP traffic isn't asymmetric so this zone protection profile shouldn't have any influence on these sessions.

[hshah]

Hi Santonic,

I see FTP session on port 21 and 20 are in pair. Which means one is for control channel and other one is for data channel.

Now, FTP server might be sending file through multiple sessions to get better throughput. Thats the reason there are multiple sessions.

I have seen server applications using multiple sessions to get faster throughput. May I know which FTP server are you using.

Regards,

Hardik shah

[lewis]

@ santonic I had the same questions when i discovered what appeared to be IPs out on the internet doing FTP into our network but I believed should have been dropped. Under further investigation and a ticket to support I found out about the predict sessions.  RTP also works this way too.

[santonic]

hshah

Thanx for your info. Yep, to me it looks as well like the sessions are in pair. But session IDs are different. So I'm still worried the data sessions will be blocked.

I don't have info about FTP server, i'll check with the client where the issue appears. Do you know if PAN supports multiple DATA sessions back or only looks for 1?

lewis

You saw data sessions (with source port 20) to internet and they were allowed despite the fact you didn't have such traffic allowed with rule?