How do you keep track of vulnerabilities?

Comments

• bigDottee@geekroom.tech ⁨1⁩ ⁨year⁩ ago

  I’ve just started to delve into Wazuh… but I’m super new to vulnerability management on a home lab level. I don’t do it for work so 🤷🏼‍♂️

  Anyways, best suggestion is to keep all your containers, vms, and hosts updated best you can to remediate vulnerabilities that are discovered by others.

  Otherwise, Wazuh is a good place to start, but there’s a learning curve for sure.

  source
• tuxec@infosec.pub ⁨1⁩ ⁨year⁩ ago

  There are a couple of things to cover here:

  1. Keep your software/containers up to date. You can subscribe to the GitHub repo and configure it to get notified for new releases and security alerts. Complementary, you can use newteleases.io and/or WUD (What’s Up Docker) and add labels to your docker compose files. Personally, I check the notification once a week and change the version for all minor tools I’m using. If there is a major release (or new Immich version) I read the changelog and update instructions (if it’s the case).

  2. For security scans, you use Trivy, but the problem is that you don’t have a centralized overview of your scan results. For this you can use DefectDojo. Depending on the case/threat model, vulnerability management for self-hosted things might be overkill, but highly recommended of you want to learn more about this. It worth mentioning Trufflehog as secrets scanner and sops as a solution to encrypt sensitive data so you can push it to git/SCM.

  source
• F04118F@feddit.nl ⁨1⁩ ⁨year⁩ ago

  GitOps + Renovate.

  Tools that allow you to work GitOps (everything is defined in text files in Git) are:

  • Kubernetes
  • NixOS
  • to a lesser degree, Ansible

  Here’s a nice starter template for running your own Kubernetes cluster via GitOps with Renovate pre-configured: github.com/onedr0p/cluster-template

  source
• ueiqkkwhuwjw@lemmy.world ⁨1⁩ ⁨year⁩ ago

  Thank you everyone for the helpful replies!

  source
• K3can@lemmy.radio ⁨1⁩ ⁨year⁩ ago

  There are some tools to help, but things are sort of specific to particular aspects. Lynis for general systems, ntopng for networks, and such.

  For 90% of stuff, though, you can just stick to stable repos and upgrade on a schedule and you’ll be alright.

  source
• lambalicious@lemmy.sdf.org ⁨1⁩ ⁨year⁩ ago

  I don’t.

  Yeah, hot take, but basically there’s no point to me having to keep track of all that stuff and excessively worry about the dangers of modernity and sacrifice the spare time I have on watching update counter go brrrr of all things, when there’s entire peoples and agencies in charge of it.

  I just run unattended-upgrades (on Debian), pin container image tags to only the major version number where available, run rebuild of containers twice a week, and go enjoy the data and media I built the containers and installed for software for.

  source

  • 9488fcea02a9@sh.itjust.works ⁨1⁩ ⁨year⁩ ago

    I think the problem is that a lot of people are just running flatpaks and dockers which might not be getting timely updates.

    I try to stick to debian packages for everything as much as possible for this reason.

    source

    • lambalicious@lemmy.sdf.org ⁨1⁩ ⁨year⁩ ago

      Regarding things like dockers and flatpaks, I mostly “solve” it by only running official images, or at least images from the same dev as the program, where possible.

      But also IMO there’s little to no reason to fear when using things like flatpaks. Most exploits one hears of nowadays are of the kind “your attacker needs to get a shell into your machine in the first place” or in some cases evn “your attacker needs to connect to an instance of a specific program you are running, with a specific config”, so if you apply any decent opsec that’s already a v high barrier of entry.

      And speaking of Debian, that does bring to mind the one beef I have with their packaging system: that when installing a package it starts the related services by default, without even giving you time to configure them.

      source
• vegetaaaaaaa@lemmy.world ⁨1⁩ ⁨year⁩ ago

  • distribution packages: unattended-upgrades
  • third party software: subscribe to the releases RSS feed (in tt-rss or rss2email), read release notes, bump version number in my ansible playbook, run playbook, done.

  source
• LiveLM@lemmy.zip ⁨1⁩ ⁨year⁩ ago

  VPN only, nothing exposed, the host runs openSUSE MicroOS which updates itself daily, all the containers get updated daily by Watchtower and if something blows up so be it, except for Nextcloud as everyone says it’s brittle as hell.

  source
• ShortN0te@lemmy.ml ⁨1⁩ ⁨year⁩ ago

  Most critical infrastructure like my mail i subscribe to the release and blog rss feed. My OSs send me Update notifications via Mail (apticron), those i handle manual. Everything else auto updates daily.

  You still need to check if the software you use is still maintained and receives security updates. This is mostly done by choosing popular and community drive options, since those are less likely to get abandoned.

  source
