SSM free learning mode, app rule making

This is already posted today in SSM free version forum:
But since it looks like almost nobody is reading that forum, I post here too

I have made the rules in SSM like this:

1. First put learning mode on and ran as many apps as I came to think. Also some that often crash to have teached SSM free about drwatson and those things.
Reboot a few times and change between admin and limited user accounts.

2. Edit all made rules to have 'Ask user' default access and while still in learning mode repeat again what is told in step 1. That adds some more check marks in parent/child rights that were not there after step 1.

3. Disable learning mode and put everything to log in Options, 'Log these events'. Do again all that is in step 1, but this time allow only least rights needed to not get asked again in those prompts you get now.
Then just check the log and try to find if any baddies are allowed running that should not. Or if some browser like IE are to be asked always. All the fine tuning.

Questions:

a) Does above make any sense, considering that the machine is assumed to be quite clean?
And if something bad was allowed, tracing them afterwards.

b) And putting all default accesses to 'ask user'?
Or instead should some applications be really allowed as child as default or have parent default right?

 

It makes plenty of sense. Unless a PC is newly formatted and all software is installed offline from known clean copies, there are no guarantees that a system is clean. Although it's unlikely, it's entirely possible for your PC to pick up something unwanted during the time you were in learning mode. If it's connected to the net, always double check. The more you can limit what other processes each process/executable is allowed to parent, the better. Nothing is gained by allowing an application to parent processes they don't need to use. When you think about it, that's one of the main reasons why Windows and Windows software gets exploited so easily and often. Any process can start any other process. Many exploits use one process/application to gain access to another, or to system processes. By limiting what each processes/application is allowed to parent, many potential exploits are prevented. This is especially true of apps like your browser and mail handler. Limiting what these 2 are allowed to do prevents a lot of problems. There are system utilities and executables that most apps don't need to be able to access like your registry editor or regsvr32.exe.

It's not totally necessary to do that with every rule. It depends on just how much control you want over your system. It's as much a personal preference choice as it is a security choice. That said, I did edit each one on my ruleset to "ask" on both default parent and child settings. Windows Explorer is generally used to launch most user apps and system utilities, but I chose not to use a default "allow" setting for either parent or child default setting. Although Windows Explorer is normally what would be used to launch regedit or msconfig, I want to be asked before it does. You could just as easily use the "block for disconnected UI" option to limit when a process can launch another.
The configuration method you described isn't too much different than the one I use, depending on whether you're using the "block process creation" or the "block everything" setting. If you're using the "block everything" setting, you'll want to examine the rules for processes that get launched by several diffent parent processes. These can include printer software, your AV scanner, media player, etc. Examples:
1, Do you want your browser and mail handler to be able to launch your media player?
2, Is your AV scanner integrated into an IM program or a download manager?
Once you get past setting all the child-parent permissions, then you can get into the other settings like choosing which apps to prevent from being terminated (your firewall for one), which apps are allowed to terminate other processes, etc. If you're ambitious, you can start setting access permissions for DLLs, configuring the alert/logging options for individual apps, and editing the settings of the modules to match how much control you want, especially the registry module. The keys and strings can be edited individually if you want.
If you're concerned about making mistakes when tightening the rules or editing the registry module, make a backup copy of your existing ruleset on the options>configs page first. If anything goes wrong, it's easy to get back to where you started from. You could even switch between to different rulesets if you wanted to. You could run a "conventional" ruleset most of the time and work on a very detailed one when you feel like it. As long as you have a functional backup ruleset available, you can experiment all you want.
Rick

 

Many thanks to you Rick for your clear answers.
Also happy to know I am on the right track.

There is an "Allow process suspending or termination" checkbox that controls what to do with that application's childs.
PERSFW.exe has a child right only to PFWADMIN.exe, whose only parent it is.
PERSFW.exe has no parents. So it should be safe from being terminated I think,
though it has no other protection from SSM against that other than denying new unwanted evil
adopting parents.
I guess I could put it's Parent default to "Deny to start" instead of "Ask user",
to be sure that no parents ever for the kerio firewall.
EDIT:
In a SSM tree view, it though shows 'services.exe' as being a parent, so I am not sure if I should make that in a rule too explicitly. I leave now firewall's default right to parents "Ask user" and wait if I get asked someday from services.exe that has it's terminating child right with a '?' mark.

Yes, I already did prevent logging for this pest 'msctf.dll' when "loading the library".
It was a real mystery to me that every time, with so many apps I started,
it wanted to set a windows hook. 2 times.
Now I have again allowed the logging for that devil and instead disabled explorer.exe in ctfmon.exe's settings to have it as a parent.
It disables also msctf.dll to set those windows hooks.

