Security updates for Tuesday

Post Syndicated from jzb original https://lwn.net/Articles/1063248/

Security updates have been issued by Fedora (mingw-openexr, vim, and yarnpkg), Oracle (freerdp), Red Hat (389-ds-base, container-tools:rhel8, libpng, libpng15, nginx, nginx:1.24, nginx:1.26, opencryptoki, python3, python3.11, python3.12, and python3.9), SUSE (ruby4.0-rubygem-activestorage, ruby4.0-rubygem-activesupport, ruby4.0-rubygem-glogalid, ruby4.0-rubygem-grpc, ruby4.0-rubygem-jquery-rails, ruby4.0-rubygem-loofah, and rubygem4.0-rubygem-fluentd), and Ubuntu (curl, linux, linux-aws, linux-aws-6.17, linux-gcp, linux-hwe-6.17, linux-oracle,
linux-oracle-6.17, linux, linux-aws, linux-gcp, linux-gcp-6.8, linux-gke, linux-gkeop,
linux-hwe-6.8, linux-ibm, linux-ibm-6.8, linux-lowlatency,
linux-lowlatency-hwe-6.8, linux-oracle, linux-oracle-6.8, linux, linux-aws, linux-gcp, linux-gkeop, linux-ibm, linux-ibm-5.15,
linux-intel-iotg, linux-kvm, linux-lowlatency, linux-nvidia,
linux-nvidia-tegra, linux-nvidia-tegra-5.15, linux-oracle,
linux-xilinx-zynqmp, linux-fips, linux-aws-fips, linux-gcp-fips, linux-gcp, linux-nvidia, linux-nvidia-6.8, linux-nvidia-lowlatency, python-cryptography, and roundcube).

PACT 2026: A Stronger, Simpler, More Profitable Path for Rapid7 Partners

Post Syndicated from Kelly Hiscoe original https://www.rapid7.com/blog/post/c-pact-2026-stronger-simpler-profitable-path-for-rapid7-partners

The cybersecurity channel is evolving fast. Buying behaviors are shifting and customers are rethinking how they evaluate solutions. And partners are rethinking how they deliver value at scale. In this environment, vendor partner programs can’t stay static.

Most partner programs are built around what works for the vendor. We continue to choose a different path, asking our partners where we could evolve and improve.

The result? Meaningful updates to the Rapid7 PACT Partner Program for 2026. Carefully designed to deliver stronger economics, simpler engagement, and clearer paths to growth.

Rapid7 PACT: Built with partner feedback in mind

Over the past year, we had ongoing conversations with partners across our global ecosystem. Those discussions were grounded in trust, candor, and a shared ambition to win together.

Partners told us where friction existed. They told us where our economics needed to be more competitive. They told us where clarity and simplicity would make it easier to go to market.

The 2026 PACT updates are our response to that feedback.

What is the Rapid7 ‘PACT’ partner program?

PACT is the framework that defines how Rapid7 works with our global network of resellers, managed security service providers (MSSPs), and distributors.

But PACT is more than a framework. It reflects our commitment to transparency, consistency, and accountability in every partner interaction. These aren’t aspirational values, they are operational principles that guide how we build trust across our channel ecosystem.

What’s new in PACT for 2026

This year’s updates focus on four core areas, each directly shaped by partner input.

  • Stronger Economics: Expanded program discounts, rebates and incentives drive greater margin, predictability, and MDR competitiveness.
  • Simpler Engagement: We are operating with two clear motions; Deal Registration and Co-Sell. Resulting in less friction and faster execution.
  • Platinum Partner Tier: A new top tier recognizes and accelerates our highest-performing, most strategic partners.
  • Tech Champion Program: Exclusive recognition and access for partner Systems Engineers to deepen technical collaboration and influence.

Why this matters now

The vendors who will earn (and retain) partner mindshare are those who combine in-demand cybersecurity solutions with a partner experience that is simple, profitable, and built for scale. We know technology leadership alone isn’t enough. The experience of working with us has to be just as strong as the solutions we deliver. The 2026 PACT updates reflect that commitment.

Ready to grow with us?

The updated 2026 PACT Partner Program is now live. Whether you’re an existing partner exploring what’s changed, or an organization considering a partnership with Rapid7, you can find everything you need at rapid7.com/partners. We’re excited about what’s ahead, and we’re building it together with our partners.

South Korean Police Accidentally Post Cryptocurrency Wallet Password

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/03/south-korean-police-accidentally-post-cryptocurrency-wallet-password.html

An expensive mistake:

Someone jumped at the opportunity to steal $4.4 million in crypto assets after South Korea’s National Tax Service exposed publicly the mnemonic recovery phrase of a seized cryptocurrency wallet.

The funds were stored in a Ledger cold wallet seized in law enforcement raids at 124 high-value tax evaders that resulted in confiscating digital assets worth 8.1 billion won (currently approximately $5.6 million).

When announcing the success of the operation, the agency released photos of a Ledger device, a popular hardware wallet for crypto storage and management.

However, the images also showed a handwritten note of the wallet recovery phrase, which serves as the master key that allows restoring the assets to another device.

The authorities failed to redact that info, allowing anyone to transfer into their account the assets in the cold wallet.

Reportedly, shortly after the press release was published, 4 million Pre-Retogeum (PRTG) tokens, worth approximately $4.8 million at the time, were transferred out of the confiscated wallet to a new address.

Simplifying Certificate Renewals for Millions of Domains with ACME Renewal Information (ARI)

Post Syndicated from Let's Encrypt original https://letsencrypt.org/2026/03/17/acme-renewal-information-ari.html

Nick Silverman is a Senior Infrastructure Engineer on the Edge Infrastructure team at Shopify, where he maintains the systems that provision, renew, and publish SSL certificates for millions of merchants’ custom domains. He is also a contributor to the Ruby acme-client gem.

