term "default deny"

Hi,
i just bother with this term and try to learn how to harden my Windows XP system (Win 7 64bit soon) with that policy. I guess that "default deny" should start with the UAC on highest setting for Windows. In my case, i'm using CIS with highest security settings too. Is there anything more i can do ? Does Windows as OS provide mor possibilities ?

Thanks for your thoughts!

 

You could make use of SRP (Software Restriction Policies), and instead of a default-deny, a default-allow, as in allow what you wish and everything else gets denied, which is a better approach to blacklisting.

If you don't have a Windows XP Pro (which I believe is only version with Group Policy), you could search the forum for Pretty Good Security by Sully, which allows users without the expensive Windows versions to make use of SRP.

NSA a nice article, IMO, about using the whitelisting approach with SRP: http://www.nsa.gov/ia/_files/os/win2k/Application_Whitelisting_Using_SRP.pdf

Always useful to take a look at.

 

Default-deny is a policy under which anything that is not pre-approved or allowed will be blocked or denied. Under default-deny, anything that is not whitelisted is for all purposes blacklisted. It's strength is that it's not necessary to identify everything that you'd want to blacklist, which eliminates the problem of missed detections. It's weakness is that the user needs to specify what is to be allowed. Default-deny makes a system very resistant to change. It can and probably will interfere with auto-updating.

Default-deny is most commonly applied to processes and executables but is not limited to just these. Depending on the users needs and skills, default-deny can be applied to parent-child settings (what other apps/processes each application is allowed to start or be started by) and many system functions like loading drivers. This requires an in-depth knowledge of your system and the needs of the software installed on it. Default-deny can also be applied to internet access and web content. The standard rule based firewall operates on the default-deny principle. It will block all traffic that you don't specifically allow.

Both SRP and Sully's Pretty Good Security can apply default-deny to processes and executables. I don't know how well these control executables that are actual operating system components. Sully could answer those questions better than I can. Classic HIPS can also be configured to implement a default-deny policy. Unlike SRP, HIPS can allow the user to whitelist the parent-child settings for each executable along with restricting many other activities that they can perform. This can give you much tighter control over your system but will require a lot more knowledge and user input to implement.

Browser add-ons like NoScript and apps like Proxomitron can apply default-deny to web content. Malicious and undesired content can be filtered out before it reaches the browser. Depending on the choice and configuration, these can remove javascript, Java, Flash, media, ads, and more.

Depending on how far you want to go and what tools you decide to use, default-deny can provide anything from basic security to nearly bulletproof. With the right choices of tools, it can be implemented on any version of most any operating system. Implementing default-deny begins with determining what you actually need.

 

That's how I understand it, too

Sure beats the alternative, that is to blacklist that which is not desired, or to blacklist selected directories.

In particular if hash rules are used, then yes, problems will ensue, as hash rules would need to be updated when hash ruled files are updated. I like Applocker's Publisher rules, whenever possible, because one can specify the current Publisher version or above.

 

Correct me if I'm wrong, but the default approach of SRP is blacklisting, as in you need to specify what you want to block, say *.bat, *.exe, etc.

It is possible to do the whitelist approach, though.

What you mention is the approach that AppLocker (Windows 7) takes. Everything not strictly allowed is blocked. By default only what's in %PROGRAMFILES% and %WINDIR% is allowed; everything else blocked.

I've never used SRP deeply, because the change from SRP to AppLocker was quite fast. But, that's how I believe it worked/works.

Again, the article from NSA explains the whitelisting approach for SRP.

 

Using Comodo Internet Security as an anti-executable. The directions there are for v4.x.

 

Many thanks for your great explanations ! If i got it right, starting with the OS, only Win XP Pro provides SRP, so i'll have a look into "Pretty Good Security by Sully". Additionally CIS seems to work "default deny" in "paranoid mode" too. I'll check MrBrians link to this thread too.

 

This always seems to be a 'not so easy' concept to get. I mean, for anyone who doesn't know it, it seems that way.

First lets establish some basics (bear with me, others will find this and appreciate it later )

