Cloud Security
- Track AWS IAM changes in Git with CloudTrail Attribution
I wanted to share a recent blog post we've put together on IAMbic Change Detection with Cloudtrail logging and attribution. If you've ever found IAM changes in AWS challenging to track, this is for you. In IAMbic, all changes get their own Git commit, regardless if they were made using Terraform/Cloudformation/Console Clicking/etc. The new CloudTrail logging integration which provides an even deeper insight into every modification all within Git.
Give it a read and please give us feedback!
https://www.noq.dev/blog/iambic-bridging-the-gap-between-iam-changes-and-version-control
- Pawning your users to Cloudflare is not how you offer your users security; fedi admins must realize this.
cross-posted from: https://lemmy.dbzer0.com/post/1491194
> I would love if just once an admin of a fedi host under DDoS attack would have the integrity to say: > > “We are under attack. But we will not surrender to Cloudflare & let that privacy-abusing tech giant get a front-row view of all your traffic while centralizing our decentralized community. We apologize for the downtime while we work on solving this problem in a way that uncompromisingly respects your privacy and does not harm your own security more than the attack itself.” > > This is inspired by the recent move of #LemmyWorld joining Cloudflare’s walled garden to thwart a DDoS atk. > > So of course the natural order of this thread is to discuss various Cloudflare-free solutions. Such as: > > 1. Establish an onion site & redirect all Tor traffic toward the onion site. > 1.1. Suggest that users try the onion site when the clearnet is down— and use it as an opportunity to give much needed growth to the Tor network. > 2. Establish 3+ clearnet hosts evenly spaced geographically on VPSs. > 2.1. Configure DNS to load-balance the clearnet traffic. > 3. Set up tar-pitting to affect dodgy-appearing traffic. (yes I am doing some serious hand-waving here on this one… someone plz pin down the details of how to do this) > 4. You already know the IPs your users use (per fedi protocols), so why not use that info to configure the firewall during attacks? (can this be done without extra logging, just using pre-existing metadata?) > 5. Disable all avatar & graphics. Make the site text-only when a load threshold is exceeded. Graphic images are what accounts for all the heavy-lifting and they are the least important content. (do fedi servers tend to support this or is hacking needed?) > 6. Temporarily defederate from all nodes to focus just on local users being able to access local content. (not sure if this makes sense) > 7. Take the web client offline and direct users to use a 3rd party app during attacks, assuming this significantly lightens the workload. > 8. Find another non-Cloudflared fedi instance that has a smaller population than your own node but which has the resources for growth, open registration, similar philosophies, and suggest to your users that they migrate to it. Most fedi admins have figured out how to operate without Cloudflare, so promote them. > > ^ This numbering does /not/ imply a sequence of steps. It’s just to give references to use in replies. Not all these moves are necessarily taken together. > > What other incident response actions do not depend on Cloudflare?
- How to verify if CrowdSec is properly configured?
Hello Community!
I installed CrowdSec bare -metal and alongside three bouncers:
- /reverse-proxy
- /cs-firewall-bouncer-1690453608v0.0.27
- /FirewallBouncer-QkP4AkuXfayzknrO4fTT8U2yjG3jHFfa
So far, so good! But I'm running the official Nextcloud web app inside some docker container with the jwilder/nginx-proxy docker image. How do I know if CrowdSec is properly configured? I already added the nginx logs inside the acquis.yml, but I'm worried. Because there seems to be a difference with just analyzing logs and installing a bouncer. (I tried multiple times and searched alot, but cannot find the answer for installing CrowdSec bouncer with jwilder's nginx image.)
Thanks in advance!
- Bad.Build: A Critical Privilege Escalation Design Flaw in Google Cloud Build Enables a Supply Chain Attackorca.security Bad.Build: A Critical Privilege Escalation Design Flaw in Google Cloud Build Enables a Supply Chain Attack
The Orca Research Pod discovered Bad.Build, a vulnerability in the Google Cloud Build service that enabled attackers to gain access to and escalate privileges.
- ALFA: Automated Audit Log Forensic Analysis for Google Workspacegithub.com GitHub - invictus-ir/ALFA: ALFA stands for Automated Audit Log Forensic Analysis for Google Workspace. You can use this tool to acquire all Google Workspace audit logs and to perform automated forensic analysis on the audit logs using statistics and the MITRE ATT&CK Cloud Framework
ALFA stands for Automated Audit Log Forensic Analysis for Google Workspace. You can use this tool to acquire all Google Workspace audit logs and to perform automated forensic analysis on the audit ...
cross-posted from: https://infosec.pub/post/397812
> Automated Audit Log Forensic Analysis (ALFA) for Google Workspace is a tool to acquire all Google Workspace audit logs and perform automated forensic analysis on the audit logs using statistics and the MITRE ATT&CK Cloud Framework. > > By Greg Charitonos and BertJanCyber
- Building Chainguard's container image registrywww.chainguard.dev Building Chainguard's container image registry
We built a passwordless container image registry with a focus on security to sustain the foundation for ongoing product growth & feature additions for our users. Everything you need to know about securing the software supply chain.
>We’ve made a few changes to the way we host and distribute our Images over the last year to increase security, give ourselves more control over the distribution, and most importantly to keep our costs under control [...]
- Kubernetes Security Basics Series Part I - Deployment and Container Orchestration
>This first post in a 9-part series on Kubernetes Security basics focuses on DevOps culture, container-related threats and how to enable the integration of security into the heart of DevOps.
- Beyond the AWS Security Maturity Roadmapspeakerdeck.com Beyond the AWS Security Maturity Roadmap
Scott (Piper)’s AWS Security Maturity Roadmap is the definitive resource for cloud-native companies to build a security program and posture in AWS. It d…
This gives a great overview of when to build, buy, or adopt an open source solution for a few different common cloud security challenges.
The talk can be seen here: https://youtu.be/JCphc30kFSw?t=2140
- Kubernetes Grey Zone: Risks in Managed Cluster Middlewarewww.wiz.io Kubernetes Grey Zone: Risks in Managed Cluster Middleware | Wiz Blog
Are your managed Kubernetes clusters safe from the risks posed by middleware components? Learn how to secure your clusters and mitigate middleware risks.
- Crying Out Cloud: a magical podcast for cloud security enthusiastswww.wiz.io Crying Out Cloud: a magical podcast for cloud security enthusiasts | Wiz Blog
Join us for game-changing news, unique Wiz insights, and battle-tested advice from industry experts. Stay ahead of the cloud curve with our latest episodes and navigate the complex world of cloud security.
Normally I wouldn't recommend a vendor based podcast, but Wiz is doing really cool stuff in the cloud security space so I'm inclined to give them a chance!
- Writeup: AWS API Gateway header smuggling and cache confusionsecurityblog.omegapoint.se Writeup: AWS API Gateway header smuggling and cache confusion
In this blog, we'll dive deeply into two potential security issues that Omegapoint identified in AWS API Gateway authorizers. We reported these issues to AWS in November 2022 and January 2023. AWS rolled out mitigations to all AWS customer accounts in May 2023.
"This allowed us to completely bypass the application’s tenant isolation and access data from any tenant in the system"
Official announcement from AWS: https://aws.amazon.com/blogs/security/removing-header-remapping-from-amazon-api-gateway-and-notes-about-our-work-with-security-researchers/
- Exploring Firecracker MicroVMs for Multi-Tenant Dagger CI/CD Pipelineswww.felipecruz.es Exploring Firecracker MicroVMs for Multi-Tenant Dagger CI/CD Pipelines
I've been experimenting with the feasibility of running Dagger CI/CD pipelines isolated from each other using Firecracker microVMs to provide a strong security model in a multi-tenant scenario. When customer A runs a pipeline, their containers are executed in an isolated environment.
- Securing the EC2 Instance Metadata Servicesecuritylabs.datadoghq.com Misconfiguration Spotlight: Securing the EC2 Instance Metadata Service | Datadog Security Labs
A look at how the EC2 Instance Metadata Service can be taken advantage of.
- Toyota admits to yet another cloud leakwww.theregister.com Toyota admits to yet another cloud leak
Also, hackers publish RaidForum user data, Google's $180k Chrome bug bounty, and this week's vulnerabilities
"Toyota said it had no evidence the data had been misused, and that it discovered the misconfigured cloud system while performing a wider investigation of Toyota Connected Corporation's (TC) cloud systems.
TC was also the site of two previous Toyota cloud security failures: one identified in September 2022, and another in mid-May of 2023.
As was the case with the previous two cloud exposures, this latest misconfiguration was only discovered years after the fact. Toyota admitted in this instance that records for around 260,000 domestic Japanese service incidents had been exposed to the web since 2015. The data lately exposed was innocuous if you believe Toyota – just vehicle device IDs and some map data update files were included. "
- Container security fundamentals seriessecuritylabs.datadoghq.com Container security fundamentals: Exploring containers as processes | Datadog Security Labs
A look at how containers work as Linux processes and what that means for security.
- Public Cloud Security Breacheswww.breaches.cloud Public Cloud Security Breaches
Breaches.cloud - Your Source for Public Cloud Security Mistakes
Very useful collection of security incidents involving public clouds
- How to get rid of AWS access keys- Part 1: The easy winswww.wiz.io How to get rid of AWS access keys- Part 1: The easy wins | Wiz Blog
Learn how to identify unused and unnecessary long-lived IAM User access keys.
(I am not fond on vendor's blogs as the signal to noise ratio is very low, since they are written to please search engines more than engineers... but Scott Piper gets a pass.)
I found this insightful, access keys are such a liability that is better to tame as early as possible. Fixing the problem a scale is a lot more challenging.
- fwd:cloudsec live streamwww.youtube.com fwd:cloudsec
fwd:cloudsec is a non-profit, conference on cloud security. At this conference you can expect discussions about all the major cloud platforms, both attack and defense research, limitations of security features, the pros and cons of different security strategies, and generally the types of things clo...
fwd:cloudsec is by far ny favorite cloud security conference. Day one has already passed (sessions are recorded) and day 2 is about to start.
See schedule at: https://fwdcloudsec.org/schedule.html