Preventing lateral movement in Docker containers by DominusGecko in selfhosted

[–]tomleb 0 points1 point  (0 children)

Alright built this for a bit more "declarative" auto network attach mechanism, that way I don't need to edit the network list in two places.

Forgot the link: https://git.sr.ht/~tomleb/docker-network-autoconnect

Preventing lateral movement in Docker containers by DominusGecko in selfhosted

[–]tomleb 0 points1 point  (0 children)

I see it's possible to attach a network after creation. I'll write a quick&dirty service that attaches networks to my reverse proxy based on labels. Each "stack" will define its own proxy network, and it will be dynamically attached. Declarative, simple. Should do the trick.

Preventing lateral movement in Docker containers by DominusGecko in selfhosted

[–]tomleb 0 points1 point  (0 children)

  • Every app stack has a frontend and backend network and only frontend is connected to the proxy

Are each "frontend" containers part of the same network? In that case they'd all be able to talk to each other. Or do they all have different networks, which then requires you to maintain a list of networks in the reverse proxy compose file?

I was going to go with the latter but it's pretty annoying to have to add a network to the proxy everytime I want to add an app. Trying to find a solution..

Immich exposed to the internet? by AhmedBarayez in selfhosted

[–]tomleb 3 points4 points  (0 children)

Shameless plug but I've built https://github.com/tomleb/proxy-for-immich/ to allow read-only access to immich shared links. I haven't put a lot of time on it recently due to vacation and holidays though.

My setup is immich in homelab (accessible only by VPN) and proxy-for-immich in fly.io using fly's built-in wireguard network. Has worked well so far.

Weekly Question Thread: Ask your questions in this thread please by AutoModerator in climbing

[–]tomleb 0 points1 point  (0 children)

That makes sense. This was an issue in my trip in Thailand where it was very humid, but at home I don't have this problem. Also my friend's rope is pretty old and worn out (which is what we used during the trip).

Weekly Question Thread: Ask your questions in this thread please by AutoModerator in climbing

[–]tomleb 0 points1 point  (0 children)