There are typically two types of users on a computer: a User and an Administrator.

Users typically can read and execute things anywhere, but can only create or modify in limited areas.

Administrators typically can read, execute, create or modify anything, anywhere.

In terms of security, the Administrator account is the least secure because there are no limitations. A user logged in as the Administrator, who then somehow gets a virus/trojan/malware to run, essentially allows the 'bug' access to everything because they are the Admin.

A User account on the other hand is more restrictive to a 'bug'. The 'bug' might be able to start (execute), but since the account is only a User account, can't do much harm to the system because of the restrictions.

When people talk about a Default-Deny policy, they generally refer to it in terms of a User account. In a User account, only an Admin can install an application to specific places, like Program Files or Windows. Since a User can't install programs there, it is ASSUMED that the Administrator knows what they are doing, and when they install a program, the User can trust it. Thus in a typical Default Deny scheme, you would always TRUST the programs that are in places where the Administrator has access to.

The Deny part of the policy is actually denying any application anywhere else but those areas that the Administrator has access to. The thought process is that if the Administrator installed it to c:\Program Files, it must be OK. If the program lives in a place the User can create or modify, it might not be so kosher because the User is only a User, not an Admin. Thus Users are less trusted and not as smart as Admins, and should not be trusted - by default.

Bearing this in mind then, a Default Deny policy would simply deny any program that does not live in an area which is off-limits to a User. In order for a program to start which lives in a place that a User has create/modify rights to, an EXCEPTION or EXEMPTION would have to be made. As luck would have it, only an Administrator can make such an execption, so unless an Admin approves it, nothing can start.

Some forms of Default Deny would be more strict, where nothing is allowed to start EXCEPT those items needed by the Operating System itself. Then an Admin would have to open each exception. This is a very tight scheme, because only those explicitly allowed applications can run.

The Default Deny policy might also be referred to as a White List. The White List is a list of APPROVED PROGRAMS that can run. If programs are not on the White List, then they are denied -- by default, thus you have Default Deny.

The other method of doing things is generally done from an Administrator account. It uses a Black List approach. Because the Administrator has full access to pretty much everything, he already can run what he chooses. In this case you create a list of programs which are "Black Flagged" to either not be allowed to run, or to be restricted or something like that. Any program found on this Black List will then be dealt with accordingly.

When using a Default Deny policy, there is no real doubt that it is very effective against exploits. The exploit would "somehow" need to have Administrator rights to be able to install itself to a place where it could be on the White List. That is hard to do, usually. Sometimes, if your system changes states a lot, it can be quite frustrating to keep the White List up to date. For many people though, they do the same thing over and over. Once they build thier White List up, everything they normally use is allowed, and everything else is Denied, by Default.

Hope that helps. I know Mr Google will show a lot of people this, because there are a LOT of key words that will be hit upon.

Sul.

 

Thank you too Sully for your effort!

 

Yes and no. Microsoft decided that their "cheapest" Windows version ought not to have Group Policy Editor, where, among other stuff, one can apply Software Restriction Policies. So, in theory, yes, SRP are only available for Windows XP Pro and more expensive versions of Windows Vista and Windows 7 (Ultimate, not
sure if some minor version also has it.).

But, in practice, every SRP is written to the Windows registry, so there would be two ways for one to apply SRPs to the "cheapest" Windows versions, which would be to "hack" directly into the Registry, which could be troubles for most users, or, courtesy of Sully, make use of PGS which is an editor for the "poor", if I can put it that way.

By the way, and I hope I haven't confused you, but when I meant a default-deny or default-allow, I meant it in a way that:

* default-deny - One needs, by default, to tell SRP what to block. The default behavior of SRP.
* default-allow - One needs, by default, to tell SRP what to allow (this would be the whitelisting approach, which would need to be set. The PDF file I linked to has pretty great info on that.) AppLocker, which is present in Windows 7, follows the Whitelist approach. One decides what wants to allow, and everything else is blocked from executing.

I just chose the wrong wording. I hope that now it is clarified, if somehow you found it odd. lol

 

