CentralMNIT

Has anyone been using IIS FTP 7.5 with virtual directories? I've run into an interesting issue with Microsoft's latest FTP revision and there doesn't seem to be much documentation on it yet. I create an FTP user who has multiple virtual directories in their home directory. - Each virtual directory is mapped to a unique UNC path - Each directory uses alternate credentials. - Global virtual directories are disabled In the IIS FTP Manager I can successfully authenticate, connect, and browse to each virtual directory. However, when logging in as this user via FTP, I get the following error when performing a directory listing: Response: 550 Keyset does not exist Error: Failed to retrieve directory listing In attempting to locate the problem, I ran Procmon.exe to see what was causing the error and noticed an Access Denied while performing the CreateFile operation on the following location: C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\6de9c.... I'm assuming this key is used for IIS authentiation. In viewing the Security ACLs for the 6de9c.... key, the IIS_IUSRS group is granted Read permissions. I'm suspecting when using alternate credentials in the scenario I'm attempting, those alternate credentials are being run against the 6de9c.... key, which doesn't have permissions by default because they're not running under the IIS_IUSRS group. (bug??) For a workaround, I created a local group containing all of the alternate credentials (from AD) and granted the group the Read permission to the 6de9c... key. Recap on the symptoms: - FTP users without virtual directories connect and are able to list directory without error - FTP users with virtual directories using pass through authentication works - FTP users with virtual directories using alternate credentials generates and error during list directory If anyone has better insight on this issue, feel free to drop a comment.

•

Monitoring Event Logs via SNMP (EvntWin) - over a year ago, 468 views