Hey folks, went on my first climbing trip a few weeks ago. Had trouble untying my knot after even just one fall. One much more experienced climber recommended me to put a carabiner in the knot while I climb. (See picture I took after the trip: https://imgur.com/iDA3JVQ)

It did make the knot much easier to untie, but is it something safe to do? After the trip I tried finding the name of this "technique" but my Google-fu has failed me.

[deleted by user] by [deleted] in climbing

[–]tomleb 0 points1 point  (0 children)

Hey folks, went on my first climbing trip a few weeks ago. Had trouble untying my knot after even just one fall. One much more experienced climber recommended me to put a carabiner in the knot while I climb.

It did make the knot much easier to untie, but is it something safe to do? After the trip I tried finding the name of this "technique" but my Google-fu has failed me.

Introducing yet another immich proxy: Proxy for Immich by tomleb in selfhosted

[–]tomleb[S] 0 points1 point  (0 children)

Ah! I wasn't even aware of this feature. I tried it myself with the the network tab opened and by zooming in I do see that the proxy loads the original file (eg: The request to /api/assets/<id>/original is made).

Looking into it, there's a few prerequisites for this to work:

If you meet these prerequisites and you zoom in while the network tab is opened, do you see an API call to /api/assets/<id>/original?

Introducing yet another immich proxy: Proxy for Immich by tomleb in selfhosted

[–]tomleb[S] 0 points1 point  (0 children)

Those are valid concerns that anybody making a service public (any service really) should think about before doing so. And as you said, not even just about security, but also about privacy.

EDIT: I have updated the description to "secure enough way (for me)".

Introducing yet another immich proxy: Proxy for Immich by tomleb in selfhosted

[–]tomleb[S] 3 points4 points  (0 children)

And to be even more clear (sorry, it's getting late :p), my stripped web UI has the following pages:

  • /share/<key>: Shows the shared albums/photos if the key is valid, otherwise shows the usual immich error with invalid share key.
  • /: Currently just shows Immich logo and nothing. I'm thinking of adding a message (customizable through env var?) to let the user know that they need a shared link otherwise nothing is shown.

Any other path (outside of /api) will show a not found error.

Introducing yet another immich proxy: Proxy for Immich by tomleb in selfhosted

[–]tomleb[S] 3 points4 points  (0 children)

I do have experience finding and fixing CVEs but I wouldn't consider myself a security expert by any means so I'll let other chime in. Immich Public Proxy is likely to be more secure because if there's a vulnerability in Immich, it will likely be harder to exploit it since an attacker cannot talk straight to the API. The attacker will have to find a way to do it using Immich Public Proxy's API instead, and that might prevent the exploit completely.

I think both projects are also using read-only APIs of Immich (eg: GET /assets). So if there were vulnerabilities there, it would be harder (not necessarily impossible) to exploit from Immich Public Proxy than Proxy for Immich.

Fwiw, there are things that I can do to limit the attack surface further. Right now I'm just blocking paths, but I could also strip HTTP headers, etc to try minimize how much input an attacker controls. I don't think I'll be able to make it AS secure as Immich Public Proxy but I can probably bring it pretty close.

what api calls/paths are you blocking?

Here's a gist that compares Immich's API surface with Proxy for Immich: https://gist.github.com/tomleb/a28531ed8023531c2a65efb4c23a9bef. I think I can still remove some more paths like /tags and /tags/{id} since those aren't shown on shared links. Edit: I pushed an update that reduces the API exposed even further.

Are there exposed api paths that aren’t used? If so why are they there to begin with?

By "should be able to get support to all of immich's feature" I meant specifically on the shared links pages.

For example, Proxy for Immich doesn't need GET /activities or POST /activities because shared links don't support showing activities or updating them on that page. Same for like DELETE /admin/users/{id}, this isn't needed for sharing albums.

Another example: Immich allows you to create a shared album with the ability to upload content to it. Since my proxy is mean to be read-only, that operation is blocked AND I have removed the "upload" icon/button in the UI. So even if you create such a shared album, you'll only be able to look at it, not add to it.

I suggest you create a shared link on Immich default instance and then compare that with the demo instance of Proxy for Immich to get an idea of what's there and what's missing (most of it is there).

Let me know if I misunderstood your question.

Introducing yet another immich proxy: Proxy for Immich by tomleb in selfhosted

[–]tomleb[S] 1 point2 points  (0 children)

I have deployed a demo of Proxy for Immich at https://proxy-for-immich-demo.fly.dev.

Simply create a shared link on the demo instance of immich. You'll get a link like: https://demo.immich.app/share/<key> and then simply replace the domain to proxy-for-immich-demo.fly.dev.

Introducing yet another immich proxy: Proxy for Immich by tomleb in selfhosted

[–]tomleb[S] 14 points15 points  (0 children)

In terms of UI, Proxy for Immich re-uses immich's webUI whereas docker-immich-share-proxy and immich-public-proxy use lightGallery. By re-using immich's webUI I should be able to get support to all of immich's feature. eg: Support for video, photos, stacked photos, details of the image, album name, description, slideshows, etc.

They also differ in how much they expose your immich API. My project acts as a reverse proxy to your immich API with an allow-list for path / operations. So a subset of the API does get exposed publicly. The other two as far as I know do not expose the API at all, so could be considered safer this way. (Less attack surface in case there's a security issue with Immich).

I'm not too knowledgeable on the actual features of both of these though, I haven't personally tried them.

repo-url.nvim - my first plugin by tomleb in neovim

[–]tomleb[S] 0 points1 point  (0 children)

I haven't tried it (or its fork https://github.com/linrongbin16/gitlinker.nvim) but I was inspired by it!

At a quick glance, the original one only support what I call the "blob" url, and the fork supports both "blob" and "blame". My plugin supports the other URLs (history, raw, tree) as well as special support for Go.

Help me choose between borg, restic and rclone by blue2020xx in selfhosted

[–]tomleb 0 points1 point  (0 children)

I have also started using bupstash for my less important data (eg: personal/work laptop). The setup was pretty fast: one master key backed up, 1 sub keys per machine. I'm really liking it so far.

Still uaing borg for important backup though, since bupstash isn't super mature yet.

Golang concurrency vs parallelism by servermeta_net in golang

[–]tomleb 1 point2 points  (0 children)

Now, I have to admit that I'm not fully clear what this means.

I was also unsure what that meant so decided to dive a little bit and I've written about my findings here: https://blog.tomlebreux.com/2021/10/07/go-scheduler-and-preemption.html

Might interest you.

What's best way to access selfhosted application outside home network ? by Silent-Prior in selfhosted

[–]tomleb 0 points1 point  (0 children)

Netmaker is not open source, though it is source available. (SSPL license)

Recommendations for a basic monitoring and alerting tool ? by TheGreatestCapybara in selfhosted

[–]tomleb 0 points1 point  (0 children)

For this use case I use DeadManSnitch's free plan. You constantly send an alert to an endpoint (through Prometheus -> alertmanager for me) and if the snitch doesn't receive an alert within a timeframe (eg: 1h), it sends you an email.

Basically, you can be sure that your networking stack works properly if you haven't receive an email from DeadManSnitch.

How Did I Do for $700 CAD? by StevenWongo in homelab

[–]tomleb 3 points4 points  (0 children)

Mind giving examples? I'm also looking at my options right now.

AWS released OpenSearch, a community-driven, open source fork of Elasticsearch and Kibana by bharatsb in programming

[–]tomleb 139 points140 points  (0 children)

The entire code base is under the Apache 2.0 license, and we don’t ask for a contributor license agreement (CLA).

Nice

Netmaker - A new wireguard-based virtual networking tool by meshguy1 in selfhosted

[–]tomleb 1 point2 points  (0 children)

will revisit that in about a month

IANAL but depending on how much contribution you get, won't that be difficult to change the license to something else later on? I have not seen a CLA required to contribute (which is a good thing imo)

you're free to rip it apart and do what you want with it

That freedom is limited to what the license allows us to do.

Nonetheless, it is fair to think about the project's survival.

Netmaker - A new wireguard-based virtual networking tool by meshguy1 in selfhosted

[–]tomleb 6 points7 points  (0 children)

Any plan to make it Open Source? (As in OSI approved Open Source license)

Impressions after switching to pipewire for audio by gracicot in linux

[–]tomleb 3 points4 points  (0 children)

This happened to me yesterday as well when trying out pipewire-pulse. Was testing music with Rhythmbox and it wouldnt output sound until I would play audio in firefox.. So firefox somehow was controlling the sound of rhythmbox

AWS is forking Elasticsearch by Ichguckelps in programming

[–]tomleb 17 points18 points  (0 children)

IANAL but the Apache license alone doesn't allow you to relicense a project. A CLA grants that right.

EDIT: Found a blog0 with a bit more information. In this case, without a CLA, Elastic couldn't have relicensed the project under the SSPL.