undefined | Better HN

0 pointsmdaniel1y ago0 comments

I spent a few seconds clicking into it before the newfound 429 responses from GitHub caused me to lose interest

I believe a sufficiently sophisticated attacker could unwind the netfilter and DNS change, but in my experience every action that you're taking during a blind attack is one more opportunity for things to go off the rails. The increased instructions (especially ones referencing netfilter and DNS changes) also could make it harder to smuggle in via an obfuscated code change (assuming that's the attack vector)

That's a lot of words to say that this approach could be better than nothing, but one will want to weigh its gains against the onoz of having to keep its allowlist rules up to date in your supply chain landscape

0 comments

1 comments · 1 top-level

fallard1y ago

Hey, I'm one of the co-author of Bullfrog. As you say, a sophisticated and targeted attack could indeed bypass our action. It's meant for blocking mostly opportunistic attacks.

I don't think any egress filtering could properly block everything, given actions will need to interact with Github APIs to function and it would always be possible to exfiltrate data in any private repo hosted on Github. While some solutions can access the outbound HTTP requests payload before it gets encrypted using eBPF, in order to detect egress to untrusted Github org/repos, this isn't a silver bullet either because this relies on targeting specific encryption binaries used by the software/OS. A sophisticated attack could always use a separate obscure or custom encryption binaries to evade detection by eBPF based tools.

So like you say, it's better than nothing, but it's not perfect and there are definitely developer experience tradeoff in using it.

PS: I'm no eBPF expert, so I'd be happy if someone can prove me wrong on my theory :)

j / k navigate · click thread line to collapse