HIPS Rulesets

Is there a source for downloadable rulesets for HIPS such as DefenseWall, GesWall, or Malware Defender? This would be a big help for noobies to use a default-deny security model.

I guess the existense of a source for rulesets depends on a database of hashes (hash such as MD5, or CRC32), which would match up with the hashes of the current system's files/programs.

Alternatively, imagine Malware Defender with a hypothetical subscription to Secunia for 1) applications whitelist 2) operating system components whitelist 3) and custom rulesets for applications and OS components with security vulnerabilities.

Adblock Plus has a rules subscription, so why cant a HIPS? So you might have 500,000 windows system file hashes. That's nothing! Hash matching would be pretty speedy considering you would only have so many hashes per filename, and then a certain rule applied according to the corresponding hash match.

 

Hashes for Windows system files would be just the beginning. Such a database would have to include the files for every version of Windows that was going to be supported, plus it would have to be updated constantly. Security app vendors don't get access to the updates any sooner than the rest of us. Maintaining this database would be a big job. It would also make the HIPS dependent on that database, the vendors servers, and a secure internet connection to them. All of those then become part of the users attack surface. In addition to hashes, most HIPS also use the file path in the rules. Then there's still all the user applications and all of the versions of those files, with updates. Some HIPS that are integrated into security suites use this model to varying degrees.

IMO, this defeats many of the basic concept behind HIPS in the first place, starting with not being dependent on a constantly updated blacklist, or in this scenario, an equally large whitelist. Maintaining this whitelist would add substantially to the vendors support expenses, which would most likely be passed back to the user in the form of a subscription. HIPS were originally designed to eliminate many of the problems that exist in conventional AVs, starting with detections that are never complete and never completely up to date. These issues would affect whitelists just as much. Because of the nature of HIPS and the default-deny policy itself, what should the HIPS do when an update for a core executable like explorer.exe or winlogon.exe hasn't been added to the whitelist? Blocking it would lock up your system. Allowing it makes you vulnerable to malware disguised as system files, a technique that's been employed for a long time.

The basic concept behind default-deny is that everything is blocked except for those items the user chooses to allow. HIPS were intended to empower the user by letting them choose what they want to allow. Making the HIPS dependent on a database for those decisions effectively gives that responsibility back to the vendor.

Maintaining those subscriptions would be a big job and would be subject to the same problems, being complete and completely up to date. It could get quite complicated on any system that isn't using default settings. Example, a lot of users disable some of the unnecessary services that run by default. Quite often Windows updates turn those services back on. Most HIPS monitor system services. Should the HIPS allow the services to be turned back on or enforce the users choice and keep them disabled?

IMO, the type of arrangement you describe has one major issue at its core. Your PC will have 2 system administrators, you and the HIPS vendor, each with their own ideas and no real communication between the two. The vendors primary concern will be making default rules that work for all users, or as many as possible. In the process, they'll allow many things that a default-deny advocate will not, just to keep from breaking apps and system components. The defaullt rules for internet firewalls have always had this same problem. To keep from breaking things, the default rules are very permissive and need to be tightened up in order to make the firewall as effective as it can be. With rules for applications and their activities, this would be much worse.

If you're serious about implementing a default-deny policy, you will have to get to know your system well enough to decide what needs to be allowed and what doesn't in addition to the user apps that you want to allow or block. If you know that your system is clean, you can use the learning mode if the HIPS you want has one. You can also keep your existing security in place, start the HIPS manually, work on its configuration when you feel like it, and make a gradual transition. You could also set up a virtual system for learning and experimenting with HIPS. In the end, HIPS software and the default-deny policy in general make what is and is not allowed on your system your decision and your responsibility. You'll have to know your system well enough to make those decisions.

 

If you want such things, try Comodo and other Firewalls/HIPSes.

 

If your everyday account is either a standard account, or an admin account with UAC enabled, I recommend using path rules instead of hash rules.

Some threads you may be interested in:
Anyone running AppLocker?
Using Comodo Internet Security as an anti-executable
PGS - Pretty Good Security

 

path rules is tighter

 

Path rules are far easier to manage than hash rules, but I wouldn't say necessarily tighter. One has to ensure there are no subdirectories writable by non-administartors when using path rules. MrBrian has this covered in one or more of these threads somewhere BTW, I agree with MrBrian that given the choice between hash or path rules, I'd recommend path. Too much maintenance would be involved with hash rules.

EDIT:

BTW, I don't know about 3rd-party HIPS, but no whitelist is needed for file hash rules with AppLocker; The hash values for any and all files scanned is system generated. However, any files that change due to program updates will require a re-scan for a new hash value, as obviously the new file's hash will differ from the previous one. This is why a ruleset built completely upon hash values would require rather high maintenance

 

I have learned a lot in reading your posts, so I would like to precede that you have my admiration. I would like to add that I never use automatic updating, and I am running XP SP2, and I don't use any security software, except for the NoScript browser extension. I haven't had malware since 1998, when it was given to me on a cd, and I removed it before it delivered payload without warning from any security software. I can't say that about my clients. They don't focus on the computer... they focus on other things, quite possibly more important!

