Archive for October 2011

Installing Microsoft Forefront Threat Mitigation Gateway (TMG) into Amazon AWS   Leave a comment

By: Kevin Gilbert

To secure a website deployment in AWS, I wanted what every security conscious administrator wants: a firewall I can monitor, intrusion protection, and a reverse proxy that does web publishing. These requirements can be a challenge in a public cloud like AWS. Forefront’s Unified Acess Gateway (UAG) can be a great solution, but is too expensive and too much overkill for what I needed.  TMG offers the required features in a simpler solution.

 The challenge with installing TMG is that the installer locks down the network interfaces on the instance during installation. This security breaks the remote desktop (rdp) connection and makes the instance unreachable.

I tried everything to get around this problem. I tried the installation inside AWS and then inside a VPC. I tried using Team Viewer instead of Microsoft’s RDP. I tried building TMG locally using VMWARE and then uploaded the virtual machine into AWS.  I probably ran the installer fifty times with no luck.

Just as I was about to give up, a colleague found the solution in a forum that talked about doing a remote installation of TMG. I gave it a try and it worked!

HOW TO INSTALL TMG

  1. Make two instances: once named TMG-installer and one named TMG. Set up their security groups to allow you to RDP and for them to be able to RDP each other.

2. Using the TMG-installer as an RDP man-in-the-middle. In other words, remote into TMG Installer and use TMG-Installer to remote into TMG via TMG’s private IP address.

 

3. Using the RDP main-in-the-middle connection, run the TMG installer

4. Here’s the magic. During the installer, TMG locks down the instance network. If the installer is being ran through RDP, the RDP private IP address will be written into the TMG firewall and allowed. If you are connected via an elastic IP, the elastic IP won’t be written into the firewall because this is a public IP address. If you do the installer locally in vmware and then upload the virtual machine to AWS, it won’t work because because your local address is used. You must install TMG in AWS using the RDP main-in-the-middle so that the TMG-Installer’s private IP address is written into the TMG’s firewalled and allowed.

5. After TMG is installed, you need to open up RDP on the TMG instance to all networks. You’ll control who actually can RDP via the instance’s security group. You do this by opening the TMG console, clicking on the Firewall Policies branch, and in the right side of the screen selecting Edit System Policy. Within the system policies you will find a terminal services policy that you can open to all networks. The last step is to click on the Firewall Policies branch and add a new a firewall policy allowing all networks to RDP. Click apply.

 

6. You can terminate the TMG-installer instance because it is no longer needed. You’ll be able to RDP from anywhere that the TMG Instance’s security group allows.

Advertisements

Posted October 22, 2011 by cloudbusterspodcast in Uncategorized

Paetec GRC at 2011 Rochester Security Summit   Leave a comment

Jim Gran from Paetec talked at the October 2011 Rochester Security Summit about automation for IT governance, risk and compliance (Grc). Jim provided two underlining theme in his speech: By being compliant are you secure? Not necessarily; and to get corporate buy-in to security one must generate value or reduce cost rather then cram security down peoples throat.

In 2007 Paetec merged with US-L and became a public company. As a result of going public they needed to get compliance in place. First they needed to be sox compliant. To be successfully theymade self-assessment built into the culture intuitively.

Paetec targeted logical access: people can only access what they need, which is the concept of Least Privilege. Change management so managers know what changes are put into production. Privilege access management so that everyone isn’t an administrator all the time. Policy and standard development that explains why we do things certain ways. Foundational security items like antivirus and firewalls. Sdlc to manage the development of software in a way that includes a security review.

Paetec uses Oracle Identity Management, which allows for decertification of the access on a regular basis to make sure people still have only the access they need.  This saved money and lowered complexity because it didn’t need to be managed individually on every system. Also does separation of duty monitoring with this tool. Linked to HR so it sees when someone new is hired, job change, or let go.

