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?

My guess is that especially if you're shopping in the 5$ price range, there's gonna be a much more important factor than some benchmark results: Availability and cost of extra features.

For java apps you're probably go for as much RAM as possible (giving Linode the edge here) OVH.com for example has an S3-like object store or alternatively, physical NAS hardware (amongst a bunch of other extras). I personally am currently looking to keep the traffic cost at a minimum (DO still doesn't charge for extra traffic but plan to do so in the future [1], Scaleway and OVH have unlimited traffic).

Some of the ones I've looked into recently also provide DDoS protection and/or load balancing while others apparently null-route your IP(s) until you can get them on the phone[2] (DDoS protection seems to be a pretty costly feature to offer).

Since all of the described (and I guess most of the discussed) services provide fast provisioning, it should be relatively easy to jump ship if you later find out you picked the wrong service.

[1] https://www.digitalocean.com/community/questions/extra-bandw... [2]: https://news.ycombinator.com/item?id=6577465

A little anecdote: About half a day after I've started using vultr, I got an abuse message from their SPAM detection system claiming that one of my IPs was sending loads of spam emails prompting me to respond within 48 hours (everything looked like my server was flagged automatically). The problem was, the time of the incident was about 12hours before I even created the instance in question. The issue was resolved quickly (there wasn't a lot to argue about after all) and I haven't had problems since, but nevertheless this leaves me wondering whether they (or another provider like them) might end up blocking my account one day simply because I missed an email. But you can't really expect premium service for dirt-cheap products, can you ;)

edit: formatting

I've had a quick look at your site because I'm currently using DO and Vultr with a PeerVPN[0] setup to connect the individual hosts - which brings me to my question:

Is it just a static website or do these instances communicate with each other? If you do, I'd like to ask if you use a VPN to connect them (and which one)?

I'm relatively happy with PeerVPN (with one or two rather minor annoyances that most likely can be solved if I actually spent time on them) but am always curious about alternatives.

[0] https://github.com/peervpn/peervpn

Has anyone of you experience with the fasthttp Go library[0]?

Does it keep its promise in terms of speed? (I assume real world code would spend much more time in actual business logic than their examples/benchmarks so I guess there wouldn't be as much a difference as they claim, but the idea of zero allocations intrigues me)

[0] https://github.com/valyala/fasthttp

So I guess the best-practice approach would be to chown/chmod/rm the file after reading its contents (assuming it'll be restored when you restart the container).

So far my approach was defining environment variables in the various docker-compoose files (in a separate deployment git repo), but this looks like a really nice alternative.

Do you have plans to update the library images to give us a choice between using ENV and secrets (for DB server passwords and the like)?

On an aside: I've gotten the Docker Datacenter announcement mail today. I only took the time to skim its contents quickly and at first thought this was a DDC-only thing. Glad to hear it isn't, keep up the awesome work.

edit: clarified my docker-compose usage

It's not just firewalls. The fact that (unencrypted) FTP is still widely used today when better alternatives like SFTP (via SSH) have existed for years strikes me as odd.

(I'm speaking about authenticated connections. For anonymous access - which should be read-only anyway - you're usually better off using HTTP anyway)

Interesting...

I bet if we had used FTP instead of HTTP for serving HTML right from the start, FTP would today have all of the same extensions and the same people would argue for it being too bloated :) (HTTP started as pretty minimalistic protocol back in the day)

I often find the discrepancy between what HTTP has originally been designed for (serving static HTML pages) and all the different things it's being used for today highly amusing. Yes, some of todays applications for HTTP border on abuse, but its versatility (combined with its simplicity) fascinates me.

Could you elaborate your issues with HTTP a bit? What kind of protocol would do a better job?

Minimal implementations of HTTP (and I'm strictly talking about the transport protocol, not about HTML, JS, ...) is dead simple and relatively easy to implement.

Of course there's a ton of extensions (gzip compression, keepalive, chunks, websockets, ...), but if you simply need to 'add HTTP' to one of your projects (and for some reason none of the existing libraries can be used) it shouldn't take too many lines of code until you can serve a simple 'hello world' site.

On top of all that, it's dead simple to put any one of the many existing reverse proxies/load balancers in front of your custom HTTP server to add load balancing, authentication, rate limiting (and all of those can be done in a standard way)

Furthermore, HTTP has the huge advantage of being readily available on pretty much every piece of hardware that has even the slightest idea of networking. Any new technology would have to fight a steep uphill battle to convince existing users to switch.

Have I mentioned that it's standardized and open?

Hi, Manuel from ondevice.io here. I've been working on this side project for a couple of months now and finally want to bring it to a larger audience :)

The main idea is to have an easy way to SSH into your devices from anywhere, without the headaches of NAT traversal. Since it simply tunnels SSH, traffic is encrypted and SSH authenticated. On top of that, there's an additional 'service-side' authentication layer (so only you can access your devices). And you can do port forwarding, rsync and all the other fun stuff SSH provides.

The traffic is tunneled using websockets over HTTPS. The server side is protocol agnostic though and there are plans to add other stuff (VNC, HTTP, ...). The client is written in Python and hosted on github [1]

I'll stick around here for a while and try to answer your questions.

[1] https://github.com/ondevice/ondevice-client

You might want to add a 'motd' with a little welcome message and a simple 'help' listing the commands and a one liner for each of them (Autocomplete for some reason didn't work for me - Chrome 48, Mac).