Security

Number of industrial control systems on the internet is lower then in 2020…but still far from zero, (Wed, May 12th)

Leave a comment
This post was originally published on this site

With the recent ransomware attack that impacted operation of one of the major US pipelines[1], I thought it might be a good time to revisit the old topic of internet-connected industrial systems. Since operational technologies are generally used to support/control processes that directly impact the physical world, the danger of successful attacks on them should be self-evident, as should the need to protect them.

While it is true that not all ICS, Industrial IoT devices and other similar systems are made equal, since some of them support highly critical processes, while others only control minor functions such as central heating in private residences, compromise of any of them would certainly not be desirable. One would therefore hope that – if nothing else – most such systems would not be directly accessible from the internet, especially since they are usually controlled with the help of specialized industrial protocols, that lack any kind of inbuilt security controls or even authentication and authorization checks.

As you have probably guessed, however, the number of internet-connected industrial systems is unfortunately much higher than one might wish.

Since (especially) many of the Industrial IoT devices are controlled only through web interfaces, it would be difficult to count all such systems on the internet. We may, however, at least look at the number of the public IPs where devices that communicate using different industrial protocols recognized by Shodan and Censys are/were accessible.

 

At the time of writing, Shodan detects approximately 80.8k public IP addresses where some sort of industrial system is accessible[2], while Censys sees about 74.2k such IPs[3]. Although this is hardly a “good” result, the numbers are significantly lower then they were 12 months ago, as the following chart based on data collected from Shodan using TriOp[4] shows.

While the overall situation seems to be slowly getting better, it is still far from ideal.

Although it would probably be too optimistic to expect it to improve significantly in the near future, perhaps the attention that the recent attacks on the pipeline and a water treatment plant in Florida[5] have gotten will have some positive effect in this area, as it may provide an impulse for organizations to at least check whether some their public IPs don’t allow direct access to their critical OT systems to anyone connected to the internet. Since such a check could be as simple as an nmap scan of relevant public IP ranges, it wouldn’t necessarily even cost that much in terms of time.

We can, however, only hope…

[1] https://www.bleepingcomputer.com/news/security/largest-us-pipeline-shuts-down-operations-after-ransomware-attack/
[2] https://www.shodan.io/search?query=tag%3Aics
[3] https://censys.io/ipv4?q=tags.raw%3A+%22scada%22
[4] https://isc.sans.edu/diary/27034
[5] https://www.bleepingcomputer.com/news/security/hackers-tried-poisoning-town-after-breaching-its-water-facility/

———–
Jan Kopriva
@jk0pr
Alef Nula

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Security

Microsoft May 2021 Patch Tuesday, (Tue, May 11th)

Leave a comment
This post was originally published on this site

This month we got patches for 55 vulnerabilities. Of these, 4 are critical, 3 were previously disclosed and none is being exploited according to Microsoft.

One of the critical vulnerabilities which requires special attention this month is a remote code execution (RCE) on HTTP Protocol Stack (CVE-2021-31166). An unauthenticated attacker could send a specially crafted packet to a targeted server utilizing the HTTP Protocol Stack (http.sys) to process packets. This vulnerability requires no user authentication or interaction – thus, it is considered a wormable vulnerability. The vulnerability affects different versions of Windows 10, Windows Server 2004 and Windows Server 20H2 and has a CVSS score of 9.8.

A second critical vulnerabilities addressed this month is RCE affecing Hyper-V on virtually all supported Windows versions (CVE-2021-28476). Microsoft's advisory states that the issue a guest VM to force the Hyper-V host's kernel to read from an arbitrary, potentially invalid address. In most circumstances, this would result in a denial of service of the Hyper-V host due to reading an unmapped address, but it may also could lead to other types of compromise of the Hyper-V host's security. The CVSS for this vulnerability is 9.9. 

The other two critical vulnerabilities are a RCE on OLE Automation (CVE-2021-31194) associated with a CVSS of 7.50 and a Scripting Engine Memory Corruption Vulnerability (CVE-2021-26419) affecting Internet Explorer 11 with a CVSS of 6.40. None of four critical vulnerabilities was previously disclosed. 

