Telnet to TCP port works even without a valid implicit/explicit security policy

[VivekPAN]

There is no FW policy which allows the SSL application over port  TCP 27017 between the given source/destinations. In fact it shows deny in the monitor -> logs but I'm able to telnet the from the source  to the destination - 172.20.249.77 over port 27017 successfully which is weird really. What could be the reason for this?Deny Logs

[OtakarKlier]

Hello,

For the Telnet traffic, which policy is allowing this, in the traffic logs? Also you can create a policy that will allow SSL over other ports, Just select SSL as the application, and then select a custom Service (port).

You will have to create the new server 27017. Just click new on the drop down.

Regards,

[VivekPAN]

Thanks for your reply but I would like to give more clarity on my issue where telnet to 27017 works even there is no policy and it's not showing in the logs as well. It took me backwards while seeing such occurence when I did a troubleshooting. 

PS : it's not allowed by any implicit policies also. 

[TomYoung]

Hi @VivekPAN ,

Do you have other L7 rules that might allow tcp/27017 before the application is identified?  When you telnet to a port, you execute the TCP 3-way handshake.  This traffic may be allowed until the NGFW sees enough packets to identify the application.  Once the NGFW has determined the application, it can allow or deny the traffic based upon the L7 rules.  The best practice to avoid allowing these initial packets is to ensure that you set application-default as the service for your L7 rules.  Then only the default ports are initially allowed.  Verify you do not have an L7 rules with a service of any.  For apps with non-standard ports, use a custom service.

Thanks,

Tom

[VivekPAN]

Hi Tom,

Thanks for your response.

1/ I don't have a firewall rule which allows the tcp/27017 at all but the telnet to the port 27017 from the source goes successful.

2, I have another query which is no way related to above query. For example, I have the below policy in place in my FW. The actual SSL application works fine from the source to the destination. But if I do a "telnet 172.1.1.2 443" from source - 10.1.1.1, the connection gets "TCP timeout" as a result. Do I need to allow "Telnet" application also in the same policy to make this work? And which means telnet'ing the destination with TCP port does not help to verify the 3-way handshake unless we don't have "telnet" app is allowed between them?

source - 10.1.1.1

destination - 172.1.1.2

destination port - 443

application - ssl

service - application-default

action - allow

[TomYoung]

Hi @VivekPAN ,

That's very interesting.  Do you have any rules with a service of "any"?  That may allow the TCP 3-way handshake on port 27017.  Or maybe application-default for one of your applications may include port 27017.

Query #2 is actually very related to query #1.  I would think the Telnet would initially succeed.  Maybe it does more than the 3-way handshake.

Thanks,

Tom

[ymiyashita]

Regarding Query #1, I would suggest to replicate it again and check the Session Browser (Monitor > Session Browser) to see which security rule the traffic is hitting. Then, it will be much clearer what's happening.

Regarding Query #2, since you said, "the actual SSL application works fine" and the service port is 443, I understand that an https server is running on port 443. If you run "telnet 172.1.1.2 443", the application won't be identified as ssl simply because it's not ssl thus the traffic won't hit the security policy that you mentioned. It won't be identified as telnet either because telnet server isn't running on that port (443). The firewall will not identify the application based on the port number, so the TCP 3way-handshake isn't enough to identify the application.
What do you want to achieve or what do you expect by running "telnet 172.1.1.2 443" against an https server? Are you trying to allow/block traffic based on the port number?

[VivekPAN]

Thanks for all your responses still I could not find the reason behind how Telnet works even If I don't allow it.

Here is another example. 

I could do Telnet successfully from the source to dest as shown below but I have the policy which allows only the SSL app over port 8443. And there is no other policy which allows "Telnet" app as I checked completely in the FW monitor. Attached the FW logs and security policy snaps for reference.

[xxx@ttgnapp0vrhom02 ~]$ telnet ttgnapp1vrhwe02.ttgtpmg.net 8443
Trying 172.20.248.150...
Connected to ttgnapp1vrhwe02.ttgtpmg.net.

ttgnapp0vrhom02 - is nothing but the server-ttgnapp0vrhom02 object in the FW policy

ttgnapp1vrhwe02.ttgtpmg.net - is an object within the address-group grp-pp-mw-eweb-servers in the FW policy

I assume only the https over 8443 should work but how come Telnet /tcp 8443 ?

[TomYoung]

Hi @VivekPAN ,

I may not have been clear before.  L7 rules on a NGFW will allow a few packets according to a security rule in order to identify the application.  This is true of all NGFW vendors.

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClIgCAK

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000CliLCAS

I don't know why the Telnet connection works for some destination IP addresses and not others.  That is most likely the behavior of the end host.  If the destination IP supports Telnet, that connection will be dropped once the application is identified.  You may be able to connect with Telnet, but you won't be able to execute any Telnet commands.

For this reason, you should never configured a drop rule by application with a service of any.  A few packets will be allowed on all ports until the application is identified.

Thanks,

Tom