mreithub

"Beginning in February of 2018, communication over DigitalOcean Private Network IPs will be isolated within the account or team where they were created"

Great news, definitely a step in the right direction. The fact that DO's "private network" isn't really private is something that's not very well known I think (try googling for the topic).

Until then: Use DO firewalls to whitelist only the services connections you want. Their firewalls treat private and public networks equally -> no more publicly accessible NoSQL databases :)

Hi, manuel from ondevice here.

That's what happens internally (so yes, you could for example use `ProxyCommand ondevice pipe %h ssh` for other tools in the ssh ecosystem - e.g. in your `.ssh/config`).

Hi, Manuel from ondevice here.

Here's a rough explanation:

- ondevice makes use of `ssh`'s `-oProxyCommand`, which makes ssh send its protocol data to a command's stdin and expect the responses on its stdout (you can use that for example to get around certain proxy servers using `nc`)

- `ondevice ssh` basically executes `ssh -oProxyCommand=ondevice pipe %h $@` (there's a bit more to it, but that's the gist) - internally `ondevice pipe` creates a websocket connection to the ondevice API servers, who in turn tell the device (where `ondevice daemon` is running) that there's a connection incoming.

pretty much the same goes for `ondevice rsync` (and the - not yet released... - `scp` and `sftp` subcommands)

Wow, I don't think I would've even considered such an attack...

DNSSEC, HSTS and Certificate Pinning would've made it more difficult to abuse this, but I guess it would've been pretty easy to get valid SSL certificates for all your favourite .io domains.

Let's try to play malicious party here:

Phase A: First set up a simple DNS forwarder playing by the rules and answering requests as we should (as to not get any unwanted attention). Gather usage statistics.

Phase B: Crawl the list of most-used domains to see if there are any valuable targets without HTTPS (port 443 is closed). Alternatively/additionally see if there are API subdomains used by software other than browsers (of which a few won't have annoying features like Cert Pinning - golang's DNS resolver for example afaik doesn't do DNSSEC). Pick some medium to high level targets where the attack might go undetected for at least some time.

Phase C: MitM time! Get certificates for the target domain(s) of your choice and get to work. Start with only a few percent of the requests to not draw too much attention (and to avoid the majority of their traffic coming from a single IP (range) all of a sudden) Obfuscate the attack by acting like a third party app or something simply doing requests for their users.

Congratulations on finding the vulnerability (and thanks for looking for that kinda stuff in the first place).

Hadn't heard of ipset before, but yeah, that seems to be a cleaner way to do this. Maybe open a feature request?

From what I can tell, there are still a few minor details to be etched out in droplan (e.g. running as background service to avoid rewriting the rules every time, ...), but it seems to do its job reasonably well (been using it for roughly two months now

I'm not affiliated with the project (I only did a PR once involving the Dockerfile).

I don't know if it's well known, but the so called 'private' interfaces DO offers aren't really private. Any other machine in the same datacenter can access your services.

So if you have a redis/mongo/... server listening in your 'private' network, I'd suggest you secure your internal services using a firewall (and droplan is a pretty simple tool to do so automatically)

GoRef is a small Go library I've built to better monitor a project of mine.

I'm using it to measure the execution time of all my HTTP routes (and other important code paths) to track down potential bottlenecks in the application (and it helped me detect a goroutine that didn't exit properly in a certain cases)

It's designed to have as little as possible overhead (as it's meant to be used in production code)

Thanks to you and the others for clarifying. For some reason it didn't occur to me they were talking about an ion engine. I've heard of them and their slow-but-steady acceleration characteristics before but never actually knew how they work (and for some reason didn't quite make the connection).

One thing I don't quite get is their claim that the rocket would need "just some solar panels" instead of a fuel tank when in the paragraph before that they talk about exhausting argon-based plasma.

If there is a propellant, you'd need to store that somewhere first, right? Does each particle of the propellant exit the rocket with much higher energy? Or can Argon be stored in a much denser form than other fuels?