Many projects ask to share lots of logs when reporting issues. It’s difficult to go through all the logs and redact informarion such as usernames, environment variabled etc.

Any ideas on how to anonymize logs before sharing? Change your username to something generic?

  • neidu2@feddit.nl
    link
    fedilink
    arrow-up
    30
    arrow-down
    1
    ·
    edit-2
    4 months ago

    For me this typically involves doing a search&replace for my username, hostname, and IP addres(es)

    • pezhore@lemmy.ml
      link
      fedilink
      arrow-up
      5
      ·
      4 months ago

      This is the correct answer. Private IPs are less concerning (on noes now someone knows a network in my homelab is 10.0.0.1/24!) - but absolutely change public IPs in logs.

      If it’s necessary to reference external users/systems in multiple log files, I’ll change the names to user1, user2, server1, db2, etc

    • wizardbeard@lemmy.dbzer0.com
      link
      fedilink
      English
      arrow-up
      3
      arrow-down
      1
      ·
      edit-2
      4 months ago

      This can also be mitigated by using a username and/or hostname that doesn’t leak private data.

      No need to make your username your real name, or make your hostname contain anything more revealing than say “living room thinkpad”

  • gencha@lemm.ee
    link
    fedilink
    arrow-up
    23
    ·
    4 months ago

    I remember this mindset in myself. Today I consider it a waste of time.

    If you rely on any tool for this, the tool will make mistakes you cannot accept. If you do it manually, you will make mistakes as well and that also does not work. Also, the information your consider worthy for removal might be key to understanding the problem.

    Like, you remove your name, but a certain character in your name is what is actually tripping up the program.

    Ultimately, don’t post your logs publicly. In the past years, I was always able to email logs to devs. I have no reason not to trust them with my log. If they want data from me, they could easily exfiltrate it through their actual application.

    • some_guy@lemmy.sdf.org
      link
      fedilink
      arrow-up
      4
      ·
      4 months ago

      This is the best advice. There’s nothing to be gained from having your info. I have sent logs to many independent devs / shops and have no fear about it. Having spent years looking at other peoples’ logs, I can tell you that people only care about resolving bugs to make their jobs easier.

      • derek@infosec.pub
        link
        fedilink
        arrow-up
        3
        ·
        4 months ago

        This is admittedly a bit pedantic but it’s not that the risk doesn’t exist (there may be quite a lot to gain from having your info). It’s because the risk is quite low and the benefit is worth the favorable gamble. Not dissimilar to discussing deeply personal health details with medical professionals. Help begins with trust.

        There’s an implicit trust (and often an explicit and enforceable legal agreement in professional contexts (trust, but verify)) between sys admins and troubleshooters. Good admins want quiet happy systems and good devs want to squash bugs. If the dev also dons a black hat occasionally they’d be idiotic to shit where they eat. Not many idiots are part of teams that build things lots of people use.

        edit: ope replied to the wrong comment

    • ouch@lemmy.worldOP
      link
      fedilink
      arrow-up
      1
      ·
      4 months ago

      What would be the most common username and hostname?

      Are there even any default usernames in distros?

      As for hostname, I think Debian defaults to debian.

      • boredsquirrel@slrpnk.net
        link
        fedilink
        arrow-up
        2
        ·
        4 months ago

        Yeah but that reveals your distro. Default is nowhere used I think, but I think “PC” is a good default.

        And “user” is for sure the default username

        • MimicJar@lemmy.world
          link
          fedilink
          arrow-up
          2
          ·
          4 months ago

          Sure that reveals your distro, but also consider what is in the logs you’re sharing. If you’re asking for help you probably also already said that you’re running Debian. Or the logs are full of apt logs already, querying a well known Debian mirror.

          You’re right that PC is a fine default, but think about the whole picture as well.

          • boredsquirrel@slrpnk.net
            link
            fedilink
            arrow-up
            1
            ·
            edit-2
            4 months ago

            The distro is not regarding logs but local network, public wifis, etc. Data minimization.

            For logs of course you can tell them what you are running.

  • QuazarOmega@lemy.lol
    link
    fedilink
    English
    arrow-up
    15
    ·
    4 months ago

    A tool would actually be so good to have, it’s such a common thing that we don’t even think about it much. You sparked my curiosity so I tried to search if there was one and it seems there is a project out there: loganon, though it’s long dead unfortunately

    • The problem is there’s likely not a universal solution that’s guaranteed to clean everything in every case.

      Cleaning specific logs/configs is much easier when you know what you’re dealing with.
      Something like anonymizing a Cisco router config is easy enough because it folllows a known format that you can parse and clean.
      Building a tool to anonymize some random logs from a specific software is one thing, anonymizing all logs from any software is unlikely.
      Either way, it should always be double-checked and tailored to what’s being logged.

      • subtext@lemmy.world
        link
        fedilink
        arrow-up
        4
        ·
        4 months ago

        I wonder if you could do something with heuristics or a micro LLM to flag words that might be expected to be private.

        I would be curious if someone could do a proof of concept with the Ollama self-hosted model. Like if you feed it with examples of names, IP addresses, API-key-like-strings, and others, it might be able to read through the whole file and then flag anything with a risk level greater than some threshold.

      • QuazarOmega@lemy.lol
        link
        fedilink
        English
        arrow-up
        4
        ·
        4 months ago

        I agree, besides basic patterns to search for, that will most likely be necessary. In fact looking a bit more at this tool, it has a list of “rules” tailored to each software specifically, I guess this could be sustainable really only if a repository of third party extensions was kept so that anyone could contribute and the pool of rules expanded progressively

    • Maeve@kbin.earth
      link
      fedilink
      arrow-up
      0
      arrow-down
      1
      ·
      4 months ago

      “boosted” this for visibility. Perhaps random devs will take interest.

  • It depends a lot on what the application is logging to begin with.
    If a project prints passwords in logs, consider to just GTFO as it’s terrible security practice.
    There might also be sensitive info that’s not coming from a static thing like your username, but from variable data such as IP addresses, gps coordinates, or whatever thing gets logged.
    Meaning a simple find&replace might be insufficient.

    When possible, I tend to replace the info I remove with a short name of what I replaced out as it’s easier to understand context when it’s not all ********** or truncated.
    example:

    proxy_container_1     | <redacted_client1_ip> - - [17/Aug/2024:12:39:06 +0000] "GET /u/<redacted_local_user2> HTTP/1.1" 200 963 "-" "Lemmy/0.19.4; +<redacted_remote_instance3_fqdn>"
    

    keeping the same placeholders for subsequent substitutions helps because if everything is the same, then you don’t know what’s what anymore.
    (this single line would be easy enough either way, but if you have a bunch and can’t tell client1 from client50 apart anymore that can hinder troubleshooting.

    regular expressions are useful in doing that, but something that works on a specific set of logs might miss sensitive info in another.

    I’m sure people have made tools to help with that, possibly with regex patterns for common stuff, but even with that, you’d need to doublecheck the output to be 100% sure.

    It helps a lot when whatever app doesn’t log too much sensitive info to begin with, but that’s usually out of your hands as a user.

  • gigachad@sh.itjust.works
    cake
    link
    fedilink
    arrow-up
    4
    arrow-down
    1
    ·
    4 months ago

    I agree with the other comment. Write a bash or Python script that replaces your username with something generic. That should do it most of the time. If the logs leak some other sensitive data then the developer fucked up. I always quickly scan logs for stuff I don’t want to share.

  • h0bbl3s@lemmy.world
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    4 months ago

    Just came here to say you could always look for alternative projects that have this built in as well. I’m not sure what logs you as looking at, but it might be best to contribute or request this feature directly for the software.

    For example I use crowdsec and they have a button on the logs pages that will anonymize the entire page and is great for taking screenshots.

    I agree with another poster that getting something to work with a number of different logs would be a huge undertaking and unrealistic for most solo devs. I do think asking whatever project could be a start. I’d love if journalctl and syslogd etc had a flag to anonymize the log output.

    Personally often times I just open the screenshot in gimp and pixelate out the areas I want hidden, but that’s not an automated solution.