The challenge

Shopify’s automated certificate management system relied on a static renewal threshold: 30 days before the end of the 90-day lifetime. To spread the load of provisioning and renewing certificates, we implemented a random 0–72 hour delay for each. While this helps evenly distribute certificate management over time, it did not take into account the Certificate Authority’s (CA) load. It was also incapable of reacting to a dynamic renewal window based on information provided by the CA.

However, this approach needed greater resilience to solve what is, in the end, a distributed coordination problem. The weaknesses are:

  • No rapid revocation response: The static logic is not aware of revocations at all.

  • Brittleness to lifetime changes: The static 30-day threshold is not resilient to changes in certificate lifetime, such as Let’s Encrypt’s announced plan to move to 45-day certificates.

  • Imperfect load distribution: Despite the random jitter, massive renewal bursts could still occur.

Shopify needed to develop a global coordination system to balance the load and handle regular and urgent renewals. Thankfully, Let’s Encrypt has led the charge on a solution for this and other very important aspects of the certificate lifecycle.

The journey

Let’s Encrypt and the Internet Engineering Task Force (IETF) published the ACME Renewal Information (ARI) standard which makes an endpoint available that provides a recommended window of time for the renewal to occur. The endpoint returns a payload that looks something like this:

GET /renewal-info/ACME_KEY_IDENTIFIER
{
  "suggestedWindow": {
    "start": "2026-02-03T04:00:00Z",
    "end": "2026-02-04T04:00:00Z"
  }
}

Shopify’s certificate management system uses the acme-client Ruby gem originally authored by another Shopify employee. A growing number of ACME clients, including certbot, have enabled support for ARI, but the Ruby gem did not yet support this feature. Rather than building a custom solution, we decided to enable support for the ARI extension directly in the client.

Let’s Encrypt’s guide to integrating ARI provided the necessary roadmap, and the implementation was completed with one PR. This contribution means that not only Shopify, but also the wider Ruby community, can benefit from the ARI extension.

Deployment and ARI at scale

Once we shipped the gem support, integrating ARI into our certificate management system was straightforward. Instead of checking a static 30-day threshold, we now query the ARI endpoint and use the suggested renewal window as the gate for initiating renewals. Those dates are stored alongside the certificate upon its initial provisioning.

The updated Ruby gem provides a method for fetching renewal information:

renewal_info = client.renewal_info(certificate: existing_certificate_pem)

This method generates an ARI certificate identifier that can be used when making the API call. The client also includes a helper method, suggested_renewal_time, which chooses a random time between the returned start and end dates. The certificate identifier can be passed to the new_order method via the replaces key, which can grant a higher priority or bypass rate limits for renewals occurring during the window, depending on the CA’s policies.

Critically, Shopify also regularly polls the ARI endpoint for updated renewal timestamps. This allows our systems to rely on those timestamps as the primary renewal timing logic and removes the need for inflexible hard-coded expiry thresholds. This becomes the mechanism that LetsEncrypt uses to dynamically change the renewal time due to a revocation event.

Results and rewards

Since enabling the use of the ARI extension, our certificate management system has become significantly more robust. Shopify now delegates the responsibility of determining renewal timing to Let’s Encrypt. The ARI extension has proven to be an impactful infrastructure improvement and the benefits gained are immediate. These benefits, alongside fewer manual interventions, are the operational success story:

  • Future-proofing: We gained resilience against any future certificate lifetime changes and mass revocation events without needing code updates—ensuring our renewal logic is flexible.

  • Optimized load: We directly benefit from the CA’s coordinated load balancing provided by the suggested renewal window, eliminating local randomness issues and the need for complex global coordination.

  • Revocation readiness: ARI allows systems to quickly detect and respond to revocation events when an urgent renewal is necessary, well before certificates get close to their due dates.

  • Simple implementation: The extension is mature (RFC 9773) and the implementation is straightforward, providing simplified renewal logic and CA-optimized timing.

  • Good citizenship: Anyone using ARI helps the CA optimize its infrastructure, and contributes to better aggregate behavior across the entire ecosystem.

If you’re still relying on static renewal thresholds, give ARI a look—Shopify wholeheartedly encourages all ACME users and client developers to adopt the ARI extension.

Standing up for the open Internet: why we appealed Italy’s “Piracy Shield” fine

Post Syndicated from Patrick Nemeroff original https://blog.cloudflare.com/standing-up-for-the-open-internet/

At Cloudflare, our mission is to help build a better Internet. Usually, that means rolling out new services to our millions of users or defending the web against the world’s largest cyber attacks. But sometimes, building a better Internet requires us to stand up against laws or regulations that threaten its fundamental architecture.

Last week, Cloudflare continued its legal battle against “Piracy Shield,” a misguided Italian regulatory scheme designed to protect large rightsholder interests at the expense of the broader Internet. After Cloudflare resisted registering for Piracy Shield and challenged it in court, the Italian communications regulator, AGCOM, fined Cloudflare a staggering €14 million (~$17 million). We appealed that fine on March 8, and we continue to challenge the legality of Piracy Shield itself. 

While the fine is significant, the principles at stake are even larger. This case isn’t just about a single penalty; it’s about whether a handful of private entities can prioritize their own economic interests over those of Internet users by forcing global infrastructure providers to block large swaths of the Internet without oversight, transparency, or due process.

What is Piracy Shield?

To understand why we are fighting this, it’s necessary to take a step back and understand Piracy Shield. Marketed by AGCOM as an innovative tool to fight copyright infringement, the system is better understood as a blunt tool for rightsholders to control what is available on the Internet without any traditional legal safeguards.