Well, I don't know m00nbl00d, not to argue, but I don't see SRP that way. It's more like telling it what to allow. Just for kicks I enabled SRP, set security level to disallowed, then took a screen cap of the additional rules where you can see what is allowed by default, the %systemroot% and %programfiles% directories. Anything else the user wants to allow would need to be added to this whitelist. IOW, what to allow, rather than deny. Maybe I'm interpreting this wrong, so other opinions would be appreciated, but that's how I see SRP's Default deny approach.

As for AppLocker, the user can choose a whitelist approach or blacklist approach, although MS recommends the whitelist or whitelist with exceptions approach.

 

Yes, that is correct. But, unlike AppLocker, SRP actually has a list of what is blacklisted (*.exe, *.pif, *.cmd, *.bat, etc); and in case some other dangerous executable type isn't blacklist, then you need to manually blacklist it.

*Again*, I reiterated that I never used SRP much, so that's how I believe it works.
I just started a virtual machine, and what I mentioned happens. Those type of executable files I mentioned are part of the blacklist of executables that shouldn't run, unless in %PROGRAMFILES% and %WINDIR%. (Here they are blacklisted to block them.)

With AppLocker, scripts and executables are allowed for %PROGRAMFILES% and %WINDIR%, everything else simply blocked (Here, they are blacklisted, because there are no rules to allow them. No blacklist needed to block them). So, in my way of seeing it, this is a true whitelist approach, unlike SRP.

As I said, sometimes, what I want to mean gets lost in my translation. lol

 

Like many terms used in security discussions, Default-Deny has different shades of meaning with different users.

For example, a Firewall is often cited as a Default-Deny product, but the Firewall can be configured differently for various situations. Here, my Firewall alerts the first time an application attempts to connect out, and I set a Default-Permit rule for the application so that I won't be bothered in the future.



Another example of a Default-Permit rule, as here with DHCP. I don't need to be alerted about this:



However, for filtering the daily inbound junk that attempts to probe, I want a Default-Deny rule in place. From my log showing the rule, Deny all other protocols. It works by Default and I see no alerts/prompts:



So, the Firewall can use alerts, and both Default-Deny and Default-Permit rules.

Here is ProcessGuard in action with a real drive-by download exploit:



In my view, this is really not Default-Deny because the user has the option to make a decision

On the other hand, SRP when set up properly will block the executable with no option to permit, as here with the same exploit:



If you have computer with several users, which of the above would you want to protect against the drive-by download?

I wouldn't want the user to have to make a decison. The users should understand that if such an alert pops up, something is attempting to execute which has no business doing so. Period.

Now, a single knowledgeable user on a computer might not have any difficulty with alerts that require a decison, as in most HIPS products, so I'm referring to my own case where I set up a security system in a home. Only the parents can grant permission to install anything, so a true Default-Deny configuration is ideal, and only those programs/executables already installed can run.

Another thing mentioned is at what point in a security strategy does the Deny come? Some have shown that in a User account the malware might execute but not be allowed to write to the system. To me, the Deny somes one step too late in this case. I would prefer the SRP way as above.

All of this is to show that in using terms, one needs to specify exactly what is meant!

----
rich

 

IMHO it is most helpful to think differently about SRP than most are used to. A more simplistic approach maybe.

Those two default rules to allow anything in %windir% and %programfiles% can be easily construed to say:

Any other directory is not to be considered trusted. Default rules cannot possibly know what other directories might be created that are also deemed as safe, so therefore only that will most likely exist will be covered.

This is Default Deny - to deny anything not in c:\windows or c:\program files.

Don't confuse the list of Executable File Types with a White or Black List - they are most certainly NOT the same.

A default install of windows will include a certain number of registered file types that are deemed as "executables". As other programs are installed, there may be other types of files that are deemed "executables". It is also possible that certain file types that M$ did not deem worthy of being included as an "executable" might be to the user.

Either way, the Executable File Type List in no way determines what is Blocked or Allowed (Black or White). It only serves to DEFINE what types of files should be monitored/checked. It is perhaps a common misconception, because it IS a list. Perhaps, and I don't know this to be fact, only guessing, the list of file types is used to keep resources down. If every file had to be checked, it might be much slower. It is likely the same situation as including dlls. If you have to check everything, it takes time and power.

Sul.

 

Right, it depends on the perspective the user is looking at it. You and Sully have explained things very nicely with in-depth, granular examples This reminds me when working with the Telcos on 4w circuit issues, and I tell them we're 5 dB low on the office tx, but they sometimes get confused and think I mean remote site tx. This happens because they are looking at it from the field perspective whereas I work at the head office, so I look at it - and try to explain things that way - from that perspective. It makes troubleshooting, well, troublesome at time

This makes complete sense to me. This is a good discussion to have because I simply want to know for sure how default-deny should be defined, as I've never been 100% on if I've been interpreting it correctly.

 

You'd be both wrong, I'm afraid.

Remove, for example, *.bat from the Executable File Type List. First, you shall get a warning saying that anything related to *.bat will have unrestricted permissions. Then, well, just for the kicks, create a batch file to delete files/folder from within the context of the limited user; create files; execute files. Permissions granted.

The same way, if you wish to block *.js files from being opened, you need to add it to the blacklist in Executable File Type List.

Note: I don't know whether or not *.js is already being blacklisted. It's just an example.

Resuming: If you delete any of the types blocked in Executable File Type List, then users will be able to execute them, outside %PROGRAMFILES% and %WINDIR%, as well.

 

I'm not sure that is correct, exactly.

The file type list is used to tell the CreateProcess() method which types of files it should check against any SRP entries. It won't matter to CreateProcess() whether the entry is an Allow, Deny, or Restrict rule. It only matters to CreateProcess() that first and foremost, is this file type in the list or not. If it is not in the list, it (I think) simply drops any further processing of SRP.

If the file type (.bat, .js, .whatever) is found in the list, then CreateProcess() will do the following:

1. deterimine whether if it should globally deny the process creation due to SRP settings - ie. it is not in %windir% or %programfiles% so it is denied, by default

2. if it is not denied by default, is there a rule that states to deny all files of that type (ie *.bat or *.js) OR is there a specific rule to deny that PARTICULAR file (ie. myfile.bat)

I think what you are seeing is that when the .bat extension is in the file type list, when using SRP in Default Deny (white list) in LUA/User account, by default it won't matter what the file name, it will be denied unless it lives in one of the two default directories (or you have your own customized rules for exclusion).

I don't know it works in that exact order or heirarchy, I haven't looked at the MSDN sheets on that for awhile now. But I am pretty certain, no offense, you are incorrect about that.

I won't be disappointed if you prove me wrong, you just might.

Sul.

 

OK. Let's see.

*.bat is part of Executable File Type List, by default.

In a default-deny approach, unless not strictly allowed, then whatever *.bat file is out of %PROGRAMFILES% and %WINDIR% simply won't execute.

Now, let's remove the *.bat from the Executable File Type List. In this scenario, SRP no longer will care for *.bat, hence they will be allowed as well, outside of %PROGRAMFILES% and %WINDIR%. There's still a default-deny, but since *.bat is no longer being monitored by SRP, because it's no longer part of the Executable File Type List, *.bat will be allowed execution.

What does this mean? It is allowed, and simply because it's no longer blacklisted in the Executable File Type List.

Yes, SRP creates a default-deny, as in that it allows whatever is under %PROGRAMFILES% and %WINDIR%; but to deny anything outside these two folders (I'm excluding our own preferences not to allow certain stuff from both the mentioned directories. It's another talking.) the Executable File Type List needs to have a list of file types it needs to monitor, otherwise everything is allowed, and to be honest, there wouldn't be much sense for SRP to exist.

So, while for both %PROGRAMFILES% and %WINDIR% does exist a whitelist approach, for everything else there's nothing but a blacklist approach.

 

@moonblood