• enumerator4829@sh.itjust.works ⁨1⁩ ⁨year⁩ ago

  Unless you have actual tooling (i.e. RedHat erratas + some service on top of that), just don’t even try.

  Stop downloading random shit from dockerhub and github. Pick a distro that has whatever you need packaged, install from the repositories and turn on automatic updates. If you need stuff outside of repos, use first party packages and turn on auto updates. If there aren’t any decent packages, just don’t do it. There is a reason people pay RedHat a shitton of money, and that’s because they deal with much of this bullshit for you.

  At home, I simply won’t install anything unless I can enable automatic updates. Nixos solves much of it. Two times a year I need to bump the distro version, bump the nextcloud release, and deal with depreciations, and that’s it.

  I also highly recommend turning on automatic periodic reboots, so you actually get new kernels running…

  source
• catloaf@lemm.ee ⁨1⁩ ⁨year⁩ ago

  That’s the neat part. I don’t!

  I have automatic updates on everything, but if I actually spent time managing updates and vulnerabilities I’d have no time to do anything else in my life.

  source
• Darkassassin07@lemmy.ca ⁨1⁩ ⁨year⁩ ago

  95% of things I just don’t expose to the net; so I don’t worry about them.

  Most of what I do expose doesn’t really have access to any sensitive info; at most an attacker could delete some replaceable media. Big whoop.

  The only thing I expose that has the potential for massive damage is OpenVPN, and there’s enough of a community and money invested in that protocol/project that I trust issues will be found and fixed promptly.

  Overall I have very little available to attack, and a pretty low public presence. I don’t really host any services for public use, so there’s very little reason to even find my domain/ip, let alone attack it.

  source

  • kewko@sh.itjust.works ⁨1⁩ ⁨year⁩ ago

    You should try wireguard if you haven’t before, like a breath of fresh air

    source
• N0x0n@lemmy.ml ⁨1⁩ ⁨year⁩ ago

  For my docker containers I use what’s up docker which not only alerts me when there is an update but also give a link to the changes, so I can have a look what’s happening !

  For my system itself… Just doing sudo pacman -Syu. Though that’s not great, cause some updates can potentially break my EndeavourOS system… I keep sometimes an eye on the forum when I see some critical changes like the kernel itself or nvidia updates though.

  source
• sugar_in_your_tea@sh.itjust.works ⁨1⁩ ⁨year⁩ ago

  I just update every month or two, or whenever I remember. I use Docker/podman, and I set the version to whatever minor release I’m using, and manually bump after checking the release notes to look for manual upgrade steps.

  source
• just_another_person@lemmy.world ⁨1⁩ ⁨year⁩ ago

  Trivy and Grype will give you a pretty decent idea of what you have for exposure, but you’re at the best of any project for fixing their own issues, or you can contribute updates if accepted.

  Really the first line of defense is just securing your comms to the public internet. If you’re running everything internally, you have a lot less to worry about. Nothing will ever be bulletproof though.

  source
• eager_eagle@lemmy.world ⁨1⁩ ⁨year⁩ ago

  upgrade all things by default

  github.com/topgrade-rs/topgrade/

  source

  • NaibofTabr@infosec.pub ⁨1⁩ ⁨year⁩ ago

    This is also a great way to just break everything you’ve set up.

    source

    • eager_eagle@lemmy.world ⁨1⁩ ⁨year⁩ ago

      that’s a lot of FUD, topgrade just upgrades all package managers you have, it doesn’t do the upgrades itself bypassing the package authors

      source

      • -> View More Comments
  • just_another_person@lemmy.world ⁨1⁩ ⁨year⁩ ago

    This is a bad idea for a number of reasons. Most obvious issue is that it doesn’t guarantee anything in the way of actually fixing vulnerabilities, because some project you use may not even be scanning their own work.

    source

    • eager_eagle@lemmy.world ⁨1⁩ ⁨year⁩ ago

      what’s the alternative? Write a PR yourself?

      source

      • -> View More Comments
• sk@hub.utsukta.org ⁨1⁩ ⁨year⁩ ago

  i subscribe to the release page of the repo in my rss reader. simple and effective.

  source

  • JustEnoughDucks@feddit.nl ⁨1⁩ ⁨year⁩ ago

    That is a fantastic idea. Wtf how is this not commonplace? Or am I just way behind 😅

    source
• slazer2au@lemmy.world ⁨1⁩ ⁨year⁩ ago

  Does badly count as a way?

  I kinda keep an eye on that self hosted .sh post that does a weekly roundup of stuff to know when I need to do patching.

  No doubt there is a container I could run that would do it for me. I just can’t remember the name of it.

  source
• 30p87@feddit.org ⁨1⁩ ⁨year⁩ ago

  How do I do it? Everything’s installed and updated via pacman/the AUR, including python packages and nextcloud apps. The only thing I don’t install via that way is Firefox addons.

  source