edit: I have used Kerio 2.1.5, so I could know about applications-I-use that want to phone home.

Okay, back to the topic. If an update altered a core file, then it could be possible that the HIPS would know, because the HIPS allowed the update to happen in the first place. If after the update, no hash match was found for the updated file, then the HIPS would optionally ask you if you want to continue the same ruleset for that particular system file.

I guess you mean that the HIPS would not be keeping track of the actions of updaters/installers. So what would you like the action to be in this case? How many core system files are there? Not that many. Let's make exceptions to the default-deny, and assume that the files were altered by the updaters/installers, which are allowed to make changes. Since we don't have a hash match, let's continue with the previous ruleset for these core system files, shall we? You say that a virus could have changed them? Maybe the web browser did it? No, because the web browser does not have that privilege. Maybe some rogue executable? Most possibly, it was the user who overrode the HIPS, when the HIPS specifcally told them the file is a rogue executable and should not be trusted (it is not on hash list from Secunia!).

Secunia does it! Hats to them! Now they can make a little something for their effective work.

I have confidence that you can solve the rest of the problems you presented, and introduce a level of security that would put a serious dent in the income generation of the IT industry. I have to get back to work.

 

Sure, if I could just get to the screen that looks just like Malware Defender, or Kerio Personal Firewall, so that I can actually know what is going on inside.

 

There are already solutions to make the default deny friendly for noobies

Comodo already include rules, every known program for Comodo is automatically allowed (you don't see any popup), It has the local whitelist, and the Cloud whitelist.

If you want a user friendly HIPS try COMODO D+ and check the setting "create rule for safe applications", then if you want it more noisy, you can get it changing the settings.

Take a look to this HIPS test, http://www.anti-malware.ru/firewall_test_outbound_protection_2011
You can use google web translator to read it in your own language.

 

Is this not enough detailed??
http://help.comodo.com/topic-72-1-206-1986-Computer-Security-Policy.html

http://help.comodo.com/topic-72-1-206-2032-Defense -Rules.html
http://help.comodo.com/topic-72-1-206-2033-Predefined-Policies.html
http://help.comodo.com/topic-72-1-206-2037-Protected-Registry-Keys.html
http://help.comodo.com/topic-72-1-206-2038-Protected-COM-Interfaces.html
http://help.comodo.com/topic-72-1-206-2036-Protected-Files-and-Folders.html
...

 

Same here, including Kerio 2.1.5. Automatic updating is incompatible with a true default-deny arrangement. For auto-updating to work, the update installers, which themselves are executables that will be unknown to the HIPS, (unless the HIPS has access to a database that would include those updates), along with their installers and all of the executables that they contain or use. If the HIPS does use or have access to such a database, the executable that launches the installers for the updates would have to be made an exception to the default-deny policy and be allowed to launch or parent new processes. This opens the door for exploits that target that application or system component. A while back, I experimented with auto-updating AntiVir/Avira on a PC defended with System Safety Monitor. I don't have the resulting rulesets handy at the moment, but I remember I had to give 2 AntiVir processes permission to launch any unknown process. I had to configure SSM to ignore hash changes for all of AntiVir's executables and give a couple of those executables permission to terminate other processes and to shut down/restart the OS. It all worked fine for a while, until AntiVir added an anti-rootkit module to one of the updates. It conflicted with SSM. The next morning, there sat a BSOD.

Somewhere around the same time, I saw an article regarding malware that exploited the way an AV would parse the file. When the AV would attempt to analyze the file, the malicious code ran with all of the permissions usually given to AV components. Instead of protecting the system, the AV becomes an exploitable part of the attack surface. I don't remember if this was all theoretical or if they've actually created such malware. Too often, something that is theory one day becomes a reality shortly afterwards. Whenever I ran across articles like that one, I'd examine my default and test security setups to see if they were able to mitigate such an attack. The SSM rules that were created to accommodate auto-updating would have prevented it from defeating such an attack. From that time onwards, I've made all updating an administrator only task, all to be done manually. While most HIPS have a learning mode and/or an install mode, IMO they allow too much.

A lot of it comes down to personal preference, how often you modify or update your system, and how much of the decision process you want to leave to the vendors discretion. The extent that you want to apply a default-deny policy makes a big difference. Default-deny can be as simple as an application whitelist or it can be expanded so that each allowed process has its own whitelist of allowed child processes.

Default-deny can be applied to internet access and/or web content as well. For internet access, it can be as simple as a list of apps that are allowed internet access or as detailed as specifying what IPs each app can connect to, what protocols and ports each can use, or even the time of day the individual apps are allowed to connect out. If you wanted to, you could do the same with web content and have global blocking of Flash, Java, specific javascripts, etc with separate site whitelists for each.

 

guest: Wow. Ok.
noone_particular: Yeah, yeah, you have to know how to drive the car, or you are going to crash. Some people need auto-pilot.