# 9. Options related to LogIDS 1.0 Pro only

As the title of this chapter indicates, I will focus here on the options that are specific to LogIDS 1.0 Pro only. This version offers more analysis support and better handling of the following log files: Snort, Windows Event Viewer logs (transfered with LogAgent in ascii format), ComLog, ADSScan, IntegCheck, and the data related to the running services, open shares and startup configuration reported by LogAgent 4.0 Pro. Each of these files have their own particularity that made them still manageable in LogIDS 1.0 Open Source, but in a somewhat clumsy way. We will look in more details how LogIDS 1.0 Pro works better with these specific files.

### - Snort :

Snort is recognized as one of the best network-based IDS around today, and even if I am not an expert with it (far from it actually), I have to agree with this statement. But one of the problem when dealing with Snort in LogIDS, as we've seen earlier, is the fact that snort logs are multi-lined, and LogIDS deal better with single-lined logs. Another problem lies in the fact that each line have it's own format, and each record may not necessarily have the same number of lines. Altough it is possible to circumvent these shortcomings in an acceptable way by fiddling with the rules in the Open Source version, LogIDs 1.0 Pro will analyze each of the lines coming from Snort, and rebuild the record with each field in a way that LogIDS can effectively deal with it later just like any other log. Snort already have built-in rules in LogIDS 1.0 Pro, which is to sound an alert when Priority 1 events occur, sound a warning for Priority 2 events, display idsreport.bmp on appropriate items on the GUI network map, and display the relevant fields in the appropriate text box. Note that not all of the Snort data is used, only the label, classification, priority, source, dest, date, protocol and references, if any. Even if you don't have to define rules for Snort (in fact, they will be overlooked by the program), you still need to define it in filter.txt, in the same way we did with the Open Source version, the 'line' field being reserved for that specific use.

### - Event Viewer logs :

Like Snort, Events from the Windows Event Viewer are multi-lined, and records vary in size. And in the same way, LogIDS 1.0 Pro will take extra steps to rebuild these records field by field, so that it can eventually be treated just like any other log file. Unlike for Snort though, I did not implement any pre-defined rules for the Event Viewer logs; instead, I have opted for going the extra mile in providing you with granularity control of your rules by defining pre-defined field names that you can use in your rules. The pre-defined field names that you can use when dealing with Event Viewer logs are the following:
`label` : Name of the Event Viewer reporting (Application, System or Security), along with the record number
`timegenerated` : comes from the Event, self-explanatory
`timewritten` : same as above
`computer` : same as above
`eventtype` : can be any of : `Error, Warning, Information, Audit Failure, Audit Success`*
`eventid` : Event numerical ID
`category` : comes from the Event, self-explanatory
`source` : same as above
`message` : same as above, if any, mostly seen in Security Events

As for the Security Events, they also have an additional field, labeled 'description which contains a textual meaning to the Event ID field, which helps in interpreting the Event at hand. Look in the appendices for a complete list of the Security Events that LogIDS 1.0 Pro can handle automatically

* For a more complete descrition about the meaning of these values, please report to your Microsoft documentation regarding the Event Viewer.

### - ComLog :

I think this is one of the coolest features of LogIDS 1.0 Pro. ComLog also suffers from being a multi-line log file, but also has the particularity of being a session file, not just the reporting of some log entry. Besides, printing ComLog sessions in the same window as the rest of the output doesn't give it justice, and makes it harder to keep track of what's going on when things are happenning, as it goes too fast in such a little space. To resolve all this, LogIDS 1.0 Pro opens a new window for each new ComLog session reporting. Each window have the hostname, ip address, date and time printed in the window title bar, for easy identification, and each session is kept in a separate window, even if launched from the same machine. When you are done with viewing the window, you can simply close it. The log file is still in the \backup folder for future reference if you need to, or you can copy&paste the session text before closing the window. There are no rules pre-defined for ComLog, apart from the separate window handling, but you can define your own if you want with the field 'line' (as defined in filter.txt), where you can try to do suspicious string pattern matching for example.

### ADSScan :

This one is simple. It overlooks ADSScan's message where it is reporting to start, but have pre-defined rules for anything else it will get, since it means that an alternate data stream as been found on a system. The rules here are pretty simple : sound an alert, change the appropriate icon to a red exclamation mark, and display the message being reported.

### IntegCheck :

IntegCheck is dealt with pretty much in the same way as ADSSCan. These two are really easy to deal with, and I added the extra support for them more for convenience than to fill a technical gap.

### services.log :

The handling of the data piped into services.log from LogAgent 4.0 Pro can be effectively be made in conjunction with the file services.txt, located in the root folder of LogIDS 1.0 Pro, like all the other configuration files. services.txt simply contains the list of the services that are allowed to run on your machines, like this: `

    Alerter
    EventLog
    Server
    Workstation
    LogAgent 4.0 Pro Service
    Messenger
    TrueVector Basic Logging Client
    Plug and Play
    Protected Storage
    Remote Access Autodial Manager
    Remote Access Connection Manager
    Remote Procedure Call (RPC) Service
    Task Scheduler
    Telephony Service
    TrueVector Internet Monitor

`

Any other running service reported be LogAgent 4.0 Pro to LogIDS 1.0 Pro will produce an alert sound, a red exclamation mark, and the display of the offending service where appropriate.

### shares.log :

This file is also generated by LogAgent 4.0 Pro, and concerns the open shares available on your network. Much in the same way as with the services, this part is handled with the file shares.txt, and works in a similar fashion. you simply put the list of allowed shares to be present on your network: `

    Log
    Log$
    ADMIN$
    C$
    D$
    G$
    H$
    I$
    IPC$

`

Here again, anything that does not match the list will produce the same symptoms as the previous two, with the difference that it will be a warning instead of an alert.

### startup.log :

And finally, startup.log, which is also generated by LogAgent 4.0 Pro, deals with the items present in the startup configuration of the machines in your network. The strategy here is the same, and any discrepancy from startup.txt will produce an alert signal similar to what has been described in this chapter. To avoid mistakes, this file could probably be best built by taking the output of startup.log to get the correct syntax. Here is what startup.txt could look like: `

    userinit
    SystemTray:SysTray.Exe
    AVG_CC:D:\Program Files\Security\Grisoft\AVG6\avgcc32.exe /startup
    WinampAgent:"D:\Program Files\Multi Medias\Winamp\Winampa.exe"
    BrowserWebCheck:loadwc.exe
    SchedulingAgent:mstinit.exe /logon
    Cookie Crusher:d:\program files\security\Cookie Crusher\ccwatch.exe
    internat.exe:internat.exe
    GetRight Monitor.lnk:D:\Program Files\Utils\GetRight\getright.exe
    Microsoft Office Shortcut Bar.lnk:D:\Program Files\Microsoft Office\Office\MSOFFICE.EXE
    PGPtray.lnk:D:\Program Files\Security\PGP\PGP50\PGPtray.exe
    ZoneAlarm.lnk:D:\Program Files\Zone Labs\ZoneAlarm\zonealarm.exe

`

All this added flexibility, extra analysis and finally more power at handling your logs files efficiently, coupled with the various forms of log file origins, make this intrusion detection system unmatched so far for the coverage of security issues while handling everything under one single comprehensive graphical interface.
8. Graphical interface options
10. Practical case scenario