SRP can be used as a black-listing tool (as in default-allow) but when members here mention SRP, they usually refer to it based on the assumption/recommendation that one follows this guide:

http://www.mechbgon.com/srp/

Or you can refer to this page for further details:
Default-Deny All Applications Part1

You can add/remove a few 'extensions' in the Executable File Type List but the concept remains as a default-deny in the 1st place....the only difference being you are the master in charge/control of what to be denied and what to be allowed. If and when you choose to remove/exclude something out of that concept, be it extensions or anything else, you are the one responsible for that change since you are the one who "allowed" or "whitelisted" it...not your tool that's being used.

The default-deny concept is in simple terms:
"Nothing is allowed by default unless we define some exceptions to the default rule"

But as we all know it, no security software/methodology is ever bullet-proof or 100% perfect. When the word "nothing" is being used, it's basically assumed as "as little as nothing as possible".

On the other hand, in my understanding at the very least, the default-allow concept in general applies to concepts where almost everything is allowed in (unless blacklisted)...not just a few extensions/executable/actions so-called *missed* by SRP or any other mechanism that uses the default-deny approach/ideology/concept (for e.g. anti-executable or a configured HIPS).

Just to add to the discussion, I personally see a pure firewall or a classical HIPS (which works on the default-deny concept) but that is not yet "configured" (password-protected or configured to auto-deny any change noticed) and rather pops out to you each time it finds something as more of a "default-ask" or "default-alert" or anything that goes along that line. That's how I see it. Others may differ.

 

Nice way of putting that. Lets add to it, I digg this stuff.

Look at the actual methods. When you execute a .bat file, the CreateProcess() method is called. One of its jobs is to, before actually creating the process, examine the SAFER registry keys. I don't know the exact order, but lets assume that to be the most efficient (yeah, we presume the OS tries to be efficient ) the first thing that happens is for CreateProcess() to see if SRP is turned on and enabled. If it is, then it would next be most efficient to see what the settings are for the calling user - is user Admin? Is Admin exempt? I user LUA? Is LUA exempt?

At this point CreateProcess() knows it has to further process the request or not. If it has to process further, it would be most efficient to examine a list of File Types and see if the file that is wishing to create a process exists in this list. If it does not exist, then processing of SRP can stop and CreateProcess() finishes its job and creates the process.

If the file wishing to create a process is included in the File Type list, then CreateProcess() has some logic to perform. (going to generalize here, just go with it )

1. it is not Admin, or it would have been allowed, so must be User.
2. it can't be defualt allow or it would have passed already, must be default deny
3. what rules are set to allow? c:\windows\* and c:\program files\*
4. is this file originating from these two directories?
5. if yes, then allow because the rule states to
6. if not, then it should be denied, by default because no rule makes an exemption

Default Deny, in SRP, means that any file with the same type listed in the File Type list is going to be denied. Admins can be exempt from this or not. Removing the file type from the list means it is no longer cared about and can do whatever. Denying only occurs (to be efficient) on specific types of files.

While we aren't exactly arguing, we are discussing the finer points of whether or not SRP uses a black list in the form of the File Types list. I look at it from how CreateProcess() might step through the logic, and I see it as a list that defines to CreateProcess() what types of files to ignore (improve performance - ignore and move on) or to process (degrade performance while examining SRP). I see the other settings in SRP as what defines the state of SRP. To me, Software Restriction Policies is able to define a system wide state - allow, deny or restrict everything or nothing.

I tend to say that if the SRP default setting is to deny, then there is no list to deny, everything is denied. The File Type List is then an extension of this, to give some granularity to CreateProcess() so that it does not have to check everything, but only a shorter list. The inclusion of the two default rules of c:\windows and c:\program files offsets the global denials by creating a White List.

I better understand why you say what you do. You see it as a list of things that effect whether things are denied or not. In the Default Deny state, the inclusion of those file types means they will be denied - easily seen as a Black List of items.

Thoughts?

Sul.

 

Yes, I'm aware of that.

I haven't said otherwise.

Yes, you're right. But, that's not really what is being discussed.

Correct.

Also correct.

