SecureXL – How it doesn’t work

[FYI….this is work in progress just stream of consciousnesses. I’ll remove this label when I think I’ve got it straight.]

[UPDATE: 2/14/2014] I have spent several months putting together how SecureXL/CoreXL works, creating labs, talking to developers and people much smarter than me. I am putting together a class on the topic .  I have to update this blog to reflect reality when I get time. Its probably about 75% correct…..

 

——————————————————

Ya know, I wish I could explain how SecureXL works but everytime I think I get it…I’m wrong. I’ve had several different CP people try to explain it to me.. and parts are wrong. So I’m not sure what to tell you. This will be my worst blog ever, but my goal is to spend my golden years trying to figure out how SecureXL works and fix this blog as I go.

You can stop reading now….

I was sent this document that does a great job of explaining SecureXL. But if its accurate who knows.

SecureXL How it worksL

For example: there is a statement in the SecureXL document that says any non-TCP/UDP/GRE rules will turn off all SecureXL. Well so much for ICMP I guess. But I think its wrong…. Acceleration is still turned on.

The basics you should remember.

SecureXL does two things…..

1) Accept Templates: Some protocols like HTTP 1.0 create MULTIPLE concurrent connections from a client to a single port on a single server, port 80. The rate of of acceptance by SecureXL is increased by caching these connections into a “template” connection table. After the first connection – any future ‘similar’ connections to the common port from that client are NOT forwarded to the firewall kernel, but instead instantly accepted and forwarded.

2) Connection Accelerated: SecureXL increases throughput on connections that have already been setup and inserted into connection table between a client and server. The successive packets in a connection will not go through the kernel but will be handled by interrupt handlers (watch your SI on ‘top’ command).

The following diagram was done by 51sec …..

12-17-2012 10-12-54 PM

Unfortunately SecureXL sometimes it feels like it only works if there is a full moon and NAT, VPN, IPS, and 100 other services are not enabled. If you do a fwaccel stat you will start to get feel of what is enabled…but I’m still leary. Also remember that fwaccel stats (with an ‘s’) is a totally different command.

Before you read the documenation you have to understand two things:

1) Accept templates/Connection templates/Connection accelerated: is overloaded. They are referring the grouped mainly HTTP traffic that creates templates in order to accelerate similar connections from 1 source PC. It is a ‘template’ because it intends to accelerate ‘similar’ traffic, not an exact connection.

2) Throughput acceleration: Connection table acceleration. Is to accelerate the second and subsequent packets of a connection. These packet have to perfectly match the connection table.

If you don’t know the difference between these two, the documentation will turn you around…

Below you can see the two commands, stat and stats. The stat command will tell you if connection templates #1 above is turned on and at what rule connection templates (not acceleration) is disabled, in this case rule #1 (by the red arrow) disables the creation of connection templates. This is what I wish I could tell you what the magic is, but I can’t I get different versions of reality. I know ICMP impacts because SecureXL was mostly designed just for HTTP connections grabbing 30 different pages from one client. The numbers in green list how many connections from templates of all connections are created and how many connections are going through the firewall kernel (F2F) for processing. You can see here that because rule #1 disables templates that 0 connection templates are created.

The second part below in red shows throughput acceleration from #2 above. “accel packets” is packets that are not forwarded to the firewall kernel and F2F are packets that are forwarded to the firewall kernel for rule processing. These are NOT the same as Accept Templates which are related to accelerating HTTP requests from a single PC. Only accelerating the second and subsequent packets from a single connection.

conns

Just a little more detail here. This is the ‘fwaccel stat’ and the ‘fwaccel stat -s’ command.
You can see how the % of accelerated packets is calculated. Take the current total
connections (TCP and non-TCP) and subtract the F2F connections (slow-path, the ones
that got forwarded through the kernel and not handled by interrupt processing).

Kasper has figured out (THANKS!!!) that PXL is really PSL, Packet Streaming Library which Check Point uses for its IPS engine. It re-assembles IP packets so the  IPS engine can inspect them (I have to update this diagram).  You can read about it here.

How secureXL computes its counts

How secureXL computes its counts

Little bit more of a deep dive here:

Why am I telling you this? Well, if for whatever reason you are wary of SecureXL (or don’t have a license) and decide to turn it off you can look at the before and after. You can also do you own ‘acceleration’ by moving the most hits rules to the top of the policy so they get hit first. You might have to use Tufin to figure out what the connection counts are on a per rule basis. CP also has some magic software where if you do a ‘fw tab -t connections’, they can tell you what rules are getting hit the heaviest.

And of course don’t trust SmartMonitor to report the right #’s. CP official policy is SmartMonitor is broke when SecureXL is turned on.

So sad. Just sharing the love here.

dreez

This is the “Oh YEAH…Aside from the marketing rah-rah, this is what will blow it up list”

