CPUG: The Check Point User Group

Resources for the Check Point Community, by the Check Point Community.


First, I hope you're all well and staying safe.
Second, I want to give a "heads up" that you should see more activity here shortly, and maybe a few cosmetic changes.
I'll post more details to the "Announcements" forum soon, so be on the lookout. -E

 

Results 1 to 5 of 5

Thread: TCP State Logging - sk101221 - Need help to understand differences

  1. #1
    Join Date
    2014-07-21
    Posts
    57
    Rep Power
    11

    Default TCP State Logging - sk101221 - Need help to understand differences

    Hi,

    I have some questions regarding this sk101221. I am not sure if I understand the differences correctly. Further I cannot submit any feedback on the CheckPoint page - it is still telling me "Submitting" but it does not.
    So I just past here the questions and comments I wanted to send to checkpoint without any other formatting:

    ##############################
    Hello,

    I have difficulties to understand the different kernel parameter values and the differences.

    So please tell me if my understanding is correct:

    1.) When "fw ctl set int fwconn_tcp_state_logging 0" (default), I can only see one log "Accept" in Smartview Tracker for the connection. Independet if the 2way handshake or something else was successfully/happend.

    2.) When "fw ctl set int fwconn_tcp_state_logging 1" I see one log entry im SmartView Tracker for "Accept" for the first TCP SYN. Do I see additional Logs in SmartView Tracker for other states? If I understand correctly I would only expect "DST FIN" and "SRC FIN" AND only for connections which where NOT in established state? So never finisches 3 way handshake, right?
    How many additional logs will I expect in Tracker? default ist the "TCP SYN" log which I can always see and then another log which contains "SRC FIN" or "DST FIN", right?


    3.) When "fw ctl set int fwconn_tcp_state_logging 2" I can expect additional logs for "DST FIN", "SRC FIN", "SYN_SENT" and "SYNACK" ? So I would only expect one additional log, righT?


    4.) When "fw ctl set int fwconn_tcp_state_logging 3" I can expect all TCP states mentioned in the SK. AND I see the default Accespt Log for TCP SYN and I must see the following additional logs depending of the case:

    4a) Connection established and successfully finished (ESTABLISHED, BOTH FIN)

    4b) Connections established but finished only from one site (ESTABLISHED, DST FIN, SRC FIN)

    4c) Connection not established successfully (SYN SENT, SYNACK)
    So I am not sure how you came to the conclusion that with "fw ctl set int fwconn_tcp_state_logging 3" I must expect 4-5 times of the logs?

    - So please help me to understand which TCP states I can expect in which kernel parameter value?

    - Please explain me how many additional logs I can expect per kernel parameter value (worst case and best case)

    - Please tell me if there is a way in SmartView Tracker to follow a connection state. For example If I see the initial TCP SYN "Accept" log in SmartView tracker, ist there a way like in Wireshark with "Follow TCP Stream" to see all additional logs to this connection?

    - Is there a way in SmartView Tracker or Smartlog to search all "Accept" packets which have the additional state information set? I would try to search for all connections which have "SRC FI" or "DST FIN" or "SYN SENT" or "SYNACK" set, because this could be a connection I need to have a deeper look into.

    - What kind of performance impact do I have to expect? Will it cost performance depending on firewalling/deep inspection power or will it cost more performance related to the additional number of logs which are sent? So if it is the number of logs only then it will cost performance on the Gateway itself and on the destination Log server, right?


    -Which process/daemon is responsible for that on the gateway so that I can compare the default setting with the other settings in my environment and find out if it is "OK" or "NOT OK" to enable these features in my environment.


    PS:
    I am using R77.10 - please explain and document if there are differences between R77.x and perhaps R80 - if there are any differences you know about yet.

    This SK is very usefull and helpfull but needs some more explaination what the differences are.
    #########################

    Can someone enlighten me ? :-)


    Regards

  2. #2
    Join Date
    2012-07-19
    Posts
    108
    Rep Power
    13

    Default Re: TCP State Logging - sk101221 - Need help to understand differences

    From reading the sk:

    Quote Originally Posted by Nachtfalke View Post
    2.) When "fw ctl set int fwconn_tcp_state_logging 1" I see one log entry im SmartView Tracker for "Accept" for the first TCP SYN. Do I see additional Logs in SmartView Tracker for other states? If I understand correctly I would only expect "DST FIN" and "SRC FIN" AND only for connections which where NOT in established state? So never finisches 3 way handshake, right?
    How many additional logs will I expect in Tracker? default ist the "TCP SYN" log which I can always see and then another log which contains "SRC FIN" or "DST FIN", right?
    You'll get one log entry for the SYN. If there was no connection established and the session expires due to check point's TCP timeout, you should get an extra log with TCP State SYN_SENT as the session technically never progressed.

    Quote Originally Posted by Nachtfalke View Post
    3.) When "fw ctl set int fwconn_tcp_state_logging 2" I can expect additional logs for "DST FIN", "SRC FIN", "SYN_SENT" and "SYNACK" ? So I would only expect one additional log, righT?
    Again, when the sk says "timeout", we're talking check point's TCP timeout. So you'll get on log for the SYN, and if and only if the session expires due to timeout (3600 secs inactivity or was never established) you get another log message.

    Quote Originally Posted by Nachtfalke View Post
    4.) When "fw ctl set int fwconn_tcp_state_logging 3" I can expect all TCP states mentioned in the SK. AND I see the default Accespt Log for TCP SYN and I must see the following additional logs depending of the case:
    4a) Connection established and successfully finished (ESTABLISHED, BOTH FIN)
    4b) Connections established but finished only from one site (ESTABLISHED, DST FIN, SRC FIN)
    4c) Connection not established successfully (SYN SENT, SYNACK)
    So I am not sure how you came to the conclusion that with "fw ctl set int fwconn_tcp_state_logging 3" I must expect 4-5 times of the logs?
    3-Way TCP Handshake
    Entry 1: SYN_SENT (src -> dst: SYN)
    Entry 2: SYNACK (dst -> src: SYN-ACK)
    Entry 3: ESTABLISHED (src -> dst: ACK)

    plus 1-2 log entries with FIN/Expired (or RST or else). Depends on the application. That's at least 4 log entries for successful TCP sessions (and thus close to 4x log amount if successful TCP sessions are the brunt of your traffic).

    Quote Originally Posted by Nachtfalke View Post
    - Is there a way in SmartView Tracker or Smartlog to search all "Accept" packets which have the additional state information set? I would try to search for all connections which have "SRC FI" or "DST FIN" or "SYN SENT" or "SYNACK" set, because this could be a connection I need to have a deeper look into.
    I'd try to search for src: dst: service: and "TCP state" in SmartLog. That should work.

    Quote Originally Posted by Nachtfalke View Post
    - What kind of performance impact do I have to expect? Will it cost performance depending on firewalling/deep inspection power or will it cost more performance related to the additional number of logs which are sent? So if it is the number of logs only then it will cost performance on the Gateway itself and on the destination Log server, right?
    The gateways need to send more logs, so performance impact may be high if you have a high number of new TCP sessions per time interval. Disk I/O on the management will increase according to that, and disk space may be an issue (both for logs and SmartLog indices).

  3. #3
    Join Date
    2010-06-06
    Posts
    1
    Rep Power
    0

    Default Re: TCP State Logging - sk101221 - Need help to understand differences

    Below each of your questions (marked as "Q#"), you will find an answer (marked as "A#").

    Q1) When "fw ctl set int fwconn_tcp_state_logging 0" (default), I can only see one log "Accept" in SmartView Tracker for the connection. Independent if the 2way handshake or something else was successfully/happened.
    A1) When "fw ctl set int fwconn_tcp_state_logging 0" (default), TCP State is not logged.

    Q2) When "fw ctl set int fwconn_tcp_state_logging 1", I see one log entry in SmartView Tracker for "Accept" for the first TCP SYN. Do I see additional Logs in SmartView Tracker for other states? If I understand correctly I would only expect "DST FIN" and "SRC FIN" AND only for connections which where NOT in established state? So never finishes 3 way handshake, right?
    How many additional logs will I expect in Tracker? default is the "TCP SYN" log which I can always see and then another log which contains "SRC FIN" or "DST FIN", right?
    A2) When "fw ctl set int fwconn_tcp_state_logging 1", state of expired connections is logged. Refer to "TCP state expected values in SmartView Tracker log" section in sk101221.

    Q3) When "fw ctl set int fwconn_tcp_state_logging 2", I can expect additional logs for "DST FIN", "SRC FIN", "SYN_SENT" and "SYNACK" ? So I would only expect one additional log, right?
    A3) When "fw ctl set int fwconn_tcp_state_logging 2", TCP state of all expired connections is logged. Refer to "TCP state expected values in SmartView Tracker log" section in sk101221.

    Q4) When "fw ctl set int fwconn_tcp_state_logging 3" I can expect all TCP states mentioned in the SK. AND I see the default Accept Log for TCP SYN and I must see the following additional logs depending of the case:
    Q4a) Connection established and successfully finished (ESTABLISHED, BOTH FIN)
    Q4b) Connections established but finished only from one site (ESTABLISHED, DST FIN, SRC FIN)
    Q4c) Connection not established successfully (SYN SENT, SYNACK)
    So I am not sure how you came to the conclusion that with "fw ctl set int fwconn_tcp_state_logging 3" I must expect 4-5 times of the logs?
    A4) When "fw ctl set int fwconn_tcp_state_logging 3", TCP state of all connections is logged. Refer to "TCP state expected values in SmartView Tracker log" section in sk101221.

    Q5) So please help me to understand which TCP states I can expect in which kernel parameter value?
    A5) Refer to "TCP state expected values in SmartView Tracker log" section in sk101221. Refer to explanation about TCP state machine. For example, http://www.tcpipguide.com/free/t_TCP...MachineF-2.htm

    Q6) Please explain me how many additional logs I can expect per kernel parameter value (worst case and best case)
    A6) It is not possible to provide any numbers / formula. The amount of TCP state logs depends on the amount of TCP traffic, which rules are configured to log TCP connections, on the value of kernel parameter "fwconn_tcp_state_logging". Check Point did not perform any performance tests with this kernel parameter.

    Q7) Please tell me if there is a way in SmartView Tracker to follow a connection state. For example If I see the initial TCP SYN "Accept" log in SmartView Tracker, is there is a way like in Wireshark with "Follow TCP Stream" to see all additional logs to this connection?
    A7) Neither SmartView Tracker, nor SmartLog provide a "Follow TCP Stream" functionality similar to Wireshark.

    Q8) Is there a way in SmartView Tracker or SmartLog to search all "Accept" packets which have the additional state information set? I would try to search for all connections which have "SRC FI" or "DST FIN" or "SYN SENT" or "SYNACK" set, because this could be a connection I need to have a deeper look into.
    A8)
    In SmartView Tracker:
    a) verify that "Information" column is displayed (if it is not, then go to "View" menu at the top - click on "Query Properties" - check the box - go to "View" menu at the top - click on "Query Properties" to hide that window)
    b) right-click on the "Information" column - click on "Edit Filter..." - in the "Field:", select "Contains" - in the "Text:", type "tcp state" (without quotes) or any relevant text (e.g., "syn_sent", "both fin") - click on OK
    c) right-click on the relevant log - go to "Follow" menu - click on the relevant option (Source, Destination, Rule)

    In SmartLog:
    a) in the search field, type "tcp state" (without quotes) or any relevant text (e.g., "syn_sent", "both fin") and press Enter
    b) right-click in the relevant column - go to "Add to Filter" menu - click on the desired value - this way you can built the final query to filter for the relevant log entries

    Q9) What kind of performance impact do I have to expect? Will it cost performance depending on firewalling/deep inspection power or will it cost more performance related to the additional number of logs which are sent? So if it is the number of logs only then it will cost performance on the Gateway itself and on the destination Log server, right?
    Which process/daemon is responsible for that on the gateway so that I can compare the default setting with the other settings in my environment and find out if it is "OK" or "NOT OK" to enable these features in my environment.
    A9) When "fw ctl set int fwconn_tcp_state_logging 3", Security Gateway will send additional logs on every logged TCP connection, which might negatively impact the performance (due to the additional number of logs, "fw" / "fwd" daemon and/or FireWall kernel might consume CPU at high level on Security Gateway). Check Point did not perform any performance tests with this kernel parameter.

    Q10) I am using R77.10 - please explain and document if there are differences between R77.x and perhaps R80 - if there are any differences you know about yet.
    A10) There is nothing specific to this SK article that was changed in R80 Management Server. On a general note, there improvements in the performance of log processing, in user experience in SmartConsole, integration of SmartEvent NGSE, etc.

  4. #4
    Join Date
    2009-04-30
    Location
    Colorado, USA
    Posts
    2,252
    Rep Power
    20

    Default Re: TCP State Logging - sk101221 - Need help to understand differences

    Wow great post SERGEi, thanks for the clarifications. Might want to consider adding this content to sk101221 in some kind of FAQ format.

    Only thing I would add (that was also mentioned in an addendum to my book) is that on firewalls prior to version R77 that don't have the TCP state logging capability, the Track option "Account" can be used to log some additional statistics about a connection after it ends. These statistics can be used to infer somewhat how the connection ended.
    Last edited by ShadowPeak.com; 2016-07-14 at 08:20.
    --
    Third Edition of my "Max Power 2020" Firewall Book
    Now Available at http://www.maxpowerfirewalls.com

  5. #5
    Join Date
    2014-07-21
    Posts
    57
    Rep Power
    11

    Default Re: TCP State Logging - sk101221 - Need help to understand differences

    @SERGEi

    Thank you for posting here the exactly same as you did in the support ticket I opened in the past. Answering the question with the same answer as it is written in the SK is "very usefull".
    Further I had the feeling that your answer - here and in the support ticket - tends to be a little bit unpolite but this could be only me personal intention.


    I hoped I would get a matrix which shows me which states I can expect dependent on which log level I set. And probably it would be possible to calculate the maximum possible state changes dependent on the log level - independet if these will visible on every connection or can vary (be lower).

    for example something like this:

    State 1 State 2 State 3 State 4 max expecten_states (additional logs)
    log_level=1 x x 2
    log_level=2 x x x 3
    log_level=3 x x x x 4


    So if there is someone who wants to help me with the above question/matrix is welcome. If not I will have to find the answer somewhere else.


    Kind regards

Similar Threads

  1. Understand fw monitor keywords i,I,o,O
    By m_1607 in forum Check Point UTM-1 Appliances
    Replies: 1
    Last Post: 2013-03-05, 03:42
  2. DLP R75.40 Problems to understand and solve
    By rpetrov in forum Data Loss Prevention Blade (DLP))
    Replies: 0
    Last Post: 2012-11-07, 07:30
  3. Please help me to understand UTM
    By rotherdrummer in forum Check Point UTM-1 Appliances
    Replies: 1
    Last Post: 2009-10-16, 07:56
  4. A little error I don't understand !!!
    By ducnv in forum Authentication
    Replies: 2
    Last Post: 2009-04-06, 10:42
  5. Help me understand how NAT and VPN tunnels work with each other
    By hammop1 in forum IPsec VPN Blade (Virtual Private Networks)
    Replies: 0
    Last Post: 2008-04-24, 11:05

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •