Hacker News Reader

Comment by res0nat0r | Hacker News Reader

I'm dealing with the same type of nonsense currently, as an internal audit team sees security groups being flagged by the scanning software that are open to 0.0.0.0/0 which is automatically "bad", even though the hosts have no public IP's and are being automatically managed by EKS to setup links to k8s NodePorts and the ELB.

Same with security groups. Gartner has some "best practice" doc somewhere, someone loads that into a security tool, the tool flags things, and these checkboxes must go from red to green. The technical hurdles to comply or actual value do not matter.

View on HN

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.

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?

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 to resolve UIDs and GIDs to names.

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 name resolution/domain. At a certain number of results/files the expense is too high, causing the job to time out

Conincidentaly I just found a book in the office on understanding and deploying ldap directory services, seems like today is gonna be spent reading!

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)

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

I suspect you're right, I'm not as familiar with our configuration (or the service) as I'd like to be

The 'ls' output is honestly superfluous, though - 'find' will report the paths.

I won't even get into how these are batched/time limited. If not this, it'd be something else eventually

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.

Dumping audit reports with a sea of red on delivery teams for things largely low-risk in reality and out of their control rarely does any good.

I'm not up on EKS-ELB these days, but if the nodes only allow ingress to NodePorts from the ELB, then it seems like those findings should be suppressed in most orgs.

If the SecEng team was partnering with the delivery team they'd know that before sending the report.

Reply on news.ycombinator.com