File access auditing on a Windows fileserver: Data Leakage Prevention

Here is a clever script concept that helps company managers notifying someone's unusual amount of file reading. That's typical behaviour for an employee who is intended to quit and try to steal all the files of that company. Such auditing softwares are on the market for several hundred or thousand bucks!
Luckily for you, I've written one in bash. OK that's not good news for ones who use only Windows. But it can be easily portable to any script language, for example, php so that it could be run directly in the Windows fileserver or DC by installing the proper runtime enviroment. (PHP, ruby, python, etc.)
Exploring that thought further, now I'm going to translate that for myself. ;) But for now, it's enough to get it work in bash.

The original idea is that we suppose that all the users open almost the same amount of files daily on their daily routines. This script always alerts when a statistical threshold percent reached per user.
In the following example you are going to see a nice solution for lab use in which I transfer the logfile from the Windows server to a Linux server to be able to run the bash script on it. You can find detailed comments inside the script.

Step-by-step installation:
1: Enable audit log policy on your Windows Server, assign it to the target folders and test it
(Note: in the above blog you can find an advanced example. In my case I look for event id 4663 because it just contains the information I need.) Set the audit rules according to your needs. The less eventrule the better. We need to trace file reads so the first rule is a must.

2: You need to export the specific events from the security log to a plain file. So create a getsec.ps1 file in c:\script\ with the following content:
Get-EventLog security -After (Get-Date).AddDays(-1) -InstanceId 4663 |select Message|ft -AutoSize -Wrap > c:\auditing\report.txt
3: Also, don't forget to create that c:\auditing folder and then put an empty file into it named: mounted

 4: Schedule the script to run at the end of the working hours or at midnight. The command is to be: (e.g.) C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe and the argument (e.g.): -executionpolicy bypass -file c:\scripts\getsec.ps1  2>&1 > C:\scripts\log.txt
5: Share c:\auditing folder with a dedicated user that is intended to be used only by the Linux server, e.g.: linuxsrv
6: On your linux box, install the following packages: cifs-utils dos2unix mutt iconv
7: Test your connection:
 [ -f /mnt/mounted ] || mount.cifs //192.168.xx.xx/auditing/ /mnt/ -o username=linuxsrv,password=Sup3rS3cur3P4$$,domain=contoso
8: Create the base directories in, e.g.
mkdir /root/auditor && cd /root/auditor
mkdir archive average stat users; echo "0" > counter

Having succeeded, congratulations, now you are ready to track your file access activity and watch out for possible data stealing FOR FREE!


Here is the mighty script. See comments inline!

"Verbose" event logging in Windows

The behavior that my Windows 2008 Network Policy Server (aka Radius Server) did not log the successfully authorized usernames always bothered me. Fortunately there is a way to get that stupid habit to work as expected.
Open an elevated command promt and type this to get a list of your event categories and their subcategories:
Auditpol /list /subcategory:* /r  (optional)

Then type: (note that category name strings are localized!)
Auditpol /set /subcategory:"Network Policy Server" /success:enable /failure:enable  
and... backup your policy(ies):
Auditpol /backup /file:C\mypolic.csv  (optional)

Another method to log both Event 6273 and 6279 could be done via a GPO:
Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies -> Logon/Logoff -> Audit Network Policy Server (set both success and failure to enable). Don't forget to gpupdate /force.

Further reading here.

Windows 2008 Server R2 hangs on "Preparing to configure Windows. Do not turn off your computer"

Last night I started installing updates on a Windows 2008 R2 box but when I had my dinner and returned to my computer I got pissed off seeing the server stalled at

and I could not RDP into the OS. I spent ca. half an hour waiting for something to happen, then, made a short google search. It turned out that if I connected to this OS via the services.msc console of an other server being in the same domain network I could see that WINDOWS MODULES INSTALLER Service was stuck in Stopping state.
Using the built-in Sysinternals utils:

