Home » deployment

Tag: deployment

Lesson Learned From Enabling AWS GuardDuty Across Multi Accounts and All Regions

Summary

AWS Guard Duty offers an enhanced security scan of all AWS services and how to better protect them based on your usage patters and well known vulnerabilities.

General Observations

  1. GD Analyzes VPC Flow Logs, AWS CloudTrail events and AWS DNS logs.
  2. Console Notification for new findings – as they are analysed and discovered.
  3. Notification frequency of new findings (to CloudWatch) every 5 minutes.
  4. Notification configurable frequency of 15ins, 60mins or 6 hours (to CloudWatch) for updates to existing findings (counts for the same finding / vulnerability)
  5. 1000 member accounts supported.
  6. Definitions for trusted IPs and cloudwatch notification time / period are set and enforced at master only to flow down to sub accounts.
  7. Max 2000 trusted IPs in single list.
  8. Max 250,000 threat IPs in single list.
  9. Master accounts cannot be member of any other account.
  10. Sub accounts can view findings related to their own account, but are unable to archive them. Master account can view all findings for all accounts and archive them, which removes them from the sub accounts findings view also.
  11. Guard Duty can be suspended on master and on slave accounts (from master) slaves can manage and re-enable suspension on themselves only.
  12. GD detectors are region specific and need to be enabled on a per region basis including any regional master/sub collector services
    • Regional Master accounts are required for aggregation from sub accounts in the same region
      • e.g you cannot have one master Guard Duty collector in EU-WEST-1 and have AWS EU-WEST-2 regions send their Guard Duty findings to it.
      • You must have a Guard Duty master enabled in the EU-WEST-2 region and invite the sub account again for every region you want to enable Guard Duty
  13. In master, sub account the trusted and threat lists are applied at the master as a single list only.
  14. Log data from CloudTrail. VPC DNS are all encrypted when in transit to GuardDuty, after analysis the logs are discarded.
  15. Immediate analysis of flow logs starts from the service being enabled, it consumes events directly as a duplicate stream of flow logs. This does not modify any existing flow log configurations.
  16. DNS analysis will only work if using AWS DNS Resolvers. Other DNS services will not be ‘captured’ or analysed.

 

Rollout

AWS documentation points to a Cloud Formation template for enabling Guard Duty. Its only available as a template in us-east-1 region, so be sure to select this region.

CloudFormation

If you just want to setup Guard Duty services in your accounts via an AWS CloudForation StackSet – use this AWS Provided CT template ‘Enable Amazon GuardDuty’

https://console.aws.amazon.com/cloudformation/stacksets/home?region=us-east-1#/stacksets/new

Caveats

If you dont specify a master ID. The CF template simply enables GuardDuty in the stackset accounts and regions only.

You have to manually invite all your ‘sub accounts’ from all regions first before this stackset will work with the ‘masterId’ (as each sub account has to have an invitation waiting from the master)

CF Message:

The Amazon GuardDuty master account ID. If you specify the master account ID, this stack set creates a GuardDuty detector in each specified account and accepts the GuardDuty membership invitation sent to each of the specified accounts by this master account. If this value is specified, before you can create this stack set, all accounts in all regions to which this stack set template is to be applied must already have an invitation from this master GuardDuty account and must NOT have a detector already created.

Python

If you want a full cross account multi region master subscriber setup, from scratch – use the AWS provided python script.]=]#=[

It creates a master detector in your specified master account, and subscribes each sub account and even every sub account region to the master, accepts the invite and links the accounts.

The script can even be run from an unrelated ‘build or deploy’ account. Perfect!

https://github.com/aws-samples/amazon-guardduty-multiaccount-scripts

AWS Support recommended using the python script as the primary deployment mechanism.

There are no currently no ansible modules for AWS GuardDuty

Python Script Notes

The disable script breaks a little but a fix is provided in the issues list

The enable script messages the root account email for each account and for EVERY region that is listed to be ‘enabled’ so for a large scale deployment many multiple emails may be delivered!

Upgrading to Citrix Receiver 4.2

We have a number of functional expectations to test prior to Upgrading to Citrix Receiver 4.2. It is imperative that things as simple as ‘desktop shortcuts’, appropriate start menu integration and XenApp session sharing work to keep the end users happy and prevent the “same ole service calls being logged again”.

Examples:

  1. A 100% dynamic client start menu (locally or in the XA/XD sessions – built based on the apps published to them) and support for XenApp6.5 session sharing
  2. Ideally one storefront “store” and one receiver version if possible deployed across the organisation (if support for all features exists)
  3. We would prefer not to rely on web interface servers if it can be helped.
  4. Simple desktop and start menu shortcut management with filtering based on device or platform (presently we use separate web interface sites)
  5. Support for File type association and Prelaunch.

Nice to haves / Things to test.

Company Laptop & desktops: Selective or filtered apps on the clients desktops (to avoid conflict with citrix published apps like Citrix outlook vs local outlook) to XenApp 4.5, XenApp 6.5 and XenDesktop 7.6.

Citrix desktop: End user ‘refresh’ on the XenApp desktop (without logging off)

Issues Encountered with Citrix Receiver 4.2

Session Sharing still broken: Whilst the configuration is not officially supported running the receiver via a published XA6.5 desktop and launching a Citrix app would start a brand new session even launching it on the same server.

Receiver Disconnects: During opening, launching or refreshing of the receiver (inside a Citrix session) the local Citrix session would disconnect http://support.citrix.com/article/CTX136339

