Thursday, April 30, 2009

Back to the SSLF

Since I now have working test environment, and includes both real and virtual machines, I will be starting back onto the SSLF testing (Fedora 10 work this weekend...hopefully).
However (and this is more planning for tomorrow), this time:
- Different user logged into each machine.
- Each box in a seperate OU
- This allows me both redundancy, and a way to verify any problems.
- This also allows me to test different apps on different clients at the same time
- Settings will be (painfully) applied sequentially.

I should also note that I created two backup copies of each virtual machine. I got into too much of a hurry in my previous attempts. :(

Passwords in plaintext?

It has been a week since I could post on here, and the reasons range from mundane to just downright stupid.

I really didn't have anything to post earlier in the week. I had decided to change my test bed set-up. Instead of: 1 DC, 1 MS, 1WS, all on an XP host, I converted another real box into a server. In this way, I can better duplicate network traffic for capture, and for testing functionality. I did originally think that I was OK with just using a virtual network on one box. However, I started to notice "little things" in the VMWare Server environment. The biggest one was that joining the domain took not only creating the computer in AD, but the Host Record (A) in DNS, along with restarting (so far) a minimum of three times. I have never had that happen before, believe it to be a hardware issue on the boxes I am using, and have moved passed that issue.

The really stupid thing that cost me a whole day: I was indirectly involved with a friend of mine who had found out that an admin had placed a very interesting plaintext file on a desktop. Apparently, the file had an Overly obvious name, and contained the admin account name and password for a vital application (this account also happened to be a domain account, and was part of Enterprise, Domain, and Schema admin groups...don't ask).

In any event, if anyone ever reads this and wonders what the set-up is now:
1 DC, 2 MS (virtual), 3 WS (2 virtual, 1 host).

Thursday, April 23, 2009

Virtual(ly annoying) domains

The testing that I have been doing of the SSLF baseline for XP workstations has been a fun challenge.
-Creating a new DC in a virtual environment
It seems as though even in a virtual environment, Microsoft still has to be a pain to work with at times. I know that this is a surprise. On Tuesday, I had successfully crashed my virtual DC (with some strange mutations visible in the RSOP prior to crash), which was followed by the fact that even after promoting my member server to a DC, I was still not able re-join my test workstation to the domain. Although it should have been a simple issue of moving the workstation into a workgroup and then back to the domain, it wasn't! The steps I had to take to re-create my virtual network are:
1) Create another virtual machine and install Server 2K3.
2) Remove all roles from original member server
3) Remove member server from domain (workstation already moved back to workgroup)
4) Run 'DCPROMO' on new server, setting up AD and DNS (a new subnet range had to used)
5) Move member server into new domain (Step 4 was done twice, with a new domain name used the second time. While I tried to keep the original domain name, this was unsuccessful. The MS an WS could ping, but not join to the domain.)
6) Establish roles on MS
7) Move workstation to new domain

It has been some time since I have done any major network admin. However, becuase I had to do some strange additional steps, I wonder if:
a) VMWare maintains a permenant routing table for bridged virtual networks?
b) even without doing any transfers, using images, shouldn't I have been able to just add at least the workstation ot the new domian through the progression: old domain->workstation->new domain?

In any event, it was right back to the SSLF adventure after this point.

Tuesday, April 21, 2009

Side Project - SSLF Baseline

Has anyone ever really tested how the SSLF baseline for windows workstations affects different software products and comm pipes used on the network? I have had so many experiences with the SSLF "breaking" this or that client/server application, and yet the documentation available is minimal. Anyone can find what each setting means and does. The problem is that most commercial software is not well documented at the lower layers
So one of my side projects is to test the SSLF baseline in a virtual environment and to see how each setting affects whatever product I am using at that time. I think that this is going to turn into a long-term project as there is a large number of security applications that I want to test against this baseline.

U of Michigan here I come!

Last Friday I received my official acceptance letter for the Masters in Software Engineering at the best university in the country - University of Michigan!
People have asked me how that relates to me focusing on network security and my answer is always the same - At least 90% of the security issues found on networks can be attributed to poor programming techniques!

First Post (Last Post??)

Life has been crazy the last couple of weeks. In addition to death, sick kids, robbery, and school, I decided to take my Dell Inspiron 1721 and install Fedora 10. I have always preferred *nix flavors to Windows, but this will be first time ever installing and running one at home. I just hope that the Dell will work better with Fedora then it did with Vista!