Piracy Shield is an unsupervised electronic portal through which an unidentified set of Italian media companies can submit websites and IP addresses that online service providers registered with Piracy Shield are then required to block within 30 minutes. Piracy Shield operates as a “black box” because there is:

  • No judicial oversight: Private companies, not judges or government officials, decide what gets blocked.

  • No transparency: The public, and even the service providers themselves, are often left in the dark about who requested a block or why.

  • No due process: There is no mechanism for a website owner to challenge a block before their site becomes unavailable on the Italian web.

  • No redress: Along with a complete lack of transparency or due process, Piracy Shield offers no effective way for impacted parties to seek redress from erroneous blocking.

It’s not entirely surprising that Piracy Shield so clearly prioritizes the economic interests of media companies over the rights of Italian Internet users. The system was “donated” to the Italian government by SP Tech, an arm of the law firm that represents several of Piracy Shield’s major direct beneficiaries, including Lega Nazionale Professionisti Serie A (Italy’s major soccer league).

The high cost of Piracy Shield

Almost immediately after Piracy Shield was rolled out, there were significant problems. In addition to the unworkable 30-minute deadline and the lack of safeguards described above, the scheme requires service providers to engage in IP address blocking. This creates an unavoidable risk of overblocking innocent websites due to the fact that IP addresses are regularly and necessarily shared by thousands of websites. Not surprisingly, within a few months of its launch, Piracy Shield caused major outages for people and businesses who had done nothing wrong. 

Notable failures include:

  • Government and educational blackouts: Tens of thousands of legitimate sites were rendered inaccessible from Italy, including Ukrainian government websites for schools and scientific research.

  • Small business & NGO disruption: A wide range of European small businesses and NGOs focused on social programs for women and children were inadvertently blocked.

  • Loss of essential services: The system blocked access to Google Drive for over 12 hours, preventing thousands of Italian students and professionals from accessing critical files.

  • Persistent collateral blocking: A September 2025 study by the University of Twente confirmed that the system routinely blocks legitimate websites for months at a time.

Even when faced with clear evidence that Piracy Shield has caused significant and repeated overblocking, AGCOM did not change course. Rather, it chose to expand Piracy Shield to apply to global DNS providers and VPNs, services which are closely associated with privacy and free expression. AGCOM also started taking increasingly aggressive steps to force global service providers, even ones with no legal or operational presence in Italy, to register with Piracy Shield.

Cloudflare’s principled challenge

Cloudflare has been clear about the risks posed by Piracy Shield from the beginning. In 2024, we met with AGCOM to highlight the scheme’s structural flaws and consequences and proposed more effective ways to collaborate that wouldn’t break the Internet’s core architecture.  

When these concerns were ignored, we moved on to legal action. We challenged AGCOM’s effort to force Cloudflare to join Piracy Shield in the Italian administrative courts and, along with the Computer & Communications Industry Association (CCIA), we filed a complaint with the European Commission. More informally, we have continued to reach out to government officials both in Italy and at the EU level to explain our position and make our concerns known. Our position has been consistent and remains that Piracy Shield is incompatible with EU law, most notably the Digital Services Act (DSA), which requires that any content restriction be proportionate and subject to strict procedural safeguards.

The European Commission, following our complaint, expressed similar concerns, issuing a letter on June 13, 2025, criticizing the lack of oversight inherent in the Piracy Shield framework. And on December 23, 2025, the Italian administrative court issued an encouraging ruling requiring AGCOM to share with Cloudflare all the records that purportedly support Piracy Shield blocking orders. While we have not yet received those records, we expect them to shed significant light on Piracy Shield’s operations. 

An excessive fine and still no transparency

Rather than awaiting the outcome of our legal challenges, and less than one week after being ordered to disclose Piracy Shield records to Cloudflare, AGCOM moved on December 29, 2025, to issue its fine. The fine’s timing was not the only eyebrow-raising thing about it. The math behind the penalty is as flawed as the system it is seeking to enforce.

Under Italian law, fines for non-compliance are capped at 2% of a company’s revenue within the relevant jurisdiction. Based on Cloudflare’s Italian earnings, that cap should have limited any fine to approximately €140,000. Instead, AGCOM calculated the fine based on our global revenue, resulting in a penalty nearly 100 times higher than the legal limit.

This disproportionate approach sends a chilling message to the global tech community: if you question a flawed regulatory system or defend the rights of your users and the global Internet, you risk facing punitive and excessive financial retaliation.

At the same time, AGCOM still has not shared with Cloudflare the Piracy Shield records that it was ordered to disclose. Instead, just four days before the deadline for disclosure, AGCOM informed us that it would make some of the records available for inspection at an AGCOM facility in Naples, subject to supervision by AGCOM officials. These limitations are not just unreasonably burdensome and contrary to the letter and spirit of the disclosure order; they raise real questions about why AGCOM is so intent on resisting transparency.

Next steps: the path forward

We are not backing down. Cloudflare is appealing the €14 million fine, pushing for full access to AGCOM’s Piracy Shield records, and will continue to challenge the underlying legality of the Piracy Shield blocking orders in the Italian administrative courts.

We recognize that rightsholders have a legitimate interest in protecting their content. In fact, we work with rightsholders every day to address infringement in ways that are precise and effective. But those interests cannot override the basic requirements of legal due process or the technical integrity of the global Internet and our network.

We will continue to pursue this challenge in the Italian courts and through the European Commission. Global connectivity is too important to be governed by “black boxes” with 30-minute deadlines that result in widespread overblocking with no means of redress. Cloudflare remains committed to building a better Internet: one where the rules are transparent, the regulators are accountable, and the infrastructure that connects the world remains free, open, and secure.

Securely connect Kafka clients running outside AWS to Amazon MSK with IAM Roles Anywhere

