FTP Server: No Allow policy but 3-Way-Handshake and Username prompt possible?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

FTP Server: No Allow policy but 3-Way-Handshake and Username prompt possible?

L2 Linker

There is no allow policy from Untrust to DMZ to contact the FTP Server.

There is an deny policy instead as a last policy between ZONE Untrust und ZONE DMZ.

But if I try to connect to FTP Server a connection is estabilished and my FTP Server asks for a Username.

This is the end of communication - but is anyone allowed to connect to my FTP Server?


Roman

1 accepted solution

Accepted Solutions

L5 Sessionator

Hi Roman,

Based on security policy configured firewall will allow few packets between client and server. This is done to evaluate the application. 1st 3 handshake packets allows for session setup. Next packets will be evaluated by app-id engine for application match. Once we recognize the application, we re-evaluate all security policy and deny application as FTP is not part of allowed application. But to recognize, firewall needs to allow few packets through. Also note that these does not include data from ftp server.

You can control this behavior by denying at service level. ie. configure policy that denies port 20 and 21 from untrust to dmz. That way firewall will not wait to evaluate the application and drop the packets once received. Hope this helps.

View solution in original post

7 REPLIES 7

L5 Sessionator

Hi Roman,

Based on security policy configured firewall will allow few packets between client and server. This is done to evaluate the application. 1st 3 handshake packets allows for session setup. Next packets will be evaluated by app-id engine for application match. Once we recognize the application, we re-evaluate all security policy and deny application as FTP is not part of allowed application. But to recognize, firewall needs to allow few packets through. Also note that these does not include data from ftp server.

You can control this behavior by denying at service level. ie. configure policy that denies port 20 and 21 from untrust to dmz. That way firewall will not wait to evaluate the application and drop the packets once received. Hope this helps.

L7 Applicator

Hello rkra ,

Could you please check the real time session in the CLI of the PAN firewall by using 'show session all filter source IP_ADD_OF_THE_TESTING_PC destination IP_ADD_OF_THE_DESTINATION'.

> show session all filter source x.x.x. destination y.y.y.y

If there is an session exist for the same traffic,  then please apply  CLI command PAN> show session id XYZ   >>>>>>>> to get detailed information about that session, i.e NAT rule, security rule, ingress/egress interface etc, which effectively passing traffic.


Thanks

Hi Hulk,

here are the details.

rkrakovic@PA1(active-primary)> show session all filter source 176.28.45.241 destination 185.9.109.124

--------------------------------------------------------------------------------

ID      Application    State   Type Flag  Src[Sport]/Zone/Proto (translated IP[Port])

Vsys                                      Dst[Dport]/Zone (translated IP[Port])

--------------------------------------------------------------------------------

9066    ftp            ACTIVE  FLOW       176.28.45.241[50780]/UNTRUST/6  (176.28.45.241[50780])

vsys1                                     185.9.109.124[21]/DMZ1  (185.9.109.124[21])

rkrakovic@PA1(active-primary)> show session id 9066

Session            9066

        c2s flow:

                source:      176.28.45.241 [UNTRUST]

                dst:         185.9.109.124

                proto:       6

                sport:       50780           dport:      21

                state:       ACTIVE          type:       FLOW

                src user:    unknown

                dst user:    unknown

        s2c flow:

                source:      185.9.109.124 [DMZ1]

                dst:         176.28.45.241

                proto:       6

                sport:       21              dport:      50780

                state:       ACTIVE          type:       FLOW

                src user:    unknown

                dst user:    unknown

        start time                    : Wed Sep 24 15:50:56 2014

        timeout                       : 1800 sec

        time to live                  : 1768 sec

        total byte count(c2s)         : 0

        total byte count(s2c)         : 0

        layer7 packet count(c2s)      : 0

        layer7 packet count(s2c)      : 0

        vsys                          : vsys1

        application                   : ftp

        session to be logged at end   : True

        session in session ager       : True

        session synced from HA peer   : True

        session owned by local HA A/A : False

        layer7 processing             : enabled

        URL filtering enabled         : False

        session via syn-cookies       : False

        session terminated on host    : False

        session traverses tunnel      : False

        captive portal session        : False

        ingress interface             : ae1.301

        egress interface              : ae4.303

        session QoS rule              : N/A (class 4)

rkrakovic@PA1(active-primary)>

L7 Applicator

Hello rkra,

ssharma is correct, I have tested in my PAN firewall with a deny policy for FTP traffic.

C:\Users\sgantait>ftp ftp.abcd.net

Connected to colo-ftp2.abcd.net.

220 (vsFTPd 2.0.6)

User (colo-ftp2.abcd.net:(none)): anonymous

Connection closed by remote host. >>>>>>>>>>>>>>>>>>>>> Connection closed after the login prompt.

While i have checked the session details, it shows 4 packets in each direction to identify the app-ID signature (with login prompt) and  as soon as it identified the application as FTP, it dropped the connection and session has been DISCARDED.

        layer7 packet count(c2s)      : 4 >>>>>>>>>>>>>

        layer7 packet count(s2c)      : 4 >>>>>>>>>>>>>

--------------------------------------------------------------------------------

ID          Application    State   Type Flag  Src[Sport]/Zone/Proto (translated IP[Port])

Vsys                                          Dst[Dport]/Zone (translated IP[Port])

--------------------------------------------------------------------------------

31392        ftp            DISCARD FLOW  NS   192.168.2.49[65042]/Trust-LAN/6  (107.219.250.12[31162])  >>>>>>>>>>>>>>>> session in DISCARD state.

vsys1                                                               1.1.1.1[21]/Untrust-ISP  (1.1.1.1[21])

Hope this helps.

Thanks

L2 Linker

"You can control this behavior by denying at service level. ie. configure policy that denies port 20 and 21 from untrust to dmz. That way firewall will not wait to evaluate the application and drop the packets once received. Hope this helps."

Ssharma,

can you help me with this? When denying 20 and 21 from UNTRUST to TRUST FTP will not work.

May be you mean to combine this policy with the FTP app policy?

Roman

L7 Applicator

Hello rkra,

You may create a new security policy and apply along with the customer service defined for port 20 and 21.

For example:

Step:-1

block-FTP-1.jpg

Step:2

block-FTP-2.jpg

Step:3

Here the policy is configured from Trust to Untrust as an example, in your case you need to create it from ZONE Untrust und ZONE DMZ. In this security polict, we need to remove the application FTP and keep it as "any" and add the custom service "FTP- Block"

block-FTP-3.jpg

Hope this help.

Thanks

Hi Rkra,

Yes that will completely deny FTP application the moment we receive the 1st Syn. Policy will basically look for any traffic that is coming from Untrust to Trust on Port 20 and 21. Thank you.

  • 1 accepted solution
  • 3747 Views
  • 7 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!