Whoa, it's summer already! No wonder there hasn't been too much activity in CMIT. So in the spirit of summer, I'd like to present a few handy security tips everyone should employ in their Active Directory (AD) environment:#1: Ensure you have a notification process in place whenever an account lockout occurs.A bit of an alarmist approach? What if you came home and noticed crowbar marks on your front door? Wouldn't you then presume the possibility of someone attempting to break into your home? Now let's take that methodology and apply it to domain security: A large amount of account lockouts presents the possibility of someone attempting to break into your domain.Account lockouts can be checked through your Domain Controller (DC) security logs via the event viewer. Set a filter for event ID 644 to quickly browse through all of your lockout events. If you have more than one DC (which you should for redundancy), make sure to check each of them, as the lockout event will only be generated on the DC where the authentication attempt took place.Easy enough? Yes. However, unless you plan on manually checking every DC's security logs on a daily basis, you'll never know about an account lockout until something breaks. A user calls in, an application stops working, a service doesn't start after a reboot, etc. And better yet, if you allow accounts to unlock automatically, you may never know about an account lockout unless you have a notification process in place. (although it's almost a guarantee users will call no matter how short of time period the unlock is...)Microsoft, in their infinite wisdom, provides no straight-forward answers for sending alerts based on generated events. Seriously, is a config tab in the event log properties too much to ask? Anyway, there's a few methods to go about doing this, and without touching on enterprise solutions, here's my recommendation:Typically, I have either used VBS, Powershell, or 3rd party products to scan the Windows Management Instrumentation (WMI) of each DC for new account lockouts (event ID 644) and send an email for each new event. In small environments, this approach works just fine, but how does it scale in a larger environment? Frequently scanning the WMI for event logs can be quite taxing on CPU resources, depending upon your DC's hardware configuration.Enter Microsoft's EvntWin and EvntCmd, which are included in Windows Server operating systems 2000 and later. These two programs will send an SNMP message containing the details of any desired event as soon as it's triggered by the OS. There's not much documentation, but they're simple enough to setup.Prior to configuring EvntWin, you should ensure you have SNMP installed and your traps configured correctly on the servers you're monitoring. Reference: http://support.microsoft.com/kb/324263In this example, we'll use EvntWin to generate an SNMP message whenever an account lockout is detected.Connect to each DC and perform the following:Start > Run > EvntWinConfiguration Type: Select CustomFrom the left menu, select Edit >>Browse Event sources: Security > SecurityLocate and select event ID 644Click AddNow the enterprise OID of the security log will be displayed. You'll need this to configure your SNMP monitor to listen for traps from this OID, so make sure to copy it.Add anything else you may find useful to be notified on and click Apply when done When you're finished, EvntWin should look like this:Side Note: You can use the Export button to create a file for use with EvntCmd and automate this process on multiple servers via a .BAT or script. Our final step is to configure your SNMP monitoring application to listen for the enterprise OID you copied earlier and send email notifications each time a trap is received.Don't have an SNMP monitoring solution yet? That's another topic for another day.Reference: http://www.microsoft.com/resources/documentation/windows/xp/all/pro...

•

Hiding Scheduled Tasks with AT and schtasks - over a year ago, 444 views

In the last month I've had 5 requests to run a scheduled "hidden" NTBACKUP job on standalone XP workstations. Requirements were as follows:- Full backups to run Sunday @ 8pm - Differential backups to run Monday - Saturday @ 8pm- NTBACKUP must not be displayed while running.- Additional accounts cannot be added to the local system.- Save .BKF file to USB attached storageThe key to running an interactive task as a hidden process is running under alternate credentials. A simple method of accomplishing this is to create a local account with a strong password, grant appropriate permissions to the account (Backup Operators in this example), then assign the credentials to the scheduled task. However, in order to meet the requirements set above, we'll need to use the built in SYSTEM account instead.There's probably a few methods for setting this up, but here's what I've found to be the quickest and most reliable method (at least on XP) for me. Works great as a quick backup for home users too!For this scenario I'll be using the ancient AT command for simplicity. AT has been replaced with the more robust (and complex) schtasks command, so I'll include an example using this method also. Surprisingly, AT is still around in Windows 7.1. Open NTBACKUP, configure and schedule your task. Save .BKF to external storage.2. Open Scheduled Tasks, locate the NTBACKUP job you created, open Properties and copy the contents of the Run: field, then delete the scheduled task.3. Create a .BAT file and paste the contents from the NTBACKUP Run: field and save. In this example, we'll be using "C:\Backups\Differential Daily.BAT"4. Once you've saved the .BAT, open a command prompt and enter the following: at 20:00 /EVERY:M,T,W,Th,F,Sa "C:\Backups\Differential Daily.BAT"For the weekly full backup, repeat steps 1 - 3 and modify the AT cmd on step 4:at 20:00 /EVERY:Su "C:\Backups\Full Weekly.BAT" As I mentioned earlier, here's the schtasks version of step 4:schtasks /Create /SC WEEKLY /D MON,TUE,WED,THU,FRI,SAT /ST 20:00:00 /TN "Differential Daily Backup" /TR "\"C:\Backups\Differential Backup.BAT"" /RU "SYSTEM"andschtasks /Create /SC WEEKLY /D SUN /ST 20:00:00 /TN "Full Weekly Backup" /TR "\"C:\Backups\Full Backup.BAT"" /RU "SYSTEM"(Note the use of the override operator "\" in /TR "\"C:\Backups\Differential Backup.BAT"". This is required because there's a space in the execution path. Without the override operator, your task will fail with a "Could not start" message... Lovely.)Once completed, you can view the jobs in Scheduled Tasks. Notice the tasks you've created now run under NT AUTHORITY/SYSTEM, and will run silently in the background without user interaction. Keep in mind, scheduled tasks created with AT are unable to be managed via the Scheduled Tasks GUI. You'll need to use the AT command if you'd like to modify the task. These tasks can be deleted and renamed via the GUI, however, you'll lose the ability to manage them with the AT command unless you rename them back to the At# (At1, At2, etc.) naming standard.Now the real trick is getting your users to check these backups on a consistent basis... Good luck!AT reference: http://support.microsoft.com/kb/313565SCHTASKS reference: http://technet.microsoft.com/en-us/library/cc725744%28WS.10%29.aspx

•

Piping with HTC EVO on Android 2.2 - over a year ago, 187 views

Last week I received an HTC EVO running Android 2.2 from my workplace. I've had an iPod Touch for the better part of a year, and I must say I'm quite impressed with what they've expanded on in the post-iPhone world. Especially the possibilities of widgets. Who knew? (Oh right, Microsoft did with Vista... and arguably Windows 98 with active desktop, and I think KDE... and I'm sure plenty of 3rd party developers before that...) Last time I owned a smart phone was in 2006... I love IT, but I don't enjoy carrying gadgets around to distract my every waking moment, unless I have a good reason to do so. This coming from a guy who used to repair cell phones for a living. --Meh. There is, however, one obnoxious "feature" I've come across that seems to be a common complaint with the HTC EVO keyboard: Those of us using the pipe symbol: | be it to manage your favorite CLI remotely, or—as I found—to enter a password, will find nothing but errors in your ventures. The HTC EVO keyboard provides access to the ASCII 166 broken pipe character: ¦ instead of the standard ASCII 124 pipe character: | as found on your average desktop keyboard. Is this by design? If it is, I don't understand using a symbol most people never use. Or am I just missing something? Could be! For a workaround, other than changing your passwords to not include a pipe character (heaven forbid), the simplest method is to locate the ASCII 124 pipe via a web browser or send yourself an e-mail including the character (from an account with credentials that doesn't use the pipe, right??), and copy/paste from the EVO. If you're a heavy pipe user, then you may want to look into downloading a custom keyboard app from the Android market that provides this key for you. Happy piping!

•

Don't Fear the Auditor - over a year ago, 161 views