Post Syndicated from Kalyan Janaki original https://aws.amazon.com/blogs/big-data/securely-connect-kafka-clients-running-outside-aws-to-amazon-msk-with-iam-roles-anywhere/

Kafka clients that are running outside of AWS (on-premises environment or other clouds) would require an IAM user with a long-lived access key to be provided as part of their codebase or in their server configuration. From a security perspective, there is an additional risk if anyone gains access to those long-term credentials, as they would have access to that AWS account.

In this post, we demonstrate how to use AWS IAM Roles Anywhere to request temporary AWS security credentials, using x.509 certificates for client applications which enables secure interactions with an Amazon Managed Streaming for Apache Kafka (Amazon MSK) cluster. The solution described in this post is compatible with both Amazon MSK Provisioned and Serverless clusters.

Introduction to AWS IAM Roles Anywhere

AWS Identity and Access Management (IAM) Roles Anywhere allows you to obtain temporary security credentials in IAM for workloads running outside of AWS, such as servers, containers, and applications.

By using IAM Roles Anywhere, your workloads can utilize the same IAM policies and roles used by AWS applications to access AWS resources. This eliminates the need to manage long-term credentials for kafka clients running outside AWS. By associating one or more roles with a profile and enabling IAM Roles Anywhere to assume these roles, your applications can employ the client certificate issued by your Certificate Authorities (CAs) to securely initiate requests to AWS. Consequently, your applications obtain temporary credentials, granting them access to the AWS environment.

IAM access control for Amazon MSK allows you to manage both authentication and authorization for your Amazon MSK cluster at no extra cost. This eliminates the necessity of using separate mechanisms for authentication and authorization. We recommend Amazon MSK customers use IAM Access Control unless they have a specific need for using mutual TLS or SASL/SCRAM authN/Z.

In the following sections, we show you how to implement a secure Kafka client machine with a detailed step-by-step tutorial using an AWS IAM Roles Anywhere to connect with a MSK Cluster.

Solution overview

The following diagram illustrates the solution architecture.

Architecture diagram showing a hybrid AWS setup where an on-premises MSK client connects to Amazon MSK Provisioned and Serverless clusters via AWS Direct Connect or VPN, using IAM Roles Anywhere, AWS STS, Route 53, and VPC endpoints for secure, private Kafka connectivity.

The flow of the architecture is as follows:

  1. The session token query from your client machine is directed to an AWS IAM Roles Anywhere endpoint, facilitated by the exchange of X.509 certificates.
  2. IAM Roles Anywhere validates the certificate and retrieves a temporary session token from STS, which is then returned to the client machine.
  3. In Amazon MSK Provisioned, the MSK client machine connects to the AWS Transit Gateway or AWS Network Load Balancer in your VPC over AWS VPN or AWS Direct Connect. For more information, refer to Secure connectivity patterns to access Amazon MSK.
  4. In Amazon MSK Serverless, the MSK client machine connects to the interface VPC endpoint in your VPC over AWS VPN or AWS Direct Connect. For more information, refer to Connect to Amazon MSK Serverless from your on-premises network.
  5. In Amazon MSK Serverless , the interface endpoint is a collection of one or more elastic network interfaces with a private IP address within your account. It serves as the entry point for traffic directed towards a MSK Serverless service.

Prerequisites

The instructions provided in this post assume that you are already acquainted with the process of creating an MSK serverless cluster and a client machine. Furthermore, it is presumed that you have successfully accomplished the following tasks:

  1. Create an Amazon MSK serverless cluster or Create an Amazon MSK Provisioned Cluster
  2. Create a MSK client machine in your on-prem data center or a VPC from another AWS account.
  3. Establish network connectivity between on premises and the Amazon MSK Serverless Cluster or Establish network connectivity between on premises and the Amazon MSK Provisioned Cluster

Configure AWS IAM Roles Anywhere

To enable IAM Roles Anywhere for your on-premises Kafka client machine, you must configure two essential components in AWS Roles Anywhere: the trust anchor and the profile. The trust anchor establishes the trust relationship between Roles Anywhere and your certificate authority. This trust is utilized for authenticating certificates to obtain credentials for an IAM role. Profiles are predefined sets of permissions that are applied once successful authentication with Roles Anywhere has been achieved.

Step 1: Generate a CA

An X.509 certificate plays an important role in facilitating communication between the client machine and Roles Anywhere. You can use Public Key Infrastructure (PKI) platform of your choice to establish a certificate authority (CA).

If you prefer to generate your own X.509 client certificate, you can refer to the instructions outlined in IAM Roles Anywhere with an external certificate authority to guide you through the process.

For simplicity of this example, we use an AWS Private CA:

Navigate to the AWS Private CA console.

Create a Root CA

  1. Choose Root as CA type option and put your organization name and organization unit name.
  2. Choose default RSA 2048 key algorithm.
  3. Choose Create CA button to generate a private the CA and install the certificate.

Create a Subordinate CA

  1. Choose Subordinate as CA type option.
  2. Choose default RSA 2048 key algorithm.
  3. Choose Create CA button.
  4. Obtain the CSR from the subordinate CA and have it signed by the root CA.

This CA will be used for issuing certificates to IAM Roles Anywhere.

For generating a more secured and auto-renewed AWS private CA, refer to Procedure for creating a CA and How to build a CA hierarchy.

Step 2: Configure anchor

  1. Go to Roles Anywhere console and open the Create a trust anchor page.
  2. Provide a name for your trust anchor and select the private CA that we created in step 1. If you prefer to use your own external CA, choose the External certificate bundle option and provide the necessary certificate bundle.
  3. Choose create a trust anchor button to finish the process.

Step 3: Create and configure a role that trusts IAM Roles Anywhere

