PAN Blocking Details

One of my readers sent me this question:

We have an internal discussion about whether it is possible to block the 3 way hanshake TCP but allow the JDBC application protocol. In other words we would like to block the test of the port with the command “telent address port” but we would like that the connections via JDBC continue to work. is it possible to do this theoretically? Is it possibile to do it with paloalto firewall?

Let’s have a look:

Some more details from the reader’s mail:

Please note: when I say blocking, I mean “connection refused” or “timeout” (so interrupt the 3 way handshake) I don’t intend to terminate the connection immediately

we want that:
telnet x.x.x.x y
Trying x.x.x.x…
telnet: Unable to connect to remote host: Connection refused

or that
telnet x.x.x.x y
Trying x.x.x.x…
telnet: Unable to connect to remote host: Connection timed out

but i want that the application protocol works fine?
Is it possibile whith Palo Altro Firewall? Or Palo Alto Firewall can only drop the connection after the 3 way hanshake like this:

telnet x.x.x.x y
Trying x.x.x.x…
Connected to x.x.x.x.
Escape character is ‘^]’.
Connection closed by foreign host.

I ask that because I inspected (with tcpdump) the packet of telnet command, it perform only 3 way hanshake then print to console:
Connected to x.x.x.x.
Escape character is ‘^]’.

So I think that a Palo Alto firewall cannot prevent the client from establishing the connection, but he can recognize that only after 3 way hanshake so only after TCP connection was established.

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.
    Port-based rule.

    (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.
    Application-based rule.
  • 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.
If the application on port X shall work, your telnet-test on this port X will succeed at a first glance, since it is too early for a firewall to detect the application as long as there is no data flowing through the device.

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.

Leave a Reply

Your email address will not be published.