See my dashboard for a more detailed breakout: (https://patchtuesdaydashboard.com).

 

Description
CVE Disclosed Exploited Exploitability (old versions) current version Severity CVSS Base (AVG) CVSS Temporal (AVG)
.NET and Visual Studio Elevation of Privilege Vulnerability
%%cve:2021-31204%% Yes No Less Likely Less Likely Important 7.3 6.4
Common Utilities Remote Code Execution Vulnerability
%%cve:2021-31200%% Yes No Less Likely Less Likely Important 7.2 6.7
Dynamics Finance and Operations Cross-site Scripting Vulnerability
%%cve:2021-28461%% No No Less Likely Less Likely Important 6.1 5.5
HTTP Protocol Stack Remote Code Execution Vulnerability
%%cve:2021-31166%% No No More Likely More Likely Critical 9.8 8.5
Hyper-V Remote Code Execution Vulnerability
%%cve:2021-28476%% No No Less Likely Less Likely Critical 9.9 8.6
Microsoft Accessibility Insights for Web Information Disclosure Vulnerability
%%cve:2021-31936%% No No Less Likely Less Likely Important 7.4 6.7
Microsoft Bluetooth Driver Spoofing Vulnerability
%%cve:2021-31182%% No No Less Likely Less Likely Important 7.1 6.2
Microsoft Excel Information Disclosure Vulnerability
%%cve:2021-31174%% No No Less Likely Less Likely Important 5.5 4.8
Microsoft Exchange Server Remote Code Execution Vulnerability
%%cve:2021-31195%% No No Less Likely Less Likely Important 6.5 5.7
%%cve:2021-31198%% No No Less Likely Less Likely Important 7.8 6.8
Microsoft Exchange Server Security Feature Bypass Vulnerability
%%cve:2021-31207%% Yes No Less Likely Less Likely Moderate 6.6 5.8
Microsoft Exchange Server Spoofing Vulnerability
%%cve:2021-31209%% No No Less Likely Less Likely Important 6.5 5.7
Microsoft Jet Red Database Engine and Access Connectivity Engine Remote Code Execution Vulnerability
%%cve:2021-28455%% No No Less Likely Less Likely Important 8.8 7.7
Microsoft Office Graphics Remote Code Execution Vulnerability
%%cve:2021-31180%% No No Less Likely Less Likely Important 7.8 6.8
Microsoft Office Information Disclosure Vulnerability
%%cve:2021-31178%% No No Less Likely Less Likely Important 5.5 4.8
Microsoft Office Remote Code Execution Vulnerability
%%cve:2021-31175%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-31176%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-31177%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-31179%% No No Less Likely Less Likely Important 7.8 6.8
Microsoft SharePoint Information Disclosure Vulnerability
%%cve:2021-31171%% No No Less Likely Less Likely Important 4.1 3.6
Microsoft SharePoint Remote Code Execution Vulnerability
%%cve:2021-31181%% No No More Likely More Likely Important 8.8 7.7
Microsoft SharePoint Server Information Disclosure Vulnerability
%%cve:2021-31173%% No No Less Likely Less Likely Important 5.3 4.8
Microsoft SharePoint Server Remote Code Execution Vulnerability
%%cve:2021-28474%% No No More Likely More Likely Important 8.8 7.7
Microsoft SharePoint Spoofing Vulnerability
%%cve:2021-31172%% No No Less Likely Less Likely Important 7.1 6.2
%%cve:2021-28478%% No No Less Likely Less Likely Important 7.6 6.6
%%cve:2021-26418%% No No Less Likely Less Likely Important 4.6 4.0
Microsoft Windows Infrared Data Association (IrDA) Information Disclosure Vulnerability
%%cve:2021-31184%% No No Less Likely Less Likely Important 5.5 4.8
OLE Automation Remote Code Execution Vulnerability
%%cve:2021-31194%% No No Less Likely Less Likely Critical 8.8 7.7
Scripting Engine Memory Corruption Vulnerability
%%cve:2021-26419%% No No More Likely More Likely Critical 6.4 5.8
Skype for Business and Lync Remote Code Execution Vulnerability
%%cve:2021-26422%% No No Less Likely Less Likely Important 7.2 6.3
Skype for Business and Lync Spoofing Vulnerability
%%cve:2021-26421%% No No Less Likely Less Likely Important 6.5 5.7
Visual Studio Code Remote Code Execution Vulnerability
%%cve:2021-31211%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-31214%% No No Less Likely Less Likely Important 7.8 6.8
Visual Studio Code Remote Containers Extension Remote Code Execution Vulnerability
%%cve:2021-31213%% No No Less Likely Less Likely Important 7.8 6.8
Visual Studio Remote Code Execution Vulnerability
%%cve:2021-27068%% No No Less Likely Less Likely Important 8.8 7.7
Web Media Extensions Remote Code Execution Vulnerability
%%cve:2021-28465%% No No Less Likely Less Likely Important 7.8 6.8
Windows CSC Service Information Disclosure Vulnerability
%%cve:2021-28479%% No No Less Likely Less Likely Important 5.5 4.8
Windows Container Isolation FS Filter Driver Elevation of Privilege Vulnerability
%%cve:2021-31190%% No No Less Likely Less Likely Important 7.8 6.8
Windows Container Manager Service Elevation of Privilege Vulnerability
%%cve:2021-31165%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-31167%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-31168%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-31169%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-31208%% No No Less Likely Less Likely Important 7.8 6.8
Windows Desktop Bridge Denial of Service Vulnerability
%%cve:2021-31185%% No No Less Likely Less Likely Important 5.5 4.8
Windows Graphics Component Elevation of Privilege Vulnerability
%%cve:2021-31170%% No No More Likely More Likely Important 7.8 6.8
%%cve:2021-31188%% No No More Likely More Likely Important 7.8 6.8
Windows Media Foundation Core Remote Code Execution Vulnerability
%%cve:2021-31192%% No No Less Likely Less Likely Important 7.3 6.4
Windows Projected File System FS Filter Driver Information Disclosure Vulnerability
%%cve:2021-31191%% No No Less Likely Less Likely Important 5.5 4.8
Windows Remote Desktop Protocol (RDP) Information Disclosure Vulnerability
%%cve:2021-31186%% No No Less Likely Less Likely Important 7.4 6.4
Windows SMB Client Security Feature Bypass Vulnerability
%%cve:2021-31205%% No No Less Likely Less Likely Important 4.3 3.8
Windows SSDP Service Elevation of Privilege Vulnerability
%%cve:2021-31193%% No No Less Likely Less Likely Important 7.8 6.8
Windows WalletService Elevation of Privilege Vulnerability
%%cve:2021-31187%% No No Less Likely Less Likely Important 7.8 6.8
Windows Wireless Networking Information Disclosure Vulnerability
%%cve:2020-24587%% No No Less Likely Less Likely Important 6.5 5.7
Windows Wireless Networking Spoofing Vulnerability
%%cve:2020-24588%% No No Less Likely Less Likely Important 6.5 5.7
%%cve:2020-26144%% No No Less Likely Less Likely Important 6.5 5.7

—
Renato Marinho
Morphus Labs| LinkedIn|Twitter

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

AWS

New – Create Microsoft SQL Server Instances of Amazon RDS on AWS Outposts

Leave a comment
This post was originally published on this site

Last year, we announced Amazon Relational Database Service (Amazon RDS) on AWS Outposts, which allows you to deploy fully managed database instances in your on-premises environments. AWS Outposts is a fully managed service that extends AWS infrastructure, AWS services, APIs, and tools to virtually any datacenter, co-location space, or on-premises facility for a truly consistent hybrid experience.

You can deploy Amazon RDS on Outposts to set up, operate, and scale MySQL and PostgreSQL relational databases on premises, just as you would in the cloud. Amazon RDS on Outposts provides cost-efficient and resizable capacity for on-premises databases and automates time-consuming administrative tasks, including infrastructure provisioning, database setup, patching, and backups, so you can focus on your applications.

Today, I am happy to announce support for Microsoft SQL Server on Outposts as a new database engine. You can deploy SQL Server on Outposts for low latency workloads that need to be run in close proximity to your on-premises data and applications. All operations that are currently supported for MySQL and PostgreSQL on RDS on Outposts can be performed with RDS for SQL Server on Outposts.

Creating a SQL Server Instance on Outposts
To get started with Amazon RDS for SQL Server on Outposts, in the Amazon RDS console, choose Create Database. Use the AWS Region that serves as home base for your Outpost.

Creating a SQL Server instance is similar to creating a MySQL or PostgreSQL database engine on Outposts. For Database location, choose On-premises. For On-premises creation method, choose RDS on Outposts, as shown here:

In Engine options, for Engine type, choose Microsoft SQL Server, and then choose your edition (SQL Server Enterprise Edition, Standard Edition, or Web Edition) and version. The latest available minor version of each major release, from SQL Server 2016, 2017 up to the newest, which is 2019. There are plans to add more editions and versions based on your feedback.

RDS for SQL Server on Outposts supports the license-included licensing model. You do not need separately purchase Microsoft SQL Server licenses. The license included pricing is inclusive of software and Amazon RDS management capabilities.

In DB instance class, choose the size of the instance. You can select between Standard classes (db.m5) or Memory Optimized classes (db.r5) for SQL Server.

The process for configuring an Amazon Virtual Private Cloud  (Amazon VPC) subnet for your Outpost, database credentials, and the desired amount of SSD storage is same as creating RDS instances. When everything is ready to go, choose Create database. The stat of your instance starts out as Creating and transitions to Available when your DB instance is ready:

After the DB instance is ready, you simply run a test query to use the new endpoint:

Now Available
Amazon RDS for Microsoft SQL Server on AWS Outposts is now available on your Outpost today. When you use Amazon RDS on Outposts, as with Amazon RDS, you pay only for what you use. There is no minimum fee. For more information, see the RDS on Outposts pricing page.

To learn more, see the product page and Working with Amazon RDS on AWS Outposts in the Amazon RDS User Guide. Please send us feedback either in the AWS forum for Amazon RDS or through your usual AWS support contacts.

Learn more about Amazon RDS for SQL Server on Outposts and get started today.

– Channy

Security

AA21-131A: DarkSide Ransomware: Best Practices for Preventing Business Disruption from Ransomware Attacks

Leave a comment
This post was originally published on this site

Original release date: May 11, 2021

Summary

This Advisory uses the MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK®) framework, Version 9. See the ATT&CK for Enterprise for all referenced threat actor tactics and techniques.

The Cybersecurity and Infrastructure Security Agency (CISA) and the Federal Bureau of Investigation (FBI) are aware of a ransomware attack affecting a critical infrastructure (CI) entity—a pipeline company—in the United States. Malicious cyber actors deployed DarkSide ransomware against the pipeline company’s information technology (IT) network.[1] At this time, there is no indication that the entity’s operational technology (OT) networks have been directly affected by the ransomware.

CISA and FBI urge CI asset owners and operators to adopt a heightened state of awareness and implement the recommendations listed in the Mitigations section of this Joint Cybersecurity Advisory, including implementing robust network segmentation between IT and OT networks; regularly testing manual controls; and ensuring that backups are implemented, regularly tested, and isolated from network connections. These mitigations will help CI owners and operators improve their entity’s functional resilience by reducing their vulnerability to ransomware and the risk of severe business degradation if impacted by ransomware.

Click here for a PDF version of this report.

Technical Details

Note: the analysis in this Joint Cybersecurity Advisory is ongoing, and the information provided should not be considered comprehensive. CISA and FBI will update this advisory as new information is available.

After gaining initial access to the pipeline company’s network, DarkSide actors deployed DarkSide ransomware against the company’s IT network. In response to the cyberattack, the company has reported that they proactively disconnected certain OT systems to ensure the systems’ safety.[2] At this time, there are no indications that the threat actor moved laterally to OT systems.

DarkSide is ransomware-as-a-service (RaaS)—the developers of the ransomware receive a share of the proceeds from the cybercriminal actors who deploy it, known as “affiliates.” According to open-source reporting, since August 2020, DarkSide actors have been targeting multiple large, high-revenue organizations, resulting in the encryption and theft of sensitive data. The DarkSide group has publicly stated that they prefer to target organizations that can afford to pay large ransoms instead of hospitals, schools, non-profits, and governments.[3],[4]

According to open-source reporting, DarkSide actors have previously been observed gaining initial access through phishing and exploiting remotely accessible accounts and systems and Virtual Desktop Infrastructure (VDI) (Phishing [T1566], Exploit Public-Facing Application [T1190], External Remote Services [T1133]).[5],[6] DarkSide actors have also been observed using Remote Desktop Protocol (RDP) to maintain Persistence [TA0003].[7]

After gaining access, DarkSide actors deploy DarkSide ransomware to encrypt and steal sensitive data (Data Encrypted for Impact [T1486]). The actors then threaten to publicly release the data if the ransom is not paid.[8],[9] The DarkSide ransomware uses Salsa20 and RSA encryption.[10]

DarkSide actors primarily use The Onion Router (TOR) for Command and Control (C2) [TA0011] (Proxy: Multi-hop Proxy [1090.003]).[11],[12] The actors have also been observed using Cobalt Strike for C2.[13]

Mitigations

CISA and FBI urge CI owners and operators to apply the following mitigations to reduce the risk of compromise by ransomware attacks.

  • Require multi-factor authentication for remote access to OT and IT networks.
  • Enable strong spam filters to prevent phishing emails from reaching end users. Filter emails containing executable files from reaching end users.
  • Implement a user training program and simulated attacks for spearphishing to discourage users from visiting malicious websites or opening malicious attachments and re-enforce the appropriate user responses to spearphishing emails.
  • Filter network traffic to prohibit ingress and egress communications with known malicious IP addresses. Prevent users from accessing malicious websites by implementing URL blocklists and/or allowlists.
  • Update software, including operating systems, applications, and firmware on IT network assets, in a timely manner. Consider using a centralized patch management system; use a risk-based assessment strategy to determine which OT network assets and zones should participate in the patch management program.
  • Limit access to resources over networks, especially by restricting RDP. After assessing risks, if RDP is deemed operationally necessary, restrict the originating sources and require multi-factor authentication.
  • Set antivirus/antimalware programs to conduct regular scans of IT network assets using up-to-date signatures. Use a risk-based asset inventory strategy to determine how OT network assets are identified and evaluated for the presence of malware.
  • Implement unauthorized execution prevention by: 
    • Disabling macro scripts from Microsoft Office files transmitted via email. Consider using Office Viewer software to open Microsoft Office files transmitted via email instead of full Microsoft Office suite applications.
    • Implementing application allowlisting, which only allows systems to execute programs known and permitted by security policy. Implement software restriction policies (SRPs) or other controls to prevent programs from executing from common ransomware locations, such as temporary folders supporting popular internet browsers or compression/decompression programs, including the AppData/LocalAppData folder.
    • Monitor and/or block inbound connections from Tor exit nodes and other anonymization services to IP addresses and ports for which external connections are not expected (i.e., other than VPN gateways, mail ports, web ports). For more guidance, refer to Joint Cybersecurity Advisory AA20-183A: Defending Against Malicious Cyber Activity Originating from Tor.
    • Deploy signatures to detect and/or block inbound connection from Cobalt Strike servers and other post exploitation tools.

