Check out this new Powershell Cmdlet from Darren Mar-Elia:
We have had the capability with other tools/script - but using PS is new, great stuff!
.
Jakob H. Heidelberg it an IT specialist with focus on security, scripting and the Microsoft world. He's an MCSE:M/S, MCDST, MCTS, MCITP, MCT, CEH & MVP- and an author on www.windowsecurity.com.
Check out this new Powershell Cmdlet from Darren Mar-Elia:
We have had the capability with other tools/script - but using PS is new, great stuff!
.
Posted by Jakob H. Heidelberg at 4:10 PM 0 comments
Labels: Darren Mar-Elia, gpoguy.com, group policy, Powershell
If you have looked into "The onion ring", or just "Tor", you have probably wondered if it would be wise to block access from these anonymous servers (or maybe just the exit nodes). I am not gonna talk about how the encrypted Tor network works, as a great deal of info can be found "out there". Main source should be: www.torproject.org - and perhaps WikiPedia.
As a security guy (or ISA administrator maybe), you ask yourself "why do these people want to be anonymous"? In this case "anonymous" means that "they" don't want targets on the Internet to see the originating IP address (the source). A "target" is typically a web site or some other web service.
The answer? Well, first you gotta ask yourself: "who are they"? And there's really no good answer to that question I guess - who really knows? All we can do is guess, so let me turn these questions around: if I were to try out a hack, or some new exploit, would I do it directly over my personal WAN IP? Or would I try to "hide" my originating IP? If you look at it in that perspective Tor networks are GREAT for hiding out - the whole idea is that it shouldn't be possible to track the communication. What you don't know can hurt you, right? I'm not saying all Tor users are hackers or anything, because they are not, but you have to look at the odds... What do you think? I cant help thinking, that if you hide from someone you have something (bad) to hide - but hey, it could be a Christmas present, right?
Anyway - you have to decide - do I want these people to be able to access my web sites and services or not? I'm not going to decide on your behalf - that's politics!
So, what can we do about it if we want them out? Well, after reading Thomas Shinders Blog entry "HammerOfGod Computer Sets — Block and Log by Country" I got an idea. How about downloading a list of Tor servers, import it into a Computer Set (CS) and make sure that CS is an Exception on all of you Published services? This way hackers out there, behind Tor servers, won't be able to poke around your IIS servers or whatever you have.
So, I started a search for Tor lists - the best thing would probably be to create it yourself dynamically - but that would take programming skills that I unfortunately haven't got. I'm just a scripting kinda guy... The thing is, you would need to have a Tor client installed and from that extract the list once in a while - not possible for me (maybe you can do it easily - please post a "how to" then).
But, then I found a list on Proxy.org - this list it updated regularly - the only thing is, that this list is formatted for easy import on Apache servers, definitely not ISA. But hey, we can change the formatting in a script and then call the "AddComputersToComputerSet.vbs" script from Microsoft... Simple, all we have to do then, is to configure the CS exceptions on our ISA rules, schedule the script and never touch it again!
So, I created a simple script for:
a) Downloading the latest Tor server list from Proxy.org
b) After the download it creates a new file with the correct format (machine_name<tab>IP_address)
c) And then it calls the AddComputersToComputerSet.vbs with the correct parameters
You can download the script here - also download the script from MS (link above) and place them in the same directory. You will need a bit of VBS knowledge to "tweak" the script(s), but I've tried to make the code "easy understandable". Now, make sure you can run it from your ISA box (it downloads over HTTP), and then schedule the thing (oh, and remember to remove the Msgbox "Done!" line if you want this as a scheduled task).
If you want it to run from another machine, take a look at the link to the AddComputersToComputerSet I provided above (some changes are needed).
Please report back if you have any bug reports or ideas! It provided "As Is" - after downloading you're on your own :)
The dynamically created/updated ISA Computer Set:
The ISA Rule/Publishing Exceptions:
What's missing?
I can think of a lot of things I'd like to add in there - but the idea with this blog entry is to "spread the word" and a Proof of Concept.
Personally I want to add logging of script actions, email alerts if the list is unavailable or some other errors occur. Also, there's a weakness in case the downloadable list is compromised somehow. Say someone adds Internal/Private/"not-Tor" IPs etc. to the list, it just might give some strange results for your users. So, we have to trust the list is OK secure - but it would be a good idea to put in some sort of validation on what IP addresses are put into this particular CS.
Hope you can use this :)
.
Posted by Jakob H. Heidelberg at 1:40 PM 0 comments
Labels: encryption, exploit, hacking, ISA, microsoft, script, scripting, security, The onion ring, Tor
Read an interesting piece of information about the most likely security threats in 2008 - read it here!
Top Ten Cyber Security Menaces for 2008:
The ranked list is created by Stephen Northcutt, Ed Skoudis, Marc Sachs, Johannes Ullrich, Tom Liston, Eric Cole, Eugene Schultz, Rohit Dhamankar, Amit Yoran, Howard Schmidt, Will Pelgrin, and Alan Paller.
.
Posted by Jakob H. Heidelberg at 9:59 AM 0 comments
Labels: security
Hi there,
Let everybody know the two very simple golden rules when it comes to web-applications that are communicating with SQL servers:
1. Never send user input text strings directly to the (backend) SQL server(s). Make sure to "clean it up" first (eg. no special chars etc.). Only accept thing you KNOW you want.
2. Always use Stored Procedures and call them with arguments instead of letting text strings (SQL injections) take control of your (backend) SQL server(s).
Sticking to those rules will make life a lot easier for admins, consultant and security guys like me. Tell you company developers, thirds party software vendors etc. to stick to the rules (even though they should know them by heart already) - spread the word and life will be a lot easier for all of us good people around the globe :)
Posted by Jakob H. Heidelberg at 12:42 PM 0 comments
Labels: security, SQL, SQL Injection
I have to blog this right away - it will be part of a larger "GP Processing" article at some point though... But this is IMHO important stuff which needs to get out there quick :)
I've heard the following sentence too many times (in one way or the other): "You can only assign Group Policy Objects to Site, Domain Level or OU's"...
- but that's only partly true! Normally in newsgroups, forums etc. this leaves the readers (eg. someone who asked a GP question or whatever) with the impression that you cannot "hit" members of a certain Security Group only (which leaves you with "Site/Domain/OU Filtering" and/or "WMI Filtering" as the only possible a choices available). But that's simply not fair to the amazing Group Policy processing engine!
Even though "WMI Filtering" is pretty well-known these days (after WS2003 arrived), many people tend to forget the little - but extremely effective and flexible - thing called "Security Filtering" (even though it's somewhat more "Basic" compared to WMI)...
Let's talk about it for a minute or two if you are interested...
You can set this kind of filtering within the Group Policy Management Console (GPMC) on either the Scope tab:
- or the Delegation tab (a bit more Advanced):
As you can see, by DEFAULT all Group Policy Objects (GPO) include "Authenticated Users" with both Allow:"Read" and Allow:"Apply Group Policy" permissions set. Both of these permissions are needed for users and computers to take on (or process) a given GPO:
The thing about the very important "Authenticated Users" group is that it includes ALL User AND Computer accounts/objects within the AD domain (Domain Controllers too, right). So, by default a GPO applies to both computers and users (we are not going to talk about disabling GPO parts etc. now).
That's the "technical" explanation why policies placed on
a) the Site applies to ALL users and computers within the Site (users site follows computer site, site follows IP address)
b) the Domain Level applies to ALL users and computers within the Domain
c) any given OU applies to ALL users and computers within that particular OU (and sub-OUs for that matter)
=> because the "Authenticated Users" security group is there by default. These default permissions on new GPOs are handled by something called "Security Descriptors", but more on that in some other blog or article.
So, we have Security permission on all of our GPOs (unfortunately not the GPO links, but that's another talk) - leaving us with GREAT power to control to whom he particular GPO should be assigned (or 'applied'). All we need to do is to change the default permissions and <Zaboooka!> we are in complete control.
First step is generally to remove the "Authenticated Users" group from the GPO in question. Click Remove (below Security Filtering section) on the Scope tab and click OK:
Click Add... and select the domain security group you want to "hit" - click OK when done:
And <poof>, this GPO will only apply to members of "The Sales Group" - or whatever group (or user, or computer object...) you selected:
Now all you need to do is to link the GPO to the Domain Level (or Site or OU if that's better in your case) - but the Domain Level should be fine for most environments.
Now, you could turn this around and Exclude certain groups, users or computers - by setting Deny:"Apply Group Policy" instead. In some cases that might be the best choice - but as always with "deny" you have to watch out (manly because deny overwrites allow)!
Also note, that Security groups can include both user and computer accounts - we are maybe used to thinking that groups are for users only (in my experience most admins know the "Domain Users" group - but the "Domain Computers" group is not that well known)... But, with this in mind, you could make a group of computers instead of applying a WMI filter for instance (which is generally slower).
You could use other methods for setting permissions than the GPMC (like scripts) - but the GPMC is a wonderful tool for doing this easily - no sweat!
One way of automatically creating Security Groups from members of an OU is described in my article "Configuring Granular Password Settings in Windows Server 2008, Part 2" - these groups are referred to as Shadow Groups (cool, right). In some "filtering situations" that is nice to know...
Wow - that was nice getting it off my shoulders, and now I can refer to this blog entry whenever I get the question again - and so can you of course :-)
.
Posted by Jakob H. Heidelberg at 12:48 AM 2 comments
Labels: gpo, group policy, OU Filtering, Security Descriptors, Security Filtering, Shadow Groups, Site Filtering, WMI Filters
Got a question about whether it's possible to attach physical network adapters to VM Wares virtual network adapters - like eg. 1-to-1. An 'yes' it's possible... Just like it's possible in Virtual PC and Virtual Server from Microsoft.
It's basically the same story for VM Ware Workstation and Server (almost the same dialog boxes) - go to Virtual Network Settings:
Select what "Virtual Networks" you want - in here you can assign specific NICs to VMnet0-9 (you BRIDGE your adapters to the virtual "switch" you could say).
Pretty nice - now you're almost done...
On the Virtual Machine Settings - select the Network Adapter - choose Custom - and select the Virtual Network your Physical Network Adapter is bound to:
That should do it. Simple, right?
.
Posted by Jakob H. Heidelberg at 9:47 PM 0 comments
Labels: multihomed, network, virtual server, virtualization, VM Ware
The Microsoft Group Policy Team invites everyone to send in suggestions for Explain text changes of any kind (check the link).
Just send your suggestions to "gptext(@)microsoft(.)com".
*
Posted by Jakob H. Heidelberg at 12:58 PM 0 comments
Labels: group policy, microsoft
So, you are in the mood for studying Group Policy? In the lack of GGPI, I know the feeling.
And you got tired of reading my GP stuff here:
http://www.windowsecurity.com/Jakob_H_Heidelberg :-)
I'll recommend you to go for these sites then:
http://blogs.technet.com/grouppolicy
http://www.gpanswers.com
http://www.gpoguy.com
That's where everything starts...
Enjoy!
.
Posted by Jakob H. Heidelberg at 8:57 PM 0 comments
Labels: gpanswers.com, gpoguy.com, group policy, microsoft, technet, windowsecurity.com
Some say Danes are strange - this is the proof :-)
A guy installs an Oracle database with his nose only - go check out "The Nose Job":
http://www.youtube.com/watch?v=CHzV4LZnvHc
Posted by Jakob H. Heidelberg at 5:04 PM 0 comments