The Windows Branch

Well I've practically completed porting the existing Traffic Analyzer code over to Windows. One or two sacrifices had to be made, however, most notably I had to cope with the lack of support for certain struct sockaddr conversion functions such as inet_aton which are normally in the arpa/inet.h header. Still, it's compiled (under MinGW, screw you Visual Studio!) and seems to work so that's cool.

Additionally, the packet capture and processing features of the Traffic Analyzer were practically completed last week when I did a partial re-write. Packet processing is now done within the constructors of the three primary classes; Session, ServerResponse and ClientCommand. Sessions encapsulate ClientCommand objects which then encapsulate their corresponding ServerResponse objects. Generic information is extracted from server responses, such as the number of rows affected by a query, error codes, warnings and server status codes. Client Commands could be elaborated upon but that's not a major issue and can be added later when integrating the RuleFilter class.

I'm looking into constructing classes with the MySQL C API so that information can be dumped into the MySQL Auditing Server and configuration data can be downloaded from it. This will be pretty straightforward, in my opinion, and should port to Windows pretty easily. I expect this portion of the coding process to be completed over the long weekend.

A Strong Handshake...

After many gruelling hours I've managed to put together reliable methods for decoding the contents of both the Server Handshake packets and Client Credentials packets. Due to the fact that both packet types contain variable length-strings representing details such as the server's version and the client's username (added to the fact that I want to use the MySQL C API) I had to stay away from c++ strings and remain in the realm of null-terminated C-strings. Of course, this meant I had to introduce measures for preventing memory leaks since we're talking about variable length (dynamic!) strings.

That was quite a headache given the amount of complex pointer-passing I'm doing, with segfaults rearing their heads left right and center along the way. However now that I've got some solid methods for decoding, creating and destroying these data types, I'm confident that subsequent work on decoding command and response packets will got far more smoothly!


We'll be having a conference call tomorrow and I hope that I'll have the command decoding methods completed before then so that I'll have a nice lump of progress to demonstrate :)

The woes of session tracking...

After a relaxing holiday in France with some friends I now return to coding! I can feel my tan wearing off already as I enclose myself in my room, fingers tapping away on the keyboard, screen glaring its artificial light onto skin which for a few sweet days had basked in the glow of real sunlight!

But that's for losers.

Anyway, the problem right now is the size of the steps I'm taking. The initial traffic analyzer design was simple enough because it didn't attempt to interpret the MySQL packet payloads in any significant way. It discarded unprintable characters and dumped the rest to the console or to a file. Right now, however, I've assigned myself the task of actually interpreting the data I'm receiving and this is not quick or easy.

The problem lies in the passive nature of the system. As with the design of any complex piece of software, you have to think long and hard about what can go wrong. In the case of a packet capture-based system where the input is variable and comes from unpredictable sources this is very much the rule of thumb. I am designing and implementing classes which will differentiate between connections and store data about those connections in discrete storage systems for later processing.

Due to the nature of MySQL packet payloads, only the initial connection handshakes really hold data about who is logging on to the server and what the server's capabilities are. Subsequent packets are aimed at a specific socket which is handled by a MySQL thread spawned for the given session, with all related session data assembled during the initial handshake. The difficulty in aping this system is high, especially when you consider that the auditing system may be executed after the initial handshake packets have already been sent. Little contingencies like that have to be planned for.

So right now I'm putting together a fairly complex set of classes which will identify packet's related session, understand the nature of those packets in terms of their purpose and extract relevant data from them.