In my case above thing could be indeed something malicious like a keylogger etc.
I have no ms office programs, so it is useless to follow instrunctions such as how to disable Microsoft alternate input etc.
I tried to get answers from wilders readers in this thread if they also get msctf.dll in this thread:
https://www.wilderssecurity.com/showthread.php?t=152011

There is a 'Save as ...' button that i have saved my current state from time to time.
Default saving folder is Windows/System32
I have saved my configs though to kerio program folder where i keep also my kerio config files.
Unlike kerio 2.1.5 there is no load config file button.
I want to load the same config file for both my XP limited and admin accounts.
I don't know how to do that or even if it is possible considering the registry thing etc. too.
Using that 'Merge...' button is not clear to me. Clear first all rules?
Propably I could use the third button, but it means separate config file for different user accounts?
The help file is really too short in this.

Jarmo

 

1 question:
i have SSM free and i got this message in the dialogue

The call to API function "LoadDriver" was successfully intercepted.
NOTE: It is recommended that you create a permanent rule only with the "Application independent" option (see the bottom of this dialog) switched on.
By doing this you will ensure, that any application will not be allowed to install any driver by simply instructing SERVICES.EXE to do that.
This function is normally called by services.exe when the application wants to start a driver and thereby perform any operations with your computer.

Now, i don't see that option, "Application independent". It seems important so i can monitor what uses services.exe. Not blocking everything, but prompting before something does. If i keep setting this -app.. by its parent...- do i need anything else? Do i have to do something so it shows that option, or do i have to go and set that rule? If so, how do i do it?

 

Yours saves to System32 by default? Mine defaulted to My Documents. It doesn't really matter where you put them. I use SSMs own folder and the Usersdata subfolder. I'm not certain if SSM behaves the same on an XP unit as it does on my 98 box. On mine, all user profiles started out using the global.cfg. If it behaves differently on XP, you can instruct SSM to use the global config file on each user account/profile. You might have to make this change from within the users accounts.
http://i138.photobucket.com/albums/q277/herbalist-rick/configfileoptions.gif
I haven't tried the "Merge" option. Not sure what it would do if the rulesets being merged had different settings for the same process. The "save as" button can be used to save all types rulesets, global, user, backup, etc. I don't see why you couldn't use the same ruleset for both limited and administrator accounts if you want to. For that matter, you could save the same ruleset under 2 different names for this purpose. I'd use global-A and global-L for admin and limited accounts respectively. If later on you decide that you want separate rulesets for the two accounts, they'll be already made and in use, which makes the editing much easier. Back when I was building my original rulesets, I used the date to name the config files, usually like this, 20050923 or 20050822b. First one was made on Sept 23, 2005. Second one was the 2nd one made on August 22, 2005. If you use a pattern like this, you'll know at a glance which is the newest. You might consider keeping a text file in with the rulesets with the changes you make listed in it. Makes troubleshooting much easier.
SSM didn't have a learning mode when I built my rulesets (before 2.0) and the parent-child settings behaved differently. With the present versions, when you configure process "A" to be the parent for process "B", the child setting for process "B" is automatically modified to match. On the early versions, pre-2.0 releases, you had to manually edit both rules. Lots of opportunities for mistakes.

No parent process for PERSFW.exe? On mine, it's started by MPREXE.EXE during bootup. I also set Explorer as an allowed parent for both Kerio executables. SSM handles the parent-child settings separate from process termination settings. The free version doesn't have the detailed control over process termination that the paid version does. Instead of setting protection for processes individually, the free version lets you decide which if any process is allowed to terminate other processes. Most apps don't need to be able to terminate another process. On mine, the only apps that have permission to terminate another are the AVs and Process Explorer. Sevral system processes are set to ask, (question mark in the box). The vast majority are blocked from terminating anything.
http://i138.photobucket.com/albums/q277/herbalist-rick/Spec_per.gif
The screenshot above is for PERSFW.exe on my system. The "keep this process in memory" option is the next best thing to termination protection. If something does manage to kill PERSFW.exe, SSM will restart it. On my old box, it takes less than 5 seconds. On most newer boxes, it's much quicker.
While these options don't offer quite as much process protection as the paid version, the difference isn't much. Even if a malicious site or software did manage to take down the firewall, what could it/they do in the few seconds before SSM restarted it, especially when SSM is still in control over all running processes? You won't end up with any "evil parent" processes unless one manages to get in while you're on learning mode or you install something that has one bundled into it.
Rick

 

Many thanks for your informative answers that will, I hope, help also others besides me reading this thread.

I will now start exploring my settings more and change to use a same config file to both my user accounts. If that does not work, i will revert back to one that was saved at the time i used Global.cfg.

I noticed that too. It is a nice feature.
Seemed to work also the other way.

