Articles from August 2017 on PowerShell.org - Welcome Automaters!

PowerShell 2.0 deprecation

Fri, 25 Aug 2017 10:29:17 +0000

PowerShell 2.0 is being deprecated - see the PowerShell Team blog for full details

#PSBlogWeek is Back!

Wed, 23 Aug 2017 17:49:39 +0000

I’ve decided to bring #PSBlogWeek back! Brush off those PowerShell blogs and grease up those typing fingers….wait..don’t do that but at least stretch a little bit. If you’d like to write a great article on PowerShell on your blog to help contribute great content and get yourself some notoriety, #PSBlogWeek is how it’s done.
For full details, head over to my blog where I’ve outlined everything or head directly over to psblogweek.com for full details!

Using PowerShell, Azure Automation, and OMS – Part III

Tue, 08 Aug 2017 14:00:43 +0000

It’s been a long road, but we’re almost there! A couple of weeks ago we looked at how we can create an Azure Automation Account and add our own custom modules to the solution to be used in Azure Automation. Last week, we took a deeper dive into configuring a runbook to take in webhook data from an alert using Microsoft’s Operations Management Suite. Then we looked into the data itself to see how we can leverage it against our runbook to fix problems for us on the fly.
This week, we’re going to modify an existing function to use that webhook data directly.
Building on Webhook Data
We could actually build our logic directly into the runbook to parse the webhook data and then pass the formatted information to our function that we’ve made available in Azure. But I prefer to keep my runbooks as simple as possible and do the heavy lifting in my function. This makes the runbook look a little bit cleaner, and allows me to minimize my code management a little more. Also, Azure Automation Runbooks, as of this writing, don’t play nicely with parameter sets in them, so I might as well pass my data along to a command that does.
Originally, I had built a one-liner that allowed me to create an NSG rule on the fly to block and incoming traffic from a specific IPAddress. It was a fairly simple command. But today, we’re going to make it a little more robust, and give it the ability to use webhook data. Here’s my original code:

Function Set-AzureRmNSGMaliciousRule { [cmdletbinding()] Param( [Parameter(Mandatory=$true)][string]$ComputerName, [Parameter(Mandatory=$true)][string]$IPAddress ) $ResGroup = (Get-AzureRmResource).where({$PSItem.Name -eq $Sys}) $VM = Get-AzureRmVM -ResourceGroupName $ResGroup.ResourceGroupName -Name $Sys $VmNsg = (Get-AzureRmNetworkSecurityGroup -ResourceGroupName $VM.ResourceGroupName).where({$PSItem.NetworkInterfaces.Id -eq $VM.NetworkProfile.NetworkInterfaces.Id}) $Priority = ($VmNsg.SecurityRules) | Where-Object -Property Priority -LT 200 | Select-Object -Last 1 If ($Priority -eq $null){ $Pri = 100 } Else { $Pri = ($Priority + 1) } $Name = ('BlockedIP_' + $IPAddress) $NSGArgs = @{ Name = $Name Description = ('Malicious traffic from ' + $IPAddress) Protocol = '*' SourcePortRange = '*' DestinationPortRange = '*' SourceAddressPrefix = $IPAddress DestinationAddressPrefix = '*' Access = 'Deny' Direction = 'Inbound' Priority = $Pri } $VmNsg | Add-AzureRmNetworkSecurityRuleConfig @NSGArgs | Set-AzureRmNetworkSecurityGroup }I want to keep my mandatory parameters for my original one-liner solution in-case I need to do something tactically. So we’ll go ahead and split the parameters for on-prem vs. webhook into different parameter sets. As webhook data is formatted as a JSON object, we’ll need to specify the data type for the WebhookData parameter as object.