CISA and FBI urge CI owners and operators to apply the following mitigations now to reduce the risk of severe business or functional degradation should their CI entity fall victim to a ransomware attack in the future.

  • Implement and ensure robust network segmentation between IT and OT networks to limit the ability of adversaries to pivot to the OT network even if the IT network is compromised. Define a demilitarized zone that eliminates unregulated communication between the IT and OT networks.
  • Organize OT assets into logical zones by taking into account criticality, consequence, and operational necessity. Define acceptable communication conduits between the zones and deploy security controls to filter network traffic and monitor communications between zones. Prohibit industrial control system (ICS) protocols from traversing the IT network.
  • Identify OT and IT network inter-dependencies and develop workarounds or manual controls to ensure ICS networks can be isolated if the connections create risk to the safe and reliable operation of OT processes. Regularly test contingency plans such as manual controls so that safety critical functions can be maintained during a cyber incident. Ensure that the OT network can operate at necessary capacity even if the IT network is compromised. 
  • Regularly test manual controls so that critical functions can be kept running if ICS or OT networks need to be taken offline.
  • Implement regular data backup procedures on both the IT and OT networks. Backup procedures should be conducted on a frequent, regular basis. The data backup procedures should also address the following best practices:
    • Ensure that backups are regularly tested.
    • Store your backups separately. Backups should be isolated from network connections that could enable the spread of ransomware. It is important that backups be maintained offline as many ransomware variants attempt to find and encrypt or delete accessible backups. Maintaining current backups offline is critical because if your network data is encrypted with ransomware, your organization can restore systems to its previous state. Best practice is to store your backups on a separate device that cannot be accessed from a network, such as on an external hard drive. (See the Software Engineering Institute’s page on ransomware).
    • Maintain regularly updated “gold images” of critical systems in the event they need to be rebuilt. This entails maintaining image “templates” that include a preconfigured operating system (OS) and associated software applications that can be quickly deployed to rebuild a system, such as a virtual machine or server.
    • Retain backup hardware to rebuild systems in the event rebuilding the primary system is not preferred. Hardware that is newer or older than the primary system can present installation or compatibility hurdles when rebuilding from images.
    • Store source code or executables. It is more efficient to rebuild from system images, but some images will not install on different hardware or platforms correctly; having separate access to needed software will help in these cases.
  • Ensure user and process accounts are limited through account use policies, user account control, and privileged account management. Organize access rights based on the principles of least privilege and separation of duties.

If your organization is impacted by a ransomware incident, CISA and FBI recommend the following actions:

  • Isolate the infected system. Remove the infected system from all networks, and disable the computer’s wireless, Bluetooth, and any other potential networking capabilities. Ensure all shared and networked drives are disconnected, whether wired or wireless.  
  • Turn off other computers and devices. Power-off and segregate (i.e., remove from the network) the infected computer(s). Power-off and segregate any other computers or devices that shared a network with the infected computer(s) that have not been fully encrypted by ransomware. If possible, collect and secure all infected and potentially infected computers and devices in a central location, making sure to clearly label any computers that have been encrypted. Powering-off and segregating infected computers and computers that have not been fully encrypted may allow for the recovery of partially encrypted files by specialists. (See Before You Connect a New Computer to the Internet for tips on how to make a computer more secure before you reconnect it to a network.)
  • Secure your backups. Ensure that your backup data is offline and secure. If possible, scan your backup data with an antivirus program to check that it is free of malware.
  • Refer to Joint Cybersecurity Advisory: AA20-245A: Technical Approaches to Uncovering and Remediating Malicious Activity for more best practices on incident response.

Note: CISA and the FBI do not encourage paying a ransom to criminal actors. Paying a ransom may embolden adversaries to target additional organizations, encourage other criminal actors to engage in the distribution of ransomware, and/or may fund illicit activities. Paying the ransom also does not guarantee that a victim’s files will be recovered. CISA and FBI urge you to report ransomware incidents to your local FBI field office.

CISA offers a range of no-cost cyber hygiene services to help CI organizations assess, identify and reduce their exposure to threats, including ransomware. By requesting these services, organizations of any size could find ways to reduce their risk and mitigate attack vectors.

Resources

Contact Information

Victims of ransomware should report it immediately to CISA at https://us-cert.cisa.gov/report, a local FBI Field Office, or U.S. Secret Service Field Office. To report suspicious or criminal activity related to information found in this Joint Cybersecurity Advisory, contact your local FBI field office at www.fbi.gov/contact-us/field, or the FBI’s 24/7 Cyber Watch (CyWatch) at (855) 292-3937 or by e-mail at CyWatch@fbi.gov. When available, please include the following information regarding the incident: date, time, and location of the incident; type of activity; number of people affected; type of equipment used for the activity; the name of the submitting company or organization; and a designated point of contact. To request incident response resources or technical assistance related to these threats, contact CISA at CISAServiceDesk@cisa.dhs.gov.

References

Revisions

  • May 11, 2021: Initial Version

This product is provided subject to this Notification and this Privacy & Use policy.

AWS

AWS Local Zones Are Now Open in Boston, Miami, and Houston

Leave a comment
This post was originally published on this site

AWS Local Zones place select AWS services (compute, storage, database, and so forth) close to large population, industry, and IT centers. They support use cases such as real-time gaming, hybrid migrations, and media & entertainment content creation that need single-digit millisecond latency for end-users in a specific geographic area.

Last December I told you about our plans to launch a total of fifteen AWS Local Zones in 2021, and also announced the preview of the Local Zones in Boston, Miami, and Houston. Today I am happy to announce that these three Local Zones are now ready to host your production workloads, joining the existing pair of Local Zones in Los Angeles. As I mentioned in my original post, each Local Zone is a child of a particular parent region, and is managed by the control plane in the region. The parent region for all three of these zones is US East (N. Virginia).

Using Local Zones
To get started, I need to enable the Zone(s) of interest. I can do this from the command line (modify-availability-zone-group), via an API call (ModifyAvailabilityZoneGroup), or from within the EC2 Console. From the console, I enter the parent region and click Zones in the Account attributes:

I can see the Local Zones that are within the selected parent region. I click Manage for the desired Local Zone:

I click Enabled and Update zone group, and I am ready to go!

I can create Virtual Private Clouds (VPCs), launch EC2 instances, create SSD-backed EBS volumes (gp2), and set up EKS and ECS clusters in the Local Zone (see the AWS Local Zones Features page for a full list of supported services).

The new Local Zones currently offer the following instances:

Name Category vCPUs Memory
(GiB)
t3.xlarge General Purpose 4 16
c5d.2xlarge Compute Intensive 8 16
g4dn.2xlarge GPU 8 32
r5d.2xlarge Memory Intensive 8 64

I can also use EC2 Auto Scaling, AWS CloudFormation, and Amazon CloudWatch in the parent region to monitor and control these resources.

Local Zones in Action
AWS customers are already making great use of all five operational Local Zones! After talking with my colleagues, I learned that the use cases for Local Zones can be grouped into two categories:

Distributed Edge – These customers want to place selected parts of their gaming, social media, and voice assistant applications in multiple, geographically disparate locations in order to deliver a low-latency experience to their users.

Locality – These customers need access to cloud services in specific locations that are in close proximity to their existing branch offices, data centers, and so forth. In addition to low-latency access, they often need to process and store data within a specific geographic region in order to meet regulatory requirements. These customers often use AWS VPN to connect to the desired Local Zone.

Here are a few examples:

Ambra Health provides a cloud-based medical image management suite that empowers some of the largest health systems, radiology practices, and clinical research organizations. The suite replaces traditional desktop image viewers, and uses Local Zones to provide radiologists with rapid access to high quality images so that they can focus on improving patient outcomes.

Couchbase is an award-winning distributed NoSQL cloud database for modern enterprise applications. Couchbase is using AWS Local Zones to provide low latency and single-digit millisecond data access times for applications, ensuring developers’ apps are always available and fast. Using Local Zones, along with Couchbase’s edge computing capabilities, means that their customers are able to store, query, search, and analyze data in real-time

Edgegap is a game hosting service provider focused on providing the best online experience for their customers. AWS Local Zones gives their customers (game development studios such as Triple Hill Interactive, Agog Entertainment, and Cofa Games) the ability to take advantage of ever-growing list of locations and to deploy games with a simple API call.

JackTrip is using Local Zones to allow musicians in multiple locations to collaboratively perform well-synchronized live music over the Internet.

Masomo is an interactive entertainment company that focuses on mobile games including Basketball Arena and Head Ball 2. They use Local Zones to deploy select, latency-sensitive portions of their game servers close to end users, with the goal of improving latency, reducing churn, and providing players with a great experience.

Supercell deploys game servers in multiple AWS regions, and evaluates all new regions as they come online. They are already using Local Zones as deployment targets and considering additional Local Zones as they become available in order to bring the latency-sensitive portions of game servers closer to more end users.

Takeda (a global biopharmaceutical company) is planning to create a hybrid environment that spans multiple scientific centers in and around Boston, with compute-intensive R&D workloads running in the Boston Local Zone.

Ubitus deploys game servers in multiple locations in order to reduce latency and to provide users with a consistent, high-quality experience. They see Local Zones as a (no pun intended) game-changer, and will use it them to deploy and test clusters in multiple cities in pursuit of that consistent experience.

Learn More
Here are some resources to help you learn more about AWS Local Zones:

Stay Tuned
We are currently working on twelve additional AWS Local Zones (Atlanta, Chicago, Dallas, Denver, Kansas City, Las Vegas, Minneapolis, New York, Philadelphia, Phoenix, Portland, and Seattle) and plan to open them throughout the remainder of 2021. We are also putting plans in place to expand to additional locations, both in the US and elsewhere. If you would like to express your interest in a particular location, please let us know by filling out the AWS Local Zones Interest Form.

Over time we plan to add additional AWS services, including AWS Direct Connect and more EC2 instance types in these new Local Zones, all driven by feedback from our customers.

— Jeff;

 

Security

Virtual Private Networks

Leave a comment
This post was originally published on this site

Virtual Private Networks (VPN) create encrypted tunnels when you connect to the Internet. They are a fantastic way to protect your privacy and data, especially when traveling and connecting to untrusted or unknown networks, such as at hotels or coffee shops. Use a VPN whenever possible, both for work and personal use.

AWS

Resolve IT Incidents Faster with Incident Manager, a New Capability of AWS Systems Manager

Leave a comment
This post was originally published on this site

IT engineers pride themselves on the skill and care they put into building applications and infrastructure. However, as much as we all hate to admit it, there is no such thing as 100% uptime. Everything will fail at some point, often at the worst possible time, leading to many a ruined evening, birthday party, or wedding anniversary (ask me how I know).

As pagers go wild, on-duty engineers scramble to restore service, and every second counts. For example, you need to be able to quickly filter the deluge of monitoring alerts in order to pinpoint the root cause of the incident. Likewise, you can’t afford to waste any time locating and accessing the appropriate runbooks and procedures needed to solve the incident. Imagine yourself at 3:00A.M., wading in a sea of red alerts and desperately looking for the magic command that was “supposed to be in the doc.” Trust me, it’s not a pleasant feeling.

Serious issues often require escalations. Although it’s great to get help from team members, collaboration and a speedy resolution require efficient communication. Without it, uncoordinated efforts can lead to mishaps that confuse or worsen the situation.

Last but not least, it’s equally important to document the incident and how you responded to it. After the incident has been resolved and everyone has had a good night’s sleep, you can replay it, and work to continuously improve your platform and incident response procedures.

All this requires a lot of preparation based on industry best practices and appropriate tooling. Most companies and organizations simply cannot afford to learn this over the course of repeated incidents. That’s a very frustrating way to build an incident preparation and response practice.

Accordingly, many customers have asked us to help them, and today, I’m extremely happy to announce Incident Manager, a new capability of AWS Systems Manager that helps you prepare and respond efficiently to application and infrastructure incidents.

If you can’t wait to try it, please feel free to jump now to the Incident Manager console. If you’d like to learn more, read on!

Introducing Incident Manager in AWS Systems Manager
Since the launch of Amazon.com in 1995, Amazon teams have been responsible for incident response of their services. Over the years, they’ve accumulated a wealth of experience in responding to application and infrastructure issues at any scale. Distilling these years of experience, the Major Incident Management team at Amazon has designed Incident Manager to help all AWS customers prepare for and resolve incidents faster.