Keeping an updated record of what credentials your service accounts run under is crucial to maintaining security integrity of your AD environment. Too often these accounts are configured and forgotten about.. That is, until you have to change the password. This is especially true for the all powerful, and over used Administrator account. When then leads to password changing apathy--a very dangerous road to travel. Think twice about using the Administrator account for *anything*, especially automated processes, such as services and scheduled tasks. Changing the password on the Administrator account can become a nightmare if you've assigned these credentials to tasks and services, yet have no easy method of locating them. Oh, and remember, after a password change, any dependent service/scheduled task will fail to start the next time that service is restarted, or the scheduled task needs to run unless you update them. Sounds like fun! So, in celebration of your decision to remove the Administrator account from all services/scheduled tasks, let's take a look at a few methods we can utilize to audit service credentials: Objective: Query every server in our AD environment for their list of services, and their credentials. First up, let's take a look at the sc.exe command with the "qc" option. Example: sc qc snmptrap >> C:\Results.txt Output: C:\Results.txt Exactly what we're looking for! Except... this command can only be run against one service at a time, so in order to meet our objective, we'd need to first collect all services via the "sc query" command, then parse that output to run with this command... and once you're finished collecting info, we'll need to parse results again to collect just what we need. Bleh. Sounds like a lot of work to make this a useful auditing tool... Next up, let's take a look at the new Microsoft poster child, Powershell! Powershell allows you to query WMI directly, which will simplify your auditing life immensely. Wait--Did you read that correctly? Allow me to restate: Windows stores vast amounts of configuration data in the WMI. If you can query the WMI easily, you can easily audit just about anything. Example: Get-WMIObject win32_service -computername 127.0.0.1 | select name,startname Output: Oh, you only care about the Administrator account? Try this one: Get-WMIObject win32_service -computername 127.0.0.1 –filter "startname='Administrator'" | select name,startname Now let's collect our server hostnames and make some modifications to the script to audit multiple devices. 1. Export a list of all servers (and workstations if you'd like) from Active Directory. This can be done easily by creating an AD query > Define Query > Computers > Name: Has a value. Run it, right click and Export List… to .csv. Adjust query as necessary. 2. We're only interested in computer names, so we'll need to parse the results. Open the .csv and copy only the hostnames to a txt file. In this example, we'll save it to C:\hostnames.txt 3. Fire up powershell and run this command: foreach ($i in Get-Content "C:\hostnames.txt") {$i + "`n" + "=========================="; Get-WMIObject win32_service -computername $i | select name,startname | Export-CSV "$i Results.csv"} Output: HOSTNAME Results.csv Easy! Simple! Or so says the programmers. Powershell is extremely power, yet a monster to learn. Most admins don't have time and expertise to play around with it. So fear not, we have a much simpler method of achieving the same results: Microsoft introduced wmic.exe as a command-line method of accessing the WMI back in Windows 2000. An excellent and much under used tool. Example: wmic /node:"HOSTNAME" /output:results.csv service get name, startname /format:csv Output: results.csv How's that for easy? By using the same steps listed above to collect hostnames, you can parse a wmic command to include each of your hostnames, which then merges them into a single csv: (This can be done with Powershell also) wmic /node:"HOSTNAME1","HOSTNAME2","HOSTNAME3","HOSTNAME4","HOSTNAME5" /output:results.csv service get name, startname /format:csv Enjoy! Reference: http://technet.microsoft.com/en-us/library/bb742610.aspx

Blog Archives

Blog Posts

Securing Insecure Applications w/IPSec

Scenario:

