Firewall has a 3-way connection establishment handshake, and a pair of 2-way close handshakes.
The PIX, like many other professional firewalls, is a stateful firewall. Essentially, this means that the PIX actively monitors all connection oriented traffic (mainly TCP), and builds a connection table (or database) that it uses to keep track of active sessions. Depending on where you set your buffer logging, you can see both the building and teardown of TCP connections that traverse the firewall. For example, you may have a user opening up an FTP session from the inside of your network out to the internet somewhere. In this case, you will see the PIX log a message like:
Built outbound tcp connection for IP address/source port to IP Address/21... (word order not exact, but you get the idea)
This log message indicates the start of the 3-way handshake process (it does not mean that it worked, however...)
You can now do a "show conn" on the PIX command line, and you should see a line in there for this particular TCP session. The destination port would be 21, since this is an FTP. Also, there are some flags at the end of the line. If the connection was successful, you will see a capital U (for Up, meaning the 3-way handshake was successful). If you have any a's or s's (small or upper case), then something didn't work, and you are most likely in a SYN-Sent state, waiting for the remote Ack-SYN. That's a whole other conversation though...
Back to the topic - let's say that this connection failed, perhaps the remote FTP server is down. The PIX has some Global connection timeout values. The default value for a half-open, (embryonic) connection is 2 minutes. If the remote server doesn't send the ACK-SYN back to the initial connection establishment, then the PIX will clear the connection from it's table, and log a connection teardown message.
There are about 3 or 4 types of teardown messages that can be logged (if memory serves me). At the very end of the log entry there is a reason. Some of them are:
FINs
TCP-Reset-O
TCP-Reset-I
Conn-Timeout
Deny
There may be others, but you'd have to check the PIX docs to see (if it's even in there...)
I know you're going to ask, so here is what each one means:
FINs - this represents a normal close - in other words the two systems talking to each other mutually agreed to close the session. This is normal behavior.
TCP-Reset-O (or I): Another way that a TCP session can be closed is for one of the parties to send a TCP-Reset. This is essentially a packet that tells the other side that "I'm hanging up on you". It's the TCP/IP equivalent to when you really piss off your girlfriend, and she slams down the phone in your ear. The difference between the I and the O has to do with the interface the reset was heard from. If it's an I, it means inside - but not necessarily the actual inside interface... it's the interface that has the higher security value of the two interfaces being used to build the connection in question. If it's an O, then it came from the lower security interface...
Conn-Timeout - just what you think - this refers back to the scenario I mentioned above with the FTP session and the remote server being down. After that 2 minute timer expires, the PIX will log the teardown with this as the reason. You will also see this if the PIX active connection idle timer expires too (default is 1 hour for that). And lastly, you can see this if the two systems fail to exchange the TCP-FIN process properly (normal close process). The normal close process, by the way, is simply a FIN packet from the system who is initiating the close request, and the other side is supposed to ACK the FIN (that's one pair). Now the session is 'half-closed'. Once the remote side is ready to close the connection too, it sends a FIN, and the other side should ACK it. Now it's fully closed. If part of this pair of 2-way handshake fail, then the connection according to the PIX is half closed (you'll see F flags in the show conn command output). The half-closed timer I believe is 5 minutes. If the connection doesn't close normally after that 5 minute counter expires, the PIX clears the connection from it's table and logs this conn-timeout reason in the teardown.
Lastly, there is 'Deny'. This one is seldomly observed. Generally, you would see it if a connection that was being application inspected (like FTP or http, for example), violated the fixup rulebase. The PIX would clear the connection and log the deny as the reason in the teardown message. I've seen really old FTP servers do this.
Anyway - I hope this clears things up a bit for you. If you are using the PIX for your business and you have a lot of traffic going through it, I highly recommend you learn more about the connection table, especially the flags at the end. The PIX can be a very powerful troubleshooting tool when the application clowns are telling you there is a network problem (the story of my life!). Between the logs and the connection flags, you can pretty much see what's going on at any given moment in time - excellent for real time troubleshooting - and tossing the problem back in their laps!
The PIX, like many other professional firewalls, is a stateful firewall. Essentially, this means that the PIX actively monitors all connection oriented traffic (mainly TCP), and builds a connection table (or database) that it uses to keep track of active sessions. Depending on where you set your buffer logging, you can see both the building and teardown of TCP connections that traverse the firewall. For example, you may have a user opening up an FTP session from the inside of your network out to the internet somewhere. In this case, you will see the PIX log a message like:
Built outbound tcp connection for IP address/source port to IP Address/21... (word order not exact, but you get the idea)
This log message indicates the start of the 3-way handshake process (it does not mean that it worked, however...)
You can now do a "show conn" on the PIX command line, and you should see a line in there for this particular TCP session. The destination port would be 21, since this is an FTP. Also, there are some flags at the end of the line. If the connection was successful, you will see a capital U (for Up, meaning the 3-way handshake was successful). If you have any a's or s's (small or upper case), then something didn't work, and you are most likely in a SYN-Sent state, waiting for the remote Ack-SYN. That's a whole other conversation though...
Back to the topic - let's say that this connection failed, perhaps the remote FTP server is down. The PIX has some Global connection timeout values. The default value for a half-open, (embryonic) connection is 2 minutes. If the remote server doesn't send the ACK-SYN back to the initial connection establishment, then the PIX will clear the connection from it's table, and log a connection teardown message.
There are about 3 or 4 types of teardown messages that can be logged (if memory serves me). At the very end of the log entry there is a reason. Some of them are:
FINs
TCP-Reset-O
TCP-Reset-I
Conn-Timeout
Deny
There may be others, but you'd have to check the PIX docs to see (if it's even in there...)
I know you're going to ask, so here is what each one means:
FINs - this represents a normal close - in other words the two systems talking to each other mutually agreed to close the session. This is normal behavior.
TCP-Reset-O (or I): Another way that a TCP session can be closed is for one of the parties to send a TCP-Reset. This is essentially a packet that tells the other side that "I'm hanging up on you". It's the TCP/IP equivalent to when you really piss off your girlfriend, and she slams down the phone in your ear. The difference between the I and the O has to do with the interface the reset was heard from. If it's an I, it means inside - but not necessarily the actual inside interface... it's the interface that has the higher security value of the two interfaces being used to build the connection in question. If it's an O, then it came from the lower security interface...
Conn-Timeout - just what you think - this refers back to the scenario I mentioned above with the FTP session and the remote server being down. After that 2 minute timer expires, the PIX will log the teardown with this as the reason. You will also see this if the PIX active connection idle timer expires too (default is 1 hour for that). And lastly, you can see this if the two systems fail to exchange the TCP-FIN process properly (normal close process). The normal close process, by the way, is simply a FIN packet from the system who is initiating the close request, and the other side is supposed to ACK the FIN (that's one pair). Now the session is 'half-closed'. Once the remote side is ready to close the connection too, it sends a FIN, and the other side should ACK it. Now it's fully closed. If part of this pair of 2-way handshake fail, then the connection according to the PIX is half closed (you'll see F flags in the show conn command output). The half-closed timer I believe is 5 minutes. If the connection doesn't close normally after that 5 minute counter expires, the PIX clears the connection from it's table and logs this conn-timeout reason in the teardown.
Lastly, there is 'Deny'. This one is seldomly observed. Generally, you would see it if a connection that was being application inspected (like FTP or http, for example), violated the fixup rulebase. The PIX would clear the connection and log the deny as the reason in the teardown message. I've seen really old FTP servers do this.
Anyway - I hope this clears things up a bit for you. If you are using the PIX for your business and you have a lot of traffic going through it, I highly recommend you learn more about the connection table, especially the flags at the end. The PIX can be a very powerful troubleshooting tool when the application clowns are telling you there is a network problem (the story of my life!). Between the logs and the connection flags, you can pretty much see what's going on at any given moment in time - excellent for real time troubleshooting - and tossing the problem back in their laps!
No comments:
Post a Comment
Thank you for your comment! It is my hope that you find the information here useful. Let others know if this post helped you out, or if you have a comment or further information.