Paetec uses BMC’s Remedy for change management. Remedy hooks Tripwire into the system which watches for unauthorized changes. When Tripwire sees a change, it checks for a change control document in Remedy. Management is notified if a change is made that doesn’t have a  change control document.

Paetec uses Centify and Oracle for single sign on across all systems. They also use this on their customer portal so that employees can log into the customer portal using their normal credentials.

Paetec used Cyberark for password vaulting. An individual normally doesn’t have escalated privileges to production systems. However, if they have been approved to make a change, the vault will give them a temporary password and then will change the password once the change period has ended. This automates the temporary privilege increase process while providing auditable logs about activities.

Paetec uses Symmantec Control Compliance Suite (CCS) to provide dashboards that automated compliance assessments on standards. Need to see how you are doing on PCI compliance? There is a dashboard for it. Paetec has added additional rules for internal audit metrics that they are interested in tracking too. Administrators like this because they get a dashboard that shows risk scores for each of their systems so they know where to focus their efforts.

Paetec uses RSA Envision and Archer EGRC for monitoring the security devices such as firewalls, antivirus, routers, etc. These products collect the logs, aggregates events across multiple devices, and can apply business logic.

Paetec received employee buy-in through newsletter, training, placards, and give aways. Jim’s belief is to let people know why you are doing the various security efforts. To focus the message on serving the employees. The employees own important aspects of security and you can’t do security without them.

 

Posted October 5, 2011 by cloudbusterspodcast in Uncategorized

Amazon AWS Storage Options   Leave a comment

By: Kevin Gilbert 

Amazon provides several AWS storage options. This can be confusing if you are new to AWS.

Instance Store – When  you start a new instance from an Amazon AMI template, it will launch in Instance Store storage. Instance Store Storage can be used for an instance’s root device. This provides a very cheap option because you only pay for the instance, not the root instance store. You can get better performance then the other options. However, the storage is not persistent. It uses ephermeral drives – if you terminate your instance the volumes are destroyed and your data is lost. Also, root devices are capped at only 10GB, but you can have a 1.6TB data volume.

Elastic Block Storage – Elastic Block Storage is an option for instances. It provides faster boot time. If you terminate an instance the EBS volume detaches and remains available to reattach to another instance. Volume sizes are only 1TB, but you can use software RAID or span drive letters across multiple volumes so that’s not a big deal. EBS holds many advances compared to Instance Store however EBS is more expensive. Also, some people are concerned about EBS because they were burned during the April 2011 EBS outage which took EBS offline for some customers.

S3 –Simple Storage Service is large amounts of cheap and relatively slower disk (but not slow enough that you’ll probably notice). The storage is normally accessed through a web brower but can also be accessed through command lines. S3 doesn’t need to be mounted or connected to an instance in order to be viewed. There are some third party tools that will mount S3 as a drive letter and then do the command line operations in the back ground. Individual objects can be up to 5 terabytes in size. For high reliability, data is stored in multiple data centers within your region. Unlike Instance Store and EBS, an instance’s root drives can not run from S3. While an instances’s data drives can be in S3 by using some third party tools that mount S3 storage as drive letters, that really isn’t the intention of S3. The intention of S3 is for static data such as backups and web pages.

Reduced Redundency Storage – RRS is S3 storage with a lower SLA. It provides 99.99% uptime instead of 99.9999999999%. While S3 can survive a two datacenter outage, RRS can only survive a single data center outage. To select RRS it is a simple check box when uploading files or a checkbox within the file’s properties. RRS is significantly cheaper then the normal S3 storage.

Now that you’ve seen the various storage that is available in AWS, you can get creative on how you use it. For example, some will  boot an instance built on Instance store (because it is cheaper) and as part of the boot process, copy their data that they’ve backed up in S3 to the Instance Store volume. Therefore they don’t care that instance store is not persistent because their current data is available in S3. Others choose to run databases within EBS because they don’t want to lose their data should their instance get terminated.

Posted October 1, 2011 by cloudbusterspodcast in Uncategorized