Param( [Parameter(ParameterSetName='ConsoleInput')][string]$ComputerName, [Parameter(ParameterSetName='ConsoleInput')][string]$MaliciousIP, [Parameter(ParameterSetName='WebhookInput")][object]$WebhookData )Now, we’re going to add some logic to parse out the data that we’re looking to use:

If($PSCmdlet.ParameterSetName -eq 'WebhookInput'){ $SearchResults = (ConvertFrom-Json $WebhookData.RequestBody).SearchResults.value Write-Output ("Target computer is " + $SearchResults.Computer) Write-Output ("Malicious IP is " + $SearchResults.RemoteIP) $ComputerName = (($SearchResults.Computer).split(' ') | Select-Object -First 1) $MaliciousIP = (($SearchResults.RemoteIP).split(' ') | Select-Object -First 1) } If ($ComputerName -like "*.*"){ $Sys = $ComputerName.Split('.') | Select-Object -First 1 } Else { $Sys = $ComputerName }You’ll notice that I’m doing some string formatting with our data here. Webhook data can concatenate multiple alerts together and separate the array by using spaces, so we’re splitting that up and grabbing the first entry for each input we need. The additional splitting on the ComputerName is to accomodate for systems that are domain joined, as Azure isn’t necessarily aware of a system’s FQDN. Mind you, this is a rough example, and continuously growing; So as my use cases evolve, so will my code.
Now that we have our data formatted, we can update our module and upload it to our Azure Automation Account using the same process outlined in Part I, but with the -Force parameter added so we can overwrite the existing instance.

Param( [Parameter(Mandatory=$true)] [object]$WebhookData ) $connectionName = "AzureRunAsConnection" try { # Get the connection "AzureRunAsConnection " $servicePrincipalConnection=Get-AutomationConnection -Name $connectionName "Logging in to Azure..." Add-AzureRmAccount -ServicePrincipal-TenantId $servicePrincipalConnection.TenantId -ApplicationId $servicePrincipalConnection.ApplicationId-CertificateThumbprint $servicePrincipalConnection.CertificateThumbprint } catch { if (!$servicePrincipalConnection) { $ErrorMessage = "Connection $connectionName not found." throw $ErrorMessage } else{ Write-Error -Message $_.Exception throw $_.Exception } } Set-AzureRmNSGMaliciousRule -WebHookData $WebhookDataNow, in a few minutes, our runbook should trigger and we can monitor the result.

$Job = (Get-AzureRmAutomationJob -RunbookName WebhookNSGRule -ResourceGroupName $AutoAcct.ResourceGroupName -AutomationAccountName $AutoAcct.AutomationAccountName) $Job[0] | Select-Object -Property * ResourceGroupName : mms-eus AutomationAccountName : testautoaccteastus2 JobId : 339601cd-14e9-4002-8fcd-7d2008726445 CreationTime : 7/24/2017 10:11:43 AM -04:00 Status : Completed StatusDetails : StartTime : 7/24/2017 10:12:21 AM -04:00 EndTime : 7/24/2017 10:13:31 AM -04:00 Exception : LastModifiedTime : 7/24/2017 10:13:31 AM -04:00 LastStatusModifiedTime : 1/1/0001 12:00:00 AM +00:00 JobParameters : {} RunbookName : WebhookNSGRule HybridWorker : StartedBy :We can start digging into the outputs of the runbook after completion to gather a little more data.

$Job = (Get-AzureRmAutomationJob -RunbookName WebhookNSGRule -ResourceGroupName $AutoAcct.ResourceGroupName -AutomationAccountName $AutoAcct.AutomationAccountName) $JobOut = Get-AzureRmAutomationJobOutput -Id $Job[0].JobId -ResourceGroupName $AutoAcct.ResourceGroupName -AutomationAccountName $AutoAcct.AutomationAccountName ForEach ($JobCheck in $JobOut){ $JobCheck.Summary } PS C:\WINDOWS\system32> ForEach ($JobCheck in $JobOut){ $JobCheck.Summary } Logging in to Azure... Target computer is server1 server1 server1 Malicious IP is 183.129.160.229 183.129.160.229 Target system is server1 Incoming MaliciousIP is 183.129.160.229 Creating rule...And now if I check against my system, we will see that OMS is auto-generating rules for us!

$VM = (Get-AzureRmResource).where({$PSItem.Name -like 'server1'}) $Machine = Get-AzureRmVM -ResourceGroupName $VM[0].ResourceGroupName -Name $VM[0].Name $NSG = (Get-AzureRmNetworkSecurityGroup -ResourceGroupName $Machine.ResourceGroupName).where({$PSItem.NetworkInterfaces.Id -eq $Machine.NetworkProfile.NetworkInterfaces.Id}) (Get-AzureRmNetworkSecurityRuleConfig -NetworkSecurityGroup $NSG[0]).where({$PSItem.Name -like "BlockedIP_*"}) Name : BlockedIP_206.190.36.45 Id : /subscriptions/f2007bbf-f802-4a47-9336-cf7c6b89b378/resourceGroups/test/providers/Microsoft.Network/networkSecurityGroups/server1nsgeus2domain Controller/securityRules/BlockedIP_206.190.36.45 Etag : W/"279e0fee-05c6-43ef-b897-19f927dd9a40" ProvisioningState : Succeeded Description : Auto-Generated rule - OMS detected malicious traffic from 206.190.36.45 Protocol : * SourcePortRange : * DestinationPortRange : * SourceAddressPrefix : 206.190.36.45 DestinationAddressPrefix : * Access : Deny Priority : 100 Direction : Inbound Name : BlockedIP_183.129.160.229 Id : /subscriptions/f2007bbf-f802-4a47-9336-cf7c6b89b378/resourceGroups/test/providers/Microsoft.Network/networkSecurityGroups/server1nsgeus2domain Controller/securityRules/BlockedIP_183.129.160.229 Etag : W/"279e0fee-05c6-43ef-b897-19f927dd9a40" ProvisioningState : Succeeded Description : Auto-Generated rule - OMS detected malicious traffic from 183.129.160.229 Protocol : * SourcePortRange : * DestinationPortRange : * SourceAddressPrefix : 183.129.160.229 DestinationAddressPrefix : * Access : Deny Priority : 101 Direction : InboundAfter letting my system go for about 24 hours, my OMS Alert triggered the runbook an additional five times. Each time generating an additional network security group rule in response to traffic that OMS had recognized as potentially malicious, and thus remediating my problem while I slept.

Using a monitoring tool that can tightly integrate with your automation tools is a necessity in the age of the Cloud. I hope you enjoyed this series and find it to be useful!
Part I - Azure Automation Account Creation and Adding Modules
Part II - Configuring Azure Automation Runbooks And Understanding Webhook Data
Part III - Utilizing Webhook Data in Functions and Validate Results

]]>

Summit agenda process

Tue, 08 Aug 2017 11:31:35 +0000

There’s been a lot of discussion on the Summit Slack channel around people proposing sessions for the 2018 Summit. I thought an explanation of how we put the agenda together would be useful for anyone thinking about submitting sessions.

First off though – if you’re thinking about submitting a session for the 2018 Summit then JUST DO IT! We are reserving a number of sessions for new speakers, as we always do. One of our goals for the Summit is to nurture the next generation of speakers. What better way to learn to speak about PowerShell than in front of the world’s greatest PowerShell audience. There is a balancing act between nurturing new speakers and having “big name” established speakers that we know will help draw an audience to the Summit.

The call for topics -https://powershell.org/2017/08/01/76318/

explains what we’re looking for and the mechanics of submitting a session. This year it’s easier than ever and the site we are using facilitates two-way communication with the potential speaker so that we can help them fine tune their proposal.

Once you’ve submitted the proposal we get an email containing the title and the text. Within a few days (at most) you’ll start to get feedback even if it’s just a thank you for submitting if there’s nothing we think should be changed. We may start an extended dialog depending on the submission and what we actually need.

Well before we open the call for topics we’ll have decided the structure of the Summit – the 2018 structure was done immediately after the 2017 Summit! I’m not giving full details at this stage but we’ll have a mixture of standard 45-minute sessions and double length sessions. The exact mix will depend on the sessions that are submitted. That structure tells me how many sessions I need. From that number, I’ll subtract those that the PowerShell team will use and the time we need for the Community Lightning Demos (yes, they are returning in 2018) and any other activities. That gives me the number of sessions I need.

A second consideration is budget. We’d love to have each session done by a separate speaker but that costs the Summit in terms of free admission, food etc. So, we have a budget which constrains the number of speakers we can sensibly accommodate without making the Summit too expensive for attendees. Again, this is a balancing act between diversity of speakers and the cost to attendees.

Having determined the number of speakers and the number of sessions required I’ll start thinking about which topics will be of most interest in April 2018. We set the agenda in October 2017 so we’re guessing to a certain degree. We look for sessions that meet one or more of these criteria:

A currently hot topic

A new feature in PowerShell that attendees may not have had the time to investigate

A topic that is causing a lot of questions on the forums

A topic that we’ve not seen before

A new module – as long as the code is explained - that solves a problem or makes life easier

A deep dive into an aspect of the PowerShell language or engine

New techniques for using PowerShell

Best practices

DevOps – usually practical based “how I did X”

What I learned doing “Y” and how that helps you

How the session fits with other sessions we’re thinking of using

It’s a positive session. Session proposals that dwell on, and just enumerate, the shot-comings of a particular aspect of PowerShell are extremely unlike to be accepted. If you turn that round and show how to overcome those issues – that’s a positive session.

Do we think the speaker understands the topic well enough to present an authorative session? This is often base on the abstract of the proposal which is why we say it’s got to get our attention.

Is it a session that can be presented as the same time as the PowerShell team or other “big name” is speaking so we can balance attendees across the rooms.

Other criteria may apply depending on circumstances.

Once, we’ve got a number of sessions available we’ll start to circulate the details amongst the people helping put the agenda together asking for feedback on the session proposals. In some cases, this will become feedback to the proposer and we’ll work with the potential speaker to refine the proposal. This process has started.

When the call for topics has closed I’ll go through the proposed sessions and create a first pass of the agenda. This first pass is circulated to a small number of people who can comment, suggest alternative sessions, move sessions around and generally rework the agenda as required. When we’re happy we’ll notify the speakers and publish the agenda. If your sessions weren’t accepted we’ll let you know.

Then we keep our fingers crossed that we’ve got it right and people will want to attend the Summit based on the agenda.

2018 will be our biggest Summit ever so we need more speakers. The information in this – especially the criteria used when thinking about sessions – should help you put together a proposal that will catch our eye.

If you’re in the slightest doubt about whether to submit sessions – JUST DO IT. If you want to discuss ideas then leave a comment, email me or join the Summit Slack channel #speaking-ideas where you can get feedback from people in a similar situation.

You are the future of Summit and we need you to submit those proposals.

Hope to see you (speaking) at the 2018 Summit.

]]>

