[Irongeek]

Ok, I'm working on another simple Autoit3 script. This one watches the Windows logs for common attacks that happen at an open WiFi hotspot like a coffee house (see http://www.irongeek....ity/coffeecrack ). It watches three things and pops up a message in the Windows systray when it sees the following:

New or changed ARP table entry (Think poor man's ARP Watch for Windows)
New event in security log
New event in firewall log

It's a pretty ghetto excuse for an IDS, but it's something I wanted to create. Any ideas as to a catchy name? The source will be released with the exe.

[mirrorshades]

DecafIDS ?

DecaffeinatID ?

[jabzor]

mirrorshades, on Jun 17 2008, 10:42 AM, said:

DecaffeinatID ?

/me likes

[Irongeek]

So far DecaffeinatID is in the lead. Whoever's name I go with, I'll link to their profile from the page or to their site if the tell me what it is.

[Dirk Chestnut]

Nah, go with something more generic. Maybe SimpleIDS? Considering it's not *just* something that works at a coffee shop... it is a simple IDS meant for desktops/laptops. Think about your range of users, and how they'll stumble onto it. Likely, they'll search something like "simple IDS" or "IDS for Windows" rather than something like "IDS for use in a coffee shop."

Just my two cents.

[M0ralGray]

If you're going for the coffee like name then i'd go with mirrorshades' DecaffeinatID. It's unbeatable. For a more generic name, as Dirk suggested, how about...

scrutinIDS - Play on the word scrutinize

WID Awake -W(indows)I(ntrustion)D(etection), Wide awake...

IDS of Vigilance - Beware the ides of March, and so forth...

Just some ideas

--M0ralGray

[Irongeek]

Ok, I need folks to test it and let me know. Get it from here:


http://www.irongeek.com/i.php?page=securit...tch-for-windows

[Lord Wud]

jabzor, on Jun 17 2008, 01:35 PM, said:

mirrorshades, on Jun 17 2008, 10:42 AM, said:

DecaffeinatID ?

/me likes

me too.

[Irongeek]

Did anyone try it?

[SAGA]

Irongeek, on Jun 18 2008, 09:48 PM, said:

Did anyone try it?

Nice...Please include a log file to track the history.....

[jabzor]

Few comments, don't take anything personal, mostly cosmetic concerns as I don't want to quickly bloat what is supposed to be a very lite ids:

• The systray icon looks kinda crap at 16x16 pixels on-top of the xp classic grey in the taskbar - I can live with it
  
• The systray menu might need some tweaking,
  current;
  'Ver 0.01' <- does nothing
  'Exit' <- close the program (doesn't work for me)
  'About' <- opens the website
  
  proposed;
  'Decaf 0.0.1..' <- in-program about box that has basic about info and a homepage link in it
  'Monitor' <- sub-menu with checkbox options of what to monitor; 'ARP Watch', 'Gateway Watch', 'Windows Firewall-log', 'Windows Security Event-log', etc
  'View Logs' <- in BOLD + functional default single-click action - added in 0.05a, /c start idslog.txt, or display it internally
  'Update' <- opens the website with version info included in link, /c start hxxp://www.irongeek.com/i.php?page=security/decaffeinatid-simple-ids-arpwatch-for-windows&ver=0.01, compare server-side to newest release
  -- <- separator bar, use one
  'Exit' <- actually close the program - added in ver 0.03 beta
  
  
• As mentioned above, make the single-click tray-icon action to open/view the log-file and the right-click action to open the menu - added in 0.05a
  
• Make the systray hover-text 'DecaffeinatID 0.01..' instead of the name of the exe, or have it display which settings are being monitored. - added the first part in ver 0.03 beta
  
• If the arp-cache clears or is renewed and the same mac/ip pair show up as the last entry for that mac/ip pair, don't display the status window again though you could edit the log prefix with a duplicate/renew or whatnot. I would only display the status window if something is new or something has changed; aka possible spoofing attempts. That, or make this another configurable option under the arp-watch, to display repeat/renewed entries in the status window.
  
• Perhaps a configurable, default-on warning at startup that you are about to wipe the security event logs with an ok/cancel button prior to wiping. If you hit cancel it doesn't wipe and disables the Security Event-log monitoring. That or you change how you monitor security event logs and only monitor entries since the program was started, so you don't need to wipe any logs, which would be preferable.
  
• Save the menu settings as they are enabled/disabled so that they are the default action the next time the program is started. - added in ver 0.03 beta
  
  
• Is it just me, or does the Exit option not actually work? .. you used the same call-variable $exitmenu twice - fixed in ver 0.02 beta

Otherwise it performs rather well for what it was written. Could use more features and more configurability, but it is the first beta so I'd say it is a success either way.

SAGA, on Jun 18 2008, 10:55 AM, said:

Irongeek, on Jun 18 2008, 09:48 PM, said:

Did anyone try it?

Nice...Please include a log file to track the history.....

It's in the original program folder, I did suggest he have a menu option (preferably the default action) to view the logs.


Note: the default autoit tray menu handling is rather limited, you might want to try out the more advanced modern menu lib.

This post has been edited by jabzor: 24 June 2008 - 11:56 PM

[Irongeek]

Ok, some of your suggestions have been implemented. Others will take time or help for other folks. Check out the new version with more settings options:

http://www.irongeek.com/i.php?page=securit...tch-for-windows

[jabzor]

Irongeek, on Jun 18 2008, 06:35 PM, said:

Ok, some of your suggestions have been implemented. Others will take time or help for other folks. Check out the new version with more settings options:

Downloading now. I'll see how easy it is to add the remaining changes, haven't played with autoit too much. :)

If you'd add a simple php wrapper to the ids homepage that parses out the version tag from the about request and compares it to the latest version that would be great.
Run(@ComSpec & ' /c start hxxp://www.irongeek.com/i.php?page=security/decaffeinatid-simple-ids-arpwatch-for-windows^&ver=' &$ver, '', @SW_HIDE)
Where $ver is the autoit ids script version, in this case 0.02 (you hardcoded the script version in the about text instead of declaring an initial variable..).

Here, a preview of the GUI I wrote in;
systray:
 decaf_jab.PNG (6.52K)
Number of downloads: 4
*NOTE* - radio button were replaced with the more aesthetic check-marks.

This post has been edited by jabzor: 24 June 2008 - 11:57 PM

[Irongeek]

Cool. Thanks for the help.

[jabzor]

DecaffeinatID Change Log:

06/26/2008: v0.07 Jabzor did some minor code cleanup and fixed two bugs.
  - concatenation and incrementors are now used
  - non-global variables are now local to their function/loop
  - redundant lines and function calls were removed, increasing overall speed
  - systray icon is once again set in both script and compiled format (broke the script icon in 0.03)
  - gateway info now reloads every time the ARP monitor is called

06/24/2008: v0.06 Jabzor made minor improvements to the GUI.
  - double-clicking the systray icon now opens the log file, right clicking still brings up the menu
  - menu style now emulates windows 2003 classic, which fixes a display issue and looks nicer
  - menu ini icon changed

06/22/2008: v0.05 Irongeek made major improvements to the program speed and a bug fix.
  - monitoring functions are now set off via timers (FAR more responsive, less resource intensive)
  - ini 'sleep' parameter is now milliseconds between timer events, Sleep=1000 is 1 second
  - ARP cache parsing improved and fixed a bug if the word 'invalid' appeared

06/20/2008: v0.04 Jabzor did major rewriting, Irongeek improved the ARP monitor.
  - code cleanup, organization and easier maintainability
  - improved ini layout and invalid ini parsing
  - improved GUI (added systray hover text, menu icons and title, check boxes, edit ini, view log, update, about)
	The ModernMenu UDF by Holger Kotsch is now used for the menu system.
  - ARP monitor is now more efficient

06/19/2008: v0.03 Internal, non-public release.

06/19/2008: v0.02 First public release. Thanks go out to Mirrorshades for helping name this project.

Quote

To Do:
- Irongeek needs to update the homepage to parse out the version id as to tell users if they have the newest version, or they can always just look for themselves
- Document code-changes - see change-log above
- Optional registry entry instead of ini for read-only storage, and/or the ability to specify runtime switches and/or external ini files
- Optional one-time warning about the program wiping your security event logs on startup; until event logs are monitored without wiping
- Monitor for a double-click on the tray icon, launch the default action (open logs) - added in 0.05a.
- Fix the horrible UI lag when monitoring files - timers in 0.04t, possibly eventually create independent child processes / threads / pipes / sockets / forking
- Figure out how to include the avi resource so the /art/ folder isn't needed in the build copy
- Figure out how to easily display the trayicon in both script and exe format.. - fixed in 0.06a.
- Further test so that the program can be run with a corrupted ini file and from a read-only location
- Ensure the context-menu checkbox options properly flag the functions to ignore <- High priority
- Stream-line the existing irongeek functions
- Write some wrapper functions for some of the code that repeats itself a lot (mostly mine)
- Test static vs dynamic arp entries, set option to ignore duplicate (pre-existing) arp entries and arp-renews
- Compile a list of system events to really focus on
- Detect DNS spoofing/poisoning, detect dns-server updates per adapter
- Provide a help file for users explaining settings and such
- Log time-stamp entry every time the program is started (informative, good practice and added bonus - a log is created regardless) <- High priority
- Log/Display list of known arp entries, gateways etc (the initial values) on startup <- High priority
- Test and possibly fix the security event monitor code (If I open eventvwr.msc, right-click clear the event security and go clear it doesn't trigger the monitor)

Some of the changes won't be that hard, like settings the default trayicon action when you click it or the wrapper functions to remove ugly/redundant code.
Other changes however will take time and effort, especially the biggest problem, calling separate applications and then WAITING for them while lagging out the GUI which becomes unresponsive until this has completed.

 decaf_0.03_running.PNG (71.81K)
Number of downloads: 16

Attached File(s)

•  jabdecaffeinatid0.03.zip (483.5K)
  Number of downloads: 8

This post has been edited by jabzor: 26 June 2008 - 04:56 PM

[Irongeek]

Damn, thanks, but I'd like to iron out the slow GUI responses to changes before we post it. I'll take more of a look at the code tomorrow.



By the way, try compiling with the latest beta.

[jabzor]

Pretty sure the slow code-response existed back in the original, it just wasn't as obvious without functional menu items.
(Hit Exit and see how long it can take to stop the application in 0.02, then comment out the function calls in the while/wend loop and hit exit again, everything is instant).
- Set all of the checkboxes to unchecked or edit the ini with all 0s in the monitor entries and the gui is as responsive as any so we'll need to look at the program calls.

Going to require a different tactic than simply batching the run-commands one after each other with a pause inbetween, possibly dedicated fork / thread / pipe /etc some way to offload the gui from the background applications.

The included compile is from the newest stable, I'll try compiling with the latest beta and see if things speed up any.
And ya, don't worry about posting it on your site until things are more smoothed out, if you want to just test the menus and about box uncheck everything and it will run smooth. :)

This post has been edited by jabzor: 19 June 2008 - 10:00 PM

[Irongeek]

We made need a companion process for the GUI. Unfortunately, Autoit3 is inherently single threaded. I'll look at it more tomorrow.

[Irongeek]

I'm looking at the code, should't $monitorgateways be $monitorfirewall? IS $monitorfirewall even used?

Also, why is the file now encoded as UTF16?

Thanks.

[Irongeek]

One last thing, I'm not very up to date on this UFD. Is there a way to tell in code the menu becomes visible? If there is, we could have it stop parsing logs when that happens so it seems more responsive.