jSguil

We really do love Sguil, but the client and server lack a few desirable things. As far as I can tell, there is only one SQL connection shared between the server and all the clients connecting to it. Obviously if someone runs a SANCP query that is a little over the top, until it comes back everyone else cannot query the database. This would make sense as the Sguil server requires the non-threaded version of TCL to work. LAMP based applications don’t run into this single connection for all users bottleneck as Apache and MySQL are multithreaded and each request will create its own (or multiple) database connection for the POST/GET and then close it on completion. I already knew about SQuerT, but it lacks a few things, such as an authentication mechanism.  There also is a web client directly associated with the Sguil project, but it was never fully completed and most of the application is a mock up. Lastly, the current Sguil clients will not be that easy to integrate with our upcoming NetWitness deployment. The combination of which, should be quite awesome.

So I have decided to start developing, what I am calling for now, jSguil. It will be along the lines of SQuerT in that it is not to be a function for function replacement for the standard TCL Sguil client. This basically gives me an excuse to actually buckle down and learn JSON/jQuery/webtwodotoh. It will be written in PHP and utilize jQuery/jqgrid. Development so far has been slow and painful as I continiously learn how to actually write PHP/JavaScript (sort of). It end up with me having to redo the entire thing I just spent two hours on due to discovering how to do something in a much better manner. Below is a screenshot of just the SANCP queries you can run. You can sort the results of each column by clicking on it. You may also notice the data is paginated and is currently allowing you to view 50/200/500 records at a time. Every time you sort or get a new page, another query is executed for only the number of  records you have chosen to display. This keeps the response times quite fast, even on large resultsets.