As preparation is key, Incident Manager lets you easily create a collection of incident response resources that are readily available when an alarm goes off. These resources include:

  • Contacts: Team members who may be engaged in solving incidents and how to page them (voice, email, SMS).
  • Escalation plans: Additional contacts who should be paged if the primary on-call responder doesn’t acknowledge the incident.
  • Response plans: Who to engage (contacts and escalation plan), what they should do (the runbook to follow), and where to collaborate (the channel tied to AWS Chatbot).

Incident Manager

In short, creating a response plan lets you prepare for incidents in a standardized way, so you can react as soon as they happen and resolve them quicker. Indeed, response plans can be triggered automatically by a Amazon CloudWatch alarm or an Amazon EventBridge event notification of your choice. If required, you can also launch a response plan manually.

When the response plan is initiated, contacts are paged, and a new dashboard is automatically put in place in the Incident Manager console. This dashboard is the point of reference for all things involved in the incident:

  • An overview on the incident, so that responders have a quick and accurate summary of the situation.
  • CloudWatch metrics and alarm graphs related to the incident.
  • A timeline of the incident that lists all events added by Incident Manager, and any custom event added manually by responders.
  • The runbook included in the response plan, and its current state of execution. Incident Manager provides a default template implementing triage, diagnosis, mitigation and recovery steps.
  • Contacts, and a link to the chat channel.
  • The list of related Systems Manager OpsItems.

Here’s a sample dashboard. As you can see, you can easily access all of the above in a single click.

Incident Dashboard

After the incident has been resolved, you can create a post-incident analysis, using a built-in template (based on the one that Amazon uses for Correction of Error), or one that you’ve created. This analysis will help you understand the root cause of the incident and what could have been done better or faster to resolve it.

By reviewing and editing the incident timeline, you can zoom in on specific events and how they were addressed. To guide you through the process, questions are automatically added to the analysis. Answering them will help you focus on potential improvements, and how to add them to your incident response procedures. Here’s a sample analysis, showing some of these questions.

Incident Analysis

Finally, Incident Manager recommends action items that you can accept or dismiss. If you accept an item, it’s added to a checklist that has to be fully completed before the analysis can be closed. The item is also filed as an OpsItem in AWS Systems Manager OpsCenter, which can sync to ticketing systems like Jira and ServiceNow.

Getting Started
The secret sauce in successfully responding to IT incidents is to prepare, prepare again, and then prepare some more. We encourage you to start planning now for failures that are waiting to happen. When that pager alarm comes in at 3:00AM, it will make a world of difference.

We believe Incident Manager will help you resolve incidents faster by improving your preparation, resolution and analysis workflows. It’s available today in the following AWS Regions:

  • US East (N. Virginia), US East (Ohio), US West (Oregon)
  • Europe (Ireland), Europe (Frankfurt), Europe (Stockholm)
  • Asia Pacific (Tokyo), Asia Pacific (Singapore), Asia Pacific (Sydney)

Give it a try, and let us know what you think. As always, we look forward to your feedback. You can send it through your usual AWS Support contacts, or post it on the AWS Forum for AWS Systems Manager.

If you want to learn more about Incident Manager, sign up for the AWS Summit Online event taking place on May 12 and 13, 2021.

Security

Correctly Validating IP Addresses: Why encoding matters for input validation., (Mon, May 10th)

Leave a comment
This post was originally published on this site

Recently, a number of libraries suffered from a very similar security flaw: IP addresses expressed in octal were not correctly interpreted. The result was that an attacker was able to bypass input validation rules that restricted IP addresses to specific subnets. 

The vulnerability was documented in (this list is unlikely to be complete):

  • Node.js netmask package [1]
  • Perl (various packages) [2]
  • Python stdlib ipaddress module [3]

All of these vulnerabilities were caused by a similar problem: These libraries attempted to parse IP addresses as a string. Later, standard-based "socket" libraries were used to establish the actual connection. The socket libraries have their own "inet_aton" function to convert an IP address string to a long unsigned integer.

It isn't an accident that security researchers started to look at these libraries right now. More and more of our applications have surrendered data to cloud services and implement APIs to access the data. Server-Side Request Forgery (SSRF) is becoming more of an issue as a result. And to restrict which IP address a particular application may connect to, we often use the libraries above.

As a simple test string, use "010.010.010.010". The leading "0" indicates that the address is octal. In "dotted decimal," the address translates to Google's name server 8.8.8.8.

So if you have to validate an IP address: How to do it? First of all: Try to stick to one of the (hopefully now fixed) standard libraries. But in general, it can be helpful to stick to the same library for input validation and to establish the connection. This way, the IP address is not interpreted differently. There is also an argument to be made to just not allow octal. I leave that decision up to you. Standards do allow that notation.

For example, most languages under the hood rely on the C "Sockets" library to establish connections [4]. This library also includes functions to convert IP addresses expressed as a string into an unsigned 32-bit integer (inet_aton) and back (inet_ntoa)  [5]. Take a look if your language is implementing these functions.  Part of the problem of the node.js vulnerability was that node.js implemented its own "ip2long" function. 

So how do you verify if an IP address is inside a subnet? Well, there is a reason netmasks are called netmasks: They are bitmasks. Bitmasking is a very efficient and simple way to verify IP addresses.

First of all: Is this IP address a valid IPv4 address?

My favorite "trick" is to convert the address to an integer with inet_aton. Next, convert it back to a string with inet_ntoa. If the string didn't change: You got a valid address. This will work nicely if you only allow dotted decimal notation. If not: just convert the string with inet_aton and keep it an integer. Not all languages may use the Sockets library for "inet_aton." Some may use their own (buggy?) implementation. So best to check quickly:

010.010.010.010 = 8.8.8.8 = 134744072 .

If you get 168430090, then you got it wrong (that would be 10.10.10.10). MySQL/MariaDB, for example, will get you the wrong answer:

MariaDB [(none)]> select inet_aton('10.10.10.10')-inet_aton('010.010.010.010');
+-------------------------------------------------------+
| inet_aton('10.10.10.10')-inet_aton('010.010.010.010') |
+-------------------------------------------------------+
|                                                     0 |
+-------------------------------------------------------+

Output encoding matters for proper input validation!

So now, how do we verify if IP address "A" is in subnet B/Z ?

"z" is the number of bits that need to be the same. So let's create a mask:

mask = 2^32-2^(32-Z)

next, let's do a bitwise "AND" before comparing the result:

