News for hackers. Stuff that matters.
Re:Cleaning Up Dead Bodies in AWS IAM by bravetraveler on Monday August 28, 2023 @01:51PM (#37297885)
I'm still on the platform side, out of K8s and the like - but this is so painfully true.

They try to tailor a lot of these things to the OS/distribution, but fail in the most wonderful ways.

A recent example: they're aware of RHEL. They're also aware of 'firewalld'.

However, they have not managed to realize that this is simply a management interface to other firewalls -- imposing standards on a long-deprecated backend; iptables

Meanwhile, using incredibly inefficient and 'portable' command lines. ie: using find in such a way that an LDAP query happens for every file

Refusing to use the arguments available to the operating system they 'tailor' for. Ultimately timing out once you hold a certain number of files.

Re:Cleaning Up Dead Bodies in AWS IAM by res0nat0r on Monday August 28, 2023 @02:11PM (#37298222)
Also having to explain to checkbox checkers, that yes in fact we are using AMI's that are not owned by our organization, and that in fact shouldn't be showing up as a risk. We are in fact using the AWS managed AMI for our EKS cluster, because that is the entire point.
Re:Cleaning Up Dead Bodies in AWS IAM by eddd-ddde on Monday August 28, 2023 @01:54PM (#37297950)
I find interesting the last example with find and ldap queries. I'm not too familiar with ldap, but i do use find frequently. Could you expand on the example and what happens and why it's bad?
Re:Cleaning Up Dead Bodies in AWS IAM by bravetraveler on Monday August 28, 2023 @02:00PM (#37298043)
Certainly! In this case, they were interested in files that were too permissive.

I don't have a good example of the command, but it was basically looking for 'worldly' permissions that were too open. It's important to note the users/groups could be discarded/ignored.

They were using 'find ... -exec ls -ld {} \;', which does an LDAP lookup on each result.

They could have made the process far more efficient with either the native '-ls' argument built into find, or adding '-n' to the exec'd 'ls'

Either would skip the domain. At a certain number of results/files the expense is too high, causing the job to time out

Re:Cleaning Up Dead Bodies in AWS IAM by eddd-ddde on Monday August 28, 2023 @03:16PM (#37299102)
Conincidentaly I just found a book in the office on understanding and deploying ldap directory services, seems like today is gonna be spent reading!
Re:Cleaning Up Dead Bodies in AWS IAM by bravetraveler on Monday August 28, 2023 @09:29PM (#37302456)
Best of luck to you! I've been around them for over a decade now, and still can't commit the various services to memory.

I like to call what I do "taking the coward's way out" -- using FreeIPA

My team setup the infrastructure in question and I've been too slow to learn it. FreeIPA is nice for quick/easy deployments.

I'm not sure how well it "scales", but it's great for getting comfortable with the "Domain Language" (sorry, pun)

Re:Cleaning Up Dead Bodies in AWS IAM by res0nat0r on Monday August 28, 2023 @05:28PM (#37300624)
I think correctly configuring nscd should prevent this, ie it should cache some of these name lookups for a period of time. As long as it is properly setup for LDAP to hook into it.

https://linux.die.net/man/8/nscd

Re:Cleaning Up Dead Bodies in AWS IAM by bravetraveler on Monday August 28, 2023 @05:46PM (#37300801)
I suspect you're right, I'm not as familiar with our configuration (or the service) as I'd like to be
Re:Cleaning Up Dead Bodies in AWS IAM by TheNewsIsHere on Thursday August 31, 2023 @04:07AM (#37333937)
Sounds like a spectacular self-DDoS on your LDAP infrastructure if that thing ever got deployed too widely and ran at the same time everywhere.