That is only how learning mode did not put any parent to persfw.exe. I never used 'Trust all" right click option when first starting SSM. Maybe I should have had, but it is tighter this way.
The change from 2.0.8.582 to 583 includes a parent child tree view in SSM Process monitor tab. Looks same as in Sysinternals's Process Explorer. Allows also to terminate programs same as that program.
Who knows, maybe kerio service and services.exe, its parent, start before SSM and that is why learning mode never made that parent child relationship. kerio 2.1.5 splash screen will always show before i have time to log into my user accounts after reboot. Thanks also for the keep in memory tip, though kerio has been very stable with me and never has stopped, not even the GUI icon. I use a cable modem internet connection with no router, so I need to do and also trust much my firewall and also keeping XP patched.

I changed my firewall from Sygate 5.5 to kerio. Not cause it was not stable. It really was stable. Not also totally cause of that loopback address local proxy thing with Sygate. It was, kerio offered me more control in packet filtering but if I even once, as you said Rick, I would have seen kerio service lost, I never would have looked back.
I once saw when i tried Sygate 5.6, that beta .... Avast antivirus's network shield warned me of having found a network attack, when it was late starting after a reboot.
That was it, Sygate 5.6 was a beta to me, never released as a pro version. So the end of SPF development and a bad apple released as a free beta testing one
It must sure be your Win 98 system, if you experience shutdowns of kerio 2.1.5?

Jarmo

 

On a friends XP unit, persfw.exe has services.exe as its parent. SSM and services.exe are started by winlogon.exe. Your screenshot wasn't up the page far enough to show it. Forgot to check the advanced properties screen for Kerio when I was there.
I've never had a problem with Kerio crashing or failing either. I trust it to dependably control traffic, but I won't trust it or any other single program to stand up against a sustained attack. Malicious code designed to attack security-ware is getting more common all the time. Although I'm not aware of any specific attacks that can terminate Kerio 2.1.5 from the internet as long as the user has a decent password set, I work on the assumption that malicious code does exist that can attack it.
All software is vulnerable to something. There is no completely "bullet-proof" code, at least not for Windows and especially not security software. I start with the assumption that an exploit or successful attack exists for everything I use. Not including hardware like routers, the firewall is first in line against attacks from the internet. For an attack to be successful, the firewall either has to be bypassed, penetrated or killed. The "Keep process in memory" option is basically a first response that assumes that the firewall would be killed, and restarts it should it happen.
Rick

 

Would someone explain or give a link that is easily understandable about this parent/child/daughter stuff? I haven't the vaguest idea what all that means. It looks to me, at a surface glance, as something that would appeal only to anal retentive personality types. I dont' mean that in any derogatory sense...just descriptive. I haven't run across these terms when using PG but I have with Kaspersky's PAD and I don't understand any of it. My reaction to such picky stuff (same thing with many software firewalls...too much ultra picky stuff) would be to just get BoClean and forget any of this type of security products except for PG which is not difficult to understand or use. Cyberhawk would be a possibility but they have a poor privacy policy and no ability to have any control. I guess I want something inbetween Cyberhawk..no personal control and high secretivness about how Cyberhawk works and something like SSM or Kaspersky's ProActive Defense. PG is inbetween but most of us using it are constantly wondering now if it is dying a slow death...I wish Wayne would just kill it if that is the case instead of letting it die painfully and allowing us users to be in uncertainty about its future.

 

Thank you. I understand Parent/child now ...at least somewhat. What's "daughter"? I don't know if SSM uses that but KAV ProActive Defense does and their explanation in Help is not too clear to me. Since there is a "daughter" (at least for PAD) is there is "son" also? Parent/child seems straightforward now that you have given me an example...but "daughter" maybe "son" in addition to "child"...getting confusing and complicated now.

I tried SSM some time ago and was confronted with what seemed to be six zillion popups... which is what ProActive Defense is like now in the Service Pack edition which I have (and will be officially released on Monday). I suppose I should try SSM again to see what is new and maybe improved from when I tried it before.

One thing I really like about PG (that others have actually complained about) is its GUI. I have aging eyes plus always have been extremely nearsighted and now have cataracts (but not quite ready for removal but they are interfering with my sight some...not enough the doctors say to get insurance to pay for removal...evidently one has to be almost blind from them before insurance will pay)! All this to say that PG's GUI is in a nice size font for me and pops up the messages in the middle of the screen where they are easiest to read. I don't recall what SSM's GUI was like but with KAV's PAD the popups are small font and down in the right corner of the screen and hard to read. The full screen window of the protected processes and where you make changes uses very small font and I can read it but there is a very long list of processes and I need to adjust each one! My eyes would be burning and stinging after just looking at one of those. PG's font though for say the Protection tab is a very readable Verdana in a nice size not too small or too large. So, I have been very thankful that PG has not "improved" its older GUI by getting one that is suitable for young folks but not for us aging folks with aging eye problems. As I said, I should install SSM again and see what its GUI and everything else is like now.

