diff options
Diffstat (limited to 'source3')
| -rw-r--r-- | source3/modules/vfs_smb_traffic_analyzer.c | 126 | ||||
| -rw-r--r-- | source3/modules/vfs_smb_traffic_analyzer.h | 140 |
2 files changed, 152 insertions, 114 deletions
diff --git a/source3/modules/vfs_smb_traffic_analyzer.c b/source3/modules/vfs_smb_traffic_analyzer.c index 4465425927..7d7332e1b9 100644 --- a/source3/modules/vfs_smb_traffic_analyzer.c +++ b/source3/modules/vfs_smb_traffic_analyzer.c @@ -21,123 +21,13 @@ #include "includes.h" #include "../lib/crypto/crypto.h" +#include "vfs_smb_traffic_analyzer.h" /* abstraction for the send_over_network function */ enum sock_type {INTERNET_SOCKET = 0, UNIX_DOMAIN_SOCKET}; #define LOCAL_PATHNAME "/var/tmp/stadsocket" - -/** - * Protocol version 2.0 description - * - * The following table shows the exact assembly of the 2.0 protocol. - * - * -->Header<-- - * The protocol header is always send first, and contains various - * information about the data block to come. - * The header is always of fixed length, and will be send unencrypted. - * - * Byte Number/Bytes Description - * 00-02 Contains always the string "V2." - * 03 This byte contains a possible subrelease number of the - * protocol. This enables the receiver to make a version - * check to ensure the compatibility and allows us to - * release 2.x versions of the protocol with bugfixes or - * enhancements. - * 04 This byte is reserved for possible future extensions. - * 05 Usually, this byte contains the character '0'. If the - * VFS module is configured for encryption of the data, - * this byte is set to 'E'. - * 06-09 These bytes contain the character '0' by default, and - * are reserved for possible future extensions. They have - * no function in 2.0. - * 10-27 17 bytes containing a string representation of the - * number of bytes to come in the following data block. - * It is right aligned and filled from the left with '0'. - * - * -->Data Block<-- - * The data block is send immediately after the header was send. It's length - * is exactly what was given in bytes 11-28 from in the header. - * - * The data block may be send encrypted. - * - * To make the data block easy for the receiver to read, it is divided into - * several sub-blocks, each with it's own header of four byte length. In each - * of the sub-headers, a string representation of the length of this block is - * to be found. - * - * Thus the formal structure is very simple: - * - * [HEADER]data[HEADER]data[HEADER]data[END] - * - * whereas [END] is exactly at the position given in bytes 11-28 of the - * header. - * - * Some data the VFS module is capturing is of use for any VFS operation. - * Therefore, there is a "common set" of data, that will be send with any - * data block. The following provides a list of this data. - * - the VFS function identifier (see VFS function ifentifier table below). - * - a timestamp to the millisecond. - * - the username (as text) who runs the VFS operation. - * - the SID of the user who run the VFS operation. - * - the domain under which the VFS operation has happened. - * - */ - - -/** - * VFS Functions identifier table. In protocol version 2, every vfs - * function is given a unique id. - */ -enum vfs_id { - /* - * care for the order here, required for compatibility - * with protocol version 1. - */ - vfs_id_read, - vfs_id_pread, - vfs_id_write, - vfs_id_pwrite, - /* end of protocol version 1 identifiers. */ - vfs_id_mkdir, - vfs_id_rmdir, - vfs_id_rename, - vfs_id_chdir -}; - -/* - * Specific data sets for the VFS functions. - * A compatible receiver has to have the exact same dataset. - */ -struct mkdir_data { - const char *path; - mode_t mode; - int result; -}; - -struct rmdir_data { - const char *path; - int result; -}; - -struct rename_data { - const char *src; - const char *dst; - int result; -}; - -struct chdir_data { - const char *path; - int result; -}; - -/* rw_data used for read/write/pread/pwrite */ -struct rw_data { - char *filename; - size_t len; -}; - static int vfs_smb_traffic_analyzer_debug_level = DBGC_VFS; static enum sock_type smb_traffic_analyzer_connMode(vfs_handle_struct *handle) @@ -277,13 +167,21 @@ static char *smb_traffic_analyzer_create_string( struct tm *tm, \ char *usersid = NULL; const char *total_anonymization = NULL; const char *anon_prefix = NULL; + /* + * first create the data that is transfered with any VFS op + * These are, in the following order: + * number of data to come [6 in v2.0] + * 1.vfs_operation identifier + * 2.username + * 3.user-SID + * 4.affected file + full path + * 5.domain + * 6.timestamp + */ - /* first create the data that is transfered with any VFS op */ opstr = talloc_asprintf(talloc_tos(), "%i", vfs_operation); len = strlen(opstr); buf = talloc_asprintf(talloc_tos(), "%04u%s", len, opstr); - len = strlen( username ); - buf = talloc_asprintf_append(buf, "%04u%s", len, username); /* * Handle anonymization. In protocol v2, we have to anonymize diff --git a/source3/modules/vfs_smb_traffic_analyzer.h b/source3/modules/vfs_smb_traffic_analyzer.h new file mode 100644 index 0000000000..7a3c358a0e --- /dev/null +++ b/source3/modules/vfs_smb_traffic_analyzer.h @@ -0,0 +1,140 @@ +/* + * traffic-analyzer VFS module. Measure the smb traffic users create + * on the net. + * + * Copyright (C) Holger Hetterich, 2008 + * Copyright (C) Jeremy Allison, 2008 + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 3 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, see <http://www.gnu.org/licenses/>. + */ + + +/* + * Protocol V2.0 definition + * +/ + +/** + * Protocol version 2.0 description + * + * The following table shows the exact assembly of the 2.0 protocol. + * + * -->Header<-- + * The protocol header is always send first, and contains various + * information about the data block to come. + * The header is always of fixed length, and will be send unencrypted. + * + * Byte Number/Bytes Description + * 00-02 Contains always the string "V2." + * 03 This byte contains a possible subrelease number of the + * protocol. This enables the receiver to make a version + * check to ensure the compatibility and allows us to + * release 2.x versions of the protocol with bugfixes or + * enhancements. + * 04 This byte is reserved for possible future extensions. + * 05 Usually, this byte contains the character '0'. If the + * VFS module is configured for encryption of the data, + * this byte is set to 'E'. + * 06-09 These bytes contain the character '0' by default, and + * are reserved for possible future extensions. They have + * no function in 2.0. + * 10-27 17 bytes containing a string representation of the + * number of bytes to come in the following data block. + * It is right aligned and filled from the left with '0'. + * + * -->Data Block<-- + * The data block is send immediately after the header was send. It's length + * is exactly what was given in bytes 11-28 from in the header. + * + * The data block may be send encrypted. + * + * To make the data block easy for the receiver to read, it is divided into + * several sub-blocks, each with it's own header of four byte length. In each + * of the sub-headers, a string representation of the length of this block is + * to be found. + * + * Thus the formal structure is very simple: + * + * [HEADER]data[HEADER]data[HEADER]data[END] + * + * whereas [END] is exactly at the position given in bytes 11-28 of the + * header. + * + * Some data the VFS module is capturing is of use for any VFS operation. + * Therefore, there is a "common set" of data, that will be send with any + * data block. The following provides a list of this data. + * - the VFS function identifier (see VFS function ifentifier table below). + * - a timestamp to the millisecond. + * - the username (as text) who runs the VFS operation. + * - the SID of the user who run the VFS operation. + * - the domain under which the VFS operation has happened. + * + */ + + +/* + * VFS Functions identifier table. In protocol version 2, every vfs + * function is given a unique id. + */ +enum vfs_id { + /* + * care for the order here, required for compatibility + * with protocol version 1. + */ + vfs_id_read, + vfs_id_pread, + vfs_id_write, + vfs_id_pwrite, + /* end of protocol version 1 identifiers. */ + vfs_id_mkdir, + vfs_id_rmdir, + vfs_id_rename, + vfs_id_chdir +}; + + + +/* + * Specific data sets for the VFS functions. + * A compatible receiver has to have the exact same dataset. + */ +struct mkdir_data { + const char *path; + mode_t mode; + int result; +}; + +struct rmdir_data { + const char *path; + int result; +}; + +struct rename_data { + const char *src; + const char *dst; + int result; +}; + +struct chdir_data { + const char *path; + int result; +}; + +/* rw_data used for read/write/pread/pwrite */ +struct rw_data { + char *filename; + size_t len; +}; + + |