PAN Blocking Details

One of my readers sent me this question:

Let’s have a look:

Some more details from the reader’s mail:

Basically, the reader is correct: The Palo Alto Networks firewall can’t prevent the client from establishing the basic telnet connection if there’s a matching allow policy in place. In other words: If the application shall work, the port has to be open and can be tested with telnet. However, if your policy allows only one certain application, you won’t be able to use this telnet session for everything. At some point, Palo Alto will recognize that your telnet-test is NOT the allowed application and will reset/block the connection.

How security policies from Palo Alto Networks work

• Either you’re using a destination TCP/UDP port-based rule, called “Service” in the PAN language. This allows/denies connections solely based on their port. (Commonly only the destination port is used for this.) Allowing port 80 will allow *anything* over this port, such as basic HTTP, Telnet, SSH, TLS, SMTP, whatever. This is the old school way of port-based firewalls and not recommended anymore.

  (Of course, the destination server must listen on this port and reply to your source IP address. In the case of TCP the full three-way handshake of SYN, SYN-ACK, ACK takes place, before any data is transferred.)

• Or you’re using an application-based rule, with or without a more restricted service of “application-default”, “any”, or “select …”. For example, you’re allowing the application “smtp” with a service of “application-default”, i.e., TCP port 25. Now, the client’s very first “SYN, SYN-ACK, ACK” will always be allowed (!) independent of the application. This is probably weird for many admins. It can be a valid mail transfer or just a telnet-test. BUT: Immediately after the first data packets traverse the firewall, it recognizes the upper-layer application (such as smtp or http or ms-rdp) and will block the session if it’s not smtp.

• In any case: As long as the port is allowed (either through a port-based rule or an application-based rule with any kind of service), the three-way TCP handshake will succeed! You will always be able to telnet to the destination service. But you won’t be able to do something different than the allowed application, as long as you’re using an application-based rule.

That is: Your clients/users will always be able to check whether the destination server and port is up and running. But they will be blocked immediately if they do something different than the allowed application.

What Palo Alto can do to block unwanted connections

• Use more specific source/destination IP addresses in your policies. Only valid clients should access the needed servers.
• Only allow needed applications with its “application-default” destination ports. In the case of the “any” selection, *every* TCP/UDP connection will be allowed at a first glance, till the real application is detected. (Again: this might be weird! Have a look at this post: Palo Alto Application: First Packets Will Pass!)
• Use User-IDs to allow only connections from declared users. This is a great feature that distinguishes between the mere IP address of a terminal server (for example), and the different users that are using this single machine.

Featured image “‘U gotta ticket ?’” by CJS*64 is licensed under CC BY-NC-ND 2.0.