A few weeks back my co-workers introduced me to an excellent method of managing multiple devices without a hardware KVM: Allow me to introduce Synergy (http://synergy-foss.org/)

(Administrator Hat) Wonderful! I can now manage my laptop and workstation from a single HID set (keyboard/mouse)!
(Security Hat) Wonderful! It works by capturing keys from Device A and replaying them to Device Bin clear text. I've just installed a keylogger.

Taking my paranoia to the next level, let's take a look at the network traffic with Wireshark:

Sure enough, the key presses and mouse movements are being transmitted in clear text. (Key Id: 100is the 100^th character in the ASCII character map: d)

So now we have a very useful and very insecure application. Anyone with a packet sniffer on my network and a bit of knowledge has the potential to capture all of my keystrokes and mouse movements. Bummer.

Synergy doesn't include any built in security, so we'll need to rely on another method of securing our traffic.

Encrypting Synergy:

By utilizing IPSec policies in Windows (2000+) we can enforce encryption between two windows devices. In this example, I'll be configuring IPSec between two Windows 7 devices. Microsoft has simplified the IPSec process in Windows 7 via Windows Firewall with Advanced Security: http://technet.microsoft.com/en-us/edge/video/how-to-encrypt-telnet-traffic-with-windows-firewall-with-advanced-security-and-ipsec

However, in this example we'll be using classic IPSec policies, which are available to previous OSes.

Configure IPSec on DeviceA

    1.      Start by opening a new MMC console: Start >Run > mmc.exe
2.      File > Add/Remove Snap-in
3.      Add the following Snap-ins:

IP Security Monitor
IP Security Policy Management

4.      Right-Click IP Security Policies > Select Create IP Security Policy…
5.      IP Security Policy Name: Synergy (or something more creative if you'd like)
6.      Leave default response rule unchecked
7.      Leave Edit Properties checked and select Finish
8.      Select Add.. from the rules tab
9.      Leave "This rule does not specify a tunnel" and select Next
10.  Leave "All network connections" and select Next
11.  IP Filter List: Select Add..

Name: Synergy
IP Filter: Select Add..
Leave "Mirrored. Match packets…" checked and select Next
Source Address: A specific IP Address or Subnet
IP Address or Subnet: Enter IP address of Device B
Destination Address: My IP Address
Select a protocol type: Any
Select Finish and OK to return to Security Rule Wizard

12. Select the IP filter you just created and select Next
13. Filter Action: Select Add..

Name: Enforce Encryption
Filter Action: Negotiate Security
Leave "Do not allow unsecured communication" and select Next
Leave "Integrity and encryption" and select Next, then Finish

14. Select the Filter Action you just created and select Next
15. Authentication Method: Select "Use this string to protect… (preshared key)

Enter a STRONG password and select Next, then Finish

16. Right-Click the IPSec policy you just created and select Assign

Configure IPSec on Device B

1. Start a continuous ping between the two devices. After enabling the IPSec filter on Device A, you should no longer be able to ping Device B until the filter is configured correctly on Device B.

Ping 192.168.100.2 -t

2.      Repeat steps 1 – 16 on Device B. Remember to set the IP filter for Device A on step 11
3.      Once successfully configured on Device B, the continuous ping should now be responding properly.

Confirm IPSec is working

1.      Locate the IP Security Monitor MMC Snap-in
2.      Expand IP Security Monitor > Device name >Quick mode > Statistics
3.      Confidential, Authenticated, and Transport Bytes should now be generating statistics, confirming IPSec is now active and operational.

Now to confirm IPSec is in place with Wireshark:

What a beautiful thing; Nothing but Encapsulating Security Payload (ESP) packets.

Let's take a look at what we've just accomplished:

Created an IPSec policy enforcing encryption between two specific IP addresses.
Confirmed IPSec is operational.

We still have another potential unresolved security issue. IPSec policies have multiple methods of being applied via IP filters, but they're just that: IP filters. We're only enforcing traffic between two predefined devices… If we suddenly change the IP of both devices, they fall outside the scope of our IP filter, IPSec is no longer enforced, and we're back to clear text communications. This could very easily happen in an environment with DHCP, or by adding another Synergy client and forgetting to setup IPSec. (Or by disabling the IPSec Policy Agent service on both devices…) In our final step, we can leverage a Defense in Depth (DiD) approach by utilizing application level filtering within the Advanced Windows Firewall to require encryption.

Enforcing IPSec with Windows Firewall w/Advanced Security:

Enforcing IPSec on DeviceA (Synergy Server)

1.      Open Windows Firewall w/Advanced Security
2.      Right-Click Inbound Rules > Select New Rule
3.      Leave "Program" and select Next
4.      This Program Path: Browse to the Synergy application path and select Next.

Device A (Synergy Server): %ProgramFiles%\Synergy\synergys.exe
Device B (Synergy Client): %ProgramFiles%\Synergy\synergyc.exe

5. Select "Allow the connection if it is secure"
6. Select Customize

Select "Require the connection to be encrypted"
Select OK, then Next

7.      Accept all defaults, name the Rule "Synergy" and finish
8.      From the list of Inbound Rules: Right-click the rule and select Enable Rule
9.      Repeat Steps 1 – 8 for Outbound Rule

Enforcing IPSec on DeviceB (Synergy Client)

1.      Repeat steps 1 – 9 above on Device B.

Congratulations! You've endured the ridiculous IPSec configuration and enforcement procedure! Make sure to thank Microsoft next time you see them.

Remember: Once you've successfully configured IPSec and Synergy stops working days later, we'll need to check a few things:

Is IPSec operational?
Did either device IP change?
Is the IPSec Policy Service running?
Is Synergy operational?

Walking through this process is a great way to securely "band-aid" an insecure app, however, I believe it also highlights the limitations of enforcing IPSec at the OS level.

Enjoy your (now secure) app.

Posted by Clint L. on July 12, 2011 at 7:33 am

Welcome to CentralMNIT!

	or login
	or login

Don't have a Grouply ID? Sign up

We use Grouply ID for authentication. What is a Grouply ID?

	or
	or

Connect with Facebook