71–80 of 104 posts
Humble question: how do you find out if your system has been affected by a malware? I know that for AUR there was a specific list of affected packages (that I checked, and haven't installed any of them), but I'm interested more in a general way. It could be from AUR, npm, or many other sources. Some malware could break and lock immediately the system, but other could stay there silent for months, so how to find out i…
Humble question: how do you find out if your system has been affected by a malware? I know that for AUR there was a specific list of affected packages (that I checked, and haven't installed any of them), but I'm interested more in a general way. It could be from AUR, npm, or many other sources. Some malware could break and lock immediately the system, but other could stay there silent for months, so how to find out i…
Ultimately I'd say it depends on your risk profile, but using something to actively approve/deny network connections on your local machine, is a great start that'd defeat most of these simpler "exfiltrate information ASAP" malware that seems popular at the moment.
Earlier quoted context omitted.
Is there another distro that has an equivalent of the AUR with handling you think is preferable?
No because there’s no way to handle an open submission repository at all. It’s impossible by design since anyone can submit packages to it. I would never use anything equivalent to AUR on any distro due to the obvious security implications. That’s been my position for as long as I have known about Arch. I never understood Arch users using the AUR as a selling point for the distro. Then again I live in the opposite en…
It’s basically like a crowdsourced set of people’s tips and tricks for installing stuff on Arch, all written in the format Arch uses for packages.
Similar to how I’d not blindly take code from an AI and whack it into production, I wouldn’t blindly take an AUR PKGBUILD and execute it. But it’s nice to have a place to go see “huh, I wonder if anybody has shared their approach so I can borrow from it”.
Humble question: how do you find out if your system has been affected by a malware? I know that for AUR there was a specific list of affected packages (that I checked, and haven't installed any of them), but I'm interested more in a general way. It could be from AUR, npm, or many other sources. Some malware could break and lock immediately the system, but other could stay there silent for months, so how to find out i…
In theory, you'd mostly care about exfiltration of data, so watching/actively managing exactly what network connections your computer/network can do, would give you upfront notification when it happens, but of course not earlier. And if your root/hardware somehow is infected, your monitoring/management tools might be affected too, so then you're basically out of luck except with external network gear outside of your…
If you have a list of good CLI utilities, you could run them in a bash script (e.g., network-monitor.sh), which would run in the background, and then redirect the output data to another file (e.g., network-monitor.txt). The key concept here is "baseline" -- you need to know what normal baseline network activity looks like, so that you can identify anomalous behavior. The way to establish a baseline is to gather a lot of data from the system.
The following are a few useful command line utilities to use for a host intrusion detection system (HIDS) using a simple network monitoring bash script. However, I am not sure exactly how to tweak the options. Also need to find a way to check for data exfiltration:
-list open ports and processes that own them: netstat -lnp
-show open network ports: lsof -i; netstat -an | grep -i listen; netstat -nap
Then it would be relatively easy to write a python script with regex tools to parse the network-monitor.txt file, establish a baseline, analyze the data for patterns and search for anomalous behavior.
Besides network monitoring, there are other command line utilities you can use to check the system for possible intrusion, which you could run in a separate bash script as part of your Host Intrusion Detection System (e.g., hids-users.sh):
-show members of root group: cat /etc/group | grep root
-show users logged in: w #if you are the only user, you should not see more than one account logged in
-search for all accounts with UID of 0: grep :0: /etc/passwd #ideally there should be only one UID of 0 on the system, but attacker can create more.
-check that daemons who never log in have * or !, meaning no passwd: cat /etc/shadow
-look for orphaned files, possible sign of attacker temp account deleted: find / -nouser -print
-search for new user accounts that are not part of regular build: sort -nk3 -t: /etc/passwd #sort numerically third column (UID), colon delim (-t:)
EDITS: several small changes for clarity and also in response to comment below
Earlier quoted context omitted.
No because there’s no way to handle an open submission repository at all. It’s impossible by design since anyone can submit packages to it. I would never use anything equivalent to AUR on any distro due to the obvious security implications. That’s been my position for as long as I have known about Arch. I never understood Arch users using the AUR as a selling point for the distro. Then again I live in the opposite en…
The AUR is, in my opinion, a pretty convenient selling point if you use any esoteric software. It’s basically like a crowdsourced set of people’s tips and tricks for installing stuff on Arch, all written in the format Arch uses for packages. Similar to how I’d not blindly take code from an AI and whack it into production, I wouldn’t blindly take an AUR PKGBUILD and execute it. But it’s nice to have a place to go see…
However, I’ll push back a bit from my perspective as a Debian Stable user. I would consider even the official Arch repositories to be dangerous just like I consider Debian Sid’s repos to be dangerous (packages are too new and not sufficiently vetted). Then regarding installing packages not available in the main Debian repos, I’ve never really had any issues installing them either as there is always either an official developer run apt repo I can add, or an official deb package, or it just builds directly from official source without tweaks. So I’ve honestly never felt like I was missing “a crowdsourced set of people’s tips and tricks for installing stuff” on Debian as I’ve just never needed one.
I do realize that installing the latest packages directly from a developer’s repo or latest deb package or source is as dangerous as the Debian Sid or Arch official repos for the same reason (too new, not vetted), but the difference is those are only a tiny portion of the packages installed on my system (like a percent of a percent, maybe a half dozen packages out of hundreds). If I ran Sid or Arch, it would be 100% of the packages on my system which is an attack surface orders of magnitude larger.
EDIT: It did just occur to me after posting this reply that I use Homebrew pretty extensively as a package manager on macOS and its official repos are equivalent to Sid/Arch official repos, so I may be a bit of a hypocrite here :P
The AUR really has been known to be low-hanging fruit for bad actors, which makes it somewhat surprising it took this long for it to be taken advantage of. I have many opinions regarding this situation, but it mostly doesn't matter. AUR staff and AUR helper developers will figure out what they want to do, hopefully they will find a good approach. But what I personally take away from this is simply that it has become…
Absolutely the wrong conclusion:
1. This is a super low hanging fruit attack
2. The ROI is significantly higher than the cost of attack
3. The cost of the attack is now drastically reduced due to LLMs (not that they necessarily mattered here but hard to rule out).
It’s less about the Linux desktop where Ubuntu is dominant and more that Arch security is so bad regarding how they maintain the AUR. Seriously it’s worse than Swiss cheese in terms of putting up roadblocks.
Humble question: how do you find out if your system has been affected by a malware? I know that for AUR there was a specific list of affected packages (that I checked, and haven't installed any of them), but I'm interested more in a general way. It could be from AUR, npm, or many other sources. Some malware could break and lock immediately the system, but other could stay there silent for months, so how to find out i…
You might start with ClamAV and something like Little Snitch.
In case anyone missed it, the latest version of yay (v13+) supports being able to skip recently added packages through its new Lua extension system https://jguer.github.io/yay/lua.html#upgrade-selection-hooks . You can control the threshold since it's just user configuration now. A bunch of common yay commands also return back the last updated time of a package thanks to https://github.com/Jguer/yay/pull/2846 .
The thing is that hook is not enough: `UpgradeSelect` only applies to `yay -Syu` so it only filters the upgrade list. Nothing protect you from a `yay -S foo` install and its dependencies. So this is not a guarantee or enforcement of a minimum release-age. Actually writing this reply I went ahead and pointed that out in an issue at: https://github.com/Jguer/yay/issues/2883