If ( A & mask == B & mask ) {
    IP Address A is in B/Z
}

So in short:

  1. Try to use the same library to validate the IP address and to establish connections. That is probably the easiest way to avoid issues. Sadly, modern languages add additional layers, and it isn't always clear what happens in the background. 
  2. Test! inet_aton('010.010.010.010') != inet_aton('10.10.10.10').
  3. IPs are long integers, not strings.

So why do I sometimes see IP addresses like "010.123.123.123" on isc.sans.edu?

Remember, we started collecting data 20 years ago. I have learned since 🙂 But some of my early sins still haunt me. Over the last few years, we moved to store the IP addresses as 32-bit unsigned integers, but "back in the day," we used 15 digit strings and zero-padded them for easy sorting… sorry. should be mostly gone by now and if you find a case where this is still happening, let me know.

What about IPv6?

That will be a different diary 🙂

What about hex notation?

There are a number of additional formats that can be used for IP addresses. For a complete collection of different representations of IP addresses [6]. Test them. Let me know what you find 🙂 .

 

[1] https://nvd.nist.gov/vuln/detail/CVE-2021-29418
[2] https://blog.urth.org/2021/03/29/security-issues-in-perl-ip-address-distros/
[3] https://nvd.nist.gov/vuln/detail/CVE-2021-29921
[4] https://www.gnu.org/software/libc/manual/html_node/Sockets.html
[5] https://www.gnu.org/software/libc/manual/html_node/Host-Address-Functions.html
[6] https://www.hacksparrow.com/networking/many-faces-of-ip-address.html

—
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Security

Who is Probing the Internet for Research Purposes?, (Sat, May 8th)

Leave a comment
This post was originally published on this site

Shodan[1] is one of the most familiar site for research on what is on the internet. In Oct 2020 I did a diary on Censys [2][3], another site collecting similar information like Shodan. The next two sites are regularly scanning the internet for data which isn't shared with the security community at large.

Net Systems Research [4] probe the internet for research, but none of the data is accesible or published on the site. This is part of the message About Us: "Net Systems Research was founded in 2015 by a group of security data researchers who wanted to utilize a global view of the internet to study these difficult and emerging internet security challenges and understand the resulting implications."

Security IPIP [5] has no information beside a banner: "Our company engaged in the researching and data collecting of IP location, internet infrastructure and network security, we need to detect the internet (Ping/ Traceoute Mainly); For network security research, we need to obtain the IP location Banner and fingerprint information, we detecting the common port openly or not by ZMap, and collecting opened Banner data by our own code. Any questions please do not hesitate to contact with us: frk@ipip.net."

Over the past 3 years, my honeypot has logged information at various point in times from these 4 different research organizations. Here are some typical logs and their top 10 IPs. Shodan uses IP range 71.6.128.0-71.6.255.255 to run its scans but unlike other scanners, it doesn't include a banner in the captured logs.

Activity first noticed 4 June 2018. This is a sample log:

20210507-171447: 192.168.25.9:80-71.6.158.166:34476 data
GET / HTTP/1.1
Accept-Encoding: identity
Host: xxxxxx.xxx.ca
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36

Activity first noticed 19 Aug 2020. This is a sample log:

