Blog: Windows 2008 R2

When working on a compromised system, it's always good to have a "toolkit" available on read-only media (in case built-in utilities, like netstat, have been replaced on the compromised machine to hide the attackers activities).  However, you also need to know how to USE the tools in your toolkit.  At my training last week I was working to recover a compromised web server.  After doing some cleanup and removing some clearly malicious software, I tried to use netstat to verify the current listening ports/services on the machine (along with associated processes).  The local netstat on the machine had been hacked to return no output, but thankfully the netstat EXE on my "toolkit" CD was working.  I quickly combed through the list of ports that were labeled "LISTENING".  I didn't see anything listening that was out of the ordinary.  However, when the following prompt popped up I knew the attacker still had remote access to my machine. [more]

Upon a closer look at the netstat output, I noticed there was an "ESTABLISHED" connection to TCP port 23 on my host (typically used for telnet).  P0wn3d!

Lesson learned… verify ESTABLISHED sessions in addition to actively LISTENING services.

I was assigned recently to a task that had been started by another network engineer. The initial problem started when software updates were applied to the server. The network adapter lost its driver and wasn’t able to talk to the network, let alone the world. He was able to restore network connectivity by reinstalling that driver and resolving other network issues that had arisen, but was unable to fix an issue where network drives were not mapping to the server in the time he had available to him.

When I took a look at it the next morning, all signs led to the network card going bad and needing to be replaced. However, as I was continuing to troubleshoot, I noticed that they had the Network Threat Protection module for Symantec Endpoint Protection (v. 11.0.4) installed. I created a rule on the firewall to open all traffic between sources on the 10.0.0.0/8 network and immediately people were able to map network drives and start working.

While working with a client, I recently promoted a new Windows 2008 R2 virtual server to a domain controller.  Prior to running dcpromo.exe everything looked and performed great, but I noticed a large amount of system resource issues following the promotion.  I also ran into several cases of not being able to open various management console snap-ins or other applications.  After troubleshooting various issues I finally decided that they all must have had a singular root cause. 

After digging around in the event viewer and scratching my head a bit, I asked another network engineer what I was missing. He looked around for a few minutes and asked me if disk quotas had been enabled via group policy.  I opened up the Group Policy Management console on another server and discovered a disk quota group policy object for terminal servers that had been applied to the Domain Controllers OU.  After excluding the new domain controller from receiving the policy, and then manually removing the existing disk quota entries the server was running at full speed with full functionality.

I had applied Windows updates to a customer’s Windows 2008 R2 server that had Microsoft Threat Management Gateway installed, and I could not RDP to the server after rebooting.  I connected to the server locally and could tell from netstat that the server was not listening at all on port 3389.

It turns out that there was a problem with the RDP-tcp protocol not working because it was configured to listen on all available network adapters.  This being a proxy server, it had internal and dmz network adapters.  To fix this issue, set the RDP-tcp protocol to only bind to the internal network adapter. [more]

• Open Remote Desktop Session Host Configuration.
• Open th/e properties of the RDP-Tcp protocol underneath Connections.
• In the Network Adapter tab, change the setting from “All network adapters configured with this protocol” to the specified internal network adapter and hit apply.
• On the Actions bar to the right, click Disable Connection and then Enable Connection to reset it.
• Run netstat to confirm that the server is listening on port 3389 again.

I have a few notes to share on DFS in Windows 2008 R2. First of all, Microsoft changed the way DFS replication is done starting in Windows 2003 R2. In previous versions, DFS replication for SYSVOL shares on domain controllers as well as DFS replications was handled by FRS (File Replication Service). Starting in Windows 2003 R2, the service was overhauled along with the management interface. Replication for DFS is now handled by DFS Replication Service and the two (DFSR and FRS) don’t play ball with one another. That is to say that you can’t use pre-windows 2003 R2 servers in the same DFS replication topologies with post-windows 2003 R2 servers. However, SYSVOL in all versions continues to use FRS until all domain controllers are Windows 2008. Additionally, once you have your DFS tree in place and get your replication topology set up, you’re not done. Make sure to edit the file exclusions list for the replication group. By default, a new replication group EXCLUDES files with the ~ (to start the file), .tmp, and .bak files. The ~ makes sense, but .tmp and .bak could be  a problem depending on the type of data in the share.