Now we create a role that you want your on-premises Kafka client machine to assume after authenticating to IAM Roles Anywhere.

  1. The trust policy of the role should contain the following: 
    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "rolesanywhere.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:SetSourceIdentity",
        "sts:TagSession"
      ],
      "Condition": {
        "StringEquals": {
          "aws:PrincipalTag/x509Subject/CN": "specific-certificate-common-name"
        }
      }
    }
  ]
}

  2. For this demo, create the following policy and attach it to the role: 
    {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kafka-cluster:Connect",
                "kafka-cluster:AlterCluster",
                "kafka-cluster:DescribeCluster"
            ],
            "Resource": [
                "arn:aws:kafka:<Region>:<Account-ID>:cluster/<Cluster-name>/<Cluster-identifier>"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "kafka-cluster:CreateTopic",
                "kafka-cluster:DescribeTopic",
                "kafka-cluster:WriteData",
                "kafka-cluster:ReadData",
                "kafka-cluster:AlterGroup",
                "kafka-cluster:DescribeGroup"
            ],
            "Resource": [
                "arn:aws:kafka:<Region>:<Account-ID>:cluster/ <Cluster-Name>/<Cluster-identifier>",
                "arn:aws:kafka:<Region>:<Account-ID>:topic/msk-<Cluster-Name>/<Cluster-Identifier>/<Topic-Name> ",
                "arn:aws:kafka:<Region>:<Account-ID>:group/<Cluster-Name>/<Cluster-Identifier>/<Group-Name>"
            ]
        }
    ]
}

Step 4: Setup profile

  1. Navigate back to the Roles Anywhere console.
  2. Under Profiles, choose Create a profile.
  3. Enter a name for the profile.
  4. Select the role we created in Step 3 and create the Roles Anywhere profile.

Step 5: Test the client machine

Now that we have successfully set up Roles Anywhere by creating a trust anchor and a profile, the next step is to test the client machine’s communication with Roles Anywhere. This involves retrieving a session token and establishing communication with the MSK broker.

  1. Request a private certificate from the CA we created in Step 1 and export the client certificates to be used in the client machine.
  2. Create a .pem file and copy all the certificate contents into this .pem file(e.g. private_key. pem) and run below command to generate a decrypted version of certificate. 
    openssl rsa -in private_key.pem -out decrypted_private_key.pem

  3. Download the credential helper and use this signing helper tool to test and confirm the functionality from your client machine. We offer the ARNs of the trust anchor and profile of Roles Anywhere, and the role we created in IAM. 
    ./aws_signing_helper credential-process \
--certificate /path/to/certificate.pem \
--private-key /path/to/decrypted_private_key.pem \
--trust-anchor-arn <TA_ARN> \
--profile-arn <PROFILE_ARN> \
--role-arn <Roles_ARN> \
--region <Region>

    You should receive the session credentials successfully from IAM Roles Anywhere.

  4. After verifying the successful setup, proceed to update or create the ~/.aws/config file. Add the signing helper as a credential_process in this file to enable unattended access for the on-premises server.
    [default] 

    credential_process = ./aws_signing_helper credential-process 
--certificate /path/to/certificate.pem 
--private-key /path/to/decrypted_private_key.pem 
--trust-anchor-arn <TA_ARN> 
--profile-arn <PROFILE_ARN> 
--role-arn <Roles_ARN>
--region <Region>

Once all steps are done, you should be able to see the Kafka client communicating to the MSK broker.

./kafka-topics.sh --create \
--bootstrap-server <BOOTSTRAP_SERVER> \
--command-config <Command Config File> \
--replication-factor <Replication Factor> \
--partitions <Number of Partitions> \
--topic <Topic Name>

Clean up

To stop incurring costs, it is recommended to manually delete the IAM Role, Profile, Trust Anchor, Policies, requested certificate in ACM and created certificates in AWS Private CA.

aws delete-role --role-name <value>

aws delete-profile --profile-id <value>

aws delete-trust-anchor --trust-anchor-id <value>

aws acm delete-certificate --certificate-arn <value>

aws acm-pca revoke-certificate --certificate-authority-arn <value> --certificate-serial <value> --revocation-reason <value> 

aws acm-pca delete-certificate --certificate-authority-arn <value> --certificate-serial <value>

Conclusion

In this post, we showed you how to utilize AWS IAM Roles Anywhere to generate temporary session tokens for accessing MSK brokers from client machines outside of AWS. By implementing this approach, the security posture of Kafka clients connecting to MSK from outside of AWS are enhanced, allowing customers with stringent security requirements to confidently adopt MSK.

If you have any questions, you can start a new thread on AWS re:Post or reach out to AWS Support.

About the authors

Ankit Mishra

Ankit Mishra

Ankit is a Senior Solutions Architect at Amazon Web Services, where he helps customers design and build secure, scalable, reliable, and cost-effective cloud solutions. Outside of work, Ankit enjoys spending time with his wife and little daughter.

Tony Anastasio

Tony Anastasio

Tony is a Senior Solutions Architect Manager on the Global Healthcare team at AWS. He leads teams of architects driving innovation across data interoperability, AI solutions, and secure cloud foundations for some of the industry’s largest healthcare organizations. In his spare time, Tony enjoys spending time with his wife and two children.

Kalyan Janaki

Kalyan Janaki

Kalyan is Senior Big Data & Analytics Specialist with Amazon Web Services. He helps customers architect and build highly scalable, performant, and secure cloud-based solutions on AWS.

Debian Project Leader election underway

Post Syndicated from jzb original https://lwn.net/Articles/1063115/