Shortcut refresh slow: In selfservicemode=false or with user subscriptions disabled (effectively making all apps mandatory) the initial log into receiver would deploy the apps to the start menu under 2 minutes (which is slow compared to pnagent and depending on how many apps were available for your login) following this Citrix article we also set the InitialRefreshMinMs and MaxMs to 1 http://support.citrix.com/article/CTX200337

 

Receiver not started automatically for new users logging onto the workstation:

We had to set a shortcut in the users startup folder or regrun keys for the receiver to open.

 

Receiver Installation:

We decided against recommending the selfservicemode=false option in combination with receiver deployments script to end user devices (as its much more difficult to reverse) rather we’d recommend to use the group policy ADM that comes with the new client to manage the selfservicemode so you can easily change it later if desired.

GPO Location: C:\Program Files(x86)\Citrix\ICA Client\Configuration\icaclient.adm

Kiosk Users: if you have a generic desktop login and people each use their own credentials just for citrix its best to just use storefrontweb as the receiver shortcut deployment to the start menu and even in the receiver window constantly got confused between the different logged on users and was definitely too slow to be a usable solution. Possibly this could be fixed with the GPO ‘Remove Apps on Logoff’

 

Storefront Filtering is per store: If we filtered an application (by its keyword: description) it was effectively hidden from all parts of that store including

  1. Receiver
  2. Storefront web
  3. Legacy Config xml receiver
  4. Regardless of any other store settings (new subscriptions enabled or disabled or the app set to mandatory)

See here how to configure Storefront Filtering

 

Mandatory Apps Ignore Start Menu Directory:

Via GPO we tried forcing the Start Menu directory (different to what the app has published) which worked for all applications except some instances of mandatory apps refused to move. This was most obvious when the user had already synced their apps to the start menu then the start menu directory was forced via GPO.

XA6.5 Published App Start Menu Folder property name is ignored:

Receiver only uses the “Client Application folder” varilable for the shortcut publication.

This makes more sense however when looking at application publication in the Citrix Studio for XenApp 7.6.

Changing the Start menu Path left all the old shortcuts initially unusable:

Changing the start menu path after a user had already sync with the store resulted in all the shortcuts being completely recreated under the new folder hierarchy, whilst the old path was left (during the sync) intact, but unusable.

Running the old shortcuts resulted in the fun message:

After the initial sync completed again (took over 2-3 minutes as I had heaps of published shortcuts) the old folder ‘Citrix’ was eventually removed.

Desktop shortcuts delivered in folders: If an application is published in the XA6.5 console with a Client Application folder, and the app is published to the desktop as well the Client application folder is also created.

Shortcuts doubled up: If there was an application with the same name locally as remote, we would end up with 2 – making it confusing for the end users – Citrix’s solution to this is the “keyword: Prefer” in the application description – which we found continued to only launch the Citrix application.

See here for an excellent explanation of the supported Storefront and Receiver Keywords: http://www.martijnhs.com/2014/05/08/citrix-storefront-keywords-explained/

 

 

Summary

The deployment method we have had most success with (so far) has been:

  • The Citrix Receiver 4.2 packaged and deployed simply with “CitrixReceiver4.2.100.exe /includeSSON” (no other commands or calls)
  • The actual storefront Store configured via GPO

  • The SSO option enabled via GPO

  • The storefront site added to trusted or intranet sites
  • The SSO options/passthrough setting enabled in the storefront servers / site
  •  We enabled The Shortcut managment options to stop confusion for end users (all citrix apps delivered in a start menu sub folder)

  • We also disabled the selfservicemode via gpo rather than forcing it during the installation in the 4.2 receiver.

  • We forced the receiver to connect to the store asap by: [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\Dazzle]

“InitialRefreshMinMs”=”1”

“InitialRefreshMaxMs”=”1”

  • We placed the receiver in the Startup Folder of the local machine, so it would launch automatically

This configuration would also mean that ALL the application shortcut are all delivered to the users start menu, but people connecting via the ‘storefront web’ page can still have subscriptions enabled so they don’t see things like the accessories published apps ‘calc, or snipping tool or magnifier etc’ from the ‘storefront web’.

*Additional Note: If upgrading existing users devices, you may find it useful to set the legacy web interface to delete / remove all shortcuts on logoff / exit –  that way you can be 99% sure that there there should be no remnants of the legacy clients shortcuts on the desktop or star menu etc for the end users

Windows Desktops / Clients

The 4.2 Citrix receiver is an absolute must have for 3D Pro / HDX graphics, the improvements are numerous for graphics display and the smoothness of 3D apps. When deploying 4.2 locally with self service it grants the users that little bit of flexibility and control over their own start menu and the customisable GPO can help you easily change your mind later should the need arise.

XenApp

On a XenApp published desktop where session sharing is still broken with Receiver 4.2 we are going to stick with Citrix Receiver 3.4 enterprise Cumulative Update 4 and have it pointing to the storefront legacy config.xml file for now – which delivers the full dynamic Citrix start menu and still supports session sharing.

It is incredibly frustrating as an integrator and even as an end user to see ‘similar’ issues that Citrix has previously fixed in prior versions of their ICA Client reappearing all over again in the new Receiver, it certainly does nothing for their reputation.

We are very interested to hear how other people are managing their upgrades and end user shotcuts. Does anyone have a simpler, quicker, inexpensive and truly dynamic way to manage end user shortcuts whilst still conglomerating the users application experience from all their platforms (i.e local client apps, Citrix apps, Microsoft SCCM, VMWare thinapp and Microsoft App-V to name a few) and still support things like true session sharing and access gateway filtering??? Drop us a line.

Also please see this excellent article to address or workaround some of the problems described above.