Correct.

Everything is say if all right, but that's not what I'm discussing.

Every type in Executable File Type List, is there to be blacklisted. If one removes any of those file types, then they become allowed, as in allowed to execute, which beats the purpose of SRP. This means what? They were being blacklisted in the first place. Which is what makes sense, because until they are removed from Executable File Type List, they are blocked.

It's not in discussion if one should or can or will remove anything from Executable File Type List.

 

Always a pleasure discussing certain stuff with you Sully, by the way.

I try to imagine that, but somehow it doesn't seem to have a place in ratiocination. Otherwise, let's see.

You see it as list so that CreateProcess() knows what files to ignore, to improve performance. But, how can it be ignoring it? I don't see it like that, because if *.bat or whatever gets blocked, because they're in the list, then it means they aren't being ignored; the list is specifically telling that they shouldn't be ignored. If we remove any of those file types from the list, then yes, they become ignored, and will be allowed execution.

So, in my own ratiocination, if once removed from the list they are allowed execution, because now this/these type(s) is/are being ignored, then how can
they be ignored if they are in list, meaning they will be blocked? I honestly can't see it from that perspective. It makes no sense. It makes sense to say it's ignored, once they are removed from the list; yes, in this scenario, they are allowed, because they are ignored. Otherwise, they won't be ignored, because they will be blocked.

-Edit-

Source: http://technet.microsoft.com/en-us/library/bb457006.aspx

So, if no file type is listed, no rule will be applied to that file type, as in it will be ignored/allowed. -Edit- The opposite is that if the file type is listed, then that file type will be blocked/not ignored.

 

Perhaps you have to put yourself as the CreateProcess().

I am CreateProcess() "ta da!"

I am working every time something is started (process is created).

Because my boss implemented all these new safety features, I must now check every single file that starts and determine if we have a policy against it.

If someone opens a text file, I must check it. If they open a music file, I must open it. Sheesh! I didn't need this sort of workload.

Oh good, looks like someone talked some sense into the boss. Now he wants me to only check specific types of files. Thats much better. Of the 10,000 files that the User-god might click on, now I only have to check maybe 10% of them, and only if they match up to a predefined list I keep track of. That means I don't have to bother that jerk CPU or his twin brother RAM. Those guys are so hyper, they get bogged down if I request permission to check everything all the time.

lol.

I understand what you mean, and I will admit, it does look that way. I guess I am so used to what is actually happening (or try to) that I see it more of an exclusion than an inclusion. It has to be IMO, or there would be a lot of resource usage checking everything. It makes much more 'programatic' sense to define it this way:

1. we want to restrict everything
2. we can't, it would be too slow
3. ok, then lets only restrict executables - the files use the executables anyway, we don't need the files
4. sounds good - lets make a short list of everything we want to restrict and if it is on the list, we will.. we will. oh, I know, lets also make two lists, a white list of allowed things, and a black list of denied things... then, when an executable file type we want monitor makes a request, we can compare to these lists and decide what we should do.

Or something along those lines lol.

Sul.

 

I agree with that.

My understanding...

1. I want to restrict everything;
2. Not done; everything will be too slow;
3. I narrow it down to executables;
4. I'll specific a list of what I want to restrict - Designated File Types*

*Designated File Types - this will take care of the file types I wish to block execution. Every file type I want to restrict needs to be added here, so that SRP also gets applied to them.

5. Some *.bat file makes a request;
6. Is it in the Designated File Types list?
7. If yes Block execution; If not Allow execution**

** In step 7, if it's blocked, then it means the file type has been associated to one in the Designated File Types, not ignored. If it has been allowed, then it's not part of the Designated File Types, and it was ignored and given permission to execute.

lol

 

How do you see it when you are Admin and use SRP to deny or restrict? File Types need to be in place for .bat files to be processed (white list ?), but yet without a specific rule in place (black list) nothing happens? Because the file type list is used in either default deny or default allow, I always viewed it as not part of the list.

How you look at it does make sense though if I stop thinking like a program and looking at the technical details

Sul.