Kurt Roeckx has announced
that Debian has moved to the campaigning period for the 2026 Debian
Project Leader (DPL) election. This year there is only one candidate,
Sruthi Chandran, so Debian voters will have a choice between Chandran
as DPL or “None of the above”. The campaign period will run through
April 3, and the voting period will run from April 4 to
April 17. Chandran has not yet posted a platform for the 2026
election, but her 2024
platform is available on the Debian wiki.

GIMP 3.2 released

Post Syndicated from jake original https://lwn.net/Articles/1063111/

After a year’s worth of development since GIMP 3.0 was released,
the team behind the open-source image editor has released
GIMP 3.2. It comes as part of the plan
to release GIMP more frequently, rather than wait six or seven years
between releases. The release comes with lots of new features (as can
be seen in more detail in the release notes),
including 20 new brushes for the MyPaint Brush tool, an “overwrite” paint
mode, new and upgraded file formats, UI improvements in a variety of
places, such as the on-canvas text editor, and new non-destructive layers:

  • You can now use Link Layers to incorporate external image as
    part of your compositions, easily scaling, rotating, and transforming them
    without losing quality or sharpness. The link layer’s content is updated
    when the source file is modified

  • The Path tool can now create Vector Layers, which lets you draw
    shapes with adjustable fill and stroke settings.

AWS Weekly Roundup: Amazon S3 turns 20, Amazon Route 53 Global Resolver general availability, and more (March 16, 2026)

Post Syndicated from Esra Kayabali original https://aws.amazon.com/blogs/aws/aws-weekly-roundup-amazon-s3-turns-20-amazon-route-53-global-resolver-general-availability-and-more-march-16-2026/

Twenty years ago this past week, Amazon S3 launched publicly on March 14, 2006. While Amazon Simple Storage Service is often considered the foundational storage service that defined cloud infrastructure, what began as a simple object storage service has grown into something far larger in scope and scale.

As of March 2026, S3 stores more than 500 trillion objects, serves more than 200 million requests per second globally across hundreds of exabytes of data, and the price has dropped to just over 2 cents per gigabyte — an approximately 85% reduction since launch. My colleague Sébastien Stormacq wrote a detailed look at the engineering and the road ahead in Twenty years of Amazon S3 and building what’s next, and if you want to read about those earliest customers and how they shaped what AWS became, I recommend How three startups helped Amazon invent cloud computing and paved the way for AI. Twenty years is worth pausing to celebrate.

Alongside the 20th anniversary of S3, Channy Yun also wrote about a new S3 feature this week: Account regional namespaces for Amazon S3 general purpose buckets. With this feature, you can create general purpose buckets in your own account regional namespace by appending your account’s unique suffix to your requested bucket name, ensuring your desired names are always reserved exclusively for your account. You can enforce adoption across your organization using AWS IAM policies and AWS Organizations service control policies with the new s3:x-amz-bucket-namespace condition key. Read Channy’s post to learn more about account regional namespaces for Amazon S3 general purpose buckets.

This week’s featured launch is one I have a personal connection to: the general availability of Amazon Route 53 Global Resolver. I wrote about the preview of this capability back in December at re:Invent 2025, and I had a great time putting that post together, so I am happy to hear that it’s generally available now.

Amazon Route 53 Global Resolver is an internet-reachable anycast DNS resolver that provides DNS resolution for authorized clients from any location. It is now generally available across 30 AWS Regions, with support for both IPv4 and IPv6 DNS query traffic. Route 53 Global Resolver gives authorized clients in your organization anycast DNS resolution of public internet domains and private domains associated with Route 53 private hosted zones — from any location, not just from within a specific VPC or Region. It also provides DNS query filtering to block potentially malicious domains, domains that are not safe for work, and domains associated with advanced DNS threats such as DNS tunneling and Domain Generation Algorithms (DGA). Centralized query logging is included as well. With general availability, Global Resolver adds protection against Dictionary DGA threats.

Last week’s launches
Here are some of the other announcements from last week:

  • Amazon Bedrock AgentCore Runtime now supports stateful MCP server features — Amazon Bedrock AgentCore Runtime now supports stateful Model Context Protocol (MCP) server features, enabling developers to build MCP servers that use elicitation, sampling, and progress notifications alongside existing support for resources, prompts, and tools. With stateful MCP sessions, each user session runs in a dedicated microVM with isolated resources, and the server maintains session context across multiple interactions using an Mcp-Session-Id header. Elicitation enables server-initiated, multi-turn conversations to gather structured input from users during tool execution. Sampling allows servers to request LLM-generated content from the client for tasks such as personalized recommendations. Progress notifications keep clients informed during long-running operations. To learn more, see the Amazon Bedrock AgentCore documentation.
  • Amazon WorkSpaces now supports Microsoft Windows Server 2025 — New bundles powered by Microsoft Windows Server 2025 are now available for Amazon WorkSpaces Personal and Amazon WorkSpaces Core. These bundles include security capabilities such as Trusted Platform Module 2.0 (TPM 2.0), Unified Extensible Firmware Interface (UEFI) Secure Boot, Secured-core server, Credential Guard, Hypervisor-protected Code Integrity (HVCI), and DNS-over-HTTPS. Existing Windows Server 2016, 2019, and 2022 bundles remain available. You can use the managed Windows Server 2025 bundles or create a custom bundle and image. This support is available in all AWS Regions where Amazon WorkSpaces is available. For more information, visit the Amazon WorkSpaces FAQs.
  • AWS Builder ID now supports Sign in with GitHub and Amazon — AWS Builder ID now supports two additional social login options: GitHub and Amazon. These options join the existing Google and Apple sign-in capabilities. With this update, developers can access their AWS Builder ID profile — and services including AWS Builder Center, AWS Training and Certification, and Kiro — using their existing GitHub or Amazon account credentials, without managing a separate set of credentials. To learn more and get started, visit the AWS Builder ID documentation.
  • Amazon Redshift introduces reusable templates for COPY operations — Amazon Redshift now supports templates for the COPY command, allowing you to store and reuse frequently used COPY parameters. Templates help maintain consistency across data ingestion operations, reduce the effort required to execute COPY commands, and simplify maintenance by applying template updates automatically to all future uses. Support for COPY templates is available in all AWS Regions where Amazon Redshift is available, including the AWS GovCloud (US) Regions. To get started, see the documentation or read the Standardize Amazon Redshift operations using Templates blog.

For a full list of AWS announcements, be sure to keep an eye on our News Blog channel the What’s New with AWS page.

Upcoming AWS events
Check your calendar and sign up for upcoming AWS events:

AWS Summits – Join AWS Summits in 2026, free in-person events where you can explore emerging cloud and AI technologies, learn best practices, and network with industry peers and experts. Upcoming Summits include Paris (April 1), London (April 22), and Bengaluru (April 23–24).

AWS Community Days – Community-led conferences where content is planned, sourced, and delivered by community leaders, featuring technical discussions, workshops, and hands-on labs. Upcoming events include Pune (March 21), San Francisco (April 10), and Romania (April 23-24).

AWS at NVIDIA GTC 2026 — Join us at our AWS sessions, booths, demos, and ancillary events in NVIDIA GTC 2026 on March 16 – 19, 2026 in San Jose. You can receive 20% off event passes through AWS and request a 1:1 meeting at GTC.

AWS Community GameDay Europe — Taking place on March 17, 2026, AWS Community GameDay Europe is a team-based, hands-on AWS challenge event running simultaneously across 50+ cities in Europe. Your team is dropped into a broken AWS environment — misconfigured services, failing architectures, and security gaps — and has two hours to fix as much as possible. Find your nearest city and sign up at awsgameday.eu.

Join the AWS Builder Center to connect with builders, share solutions, and access content that supports your development. Browse here for upcoming AWS-led in-person and virtual events and developer-focused events.

That’s all for this week. Check back next Monday for another Weekly Roundup!

— Esra

This post is part of our Weekly Roundup series. Check back each week for a quick roundup of interesting news and announcements from AWS!

NVIDIA GTC 2026 Keynote Live Coverage

Post Syndicated from Ryan Smith original https://www.servethehome.com/nvidia-gtc-2026-keynote-live-coverage/

It is that time of the year again. No, not Christmas (unless you are an AI developer, at any rate), but rather NVIDIA’s annual GTC conference for all things NVIDIA. As has become an annual tradition for us at STH, we are are covering the 2026 GTC keynote live, to catch all the latest and […]

The post NVIDIA GTC 2026 Keynote Live Coverage appeared first on ServeTheHome.

Rapid7 Guidance on Observed Microsoft Teams Phishing Campaigns

Post Syndicated from Brett Deroche original https://www.rapid7.com/blog/post/dr-guidance-on-observed-microsoft-teams-phishing-campaigns

The Rapid7 MDR team is currently monitoring an increase in phishing campaigns where threat actors (TAs) impersonate internal IT departments via Microsoft Teams. The primary objective is to persuade users to launch Quick Assist, granting the TA remote access to deploy malware, exfiltrate data, or facilitate lateral movement across the network.

Social engineering via IT Support impersonation is not a new threat, but the recent surge in Teams-based delivery highlights a critical vulnerability in how organizations manage external access. Teams often allows any external user to message internal staff. This is the functional equivalent of operating an email server without a gateway filter. While a cautious user might notice an “External” tag on the chat, the inherent trust placed in collaboration tools often overrides standard security instincts, granting threat actors a direct, high-trust channel to your end users.

Threat overview

The attack we’ve observed typically follows a specific sequence of events:

  1. Initial contact: The threat actor sends spoofed Microsoft Teams chat requests to multiple users within an environment, simultaneously. These often appear to come from “IT Support,” “System Admin,” or other spoofed internal aliases.

  2. Engagement: Once a user accepts the chat request, the threat actor initiates a conversation under the pretext of IT support offering computer support, such as “fixing a technical issue” or “performing a security update.”

  3. Exploitation: The threat actor requests the user to launch Quick Assist. Once the connection is established, the TA gains remote access to the machine, allowing them to deploy malware, exfiltrate data, or move laterally through the network.

What you should do now

To protect your environment from this activity, Rapid7 recommends the following technical controls:

Harden Microsoft Teams settings

In the Teams Admin Center, limit external communications to “Only allowed domains.” This prevents random external tenants from messaging your employees unless they are on an approved allowlist. In addition, Rapid7 recommends disabling the ability for users to communicate with external Teams users who are not managed by an organization. 

If your business doesn’t require cold outreach from external vendors, toggle off “Allow External Users to Start Conversations” to ensure only your users can initiate outside chats. If your business does require this functionality more broadly, consider implementing Spoof Intelligence.

Implement automatic blocking of spoofed Teams messages

Enable Spoof Intelligence within your Microsoft 365 security settings. This feature automatically detects and blocks senders who are not who they claim to be. This feature works by identifying and managing senders that fail SPF/DKIM/DMARC. If you have known senders who don’t have these configured, ensure you set the appropriate exceptions.

Disable/harden Quick Assist 

Rapid7 recommends removing or disabling Microsoft Quick Assist if it is not required within your environment. This can be achieved via Group Policy Object (GPO) blocking the application, blocking network traffic to the Quick Assist domain, or uninstalling the Quick Assist package.

Watch for red flags