20210506-011443: 192.168.25.9:80-162.142.125.38:46726 data
GET / HTTP/1.1
Host: 70.55.XX.XXX:8080
User-Agent: Mozilla/5.0 (compatible; CensysInspect/1.1; +https://about.censys.io/)
Accept: */*
Accept-Encoding: gzip

Activity first noticed 15 Feb 2019. This is a sample log:

20210506-013155: 192.168.25.9:8443-92.118.160.5:47195 data
GET / HTTP/1.1
Host: 70.55.XX.XXX:8443
User-Agent: NetSystemsResearch studies the availability of various services across the internet. Our website is netsystemsresearch.com

Activity first noticed 14 Oct 2018 data. This is a sample log:

20210506-082116: 192.168.25.9:81-172.104.67.101:42966
GET / HTTP/1.1
Host: 70.55.XX.XXX:81
User-Agent: HTTP Banner Detection (https://security.ipip.net)
Connection: close

Since the data is already out there, why not use Shodan or Censys to explore what services a home router is sharing to the internet. Here is an example of list of services recorded and audited by Shodan which also includes SSL certificate information, banner version, etc.

 

[1] https://www.shodan.io
[2] https://censys.io/ipv4
[3] https://isc.sans.edu/forums/diary/An+Alternative+to+Shodan+Censys+with+UserAgent+CensysInspect11/26718
[4] http://www.netsystemsresearch.com
[5] https://security.ipip.net/
[6] https://isc.sans.edu/ipinfo.html?ip=71.6.158.166 (Shodan RESEARCHER: THIS IP IS USED FOR INTERNET WIDE RESEARCH SCANS)

———–
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Powershell

Announcing PowerShell Crescendo Preview.2

Leave a comment
This post was originally published on this site

We are pleased to announce the second preview of PowerShell Crescendo, a framework to rapidly
develop PowerShell cmdlets for native commands, regardless of platform.

The updated preview releases are now available for download on the PowerShell Gallery:

To install Microsoft.PowerShell.Crescendo:

Install-Module Microsoft.PowerShell.Crescendo -AllowPrerelease

For more information on Microsoft.PowerShell.Crescendo, check out these previous blog posts:

Crescendo Preview 2 Updates

This update to Crescendo adds elevation support for native commands, and generation of a module
manifest when exporting a Crescendo module. Read the full list of changes below:

  • Added support for native command elevation on Windows and Linux platforms. (Issue #50)
  • Export-CrescendoModule now exports a module manifest (psd1) along with the module file (psm1). (Issue #51)
  • Added support for generating aliases for Crescendo cmdlets (Issue #52)
  • Added support for SupportsShouldProcess. Thanks jdhitsolutions! (Issue #59)

Native Command elevation

Native commands may require administrative elevation to perform the requested operation. The
Crescendo schema has been extended to support elevation on Windows and Linux/macOS platforms. The schema
supports the new keyword Elevation that has two properties Command and Arguments.

  • Command: Defines the elevation mechanism to be used to elevate the native command. The function
    Invoke-WindowsNativeAppWithElevation has been included to aid with elevation on Windows. sudo
    has been tested as well.
  • Arguments: These are the parameters to be used in conjunction with the elevation command. This can
    be a collection of parameters.

    • OriginalName: This is the parameter to be used with the elevation command.
    • DefaultValue: The default parameter value.

Windows Native Command Elevation

Elevation on Windows is supported using the built-in function
Invoke-WindowsNativeAppWithElevation. Invoke-WindowsNativeAppWithElevation uses Start-Process
with a PSCredential to invoke the native command and captures the output and errors of the native
command which are returned to the user. This function is inserted into the Crescendo module you
export. In the example below, the PowerShell cmdlet Get-Credential will prompt for credentials
necessary to elevate the native command when the exported Crescendo function is executed.

"Elevation": {
        "Command": "Invoke-WindowsNativeAppWithElevation",
        "Arguments": [
            {
                "OriginalName" : "-Credential",
                "DefaultValue": "(get-credential)"
            }
        ]
    },

In automation scenarios that require elevation without user interaction, Crescendo supports
retrieving credentials from secured vaults. In the example below, credentials for elevation are
retrieved from SecretManagement and SecretStore.

For more information about storing and managing secrets, see [SecretManagement Announcement](https://devblogs.microsoft.com/powershell/secretmanagement-and-secretstore-are-generally-available/

"Elevation": {
        "Command": "Invoke-WindowsNativeAppWithElevation",
        "Arguments": [
            {
                "OriginalName" : "-Credential",
                "DefaultValue": "(get-secret admin)"
            }
        ]
    },

Elevation can be defined for each cmdlet. When authoring a Crescendo json configuration, include
the elevation definition before the parameters are defined. In the example below, the native command
netsh.exe requires elevation to enable and disable the Windows Firewall.

{
    "$schema": "./Microsoft.PowerShell.Crescendo.Schema.json",
    "Verb": "Set",
    "Noun": "WinFirewall",
    "Platform": ["Windows"],
    "OriginalCommandElements": ["advfirewall", "set", "allprofiles", "state"],
    "OriginalName": "$env:Windir/system32/netsh.exe",
    "Elevation": {
        "Command": "Invoke-WindowsNativeAppWithElevation",
        "Arguments": [
            {
                "OriginalName" : "-Credential",
                "DefaultValue": "(get-credential)"
            }
        ]
    },
    "DefaultParameterSetName": "Enable",
    "Parameters": [
        {
            "OriginalName": "on",
            "Name": "On",
            "ParameterType": "switch",
            "ParameterSetName": ["Enable"]
        },
        {
            "OriginalName": "off",
            "Name": "Off",
            "ParameterType": "switch",
            "ParameterSetName": ["Disable"]
        }
    ]
}

Linux Native Command Elevation

Native command elevation for Linux and macOS is handled through the command sudo. To enable
elevation for Crescendo, include sudo as the Command value. In the example below, when the
function Get-TimeServer is executed, the user is prompted for the sudo password. The native
command is elevated with sudo privileges. In automation scenarios that require elevation without
user interaction, configure the sudoers file.

{
    "$schema": "../src/Microsoft.PowerShell.Crescendo.Schema.json",
    "Verb": "Get",
    "Noun": "TimeServer",
    "Elevation": {
        "Command": "sudo"
    },
    "OriginalCommandElements": ["-getnetworktimeserver"],
    "OriginalName": "/usr/sbin/systemsetup",
    "Platform": ["MacOS"],
    "OutputHandlers": [
        {
            "ParameterSetName": "Default",
            "Handler": "$args|%{[pscustomobject]@{ TimeServer = $_.Split(':')[1].Trim()}}"
        }
    ]
}

SupportsShouldProcess

Cmdlets that cause change to the system, such as files and service configurations, create a risk
that could negatively impact operations. To help mitigate risk, cmdlets support common parameters
-WhatIf and -Confirm. These parameters provide greater detail about the target of each
change, and provides a confirmation mechanism allowing the user to approve each change. Crescendo
supports this functionality when wrapping native commands though the schema keyword
SupportsShouldProcess.

In the example below, The keyword SupportsShouldProcess accepts a boolean to enable the common
parameters -WhatIf and -Confirm.

{
    "$schema": "../src/Microsoft.PowerShell.Crescendo.Schema.json",
    "Verb": "Remove",
    "Noun": "DockerImage",
    "OriginalName": "docker",
    "SupportsShouldProcess": true,
    "OriginalCommandElements": [
        "image",
        "rm"
    ],
    "Parameters": [
        {
            "Name": "ID",
            "OriginalName": "",
            "Mandatory": true,
            "ValueFromPipelineByPropertyName": true
        }
    ]
}

Executing Remove-DockerImage with the -WhatIf parameter supported by SupportsShouldProcess.

Get-DockerImage | Where-Object {$_.id -match "d70eaf7277ea"} | Remove-DockerImage -WhatIf

When SupportsShouldProcess is set True, the following expected output will result.

What if: Performing the operation "Remove-DockerImage" on target "docker image rm d70eaf7277ea".

Aliases

Aliases for Crecendo wrapped native commands are now supported in the Crescendo schema with the
keyword Aliases. In the snippet below, the cmdlet definition Set-WinFirewall includes the alias
definition SFW. When exported, the Crescendo created module will include the Set-WinFirewall
function and SFW alias.

{
    "$schema": "./Microsoft.PowerShell.Crescendo.Schema.json",
    "Verb": "Set",
    "Noun": "WinFirewall",
    "Platform": ["Windows"],
    "OriginalCommandElements": ["advfirewall", "set", "allprofiles", "state"],
    "OriginalName": "$env:Windir/system32/netsh.exe",
    "Aliases": ["SFW"],
    "Elevation": {
        "Command": "Invoke-WindowsNativeAppWithElevation",
        "Arguments": [
            {
                "OriginalName" : "-Credential",
                "DefaultValue": "(get-credential)"
            }
        ]
    },

Future plans

Next/Future plans for preview.3 will be based on feedback and include a few items under investigation:

  • Improved OutputHandler support for building objects from native command string output.
  • Support for multiple cmdlet definitions in a single json configuration.

Our goal is to make it easier to convert your native commands to PowerShell cmdlets and receive the
benefits that PowerShell provides. We value your ideas and feedback and hope you will give Crescendo
a try, then stop by our GitHub repository and let us know of any issues or features you would like
added.

For more information about PowerShell Crescendo issues and features, see:
Crescendo on GitHub

Jason Helmick

Program Manager, PowerShell

The post Announcing PowerShell Crescendo Preview.2 appeared first on PowerShell Team.

Iron Castle Systems