Using PowerShell, Azure Automation, and OMS – Part II

Tue, 01 Aug 2017 14:00:46 +0000

So last time we learned how to upload our custom modules into Azure Automation so we can start using them in Azure Automation Runbooks. This week we’re going to take a look at configuring a runbook to see what kind of data we can ingest from OMS Webhook data, and how we can leverage that data to pass into our functions.
Creating the Runbook Script
So first off, let’s talk about basic runbooks and running them against objects in Azure. As previously discussed, when your automation account is created, it creates with it an AzureRunAsAccount. This account is configured to act on behalf of the user that has access to the automation account and the runbooks in order to perform the runbook task. In order to leverage this account, you need to invoke it in the runbook itself. You can actually find an example of this snippet in the AzureAutomationTutorialScript runbook in your automation account.

$connectionName = "AzureRunAsConnection" try { # Get the connection "AzureRunAsConnection " $servicePrincipalConnection=Get-AutomationConnection -Name $connectionName "Logging in to Azure..." Add-AzureRmAccount -ServicePrincipal-TenantId $servicePrincipalConnection.TenantId -ApplicationId $servicePrincipalConnection.ApplicationId-CertificateThumbprint $servicePrincipalConnection.CertificateThumbprint } catch { if (!$servicePrincipalConnection) { $ErrorMessage = "Connection $connectionName not found." throw $ErrorMessage } else{ Write-Error -Message $_.Exception throw $_.Exception } }So now that we’ve got our opening snippet, we’ll add that into a new .ps1 script file in our preferred integrated scripting environment tool and get to work.
Now, in order to be able to ingest data from an OMS Alert, we need to be able to pass the data to our Azure Automation runbook. In order to do so, we only need to add a $WebHookData parameter to the runbook and specify the data type as object.

Param ( [Parameters()][object]$WebHookData )Now, we need to convert that data from a JSON object into something readable in our output. Webhook data is presented with three primary datasets - WebhookName, RequestHeader, and RequestBody. WebhookName, obviously is the name of the incoming webhook. RequestHeader is a hash table containing all of the header data for the incoming requestion. And finally, RequestBody is the body of the incoming request. This is where the data we want to parse will reside. Specifically, it will reside under the SearchResults property of the RequestHeader dataset.

$WebhookData.WebhookName $WebhookData.RequestHeader $WebhookData.RequestBodySo let’s configure our runbook to display the incoming data to examine what we have to play with.

$SearchResults = (ConvertFrom-Json $WebhookData.RequestBody).SearchResults.value $SearchResultsPublish the Runbook
Now, we’ll go ahead and save our script as a .ps1 file and upload it to our automation account with the Import-AzureRmAutomationRunbook cmdlet.

Import-AzureRmAutomationRunbook -Path 'C:\Scripts\Presentations\OMSAutomation\ExampleRunbookScript.ps1' -Name WebhookNSGRule -Type PowerShell -ResourceGroupName $AutoAcct.ResourceGroupName -AutomationAccountName $AutoAcct.AutomationAccountName -PublishedAnd now we can see our return.

And if we check through the UI, we can see a brand-new, shiny runbook sitting in our automation account! Now, we can configure a basic alert to monitor in OMS.
Create an Alert
For the purposes of this example, I’ve create a couple of virtual machines with network security group rules for HTTP:80 and RDP:3389 accepting connections from anywhere. I do not recommend doing this for a production virtual machine. /endDisclaimer
As you can well expect, these machines are throwing MaliciousIP traffic alerts in Operations Management Suite’s console:

So if we click on the MaliciousIP flag, it’ll take us to the Log Search screen. This includes the query data that we can use for the alert. However, you’ll want to clean up the query data a bit to generalize it. In this example, the query is specific to the country that is displayed in the given flag. But if we remove the country specific portion of the query, it’ll allow us to cast a wider net and get data on potentially malicious traffic from any given country.

Canned Query: MaliciousIP=* AND (RemoteIPCountry=* OR MaliciousIPCountry=*) AND (((Type=WireData AND Direction=Outbound) OR (Type=WindowsFirewall AND CommunicationDirection=SEND) OR (Type=CommonSecurityLog AND CommunicationDirection=Outbound)) OR (Type=W3CIISLog OR Type=DnsEvents OR (Type = WireData AND Direction!= Outbound) OR (Type=WindowsFirewall AND CommunicationDirection!=SEND) OR (Type = CommonSecurityLog AND CommunicationDirection!= Outbound))) (RemoteIPCountry="People's Republic of China" OR MaliciousIPCountry="People's Republic of China") Modified Query: MaliciousIP=* AND (RemoteIPCountry=* OR MaliciousIPCountry=*) AND (((Type=WireData AND Direction=Outbound) OR (Type=WindowsFirewall AND CommunicationDirection=SEND) OR (Type=CommonSecurityLog AND CommunicationDirection=Outbound)) OR (Type=W3CIISLog OR Type=DnsEvents OR (Type = WireData AND Direction!= Outbound) OR (Type=WindowsFirewall AND CommunicationDirection!=SEND) OR (Type = CommonSecurityLog AND CommunicationDirection!= Outbound)))
After testing our query to make sure it’s valid, we can now hit the alert button and configure the alert. Here you’ll need to give it an alert name, a schedule, and number of results before it triggers the alert. You’ll also want to select the Runbook option under actions and select the test runbook we created. Then we hit save, and wait for our alert to trigger and the runbook to fire.

And as you can see, I didn’t have to wait long:

Validate our Data
If we click on one of the completed instances, and navigate to the output blade, we can now see the data we’re receiving from our triggered alert. This particular data shows that inbound traffic from Colombia is attempting an RDP connection to my virtual machine. With the inbound IP Address and target system name, we now have enough data to be able to create a full-blown auto-remediation solution.

`Logging in to Azure… Environments Context

{[AzureCloud, AzureCloud], [AzureChinaCloud, AzureChinaCloud], [AzureUSGovernment, AzureUSGovernment]} Microsoft.Azur… Computer : server1 MG : 00000000-0000-0000-0000-000000000001 ManagementGroupName : AOI-cb0eefe8-b88f-47ce-ae91-dbc46df99751 SourceSystem : OpsManager TimeGenerated : 2017-07-21T12:17:37.45Z SessionStartTime : 2017-07-21T12:16:52Z SessionEndTime : 2017-07-21T12:16:52Z LocalIP : 10.119.192.10 LocalSubnet : 10.119.192.0/21 LocalMAC : 00-0d-3a-03-ea-a6 LocalPortNumber : 3389 RemoteIP : 200.35.53.121 RemoteMAC : 12-34-56-78-9a-bc RemotePortNumber : 4935 SessionID : 10.119.192.10_3389_200.35.53.121_4935_2184_2017-07-21T12:16:52.000Z SequenceNumber : 0 SessionState : Listen SentBytes : 20 ReceivedBytes : 40 TotalBytes : 60 ProtocolName : TCP IPVersion : IPv4 SentPackets : 1 ReceivedPackets : 2 Direction : Inbound ApplicationProtocol : RDP ProcessID : 888 ProcessName : C:\Windows\System32\svchost.exe ApplicationServiceName : ms-wbt-server LatencyMilliseconds : 116 LatencySamplingTimeStamp : 2017-07-21T12:16:52Z LatencySamplingFailureRate : 0.0% MaliciousIP : 200.35.53.121 IndicatorThreatType : Botnet Confidence : 75 Severity : 2 FirstReportedDateTime : 2017-07-20T20:10:32Z LastReportedDateTime : 2017-07-21T11:25:11.0661909Z IsActive : true ReportReferenceLink :https://interflowinternal.azure-api.net/api/reports/download/generic/webbot.json RemoteIPLongitude : -75.88 RemoteIPLatitude : 8.77 RemoteIPCountry : Colombia id : 149270bc-74fc-13d0-34a9-3fd665a457b2 Type : WireData __metadata : @{Type=WireData; TimeGenerated=2017-07-21T12:17:37.45Z} `It’s a long road, and we’re almost there! Next week, I’ll take you through my process of modifying my module to directly ingest webhook data, and how we can take our OMS queries and deploy them to other Operations Management Suite solutions using PowerShell. See you then!
Part I - Azure Automation Account Creation and Adding Modules
Part II - Configuring Azure Automation Runbooks And Understanding Webhook Data
Part III - Utilizing Webhook Data in Functions and Validate Results - Coming Soon!

]]>