These services prevent ACCEPT TEMPLATES from being created (Throughput acceleration is not inhibited by the presence of rules with these properties.)

• Service with a port number range

• Service type “other” with a match expression

• Service type RPC, DCOM, or DCE-RPC

• Service with “enable reply from any port” checked

• Source or destination is a domain or a dynamic object

• Time object associated with the rule

• Client or session authentication involved with the rule

• SYN Defender (the entire 3-way handshake must be supervised by the FireWall-1 application, slightly reducing the effect of connection-rate acceleration – most significant performance impact on short duration connections)

The following rule properties present in the security policy will disable throughput and connection-rate acceleration for all traffic.

• Rules with action “encrypt” on an interface that does not support cryptography

• Rules where the source or destination of the rule is the gateway itself

• Rules where the service has an INSPECT handler (e.g. FTP control connection)

• Rules with Security Servers or services with resources

Firewall Connection Rate, IP1260

• Rules with user authentication

• Rules for non-TCP/UDP/GRE/ESP connections (NOTE ICMP disables accept templates!!!, and it won’t be throughput accelerated)

Traffic Limitations

The following traffic is not throughput or connection-rate accelerated by SecureXL.

• Multicast traffic

• Directed broadcast traffic

• Traffic across an Access Control List-enabled interface

• Traffic whose Protocol field in the IP header is not TCP or UDP (e.g. ICMP, IGRP, etc.)

• IPv6 traffic

• VPN encryption algorithms that are not supported by the hardware.

• IP compression enabled for VPN traffic.

The following traffic is not connection-rate accelerated by SecureXL.

• VPN

• Complex connections such as FTP, H.323…

• Non-TCP/UDP connections

Environment Limitations

The following environment disables connection rate acceleration for the traffic that the environment is applied to by SecureXL.

NAT

FTP

VPN traffic

MORE REFERENCES:

Good Explanation from CPUG

Advertisements
Post a comment or leave a trackback: Trackback URL.

Comments

  • Dave  On December 20, 2012 at 5:32 am

    I have to disagree about RPC not disabling SecureXL. On a gateway that I’m dealing with, ALL_DCE_RPC or even just certain (but not all) RPC services will put the brakes on SecureXL. Unfortunately, I’m needing some RPC to enable AD logons across some segments so it’s a necessary evil but I have not been able to identify which specific RPC services are killing it.

    • dreezman  On December 20, 2012 at 8:29 am

      Thanks for input. Like I said I’m trying to differentiate between marketing and reality myself so any input anyone has I’d love.

      • Dave  On December 20, 2012 at 8:44 pm

        From what I can tell in my policy, it’s only the RPC bits that are preventing SecureXL from working all the way through. With any luck, perhaps I can identify which RPC services kill it. I seem to remember when I was testing it a bit earlier, some of the built-in RPCs didnt seem to disable it. It wasn’t until I hit my catch-all ALL_DCE_RPC that it stopped. Trying to discern exactly which RPC calls are needed for a system to auth against AD seems to be quite a challenge though.

  • Arjun Kanuri  On May 3, 2013 at 7:44 am

    I would like to thank you for the efforts you’ve put in penning this blog. I really hope to see the same high-grade blog posts by you in the future as well. In truth, your creative writing abilities has inspired me to get my own site now 😉

  • Kaspars  On February 20, 2014 at 2:15 pm

    PXL is not video streaming but PSL (passive stream library) accelerator. Kind of SecureXL for IPS stuff 🙂

    PSL is an infrastructure layer, which provides stream reassembly for TCP
    connections. This layer handles packet reordering, congestion handling and
    is responsible for various security aspects of the TCP layer such as handling
    payload overlaps, some DoS attacks, and others. The PSL layer is capable of
    receiving packets from the firewall chain and from SecureXL module.
    The PSL layer serves as a middleman between the various security applications
    and the network packets. This layer provides the applications with a coherent
    stream of data to work with, free of various network problems or attacks. The
    PSL infrastructure is wrapped with well defined APIs called the Unified Streaming
    APIs which are used by the applications to register and access streamed data.

    Full description in Check Point IPS Engine Architecture whitepaper

    • Dreezman  On February 20, 2014 at 6:53 pm

      This makes complete sense and is the nugget that puts IPS all together. PXL never made sense to me. I have never seen this paper before so THANK YOU so much for contributing!!

      dreez

  • Jens  On March 15, 2014 at 12:58 pm

    There is a new Checkpoint SK98348. It’s definitely worth a read in regards to SecureXL, CoreXL, …

    • Dreezman  On March 16, 2014 at 7:39 pm

      THanks! Yes I am full in reading them in detail. I am working with the authors to improve them as I read them. Sergei is really dedicated to making them right.

      dreez

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

blog.lachmann.org

Michael Endrizzi's - St. Paul MN - CheckPoint blog on topics related to Check Point products and security in general.

%d bloggers like this: