| KFSensor |
| About |
| Overview |
| Screen shots |
| Features |
| Enterprise edition |
| Compare editions |
Download trial  |
| Buy KFSensor |
| News |
| Manual |
| Knowledge Base |
| Links |
| Extras |
Factsheet (.pdf)  |
Database Log
KFSensor always records events into XML files, which it stores on the local machine.
It can also store events into an SQL based database.
The Database Log dialog box enables the database settings to be configured.
By default KFSensor loads the events it displays by communicating directly with the KFSensor server.
It has an alternate mode of operation where it loads the events from a database. This mode of operation is faster for loading
a large number of events.
KFSensor uses ODBC to access the database and therefore supports a large number of database types.
The two database systems specifically supported and tested are MS SQL Server and MySQL.
Before you configure KFSensor you will need to create a blank database and configure an ODBC DSN to reference the database.
Once configured you can load the data from old log files into the database.
Use the 'Import Logs Into Database' option from the File Menu to do this.
Database ports and load order
It is common to install KFSensor and the database system it uses onto the same machine. There are several advantages to this such as the need for only one machine and the inherent security of not having both systems communicate over the network. There are however two issues with running both systems on the same machine that can make life difficult, but are easy to resolve.Database ports
KFSensor opens the ports used by the two most popular database systems, MySQL's 3306 and SQL Server's 1433.Only one system can use these ports and it should be KFSensor as there are a popular attack target.
The way around this is to configure the database system to listen to a different port number, one not associated with any other service, that is one not defined in KFSensor.
With MS SQL Server it is possible to disable TCP altogether and just use shared memory.
Service load order
By default at boot up time, Windows will start KFSensor and the database at the same time which often results in many errors in the log files and a slow down in start up times as KFSensor keeps trying to make a database connection.The KFSensor server service should start after the database system has started.
It is straight forward to configure this using the Service Dependencies field in the Server Settings dialog.
ODBC Settings
- DSN
The DSN is the name of the unique ODBC definition.
- User name
The database account name with which KFSensor should log on with - Password
The password of the database account.
n.b. The User name and password may be blank if not needed. For example if you are using Windows integrated security in SQL Server.
Options
- Enable database logging
If this option is checked then the KFSensor Server will write log events to the database. - Monitor uses database
If this option is checked then the KFSensor Monitor will read log events to the database.
- DB Latency
A delay in milliseconds.
Some databases systems do not immediately update the database file system, which can cause problems for KFSensor.
This setting adds a delay to the processing of the log data to avoid database latency being an issue.
For Microsoft Access use a value of 1500. Database servers such as MySQL and MS SQL Server are not affected by this issue and a value of 0 should be used. - Store binary as text
The received and sent fields of each event can contain any type and any size of data. This is often in a non text format.
There are two different ways in which this binary data can be stored in the database.- Unchecked - use long binary field
The default option is to store the raw data in a long binary, or BLOB field in the database.
This option is the fastest and most compact. - Checked - use long text field
If this option is checked then the binary data is encoded into a text format and saved in a long char, or Memo field in the database.
This option is slower, as the data needs to be converted both to and from the text format. It also uses up significantly more space in the database.
The main advantage of this option is that in certain databases it is much easier to view and search a long char field than a long binary field. This is only important if you plan to examine or process the log database yourself.
- Unchecked - table - kflog
This table defines the received and sent fields as OLE Object fields in Access and as mediumblob fields in MySQL. - Checked - table - kflogt
This table defines the received and sent fields as Memo fields in Access and as mediumtext fields in MySQL.
- Unchecked - use long binary field
- Memory conservation
- Unchecked - KFMonitor loads and keeps complete events in memory. If there are many events with large received and sent fields then this will use a considerable amount of memory
- Checked - KFMonitor only loads partial contents of an event, significantly reducing the amount of memory used. The disadvantage is that there will be a slight delay when the event details dialog is displayed, or when an event is exported, as the full details will then have to be loaded.
Database Version
Displays the current KFSensor database version.
As new features are added to KFSensor so occasionally there is need to change the database structure.
KFSensor will inform you if have an old database structure and allow you to upgrade it using the Configure button.
Buttons
- Configure
KFSensor requires several tables to be created in the database before it can be used.
This button creates the tables that KFSensor needs.