PowerShell and DevOps Global Summit 2018 – Call for Topics

Tue, 01 Aug 2017 09:49:30 +0000

The PowerShell and DevOps Global Summit 2018 will be returning to the Meydenbauer center, Bellevue WA on 9-12 April 2018. PowerShell, and DevOps, experts from all over the world, including PowerShell team members, will once again join together to discuss and learn about maximizing PowerShell in the workplace in fast-paced, knowledge packed presentations. The Summit’s also the place to explore and further your knowledge of DevOps principles and practices in a Windows environment, make new connections, learn new techniques, and offer something to your peers and colleagues. If you want to share your PowerShell or DevOps expertise, then this is your official call to submit presentations for selection!

Topic Areas: What we are looking for

Articles from August 2017 on PowerShell.org - Welcome Automaters!

PowerShell 2.0 deprecation

#PSBlogWeek is Back!

Using PowerShell, Azure Automation, and OMS – Part III

Summit agenda process

Using PowerShell, Azure Automation, and OMS – Part II

PowerShell and DevOps Global Summit 2018 – Call for Topics

Topic Areas: What we are looking for

PowerShell + DevOps Global Summit Scholarship Program

Applying

Articles from August 2017 on PowerShell.org - Welcome Automaters!

PowerShell 2.0 deprecation

#PSBlogWeek is Back!

Using PowerShell, Azure Automation, and OMS – Part III

Summit agenda process

Using PowerShell, Azure Automation, and OMS – Part II

PowerShell and DevOps Global Summit 2018 – Call for Topics

Topic Areas: What we are looking for

What kind of sessions get selected?

How to submit abstracts of presentations

Presentation submission deadline: When you should send it by

When you will know you’ve been selected