|
|
|
|
|
|
|
|
 |
 |
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [FW1] Active connections
>-----Original Message----- >From: [email protected] [mailto:[email protected]] >Sent: 7. mars 2001 23:24 >To: FW1-MailingList (E-mail) >Subject: [FW1] Active connections > > > >Hi everybody, > >Is there any checkpoint command which can give me the active >connections as well as the type of these connections. For >example are they http, ftp, ssl, smtp etc.. >Is look like that ./fw tab -s connections -t command is giving only virtual connections > >I'll appreciate any suggestions >Thanks > >Kiril You should be able to use the output of the fw tab -t connections - command. Below you will find an explanation on how you should read the output. Hope that will help you. /erik *********************cut/paste check point ATRG41********************* The basic structure of a connection in a table entry Many tables store entries that represent connections. In those tables, the first five fields follow a common standard. An example of these five fields is shown below along with the meaning of each field.. Other connections in other tables will, in most cases, contain the same five key fields but will store different field values. These first five fields are known as the "key" part of the table entry. <c7cb4764, 0000008a, c7cb47ff, 00000050, 00000006 ... > Field Example value Description 1 c7cb4764 Source IP address 2 0000008a Source port 3 c7cb47ff Destination IP address 4 00000050 Destination port 5 00000006 IP protocol number, as defined in RFC 1700 (11 - UDP, 6 - TCP 1 - ICMP...) Note: FireWall-1 is able to search on the "key" entries of the table. connections table The connections table contains data on all active connections. Example attributes: refresh, expires 60, expcall 133279992 4, implies 2, kbuf 1, hashsize 8192 <c7cb4764, 0000008a, c7cb47ff, 00000000, 00000011; 00000000, 00000002, 00000000; 39/40> <c7cb4765, 0000008a, c7cb47ff, 00000000, 00000011; 00000000, 00000002, 00000000; 37/40> The connections table uses the following format: Field Example value Description 1. c7cb4764 source IP address 2. 0000008a source port 3. c7cb47ff destination IP address 4. 00000000 destination port 5. 00000011 IP protocol 6. 00000000 r_ckey. This field is a pointer to the encryption key if the connection is encrypted, otherwise it is NULL 7. 00000002 r_ctype. Described below 8. 00000000 r_cflags. Described below 9. 39/40 time left/total time. There are x of y seconds left until the entry times out and is deleted from the table r_ctype The r_ctype field contains eight hexadecimal digits in the form 0000klmn. The last four digits of the value are interpreted using the tables below. Value of 'n' Description 1 TCP connection 2 UDP connection 3 Connection is encrypted 4 Reverse connection is encrypted Value of 'm' Description 0 Other 8 IPSec connection Value of 'l' Description 0 Match by protocol (the most common value) 1 Match by offset (never used) 2 Match by RPC (for RPC connections) 3 Match by getport (for RPC connections) 4 Match by callit (for RPC connections) 5 Match by seq/ack change (for encrypted/NATed connections where the SEQ/ACK numbers may be changed. Digit 'k' is interpreted as four binary digits of the form 0xyz. If a bit in any position is set to 1, the corresponding value in the table below is assumed. Bit of digit 'k' Description 0 First bit is always 0 x Established TCP connection y FIN sent in reverse connection (by the destination) z FIN sent in forward connection (by the source) r_cflags The r_cflags field contains eight hexadecimal digits that should be interpreted as four bytes of the form ghij. The values of g, h, i and j are interpreted using the tables below. Byte j is interpreted as eight binary digits of the form PQRSTUVW. If a bit in any position is set to 1, the corresponding value in the table below is assumed. Bit of byte 'j' Description P Accounting flag (0 if the connection has no accounting) Q Accounting flag (0 if the connection has no accounting) R Accounting flag (0 if the connection has no accounting) S More inspection needed for this connection (has prologue) T Reverse connection accepted without going through Rule Base U Connection accepted without going through Rule Base V One way connection (only the destination sends data) W One way connection (only the source sends data) Byte i may have the following values: Hexadecimal value Description 0x66, 0x67 IIOP connections 0x82 clear FTP PORT command 0x83 encrypted FTP PORT command 0x84 FTP PASV command 0x86 RSH stderr connection 0x88 H.245 connection Hexadecimal value Description 0x90, 0x91, 0x92, 0x93, 0x94, 0x95 Xtreme connections 0xa1 VDOlive connection 0xa3, 0xa4, 0xa5 RealAudio / RTSP connections 0xa8 RTP connection 0xaa NetShow connection 0x00 Any other connection Byte h holds the interface ID (the number of the interface in "fw ctl iflist") of the interface in the direction of the destination. Byte g holds the interface ID (the number of the interface in "fw ctl iflist") of the interface in the direction of the source. *****************************************end******************************** ********** ================================================================================ To unsubscribe from this mailing list, please see the instructions at http://www.checkpoint.com/services/mailing.html ================================================================================
|
||||||||||
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
