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

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?

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!

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

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 [...]

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.

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

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!

"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/

"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. "

This is an excellent series on container security fundamentals by Rory McCune who is a bit of an authority in this field:

• part 1
• part 2
• part 3
• part 4

Very useful collection of security incidents involving public clouds

(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 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