taskkill /S hostname /IM trustedinstaller.exe

or

sc \\computername queryex TrustedInstaller
taskkill /s computername /pid /f

...I could have been able to terminate that task. According to some internet records if I had done so, my server would have restarted without a hitch. Luckily enough, after entertaining me for more than one hour (-meanwhile actualy doing nothing-) this damn server finally restarted by itself! After the reboot it installed the updates and got ready in less than 5 minutes.
So, in case you are here because you are in the same business as I was, now you'd better have some coffee and wait patiently instead of roughly interfere.

How to remote control your domain Windows 7 computers via remote powershell and remote registry from a Windows 2012 domain controller

From briantist.com

If you are lucky enough to have no machines in your environment below Windows 7 / 2008 R2 (where do you work?!) then this is the only one you need. All of the settings we are using will be in Computer Configuration so if you want to disable User Configuration as I have go ahead.

1. Create your GPO, name it what you want, place it where you want, etc.
2. Edit your policy.

Enabling WinRM

1. Browse to:
   Policies > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service
   1. Open the “Allow Remote Server management through WinRM” policy setting (Server 2008 R2 and later).
   2. Open the “Allow automatic configuration of listeners” policy setting (Server 2008 and earlier).
2. Set the Policy to Enabled.
3. Set the IPv4 and IPv6 filters to * unless you need something specific there (check out the help on the right).

Setting the Firewall Rules

You can use the new Firewall with Advanced Features policy to configure the rule instead, but this will only work on Vista and above. Additionally, you should configure this from a Windows 7 / 2008 R2 machine because of a difference in the pre-defined rule.

1. Browse to:
   Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security > Windows Firewall… > Inbound Rules
2. Right click and choose “New Rule…”
3. Choose the “Windows Remote Management” pre-defined rule.
4. When you click next you should see the two rules that will be added.
5. Click next, choose to Allow the connection, and then Finish.

Service Configuration

At this point we have enough in place to get this working, but I like to do a few more things to ensure that the WinRM service is configured to start automatically and to restart on failure.

1. Browse to:
   Policies > Windows Settings > Security Settings > System Services
2. Find the “Windows Remote Management (WS-Management)” service.
3. Define the policy and give it a startup mode of Automatic.
4. Browse to:
   Preferences > Control Panel Settings > Services
5. Create a new Service preference item with the following parameters:
   1. General Tab
      
      1. Startup: No Change (the policy we set above will take precedence over this anyway)
      2. Service name: WinRM
      3. Service action (optional): Start service
   2. Recovery Tab
      
      1. First, Second, and Subsequent Failures: Restart the Service

 Whole article is here

Set powershell execution policy

Go to Computer configuration / Policies / Administrative templates: Policy definitons (ADMX files) / Windows components / Windows Powershell. Set "Turn on script execution" to "Allow all scripts". This policy setting exists under both "Computer Configuration" and "User Configuration" in the Local Group Policy Editor. The "Computer Configuration" has precedence over "User Configuration." If you disable or do not configure this policy setting, it reverts to a per-machine preference setting; the default if that is not configured is "No scripts allowed." !

Remote registry access enable

1. On a domain controller, Start > administrative tools > Group Policy Editor > Either edit an existing policy or create a new one (Remember its a computer policy you need to link it to something with computers in it, if you link it to a users OU nothing will happen).

2. Navigate to, Local Computer Policy > Computer Configuration > Policies > Windows Settings > Security Settings > System Services.

3. In the right hand pane locate "Remote Registry".

4. Define the policy, and set the startup type to automatic.

Article is from petenetlive.

Microsoft Windows Server: READ ONLY Domain Controllers ?! Nooooo

RODC? That's one of the biggest fallacy in the IT I've ever seen. For those who don't know: that's some kind of domain controller to be placed in a branch office. That's an office where security is in question, where servers can easily be stolen.
RODC's don't have writeable LDAP DB locally so they forward all the login requests to a RWDC. Do you see how supersecured they are?

Here is where the mystification begin: RODCs still have cached passwords locally so in case hackers gain direct access to the local system passwords - theoretically - could be compromised.
And the most biggest terrible security risk: passwords and accounts still CAN BE reset, re-enabled or in any way modified against an RODC. In this case an RODC stupidly forward the request to a RWDC and of course RWDC will automatically commit and redistribute the changes because of the confidential relationship between them.
In short: "When the password is changed or reset against an RODC, the RODC will forward the change to a W2K8 RWDC and after that it will automatically inbound replicate the password using the "Replicate Single Object" method assuming the account for which the password was reset/changed is still allowed to be cached/stored."
See more info for example at http://social.technet.microsoft.com/Forums/windowsserver/en-US/198e7c6a-0541-43cf-803f-1259e66fdd80/how-to-know-readonly-domain-controller

Windows 2003 / Exchange migration to Windows 2008 R2 / Exchange 2010

That's really a difficult scenario.
Let's imagine that we have a working system of two physical server hardwares, one for Windows 2003 and one for Exchange 2003 Server.
We are going to install two new physical server into the domain. Each powered by a Windows 2008R2 and a Hyper-V role installed on it. On these 2 new hosts we are going to install 6 virtual servers. Having done the whole process we remove the old Windows 2003 hosts.


[..........]
Here come the Windows 2008 R2 installing steps and the process that the two new domain contollers are taking over the FSMO roles from the old Windows 2003 DC
[..........]

So, we are going to install six new Windows 2008 R2 servers. Two stand for domain controlling and the related roles (called DC1 and DC2) and four to serve Exchange 2010.
2 servers are for CAS (Client Access Server) Failover Array and 2 for Mailbox Servers. As I mentioned (did I?) no storage attached to this hw config.
The first step prior to install Exchange 2010 is to raise the domain and forest functionality level at least to 2003 level. Double check if it's okay. 

In case that shit happens, you should consider this and this. But before a problem occurs, you may want to read this. Be careful with dcpromo /forceremoval on Windows 2003 because you may not be able to login with your domain user after the removal. DO NOT do /forceremoval on a working Exchange server.

[...] Here comes the howto on taking Exchange 2003 database and roles by the new servers [....]

to be continued....

"szakmai blog"

Idestova 8 éve dolgozok rendszergazdaként, de előtte is számítógépekkel foglalkoztam. Rengetegszer felmerült már bennem a gondolat, hogy indítsak egy blogot és elmeséljem benne angolul és magyarul is azokat az érdekes problémákat, amikkel szembesültem (angolul, hogy a gugli is szeressen és legalább esély legyen rá, hogy lesznek látogatóim) - és a megoldást is, amennyiben megtaláltam rá. Nem vagyok egy nagy blogger, így sosem jutottam el idáig.... Egészen mostanáig.

Úgy alakult, hogy megszűnik a munkahelyem. Több önéletrajzot is benyújtottam, egyiket a BalaBit -hez. A jelentkező form-on volt egy érdekes rovat, ahol meg kellett volna adnom a szakmai blogom címét. Nos, ez volt a végső lökés. Így most már van blogom... Igyekszem feltölteni a szívásokkal az elmúlt évekből, legalább címszavakban, mozaikszerűen, vagy linkekkel. Amennyire még emlékszem. :-) Talán 1-2 dolog majd eszembe jut...

Rendszergazdaként és rendszermérnökként főleg Linuxokkal foglalkoztam, sok mindent láttam és sok mindent csináltam is. De Windows 2k3 2k8 és Exchange 2k3 2k7 esetében sem lehetne eladni, bár újat mutatni biztos...  De most nem ilyesmivel indítok. Már tudom is, hogy mi lesz az első komoly bejegyzésem, egy olyan probléma, amivel épp a héten küzdöttem meg. Több-kevesebb sikerrel.