edit: after just reading this thread, I don't think I want to install SSM! I'll take PG with all its warts as it has never caused a BSOD. https://www.wilderssecurity.com/showthread.php?t=153949

 

The simplest way to explain parent-child relationships is like this.
The process that is starting another is that processes parent. The process being started is the child. Never heard of daughter. If you look at the lower section of the screenshot Jarmo P posted of part of his process tree (the display that shows all that is running and what parented each process) where you see "C:\Windows\explorer.exe" and 6 processes listed below it, starting with C:\PROGRA~1\ALWILS~1\Avast4\ashDisp.exe, those 6 are child processes of explorer.exe.
When there is no rule set or the particular dependency isn't set, SSM will prompt the user. If you're seeing a lot of prompts, it usually means that your ruleset isn't finished. Unfortunately, the tighter you try to control your system, the more prompts you see. When you allow a process to be launched by any other process, you'll be asked once. When you are specifying each allowed parent, you'll be prompted every time something new tries to launch that process. XP has a lot of executables, some of which aren't used that often. It takes a while to get everything covered. You don't have to do it all at once, even if you're specifying every allowed parent, hook, driver, etc. You can always uncheck the "start automatically" option and manually start SSM when you feel up to working with it, and either shut it off or disable the application rules when you don't.
Regarding SSM and BSODs, there are several factors that contribute to that kind of problem, some of which are not the fault of any one piece of software. The hardest ones to fix are ones that are caused by security apps hooking the kernel. More and more security apps set kernel hooks. The problem is the number of hooks, not the hooks themselves. In many of the cases where BSODs are caused by HIPS software, the real cause is more than one application trying to perform the same function. You can look around at the different threads and see users running a firewall suite with a HIPS component AND a separate HIPS program or 2 separate HIPS programs. 2 HIPS programs, each wanting to hook at the lowest possible level in the system. They can't both have the "final say" in the matter. The vendors for many of the HIPS programs have and are trying to keep them from conflicting, but with more and more apps being designed to set kernel hooks, users are putting them in a very bad position. I'm not saying that you're doing this specifically. I don't know what you're running, but I see in several threads users running more than one HIPS. Most users know that they shouldn't run more than one resident AV or firewall because they can conflict. This applies just as much with HIPS if not more so. The last thing any PC needs is 2 apps conflicting at kernel level. Instead of asking the vendors of HIPS "A" to fix its conflicting with HIPS "B", stop running 2 HIPS. One is sufficient. Users need to be more careful choosing their security-ware and avoid duplicating coverage.
Rick

 

Thank you. That was educational. Currently, I'm running ProcessGuard and KAV and KAV's Proactive Defense was complimenting PG as PG has no registry protection and in other areas where they might overlap there was very little of that. But that was before the Service Pack release which became official a few hours ago. This version of KAV 2006 really beefs up ProActive Defense and I was seeing a lot of conflicts between it and PG. Thus, I can appreciate your point about not running two HIPS. I turned off ProActive Defense (it's the one with daughter processes). SSM still seems too complicated to me. It is probably more complicated than KAV's Proactive Defense and I no longer like it with the numerous popups.

 

It's not always sufficient just to shut off one of the conflicting apps. Just because something is disabled doesn't mean that the hooks it sets aren't still there. Ideally, a user shouldn't install security apps with overlapping functions. Easier said than done, I know, especially when the trend is towards "do it all" suites. It doesn't help when the vendors of the suites don't make it clear whether they're hooking the kernel or not, so a user doesn't always know whether that suite will clash with their HIPS or not. The prblem is being made worse by the rate HIPS apps are being developed. When Vendor "A" fixes the conflict their software has with vendor "B"s version 1, it doesn't mean that the problem won't be back when vendor "B" upgrades to version 2. If either one auto-updates, conflicts can appear at any time with no warning. There is no reason for a user to run more than one HIPS or security program that controls running processes and their behavior unless you don't trust one of them to do the job. I see instances where users have both conventional HIPS and PrevX for example. On paper it's a good idea, but in reality you have 2 separate apps that can easily conflict with each other. Both want control over all that runs, including each other. If one does something the other doesn't want to permit, will they clash? Sooner or later, they probably will. People, choose the one you trust and the one that matches your needs and remove the other one.
SSM can be a bit intimidating, but it doesn't have to be. You don't have to get that detailed with your rules to the point of setting parent-child permissions, drivers, etc. You can leave it in the "block process creation" mode and limit your rules to what processes you want to allow. You can run a basic ruleset made with the learning mode most of the time and load a more detailed one when you feel up to working with it. Either way, SSM is pretty much targeted at users who know their system and how they work. It's a bad choice for the casual user and isn't good for those whose systems are constantly changing, always installing or removing something.
Rick