Train staff to recognize these specific “Teams spoofing” hallmarks:

  • The “external” tag: Remind users to look for the (external) tag next to a name. Real internal IT support will never have this tag.

  • Sense of urgency: Attackers often claim there is a “security breach” or “expired password” to rush the user into bypassing safety protocols.

  • Out-of-band verification: Establish a policy that IT will never initiate a support session via a cold-call Teams chat without a pre-existing ticket number. If a user is unsure, IT should have a pre-established process in place for a user to validate the requestor’s identity.

Rapid7 customers

We are continually monitoring your environment for related activity. Below is a non-exhaustive list of detections that are deployed:

  • Suspicious Chat Request – Potential Social Engineering Attempt

  • Suspicious Conversation – Potential Social Engineering Message Interaction

  • Initial Access – Potential Social Engineering Session Initiated Following Chat Request

  • Suspicious Chat Request – Multiple Users Contacted by Foreign Tenant via Default Tenant Domain

  • Initial Access – Microsoft Teams Remote Control Granted to Suspicious External Account

Rapid7 MDR is here to support your team, strengthen your defenses, and help you stay ahead of adversaries attempting to use this tactic to gain access to your environment. Learn more about our service here.

[$] A safer kmalloc() for 7.0

Post Syndicated from corbet original https://lwn.net/Articles/1062856/

A pull request that touches over 8,000 files, changing over 20,000 lines of
code in the process, is (fortunately) not something that happens every day.
It did happen at the end of the 7.0 merge window, though, when Linus
Torvalds merged
an extensive set of changes by Kees Cook to the venerable kmalloc() API (and
its users). As a result of that work, though, the kernel has a new set of
type-safe memory-allocation functions, with a last-minute bonus change to
make the API a little easier to use.

From Threat Detection to Response: What to Expect from Our MDR Sessions

Post Syndicated from Emma Burdett original https://www.rapid7.com/blog/post/it-threat-detection-response-mdr-sessions-global-cybersecurity-summit

Detection and response are under pressure. Expanding attack surfaces, identity misuse, cloud sprawl, and AI-accelerated threats have changed what “ready” looks like for a SOC. That’s why this year’s Global Cybersecurity Summit places Continuous Threat Defense at the center of the conversation.

The focus is clear: this is what modern MDR looks like when it’s designed to disrupt attackers earlier, not just react to them faster.

2026 MDR sessions: A sneak peek

Throughout the summit, several sessions will explore how detection and response are evolving in practice. In this year’s “Inside the Modern SOC”, we’ll look at how response actually unfolds when pressure is high and decisions matter. It’s a close examination of ownership, escalation, and how teams coordinate across endpoint, identity, and cloud telemetry.

In “Using Red Teaming to Power Preemptive MDR”, the conversation shifts upstream. Rather than treating red teaming as a compliance exercise, this session examines how continuous testing strengthens detection coverage and validates response workflows before a real attacker forces the issue.

For the executive leaders “A CISO’s Guide to MDR Accountability and Outcomes” will examine MDR through a leadership lens, describing how leaders can best evaluate performance, define success, and ensure response strategies hold up under scrutiny. As detection models grow more complex, clarity around accountability can become just as important as technical capability.

For hands-on practitioners, “Hunt or Be Hunted: Frontline Tales of Detection” offers a scenario-driven walkthrough of how SOC analysts triage signals, manage handoffs, and make decisions under real operational pressure. Meanwhile,” IR in Practice: Tools, Tradecraft, and Adversary-Informed Investigation” provides a deeper look at investigative workflows, including practical use cases and adversary-informed response approaches.

What preemptive MDR really means

Together, these sessions represent part of a broader theme: Preemptive Security Operations is not about adding more tools or generating more alerts. It is about reducing uncertainty, aligning exposure with detection, and building workflows that allow teams to act with confidence.

And this is only a preview. Additional sessions, speakers, and perspectives will continue to be announced as the summit approaches.

If you’re responsible for detection strategy, response readiness, or MDR governance, this track is designed to meet you where you operate. Join us May 12–13 and be part of the shift toward more confident, preemptive security operations.

Register now

Security updates for Monday

Post Syndicated from jzb original https://lwn.net/Articles/1063095/

Security updates have been issued by AlmaLinux (.NET 10.0, .NET 8.0, .NET 9.0, delve, git-lfs, gnutls, kernel, mingw-libpng, nfs-utils, opentelemetry-collector, python3.11, python3.12, python3.9, and vim), Debian (chromium, gimp, kernel, linux-6.1, and wireless-regdb), Fedora (alertmanager, chromium, freerdp, glab, golang-github-openprinting-ipp-usb, gst-devtools, gst-editing-services, gstreamer1, gstreamer1-doc, gstreamer1-plugin-libav, gstreamer1-plugins-bad-free, gstreamer1-plugins-base, gstreamer1-plugins-good, gstreamer1-plugins-ugly-free, gstreamer1-rtsp-server, insight, pcs, pgadmin4, python-gstreamer1, python3.10, python3.11, python3.6, qgis, SDL2_sound, SDL3_sound, systemd, and wireshark), Mageia (python-nltk, tomcat, and vim), Oracle (.NET 10.0, .NET 8.0, .NET 9.0, compat-openssl11, dtrace, python3.12, and vim), Red Hat (buildah, git-lfs, golang-github-openprinting-ipp-usb, opentelemetry-collector, podman, and runc), and SUSE (amazon-ssm-agent, busybox, clamav, firefox, giflib-devel-32bit, glibc, heroic-games-launcher, himmelblau, kubelogin, libpng15, libsoup, libsoup2, mingw32-binutils, mingw64-binutils, osc, obs-scm-bridge, python, python-black, python3, qemu, ruby4.0-rubygem-actioncable, ruby4.0-rubygem-actiontext, ruby4.0-rubygem-activejob, ruby4.0-rubygem-activemodel, tomcat, and tomcat10).

The collective thoughts of the interwebz